Lost/random ID after battery replace

[radek-turecki]

Hello,

I'm using RTL_433 on the Windows 11 platform. Everything works almost fine and all information from the sensors are reported to MQTT by command:
rtl_433-rtlsdr.exe -M time:iso -C si -F mqtt://127.0.0.1:1883,retain=0,devices=sensors/rtl_433/ID[id]_[channel]/

But the problem is after replacing battery in the sensor. Very often, after replacing the battery, the temperature and humidity sensor is read with a different ID.

I use ID as the identifier of a given sensor as in the photo below:

So the question is - how to keep the ID for given sensor or how to identify the sensor regardless of ID (but I have several sensors from the same manufacturer)?

Thank you in advance for your help. Radek

[merbanan]

Hi, that is simply almost impossible.

One way that might work is to enable statistics and then look at signal strength. If you are lucky there is a clear difference that can map to different sensors. If that does not work switch to lithium based batteries. Then you dont need to change id that often.

[radek-turecki]

Yes, this is possible and occurs very often(!) I have 6 sensors (3 from one vendor and rest mixed) that operate wirelessly in the house. I will say more - practically every battery change ends up changing the ID.

Signal strength will not be a solution, as it can also fluctuate when other devices are operating on these frequencies. I have no way in OpenHub to control a device with a given ID that depends on its signal strength.

Changing the battery type to lithium batteries is not a solution either, because sooner or later at the end I have to reconfigure the home assistant software :-(

[pswiatki]

The only way, Radku: go for more expensive sensors - the ones that present consistent IDs over their radio interface. ~2 years ago I had that moment of "great surprise", too. It was very disappointing.

[radek-turecki]

Can you recommend any specific models that do not have this problem?

[merbanan]

The only solution that works in the long run is to replace the sensors. We have tried our best to make all sensors unique but these devices were not designed with this in mind.

[radek-turecki]

Do I need to pay attention to any specific parameter/function in the specification for them to work without a problem?

[merbanan]

Wmbus based ones have a very unique id.

[radek-turecki]

Thank you very much.

[zuckschwerdt]

To confirm you can check the decoder source, e.g. https://github.com/merbanan/rtl_433/blob/master/src/devices/fineoffset.c#L51 is a changing ID and https://github.com/merbanan/rtl_433/blob/master/src/devices/fineoffset.c#L448 is a fixed ID. It's usually commented in the source like that. Someday we'll have a nice big table with those hints, hopefully.

[zuckschwerdt]

Some time ago there was an idea floating around: Write a bridge script (see https://github.com/merbanan/rtl_433/tree/master/examples) that tracks known sensors. When one drops out and a new one comes online (maybe with roughly the same readings) then assume that the battery changed. The sensors then can be forwarded to MQTT with some fixed pseudo-ID.

Lot's of small details to consider and fine-tune though, e.g. a way to reconfigure manually and such. In the end, I guess, not much gained but potential for additional problems.

[radek-turecki]

solution a little around, but as you rightly pointed out is asking for additional trouble, but thank you for the suggestion.

[merbanan]

As long as only one device at a time disappears it will work. If you also track the period and phase it could improve tracking. But as long as you lose running state you need to reconfigure. But it will be a lot of work for something that can be solved by just buying other sensors.

[radek-turecki]

Hmmm, I'm still trying to analize this problem, I run the command on console (insted of mqtt) and result is as following.

Question in my mind - Why some sensors have "ID" (model: inFactory-TH), and some of them "House Code" (where the model is differnet that " inFactory-TH")?

For output format I'm using -F to mqtt and [id] as parameter.

Maybe here is some problem in the RTL_433 code, if it doesn't find the ID, it substitutes some other random value from the "House Code" after restarting the sensor?

It is possible that I am wrong, but I am looking for potential solution....

R:\_OpenHAB\rtl_433-win-msvc-x64-23.11>rtl_433-rtlsdr.exe -M time:iso -C si
rtl_433 version 23.11 branch  at 202311281352 inputs file rtl_tcp RTL-SDR
Found Rafael Micro R820T/2 tuner
[SDR] Using device 0: Realtek, RTL2838UHIDIR, SN: 00000001, "Generic RTL2832U OEM"
Exact sample rate is: 250000.000414 Hz
Allocating 15 (non-zero-copy) user-space buffers
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2024-07-08T19:00:44
model     : Ambientweather-F007TH                  House Code: 243
Channel   : 3            Battery   : 1             Temperature: 27.6 C       Humidity  : 54 %          Integrity : CRC
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2024-07-08T19:00:56
model     : inFactory-TH ID        : 181
Channel   : 2            Battery   : 1             Temperature: 27.50 C      Humidity  : 34 %          Integrity : CRC
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2024-07-08T19:01:31
model     : Ambientweather-F007TH                  House Code: 8
Channel   : 6            Battery   : 1             Temperature: 23.3 C       Humidity  : 61 %          Integrity : CRC
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2024-07-08T19:01:34
model     : Nexus-TH     House Code: 72
Channel   : 1            Battery   : 1             Temperature: 30.30 C      Humidity  : 34 %
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2024-07-08T19:01:37
model     : Ambientweather-F007TH                  House Code: 29
Channel   : 5            Battery   : 1             Temperature: 23.3 C       Humidity  : 65 %          Integrity : CRC
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2024-07-08T19:01:43
model     : Ambientweather-F007TH                  House Code: 243
Channel   : 3            Battery   : 1             Temperature: 27.6 C       Humidity  : 54 %          Integrity : CRC
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2024-07-08T19:01:52
model     : inFactory-TH ID        : 48
Channel   : 3            Battery   : 1             Temperature: 27.22 C      Humidity  : 42 %          Integrity : CRC
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2024-07-08T19:02:09
model     : inFactory-TH ID        : 181
Channel   : 2            Battery   : 1             Temperature: 27.44 C      Humidity  : 34 %          Integrity : CRC

[zuckschwerdt]

The -F kv output has pretty names for things, but it's really just e.g. "id" everywhere. Try -F json to get rid of the pretty names.

[knarrff]

Another idea: some sensors let you choose a "channel", which is essentially like the id, but fixed. However, even when you can, often you only have ~3, and you have you have 6 sensors.

I also have that many sensors. They way I deal with this is: all sensors do use the same channel, except when I needed to change the battery: then I temporarily switch to a different channel for the new sensor. This way I can easily figure out which is "new" is (there can only be one), change it in the scripts, and then change the channel back to normal.

[pswiatki]

Well, I can easily pick up sensors from some of the neighbours. So, channel is not really the ID that could be used. Perhaps when combined with the RSSI, but then again - not always one's own sensors are the strongest.

[knarrff]

Another idea what might work (or not): some sensors send their data after x seconds, over and over again. Only, it is not x seconds exactly for each sensor, but a little after for one and a little slower for another sensor - and that timing is measurable. I can see the "send times" shift with regard to each other on a timescale of hours/days. It would not be a nice solution: depends on sensors - for sure model but possibly also individual sensors, and possibly more difficult: it might depend on battery voltage (not sure - all "my" plots do look straight, but I only need to change batteries every ... 2 years or so). But it would be another, possible "angle" to identify individual sensors.

[knarrff]

Something else I do use especially in noisy environments: my sensors do have a "test" button (inside, next to the battery). It does two things: it sends a signal immediately (which is nice for testing: mine otherwise only send every 50s), but it also sets a bit in the signal that is otherwise unset: which means a bit that should distinguish it from most other signals even in a noisy environment.

[knarrff]

In theory, with not too many sensors, you could even automate this to interpret some "morse code" by pushing that button with a certain timing. I think it might border on over-engineering, but why not. :)

[pswiatki]

Interesting. I am eager to check if I have such buttons (or at least pads on the PCB). Have to open one to see.

[radek-turecki]

Frighteningly complicated proposals to solve the problem(!)

The only reasonably suggestion is to replace the batteries with lithium batteries, but this is an expensive option and also does not completely solve the problem.

In my opinion, there should be a function/parameter in RTL to force/replace any IDx to any other IDy, then all it would take is a command or an entry in the ini file what IDx to be replaced with another IDy, then I would correct only 1 entry instead of making changes in many parameter configurations in the application receiving data from MQTT.

[zuckschwerdt]

Filtering data to match your needs is exactly what the bridge scripts in examples are about. The mechanism is already there.

[radek-turecki]

bridge scripts to mach the data are additional elements in this chain :-( So first I need to call RTl, then parse a text by bridge script and send it again to mqtt. (or maybe I'm wrong).

Thank to implementation such a function into RTL then I would force chane ID and put it directly into MQTT in the one simple command.

[gdt]

@radek-turecki Keep in mind that what you call simple is "somebody else implements and maintains complexity in one big program so it does what I want". I see the bridge script concept as separating concerns into two programs so that each is easier to understand. In a future world where rtl_433_mqtt_relay.py graduates formally from example to installed program (it has already logically graduate as many use it in production), it could be started by a single rtl_433 argument that sort of runs it as a subprocess. Then it being separate is just an implementation detail.

@zuckschwerdt's suggestion to map in the bridge is a great one. The script could take a mapping table and convert the device's generated topic to a logical name. So instead of Acurite-986/1R/12345 one would get temp-freezer in MQTT. You'd then just change the mapping entry after changing batteries. This kind of code is vastly easier to write in python, compared to C. An alternative is to generate your HA config and just rerun the jinja2 program.

[zuckschwerdt]

I've now added a dedup and rename republish MQTT filter example. Works well enough.
https://github.com/merbanan/rtl_433/blob/master/examples/mqtt_filter.py