Inovelli Z-Wave Red Series Notification LED

gregg098 · September 17, 2020, 2:41pm

2 taps on the config button stops notifications as well. If you wanted a longer time on the notification, you could, for example, just require that either the door is locked or someone double taps to clear it. Either way, it gets noticed.

BrianHanifin · September 18, 2020, 6:25am

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

Choose - using the recently added choose: feature a separate call has been created for the Z-wave and OZW versions of the service call.
Variables - using 0.115’s new variables: feature the variables sent each service call only have to be calculated once.
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”.

github.com

brianhanifin/Home-Assistant-Config/blob/39f211043525d41730b59df7517c2ad40db7cfee/scripts/notifications/inovelli_led.yaml

---
# Calculation References:
#   https://nathanfiscus.github.io/inovelli-notification-calc/
#   https://community.inovelli.com/t/home-assistant-2nd-gen-switch-rgb-working/168/62
#   https://docs.google.com/spreadsheets/u/1/d/1SGJrJHCUtz8AzznWL_mLCTJjjr2U0IpltcUkRr7N_6M/edit?usp=sharing
#
# Changes:
#   July 22, 2020: Incorporating changes from Kevin Schlichter.
#   https://github.com/kschlichter/Home-Assistant-Inovelli-Red-Dimmer-Switch
variables:
  # The dimmer's "supported_features" attribute is 33.
  parameter: |
    {%- if state_attr(entity_id,"supported_features")|int == 33 %}
      16
    {%- else %}
      8
    {% endif %}
  color: |
    {%- if color is not number %}
      {{ color|default("Yellow") }}

This file has been truncated. show original

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.

TheMattS · September 18, 2020, 12:10pm

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.

kschlichter · September 18, 2020, 3:55pm

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.

TheMattS · September 18, 2020, 4:08pm

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.

BrianHanifin · September 18, 2020, 10:15pm

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
  data:
    entity_id: light.family_room
    model: dimmer
    color: purple
    duration: 10 seconds
    effect: blink

github.com

brianhanifin/Home-Assistant-Config/blob/e62c82b9ea4315b8810cf5707d872aafbcf17de9/scripts/notifications/inovelli_led.yaml

---
# Calculation References:
#   https://nathanfiscus.github.io/inovelli-notification-calc/
#   https://community.inovelli.com/t/home-assistant-2nd-gen-switch-rgb-working/168/62
#   https://docs.google.com/spreadsheets/u/1/d/1SGJrJHCUtz8AzznWL_mLCTJjjr2U0IpltcUkRr7N_6M/edit?usp=sharing
#
# Changes:
#   July 22, 2020: Incorporating changes from Kevin Schlichter.
#     https://github.com/kschlichter/Home-Assistant-Inovelli-Red-Dimmer-Switch
#
#   September 17, 2020: 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”.
#
#   September 18, 2020: Added "model" parameter with options of dimmer, switch, combo_light, combo_fan. This replaces
#     supported_features as the combo fan/light switch also had the same supported_features value.

This file has been truncated. show original

mang0 · September 24, 2020, 7:16pm

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.

Hurricane · September 26, 2020, 1:22am

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

BrianHanifin · September 26, 2020, 5:39am

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
  data:
   entity_id: light.family_room
   color: pink
   level_on: 10
   level_off: 0

github.com

brianhanifin/Home-Assistant-Config/blob/744ccbfb5129b500c140ee65b3f51ef2d232f90d/scripts/notifications/inovelli_led_set_defaults.yaml

---
variables:
  model: |
    {% if model is string %}
      {{ model }}
    {%- elif state_attr(entity_id, 'product_name') is string %}
      {%- if 'LZW31' in state_attr(entity_id, 'product_name') %}
        dimmer
      {%- elif 'LZW36' in state_attr(entity_id, 'product_name') %}
        combo_light
      {%- else %}
        switch
      {%- endif %}
    {%- else %}
      dimmer
    {%- endif %}
  node_id: '{{ state_attr(entity_id,"node_id") }}'
  parameters:
    dimmer:
      color: 13

This file has been truncated. show original

takissd · October 15, 2020, 3:51am

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!

codeblue11 · October 15, 2020, 4:59am

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.

Set up a scripts folder in your main home Assistant root directory.
Copy your scripts.yaml file and put it in your scripts folder (you don’t need to delete the original).
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.
Add to your configuration.yaml file: script: !include_dir_merge_named scripts
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.

datascope11 · October 22, 2020, 8:51pm

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
or
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!

codeblue11 · October 22, 2020, 9:16pm

It goes in your new scripts folder.

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

datascope11 · October 22, 2020, 9:27pm

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

codeblue11 · October 22, 2020, 9:43pm

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

datascope11 · October 22, 2020, 9:49pm

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.

firstof9 · October 22, 2020, 11:52pm

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

inovelli_led:
  mode: parallel
  (contents from github here)

datascope11 · October 23, 2020, 12:48pm

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

firstof9 · October 23, 2020, 2:01pm

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

datascope11 · October 24, 2020, 8:04pm

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

entity_id: 
  light.upstairs_hall_level
  light.hallway_pot_level
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?
Thanks!