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.
I suspect you are correct however 3.9 comes bundled with 117.
FYI, the Node-Red solution isn’t affected by the change.
Mine still works without issues or changes after updating.
That makes sense; Node-Red is based on JavaScript, not python (let alone python 3.9).
Yes, of course. I just wanted to remind everyone of an alternative if they don’t want to wait for fixes for python.
Home Assistant 0.117.X doesn’t use python 3.9, it uses python 3.8.6.
According to the releases notes for 0.117, the development team is currently working on ensuring compatibility with 3.9 (but it’s not implemented in 0.117).
We are currently working on ensuring Python 3.9 is fully supported and tested.
So if people are experiencing problems with rfbridge_demux.py in 0.117, it’s unrelated to python 3.9. In fact, version 116.X used python 3.8.5, just one patch release prior to 0.117’s use of 3.8.6.