LED Effects with Inovelli Blue and Zigbee2MQTT/Home Assistant

Switches General Discussion
#21

I was not having luck with my new fan switch and discovered that it is showing up as model “Fan controller (VZM35-SN)” without the Inovelli. Adding a line to models around 201 resolved my issue. Not sure why mine is showing up differently. Currently running Z2M 1.33.1-dev

#22

Interesting, if the models values were stripped down to just the model number the filter should work the same. Can you test that for me?

  models:
    - VZM31-SN
    - VZM35-SN
#23

This means you are using the contributed convertor instead of the external convertor and the maintainer of z2m requested the name of the device be changed, removing the Inovelli portion from the name.

1 Like
#24

Looks great! Is there something like this to control LED notifications for the Z-Wave Red 800 LR switches?

#25

Can you say more about the external converter? I run Z2M in its own docker and the latest tag didn’t have the VZM35-SN yet so I had to use the dev tag. I actually just got around to converting from ZHA to Z2M so it is very new to me but I love the flexibility of MQTT. I run HAOS in its own proxmox VM and then dockers for node-red, mqtt, z2m, etc.

Thanks

#26

This works!

1 Like
#27
#28

Nice! Thanks for testing. I’ll update the blueprint soon.

1 Like
#29

There was a PR to add the VZM35 to z2m default converters. The z2m repo maintainer renamed the device in the PR. So, since you were using the dev z2m, you were getting the new name and that was making the blueprint have issues. Looks like having the model numbers in the blueprint catches the devices no matter which converter / version you are using.

Update inovelli.ts · Koenkk/zigbee-herdsman-converters@f79948a (github.com)

1 Like
#30

I pushed an update, then another later on to fix the first update.

2023.10.2

Update model filter to only model numbers

  • This fixes the fan switch not working with the latest Zigbee herdsman converters

2023.10.3

Model ID fix

  • Fix changing the model IDs in the last update that broke the script
#31

I just started playing with this. In general it seems to be working, but seems to mess up the LEDs when the switch is used locally. If an automation sets the LEDs and then I turn the switch on or off locally, the LEDs immediately go back to what the automation set instead of representing the on/off state of the switch.

I am using an interval of “indefinitely” which seems to me to be appropriate. I would only expect the behavior I am seeing with an interval of “forever”. Is there some other parameter that I am missing?

Also, Is there a way to query the current LED state of a switch?

TIA

#32

This is how effects work. The effect stays until it times out or it is cleared (or never if you pick “Indefinitely”). To remove the effect, you need to send “Clear” as the effect, or just leave “effect” blank in my script as that sends clear.

#33

Ah. I assumed “clear” was translucent, or something.

Thanks.

#34

I am using “developer tools” to pay with this. If I use “All” for the Led it works. If I choose anything else (“Led 1”, “Led 2”, etc), nothing happens. Should that be working?

TIA

#35

You have to clear all before you can set the individual LEDs.

#36

Okay. Is it possible to have a “Clear” on “All” reset the state of all of the leds back to the default? Doing that command does let me issue new calls to change the state of individual leds, but I am left with a mish-mash of colors from previous calls.

If I go through and individually call “Clear” on each led (“Led 1”, “Led 2”, “Led 3”, etc) then I get back to the default state, but it would be nice if a single call could be used to do that.

Thanks.

#37

Ah, that’s something I haven’t run into.
I have my automations clear the individual LEDs when the status is over.