I found a deal during Prime Day or something on some cheap Govee Leak Sensors. What drew me to these initially is they had a local alarm as well as an option to smart home integration. Normally for these to work in a smart home you have to purchase a hub (yay, yet another hub) but they transmit on a 433mhz broadcast and I heard rumors of stories of legends that you can use an SDR USB stick to pick them up and process them.

Being that I don’t want yet another hub in the mix, and I feel like something which is meant only to send data doesn’t need a complicated mesh protocol like zwave, zigbee, or matter I thought I’d give it a try. This is my experience getting something like this working with an existing Home Assistant setup and a cheap RTL SDR USB stick.

Components

rtl_433

rtl_433 is a standalone project which decodes radio transmissions from devices on the 433.92 MHz, 868 MHz (SRD), 315 MHz, 345 MHz, and 915 MHz ISM bands. (and other frequencies) and forwards them to an MQTT server. I found it to be fairly mature and somewhat straight forward to setup, though I had some initial challenges. Some of those may have been self-inflicted but I’ll document what I found out. There exists a Home Assistant add-on which makes HA integration pretty simple. That being said, if you have a spare Linux machine (or other OS) that you can run the SDR on to do initial troubleshooting it could be helpful. I had a few SDRs and a HackRF One and a Portapack that I was able to use to ensure the device was transmitting before going too far down the rabbit hole.
The version I ended up using for Home Asssitant was rtl_433_next (which pulls from master branch of rtl_433. I did this as the released versions were showing errors for the Govee Sensors in my initial testing.

RTL SDR USB Stick

There are a ton of options out here, I think most of the DVB RTL SDR radios will work, I was able to get both a newer RTL-SDR Blog stick as well as a really old RTL SDR stick working. My HackRF One was more trouble to get running so I opted out of that but it was a supported option.

An MQTT Server

A working MQTT server configured with Home Assistant. As I was using the rtl_433_next add-on with Home Assistant and built-in Mosquitto option, setup was super simple.

Water Sensors

I picked up these Govee Water Leak Detectors, but anything that would talk on 433.92 MHz, 868 MHz (SRD), 315 MHz, 345 MHz, and 915 MHz ISM bands. bands could be potentially supported as long as it talks on one of the supported protocols on the projects page.

Putting it all together

First things first, I wanted to make sure these leak detectors were transmitting where I thought they were, and that I could at least reliably identify them in the RF spectrum. When you first activate the battery, it sends an initial transmission identifying itself and reporting it’s battery state. You’ll only get the battery state message once in a blue moon, so it could be tricky creating a battery sensor in HA for it. These are apparently really efficient devices, I’m guessing the spartan check-in messages help with that. Luckily you can prompt a transmission by pressing the test button on the device, which will send a “Button Press” event. Using my HackRF One Portapack I tuned to 433 and pressed the button a few times to see that it was, in fact, transmitting every time I pressed the button. This isn’t entirely necessary but I like to know something is happening before I start trying troubleshoot.

RTL SDR stick

Just plug it in!

rtl_433_next

All I needed to do here was setup the rtl_433-hass-addons repo in Home Assistant, install the rtl_433_next Add-On and start it. No configuration is needed, but if you feel the need you can provide one. I may go in later and block some of the protocols showing up as I have a neighbor with a Simply Safe alarm system whose sensors I keep seeing.

MQTT

Once rtl_433_next is running, you can turn your attention to MQTT. I’ve found MQTT Explorer to be a good tool to troubleshoot and analyze MQTT connections. Create an MQTT User in your Mosquitto Configuration, if you’ve not already and setup a connection in MQTT Explorer to Mosquitto/Home Assistant. If all is well, you should notice an “rtl_433” branch:

From here we can expand and see what sensors have already been detected. If your Leak Detector is not yet powered on, you can remove the battery activation tab now and it should appear shortly. If it is on but not showing, pressing the button should generate an event and it should appear as a sensor in a second.

If you look at our MQTT topic path above for event, it expands to

rtl_433/9b13b3f4-rtl433-next/devices/Govee-Water/23927/event

When we construct our configuration below, we will replace whatever is in place of 9b13b3f4-rtl433-next in your environment with a +. That will change across different versions of the add-on as it’s randomly generated. You can, however, specify a static topic path in the rtl_433 configuration, but I feel like this is a more portable way to do it.

If you want to test the Leak Sensors themselves, you can bridge the contacts or place in water… Be warned, it is LOUD. If you’ve done that, you’ll notice that your event message has changed to “Water Leak”.

Home Assistant

Now we need to create the configuration for Home Assistant. While there is an MQTT Auto Discovery available, I opted to keep my configuration manual until I felt comfortable with it all. So this is how I did my configuration.

Each Leak Detector has three sensors you can configure:

The Leak Detection (binary)
The Battery (number)
The Button (binary)

I choose to create only two sensors for my installation (Leak Detection and Battery).

To discover the Battery values, you need a sensor which has not been powered on yet, or one that you’ve removed and replaced the battery from. That is because the periods between battery reporting are quite long, and a button press does not trigger this. The good news is, it’s pretty simple. Using MQTT Explorer you can discover the topics you need, but I’ve got mine below which could be a good start. Pay attention to unique_id and the state_topic of the sensors as they will change for each sensor you add, otherwise these should work as-is.

configuration.yaml
mqtt:
  binary_sensor:
    - name: "Leak - Kitchen Sink"
      state_topic: "rtl_433/+/devices/Govee-Water/23927/event"
      unique_id: 23927_Govee_H5054
      device_class: moisture
      payload_on: "Water Leak"
      payload_off: "Button Press"
  sensor:
    - name: "Battery - Leak - Kitchen Sink"
      state_topic: rtl_433/+/devices/Govee-Water/23927/battery_ok
      device_class: battery
      unique_id: 23927_Govee_H5054_battery
      value_template: "{{ (value_json | float * 100 ) | int }}"
      unit_of_measurement: "%"

Automation

Now that you have a shiny new sensor… Now what? I wanted to create a generic automation that would work for ANY leak sensor I add. I don’t want to have to think about adding the leak sensor to the automation if I can get away with it, I found this blueprint from this topic on the Forums. This has the benefit of working with ANY sensor in the “moisture” class.

That being said, I don’t know what will happen with a soil moisture meter, so… you know… be careful. :)

Conclusion

That’s all for now, I’ll work to update this post if I find any issues or make changes. One of the improvements I want is to have Alexa send an alert throughout the house and do it periodically until the alert is acknowledged at the device. This way it’ll hopefully get more attention than just a push notification to a phone. Feel free to comment questions, ideas, or whatever below.