Add support for Geevon TX19-1

[anarsoul]

The device itself can be found at Amazon, e.g. https://www.amazon.ca/Geevon-Wireless-Outdoor-Thermometer-Replacement/dp/B0BMLRJ61Q

The protocol is essentially the same as with TX16-3, the only difference is that checksum algorithm has changed. I tried feeding the data into reveng, but unfortunately it's enable to find CRC model.

[zuckschwerdt]

Thanks! Is there really an extra bit between packets? Or is that maybe a sync pulse for the next packet -- we sometimes see that.

We need to figure out the new checksum. Not having any checksum will produce false positives.

The model key should have the name string on the same line, use DATA_COND if you need different names.

[anarsoul]

Thanks! Is there really an extra bit between packets? Or is that maybe a sync pulse for the next packet -- we sometimes see that.

This is what I get when I run rtl_433 -R 0 -X "n=geevon,m=OOK_PWM,sync=750,long=500,short=250,r=1700,invert"

time      : 2024-12-08 12:27:06
model     : geevon       count     : 6             num_rows  : 6             rows      : 
len       : 1            data      : 0, 
len       : 73           data      : 80002e3027aa55aacd0, 
len       : 73           data      : 80002e3027aa55aacd0, 
len       : 73           data      : 80002e3027aa55aacd8, 
len       : 73           data      : 80002e3027aa55aacd0, 
len       : 73           data      : 80002e3027aa55aacd0
codes     : {1}0, {73}80002e3027aa55aacd0, {73}80002e3027aa55aacd0, {73}80002e3027aa55aacd8, {73}80002e3027aa55aacd0, {73}80002e3027aa55aacd0

From what I can tell from the capture extra bit is here, see https://triq.org/pdv/#AAB00B040100FC02D801DC27148155+AAB00B040300FC02D801DC27149155+AAB054040100FC02D801DC271482A082A082A082A082828282828282828282A082A0A0A08282A0A0A0828282828282A08282A0A0A0A082A082A082A08282A082A082A082A0A082A082A082A082A082A0A0A0A0A0A0829155+AAB00B040300FC02D801DC27149155+AAB054040100FC02D801DC271482A082A082A082A082828282828282828282A082A0A0A08282A0A0A0828282828282A08282A0A0A0A082A082A082A08282A082A082A082A0A082A082A082A082A082A0A0A0A0A0A0829155+AAB00B040300FC02D801DC27149155+AAB054040100FC02D801DC271482A082A082A082A082828282828282828282A082A0A0A08282A0A0A0828282828282A08282A0A0A0A082A082A082A08282A082A082A082A0A082A082A082A082A082A0A0A0A0A0A0A09155+AAB00B040300FC02D801DC27149155+AAB054040100FC02D801DC271482A082A082A082A082828282828282828282A082A0A0A08282A0A0A0828282828282A08282A0A0A0A082A082A082A08282A082A082A082A0A082A082A082A082A082A0A0A0A0A0A0829155+AAB00B040300FC02D801DC27149155+AAB053040100FC02D801DC271482A082A082A082A082828282828282828282A082A0A0A08282A0A0A0828282828282A08282A0A0A0A082A082A082A08282A082A082A082A0A082A082A082A082A082A0A0A0A0A0A08355

Set slicer to PWM, short to 256us, long to 476uS, sync to 728uS

We need to figure out the new checksum. Not having any checksum will produce false positives.

Not really unless there is another protocol with payload of 72 bits with 0xaa, 0x55, 0xaa at the same positions. Anyway, I have no idea how to reverse engineer the checksum. There is no software from Geevon to capture the data and I have no way to dump the firmware from the sensor.

The model key should have the name string on the same line, use DATA_COND if you need different names.

I'll look into it.

[anarsoul]

BTW, it looks like TX16-3 is also 73 bits, see https://github.com/merbanan/rtl_433/blob/master/src/devices/geevon.c#L67 but the author didn't bother to document the last bit

Another issue: I don't understand why tests/symbolizer.py check complains, could you help me with that?

[zuckschwerdt]

don't understand why tests/symbolizer.py check complains

There are these warnings and errors:

• Warning: doc missing for geevon_callback_tx16_3
• Warning: doc missing for geevon_callback_tx19_1
• Error: models not found for geevon_tx16_3
• Error: models not found for geevon_tx19_1

For the docs maybe use a doc comment with @sa geevon_callback_generic() (which should be called geevon_callback_decode).
The models just need to be on the same line.

[zuckschwerdt]

For the checksum, post a list of many different codes and we'll take a look at what it could be.

[anarsoul]

For the checksum, post a list of many different codes and we'll take a look at what it could be.

How many do you need?

[zuckschwerdt]

Not sure, let's start with about 30 unique code, mostly close together (very little bit differences) if that's possible.

[anarsoul]

Not sure, let's start with about 30 unique code, mostly close together (very little bit differences) if that's possible.

Here you go:

7f002db063aa55aa78
7f002de063aa55aac5
7f002e0063aa55aad3
7f002d9060aa55aa79
7f002d0028aa55aa1a
7f002c6026aa55aaa1
7f002c002aaa55aa2f
7f002bc02aaa55aacf
7f002b802baa55aa59
7f002b502baa55aa57
7f002b202caa55aa86
7f002ae02daa55aa38
7f002ab02eaa55aa7c
7f002a902eaa55aa84
7f002a6030aa55aaee
7f002a5030aa55aa6a
7f002a2031aa55aa78
7f002a0030aa55aad7
7f0029d031aa55aa12
7f0029b032aa55aad2
7f0029a033aa55aaf9
7f00299033aa55aa7d
7f00298033aa55aa01
7f00296033aa55aa8b
7f00295033aa55aa0f
7f00294034aa55aae7
7f00293034aa55aaa2
7f00292034aa55aade
7f00290034aa55aa26
7f002a4059aa55aad6
7f0029205daa55aa1e
7f00291045aa55aac5
7f00290037aa55aadf
7f00290035aa55aa71
7f0028f035aa55aa1c
7f0028e035aa55aa60
7f0028d035aa55aae4
7f0028c034aa55aacf
7f0028b034aa55aa8a
7f0028b035aa55aadd
7f0028a034aa55aaf6
7f00288032aa55aacd

[anarsoul]

And a bit more:

5400288038aa55aa7f
540028d039aa55aa95
5400290039aa55aa00
5400294038aa55aa96
5400298038aa55aae4
540029c037aa55aa6b
54002a0036aa55aad2
54002a4035aa55aaea
54002a8034aa55aacf
54002ab034aa55aa4b
54002af033aa55aa1e
54002b2032aa55aadc
54002b6031aa55aae4
54002b9031aa55aa12
54002bc02faa55aa33
54002bf02faa55aab7
54002c202eaa55aa7c
54002c402eaa55aa45
54002c702daa55aa38
54002ca02caa55aa61
54002cc02baa55aacc
54002ce02baa55aa34
54002d002aaa55aa72
54002d2029aa55aa73
54002d4029aa55aa4a
54002d6028aa55aae5
54002d8028aa55aa6f
54002da027aa55aad9
54002db027aa55aaa5

(The first byte - ID - changes when you remove the batteries, apparently it's generated randomly)

[zuckschwerdt]

Checksum looks like a LFSR, Galois with bit reflect and byte reflect, generator 0x98 and key 0x25.
I.e. somthing like if (chk != lfsr_digest8_reflect(b, 8, 0x98, 0x25)) …

[anarsoul]

lfsr_digest8_reflect

It doesn't seem to work:

geevon_decode: a9002e601faa55aa0b - calculated: 62
geevon_decode: a9002e501faa55aa8f - calculated: f2
geevon_decode: a9002e401faa55aaf3 - calculated: 0a

[zuckschwerdt]

Yes, the key is rolled the wrong direction I think. I'll look into that.
Meanwhile you can test with this:

// Checksum is actually an "LFSR-based Toeplitz hash"
// gen needs to includes the msb if the lfsr is rolling, key is the initial key
static uint8_t lfsr_digest8_galois(uint8_t const *message, int bytes, uint8_t gen, uint8_t key)
{
    uint8_t sum = 0;
    // Process message from last byte to first byte (reflected)
    for (int k = bytes - 1; k >= 0; --k) {
        uint8_t data = message[k];
        // Process individual bits of each byte (reflected)
        for (int i = 7; i >= 0; --i) {
            // fprintf(stderr, "key at bit %d : %04x\n", bit, key);
            // XOR key into sum if data bit is set
            if ((data >> i) & 1) {
                sum ^= key;
            }

            // shift the key right (not roll, the lsb is dropped)
            // and apply the gen (needs to include the dropped lsb as msb)
            if (key & 1)
                key = (key >> 1) ^ gen;
            else
                key = (key >> 1);
        }
    }
    return sum;
}

[anarsoul]

Yeah, this one works, thanks! Out of curiosity, how did you reverse engineer it?

[zuckschwerdt]

LFSR (digest) is a common scheme so I wrote a program to brute force the parameters: https://github.com/triq-org/revdgst/

[zuckschwerdt]

There is now a lfsr_digest8_reverse() which should work here.