I’m not in towards a discussion on what is secure or not. This is merely an arbitrary example on what is possible to achieve regarding this demux RF codes topic, using the latest evolutions on automations, since HA 0.113. An all-in-one approach, without messing around with python scripts, with no need to define any binary_sensors/entities in general, much simpler, through straight and plain yaml code.
My 2 cents.
But you literally said it was like a garage door opener and even went as far as to include a picture of one. I’ve simply pointed out you’ve made a misleading a statement.
No need to define any binary_sensors? Well, yeah, your example doesn’t use any so there’s that. However, it does use an “entity” namely alarm_control_panel.home_alarm and I’m quite sure you had to define that.
It doesn’t scale well; with many sensors (try 20) the result is a very long chain of conditions, as opposed to a compact dictionary in a python_script. Plus to get to the 20th condition, it must evaluate the first 19 conditions whereas a key-lookup for a dictionary is fast and efficient.
If you try this technique with a binary_sensor that reports both its on and off states, you need one condition for its on state and another for off state. For ten binary_sensors, that’s twenty conditions. More conditions are needed if the binary_sensor also reports low-battery.
Handling each received code takes about 6 lines of YAML. 10 binary_sensors x 2 codes x 6 lines = 120 lines of “straight and plain”, and lengthy, YAML.
I’m using RF door sensors, and as mentioned, with multiple states (open, closed, battery), the code to check states becomes lengthy.
The sensors I use transmit a unique ID for each, with a single character state code appended to the end of the ID string.
To overcome the need for lengthy code, my automation takes the unique ID and publishes an MQTT message to the homeassistant topic with the device ID set to the unique ID of the door sensor, as well as fields for device class, etc. If you have auto configuration set up for mqtt on homeassistant, it reads the MQTT and creates binary sensors corresponding to each door sensor.
A second automation publishes the state of the sensor to MQTT, again under the unique ID, which homeassistant uses to update the state of the corresponding binary sensor.
Both automations are triggered by homeassistant receiving data from the rfbridge result topic, and have some conditions to filter the signal for length and structure so it’s not firing all the time. I also keep the create automation disabled except when I am setting up a new sensor since it seems there is lots of RF noise that even with filters results in the creation of random devices.
I hope this is clear enough to understand - it’s been a while since I wrote the automations and I’m working from memory which is a little fuzzy. Let me know if anyone wants details.
LOL. I have been tearing my hair out trying to figure out why half of my sensors worked, but not the other half. It was exactly this problem. I just couldn’t see it.
Thanks for a great tutorial. Works like a charm on my 5 water sensors, and 6 door sensors.
I would be interested in seeing this. My door sensors end with A for open, and E for closed, with the first five characters the ID, like yours. I have not yet figured out the battery info yet, though.
I wrote it all down here:
https://community.home-assistant.io/t/auto-setup-of-433-mhz-door-motion-sensors
Including the yaml for the automations. Hope it’s useful.
Battery, I think, ends with 6, although I’ve never had a battery fail yet and it’s hard to simulate.
This approach has been working well for several weeks. However, i recently added a couple more sensors, and now nothing works. The addition may be unrelated. The RF bridge still registers all the codes, according to the console. The only changes to HA were the added codes to demux, and the added entities to the configuration.yaml. VS editor does not show any errors. There is nothing about it in the log. The RF bridge still show up on HA, and in mosquito.
Any suggestions on deeper debugging?
Undo the changes.
Yeah, I tried that. But I cannot be sure that there wasn’t a missed keystroke somewhere else. AFAIK, there are no saved edits to retrieve (using Visual Studio Code).
EDIT: Staring at it some more, and found the problem. I ‘fat-fingered’ an erron in the python script—if that is possible from a keyboard. I fixed it, and it works again.
Thanks for paying attention. Sometimes that is all one needs.
been using this python script to receive data from a tasmotized sonoff RF for some door sensors (with retain flag on) and 433 wall remotes (retain flag off).
However, everytime Home Assistant restarts, 4 of the door sensor states will be stuck to ON even though it wasn’t ON before the restart. Anyone having the same problem? It only happens to some sensors even though they’re all the same Kerui door sensor configured exactly the same. The other 7 sensors are retaining the correct values as per before the restart.
It happens every restart and I have to manually open/close the door or set state via HA Developer Tools so it shows the correct state on frontend. Driving me nuts!
Any help is appreciated!
Hi all, I have been using this script for months without problems.
Now, after upgrading to Python 3.9, when the script is called i receive in the log file the error Error executing script. Unexpected error for call_service at pos 2: Unknown slice type: <ast.Name object at 0x9a548460>
I isolated that the error is produced by the row:
service_data = {'topic':'home/{}'.format(d[p][0]), 'payload':'{}'.format(d[p][1]), 'qos':0, 'retain':'{}'.format(d[p][2])}
Any idea?
Thank you in advance!
also stopped working for me. I pressume it’s related to the new “native” templating as it warns of potential mqtt breakages
The problem is related to the extraction of an object from a list.
This code generates the same error:
my_list = ['p', 'r', 'o', 'b', 'e']
logger.warning('<<< first element: {} >>>'.format(my_list[0]))
The logged error is always:
raise NotImplementedError("Unknown slice type: {0}".format(slice_))
NotImplementedError: Unknown slice type: <ast.Constant object at 0x979a1a60>
I tried
logger.warning('<<< first element: {} >>>'.format(my_list[0:1]))
and the result is 1) no error but 2) the element is extracted as a list, i.e. as follows:
['p']
Which is not what we need.
Any idea?
my_list = ['p', 'r', 'o', 'b', 'e']
logger.warning('<<< first element: {} >>>'.format(my_list[0]))
Your example contains valid python code. The fact it generates an error in 0.117 implies there may be a problem with the python_script integration.
I have 116.4 and Python 3.9
Then it must be python 3.9 (which is included in Home Assistant 0.117 no, it’s not, it’s 3.8.6) that causes the issue. I don’t have access to version 3.9, but your example works in 3.6.
I found a solution:
service_data = {'topic':'home/{}'.format(str(d.get(p)[0:1])[2:-2]), 'payload':'{}'.format(str(d.get(p)[1:2])[2:-2]), 'qos':0, 'retain':'{}'.format(str(d.get(p)[2:3])[2:-2])}
Not the best but… it’s working.
Ciao!
Something is terribly wrong if we can no longer do this:
'home/{}'.format(d[p][0])
^^^^^^^
and now must do this:
'home/{}'.format(str(d.get(p)[0:1])[2:-2])
^^^^^^^^^^^^^^^^^^^^^^^^
Based on the error message, it seems like it interprets d[p][0] as an attempt to slice a string as opposed to accessing items in a list.
This is a huge disappointment. I’ll not be upgrading to 117 until a solution is found. This strategy has made such a difference to my system.
Sadly, I don’t have the skills to contribute.
I also had the same problem with 116.4. I rather think the issue is related to Python 3.9.