(RTL433/MQTT) The same LaCrosse sensor is detected under different IDs

VladStar · February 19, 2026, 6:09pm

Long story short - I am getting tired of dealing with multiple devices detected by MQTT over the time for the same LaCrosse weather sensor and would appreciate some good advice how to resolve it.

Please find the details below.

My HA configuration includes:

SDR USB stick
rtl_433 add-on (link) with the following configuration in rtl_433.conf.template file (showing only important entries):

output json
output mqtt <...> devices=rtl_433/9b13b3f4-rtl433/devices[/type][/model][/subtype][/channel][/id],events=rtl_433/9b13b3f4-rtl433/events,states=rtl_433/9b13b3f4-rtl433/states
protocol 73  # LaCrosse TX141-Bv2, TX141TH-Bv2, TX141-Bv3, TX141W, TX145wsdth, (TFA, ORIA) sensor

rtl433_mqtt_autodiscovery Add-On (link)
HA MQTT Integration (link)

In general, everything works fine, except when the same sensor is discovered under different IDs over the time. Seems to be mostly happening after the HA upgrades or restarts.

So, every time this happens I have to go in, detect and remove old MQTT entries, rename the current one (to make sure my dashboards are not broken). This drives me nuts! Needless to say, that every time I do that, I lose the historical data.

I also have the same issue with a few Acurite fridge sensors:

We can take them out of picture for now, if I learn how to deal with a single LaCrosse sensor, I can perhaps fix them in a similar way.

So, the question is what can I do, to tell it to stop them from multiplying? (and use the existing device IDs, rather then adding/discovering as new)

Thanks!

Didgeridrew · February 19, 2026, 10:58pm

I’m using an OpenMQTTGateway with RTL433, but I have the same problem with a couple Acurite outdoor temperature sensors and some window sensors.

I don’t know if this is any better, but I’ve basically given up on relying on MQTT device discovery for RTL433. I just set up a trigger-based Template Sensor and change the MQTT Trigger’s topic manually whenever necessary. That way, at least, I have a stable entity ID and history is maintained.

mekaneck · February 20, 2026, 5:17am

This is caused because some of the devices discovered by rtl433 don’t have a fixed “ID” and therefore a new one is assigned each time a new connection is made. You can fix this in one of two ways, but since you are using add-ons I’m not sure how much control you have to do either method:

Option 1: Change RTL433 config so that the ‘ID’ is not used at all. If you have the ability to edit the rtl_433.conf file, you can remove [/id] from the output line. The downside is that it removes this from the path for all entities, so if you have multiples of the same device, they will all publish to the same state topic and therefore there’s no way to distinguish one from another. (Edit: and this might not be compatible with the RTL433 autodiscovery addon, but I don’t use it so I don’t know.)

Option 2: Use a wildcard in the state topic that the mqtt sensor listens to. But again, I don’t use the rtl433 auto-discovery add-on so I can’t comment if there is a way to modify how it works. But you can at least edit the HA autodiscovery config payload in your mqtt broker manually as a test. I just don’t know if, or how quickly, the add-on would overwrite it back to what it was. In my manually-configured sensor, I have the following:

mqtt:
  sensor:
    - name: "Food Temperature"
      state_topic: "rtl_433/Maverick-ET73x/+/temperature_1_C"
      # ... rest of config...

The + in the state topic takes the place of the random ID in the path, and so this sensor will listen to all topics that match that path, and so the sensor will reflect the data from the topic that was updated most recently. Again the issue here is that for multiple similar devices, it’s difficult or impossible to separate them. But at least for this option, you pick which entities you want to ignore the ID for, rather than ignoring it for everything that RTL433 discovers.

For a test, you can find your entitiy’s autoconfig payload in mqtt explorer (it would be under homeassistant/domain/someuniqueid/object_id/config) and change the state topic to replace the ID in the path to a +. Keep in mind there is one autoconfig payload for each entity, so if your device has 5 entities you’ll need to find the 5 payloads and change them all.

VladStar · February 20, 2026, 8:53pm

Thank you for the answer, I really appreciate it!

This is the part I don’t understand… entries from rtl433 add-on log:

{"time" : "2026-02-20 12:53:00.810580", "protocol" : 73, "model" : "LaCrosse-TX141THBv2", "id" : 240, "channel" : 0, "battery_ok" : 1, "temperature_C" : 6.300, "humidity" : 99, "test" : "No", "mic" : "CRC", "mod" : "ASK", "freq" : 433.981, "rssi" : -0.190, "snr" : 17.101, "noise" : -17.291}

{"time" : "2026-02-20 13:49:40.822414", "protocol" : 73, "model" : "LaCrosse-TX141THBv2", "id" : 240, "channel" : 0, "battery_ok" : 1, "temperature_C" : 6.800, "humidity" : 99, "test" : "No", "mic" : "CRC", "mod" : "ASK", "freq" : 433.986, "rssi" : -0.198, "snr" : 17.438, "noise" : -17.636}

{"time" : "2026-02-20 15:38:50.808038", "protocol" : 73, "model" : "LaCrosse-TX141THBv2", "id" : 240, "channel" : 0, "battery_ok" : 1, "temperature_C" : 8.600, "humidity" : 99, "test" : "No", "mic" : "CRC", "mod" : "ASK", "freq" : 433.986, "rssi" : -0.254, "snr" : 17.317, "noise" : -17.571}

so, it’s giving me the same “id” every time (until something happens, like HA restart). The end sensor remains untouched.

Does this mean, that the “id=240” was not sent by the device, but (due to missing id from the device) was randomly created after the first packet and cached by rtl433?

Would it be possible and would it help to make it (somehow) “more persistent”, or perhaps increase some timeouts?

I also noticed from the MQTT Explorer, that corresponding end entries (i.e. devices->Lacrosse-TX141THBv2->0>240) sometimes are getting removed and then re-appear. Not sure if this is a glitch or actually happening.

iamjosh · February 20, 2026, 9:55pm

You can set up MQTT sensors manually. This is an example of what I use.

The device sends this:

{"time":"2026-02-20T16:53:38.581220-0500","protocol":42,"model":"Hideki-TS04","id":5,"channel":1,"battery_ok":1,"temperature_F":0.5,"humidity":49,"mic":"CRC","mod":"ASK","freq":433.89482,"rssi":-2.00951,"snr":21.38408,"noise":-23.3936}

In my configuration.yaml file add:

# includes
mqtt:
  sensor: !include mqtt_sensor.yaml
  binary_sensor: !include mqtt_binary_sensor.yaml

Then in the mqtt_sensor.yaml file in the same directory:

################################
#CHEST FREEZER                 #
#Changes IDs on battery change!#
#Changed battery 4/22/25       #
################################
  - name: "Temperature"
    state_topic: "homeassistant/events/Hideki-TS04/5"
    unique_id: chest_freezer_temperature
    qos: 0
    force_update: true
    device_class: temperature
    unit_of_measurement: "°F"
    state_class: measurement
    value_template: |
      {{ value_json.temperature_F }}
    device: {
        model: "Hideki-TS04",
        identifiers: ["3"],
        name: "Chest Freezer Sensor",
        suggested_area: "Garage"
        }   
 
  - name: "Humidity"
    state_topic: "homeassistant/events/Hideki-TS04/5"
    unique_id: chest_freezer_humidity
    device_class: humidity
    qos: 0
    force_update: true
    state_class: measurement
    unit_of_measurement: "%"
    value_template: |
      {{ value_json.humidity }}
    device: {
        model: "Hideki-TS04",
        identifiers: ["3"],
        name: "Chest Freezer Sensor",
        suggested_area: "Garage"
        }

and in the mqtt_binary_sensor.yaml:

#  binary_sensor:
################################
#CHEST FREEZER                 #
#Changes IDs on battery change!#
#Changed battery 4/22/25       #
################################
  - name: "Battery"
    state_topic: "homeassistant/events/Hideki-TS04/5"
    unique_id: chest_freezer_battery
    device_class: battery
    qos: 0
    force_update: true
    payload_on: 0
    payload_off: 1
    value_template: |
      {{ value_json.battery_ok }}
    device: {
        model: "Hideki-TS04",
        identifiers: ["3"],
        name: "Chest Freezer Sensor",
        suggested_area: "Garage"
        }

Changing the topic to the new ID will keep your data history.
Using a device: configuration in the sensors will group the entities together in a device in the MQTT integration, so you’ll see temperature, humidity, and battery status entities in a single device.

mekaneck · February 21, 2026, 1:23am

Yes, it’s created by rtl433 when the device doesn’t provide anything unique. And so when either the sensor is restarted or rtl433 is restarted, rtl433 thinks it is communicating with a new sensor and assigns a new ID.

You can read this issue on GitHub where the rtl433 author explains there is nothing he can do about it, some sensors just weren’t designed to provide a unique identifier.

MQTT payloads are either retained (using the retain flag) or not retained. If they are not retained, when you open MQTT explorer you will not see that information until it is published again by the device that is publishing it. MQTT explorer will then hold it in memory and display it to you while you have the program open, but any other client that connects after it was published would never see it (until it is published again).

Conversely if they are published with the retain flag set, you (or any other client) will be able to see the data as soon as you connect to the broker.

mekaneck · February 21, 2026, 1:36am

Here is the comment in the rtl433 source code for that Lacrosse device:
https://github.com/merbanan/rtl_433/blob/14bba0cc72af5ca06b9cd8e5afb997a25a901102/src/devices/lacrosse_tx141x.c#L62

So based on that, for your Lacrosse device specifically, it is the device that generates the unique ID and it generates a new one upon each power-up.

VladStar · February 21, 2026, 2:46pm

Thanks a lot for the explanations!

To summarize (for those who may come to this topic later), for the devices that don’t have or don’t send their unique ID:

there are two possible workarounds for a single device within the same brand/model/type
there is no workaround for multiple devices of the same brand/model/type (unless you are willing to group them all together into one)

mekaneck · February 21, 2026, 4:20pm

There is a possible workaround if there is something distinguishing about each sensor. For example if you have one sensor in your freezer and one in your fridge, you could set up your state template for the fridge sensor to ignore any value that is less than some threshold, like 24°F. Of course if your freezer turns off and starts warming up, it won’t be possible to distinguish them above that value. Another example is if the sensor provides a signal strength (rssi), and they are noticeably different, you could use that.

But if there’s nothing different between the sensors, then yes you are out of luck completely and stuck with changing IDs in your config to match whenever they are changed by the device or by RTL433. The advice is to buy a better sensor.

VladStar · March 3, 2026, 10:24pm

Fortunately for me, I have two different types of Acurite monitors (986 and 515), where each of them has two sensors, that report via different channels in their path. MQTT Discovery usually detects them as 4 separate devices, but I decided to combine them for each fridge.

My final configuration (from mqtt.yaml):

binary_sensor:
  # Acurite-986 Basement Fridge Sensors (freezer + main camera)
  - name: Basement Fridge Sensor Freezer - Battery Status
    unique_id: "basement_fridge_freezer_sensor_battery"    
    state_topic: rtl_433/9b13b3f4-rtl433/devices/Acurite-986/2F/+/battery_ok
    device_class: battery
    payload_on: 0
    payload_off: 1
    device:
      identifiers: "acurite986_fridge_sensor"
      name: "Basement Fridge Sensor"
      manufacturer: "Acurite"  
      model: "986"
  - name: Basement Fridge Sensor Main Camera  - Battery Status 
    unique_id: "basement_fridge_main_camera_sensor_battery"    
    state_topic: rtl_433/9b13b3f4-rtl433/devices/Acurite-986/1R/+/battery_ok
    device_class: battery
    payload_on: 0
    payload_off: 1
    device:
      identifiers: "acurite986_fridge_sensor"
      name: "Basement Fridge Sensor"
      manufacturer: "Acurite"  
      model: "986"

  # Acurite-515 1st Floor Fridge Sensors (freezer + main camera)
  - name: 1st Floor Fridge Sensor Freezer - Battery Status
    unique_id: "1st_floor_fridge_freezer_sensor_battery"    
    state_topic: rtl_433/9b13b3f4-rtl433/devices/Acurite-515/AF/+/battery_ok
    device_class: battery
    payload_on: 0
    payload_off: 1
    device:
      identifiers: "acurite515_fridge_sensor"
      name: "1st Floor Fridge Sensor"
      manufacturer: "Acurite"  
      model: "515"
  - name: 1st Floor Fridge Sensor Main Camera  - Battery Status 
    unique_id: "1st_floor_fridge_main_camera_sensor_battery"    
    state_topic: rtl_433/9b13b3f4-rtl433/devices/Acurite-515/AR/+/battery_ok
    device_class: battery
    payload_on: 0
    payload_off: 1
    device:
      identifiers: "acurite515_fridge_sensor"
      name: "1st Floor Fridge Sensor"
      manufacturer: "Acurite"  
      model: "515"

sensor:
  # Acurite-986 Basement Fridge Sensors (freezer + main camera)
  - name: Basement Fridge Sensor Freezer - Temperature
    unique_id: "basement_fridge_freezer_sensor_temperature"    
    device_class: temperature
    unit_of_measurement: "°C"
    state_topic: rtl_433/9b13b3f4-rtl433/devices/Acurite-986/2F/+/temperature_C
    value_template: "{{ value }}"
    json_attributes_topic: "rtl_433/9b13b3f4-rtl433/devices/Acurite-986/2F/+/time"
    json_attributes_template: "{{ {'temperature_C':value} | to_json }}"
    device:
      identifiers: "acurite986_fridge_sensor"
      name: "Basement Fridge Sensor"
      manufacturer: "Acurite"  
      model: "986"
  - name: Basement Fridge Sensor Main Camera - Temperature
    unique_id: "basement_fridge_main_camera_sensor_temperature"    
    device_class: temperature
    unit_of_measurement: "°C"
    state_topic: rtl_433/9b13b3f4-rtl433/devices/Acurite-986/1R/+/temperature_C
    value_template: "{{ value }}"
    json_attributes_topic: "rtl_433/9b13b3f4-rtl433/devices/Acurite-986/1R/+/time"
    json_attributes_template: "{{ {'temperature_C':value} | to_json }}"
    device:
      identifiers: "acurite986_fridge_sensor"
      name: "Basement Fridge Sensor"
      manufacturer: "Acurite"  
      model: "986"

  # Acurite-515 1st Floor Fridge Sensors (freezer + main camera)
  - name: 1st Floor Fridge Sensor Freezer - Temperature
    unique_id: "1st_floor_fridge_freezer_sensor_temperature"    
    device_class: temperature
    unit_of_measurement: "°C"
    state_topic: rtl_433/9b13b3f4-rtl433/devices/Acurite-515/AF/+/temperature_C
    value_template: "{{ value }}"
    json_attributes_topic: rtl_433/9b13b3f4-rtl433/devices/Acurite-986/AF/+/time
    json_attributes_template: "{{ {'temperature_C':value} | to_json }}"
    device:
      identifiers: "acurite515_fridge_sensor"
      name: "1st Floor Fridge Sensor"
      manufacturer: "Acurite"  
      model: "515"
  - name: 1st Floor Fridge Sensor Main Camera - Temperature 
    unique_id: "1st_floor_fridge_main_camera_sensor_temperature"    
    device_class: temperature
    unit_of_measurement: "°C"
    state_topic: rtl_433/9b13b3f4-rtl433/devices/Acurite-515/AR/+/temperature_C
    value_template: "{{ value }}"
    json_attributes_topic: rtl_433/9b13b3f4-rtl433/devices/Acurite-986/AR/+/time
    json_attributes_template: "{{ {'temperature_C':value} | to_json }}"
    device:
      identifiers: "acurite515_fridge_sensor"
      name: "1st Floor Fridge Sensor"
      manufacturer: "Acurite"  
      model: "515"

Not sure if I need all those json definitions and value templates, but (after struggling with different combinations), at least it works.

Any suggestion how to simplify this config (if any) would be appreciated.