The rationale for the 3 acurite devices being handled by the same protocol is they use the same RF encoding with slight differences in message format that can be used to tell them apart. If they were split into 3 separate protocols, they would still match, and all 3 would run each time. They wouldn't output anything, but they'd do the same message envelope validate in each call back.
The ability to turn protocols on an off was added to rtl_433 to reduce CPU overhead and to ignore false positives. The CPU overhead problem has been fixed, it used to be that every sample was iterated over for each enabled protocol. Now the message is converted into pulses much earlier. CPU usage on a 1st gen. RPi was then low enough that it could run with all protocols enabled. Protocols in rtl_433 are still a bit more heavyweight then they should be. There is some cleanup work that needs to be done there at some point.
What are the use cases where you've got multiple Acurite devices, but only want to see the output from a subset?
thanks for the explanation. fixing the cpu overhead goes a long way toward making the selection of separate protocols moot.
however, selecting output from rtl_433 based on sensor, not protocol, is still useful.
one use case is that when i test for lightning sensor, any other sensor data just complicates things. but that is a development use case, so not really a big deal.
the use case for support is a much bigger deal. it is easier to explain to users "each type of sensor has its own number in rtl_433" rather than trying to explain "there are two different options for 5in1 packets, and if you just want to get lightning data you also have to get 5in1 and tower data, but not the same 5in1 data as the other 5in1"
from a user point of view, it does not matter which sensors share the same protocols, especially when the semantics of using rtl_433 are based on "choose a type of sensor" rather than "choose a protocol". users see sensors and sensor models, not protocols or encoding/decoding.
If you wanted to select/filter certain devices, why wouldn't that be handled in what ever consumed the output of rtl_433?
Each device type has a fixed string to identify the device type "Acurite tower sensor", "Acurite 5n1 sensor", "Acurite lightning".
Also each devices decoded by the shared Acurite protocol 39 has a fixed ID that is on the order of 12-16 bits. The consumer could select on that. (A consumer might also want to select on Channel number.)
the weewx-sdr driver already does this using this construct:
database_field = <observation_name>.<sensor_identifier>.<sensor_type>
to map sensor output to fields in a database.
but once again from a user point of view, it is more difficult to filter when you're getting data from things you do not care about.
if someone is trying to set up a lightning sensor, but they're getting 5in1 packets from one neighbor and tower packets from another neighbor, that makes the configuration more difficult.
Some of this should get easier with the conversion to structured data that will output JSON. I think a Pull Request has recently been merged that makes the 592TXR tower sensor output JSON, but I haven't tried it yet. I should follow suit and make the 5n1 have structured data output.
weewx-sdr will do json parsing if you ask for it from rtl_433 and the sensor parser emits json. otherwise it falls back to parsing lines of text.
from my pov, having a stable output from the rtl_433 sensor is more important than whether that output is json or lines of text. but it would be nice if everything did json (or nothing did json) so i don't have to maintain two different parsers for every sensor.
m