My script is working again (and so is my UNRAID server after my old SSD failed and took Home Assistant offline for several days). I’m guessing a Z-Wave JS update fixed something in the meantime. Here are the changes:
March 26, 2021
Added fields to help users experimenting in the Services Developer Tool.
Just need to think of how to add multiple conditions for the LED indicator based on the state of various locks. Node-Red is great for stuff like this but I’m trying to stay away.
I too was unable to get “Off” to work when using this with ZWave JS. I have the same problem mentioned above - I can set new effects, but never remove an effect. I am using a LZW31-SN dimmer with the latest version of the script from April.
I enabled the debug logging that’s in the script and this is what appears:
… however calling this service does turn the effect off:
service: zwave_js.set_config_parameter
target:
entity_id: light.test_light
data:
parameter: LED Effect Type
value: '0'
Using that information, I’ve worked-around this issue by updating my copy of the script to call set_config_parameter in the spot that is intended to clear the previous effect for zwave_js.
Yeah, I am not sure why it sets it as value: ‘0’
What I am doing is just just using a value obtained from the Inovelli Switch Toolbox to set the manual command for off:
So i found this script the other day and its really useful, thank you for that! I havent completely reverse engineered it, so this is a lazy question, but what are the possibilities for creating a list of effects to ‘loop’ through?
I imagine its outside of the scope of this script, but that this script could be integral in creating that effect. for example, lets say i turn all leds to pulse yellow when my garage is open, or pulse orange when the front door is unlocked for longer than 5 minutes, or to pulse red if the front or back door was left open. I think it would be neat to have a script that continually rotates through existing ‘alerts’ every 10 seconds or so.
There’s probably a better way, but I would use one automation to set an input_boolean ‘on’ or ‘off’ for each of the alerts you want to cycle through, and then use a second automation to call the effects script and set an input_select to track where you’re at in the cycle.
The triggers for the second script would need to be:
Any of the alert booleans changing state, unless you’re okay just waiting for its turn in the cycle to come up.
A time pattern. Every 10s, or 1s, or however long you want each alert to display.
A condition that at least one of them is ‘on’.
The action would be a series of nested if / elif statements or a choose. I’d start with looking at the trigger to see if an input_boolean changed so you can jump to its position in the loop then, if the time pattern triggered it, looking at where you’re at in the cycle and testing what the next active boolean is, setting the input_select to that option and finally calling the script with the “color” of that alert.
It seems like a lot of flashing lights for me, personally, but I think it’s possible to do.
According to the current Z-Wave integration counts (from Home Assistant Analytics) there are 11,539 total Z-Wave integrations in use. Of those 11.5% of those integrations are using one of the two deprecated integrations.
At some point Home Assistant is likely to remove support for both the OpenZWave and Z-Wave integrations. Which leads me to consider removing all of the extra code that deals with those two integrations.
Someone shared an Automation Blueprint they made in this discussion. Apparently Home Assistant likes that. That reminds me Script Blueprints were added recently, I am going to see if I can migrate this script over.
You can paste the entirety of the YAML code into the Home Assistant script editor, as long as you remove the first line ---.
However, it looks like in doing so the YAML code errors occur due to the formatting gets scrambled. For example:
variables:
debug: false
zwave_integration: "{%- if state_attr(entity_id, 'product_name') is string %}\n\
\ zwave\n{%- elif device_attr(device_id(entity_id), \"model\") is string %}\n\
\ zwave_js\n{%- else %}\n ozw\n{%- endif %}\n"
The solution is to store the script store the script manually in a YAML file. For example I can run both the UI generated script code and YAML stored script code side-by-side by using the following trickery.
Storing the above code in your configuration.yaml file would allow you to save my file as is inside of the /scripts directory at the root of your Home Assistant config. You could literally save my file to /scripts/inovelli_led.yaml and it should work.
January 22, 2022 changes:
1. Released this script as a Blueprint script!
2. Added Brightness "level" parameter to fields.
3. Little bit of code cleanup.
I believe this is a limitation of the firmware. Inovelli provided us with a formula to calculate the proper values to send to their devices, and I do not believe white is one of the options available.
