Support for Govee RF water leak detectors

snicker commented 4 years ago

I recently came up on some RF water leak detection sensors and rtl433 does not seem to pick up on them. Govee Water Detectors

What is the simplest way to gather data from these devices? I feel like there might be a lot of other 433.92mhz noise and when I save to file, I get a lot of other data? I can't seem to isolate which signal comes from these devices.

merbanan commented 4 years ago

Remove the antenna of the rtl_sdr device then play with the -g level until you only pick up the signals from the sensor. Place it around 1m away and record signals with -S unknown.

mguinness commented 3 years ago

Recorded the captured signal in g001_433.92M_250k.zip from leak alarm.

Teardown images of device at Govee H5040 & H5054 show the innards.

Below is an excerpt from thread Govee WiFi Water Sensor on HA forum:

Just got my bridge and have started testing things out. Obviously get a hex code when the sensor sends a signal. Have found that the active sensors sends 20CCFB for an alarm and then if you push the button or remove/insert the battery I get 20CCFC. So I am guessing the 20CCF is the device and the ‘B’ or ‘C’ is what determines what the “message” is.

mguinness commented 3 years ago

After reading issue https://github.com/merbanan/rtl_433/issues/1406 I used rtl_433 -w g001_433.92M_250k.ook g001_433.92M_250k.cu8 to convert to OOK (g001_433.92M_250k.txt) and seeing some good pulses in https://triq.org/pdv/.

Also using rtl_433 -r g001_433.92M_250k.cu8 -X "n=WD51,m=OOK_PWM,s=440,l=940,g=900,r=9000,unique" I get the following output:

time      : @0.090488s
model     : WD51         count     : 25            num_rows  : 25
len       : 2            data      : 0
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : @1.670216s
model     : WD51         count     : 11            num_rows  : 11
len       : 27           data      : 8080e80

zuckschwerdt commented 3 years ago

The OOK looks really good and clean. But shouldn't it be -X "n=WD51,m=OOK_PWM,s=290,l=850,g=990,r=9000,unique (i.e. match s and l to the pdv guess). Maybe the slicer can stil pick it up anyway? The code from your OOK example would be something like 96e904040740 right? edit: btw, rtl_433 -A filename will suggest just this :)

zuckschwerdt commented 3 years ago

Great work documenting the insides. An ESP8266 with WIFI? Such overkill where an EV1521 OTP would have done :)

mguinness commented 3 years ago

btw, rtl_433 -A filename will suggest just this :)

That's assuming I know what I'm doing :) Thanks for that.

Great work documenting the insides.

I can't claim credit for the teardown, I found it online and thought it might be useful.

Below is a capture after inserting batteries. Are the last four digits (0e80) the device code and the first 3 the state? The Home Assistant thread previously mentioned has different codes, but the Sonoff RF bridge might be decoding differently.

time      : 2020-11-04 11:24:46
model     : WD51         count     : 25            num_rows  : 25
len       : 2            data      : 0
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2020-11-04 11:24:47
model     : WD51         count     : 1             num_rows  : 1
len       : 27           data      : a0a0e80

@snicker Were you able to capture anything from your leak detector?

snicker commented 3 years ago

will give this a shot this afternoon! Thanks for the assist @mguinness

mguinness commented 3 years ago

Just for completeness, pressing the button on the leak detector produces a shorter signal (g002_433.92M_250k.txt) which I think is used for pairing the device to the gateway, I'm assuming this signal provides the device code for registration into the gateway.

I'm hoping someone more knowledgeable can improve the decoding as data is showing as zero and also if snicker can provide another sample that might be useful to confirm it is indeed the device code that is being transmitted.

time      : 2020-11-09 10:35:42
model     : WD51         count     : 25            num_rows  : 25
len       : 2            data      : 0

mcsquared88 commented 3 years ago

Thanks to @mguinness for laying the groundwork. The folks over at the Home Assistant forums (https://community.home-assistant.io/t/govee-wifi-water-sensor/213277/67) seemed to have mostly figured out how to read these sensors using the Sonoff RF bridge, but I wanted to use rtl_433 and my RTL-SDR.

I've figured out how to reliably decode the signals being transmitted from my 3 Govee H5054 water leak sensors using rtl_433. I assumed that the communication between the sensors and the gateway is one way, and that the sensors only send 3 messages: button pressed, leak detected, and battery level. From the photos of the sensor circuit board, it seems the top and bottom contacts are wired to the circuit board in different spots, so I originally thought the top and bottom contacts may send separate signals. But from my testing, that doesn't seem to be the case. I also learned from my testing that the signal sent when batteries are inserted is the same signal sent when the button is pressed.

I used rtl_433 build 2.11, using the official Windows binary available at https://bintray.com/chzu/dist/rtl_433/20.11#files and the following flex decoder spec: -X "n=Govee_H5054,m=OOK_PWM,s=440,l=940,g=900,r=9000,bits=48,unique". This is the same basic spec used by @mguinness, but I changed the name and added bits=48 to eliminate some invalid data. Like a lot of similar devices, when an event is triggered, these sensors repeatedly send the same signal dozens of times to ensure that the receiver receives the signal correctly. So eliminating the few garbled transmissions is fine.

The data values I get from this flex decoder spec follow one of the following patterns: ####04040??? when a leak is detected, ####05050??? when the button is pressed or batteries are inserted, or ####03BB0 to report battery level, where #### is a unique ID for each sensor and BB is a code indicating the battery level (details below). I'm assuming the last 3 characters (???) is a CRC for the rest of the message, but I never bothered attempting to figure out how it's calculated. You can manually determine the ID for each of your sensors by pressing the button on a sensor (or installing the batteries) and making note of the data value displayed by rtl_433.

The Govee app shows the battery level as being from 1 to 5 bars. Using different batteries at different levels of charge, I was able to determine the signals sent for most battery levels: 5 bars - 039b0 4 bars - 03bc0, 03c40 or 03b60 3 bars - 03e50 2 bars - 03e70 1 bar - Unknown at this time

I tried some almost-dead batteries, and when I inserted them, the speaker made a clicking sound for a few seconds. But rtl_433 never captured any transmissions. Someone reported in the Home Assistant forum that the sensors send a low battery signal when the voltage level dropped below 1.8 volts for more than 5 seconds. I don't have a voltage regulator to test that myself, so there may be one or two other messages that I haven't seen and haven't documented here. I'm also not sure if the multiple signals I saw for the 4-bar battery level are garbled transmissions or something else. If someone has some of these sensors and a voltage regulator, it would be great to try to figure out the signal sent when the battery level gets too low.

I don't know how perfectly we have to decode a device's transmissions before it can be officially added to the rtl_433 source code, but this information was enough for me to eliminate the Govee Wi-Fi gateway and app and integrate my sensors directly into Home Assistant (using a RTL-SDR and rtl_433 to receive the signals and transmit them as MQTT messages).

I have captures of the signals transmitted from 3 different sensors when the button is pressed and when a leak is detected that I can share if helpful.

At a cost of $8-$11 per sensor (depending on quantity purchased) and about $20 for a RTL-SDR dongle, this is a fantastic and fantastically cheap solution. A bundle consisting of the Govee Wi-Fi gateway (H5050) and 3 sensors sells for $50 on Amazon. But for $4 more, you can buy 3 sensors and a RTL-SDR dongle, which is incredibly more capable (assuming you have an always-on device you can connect it to). And the battery life on these sensors is incredible. I've had mine for over a year and the included no-name batteries are still all at 4 bars (and that's after all the testing I did to reverse-engineer the protocol).

If this was added as a supported device protocol in rtl_433 itself, I'd suggest only reporting signals that have a length of exactly 48 bits and that have one of the listed values in the 5th thru 9th characters. It would also be great if rtl_433 could separate the ID (the first 4 characters) from the event value (the 5th thru 9th characters) in the MQTT output.

zuckschwerdt commented 3 years ago

If this just three fixed messages (with variation for the battery level) then this can be quickly written as a flex decoder conf file. Look through https://github.com/merbanan/rtl_433/tree/master/conf for examples with a get= option. E.g. get=@0:{16}:id, is start at bit 0, get 16 bits, output as id And get = @16:{4}:state:[15:OFF 0:ON], is start at bit 16, get 4 bits, output as state where value 15 is shown as OFF, value 0 as ON (each character in the hex codes you explained is 4 bit, starting at 0)

mcsquared88 commented 3 years ago

Thanks @zuckschwerdt. The .conf file format looks easy enough, and I think I can figure out the get option to extract the device IDs, events, and battery levels. One question: Can I use a .conf file with the -c option, or must I recompile rtl_433 to use them?

I've also just bought some more sensors so I can confirm that what I've observed with my sensors (which I had previously "paired" to the Govee Wi-Fi gateway) will also work with fresh-out-of-the-box sensors.

zuckschwerdt commented 3 years ago

Yes, the -c option is to read the conf files, multiple stacked ones if needed, e.g. a base conf file with options like frequency and then files for each decoder.

zuckschwerdt commented 3 years ago

To the checksum idea: the codes are reported as 27 bits, but the last 3 bit (the last hex char) seems always 0? I would guess it's just a round number of 24 bits then (6 chars), the rest is an artifact of the transmission or the demodulation. The last byte is then usually a checksum. The first byte would usually be the ID and the middle byte looks like the state. This does not seem to fit the battery level readings though. Can you paste full codes for the various states and levels? edit: I looked at the wrong codes here, they are longer, still a round number of bits is expected and checksum should be the last byte.

zuckschwerdt commented 3 years ago

Since there are serial numbers in the codes, best to send me a mail if you like.

mcsquared88 commented 3 years ago

Since there are serial numbers in the codes, best to send me a mail if you like.

Thanks for the offer, @zuckschwerdt. I just sent you an email.

skilau commented 3 years ago

I've also just bought some more sensors so I can confirm that what I've observed with my sensors (which I had previously "paired" to the Govee Wi-Fi gateway) will also work with fresh-out-of-the-box sensors.

Hey, based on your thread out on the HA forum about this, I picked up one of the 5 packs of sensors WITHOUT the Gateway, along with the RTL-SDR USB dongle. Since these are virgin, never seen a Gateway, I can confirm that your findings are valid on these as well.

It makes sense how they "pair" with the Gateway, they just watch for the button press, and then grab the ID that comes in with it.

skilau commented 3 years ago

Hi! I have created a driver for this leak detector based on this thread, (and my experiments with my 5 of these sensors). I have submitted a pull request for it here: https://github.com/merbanan/rtl_433/pull/1653

I know it is a very basic driver, but then again, it is a very basic sensor.

mcsquared88 commented 3 years ago

Fantastic! I think the unknown 0x202 event is actually a heartbeat signal, but I haven't had enough time to confirm and figure out how often it's sent. I will post an update when I get more data. But in the meantime, it might be worth adding that to the driver.

--Adam

On Wed, Feb 17, 2021 at 12:24 PM skilau notifications@github.com wrote:

Hi! I have created a driver for this leak detector based on this thread, (and my experiments with my 5 of these sensors). I have submitted a pull request for it here:

1653 https://github.com/merbanan/rtl_433/pull/1653

I know it is a very basic driver, but then again, it is a very basic sensor.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/merbanan/rtl_433/issues/1518#issuecomment-780793529, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB66ZZCSWPNDBJNIONVI3H3S7QJXLANCNFSM4SPY373A .

skilau commented 3 years ago

@mcsquared88 : Added the Heartbeat check. (I haven't had mine running long enough to see it yet!). A big thanks to you on all the investigation and work you did above!

sweichbr commented 3 years ago

Hi - bit of a newbie - how can I add this driver to my rtl_433 installation. I have a bunch of these sensors, and have been using the RF bridge, but its been a bit of hit and miss, so I want to move it an existing rtl_433 setup that I am already using with HA.

mguinness commented 3 years ago

You'll have to watch issue https://github.com/merbanan/rtl_433/pull/1653 and wait for it to be merged into the main branch, or alternatively build from the skilau branch.

mcsquared88 commented 3 years ago

Apologies if this isn't the place for this. I logged all signals received from my Govee sensors for the past 2 days, and it seems my original 3 sensors I bought over a year ago are sending the heartbeat signal every 6 to 6.5 hours. But the additional 5 sensors I bought a few weeks ago don't seem to be sending any heartbeat signal. I've thought of various possible reasons for this: The newer sensors have newer firmware that just doesn't send the heartbeat signals at all. The newer sensors have newer firmware that only sends the heartbeat signals every few days and I just haven't been listening for long enough. The heartbeat signals are only sent when the battery level goes below some set level. Communication between the sensors and the WiFi bridge is actually two-way, and the sensors needs to be paired with the bridge before they send the heartbeat signals. If others can see if their sensors are sending heartbeat signals, that would be helpful.

skilau commented 3 years ago

If others can see if their sensors are sending heartbeat signals, that would be helpful.

I have yet to see a Heartbeat signal from one of these sensors, and have watched them for about 4-5 days now. My 2 sets of 5 were purchased within the past couple of weeks, so they are quite new, with fresh batteries in them.

Wonder if Govee decided to get rid of it in newer firmware, perhaps they thought it ate the batteries too much?

I was actually kind of hoping to see the heartbeats, as that would be a feature I would totally use, to have Home Assistant send me an alert if it didn't hear from one of them within say 24 hours, so I know something is wrong with it. (ie, batteries died, unit died, cat killed it somehow, etc, etc)

I don't have one of their bridges, so I can't test to see if these guys are really bi-directional or not.

I don't know if you still have your old bridge, so you could try pairing one of your new 5 into it, and see if changes functionality or not.

mcsquared88 commented 3 years ago

I don't know if you still have your old bridge, so you could try pairing one of your new 5 into it, and see if changes functionality or not.

I do still have the bridge and that's my plan, but I may not have time until the weekend. I also want to try swapping batteries between a newer and older unit to see if the battery level has anything to do w/ if/when it sends the heartbeat signal.

At least for the older units, the fact that I saw the 0x202 signal sent every 6 to 6.5 hours on 3 units does confirm it's a heartbeat signal, which is definitely a feature you want in devices like these that (ideally) will never actually trigger an alarm. I'd gladly give up some battery life to have the heartbeat signal.

mguinness commented 3 years ago

Based on the teardown photo, I only see a single antenna. Also it does show a board date and revision which could be useful.

teardown

zuckschwerdt commented 3 years ago

Can you read info off the 6-pin chip?

mcsquared88 commented 3 years ago

I've done some testing in an attempt to figure out why the three H5054 sensors I bought over a year ago (as part of a package with the H5040 WiFi gateway) are sending a heartbeat signal every 6 to 6.5 hours, but the 5 additional H5054 sensors I bought a month ago are not.

I've setup the gateway again and synced one of the new sensors to the gateway. I've removed and re-inserted the batteries. And I've even opened up the cases for one of the new and one of the old sensors. The info printed on the circuit board of both exactly matches the photo above. And I've been logging all signals received for a few days. But I still haven't seen the new sensors send a heartbeat signal.

Here's my cynical idea of why Govee would remove such a useful feature: Govee either never implemented the heartbeat signal in the app, or they previously implemented it but then removed it. I have never seen any mention or evidence of a heartbeat signal in the advertising, the documentation, or the Govee app. When I re-installed the app on my phone and logged into my Govee account, at least a month after uninstalling the app and unplugging the gateway, the app showed my sensors and their battery levels even before it had connected to the gateway. If the system monitored the heartbeat signals, it should have warned me that my sensors and/or gateway appeared offline. I only figured out the heartbeat singals exist by monitoring the sensors with rtl_433.

I suspect Govee updated the firmware used in later sensors to not even send the heartbeat signals, which increases the battery life. Increased battery life is something Govee can advertise and that everyone can understand. It's a lot harder to explain why a sensor may occasionally show as offline and to convince people that that's OK. So rather than deal with users reporting problems and/or complaining in product reviews that the sensors go offline, the official Govee app just blindly reports the last status received, even if it was weeks ago.

Regardless of the reason, I doubt it's possible to reflash the firmware on the sensors to get them to send the heartbeat signals. And it doesn't even seem possible to determine visually whether a sensor will or won't send the heartbeat signals (so you could choose to buy the sensors that do send the heartbeat signals).

If you have at least one sensor that send the heartbeat signal, it makes it really easy to verify that the rtl_433 is receiving signals and forwarding them to your home automation system. If you don't have any sensors that send the heartbeat signal, you should probably press the button on at least one of your sensors every few weeks or months to check that everything is still working, rather than wait months and months (and months) for a sensor to send a battery level signal.

skilau commented 3 years ago

Thanks @mcsquared88 for doing this investigation on the Heartbeat! Yeah, I suspect you are right, that they removed the heartbeat probably to save battery life... Too bad that they didn't just bump it up from 6 hours to 24 hours... A once a day check in would have been adequate.

On the positive side for me, is that I have a Lacrosse Temp sensor outside that happens to send its data in about once every couple minutes, so I can create a health check for the RTL-SDR dongle (and rtl_433) on continually getting those messages from it.

Of course, this doesn't check the health of each of those water leak sensors, so checking them with a button press every couple weeks is probably a good idea.

For 8 bucks each, these sensors are really still a great deal, in fact, I am tempted to try out their Contact Sensor and Motion Sensor, which appear to send over 433 as well.

skilau commented 3 years ago

Hi all, (that are still following this thread).

I picked up a couple of the Govee Door Chime Sensors, because I was hoping I could possibly replace my Wyze (v1) Contact sensors with them. (The Wyze v1 contact sensors have a fatal hardware flaw that cause themselves to brick when the battery dies, so I am on borrowed time with them)

https://www.amazon.com/Govee-Wireless-Magnetic-Security-Indicators/dp/B07RWTZNKW/ (They were on sale for about 20 bucks for 2, after a 20% coupon)

The Govee Chime Sensors also send over 433, which is another reason I figured I would try them.

I received them today, and have tested them... They are OK, but unfortunately, they only send a message when they are triggered OPEN. They do not send another message when they are closed/the magnets come back together.

Thus, they aren't particularly useful for places you need to watch open and close status. (And thus, not a replacement for my Wyze contact sensors)

But, if you need to watch something that should never open, and if they do, you know something is wrong, then these might be a good product. (For example, I have a couple basement windows that literally should never be opened. If they are, I know someone is breaking in, or the window was broken somehow. So I will be using these there for now)

Anyway, they use the same exact frequencies and protocol as the Water Leak sensors, just a different Event value to mark the "Open" status, so I will be changing my rtl_433 driver/pull request to make my driver a more generic "govee" driver, and will include support for both devices.

Just figured I would let you guys know, in case anyone is still watching my fork/pull request.

skilau commented 3 years ago

OK, the updated patch was posted, to be a more generic Govee driver, with support for the Leak sensor and now the Contact sensor. In case anyone is curious, here is a picture of the guts of the Contact sensor. As you might imagine, you just got a Reed switch in there driving it.

Probably the most interesting thing is the 2 A23 batteries. The Wyze sensors used a much smaller battery, and still is able to get a year or so out of them. I wonder how long these batteries will last?

I am just sad they don't send an Closed event. Without that, it really doesn't solve what I am looking for.

PXL_20210328_210500393

billgrundmann commented 3 years ago

I figured out the Govee water sensor decoding last year. Most of the packets are repeated multiple times to insure or increase a successful delivery. It is important to validate the parity of the packet. Voltage seems to only be transmitted on registration and when the voltage significantly changes.

6 bytes of 48 bits per data packet
{byte1, byte2} = unit number of the sensor; unit = (byte1 << 8) + byte2;
byte3 = type of message or packet 0xfa - registration request (aka the button was pushed) 0xfb - water leak alarm 0xfc - voltage in {byte4} as follows 0xfd - heartbeat, or still alive and reporting in; this seems to happen on a regular basis during the day a timeout for a unit's heartbeat would indicate something wrong on the sensor
byte4 = if (byte == 0xfc), then voltage of battery, otherwise ignored fit value from 8 different sensor units: voltage = 1.7944 + 0.0121 * {byte4} range = observed 2 to 3.1 volts
byte5 - ignored

byte6 - check byte This took the most time to figure out: {101pppp1} - where 'pppp' is nibble parity of bytes 1 through 5 determined as follows:

  // return 1 if the check-byte has the correct value
  inline uint8_t Check() {
    // check nibble-parity of all previous bytes
    uint8_t parity = 0;
    for (uint8_t i = 1; i < 6; i++) {
      uint8_t data = bytes[i];
      parity ^= (data >> 4);  // high nibble
      parity ^= (data & 0xf); // low nibble
    }
    // add in the magic constant bits
    if (bytes[5] & 1)
      parity = (parity << 1) | 0xA1;  // shift parity to correct field
    else
      parity = (parity << 2) | 0x42;  // shift parity to correct field
    // return if check byte matches
    return parity == bytes[6];  
  }

Bit timing seems to have some variance between units. My first set of 6 sensors all had the same bit timing. A later set of 2 had a slightly different bit timings. I believe the start-bit interval is key to determine which variant is transmitting and using start-bit width to select a table of timings for the packet.

I have yet to wrap this as an esphome sensor. Any help would be appreciated.

billgrundmann commented 3 years ago

The code posted for the parity check has an error in translation. if (bytes[5] & 1) --> if (bytes[6] & 1)

My original code has bytes declared as array [0:5].

mckellip commented 3 years ago

You are all awesome for doing all the legwork on this I cannot thank you all enough. Rtl stuff is all new to me and reading this ticket, @skilau's pull request 1653 and another article (mentioned below) got me through it.

Sadly @skilau's pull request is still waiting on final testing and I didn't want to wait anymore. Plus, I am using Unraid with docker so not sure when that would get updated. I also have no idea how to change branches on a docker or if even possible without making a new docker. I thought that would take too many hours figuring out, so I went with my other option.

I decided to try @zuckschwerdt's idea of doing a flex decoder file. Though, I don't think I saved time trying to figure this out because it has been a long time since I have dealt with Hexadecimal. Plus, I could not find any help on how to use get= option except reading @zuckschwerdt's comment (a lot), looking at other config files and digging through @skilau's code. I kept pushing the test button and using water and kept looking at the output (Wife was not happy).

I was using this command that @mcsquared88 put in his comment and trying to add different get= options to it. rtl_433 -r filename.cu8 -X "n=Govee_H5054,m=OOK_PWM,s=440,l=940,g=900,r=9000,bits=48,unique"

I wasn't sure what the output was support to be, finally reading through @skilau's code about 20ish times it clicked that I needed to look it up in decimal format. So I used a hexadecimal to decimal converter to take all the outputs @skilau and @mcsquared88 figured out and converted them to the decimal output so the actually matched what the get= option returned.

Instead of making a full decoder config file I just put it in the bottom of my main config. So far it seems to be working with my two H5054 detectors (I have brand new ones.... I have not seen a heartbeat either). Here is the code I put at the bottom of my rtl_433.conf file (I am getting results in my MQTT with MQTT Explorer). decoder n=Govee_H5054,m=OOK_PWM,s=440,l=940,g=900,r=9000,bits=48,get=id:@0:{16},get=event:@16:{16}:[1285:test 1028:leak_detected 1022:battery_empty 999:battery_25_percent 997:battery_50_percent 950:battery_75_percent 956:battery_75_percent 964:battery_75_percent 923:battery_full 514:heartbeat],unique

I thought about opening a pull request with a new config file but didn't want to step on @skilau feet because his driver files where a huge help and without them I would not have been able to get this working.

This article helped me figured out how to setup my docker, put the decoder direct in my config file, see it in MQTT Explorer and pull the messages into Home Assistant (I have not done the Home Assistant part yet but that seems like the easy part I will update if I have issues)

*Updated a typo

cheechm13 commented 3 years ago

Instead of making a full decoder config file I just put it in the bottom of my main config. So far it seems to be working with my two H5054 detectors (I have brand new ones.... I have not seen a heartbeat either). Here is the code I put at the bottom of my rtl_433.conf file (I am getting results in my MQTT with MQTT Explorer). decoder n=Govee_H5054,m=OOK_PWM,s=440,l=940,g=900,r=9000,bits=48,get=id:@0:{16},get=event:@16:{16}:[1285:test 1028:leak_detected 1022:battery_empty 999:battery_25_percent 997:battery_50_percent 950:battery_75_percent 956:battery_75_percent 964:battery_75_percent 923:battery_full 514:heartbeat],unique

I have duplicated this in my conf file and it is showing up in my MQTT explorer as distinct Govee H5054 devices when pressing the test button or activating the sensor via the contacts.

Is there a way to add this as a device class to be picked up by the Add-on called rtl_433 MQTT Auto Discovery?

Or are you adding each Govee as a separate binary sensor with attributes in your config.yaml file?

Curious how you eventually added them to HA. Thanks in advance and great work by all!

mckellip commented 3 years ago

@cheechm13 this is the first 433 sensors I have added to my system so I am pretty new to it. I didn't even know rtl_433 mqtt auto discovery existed, but now you gave me something else to play with.

I did get these added successfully to my config.yaml file as binary sensors, actually just this weekend. Here is the details I added and then I built alerts off these.

binary_sensor:
- platform: mqtt
  state_topic: "rtl_433/+/devices/Govee_H5054/12851/event"
  device_class: moisture
  unique_id: 12851_govee_water
  name: kitchen_main_sink_water_leak
  payload_on: leak_detected
  payload_off: test
- platform: mqtt
  state_topic: "rtl_433/+/devices/Govee_H5054/13251/event"
  device_class: moisture
  unique_id: 13251_govee_water
  name: kitchen_island_sink_water_leak
  payload_on: leak_detected
  payload_off: test

Sadly, health checks have never fired for my Govee devices so guessing that feature is gone. Also, I have not figured out how to get battery data, it seems to just be getting overwritten. I tried creating different get sections in my rtl_433 decoder (shown below), but those get overwritten as well by the numbers. Not sure if there is a way to ignore them if not one of the options in that get section. I sorta gave up for now and was hoping that maybe the code @skilau added will account for this. For now with my fresh batteries everything is working great, but I just need to remember to set reminders for like weekly checks.

Here is the changes to the decoder I tried to make to get battery info but keeps getting over written with numbers when I hit the test button. decoder n=Govee_H5054,m=OOK_PWM,s=440,l=940,g=900,r=9000,bits=48,get=id:@0:{16},get=event:@16:{16}:[1285:test 1028:leak_detected],get=battery:@16:{16}:[battery_empty 999:battery_25_percent 997:battery_50_percent 950:battery_75_percent 956:battery_75_percent 964:battery_75_percent 923:battery_full],get=heartbeat:@16:{16}:[514:heartbeat],unique

skilau commented 3 years ago

Hi all! Yup, as most have seen, Govee removed the heartbeat for some reason, which is too bad. That would have allowed us to trigger a warning if we don't hear from the sensor once a day/couple days, etc.

On the positive side, I have been running these for 6+ months now, and they do send a message each time they move down a notch in battery life.

I deployed these all about the same time and I have gotten a message from each of them over the past 2-3 weeks that they are now down to 4 bars from 5 bars.

So far, I am still impressed with these things. They have worked against 1 minor leak, and a couple false alarms where my kid got water on them.

I still hope that my pull request here: https://github.com/merbanan/rtl_433/pull/1653 gets merged at some point, as it definitely is a hassle to maintain/build my own RTL-433 package for Home Assistant.

(I use the rtl_433 binary to watch these water sensors, and to watch a number of temperature sensors in Home Assistant, and send alerts/warnings to me whenever something interesting happens)

mckellip commented 3 years ago

@skilau sounds like I still have about 5 months before my batteries go down.... How are you watching the battery info in home assistant? Do you have a sensor for battery and a binary sensor for leak event?

zuckschwerdt commented 3 years ago

This is now merged, we still need to work @billgrundmann thorough protocol decoding in.

zuckschwerdt commented 3 years ago

Checksum is now also merged with added Battery level and Battery voltage output. Closing, but feel free to report problems here.

skilau commented 3 years ago

@zuckschwerdt Thanks you so much! I really appreciate it!

zuckschwerdt commented 3 years ago

:) Glad to help. Note that output keys and ID changed. It looks like inverting all bits is likely the true protocol. The event codes looked better not-inverted (1,2,3,4,5) but inverted the battery level is now a direct 0-100 value. https://github.com/merbanan/rtl_433/blob/master/src/devices/govee.c#L137-L144

sergesyrota commented 2 months ago

A bit of an old thread, but I thought I’d try my luck… I have both older versions with heartbeat, and newer versions without heartbeat. Anyone thought about dumping firmware from the older sensor and re-programming newer one? I’m assuming this is the chip, but there are no markings on it in any of the sensors I disassembled. Let me know if you have any pointers, as I can’t figure out from poking around.

I was able to figure out some pins, though: 1 - 3.3V (boost converter) 4 - Button (w/ pullup; clicking brings this pin to GND) 6 - ADC? (Battery voltage input) 9 - Digital out: LED 10 - Probe in (3.1V when OK, 1.2V when probes contact water) 16 - GND

zuckschwerdt commented 2 months ago

The position of Gnd/Vcc can be a hint. Maybe you get lucky probing the unused pins for a debug UART (needs a restart for each pin).

merbanan / rtl_433

Support for Govee RF water leak detectors #1518

1653 https://github.com/merbanan/rtl_433/pull/1653