I have a potentially dumb question. I read through the config notes and understand how the CLI commands work, but I’m using the add-on.
Is there a glossary of the CLI commands and what they translate to in the rtl.conf file? For example, ‘-f’ is ‘frequency’ in the .conf file.
I also found this tricky when first exploring rtl_433. The docs are in the examples directory at rtl_433/rtl_433.example.conf at 3428b8a95c0eeee7e4fe2a212dc6814e05d2be44 · merbanan/rtl_433 · GitHub.
I found that looking into auto discovery that some of the flags are not mapped out for interlogix door/window contacts. I had to add below into main configuration.yaml file:
- sensor:
- platform: mqtt
name: "name your device here"
state_topic: "rtl_433/<Hostname>/events/<deviceid>"
device_class: "timestamp"
unique_id: "<manuf>-contact-<deviceid>-UTC"
value_template: {{ value_json.time }}
icon: "mdi:clock-in"
device:
identifier: "<deviceid>"
name:
model:
manufacturer:
suggested_area:
- binary_sensor:
- platform: mqtt
name: "name your device here Open Closed"
state_topic: "rtl_433/<Hostname>/events/<deviceid>"
device_class: window
unique_id: "<manuf>-contact-<deviceid>-open-closed"
value_template: {{ value_json.switch1 }}
payload_on: "OPEN"
payload_off: "CLOSED"
icon: "mdi:window-closed"
device:
identifier: "<deviceid>"
name:
model:
manufacturer:
suggested_area:
- platform: mqtt
name: "name your device here Tamper"
state_topic: "rtl_433/<Hostname>/events/<deviceid>"
device_class: window
unique_id: "<manuf>-contact-<deviceid>-tamper"
value_template: {{ value_json.switch3 }}
payload_on: "OPEN"
payload_off: "CLOSED"
icon: "mdi:shield-home"
device:
identifier: "<deviceid>"
name:
model:
manufacturer:
suggested_area:
- platform: mqtt
name: "name your device here Battery OK"
state_topic: "rtl_433/<Hostname>/events/<deviceid>"
device_class: battery
unique_id: "<manuf>-contact-<deviceid>-batt"
value_template: {{ value_json.battery_ok }}
payload_on: "0"
payload_off: "1"
icon: "mdi:battery"
device:
identifier: "<deviceid>"
name:
model:
manufacturer:
suggested_area:
Be sure to use MQTT Explorer to view message traffic and topics.
I was then able to set up dashboards, floor plans, and automation/notifications from there. The benefit of manual addition in config is that we can control what is added into system. This way I am not adding sensors for every car that drives by.
Let me know what you think and how it works out. Would be nice to get auto discovery set up for interlogix door and window contacts.
ah ha. I think I was staring at the computer too long when I set that up, or something.
So these would be the options I would use in the config file?
AlecD,
Correct, in the config files you will use the full names as you highlighted and not the -letter format.
Thanks for the verification!
Would it be possible to get rtl_433 MQTT Auto Discovery to also add the two binary sensors of the Govee water leak detector?
protocol 192 # Govee Water Leak Detector H5054, Door Contact Sensor B5023
I added the leak detected and button binary_sensors manually. The logs of Auto Discovery appear to skip the Govee messages with the “event” tag.
I have been able to run rtl_433 with multiple config files to use two radios on different frequencies, however when I include the output to mqtt within each of these files, I get a connection error/failure as it sees the same client seeing a new connection. When I leave the output to mqtt option active in one of the two config files it works no issue.
I have tried creating a different user and password for each conf file but still does not work.
So I was able to find the issue to MQTT client connection issues above under another thread. If using multiple radios, the device line of the config file must be before the output line:
device :00000002
output mqtt://<IP>:<PORT>,user=<USER>,pass=<PASSWORD>,retain=<RETAIN>
I had mine originally listed this way but in troubleshooting other issues these two lines ended up getting swapped in order (copied and pasted in wrong place) with the output before device. All is well and now receiving updates as desired.
I have Zigbee leak detectors, so I wouldn’t be working on this myself. But if someone does the work upstream in the rtl_433 project, it can be pulled into the addon. Glad you were able to get them added manually - can you post the message you crafted for discovery for the benefit of others?
That makes sense! I imagine it’s using the device number in the client ID. I’ll make a note to call that out specifically in the initial example file that’s created.
It was not a discovery message. I made two binary sensors that listen to two specific MQTT messages.
binary_sensor:
- platform: mqtt
name: water leak sump pit
payload_on: "Water Leak"
off_delay: 60
state_topic: "rtl_433/9b13b3f4-rtl433/devices/Govee-Water/25772/event"
- platform: mqtt
name: water leak sump pit button
payload_on: "Button Press"
off_delay: 60
state_topic: "rtl_433/9b13b3f4-rtl433/devices/Govee-Water/25772/event"
Greetings. I am using the rtl_433 add on without autodiscovery with my outside weather station and it works well with one problem.
The weather station is identified as a Cotech-367959 ID: 211. All the sensors are decoded except for “light_lux” and “uv”. This is a documented problem. One user has managed to decode the sensors by updating rtl_433 to a more recent release.
See Hacking the FT-0310 Weather Station – SH
With an updated build that user managed to get his weather station recognised as a Cotech-367959 ID: 28 and “light_lux” and “uv” are properly decoded.
I am pretty sure he has the same weather station.
I am confused by this as I understood that this add-in is built from the latest release of rtl_433.
Any thoughts?
The latest release was built from Change light_klx to light_lux in Bresser-7in1 (#2061) · merbanan/rtl_433@9eec461 · GitHub (April 28 2022) and there’s only two (unrelated?) commits after: Commits · merbanan/rtl_433 · GitHub
You could try running rtl_433 with output kv added, or check the mqtt broker to see if the data is there?
Looks like it is a problem with rtl_433 not understanding the weather station. Helpfully, the developers are looking at what can be done to improve the implementation.
Thanks for your assistance.
I am having issues starting the rtl_433 add-on… here is the log:
[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.
/tmp/rtl_433_heredoc: line 1: GPRMC: unbound variable
[cmd] /run.sh exited 1
[cont-finish.d] executing container finish scripts...
[cont-finish.d] done.
[s6-finish] waiting for services.
[s6-finish] sending all processes the TERM signal.
this was working last week, never really did anything with it and today I went to setup grafana and noticed I no longer have new data…and now I cannot even start the add-on. I had some issues with the config file getting deleted unless it was named “rtl_433.conf.template” … I deleted some other text files I had with different iterations of config from the /config/rtl_433/ folder and now just have the one in there that is 99% the example file. I tried removing the add-on and reinstalling it but still can’t get it working… any thoughts?
Does GPRMC mean anything to you? Could you post your config?
One possibility is that your editor isn’t adding an EOL character at the end of the file. I’m hoping to handle that case cleanly in the next release: Allow configuration files without blank / EOL characters · Issue #81 · pbkhrv/rtl_433-hass-addons · GitHub
Another thing to test would be to rename your existing file to something like rtl_433.conf.disabled. Restart the addon, and it will create a stock config that should work out of the box. It’d be good to confirm it does for you.
I was hoping the GPRMC meant something to you… it was in the commented out section of the example config file. I am using the file editor add on. I think I got an EOL character error yesterday but added one which solved that issue.
I renamed the config file and then the log stated that it couldn’t find a config file and then exited… the log is identical except instead of the GPRMC line the error is:
cat: can't open '/config/rtl_433/*.conf.template': No such file or directory
I am on 0.2.3
then I started deleting a bunch of stuff from the example config, which is what I started with yesterday
# -K rmc=gpsd,nmea,filter='$GPRMC'" (NMEA GPRMC report)
turns out as long as commented out line 209 from the eample config file is not in the config file the rest of the default example file works unedited
Ah! That’s it. I didn’t realize there were any $ in the example config. On startup, the addon will see $GPRMC and try to replace it just like $user and the other mqtt host variables. This is probably something best handled with documentation improvements. I’ll see what I can do for the next release.
I don’t see a definitive answer in the thread, so apologies for a possible duplicate information. This might need to be put in the ‘official’ README on Github. I was able to setup the plugin to use two frequencies (aka multiple / double frequencies) to scan both the Acurite weather sensor and WH51 soil moisture meter. Here is a section I have added to my rtl_433.conf.template:
hop_interval 90
frequency 915.00M
frequency 433.92M
report_meta time:tz
The hop interval is a time in seconds between the switch. For some reason, you would see hopping in the rtl_433 log on HA right away only if you set it to 5 seconds.
[rtl_433] Tuned to 915.000MHz.
[rtl_433] Allocating 15 zero-copy buffers
[rtl_433] Tuned to 433.920MHz.
[rtl_433] Allocating 15 zero-copy buffers
[rtl_433] Tuned to 915.000MHz.
Other values result in the messages appearing eventually, so it might appear as if the hopping is not working (even though it does). WH51 reports every 70 seconds, so 90 second hop interval makes sure we scan it at least once every hop.
Note that I’ve also added ‘report_meta time:tz’ - I was seeing a lot of these errors in home-assistant.log:
2022-06-29 00:21:21 ERROR (MainThread) [homeassistant.util.logging] Exception in message_received when handling msg on 'rtl_433/9b13b3f4-rtl433/devices/Fineoffset-WH51/0ce86c/time': '2022-06-29 00:21:21'
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/components/mqtt/debug_info.py", line 47, in wrapper
msg_callback(msg)
File "/usr/src/homeassistant/homeassistant/components/mqtt/sensor.py", line 304, in message_received
self.async_write_ha_state()
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 533, in async_write_ha_state
self._async_write_ha_state()
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 571, in _async_write_ha_state
state = self._stringify_state(available)
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 539, in _stringify_state
if (state := self.state) is None:
File "/usr/src/homeassistant/homeassistant/components/sensor/__init__.py", line 398, in state
raise ValueError(
ValueError: Invalid datetime: sensor.fineoffset_wh51_0ce86c_utc provides state '2022-06-29 00:21:21', which is missing timezone information
That’s a known issue upstream at HASS bridge emits incorrectly formatted time · Issue #1904 · merbanan/rtl_433 · GitHub.