Heads up this script won’t work with OZW because the model name is not an attribute on the entity, it’s on the device. I’m not sure if there’s a way to get that data from the script.
Did you just do this recently? I think the recent update to 113 moved the folders around. Now it’s python 3.8 but the /site-packages/ folder is no longer there. Also searching using find / -type d -iname ozw_config doesn’t find anything either…
Anyone know where it got moved so i can add the config there?
It’s docker on top of pi4. The standard install with hassio etc:
pi@raspberrypi:~ $ sudo docker exec -it hassio_supervisor /bin/bash
bash-5.0# ls -lh /usr/local/lib/python3.8/site-packages/python_openzwave/ozw_config/manufacturer_specific.xml
ls: /usr/local/lib/python3.8/site-packages/python_openzwave/ozw_config/manufacturer_specific.xml: No such file or directory
bash-5.0#
I have /usr/local/lib/python3.8/site-packages but i don’t have python_openzwave in there. I remember doing these steps a few versions back, when it was on 3.7 still and it did work.
I just migrated my Z-Wave devices to the new OZW integration. The revisions to the original script required are fairly simple. Change service: zwave.set_config_parameter to service: ozw.set_config_parameter and remark out the size: 4 line (e.g. #size: 4). Oh, and instead of passing an entity_id that begins with zwave., just pass the light. entity instead as OZW doesn’t provide zwave. entities.
Below is my current version of the script, including a couple of ideas from @ kschlichter’s version. However, the Product name is not
Frankly, I’m just guessing now. I don’t have a pi4 I can put hassio on, but instead of ‘find / -type d -iname ozw_config’ try ‘find / -iname manufacturer_specific.xml’ and that might provide a clue. If python_openzwave isn’t in /usr/local/lib/python3.8/site-packages, what is? Maybe it’s named differently in hassio?
So I wanted to try this out… but I’m having trouble getting this to work consistently. In y’all’s experience, is there some sort of timeout feature on this where you can’t call the service more than once in a certain amount of time?
I feel like I can get it to work once for a duration and then when I try to get it to work to test a second time, there’s no response. Any ideas?
There doesn’t seem to be one that I’ve encountered. I haven’t tested rapid updates to a single switch though. For me there’s generally 10 seconds or more before updating the same switch.
That’s interesting. When I test the notification light (i.e. 5 second duration) with the services tab under dev tools, I am unable to replicate 10 seconds after unless I change a variable. Same thing with automations. For instance, if I have the light blink for 5 seconds after, say the door sensor is activated, I’ll wait 5 minutes or so, and try to repeat the process, and it won’t work.
No errors showing up in the logs. Just if I hit “call service” consecutively, nothing happens. I’m using @BrianHanifin’s latest version of the OZW script. I had tried using the one posted on your git, but I kept getting this argument of type 'NoneType is not iterable error when calling the service.
My automation was just a super simple one I created in the UI to test the functionality.
I’ll call the service once and it will work, but unless I change say “green” to “red,” I can’t get it to work a consecutive time after the green stops blinking. It’s really odd.
Kind of a dumb question, I havent worked with scripts much, can I just drop script.inovellie_led.yaml into my config folder and have it show up as a callable service or do I need to add anything to my configuration.yaml? Do i need to restart HA after dropping it in?
It’s not a dumb question. In comment 37 RarelyComplete made one that you can past into the UI editor. To keep it in its own file, I put mine in scripts/inovelli_switch_leds.yaml and then in my configuration.yaml I have the line “script: !include_dir_named scripts” as per https://www.home-assistant.io/docs/configuration/splitting_configuration/
The chase effect should look something like the light bar on the front of Knight Rider, if you’re as old as I am, or the eyes on the Cylon soldiers in the Battlestar Galactica reboot. Play with the Inovelli toolbox (link below) to see it on the LZW31-SN. The LZW30-SN on/off switch only has a single LED, not the LED bar, so the chase effect is invalid. Take a look at my spreadsheet (below). If you send Red, Indefinitely, Chase, 10 to an LZW30-SN I believe it should be interpreted as a fast blink, since that seems to hold the value “2” for effects in the math. Is that what it’s doing for you? You might also try adding “mode: parallel” to your script and automation, in case it’s defaulting to one of the other modes (script modes linked below). That might be why your script isn’t running a second time, but if my understanding is correct, your script (or service call) would also have to still be running which means something else has gone wrong. This doesn’t sound like what’s happening, but it’s worth playing with just to be sure.
If you’re using BrianHanifin’s latest version, I guess you’re on the new OZW beta, which is an added layer of unfamiliarity for me. I haven’t moved to the beta, and I don’t know how that might impact things. Sorry I don’t have an answer, but maybe something here will get you going in the right direction.
Yes, essentially Chase shows up as a fast blink on the LZW30 switches. If I call a “color: green” service, the light will flash green for 10 seconds and then change back to the default color. When I look at my logbook, it looks like it shows the correct on/off sequence.
10:44:54 AM
inovelli_led turned off (Jen)
10:44:54 AM
inovelli_led turned on (Jen)
10:44:54 AM
inovelli_led started (Jen)
I’ve tried adding mode: parallel and also mode: restart in the past with no difference. It will 100% work consecutive times IF I change a variable. So I can call a green flash and then a red flash and then a green flash again with no problems.
Kevin, I was looking at this code again, and I figured out a way we could choose the correct service call depending on the entity_id passed. If an entity_id that beings with zwave. is passed, then use zwave.set_config_parameter. However, if a different entity_id type is passed (e.g. light.family_room) then use ozw.set_config_parameter.
However, ozw.set_config_parameter does not support the size parameter. So, unless that is optional for the zwave.set_config_parameter command you’d have create a second script to call, which uses a - choose: to call both commands (one with a size, and one without). But it is doable.
Oh, and for some reason effect #5 “Pulse” doesn’t seem to work since I switched to OZW.
I added a random colour.
