Try something like this if you just need one-way radio just need to intermittently send a few bytes [1]. On the receive side there are similar modules [2], but if you've got an RPi on the receive side or a desktop computer then there is another way to receive which I'll describe below.

The transmit module uses a few mA when transmitting. I don't know what it uses when just sitting idle--probably very low but if not just don't give it power except when transmitting. Its maximum current draw is below is below what a GPIO pin can supply on an Arduino, RPi, and microcontrollers such as the ATtiny, so you could probably just hook its Vcc pin directly to a GPIO, hook its DATA IN to another GPIO, hook up ground and (optionally) add an antenna, and you are all set.

Lets say you can send at a rate of 2400 bits/second, and you need to send 400 bits every minute. That's 10 seconds of transmit time per hour. If it draws 10 mA while transmitting, that's 0.028 mAh or 0.14 mWh if you are using a 5 V system. A rechargable NiMH battery has about 2000 mWh capacity, which should power the transmitter for around 600 days.

For receiving you could use the corresponding module, but that is a bit of a pain. The way the transmit side works is that it has an oscillator running at 433.92ish MHz, and a transistor controlling whether or not the output of that oscillator is fed to the antenna. The DATA IN data controls that transistor.

If DATA IN is 1, the module transmits. If DATA IN is 0, the module does not transmit. The typical way this is used is to use this to send a series of pulses. You might encode a 1 message bit as pulse of T usec followed by no transmission for T usec, and a 0 message bit as a T usec pulse followed by 2T usec of silence. Or you might do a 1 as a pulse of 2T followed by silence of T, and a 0 as a pulse of T followed by 2T of silence. There are other ways, but those two are pretty common. (And you might use longer pulses to mark starts of messages or ends of messages).

The receiver module just monitors 433ish MHz and outputs a 1 on its DATA OUT when it thinks someone is transmitting and a 0 when it thinks no one is transmitting. The thing is it automatically adjusts the gain to where it almost always sees something even though it is usually noise. So what you see from the receiver's DATA OUT is an almost constant stream of 1 and 0. You need to look at that, and try to find in that sections that match what your transmitter sends.

If where you want to actually deal with the received data is an RPi or a desktop computer or similar, a simpler approach is to get an RTL-SDR dongle and the program rtl_433 [5]. From the description:

> rtl_433 (despite the name) is a generic data receiver, mainly for the 433.92 MHz, 868 MHz (SRD), 315 MHz, 345 MHz, and 915 MHz ISM bands.

...

> It works with RTL-SDR and/or SoapySDR. Actively tested and supported are Realtek RTL2832 based DVB dongles (using RTL-SDR) and LimeSDR (LimeSDR USB and LimeSDR mini engineering samples kindly provided by MyriadRf), PlutoSDR, HackRF One (using SoapySDR drivers), as well as SoapyRemote

It already knows about nearly 200 sensors and devices. Find a device it already supports that is similar to what you are doing, and use that as a model to add a decoder for your device.

[1] https://www.sparkfun.com/products/10534

[2] https://www.sparkfun.com/products/10532

[3] It is a very popular band for a ton of consumer devices. In my fairly low density neighborhood, I can pick up at least 5 temperature or temperature/humidity sensors from various home weather stations, the sensors from someone's AcuRite 5-in-1 weather station [4], the tire pressure sensors from several cars, someone's power use monitor, a soil moisture sensor, and some sort of remote button or keypad.

[4] https://www.weathershack.com/product/acurite-06004m.html

[5] https://github.com/merbanan/rtl_433