Geevon T230303 Soil Moisture/Temp/Light Level Sensors - Help with finishing decoding

[emmjaibi]

Hello all and thank you for this amazing repository and project. I have caught the RTL_433 'fever' after getting tired of having 3 different temperature/humidity/weather consoles around the house.

I picked up another (!) console kit the other day which comes with an inexpensive weather-proof probe/transmitter for soil moisture, temperature, and relative light levels. I ordered the console display and two probes and have done my best to try and analyze and decode what I have been able to find. https://www.amazon.ca/Geevon-Moisture-Multiple-Indicator-Tempature/dp/B0CPSQVL9L?th=1

The console supports up to 6 sensors and they seem to get assigned a 'Number' based on the order in which they are first powered. There seems to be a fixed id for the sensors based on the two I have which survives battery changes but the number it will display under on the console does not stay the same (it is only based on first come first served).

Each sensor provides the following information as shown on the console display:

1. Soil Moisture (%) - docs say supports between 0 - 80 but I suspect it goes up to 99%
2. Temperature (C or F but I use C) - seems to support at least on the display -199C to 199C as there is space for a '-' and also for a '1' in the hundreds column but docs say nothing about range
3. Battery Level (x of 3) - shows as 1,2, or 3 segments out of 3 on a battery icon
4. Light Level (9 options) - shows light in a relative level using LOW, NOR, or HIGH with optional modifiers of '-' or '+' so complete range is LOW- to LOW to LOW+ to NOR- to NOR to NOR+ to HIGH- to HIGH to HIGH+

Here's the link to some example messages as captured and dissected in BitBench:
https://tinyurl.com/3mv7eapv

It looks like it has an inverted OOK PWM encoded signal with a preamble of 0x55aa and possibly a sync at the end of 0xf8. It seems to send the data in a pulse of packets of 12 total with the last repeat having 7bits truncated at the end.

Here is the flex decoder I have narrowed it down to which I used to do the bitbench analysis:

decoder {
    name        = Geevon_230303,
    modulation  = OOK_PWM,
    short       = 400,
    long        = 1200,
    sync        = 600,
    reset       = 3000,
    gap         = 2000,
    tolerance   = 100,
    bits        = 65,
    invert,
    preamble    = {20}0xaa551,
    get         = id:@0:{12},
    get         = moisture:@12:{8},
    get         = temp_sign:@20:{1}:[0:+ 1:-],
    get         = temperature_C:@21:{7},
    get         = battery_level:@30:{2}:[1:1/3 2:2/3 3:3/3],
    get         = light_level:@32:{4}:[0:low- 1:low 2:low+ 3:nor- 4:nor  5:nor+ 6:high- 7:high 8:high+]
}

I have some samples in cu8 format recorded for this but I think (hope) I'm past that stage in this analysis and so I won't post them unless requested.

I would really appreciate some guidance in trying to confirm the format of these messages and maybe solving the mystery of the couple of bits which I can't seem to figure out - perhaps they are CRC or more likely parity bits or maybe even they provide further temperature measurement details?

When I run the flex decoder, it is pretty reliable in pulling the data from the two sensors I currently have outside....but they only get published as subfields in the 'rows' field in MQTT by rtl_433 so they can't yet be used for full importation into HA.

This is what it looks like in MQTT Explorer right now:

rtl_433/9b13b3f4-rtl433/devices/Geevon_230303
Geevon_230303
..time = 2024-06-20T23:55:16.658965-0700
..count = 1
..num_rows = 1
..rows
......0
..........len = 45
..........data = 3fd380ef0600
...........id = 1021
...........moisture = 56
...........temp_sign = +
...........temperature_C = 14
...........battery_level = 3/3
...........light_level = low-
codes
...0 = {45}3fd380ef0600
mod = ASK
freq = 433.9023
rssi = -4.67397
snr = 16.78837
noise = -21.4623

Thanks again for your interest and support in this little reverse engineering attempt :)

[zuckschwerdt]

The last field is a checksum based on nibble-wide addition with carry. It seems to be one less than the sum of bit 20 to 56. See this BitBench.

[emmjaibi]

Wow - you make it look trivial to figure these things out. Thank you!

So that gives a structure of 68 bits like this:
PPPP PPPP PPPP PPPP PPPP IIII IIII IIII MMMM MMMM STTT TTTT ??BB LLLL CCCC SSSSSSSS
P=Preamble of 20 bits equal to 0xaa551
I=ID assumed 12 bits length seems to survive battery changes
M = soil moisture ~0-99% as an 8 bit integer
S = sign for temperature (0 for positive or 1 for negative)
T = Temperature as 7bit integer ~0-100
2 mystery bits
B = battery status in values of 1-3 for number of segments to show for battery
L = light level (9 states from LOW- to HIGH+)
C = 4 bit checksum
S = Sync of 8 bits equal to 0xf8

OK so if the 4 bits in position 57-60 are a checksum then it makes me think once more that the two bits in position 49 and 50 must be something meaningful - perhaps additional resolution for temperature? I tried all sorts of encoding schemes using 10bits for temperature and all I could seem to make match is a single bit for sign and 7 bits for temperature and then we are left with those two mystery bits after.

I currently have my flex decoder looking for 65 bits of data - I assume this is working despite the actual length as per BitBench showing 68 bit width because of the inversion that happens as part of the decoding with the sync bits?

How do I get this to the next step where I can get the data published to MQTT in a proper topic format instead of it all showing up as row/0/x?

[zuckschwerdt]

You need a length indication before the hex data, e.g. {65}, otherwise the length will be a whole count of nibbles. But that trailer can easily be ignored.

The "sync" trailer is unexpected. Are you sure it's not a decoding artifact? Does it look like proper bits in the spectrogram or OOK data?

You can add ,unique to the flex spec to only output one unique decode at the top level (no nested rows).

With all the fields and checksum and documentation you have this can also be a full decoder. Are you up to the C coding or do you want help there?

[emmjaibi]

You're right - I think the trailing pulses are a sequence of 5 '1's so the trailing zeros are just dead space gap not really part of a sync. So yes, when I put {65} in front of the raw hex in BitBench it works out properly.

Attached for you to double check if you wouldn't mind is an example sample:
g008_433.92M_250k.zip

When I try putting the unique argument in the flex decoder, I end up with no decoded data. Not sure why that happens. I also tried using the repeats>4 argument, but found it was dropping sometimes or perhaps I just don't know how to properly specify it along with the preamble and other arguments.

If you have a chance, please have a look at the sample and see if maybe I should tweak something else for the decoder. Also - any thoughts on the mystery two bits after the temp integer value? I can't figure that out after looking at it for a while.

[emmjaibi]

So it turns out, after getting 4 more of these sensors, that I had the structure slightly wrong. They seem to use a 16 bit permanent ID rather than a 12 bit ID. So the preamble was too long initially. The revised structure is as follows: BitBench

PPPP PPPP PPPP PPPP IIII IIII IIII IIII MMMM MMMM sTTT TTTT ??BB LLLL CCCC SSSSS

P = Preamble of 16 bits equal to 0xaa55
I = ID assumed 16 bits length seems to survive battery changes
M = soil moisture ~0-99% as an 8 bit integer
s = sign for temperature (0 for positive or 1 for negative)
T = Temperature as 7bit integer ~0-100
?? = 2 mystery bits
B = battery status in values of 0-3 for number of segments to show for battery
L = light level (9 states from LOW- to HIGH+) with values 0-8
C = 4 bit checksum
S = Sync of 5 bits equal to 0xf1

[a10kiloham]

Would you mind sharing the final decoder code you used? I just got an unbranded one of these on Aliexpress branded simply as HG01 or HG-01

[a10kiloham]

Has anyone gotten the final detection code working on this? I'd be highly appreciative. I've tried the following but with no result:

decoder {
    name        = Geevon_230303,
    modulation  = OOK_PWM,
    short       = 400,
    long        = 1200,
    sync        = 600,
    reset       = 3000,
    gap         = 2000,
    tolerance   = 100,
    invert,
    bits=66,
    preamble    = {16}0xaa55,
    get         = id:@0:{16},
    get         = moisture:@16:{8},   
    get         = temp_sign:@24:{1}:[0:+ 1:-],
    get         = temperature_C:@25:{7},
    get         = unknown:@33:{2},
    get         = battery_level:@35:{2}::[1:1/3 2:2/3 3:3/3],
    get         = light_level:@37:{4}:[0:low- 1:low 2:low+ 3:nor- 4:nor 5:nor+ 6:high- 7:high 8:high+],
    get         = checksum:@41:{4},
    get         = sync:@45:{5},
    unique,
}

[zuckschwerdt]

Wasn't the suggested decoder bits=65? what do you get if you skip that parameter?

[a10kiloham]

No result with bits set to 65 or just omitting that row. My testing is somewhat limited as I can only access the rtl433 app via a web ui so hard to see the full logs as much

[zuckschwerdt]

Are you receiving the transmissions at all, maybe try -A to see all incoming data regardless of decoding.
Otherwise try to grab a transmission as sample file (could be hard to do with a web ui though). https://triq.org/rtl_433/ANALYZE.html

[emmjaibi]

Hi - this is what I have been using now for a few months with reasonable reliability. It sometimes picks up a corrupted packet because I'm still running it as a flex decoder so no crc checks (although it was already figured out how it works above) because I'm not well versed enough to do the full code required.

decoder {
    name        = Geevon_230303,
    modulation  = OOK_PWM,
    short       = 400,
    long        = 1200,
    sync        = 600,
    reset       = 3000,
    gap         = 2000,
    tolerance   = 100,
    bits        = 65,
    invert,
    unique,
    preamble    = {16}0xaa55,
    get         = id:@0:{16},
    get         = moisture:@16:{8},
    get         = temp_sign:@24:{1},
    get         = temp_val:@25:{7},
    get         = unknown_bin:@32:{2},
    get         = battery_level:@34:{2},
    get         = light_level:@36:{4},
    get         = temp_raw:@24:{8}:%
}

Perhaps you can take a photo of the probe you have purchased (and in particular, close up of the small PCB board inside)? Maybe it isn't really the same design.

[a10kiloham]

This is the inside of it @emmjaibi
https://imgur.com/a/m3wGenZ

I've tried the other suggestions here to no luck so will try and find time to debug more this week.

Thanks for the help!