Inovelli Z-Wave Red Series Notification LED

There are some massive improvements to my version of this code. Here are the highlights:

  1. Choose - using the recently added choose: feature a separate call has been created for the Z-wave and OZW versions of the service call.
  2. Variables - using 0.115’s new variables: feature the variables sent each service call only have to be calculated once.
  3. Supported Features - I realized that I could probably tell the difference between modules using the “supported_features” attribute of each switch. For example my dimmer’s supported features is “33”.

P.S. I only have a dimmer installed right now. Since I am using OZW while Kevin is using Z-wave it would be difficult for me to merge all of his changes. I do have a fan module and will probably install it in my son’s bedroom… eventually. But it currently is difficult with OZW to detect which module is installed automatically. I aspire to merge our code in some way eventually.

@kschlichter Do your other switches have unique “supported_features” attributes? If they do would you be so kind as to share those with me? It would help me make my script more universal, and closer to feature parity with yours. :slight_smile:

1 Like

Nice work getting this updated!

Unfortunately both the fan and light controls in the combo switch show up as dimmers so they have the same supported_features as the standalone dimmer switch but they don’t have the same parameter (24 for the light, 25 for the fan). There’s no other distinguishing attributes I can see for the devices to help differentiate.

My current 0.114 script uses a map so I can just set the model when calling the script:

{% set models = {
      'dimmer': 16,
      'combo_light': 24,
      'combo_fan': 25,
      'switch': 8

I’m assuming that should translate pretty well in your updated script like the other maps (colors, durations, etc.) so.


Passing the model type to the script seems like a pretty good way to go as long as Inovelli doesn’t change the parameters in a future generation. It’s easy to add to existing automations and should work for both the integrated Z-wave and open Z-wave beta. Hopefully we’ll be able to read the model number in some future release of OZW. I can think of a few other use cases.

1 Like

Agreed. We could probably update it to use the actual model number if we wanted to be sure new models didn’t collide. Just got done updating to 0.115.1 so I’ll see if I can tweak @BrianHanifin’s version and post it later if nobody gets it first.

Update #2: I’ve created a follow-up article on my blog which explains these code improvements section by section.

Update: a half hour after posting I realized what the “Type” parameter was and that I didn’t need it if we are just going to pass a model: combo_fan, so removed it. The model variable is just there to set defaults In fact, the Z-Wave version won’t have to pass anything unless you are specifically targeting the fan light, as it defaults to combo_light for the LZW36.

Here is the latest revision. This adds a “model” parameter which now supports all 4 parameter numbers. Here is an example service call to my dimmer:

- service: script.inovelli_led
    entity_id: light.family_room
    model: dimmer
    color: purple
    duration: 10 seconds
    effect: blink

Thanks for this. Interestingly, after this update, the previous problem of not being able to call this service repeatedly disappeared! It now works for me every time. :slight_smile:

1 Like

thanks for all your work on this! Fantastic stuff! Love this community.

1 Like

I created a separate script which sets the default LED color, as well as the on and off
brightness levels. The following example sets the color to pink, sets the on level to full brightness (10) and the off level to 0 (off).

This uses the techniques shared by @kschlichter. Thank you for the additional contribution Kevin! I decided separating this out into a new script made more sense to my brain.

- service: script.inovelli_led_set_defaults
   entity_id: light.family_room
   color: pink
   level_on: 10
   level_off: 0

thanks for the script! It works great on all my inovelli devices.
Just FYI, the fan/light devices only support also a white color. I used to be able to set it through my smarthings account. Maybe at some point you can add it to your script! :slight_smile:

1 Like

Whew, finally got this set up. It’s a bit confusing as someone who’s somewhat competent in home Assistant but still new.

The issue I had is that I’ve used the UI to set up some scripts that I don’t want to break but it’s all but impossible to have HA look for both a scripts.yaml folder with your UI scripts and your separate inovelli_led.yaml folder. So here’s what I ended up doing after spending a lot of time on it.

  1. Set up a scripts folder in your main home Assistant root directory.
  2. Copy your scripts.yaml file and put it in your scripts folder (you don’t need to delete the original).
  3. Make a inovelli_led.yaml folder and copy the script provided by Brian. Put a name such as inovelli_led: at the beginning of the file.
  4. Add to your configuration.yaml file: script: !include_dir_merge_named scripts
  5. Reload home Assistant and you should see everything in scripts. In the future when you create a script through the UI you will have to copy it from the scripts.yaml file in your root directory to the one in the scripts folder. It will no longer read your original scripts.yaml file.

There’s probably a niftier way to do this using packages but that’s the way that worked for me.


Thanks @codeblue11. Quick question, regarding step 3. This new inovelli_led.yaml folder and it’s scripts from Brian go into the new scripts.yaml folder? Or in a separate folder?
For example,
a) config/scripts/invoelli_led.yaml/inovelli_led.yaml
b) config/inovelli_led.yaml/inovelli_led.yaml

I’m thinking it’s a) based on your instructions, but it’s not entirely clear.
Many thanks!

It goes in your new scripts folder.

In my case that’s: config/scripts/inovelli_led.yaml

1 Like

Thanks for the quick reply. Unfortunately for me, I’m getting an error when checking config.

Invalid config for [script]: [model] is an invalid option for [script]. Check: script->script->variables->model. (See /config/configuration.yaml, line 16).

Thank line in config.yaml seems correct:
script: !include_dir_merge_named scripts

If you have another !include for scripts you need to delete it

Strange. I had the old include commented out. Deleted it, but same error.
Do I need to do anything other than paste Brian’s code in this file?

Edit: It must be something with the pasted data. If I blank out the inovelli_led.yaml file, everything works fine with the include in my config.

Add the following to the top of the file and remove the ---:

  mode: parallel
  (contents from github here)

Wow. Just wow. Can’t believe I missed that piece. 4 months in, noobness will never end.

Based on his repo setup he likely !included'ed the file :wink:

1 Like

Hi all.
I’ve got this script working for single dimmer/switches, but can’t seem to get it to work on multiple at the same time. Probably a noob question and easy answer. For example, when messing around with Dev Tools / Service - this works:

entity_id: light.upstairs_hall_level
color: red
dimmer: "true"
duration: 10 seconds
effect: chase
level: 10

I figured I could create a couple of groups to separate out my dimmers from switches, and ended up with group.inovelli_dimmer and group.inovelli_switch - however calling this in the service as entity_id doesn’t work. So I abandoned that and tried to use multiple entities in the service call and still can’t get it to work. For example, the below service calls don’t work:

entity_id: group.inovelli_dimmer
color: red
dimmer: "true"
duration: 10 seconds
effect: chase
level: 10
color: red
dimmer: "true"
duration: 10 seconds
effect: chase
level: 10

I’ve been trying several combinations of entity_id and entities, with dashes, without dashes etc… Can the script not be used for making multiple Inovelli LED’s do the same thing? Why wouldn’t the grouped dimmers work?

Nope has to be done individually due to node_id lookups.

See previous answer.