MQTT relay: id is missing from devices with channel

[gdt]

rtl_433_mqtt_relay.py only adds id to the topic if channel is not present. This results in channel only for Acurite Tower devices, and really id is what is useful.

I propose to construct an "id-channel" hybrid, dropping those not present, as the point is to allow the receiver maximal naming accuracy.

This will be a wire protocol break, but I think we don't have a rule against that, and progress is more important.

I am about to do this and test it; this issue is just running the concept up the flagpole for objections.

[zuckschwerdt]

rtl_433_mqtt_relay.py is just an example. The idea was to showcase a few interesting lines of post-processing. That "no ID if Channel" is not possible with our normal MQTT output.
(Incidentally I use something like that script to read my sensors where I don't want to bother with ID changes on battery replacement.)

[zuckschwerdt]

Maybe showcase and comment a few different ways to build a topic.

[gdt]

I'm actually using this in production, to feed things into Home Assistant. I think there should be a way to do that, further extended with a config file (to avoid having to modify it).

I can see your point about ID, but to me skipping ID is a special case. Partially because a lot of devices (non-buggy ones :-) have stable IDs, and because the "skip id" strategy only works if there is one within range with that channel, which seems just to be luck.

I also am going to move the config from variables to a file of json, so people can use the git version without editing it with credentials (but same defaults if file not found). I could do that first, and have a variable to skip id.

I didn't find this to be a good example; it's much too mysterious, especially for those not already expert. Do you mean I should create a scripts/ dir and copy this to be something real instead? Or do this outside of the project?

Or are you saying that the mqtt support in the C executable is the main thing, and this is deprecated? It seems far easier to me, both from coding and debugging, to do the variable processing in python and I think the json string is a good "narrow waist" joint point.

[gdt]

I finally understood "is not possible with our normal MQTT output". I can see the point of showing interesting things, but I think the behavior should be the recommended path for most people so it's also useful.

Longer term there is:
calibration files, e.g. to tweak temp and humidity before sending
calculating dewpoint to send that too
accumulating repeated transmissions and doing some kind of error correction/merging
perhaps a plausibility filter to reject some errored packets
basically making a more capable sensor.

I realize that at some point I may diverge too far from project norms, but I'd just as soon have as much of the improvements that fit be here, for others to benefit from.

[zuckschwerdt]

If you want to build some examples to actually useful scripts then go ahead. Users will be requesting odd things though (command line arg for mqtt client certs?) -- be prepared ;)

Quick search shows argparse and configparser can work together: https://stackoverflow.com/questions/48538581/argparse-defaults-from-file -- could be easier /more natural to accept config.

The scripts are older that built-in protocols, but I always like to use a bridge script with some additional filtering myself.

It could also be interesting to add a script (or mode of operation) that reads from the HTTP API. An advantage would be the information if there is currently a connection (with UDP you won't known if there is a live rtl_433) and the possibility for multiple consumers (UDP readers per host are round-robin not fan-out).

[zuckschwerdt]

I've added example scripts for chunked/streaming/websocket HTTP API with 687fe8e.
Anyone feel free to make those nicer and easier to follow for new users.

• https://github.com/merbanan/rtl_433/blob/master/examples/rtl_433_http_events.py
• https://github.com/merbanan/rtl_433/blob/master/examples/rtl_433_http_stream.py
• https://github.com/merbanan/rtl_433/blob/master/examples/rtl_433_http_ws.py

[gdt]

status: I still have a local change that I need to clean up and submit.

[gdt]

I'm coming back to this. As I see it:

• rtl_433_mqtt_relay.py is still an example and thus we needn't be all that concerned about breaking changes.
• for many devices, if you have multiple, you really need id, and even if you have one you never know if your neighbor is going to get one, so not using id is unsound.
• The default format for rtl_433's builtin mqtt support is devices[/type][/model][/subtype][/channel][/id].

and therefore it is entirely reasonable to change the example script to simply append /id if defined, vs the current behavior of appending it if channel is not defined and id is defined. Yes, people using the example, if they decide to use the newer example code, will need to adjust configs. But that seems better than adding complexity which feels like it will take up more time than that one-time hit, over the next 5 years.

[gdt]

Closing in favor of #3014