Inovelli Z-Wave Red Series Notification LED

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:

zwave_integration: zwave_js
model: dimmer
color: '0'
level: '4'
duration: '0'
effect: '0'
node_id: 'None'
parameter: '16'
value: '0'

This was working for me on the old zwave integration with an earlier version of the script. :slight_smile:

After some more testing, I’ve learned that calling this service does not clear the effect:

service: zwave_js.bulk_set_partial_config_parameters
target:
  entity_id: light.test_light
data:
  parameter: '16'
  value: 0

… 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.

Here it is in case it helps others: Worked around issue preventing effect from clearing in zwave_js when setting effect type to 'Off'. · GitHub

1 Like

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:

service: zwave_js.bulk_set_partial_config_parameters
target:
  entity_id: light.red_series_dimmer
data:
  parameter: '16'
  value: '16714410'
1 Like

I don’t recall how we started using the zero, but I can tell you that it worked with previous Zwave integrations that I have used.

Thank you for resolving this! I noticed my effect wasn’t clearing, but I hadn’t had a chance to troubleshoot it yet.

Updated code below:

3 Likes

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.

Anyone have any tips on how that might be done?

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:

  1. Any of the alert booleans changing state, unless you’re okay just waiting for its turn in the cycle to come up.
  2. 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.

I got around to implementing the device_id() feature released in 2021.8.0. This allows us to do the following exciting things now.

  1. Auto-detect which integration is likely in use Z-Wave JS, Z-Wave, OpenZWave (ozw)!
  2. Reliably extract the model name from the parent device of the light switch!
  3. Auto-determine which model type is being used!

No longer should you have to manually set the zwave_integration variable or pass the model type variable in the script call!

1 Like

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.

What are your thoughts?


11,539 Z-Wave installations

Integration Installations Percent
Z-Wave JS 10,212 88.5%
Z-Wave (deprecated) 1,025 8.9%
OpenZWave (deprecated) 302 2.6%
Total 11,539

Oops my bad, that’s weird, I deleted my post to avoid confusion!

Not sure why I keep getting this when I copy your link:
image

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.

2 Likes

Okay, I’m sure I’m missing something obvious, but how do I add this to my HA?

An up to date version of the inovelli_led script can always be found at this link in my GitHub repository.

I’ve got that, but when I try to copy it into my scripts file or into the script editor, it generates errors and I can’t save.

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.

homeassistant:
  script ui-script: !include scripts.yaml
  script: !include_dir_named scripts

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.

You could make it a blueprint script @BrianHanifin.

Allows for either script or automation.

1 Like
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.

Updated script

Blueprint script

Z-Wave JS only!

1 Like

That got it, thanks!

1 Like

@BrianHanifin I’ve been following your scripts for years, I love them. QQ: why no white colour option?

1 Like

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.

If you look at the Inovelli Switch Toolbox by nathanficus and the spreadsheet provided by Inovelli, you will see that there is no white color option.

Weird. It works as an option in the zwave mqtt integration.

I’m able to set effects and the dimmer LED to white on switches, dimmers, and fan / light combos through the ZWave to MQTT integration. White was added to the firmware recently, but I don’t remember what the minimum requirements are. My dimmers are running firmware 1.61 / 1.45 for reference. Feel free to use what I’ve done, if it helps. It was originally based on your work anyway, Brian. That Inovelli calculator has always been somewhat incomplete, since it doesn’t account for the effects switches don’t have.