rtl_433

rtl_433 copied to clipboard

I'm trying to grok what rtl433 is producing in MQTT my output configuration looks like this.

mqtt://host:port,retain=1,devices=sensors/rtl_433/P[protocol:255]/ID[id:0],events=sensors/rtl_433/events,states=sensors/rtl_433/states

Now when I receive an event, the event sometimes includes a model, sometimes includes a protocol and sometimes includes an id, and when the device is created it sometimes has a protocol, sometimes includes an id, but never has a model, and I know that there's a default set there for protocol to be 255 and id to be 0, which isn't at all helpful.

Shouldn't there be some consistency?

I would expect some kind of consistency in how the codes that are received are noted too, as there's a bunch of values which come out but non seem to be consistent in terms of button+action, for instance, a remote I have may produce button and code in the device output, but neither of those correspond to the precise button, e.g. it may be row 4, but the on and off buttons are different buttons and the code doesn't determine the difference between them.

this decoder for instance decoder n=Kerui,m=OOK_PWM,s=333,l=972,r=11000,g=1100,bits=25,invert,get={20}:state,get=@20:{4}:event:[10:pir 14:open 7:close 11:tamper 15:battery_low] doesn't produce a protocol, or an id but within the JSON there are clearly some unique identifiers which would serve as an ID.

A reliable and predictable structure of JSON would help tremendously here.

I think at the very least model and brand should appear in both events and device entries in MQTT if they are known.

Flex decoders don't have a protocol number as they are specified/loaded dynamically. The only proper protocol numbers are listed with "-R". "model" however is always available -- you should use that.

There is almost always and "id" on protocol, but some few just don't have that. If you want an ID for a flex decoder then add something like ,get=@0:{8}:id (e.g. if ID is the first byte).

Especially the the cheap foil-keypads do not have a common agreed button to bits mapping. We can only report the raw code.

model isn't sufficient to build a unique path for MQTT from, it needs to have a MQTT path compliant device type identifier and a unique instance identifier, I don't always get an ID, or I get a non-unique ID or sometimes I get a non numeric ID such as H, this doesn't prevent devices over-writing each other.

From what you're saying it may be best to adapt my config to

mqtt://host:port,retain=1,devices=sensors/rtl_433/M[model]/ID[id:0],events=sensors/rtl_433/events,states=sensors/rtl_433/states

I'll try that next.

M[model] doesn't produce a good output P[protocol:255] is better, if the protocol numbers are auto-assigned then it should be possible to include them in the flex decoder?

from the other side of this, model should probably be included in the devices output, just for completeness, but isn't, that's not entirely useful either it means when I do use protocol I lose the model entirely.

What exact problems did you notice with [model]? It should always be "<Manufacturer>-<Model>" https://triq.org/rtl_433/DATA_FORMAT.html

Protocol is neater, and there's still not unique identifier that's required in there.

Even being able to specify a fixed protocol, or have the first row back populate into the object would help.

For instance I have this decoder...

n=Doorbell,m=OOK_PWM,s=300,l=600,r=5256,g=548,t=134,y=0,bits=25,match=cba,get={12}:protocol,get=:12:{8}:id

This produces a series of rows,

{"time":"2022-04-19T14:28:24.850420","model":"Doorbell","count":5,"num_rows":5,"rows":[{"len":25,"data":"cba3fa8","protocol":3258,"id":203},{"len":25,"data":"cba3fa8","protocol":3258,"id":203},{"len":25,"data":"cba3fa8","protocol":3258,"id":203},{"len":25,"data":"cba3fa8","protocol":3258,"id":203},{"len":25,"data":"cba3fa8","protocol":3258,"id":203}],"codes":["{25}cba3fa8","{25}cba3fa8","{25}cba3fa8","{25}cba3fa8","{25}cba3fa8"],"mod":"ASK","freq":433.84966,"rssi":-0.133507,"snr":15.74729,"noise":-15.8808}

Each of which now contains a protocol and id, these are then unique enough to make sense of.

This is generally better because Model returns all kinds of spurious information where as two uniquely identifying values are sufficient for me to name that device.

However, because those protocol and id values are inside of the rows, they're not as useful as if they existed in the parent object.

My gripe here is about inconsistency, and any way of making the output from flex, and other decoders more generally reliable and uniquely identifiable should be the end-goal.

This will also translate to better HASS integration as that's my intended audience. I'm willing to write patches if given some signposts.

Maybe unique or countonly can help with the flex decoder output.

I'm still not following the "Model returns all kinds of spurious information"? Please give examples.

And note that "id" is perhaps not the unique attribute users are looking for. For simple devices it's likely "model"+"channel".

Spurious as in, my motion sensors identify as smoke detectors, and are the wrong brand/model... but the data is usable.

Ok, now I get it. But wouldn't the protocol show the same wrong info? (but a number instead of "Motion"/"Smoke")

Sure, but a numeric protocol is more ambiguous in the right way, in so far as the model name is misleading, I have actual sensors which are different brands and the erroneous information is distracting.

I've opened the following PR #2050 which deals with one part of the issue. Of course it's still up to the person creating the decoder to configure the appropriate keys they need.

in testing it's struck me as odd that with the following in the flex decoder match=cba, I still get data frames which don't start with cba, surely the match should trim the chaff off either end? I think I might look into fixing the filtering there, rather than trying to pick the mode of the results in the rows. With a proper fix at that level it would mean that the first row is sufficient, but it also means filtering out a lot more junk generally.

For match= at least one row needs to match at any position. In that way it's not a filter for rows but for transmissions. A row filter would be good to have. Also anchoring the match might be a useful addition.

But that's getting into procedural processing, which would be great but also complicated to design right. The idea was to add filter and transform steps at some point. E.g. functions like "match", "align", "decode_9to8", "check_crc" that are processed in-order. But we'll then need to have a tokenized "program" and some "execution".

Starting with a simple filter would be something.

I recently encountered a similar challenge...

• My flex config has the 'id' value extracted OK
• My MQTT topics are created, but only to the Man-Model level: rtl_433/foohost/devices/Quinetic-QUGDMK
• Within that topic all of the extracted data is within the rows object.

Adding unique to my flex config solved the issue, and the unique topics are now created, e.g. rtl_433/foohost/devices/Quinetic-QUGDMK/9362

Where are we on this? Are there still problems with the current code? If so, are they really about mqtt, or about disorder in the underlying decoders, or something else?