-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support for sensors with state
keys
#2965
Comments
You have filed an issue in the rtl_433 repo. for that, you should be reading rtl_433_mqtt_relay and rtl4_433_mqtt_hass in examples. You may wish to modify them. If a hass addon is not doing what you want, and you don't want to start reading python code here and using your own version, that should be addressed to that addons tracker. |
I set the feedback tag to ask you to convert this into an issue that is about the contents of the rtl_433 repo. (if that's what you want to do vs closing and bringing it up with the addon). |
That looks somewhat like the Honeywell/2GIG/etc. family of security sensors. You probably want to define a binary_sensor based off of contact_open. My advice is not to use autodiscovery but to instead use manual MQTT configuration. There are two many things that autodiscovery doesn't know. Some sensors may use reed_open or alarm for the bit you are interested in, so the decoded state won't match. The autodiscovery script does have definitions for contact_open, reed_open, but they don't seem to get processed. I never tried to figure out why. I like being able to set the device class to door, window, motion, etc. but have it defined as data someplace outside of home assistant's config_json files. There is more I could be doing to monitor availability like Zigbee2MQTT does. I wound up defining all my sensors in a YAML file and then defined a Jinja2 template (same templating as home assistant) for the MQTT configuration. I process about 30 security sensors this way. If I need to update something I usually just need to change the template and run my script.
This is what the template file looks like. It's quick and dirty so it defined everything for 1 sensor in 1 file.
|
Regarding the autodiscovery script in this repo (mqtt_hass), I had a note that for the Honeywell security sensors it was only generating binary_sensors for 'alarm' and 'tamper' fields. As I said above, the autodiscovery script does have definitions for contact_open, reed_open, but they don't seem to get processed. I never tried to figure out why. |
very cool jinja2 stuff. can you post the command line to make a yaml from it (presumably you !include it). do you have to worry about having all mqtt in the same generated file? Also, if you have wisdom about why you chose jinja2 instead of m4, I'd like to hear it. Yes, I know m4 is wicked old school. |
I didn't post the script that runs Jinja2 because was a quick first pass at getting it working. It was good enough for me, but would be a bit embarrassing to post. I will put something together. I have some aspirations at building something to replace the autodiscovery stuff, but I get stuff that works well enough for me and don't get back to it. As far as the code goes, it's one of those 98% scaffolding things. You load all the variables in a dict, and then call jinja2 to process the template. You get a string back and write it to a file. The interesting work is done in 2 lines. The Home Assistant MQTT configuration doesn't have any real interdependencies. I like to have all the config for one sensor (or one integration) in one file. It works well with source code control. It also lets me fall back on old habits--If one sensor (on integration) needs to be disabled Yes, I know m4 from the old days, particularly when I wound up responsible for all the sendmail configs for my company because I was the one that did the internet firewall. For this Jinja2 really makes sense because it is what Home Assistant uses and you have to climb that learning curve for Home Assistant (especially if you don't want to be an appliance operator). So anything I did there would be eaiser for Hass users to pick up. I've also adopted Ansible for configuration management, which uses YAML + Jinja2 templating. Another bonus, if you have a Home Assistant install handy, you have easy access to a sort of REPL for Jinja2 in Developer Tools -> Templates. |
Until I get around to cleaning up my script, see this blog & code I found for something close in terms of using Jinja2 to generate config files:
This looks like an updated version of the Jinja2 tutorial I found a few years back. It was also generating some router config files. Same repo, this looks useful for defining custom Jinja2 functions (filters): This could be useful for simplifying the templates. |
@digitaltopo I am also using manual config, more because I started that way, but I think @rct's approach is wise given the ability to customize. Thanks for the pointers; that helps enough to point me on the right track. Writing a bit of code is fine, but I wasn't sure if there was already a program. My remaining worry is that I'd like (probably) to have some things in regular config and some generated. It seems like HA is not ok with mqtt:/sensor: in one place and in another, unioning the included lists/maps. But that's an HA problem, not an rtl_433 problem. |
@digitaltopo - the script can be run anywhere that Python is installed with the YAML and Jinja2 modules, so windows, Linux, Mac. I think you should be able run it on Home Assistant using Frenck's ssh/web terminal add-on (the community ssh, not the core one). Then you wouldn't have to copy any files over. The add-on's Python doesn't have the Jinja2 module installed by default, but it could be added with If I turn this into a little more of an app, rather than go the add-on route, I'd probably make it an AppDaemon package. AppDaemon has somewhat fallen out of favor as functionality in Home Assistant has increased. But AppDaemon would take care of a bit of the scaffolding and provide a sort of UI. I've got a toy app that subscribes to rtl_433 via MQTT and and publishing some stats to help me track the health of the RF environment. |
It also occurred to me that PyScript (which I haven't used yet) could be another way to integrate something like this. I don't think it is sandboxed from the filesystem. You could define a service in PyScript and then use Home Assistant's developer tools to call it. |
Give me a bit, I'll put what I have up in a scratch repo as a PoC.
Ah, it sounds like you are tripping over Home Assistant's various When I tried to follow Frenck's split config file guidance from a number of years ago I kept banging my head against stuff like that. It used a merged list for sensors.
I gave up on that and just use packages which avoids (most if not all) of the conflicts. This is also from Frenck's split config, but now I just put stuff in a file in integrations and don't use the entitles lists.
I think some of the changes they've made in the past few years that resulted in some legacy config styles (like template sensors) changing which domain things are defined under in which order have improved things. In the past I sometimes needed to stick in some throwaway identifier like |
@gdt @digitaltopo - your interest/questions motivated me to put my script up in a repo as a proof of concept: |
I have several sensors that show up fine on autodiscovery, but unfortunately the primary key used for the sensor is not in the list:
https://github.com/pbkhrv/rtl_433-hass-addons/tree/main/rtl_433_mqtt_autodiscovery#what-sensorsdevices-does-this-script-support
My sensors look like this:
I'd like to request that the
state
key is added to the supported list. Other keys that would be helpful arecontact_open
, andreed_open
, but those are generally redundant ofstate
.I'm not sure how to get these added, or what the best way to do this would be. I'm open to adding these manually as well, but I'm lacking a bit of understanding on how 'discovery' should work here. If I manually add mqtt sensors, do I not need to use autodiscovery (https://github.com/pbkhrv/rtl_433-hass-addons/tree/main/rtl_433_mqtt_autodiscovery#what-do-i-do-if-my-sensor-is-not-supported)?
Thanks for any help on this!
The text was updated successfully, but these errors were encountered: