rtl_433
rtl_433 copied to clipboard
merbanan
Unable to read Govee Leak Detector Sensors
I purchased two packs of the Govee H5054 leak detector sensors, one 3-pack with the Wifi gateway included, and one "expansion pack" with just five of the bare sensors.
I already have a working instance of rtl_433 connected to Home Assistant for pulling data from some Acurite sensors, and was able to easily add the three detectors that came with the gateway, but have not been able to read anything from the five that came in the expansion pack. All five seemingly function perfectly, and I was even able to add them to the gateway, but no luck with RTL_433.
Opening them up, both versions have a date code of 2021-08-10, and board revision V5.2, so unless Govee changed the firmware I'm at a loss. I'm happy to provide any additional info or logs that might help.
HI, did you read the issue in #2189 ? There was a broken unit, did you test only one or all.?
Br .Frank
I've been fighting this as well. I just received a 5 pack and none of these decode. I have another set purchased last year works perfectly so I suspect there's some manufacturing flaw or protocol difference between the two lots. I'm pretty green with rtl_433, but I'm also willing to take steps to troubleshoot/diagnose if someone is willing to offer some guidance.
HI, did you read the issue in #2189 ? There was a broken unit, did you test only one or all.?
Br .Frank
I did read that issue. I tested all five, and none are being correctly picked up by RTL_433. That fact that all five function as expected with the Govee gateway, and none work with RTL_433 leads me to suspect a protocol change vs defective unit(s), but I'm willing to run some diagnostics as long as someone can provide some guidance on how to do so.
The three that came with the gateway function as expected with both the Govee gateway and RTL_433, but the other five only work with the Govee gateway.
2022-12-5_FCC-2AQA6-H5054_unknown.zip
I believe g004 should represent a button press, and g008 an alarm event.
2022-12-5_FCC-2AQA6-H5054_known.zip
Versus the g011 for button press and g012 for alarm event on a module that is showing up correctly.
That is very strange, parity check is failing and if you disable the parity check, the event codes that are send from the device is different from the working example.
Raw code for g004 is Raw Code : de0dcfab22c3 Raw code for g008 is Raw Code : de0dcdfe4ef1
So the ID field (first 2 bytes) seems to be OK, but the rest is different from the "working" sensor. See the bitbench Not sure what is happening
One thing to note: You are exactly hitting DC (433.920M) and that will cause trouble. There is a demo for a newer PDV with much improved zoom here: https://triq.org/spectrogram-next/ Zoom in (mouse scroll) and look at the waveform :)
Perhaps try -f 433.89M
Hi @zuckschwerdt , not sure but you mean to use -f 433.89M during recording?
Hi @Ninja1283 and @bombledmonk, did you test the Sensors with the option -f 433.89M like Christian was suggesting?
I did. Signal was a bit cleaner, but still not registering correctly. 433_89MHz.zip
Oddly enough, during some of my testing, two of the five sensors did somewhat correctly register:
Detected OOK package 2022-12-05 22:41:31
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time : 2022-12-05 22:41:31
model : Govee-Water id : 8690
event : Unknown Raw Code : de0dcdf93e16 Integrity : PARITY
Analyzing pulses...
Total count: 1200, width: 1506.96 ms (376740 S)
Pulse width distribution:
[ 0] count: 6, width: 1512 us [1388;1656] ( 378 S)
[ 1] count: 465, width: 860 us [704;1088] ( 215 S)
[ 2] count: 640, width: 296 us [276;356] ( 74 S)
[ 3] count: 1, width: 3112 us [3112;3112] ( 778 S)
[ 4] count: 28, width: 224 us [224;232] ( 56 S)
[ 5] count: 45, width: 428 us [388;540] ( 107 S)
[ 6] count: 12, width: 616 us [552;696] ( 154 S)
[ 7] count: 2, width: 1124 us [1108;1140] ( 281 S)
[ 8] count: 1, width: 2324 us [2324;2324] ( 581 S)
Gap width distribution:
[ 0] count: 606, width: 824 us [796;852] ( 206 S)
[ 1] count: 1, width: 2860 us [2860;2860] ( 715 S)
[ 2] count: 22, width: 8588 us [7144;8672] (2147 S)
[ 3] count: 430, width: 264 us [212;320] ( 66 S)
[ 4] count: 22, width: 1392 us [1296;1412] ( 348 S)
[ 5] count: 7, width: 76 us [64;80] ( 19 S)
[ 6] count: 50, width: 188 us [148;204] ( 47 S)
[ 7] count: 37, width: 380 us [336;388] ( 95 S)
[ 8] count: 13, width: 120 us [104;140] ( 30 S)
[ 9] count: 8, width: 560 us [508;592] ( 140 S)
[10] count: 2, width: 52 us [52;56] ( 13 S)
[11] count: 1, width: 96 us [96;96] ( 24 S)
Pulse period distribution:
[ 0] count: 27, width: 2220 us [1932;2448] ( 555 S)
[ 1] count: 2, width: 3436 us [3192;3684] ( 859 S)
[ 2] count: 22, width: 8884 us [7432;8972] (2221 S)
[ 3] count: 1056, width: 1120 us [924;1308] ( 280 S)
[ 4] count: 78, width: 612 us [496;760] ( 153 S)
[ 5] count: 5, width: 408 us [352;464] ( 102 S)
[ 6] count: 6, width: 848 us [784;896] ( 212 S)
[ 7] count: 1, width: 300 us [300;300] ( 75 S)
[ 8] count: 2, width: 1516 us [1512;1524] ( 379 S)
Pulse timing distribution:
[ 0] count: 28, width: 1416 us [1296;1656] ( 354 S)
[ 1] count: 1072, width: 840 us [704;1088] ( 210 S)
[ 2] count: 1065, width: 284 us [236;364] ( 71 S)
[ 3] count: 2, width: 2984 us [2860;3112] ( 746 S)
[ 4] count: 78, width: 208 us [180;232] ( 52 S)
[ 5] count: 80, width: 408 us [368;540] ( 102 S)
[ 6] count: 19, width: 600 us [516;696] ( 150 S)
[ 7] count: 2, width: 1124 us [1108;1140] ( 281 S)
[ 8] count: 1, width: 2324 us [2324;2324] ( 581 S)
[ 9] count: 22, width: 8588 us [7144;8672] (2147 S)
[10] count: 7, width: 76 us [64;80] ( 19 S)
[11] count: 17, width: 144 us [116;172] ( 36 S)
[12] count: 2, width: 52 us [52;56] ( 13 S)
[13] count: 5, width: 104 us [96;112] ( 26 S)
Level estimates [high, low]: 15925, 65
RSSI: -0.1 dB SNR: 23.9 dB Noise: -24.0 dB
Frequency offsets [F1, F2]: 16808, 0 (+64.1 kHz, +0.0 kHz)
Guessing modulation: No clue...
Detected OOK package 2022-12-05 22:41:33
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time : 2022-12-05 22:41:33
model : Govee-Water id : 8690
event : Unknown Raw Code : de0dcdf93e16 Integrity : PARITY
Analyzing pulses...
Total count: 321, width: 413.24 ms (103309 S)
Pulse width distribution:
[ 0] count: 190, width: 296 us [276;332] ( 74 S)
[ 1] count: 131, width: 856 us [832;884] ( 214 S)
Gap width distribution:
[ 0] count: 184, width: 820 us [800;852] ( 205 S)
[ 1] count: 124, width: 264 us [248;296] ( 66 S)
[ 2] count: 6, width: 1396 us [1384;1412] ( 349 S)
[ 3] count: 6, width: 8660 us [8648;8672] (2165 S)
Pulse period distribution:
[ 0] count: 308, width: 1120 us [1096;1148] ( 280 S)
[ 1] count: 6, width: 2252 us [2248;2256] ( 563 S)
[ 2] count: 6, width: 8956 us [8936;8976] (2239 S)
Pulse timing distribution:
[ 0] count: 314, width: 284 us [248;332] ( 71 S)
[ 1] count: 315, width: 836 us [800;884] ( 209 S)
[ 2] count: 6, width: 1396 us [1384;1412] ( 349 S)
[ 3] count: 7, width: 8852 us [8648;10004] (2213 S)
Level estimates [high, low]: 15933, 65
RSSI: -0.1 dB SNR: 23.9 dB Noise: -24.0 dB
Frequency offsets [F1, F2]: 19162, 0 (+73.1 kHz, +0.0 kHz)
Guessing modulation: Pulse Width Modulation with multiple packets
view at https://triq.org/pdv/#AAB0260401011C0344057422948190818181818181909081909081818181819090909081908181928355+AAB03B0405011C0344057422948181908181818190909090908181908181819090818190818181818181909081909081818181819090909081908181928355+AAB03A0401011C03440574229481819081818181909090909081819081818190908181908181818181819090819090818181818190909090819081819355
Attempting demodulation... short_width: 296, long_width: 856, reset_limit: 8676, sync_width: 0
Use a flex decoder with -X 'n=name,m=OOK_PWM,s=296,l=856,r=8676,g=856,t=224,y=0'
pulse_slicer_pwm(): Analyzer Device
bitbuffer:: Number of rows: 13
[00] {27} bf 27 c2 c0 : 10111111 00100111 11000010 110
[01] { 1} 80 : 1
[02] {48} de 0d cd f9 3e 16 : 11011110 00001101 11001101 11111001 00111110 00010110
[03] { 1} 80 : 1
[04] {48} de 0d cd f9 3e 16 : 11011110 00001101 11001101 11111001 00111110 00010110
[05] { 1} 80 : 1
[06] {48} de 0d cd f9 3e 16 : 11011110 00001101 11001101 11111001 00111110 00010110
[07] { 1} 80 : 1
[08] {48} de 0d cd f9 3e 16 : 11011110 00001101 11001101 11111001 00111110 00010110
[09] { 1} 80 : 1
[10] {48} de 0d cd f9 3e 16 : 11011110 00001101 11001101 11111001 00111110 00010110
[11] { 1} 80 : 1
[12] {48} de 0d cd f9 3e 16 : 11011110 00001101 11001101 11111001 00111110 00010110
It only happened once for each sensor though:
time : 2022-12-05 22:43:36
model : Govee-Water id : 8690
event : Unknown Raw Code : de0dcdf82e37 Integrity : PARITY
time : 2022-12-05 22:47:01
model : Govee-Water id : 7945
event : Unknown Raw Code : e0f6cdf1220e Integrity : PARITY
(FYI, one was during a run @ 433.89MHz, and one was during a run @ 433.92MHz. Both returned an "Unknown" event, instead of the correct "Button Press".)
Hmm, very strange. The parity is still not working and the codes seems to be different. See bitbench
For those devices the codes seems to be: (event == 0x054) { event_str = "Button Press"; else if (event == 0x201) { event_str = "Water Leak";
A very dirty hack would be: govee.zip Where the parity stop is disable and the two new codes are in. So it should work with both versions of your devices.
@zuckschwerdt regarding parity, I am absolutely no expert in parity checking(completely unknown for me), maybe you can give us a hint?
@franki29 See this BitBench
Whole message should be inverted (Button "Invert") the format string should be ID:8h8h ?4h EVENT:4h EVENTDATA:8h ?8h CHK:3b 4h 1b
The checksum is 4-bit parity (i.e. nibble-wide add without carry) and shown in the BitBench now.
To me none of the broken codes look plausible. The last bytes needs to be 101 PPPP 1.
Could this be bad reception?
@zuckschwerdt Hmm, I saw a thread in homeassistant where a user is also claiming that some sensors does not work. So maybe they really change the protocol. I also pick up some data from a older thread that is working with current implementation and we have some differences. Looking at the latest Bitbench data from you: In the older version the ?4h EVENT:4h seems to be equal to the event data EVENTDATA:8h ?f EVENT:a EVENTDATA:fa ?f EVENT:b EVENTDATA:fb ?f EVENT:b EVENTDATA:fb
But in the, let say "new Version", it is different
@bombledmonk can you also send us some cu8 samples to check?
Hi @zuckschwerdt , I was playing around with the bitbench data. Can this be a solution for the "new Version"? (But I think I am terrible wrong :-) ) Bitbench
Can this be a solution for the "new Version"?
Interesting, maybe. We need to compare old and new cu8 files to see if there is some shift in the bits or something like that.
i also just purchased a new pack of sensors and had troubles with the decode too, so started poking around...
From what i can tell, they appear to be doing things a bit differently now. They don't use that parity check any more. The last 2 bytes of the 48b word are a CRC16/AUG-CCITT checksum (b[4:5] = crc16 checksum):
uint16_t crc_sum = crc16(b, 6, 0x1021, 0x1d0f);
if (crc_sum == 0) {
// new version of message
}
The event type ( b[2] & 0xf ):
0 = Button Press
1 = Battery Report
2 = Water Leak
The extra event data in b[3]:
- When button press, always the value 0x54.
- When battery report, i'm seeing 0x64 -- assuming this is still the same battery level indicator, i.e. 0x64 = 100% full ... older batteries i put in appeared to scale that number down
- When water leak detected, the event data appears to be an incrementing counter corresponding to a "unique" event... if the water leak is persistent, it repeatedly transmits the same value ... if the water leak is cleared (i.e. i dried it off), the next water leak will have +1 value in b[3].
b[0:1] still looks like the device id
I was going to make a PR (but don't have the old sensors to make sure i don't break things). If someone can help me validate changes, i'm happy to clean up and push what i've done.
Just add a new decoder in the same file. The crc check will make sure things work well.
I likewise just received a 5 pack of these sensors after finding this rtl_433 plugin and the discovery add on was able to pick up my refrigerator sensors acurite 986 both temp and battery.
Unfortunately no dice on 5/5 of these H5054.
I just got a 5 pack of the H5054 from Amazon and was unable to get them to read correctly with the latest master rtl_433. Using the changes from #2273 it appears they are correctly reporting button, leak and battery events to MQTT. So far I have only tried 2/5 of them but prior to those changes 0/2 were working.
I also have a H5054. After applying the changes from https://github.com/merbanan/rtl_433/pull/2273, the button press is detected but not the alarm nor the battery.
