That seems unlikely. If they did, wouldn’t they have to re-pair or sync with whatever they are expected to send data to normally? Then again, this line specifically mentions an ID changing on each power up:
Even if the entity ID does change when swapping batteries, you should be able to rename the entity ID in Home Assistant back to whatever it was.
Yes, I can change the sensor ID for any cards or sequences that I have. I assume you would lose any history with the old version. The history is nice to have to see when the freezer went up in temp and how long it takes to get back, especially with new items - useful for family education about leaving doors open.
However, I have noticed it has randomly created new sensors and then gone back to the original. The new sensors get one or two blocks of data and then go off-line. I am guessing that there has been some data corruption/interference so it sees this as a new sensor and then when it gets clean data it goes back to the original.
Makes sense. In that case, I’d only run the autodiscovery addon as needed, and instead of getting new partial data and entities, you’ll simply have gaps in readings.
Luckily I am not picking up lots of neighbourhood sensors, so I can leave it running for now. It’s easy enough to delete the occasional doppelgänger that shows up.
If it annoys me too much I’ll put the Sonoff sensors (Zigbee) back in the fridge and work out a better battery arrangement for them.
I previously had to add this
"power0_W": {
"device_type": "sensor",
"object_suffix": "watts",
"config": {
"device_class": "power",
"name": "Power",
"unit_of_measurement": "W",
"value_template": "{{ value|float }}"
}
}
To the
rtl_433_mqtt_hass.py
File to get power from my currentcost devices into home assistant, however since the latest update this no longer works and I can’t find this file so I can make the same changes.
How do I get power data from current cost devices into home assistant in the latest update ?
You can always create the discovery topic by hand by following the docs at MQTT Discovery - Home Assistant. I did this before the discovery script supported doorbells.
In the long term, if you file a pull request against rtl_433/rtl_433_mqtt_hass.py at 45e8fc54b32ce9daf70e967b4fb396e86f9fde24 · merbanan/rtl_433 · GitHub upstream, we can either patch it in or it will come in once it’s merged there.
I’m guessing it remains true that you can’t use a single SDR dongle to handle devices on different frequencies?
If that is true, is there documentation for using multiple radios with rtl_433?
You’re correct, SDRs can only tune one frequency at a time.
You can use multiple SDRs by creating multiple configuration files and setting device and frequency:
Makes sense, thank you for the reply
Forgive my ignorance on the matter, but is it possible to have a single device with multiple receivers so that i could listen to separate frequencies simultaneously while only occupying one USB slot?
I don’t know of any like that. I’ve found with both of my setups (RPi 4 and a desktop PC motherboard) I needed to use an external hub or extension cable because you can’t fit two radios side by side. I ended up purchasing this USB hub to support my 2 NESDR radios, a zzh! zigbee adapter and an Aeotec Z-Wave adapter. It has lots of space between the ports, and because it’s got it’s own power adapter it’s fine to use a long USB cable to place wherever you want.
So I took your advice and added another SDR into the mix to try and read 2 different frequencies simultaneously. I’m still struggling on the software side to get HA to recognize both radios independently . I’m not fully understanding how the rtl+mqtt plugins expect you to feed them multiple .conf.template files.
My setup is two Nooelec SDR Mini connected via a small USB hub to a raspi4 (all connected via USB3)
Here are a couple images of my file config file structure which is where I think my problems are coming from:
I’ll fully admit that my knowledge of MQTT is very limited and could be playing a huge part in all this. I’ve poked around different tutorials/README’s but I’m still struggling to wrap my brain around how to effectively implement it. So far I’m leaning heavily on auto discovering and things ‘just working’ 
Can you post your two configuration files, as text? Do you have device 0 in your temperature.conf.template file?
Here’s my two configuration files as examples.
weather_station.conf.template:
# This is an empty template for configuring rtl_433. mqtt information will be
# automatically added. Create multiple files ending in '.conf.template' to
# manage multiple rtl_433 radios.
# https://github.com/merbanan/rtl_433/blob/44e893c0105bd04d1b5720f34fd227b5948ecd65/conf/rtl_433.example.conf
device 0
output mqtt://${host}:${port},user=${username},pass=${password},retain=${retain}
report_meta time:iso:tz:local
convert si
And doorbell.conf.template:
# This is an empty template for configuring rtl_433. mqtt information will be
# automatically added. Create multiple files ending in '.conf.template' to
# manage multiple rtl_433 radios.
# https://github.com/merbanan/rtl_433/blob/44e893c0105bd04d1b5720f34fd227b5948ecd65/conf/rtl_433.example.conf
device 1
frequency 916.8M
output mqtt://${host}:${port},user=${username},pass=${password},retain=false
report_meta time:iso:tz:local
Sure thing!
My temperature.conf.template:
# This is an empty template for configuring rtl_433. mqtt information will be
# automatically added. Create multiple files ending in '.conf.template' to
# manage multiple rtl_433 radios, being sure to set the 'device' setting.
# https://github.com/merbanan/rtl_433/blob/44e893c0105bd04d1b5720f34fd227b5948ecd65/conf/rtl_433.example.conf
output mqtt://${host}:${port},user=${username},pass=${password},retain=${retain}
# Uncomment the following line to also enable the default "table" output to the
# addon logs.
# output kv
frequency 433.92M
device 0
protocol 40
and my security.conf.template
# This is an empty template for configuring rtl_433. mqtt information will be
# automatically added. Create multiple files ending in '.conf.template' to
# manage multiple rtl_433 radios, being sure to set the 'device' setting.
# https://github.com/merbanan/rtl_433/blob/44e893c0105bd04d1b5720f34fd227b5948ecd65/conf/rtl_433.example.conf
output mqtt://${host}:${port},user=${username},pass=${password},retain=${retain}
# Uncomment the following line to also enable the default "table" output to the
# addon logs.
# output kv
frequency 345M
device 1
protocol 70
I assumed there’s no harm in specifying the device and frequency in both files?
Is there a right or wrong way to specify the devices, or is it just important that each conf file contain a unique device number?
No, in fact you need to specify a device (otherwise it will try to use the first device it finds, even if it’s already in use), and if it was the same frequency you could just use one radio. The file format is fully documented at rtl_433/rtl_433.example.conf at 44e893c0105bd04d1b5720f34fd227b5948ecd65 · merbanan/rtl_433 · GitHub.
Andrew,
I have followed this thread and trying to do the same as teh_zuul and using two different receivers for two different frequencies without hopping between them on a single receiver. I have attempted to make this work over the past couple of weeks with no success. Any assistance or advice would be greatly appreciated to get the add-on to recognize the separate conf.template files and run each on a different device would be helpful.
Intel machine i7-10700 with 32GB RAM and 500GB USB SSD (running Home Assistant OS from this directly, not in a VM via windows or other OS)
Home Assistant with latest OS, Core, and Supervisor updates
rtl_433 add-on running from rtl_433-hass-addons/rtl_433 at main · pbkhrv/rtl_433-hass-addons · GitHub
I have also made sensors/binary sensors for each of the door/window contacts so that I can include the timestamp, battery_ok, open/close switch, and tamper switch. I have also created binary sensors for the doorbell pushbuttons to differentiate from the normal and secret knocks.
Radio information:
from System Hardware:
1-9.1.3
Subsystem: usb
Device path: /dev/bus/usb/001/009
Attributes:
BUSNUM: ‘001’
DEVNAME: /dev/bus/usb/001/009
DEVNUM: ‘009’
DEVPATH: /devices/pci0000:00/0000:00:14.0/usb1/1-9/1-9.1/1-9.1.3
DEVTYPE: usb_device
DRIVER: usb
ID_BUS: usb
ID_FOR_SEAT: usb-pci-0000_00_14_0-usb-0_9_1_3
ID_MODEL: RTL2838UHIDIR
ID_MODEL_ENC: RTL2838UHIDIR
ID_MODEL_ID: ‘2838’
ID_PATH: pci-0000:00:14.0-usb-0:9.1.3
ID_PATH_TAG: pci-0000_00_14_0-usb-0_9_1_3
ID_REVISION: ‘0100’
ID_SERIAL: Realtek_RTL2838UHIDIR_00000003
ID_SERIAL_SHORT: ‘00000003’
ID_USB_INTERFACES: ‘:ffffff:’
ID_VENDOR: Realtek
ID_VENDOR_ENC: Realtek
ID_VENDOR_ID: 0bda
MAJOR: ‘189’
MINOR: ‘8’
PRODUCT: bda/2838/100
SUBSYSTEM: usb
TAGS: ‘
’
TYPE: 0/0/0
USEC_INITIALIZED: ‘2936877’
1-9.2
Subsystem: usb
Device path: /dev/bus/usb/001/007
Attributes:
BUSNUM: ‘001’
DEVNAME: /dev/bus/usb/001/007
DEVNUM: ‘007’
DEVPATH: /devices/pci0000:00/0000:00:14.0/usb1/1-9/1-9.2
DEVTYPE: usb_device
DRIVER: usb
ID_BUS: usb
ID_FOR_SEAT: usb-pci-0000_00_14_0-usb-0_9_2
ID_MODEL: RTL2838UHIDIR
ID_MODEL_ENC: RTL2838UHIDIR
ID_MODEL_ID: ‘2838’
ID_PATH: pci-0000:00:14.0-usb-0:9.2
ID_PATH_TAG: pci-0000_00_14_0-usb-0_9_2
ID_REVISION: ‘0100’
ID_SERIAL: Realtek_RTL2838UHIDIR_00000002
ID_SERIAL_SHORT: ‘00000002’
ID_USB_INTERFACES: ‘:ffffff:’
ID_VENDOR: Realtek
ID_VENDOR_ENC: Realtek
ID_VENDOR_ID: 0bda
MAJOR: ‘189’
MINOR: ‘6’
PRODUCT: bda/2838/100
SUBSYSTEM: usb
TAGS: ‘’
TYPE: 0/0/0
USEC_INITIALIZED: ‘2575075’
1-9.4
Subsystem: usb
Device path: /dev/bus/usb/001/008
Attributes:
BUSNUM: ‘001’
DEVNAME: /dev/bus/usb/001/008
DEVNUM: ‘008’
DEVPATH: /devices/pci0000:00/0000:00:14.0/usb1/1-9/1-9.4
DEVTYPE: usb_device
DRIVER: usb
ID_BUS: usb
ID_FOR_SEAT: usb-pci-0000_00_14_0-usb-0_9_4
ID_MODEL: RTL2838UHIDIR
ID_MODEL_ENC: RTL2838UHIDIR
ID_MODEL_ID: ‘2838’
ID_PATH: pci-0000:00:14.0-usb-0:9.4
ID_PATH_TAG: pci-0000_00_14_0-usb-0_9_4
ID_REVISION: ‘0100’
ID_SERIAL: Realtek_RTL2838UHIDIR_00000001
ID_SERIAL_SHORT: ‘00000001’
ID_USB_INTERFACES: ‘:ffffff:’
ID_VENDOR: Realtek
ID_VENDOR_ENC: Realtek
ID_VENDOR_ID: 0bda
MAJOR: ‘189’
MINOR: ‘7’
PRODUCT: bda/2838/100
SUBSYSTEM: usb
TAGS: ‘’
TYPE: 0/0/0
USEC_INITIALIZED: ‘2616854’
File
/config/rtl_433/rtl_433.conf.template:
config_file /config/rtl_433/alarm.conf.template
config_file /config/rtl_433/doorbell.conf.template
File
/config/rtl_433/alarm.conf.template
device :00000003
frequency 319.508M
protocol 100
gain 28
convert si
report_meta newmodel
report_meta time:utc
output mqtt://<IPADDRESS>:<PORT>,user=USER,pass=PASS,retain=1,devices=rtl_433/<HOSTNAME>/devices[/model][/subtype][/id],events=rtl_433/<HOSTNAME>/events[/id],states=rtl_433/<HOSTNAME>/states
output json
verbose 1
File
/config/rtl_433/doorbell.conf.template
device :00000002
frequency 916.8M
protocol 116
gain 28
convert si
report_meta newmodel
report_meta time:utc
output mqtt://<IPADDRESS>:<PORT>,user=<USER>,pass=<PASS>,retain=1,devices=rtl_433/<HOSTNAME>/devices[/model][/subtype][/id],events=rtl_433/<HOSTNAME>/events[/id],states=rtl_433/<HOSTNAME>/states
output json
verbose 1
Logs of rtl_433 after starting:
[s6-init] making user provided files available at /var/run/s6/etc…exited 0.
[s6-init] ensuring user provided files have correct perms…exited 0.
[fix-attrs.d] applying ownership & permissions fixes…
[fix-attrs.d] done.
[cont-init.d] executing container initialization scripts…
[cont-init.d] done.
[services.d] starting services
[services.d] done.
[17:14:07] WARNING: rtl_433 now supports automatic configuration and multiple radios. The rtl_433_conf_file option is deprecated. See the documentation for migration instructions.
Starting rtl_433 -c /config/rtl_433/rtl_433.conf.template
rtl_433 version 21.12-51-g2b49b81a branch at 202201311039 inputs file rtl_tcp RTL-SDR
Use -h for usage help and see https://triq.org/ for documentation.
Publishing MQTT data to port
Publishing device info to MQTT topic “rtl_433//devices[/model][/subtype][/id]”.
Publishing events info to MQTT topic “rtl_433//events[/id]”.
Publishing states info to MQTT topic “rtl_433//states”.
New defaults active, use “-Y classic -s 250k” for the old defaults!
Registering protocol [116] “Honeywell ActivLink, Wireless Doorbell (FSK)”
Publishing MQTT data to port
Publishing device info to MQTT topic “rtl_433//devices[/model][/subtype][/id]”.
Publishing events info to MQTT topic “rtl_433//events[/id]”.
Publishing states info to MQTT topic “rtl_433//states”.
Registered 2 out of 212 device decoding protocols
Found 3 device(s)
trying device 1: Realtek, RTL2838UHIDIR, SN: 00000002
Found Rafael Micro R820T tuner
Using device 1: Generic RTL2832U OEM
Exact sample rate is: 1000000.026491 Hz
[R82XX] PLL not locked!
Sample rate set to 1000000 S/s.
Bit detection level set to 0.0 (Auto).
Tuner gain set to 28.000000 dB.
Reading samples in async mode…
Tuned to 319.508MHz.
Allocating 15 zero-copy buffers
MQTT Connected…
MQTT Connected…
baseband_demod_FM: low pass filter for 1000000 Hz at cutoff 100000 Hz, 10.0 us
MQTT Connection established.
MQTT Connection established.
After this I begin to see the JSON messages and can also see MQTT messages using MQTT Explorer.
Sorry for the long post but hopefully the details help give sufficient information needed to advise on this.
Best regards,
Bill
I think this is part of your problem. You shouldn’t need this file at all! Actually, I wasn’t even aware of the config_file option. One rtl_433 process is started per conf.template file, which means you’d get three processes running, with one of them trying to use the conflicting configs in your alarm and doorbell files.
Your device lines are different than mine, but I think that’s hardware dependent so it’s likely fine.
I’d start by removing or renaming the file to rtl_433.conf.template.disabled, and see if that gets your two configs working.
I deleted the rtl_433.conf.template file (since it was only two lines and have saved elsewhere), went into the configuration tab of add-on and cleared the options for location of rtl_433 conf file. I then restarted the add-on and now seeing [alarm] and [doorbell] at the beginning of each line in the logs now, so appears to be working now but will have to wait until later on to test the doorbell and confirm everything is working as expected.
As far as the device lines, looking at the example file, I had seen that using device :<SERIALNUMBER> was an option to specify which receiver to use. I will be certain to post an update once I am able to test things out. I will also follow up and provide some config file info so that I can share what I learned with others.
I’m working with some interlogix door sensors and trying to get them to auto-discover. Im using a norelec stick like many here.
I know I had auto-discover working at 433M at least since some TPMS sensors popped up no problem when I forgot to add any sort of configuration rtl_433.
I added my config to modify frequency to 319.5 and can see the messages coming in the logs of the rtl_433 addon. I’m able to use the mqtt configuration screen to see the messages getting in to mqtt below:
Message 220 received on rtl_433/events/23f6f8 at 10:52 AM:
{
"time": "2022-04-12 17:52:41",
"model": "Interlogix-Security",
"subtype": "unknown",
"id": "23f6f8",
"battery_ok": 1,
"switch1": "OPEN",
"switch2": "CLOSED",
"switch3": "CLOSED",
"switch4": "CLOSED",
"switch5": "CLOSED",
"raw_message": "0400a0"
}
QoS: 0 - Retain: false
I note that some of the sensors say unknown and some say contact for subtype.
None of them appear to be auto discovering. I was thinking it should be working since at least battery_ok is being recieved by the mqtt addon right?
What am I missing? The auto-discover addon is showing that it’s found the addon and subscribing.
I see no mention of switch# starting at rtl_433/rtl_433_mqtt_hass.py at 3428b8a95c0eeee7e4fe2a212dc6814e05d2be44 · merbanan/rtl_433 · GitHub so I don’t think it’s supported by the autodiscovery script yet.
A good first step would be to follow the docs at MQTT Sensor - Home Assistant getting it set up manually. While the payload says switch, if it’s a door sensor it should be a sensor in HA. Once that’s working, if you have the skills filing a PR upstream would be next.