Writing basic flex decoders

[frevoli]

Hello all. Having written and used a few basic flex decoders via the -W flag I thought it would be good to add them to the main list of decoders properly. I followed an excellent online guide which was going perfectly until it told me to add my decoder to the list in src/Makefile.am but I can't find this directory anywhere. If someone could tell me what I'm missing it would be most appreciated! Many thanks, Matt

[frevoli]

Thanks for all your help recently with my questions and project assistance. Thanks to you I have now got my head around flex decoders and am ready to take the next step into writing proper scripted decoders.

If I write a new decoder can I add it in the same way you added Yale support yesterday? By making the necessary additions to: conf/rtl_433.example.conf include/rtl_433_devices.h src/CMakeLists.txt src/devices/ vs15/rtl_433.vcxproj vs15/rtl_433.vcxproj.filters

And after doing all that will I need to recompile or reload config to make it work. Thank you

[zuckschwerdt]

Yes, exactly that way. Or just include/rtl_433_devices.h and src/devices/<New_Decoder.c> then stage or commit your files and run ./maintainer_update.py -- that updates all other files.

[frevoli]

Fantastic thank you 😄

[frevoli]

Hi Christian,

Just an update to let you know my tests with rtl_433 are going well. I’m a radio ham so I have a steerable 433MHz beam on my roof which has proved really useful for “hoovering up” device transmissions in my neighbourhood.

Quick question - despite having many decoders, there are still many devices that get ignored bulecause I don’t have a decoder for them. I use -F to write my decoder captures to a csv file. Is there any way that rtl_433 can record the undecodable signals as a raw IQ file so I can analyse them later?

Cheers Matt

On 8 Jan 2022, at 20:31, Christian W. Zuckschwerdt @.***> wrote:

 Yes, exactly that way. Or just include/rtl_433_devices.h and src/devices/ then stage or commit your files and run ./maintainer_update.py -- that updates all other files.

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.

[zuckschwerdt]

Sure, use -S unknown to collect sample files. Then group, analyze and gives us more decoders ;) Though many might just be bad reception, should be easy to triage in the waterfall. ( https://triq.org/pdv/ )

[frevoli]

Awesome thanks mate. Can I use -F and -S in the same command?

Sent from my iPhone

On 29 Jan 2022, at 08:49, Christian W. Zuckschwerdt @.***> wrote:

 Sure, use -S unknown to collect sample files. Then group, analyze and gives us more decoders ;) Though many might just be bad reception, should be easy to triage in the waterfall. ( https://triq.org/pdv/ )

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.

[zuckschwerdt]

Yes, also multiple -F if you want e.g. logging and console output at the same time.

[frevoli]

Oh and I forgot to ask… when you use -S the file names are sequentially numbered with receiver details. Is there any way of changing or adding to the file name so that it is date/time? If this is not possible then it’s no major problem as I can probably resolve this with Python. Thanks again Matt

Sent from my iPhone

On 29 Jan 2022, at 09:19, Matt @.***> wrote:

Awesome thanks mate. Can I use -F and -S in the same command?

Sent from my iPhone

On 29 Jan 2022, at 08:49, Christian W. Zuckschwerdt @.***> wrote:

 Sure, use -S unknown to collect sample files. Then group, analyze and gives us more decoders ;) Though many might just be bad reception, should be easy to triage in the waterfall. ( https://triq.org/pdv/ )

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.

[frevoli]

-S unknown seems to be saving a lot of files! Like one every couple of seconds. They can’t all be genuine surely. Is there any way to filter away the noise? The danger is this will utilise a lot of HDD space if I leave it running for a period of time. Cheers again Matt

Sent from my iPhone

On 29 Jan 2022, at 09:30, Matt @.***> wrote:

Oh and I forgot to ask… when you use -S the file names are sequentially numbered with receiver details. Is there any way of changing or adding to the file name so that it is date/time? If this is not possible then it’s no major problem as I can probably resolve this with Python. Thanks again Matt

Sent from my iPhone

On 29 Jan 2022, at 09:19, Matt @.***> wrote:

Awesome thanks mate. Can I use -F and -S in the same command?

Sent from my iPhone

On 29 Jan 2022, at 08:49, Christian W. Zuckschwerdt @.***> wrote:

 Sure, use -S unknown to collect sample files. Then group, analyze and gives us more decoders ;) Though many might just be bad reception, should be easy to triage in the waterfall. ( https://triq.org/pdv/ )

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.

[zuckschwerdt]

There is no option to save any other file names, but date/time might be a worthwhile change. For now just use a script to rename based on file mtime, but keep the frequency and sample rate tag.

A filter to only save plausible samples would be nice. But we don't have that, no idea how to discern that. All files really should contain some pulses. Perhaps we could filter on a minimum number of pulses, e.g. "needs at least 10 proper pulses".

[frevoli]

Great ideas yes. I’ll randomly dip into some of the saved unknown files and see if they are noise or genuine, and see if I can spot a pattern. Perhaps file size could be a clue. If false hits can’t be filtered in live time it would still be cool to have a simple script which could iterate through them and delete the noise ones.

Sounds like my next task!

Cheers Matt

Sent from my iPhone

On 29 Jan 2022, at 11:16, Christian W. Zuckschwerdt @.***> wrote:

 There is no option to save any other file names, but date/time might be a worthwhile change. For now just use a script to rename based on file mtime, but keep the frequency and sample rate tag.

A filter to only save plausible samples would be nice. But we don't have that, no idea how to discern that. All files really should contain some pulses. Perhaps we could filter on a minimum number of pulses, e.g. "needs at least 10 proper pulses".

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.

[zuckschwerdt]

Appreciated! Try to find a scheme to sort out the "noise" files. File size is rather static, is always multiples of the block size (128k).

[frevoli]

That’s good to know, thanks. I’m wondering if I can write an algorithm that detects a patterned wave within the IQ file. Perhaps something GNU based. I’ll keep you posted mate!

Sent from my iPhone

On 29 Jan 2022, at 12:30, Christian W. Zuckschwerdt @.***> wrote:

 Appreciated! Try to find a scheme to sort out the "noise" files. File size is rather static, is always multiples of the block size (128k).

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.

[zuckschwerdt]

Since the buffer already passed the ASK or FSK demod with some supposed data, my first idea would be to inspect the pulse data, like the -A analyzer does. Much easier to do (do we have enough pulses, different but consistent lengths, ...)

[frevoli]

Christian, I think the -S unknown function is performing better than you give it credit for! I left it running for about an hour, in which time it captures just under 700 files which totalled just over 200Mb. I’ve randomly checked several of these files and most of them contain a signal/burst(s) of some description. I have found very few which are just noise. Therefore it seems an additional filter is unnecessary. Sure, there is still the option to run the files through a post-processing script to weed out the noise only files, but on the whole it works well as it is. I just have to accept that I will need a large amount of storage if I’m to run this for any long period. Cheers Matt

Sent from my iPhone

On 29 Jan 2022, at 12:57, Christian W. Zuckschwerdt @.***> wrote:

 Since the buffer already passed the ASK or FSK decode with some supposed data, my first idea would be to inspect the pulse data, like the -A analyzer does. Much easier to do (do we have enough pulses, different but consistent lengths, ...)

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.

[zuckschwerdt]

I prefer raw .cu8 files to really see what the signal is, but it might be an option to dump as .ook (also fsk) files. Those are quite small. Or run a periodic cleanup with rtl_433 -w FILE.ook FILE.cu8 ; rm FILE.cu8

[PeterHaban]

There is now a experimental decoder. Please check different sensors and events and report what you get.

Would be interesting if the guess on sensor type and event is correct, and what's in state (battery?).

Guessed data so far:

• Event 01: trigger, 03: binding, 04: tamper
• State: Could be battery?
• Yale HSA6010 Door/Window Contact: Sensor type: ac or ad
• Yale HSA6020 Motion PIR: : Sensor type: 15

And really interesting would be data from

• Yale HSA6080 Keypad
• Yale HSA6060 Remote Keyfob

Send me privately by mail if you like.

Hi, thanks for all your hard work on this :) I've got it working with a plugin for Home Assistant which gives me access to the mqtt messages. I've been playing with it for a bit and got the following:

Door/Window Sensor { "time": "2022-03-02 13:46:37", "model": "Yale-HSA", "id": 40950, "stype": 172, "state": 16, "event": 1, "mic": "CHECKSUM" }

Siren/Keypad (<- guess, this happens in addition to the key fob signal when I lock/unlock with the key fob) { "time": "2022-03-02 13:45:53", "model": "Yale-HSA", "id": 56584, "stype": 172, "state": 240, "event": 8, "mic": "CHECKSUM" }

Key Fob (<- pretty sure, only happens when I push the fob button) { "time": "2022-03-02 13:45:50", "model": "Yale-HSA", "id": 16858, "stype": 3, "state": 0, "event": 3, "mic": "CHECKSUM" } Keyfob: event 3 = Disarm event 0 = Arm

Is there any way I can see the Sensor type? Ideally the mqtt messages should have something like "device type = sensor/key fob/panel/siren" in the message, I can figure out what they are by ID but it would make it a lot easier to build automations. Happy to help and get more data if you can guide me on what's needed :)

[zuckschwerdt]

So far we guess stype 172 and 173 would be a window sensor, and 21 a PIR. 3 is new for the keyfob. But it really seems that the stype field is wider, as only stype+state seem to distinguish window and keypad above.

[zuckschwerdt]

If you could collect as many different messages as possible that woul be great. By that I just mean a table of Device-Type, Action, stype, state (maybe event).

Also are all your window/door contacts 172/16. Is siren always only 172/240 and Keyfob always 3/0? And I guess only the Keyfob really has different events? Or maybe the siren too (on/off)?

[PeterHaban]

I've had a bit more time to play and started with the door/window and PIR sensors. More detailed information and full mqtt messages in attached files at the bottom but in summary:

Window/Door sensor: All of mine are stype 173 or 172

Contact opened: state: 16 event: 1

Tamper button closed/off: state: 16 event: 4

Tamper button released/on: state: 18 event: 4

Binding button pressed: state: 18 event: 3

Low battery: state: 24 event: 4

PIR: Mine is stype: 21

Binding Button: state: 48 event: 3

Tamper button closed/off: state: 48 event: 4

Tamper button released/on: state: 50 event: 4

Movement trigger: state: 48 event: 1

Low battery: state: 50 event: 1

There is a tamper button inside which is usually pressed (safe/off) and it gets released (triggered/on) when the sensor is taken off its mount.

I've found the low battery signal by attaching a PIR and door/window sensor to an adjustable bench power supply and slowly dropping the voltage. door_window sensors.txt PIR.txt

[zuckschwerdt]

Very nice table, thanks. So stype extends partway into state, and the other "half" of state is likely event, as seen with tamper vs battery messages. (It's actually just three bytes we named stype, state, and event and that doesn't seem to hold up.)

[PeterHaban]

Found a bit more time to play with the key fob. Each sequence below is triggered by a signal from the key fob followed by what I think is the control panel sending commands to the siren. The two arm sequences have two signals to the siren, the first one is pushed out when a 10s beeping phase starts (10s to get out) and the second one when the beeping phase stops (one single confirmation beep, same for the disarm).

Arm:

1. Key Fob -> Control panel stype: 3 state: 0 event": 0

2. Control panel -> Siren - Ten second beeping starts stype: 172 state: 240 event: 5

3. Control panel -> Siren - Confirmation beep stype: 172 state: 240 event: 7

Home Arm:

1. Key Fob -> Control panel stype: 3 state: 0 event: 2

2. Control panel -> Siren - Ten second beeping starts stype: 172 state: 240 event: 5

3. Control panel -> Siren - Confirmation beep stype: 172 state: 240 event: 9

Disarm:

1. Control panel -> Siren -> Control panel stype: 3 state: 0 event: 3

2. Control panel -> Siren - Confirmation beep stype: 172 state: 240 event: 8

There's also an emergency/panic button on the key fob but it's too late to try that one... Do you need anything else? If you can make some changes to the code I'm happy to test if it picks it all up ok :)

[gdt]

I am having trouble understanding this issue. There's a lot of question/answer, which is fine but doesn't need to stay open.

What's the status and next steps? If anyone thinks it should be open, please explain why.

[gdt]

Nobody has explained why this questions should remain open....