May be the discovery intervall: 600 sec.? Change it to 6 or so.
Ok, I’ve solved it, I just had this events=rtl_433[/model][/id] in the output line on the rtl_433 config file. I removed it and it works!
1 Like
Hello all, I’m preparing to tag a new release of both addons from the code in the next branch. I’ll likely do that in the next day or two. The most notable improvement is that we now build and publish the Docker containers to GitHub’s container registry. As well, it updates rtl_433 to the latest commit as of February 4th.
Since we’re changing the under-the-hood installation method, you will likely get Image ghcr.io/pbkhrv/rtl_433-hass-addons-rtl_433-amd64:next does not exist for addon_local_rtl433 as an error if you just press the upgrade button from the last releases. Uninstalling and reinstalling both addons fixes it. This matters most of the autodiscovery addon since it’s config UI manages custom MQTT connection info. Sorry for the speed bump, but hopefully we have less and less as we approach a “1.0” release.
See rtl_433/changelog and rtl_433_mqtt_autodiscovery for the individual notes.
1 Like
I too have found out there’s no way to bulk delete at least that I can find. Which stinks because it is up to 1300 before I shut it off.
Issue is, that if I do this, then the devices that are already added stop working as well:(
Ah! It looks like they stop working, but only after HA is restarted. I’ve changed the config to retain topics, and that seems to preserve them correctly after a restart. I’ll clarify in the README for the next release.
1 Like
Thank you!
Hi.
First thank you for all your work so far… 
I have a sandbox installation of Home assistant on a virtual machine. There I reinstalled rtl_433 addon to current version: 0.2.0 without any problem…
Trying to do the same on a Raspberry pi 4 produces errors and fails:
Can’t install ghcr.io/pbkhrv/rtl_433-hass-addons-rtl_433-aarch64:0.2.0: 500 Server Error for http+docker://localhost/v1.41/images/create?tag=0.2.0&fromImage=ghcr.io%2Fpbkhrv%2Frtl_433-hass-addons-rtl_433-aarch64: Internal Server Error (“manifest unknown”)
What seems to be the problem?
I rebooted the pi, I removed custom config file rtl_433.conf.template. I am running out of ideas how to solve this…
Looks like I missed adding aarch64 to the build list. I’ll try to get a new build up tonight.
Thank you very much.
New tags built and out! I don’t have hardware to test on, but hopefully they work for yours.
Thanks for all the work and the quick turnaround on the Raspberry Pi4 fix. Seems to be working in HASS.
1 Like
Hi. I am a HA newbie so may be my question is stupid. I would like to ask, if this add_on is possible to use, for receiving signals from 433MHz remotes, to trigger instant actions. What I have understood from the discussion, it is, that it can receive signals from sensors, and publish them on some periodical base. But what about remotes, and instant reactions? Is it possible?
My goal is to use RF433 remotes to control some ZigBee switches (lights).
Yes, that is absolutely possible, as long as rtl_433 supports the remotes. I have a 918MHz doorbell, that with an HA automation triggers a notification to my phone. However, you may prefer to use ZigBee remotes or buttons instead. Lots are using rtl_433 for motion or door sensors.
Be aware - “instant” is subjective with all of this. Even on the best of days, there’s some additional latency (say, a 10th to a quarter of a second?) putting HA in the middle of things as compared to a simple RF remote and light switch. But, you get automation possibilities and the ability to bridge different systems like you’re trying to do.
1 Like
I’m really struggling with this addon recently. I had it working fine, but then I noticed none of my sensors were updating and upon further inspection the rtl_433.conf file is missing and a new rtl_433.conf.template file is in my config directory, but it’s a generic one with nothing but a mqtt output on it. So now I have to recreate what was working before. Found this out with version 0.1.3 installed.
EDIT: it looks like the 0.1.3 update deleted my config file, which was stored as “/config/rtl_433/rtl_433.conf”
# Remove all rendered configuration files.
rm -f $conf_directory/*.conf
So, I updated to the newest version 0.2.1 and created a new rtl_433.conf.template file, but the addon only starts maybe 1 out of 20 times. I get to here and it just stops.
My config is very simple at the moment as I try to remember how I had it setup before:
verbose 1
frequency 345M
output mqtt://192.168.1.13:1883,user=mqtt,pass=PASSWORD,devices=rtl_433[/id]
convert si
protocol 70
Any thoughts?
Yes, that was added a release back to support multiple radios. I think it may be a good improvement to only remove specific files that were created that have a matching .template file, instead of *.conf. Looks like you got that sorted though!
That error about line 53 with the heredoc rendering is a sign something isn’t right. I can’t seem to replicate it though. Perhaps you could upload it somewhere, in case the forum or copy / paste is changing it?
However, regarding the hang - that is what rtl_433 does when it can’t reach the mqtt server. I’d check that line, or if you’re using the Mosquitto addon you can use the default line that autoconfigures things.
The heredoc warning was resolved by added a blank line at the end of my config file.
I can get mqtt working if I just use the standard output line with no extra options, but I would like to customize them to reduce traffic and get them sorted into specific topics that match my existing setup.
I opened an issue on the merbanan/rtl_433 project and apparently I’m doing everything correctly: https://github.com/merbanan/rtl_433/issues/1995
Could the addon/builds/etc. specifically for this addon be messing with how the rtl_433 project interprets the format strings I added to the end of my mqtt output? I can open an issue on the github if that’s better.
1 Like
I’ve set this up on a RPi 4 with the HA operating system and the flashed Sonoff Bridge. Thanks to all the people maintaining this, because it is way above my skill level.
I have followed all the config advice above and it seems to be working - kind of… It is very patchy and I am not sure what to do to improve the performance.
It seems to take a while for the auto-discovery to work. If I leave things alone for at least 30 minutes, it can see three devices - Acurite fridge (1R) and freezer (2F) sensors and a Nexus temp/humidity sensor. They have been created as sensors by MQTT.
But then it seems to go to sleep and does not recognise the data coming in from 1R and the Nexus device, so nothing is updated. It is still converting the freezer (2F) data.
I can see 1R is triggering the RF Bridge and its raw data is shows up on the Console and the rtl_433 log - it is just not being converted.
The Nexus sensors are also showing up in the Bridge trigger light and console raw data and as raw data in the rtl_433 log… but they just stopped being converted. My config seems the same as other above
I’ve changed batteries in the fridge sensor, with no change, although I can get it to occasionally trigger a conversion if I have it sitting close to the bridge - so it could be another battery change needed (or is there a way to up the Bridge’s sensitivity?). I have noticed after a battery change, that I get a different ID on the sensor - MQTT explorer showed 1R with an ID of 27382 - and then after the battery change it came up as a new sensor with a different ID = 6225.
Any suggestions on keeping it engaged?
OK - I feel dumb.
I had my Bridge sitting not far from the RPi and a Zigbee coordinator etc. On a hunch I moved it to another power point and suddenly the Acurite sensors can’t shut-up. Now if the Nexus sensor would start calling home again that would be nice.
I assume the Acurite sensors have a rolling ID which means every time I change batteries they will come up with a new ID, which means re-doing any cards or automations.
Is there any way to deal with that?
1 Like