I removed the devices= (as suggested above) and now MQTT Explorer shows:
Sorry if this should be obvious but how to now create/access devices in HA based on these sensors?
Sorry if this should be obvious but how to now create/access devices in HA based on these sensors?
Autodiscovery is nice to have, but didn’t work first time for me so I just went manual route. Seriously not difficult just to set them up manually once you know the topics.
1 Like
I have auto discovery working, and it defined my nine sensors. Four of them report temperature and humidity correctly and the other five which have a model of Acurite Tower show only unknown as they say there are zero messages. However, if I run MQTT tool and look at the broker. I can see the messages from these sensors coming in. All of the sensors are on a raspberry pi sending the information via MQTT to HA.
My second remaining problem is that I have a second raspberry pi with a few sensors on it and it will only connect to the MQTT broker on HA when the first raspberry pi is not connected. Perhaps this has something to do with unique client IDs but if anybody can help, it would be greatly appreciated.
Not an expert here, but are you using the same MQTT broker credentials for both rpis? Not sure if this would be a problem or not, but sounds like a conflict to me if only one works at a time.
@fenty17 It turns out that problem was that the hostnames of the 2 Raspberry Pis were the same. Changing one, fixed the simultaneous connection issue. I still have the problem that 5 sensors are not showing temperature or humidity in HA (though the MQTT messages have the data).
1 Like
Here is what MQTTtool shows:
The Acurite 609_TXC sensors show temp/humidity in HA , but the Acurite Tower sensors do not.
Hi. Just circling back on this “skipped” dynamic. Any thoughts on how to resolve this? Ty again
Problem with 5 Acurite-tower sensors solved with new(est) version of rtl_433.
The autodiscovery script doesn’t have support for every single device or even every single field - just the most common ones. So the fast solution is to manually configure them as was linked above. Otherwise, if you are comfortable or interested in writing Python code, the autodiscovery script could be improved to support your sensors. That would be done as a pull request in the GitHub - merbanan/rtl_433: Program to decode radio transmissions from devices on the ISM bands (and other frequencies) project.
For me autodiscovery works, but the discovered sensors are not updated anymore. I have an Alecto ws1200 v2 weather station, but it doesn’t update the temperature of the entity. I can see in the log that the temperature en rainfall is updated but it doesn’t update the entity in HA.
I am having a similar problem. I have a dozen or so Acurite sensors that were created via Auto Discovery. I have a Raspberry Pi that is sending the sensor data to HA via MQTT. Several times now, after working for 10 hours or more, the sensors stopped being updated and show unavailable in the dashboard. If I run MQTTTool I can see that the messages are still being received by HA’s MQTT broker. Can anyone diagnose this problem and suggest a fix?
If I restart HA entirely (shutdown and restart the HA Virtualbox instance), the sensors start updating again. This suggests an HA bug. Is this the right place to report it? (However, even after restarting, some sensors do not seem to be updating though I can see the messages are being received by the MQTT broker). The sensors that are not updating say" This entity is no longer being provided by the mqtt integration. If the entity is no longer is use, delete it in settings" ???
@ihf1 thanks, restarting HA solved indeed the problem, now my entities in HA are updating again from mqtt.
1 Like
I am new , likely a dumb question
I am getting an error when I put your suggestion in my configuration.yaml:
Error loading /config/configuration.yaml: while parsing a block mapping
in “/config/configuration.yaml”, line 3, column 1
expected , but found ‘-’
in “/config/configuration.yaml”, line 37, column 1
I think I need to replace the first two lines for your code with the following:
mqtt:
sensor:
However, I then get this error:
Error loading /config/configuration.yaml: invalid key: “{‘value_json.time’: None}”
in “/config/configuration.yaml”, line 43, column 0
Please help 
The auto discovery is great the first time, but as mentioned, when the batteries are replaced, everything breaks.
I am curious as to how different people handle the situation. I have devices and entities that are then associated with automations, templates, and lovelace presentations. One time, I renamed the old device and its entities. Then, I added the new device, then went and renamed it, and then went to each entity, and renamed them. I believe it worked fine. The next time I tried this, all the automations and lovelace and templates did not update (maybe I had a typo?). It was frustrating.
How do you handle this? Do you do an MQTT thing? Do you configure everything within configuration.yaml instead of auto?
I used to rename the entities to something simple (say sensor.weather_station_temperature). However, rtl_433 upstream added a device topic suffix (-T) option which we now support in the next branch. I just switched to it myself last week (which meant one last reset of things). It still requires more configuration than I’m happy with, but is a step forward.
Is there a restriction in using flex decoders in the main conf.template?
I have a decoder which works fine when running standalone rtl_433, and reports like most others.
decoder n=Cotech FT0203/18-3676 Anemometer,m=OOK_MC_ZEROBIT,s=504,l=0,r=972,bits=79,get=id:@0:{24}:%x,get=battery_ok:@24:{4}:[12:1 0:0] (I’ve cut it down to the battery for simplicity’s sake)
But when run with auto discovery, all it wants to pass is a UTC timestamp.
Debug log says:
DEBUG:root:MQTT message: "{\"time\":\"2023-08-29T16:57:19.760619+0100\",\"model\":\"Cotech FT0203/18-3676 Anemometer\",\"count\":1,\"num_rows\":1,\"rows\":[{\"len\":79,\"data\":\"002938c800001dfffe06\",\"id\":10552,\"battery_ok\":\"1\"}],\"codes\":[\"{79}002938c800001dfffe06\"]}"
DEBUG:root:homeassistant/sensor/Cotech_FT0203_18-3676_Anemometer/Cotech_FT0203_18-3676_Anemometer-UTC/config:{"device_class": "timestamp", "name": "Cotech_FT0203_18-3676_Anemometer-UTC", "entity_category": "diagnostic", "enabled_by_default": false, "icon": "mdi:clock-in", "state_topic": "rtl_433/9b13b3f4-rtl433/devices/Cotech_FT0203_18-3676_Anemometer/time", "unique_id": "Cotech_FT0203_18-3676_Anemometer-UTC", "device": {"identifiers": ["Cotech_FT0203_18-3676_Anemometer"], "name": "Cotech_FT0203_18-3676_Anemometer", "model": "Cotech_FT0203_18-3676_Anemometer", "manufacturer": "rtl_433"}}
DEBUG:paho.mqtt.client:Sending PUBLISH (d0, q0, r0, m3), 'b'homeassistant/sensor/Cotech_FT0203_18-3676_Anemometer/Cotech_FT0203_18-3676_Anemometer-UTC/config'', ... (485 bytes)
INFO:root:Published Cotech_FT0203_18-3676_Anemometer: time
INFO:root:Skipped Cotech_FT0203_18-3676_Anemometer: count, num_rows, rows, codes
Do I need to go a little deeper, or either add device support to rtl_433, or auto discovery?
Or are there some flags I need to be sending?
If I’m reading it right, the information is being sent to MQTT.
No, there shouldn’t be: rtl_433/conf/rtl_433.example.conf at 70d84d01e1be87b459f7a10825966f3262b7dd34 · merbanan/rtl_433 · GitHub
I would start with the autodiscovery script given you see the data in MQTT. The Skipped message is telling you what keys it sees that it doesn’t know how to handle. One challenge is that they’re generic enough that they may not have common meanings across all decoders, which makes it more difficult to write support without special-casing specific devices.
New user, things are working on the hardware side and add-ons are loading but I can’t push my conf file (see below - “Failed to stat “/config/rtl_433.conf””); any clue what I could be doing wrong?
Also why this mention (couldn’t find references to it in the documentation):
“The rtl_433_conf_file option is deprecated. See the documentation for migration instructions.”
s6-rc: info: service s6rc-oneshot-runner: starting
s6-rc: info: service s6rc-oneshot-runner successfully started
s6-rc: info: service fix-attrs: starting
s6-rc: info: service fix-attrs successfully started
s6-rc: info: service legacy-cont-init: starting
s6-rc: info: service legacy-cont-init successfully started
s6-rc: info: service legacy-services: starting
s6-rc: info: service legacy-services successfully started
[23:59:07] INFO: The mqtt addon is not available.
[23:59:07] INFO: Manually update the output line in the configuration file with mqtt connection settings, and restart the addon.
[23:59: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.conf
rtl_433 version 22.11 branch at 202211191645 inputs file rtl_tcp RTL-SDR
Use -h for usage help and see https://triq.org/ for documentation.
Failed to stat "/config/rtl_433.conf"
Registered 191 out of 223 device decoding protocols [ 1-4 8 11-12 15-17 19-23 25-26 29-36 38-60 63 67-71 73-100 102-105 108-116 119 121 124-128 130-149 151-161 163-168 170-175 177-197 199 201-215 217-223 ]
Found Fitipower FC0012 tuner
Edit: Ok got it, needed to use the internal Mosquitto broker and the default created conf.template file.
1 Like
I have several Govee H5054 water leak sensors that I would like to bring into Home Assistant. rtl_433 Autodiscovery is seeing the device but only shows the battery status. My guess is that the key of interest is “event” which shows if there is a leak or if the button on the device is pressed. Home Assistant is adding the device but only with the battery_ok status. Could “event” be added as a valid key and would this solve the problem I am seeing?
If it helps, here is what MQTT explorer shows:
