-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
EV1527 sub-decoders Akhan-100F14 and Smoke-GS558 produce false decodes and should be disabled by default #2939
Comments
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 |
Hi @jharris4: At RF signal, it's already known, for Akhan, modulation = OOK_PWM, short=316, long=1020 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:
You should have To confirm that try:
And you may see the pulse duration increasing with long press. Edit: if you reverse your Smoke-GS558 from |
Thanks for the pointers! I'm having some success with a flex decoder now:
Now I see output like this:
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 |
@jharris4 : good progress ! you already used the About repeats purpose into the same RF transmit:
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. |
@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. |
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). |
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:
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. |
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. |
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. |
@gdt for these devices the same repeated message is the control to validate it without checksum/crc.
|
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. |
Now we have an issue to treat repeats as MIC: #2957 |
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. |
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? |
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. |
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:
|
@jharris4 Can you post a specific manufacturer/model? It sounds like we are arriving at
I will retitle and this can await a PR. |
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” On the actual circuit board the only writing is “SOS v2.1”. |
Both are now default disabled with #2958 |
disabled so closing. feel free to comment if there is something else to be done |
Hi, I've been using rtl_433 for a few things, and recently purchased a couple of 433mHz RF buttons to try out.
A single press of the button results in the following (variable number of repeated messages)
Where it gets interesting is when I long press the button (holding it down) I get those same messages, but when I release the button I get one additional new message for a completely different protocol:
I'm seeing this consistently for long & short press, which means I can create some automations around those actions, but it feels odd/weird to build this on top of events that are being reported as if they are coming from two different devices.
Has anyone else encountered a similar pattern with another device, or is there any recommended advice on how to handle this kind of situation? Thanks!
The text was updated successfully, but these errors were encountered: