EV1527 sub-decoders Akhan-100F14 and Smoke-GS558 produce false decodes and should be disabled by default about rtl_433 HOT 21 CLOSED

Fair enough on hand parsing but ... libraries.

My real problem is that people say "use flex" but then when someone gets rtl_433 and runs it those decoders do not just work.

So for EV1528, should we just have a default decoder that prints EV1528 and the hex, and disable the rest? Then people will discover they have something, and can enable their device.

In case it's not clear, I'm a huge fan of being able to just run with pretty much no args and find what's out there. But I also don't want to decode anything without a decent checksum/crc.

from rtl_433.

I'd vote for trying to reduce these false positives for Akhan-100F14 and Smoke-GS558 etc, but then again I'm biased by my own current needs :-)

FWIW, I've now got 6 of these buttons ($12 each CAD on Amazon lol) and the following config seems to be working flawlessly to distinguish between them:

decoder n=SOS-Button,m=OOK_PWM,s=400,l=1100,g=1200,r=3300,unique,bits=25,get=id:@0:{20},match={20}d0a5de8

decoder n=SOS-Button,m=OOK_PWM,s=400,l=1100,g=1200,r=3300,unique,bits=25,get=id:@0:{20},match={20}77995e8

decoder n=SOS-Button,m=OOK_PWM,s=400,l=1100,g=1200,r=3300,unique,bits=25,get=id:@0:{20},match={20}d37bde8

decoder n=SOS-Button,m=OOK_PWM,s=400,l=1100,g=1200,r=3300,unique,bits=25,get=id:@0:{20},match={20}f1355e8

decoder n=SOS-Button,m=OOK_PWM,s=400,l=1100,g=1200,r=3300,unique,bits=25,get=id:@0:{20},match={20}3d8f7e8

decoder n=SOS-Button,m=OOK_PWM,s=400,l=1100,g=1200,r=3300,unique,bits=25,get=id:@0:{20},match={20}664f7e8

from rtl_433.

Hi @jharris4:

They are all based on EV1527/PT2260/62/64 protocols.

So you may have to arrange your own conf file for your remote and get the figures. Look into conf folder to get samples.

Also look into the Akhan decoder to get more details around the RF signal modulation and pulse information, this will help you build the conf file.

Try with -R 48:v -R 86:v to get the raw message (codes) information that could help you also.

from rtl_433.

Ok, I ran rtl_433 -S all -T 2 and pressed the button once to record the raw data.

Terminal output was:

time      : 2024-05-26 21:27:28
model     : Akhan-100F14 ID (20bit): 0x2f5a2
Data (4bit): 0x1 (Lock)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2024-05-26 21:27:28
model     : Akhan-100F14 ID (20bit): 0x2f5a2
Data (4bit): 0x1 (Lock)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2024-05-26 21:27:28
model     : Akhan-100F14 ID (20bit): 0x2f5a2
Data (4bit): 0x1 (Lock)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2024-05-26 21:27:28
model     : Akhan-100F14 ID (20bit): 0x2f5a2
Data (4bit): 0x1 (Lock)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2024-05-26 21:27:28
model     : Smoke-GS558  id        : 8919
unit      : 20           learn     : 0             Raw Code  : 845af4
*** Saving signal to file g004_433.92M_250k.cu8 (83716 samples, 262144 bytes)

And here's what the resulting cu8 file looks like with triq's I/Q spectrogram:

from rtl_433.

Hi @jharris4:

At RF signal, it's already known, for Akhan, modulation = OOK_PWM, short=316, long=1020
For Smoke-GS558, it's little more, OOK_PWM, short=436, long=1202, reset=14100

Your button could be in the middle, close to Akhan values, inside the tolerance range, and may be due to battery in your RF button the signal is slowdown after a long press and is decoded as Smoke. Could be also poor RF quality into such device sensor.

Try this:

rtl_433 -R 48:v -R 86:v

You should have codes : {25}0x2f5a21 what ever Akhan or Smoke-GS558

To confirm that try:

rtl_433 -R 48 -R 86 -A

And you may see the pulse duration increasing with long press.

Edit: if you reverse your Smoke-GS558 from Raw Code : 845af4 --> (reverse byte 2,1,0 to 0,1,2 position) --> 0xf45a84 --> (reverse bit position) --> 0x2f5a21 as expected.

from rtl_433.

Thanks for the pointers! I'm having some success with a flex decoder now:

rtl_433 -R 0 -X n=Button,m=OOK_PWM,s=400,l=1100,g=1200,r=3300,unique,bits=25,get=ID:@0:{20},match={20}d0a5de8.

Now I see output like this:

time      : 2024-05-27 17:39:08
model     : Button       count     : 1             num_rows  : 1             len       : 25            data      : d0a5de8       ID        : 854621

time      : 2024-05-27 17:39:08
model     : Button       count     : 1             num_rows  : 1             len       : 25            data      : d0a5de8       ID        : 854621

For a single button press, I get a few of those, and for a long press there's a steady stream of them.

Does rtl_433 provide any way of aggregating/batching some of these signals somehow? I was thinking the repeats flex decoder option could be useful, but couldn't figure out how to use it.

from rtl_433.

@jharris4 : good progress !

you already used the unique into the flex to remove repeated data.

About repeats purpose into the same RF transmit:

repeats=<n> : only match if some row is repeated <n> times
     use repeats>=n to match at least <n> and repeats<=n to match at most <n>

If the gap between 2 transmits is too important or signal duration is >1 s if I'm not wrong, rtl_433 considers as 2 or more RF transmits and you will see the message repeated.

from rtl_433.

@jharris4 It seems the next step is for you to polish a flex decoder definiton and submit it as a PR to be in the tree somehow, to help others.

There may still be a bug lurking, in that absent flex there are some decoders claiming some of these things, and it's not entirely clear that the way things are is right, or optimal, or what optimal even means.

from rtl_433.

At some point we should default-disable EV1527 protocols like Akhan-100F14 and esp. Smoke-GS558 -- or better turn them into flex decoders (but advanced checking and extraction options are missing in the flex spec currently).

from rtl_433.

What then is the plan for this issue? Before we disable and move to flex, I think we need to address #2654 first. Seems like I should open three issues and then close this:

1. Add mechanism for flex decodes to validate crc/checksum (and become first-class decoders capable of being default on)
2. add some flex decoders to be default on, with mechanism to enable/disable them (flex gets a protocol and there's a sub-protocol? protocol gets a 32-bit int and we assign in-tree flex decoders in some range far about the existing 'real protocols'?)
3. default-disable EV1527 protocols that claim packets not from their devices

about 3, it seems that passing the crc is enough to know it's a valid frame but not enough to know what device, as the missing protocol id field is... missing. I don't want to debate any of the approaches to these, just figure out what the new issues should be, so we can close this, as we have to be in a mode where non-actionable issues do not linger.

from rtl_433.

re 1: I suspect more additions to the current flex spec parser will be fragil. I did test an improved and more expressive language for that but I don't really want to write all that in C.

re 3: EV1528 is just "fixed" 24 bits, there is generally no way to tell if it's any particular device. For some devices there is structure to the bits (like a unit or button code) but generally it's just a long ID.

from rtl_433.

@gdt for these devices the same repeated message is the control to validate it without checksum/crc.

• What is the number of repeated message to consider as accurate/valid ? Or not enough for you , you still need crc or checksum ?

from rtl_433.

We do not, as far as I know, have a facility to accumulate internally bits from decoders without checksums and then call 3 or 4 of them that match exactly a valid decode and output it once. I am not even sure we have an open issue to add that. If we did, and the false rate was reasonably low, that would be ok, because "got same bits 3 times" or maybe even twice, is a kind of checksum. But now, I think they get sent to the output just arriving once.

The problem with EV1528, as I understand it, is that it has a checksum and that gives you 24 bits, and this is reliable. But then various decoders are looking at those bits and guessing that it's their device, and this is fundamentally flaky.

from rtl_433.

Now we have an issue to treat repeats as MIC: #2957

from rtl_433.

The EV1527 OTP encoder is very simple. It has 20 bits "burned-in" ID ("1 million codes") and pins for additional 4 bits data. It's then encoded to PWM (timing 1:3 and 3:1).

That 24 (+1 sync) bit format has become ubiquitous, and the bits might represent something else, e.g. remote controls likely use more than just 4 data bits.

Your conclusion is correct, upon receiving 24 (25) bits with some wildly varying PWM timing we have no clues what it represents.
Users should generally note the exact timings of a particular device, adjust some flex decoder and use that. They can combine (and discern) multiple devices if timings vary with enough margin. Otherwise it is mostly a "one EV1527 decode per household" thing.

from rtl_433.

So therefore, we should have an open ticket to disable all the things that interpret EV1527, and just have a generic decoder that has 4 1-bit fields and a 20-bit field? And have flex decoders with more precise timing checked in so that people can grab them easily? And then close this?

from rtl_433.

I need to have another look, but I'd say that most decoders reading 24/25 PWM bits have additional checks, just Akhan-100F14 and esp. Smoke-GS558 are prone to false positives. A generic EV1527 (also PT2260/PT2262 SC2260/SC2262) might produce false positives -- but that is worth a try.

from rtl_433.

@jharris4 Can you post a specific manufacturer/model?

It sounds like we are arriving at

• any EV1527 sub-decoder that is prone to false positives should be disabled by default, and we have a list of two right now.

I will retitle and this can await a PR.

from rtl_433.

I don’t know the specific manufacturer/model.

I’ve seen the button sold under a couple of generic sounding names like this:

“Gloglow 433Mhz Rf Ev1527”
https://a.co/d/d2lR2Tz

On the actual circuit board the only writing is “SOS v2.1”.

from rtl_433.

Both are now default disabled with #2958
It should now be easier to just use custom EV1527 flex decoders.

from rtl_433.

disabled so closing. feel free to comment if there is something else to be done

from rtl_433.