@vesalius I’ve released the code to support VTM30-SN devices to production. Let me know if you find any issues with it. I don’t have one to test myself.
@Redbluefire color: white should work correctly now in the blueprint update from today.
This is a fantastic Blueprint for Home Assistant! Provided I actually understand how it works 
.
From what I’m seeing, this gives you access to all the LED strip config options of an Inovelli switch that are hard to configure normally.
I use ZHA and Blue switches; got a bunch around the house:
- mmWave
- On-Off
- Ceiling Fan
- Aux (no light)
I tried out one with “Unicorn”, and it has some pink-green-blue colors now.
When I saved the Blueprint, it created a script. Am I supposed to call that script when I want to change the “scene” of the LED strip?
I guess, I have a few questions:
- Am I right in assuming this tool gives you access to settings that are extremely difficult to set manually?
- Are you supposed to run the script when turning on the light entity or only when you wanna change the color values?
- How do you get cool effects? Does this do that too? How? By running the script? I saw some neat LED-strip effects (similar to WLED) on a video by Tom’s Smart Home. That’s how I came to find this Blueprint.
Thank you for using the blueprint. 
When I saved the Blueprint, it created a script. Am I supposed to call that script when I want to change the “scene” of the LED strip?
There are a couple of ways to use the blueprint.
- You can generate a script for each set of devices and parameters, then call the scripts from at automation or the UI.
- You can also save it with the default options and pass parameters to the script in an automation each time you want to change something.
- Am I right in assuming this tool gives you access to settings that are extremely difficult to set manually?
It gives you access to the LED color settings, so you can set the LED bar color, brightness, and effects or do the same for individual LEDs on the device. It won’t let you set things like timeout, default brightness levels for light itself, or the other configuration settings—it’s strictly for the LED bar. In ZHA these are not as easy to set as they are in Zigbee2MQTT or Z-Wave.
- Are you supposed to run the script when turning on the light entity or only when you wanna change the color values?
You only need to run it when you want to change the color of the LEDs. Since you running Blue Series devices, you can set different colors for when the light is on and when the light is off, if that’s something you want to do. You wouldn’t necessarily have to run the script ever again if you want that same behavior forever.
- How do you get cool effects? Does this do that too? How? By running the script? I saw some neat LED-strip effects (similar to WLED) on a video by Tom’s Smart Home. That’s how I came to find this Blueprint.
How to configure the effects is documented in the readme with examples at different points. Just do a search for "effect: " and you should find several.
I tried out one with “Unicorn”, and it has some pink-green-blue colors now.
Before you can change the “Unicorn” color set to a solid color, like the default blue, you’ll need to clear the custom color back to red.
1 Like
Great tips thanks! That clarifies it for me. I’ll see what I can do!
Side note: For me, the light entity controls the brightness of the LED bar because I have all my switches in smart bulb mode.
Thanks for this! I’m having trouble getting it to set Effect Color. The effects are passing but it is only using orange for the Effect Color even when I use other colors. What am I doing wrong?
Can you show me how you’re calling it, which devices you have and, if they’re Blue Series, whether you’re using ZHA or Z2M?
I’m using a Red Series LZW31-SN. I use the below script and then in HA when I open the script I use “Run script” to see if it works.
alias: Purple fast blink
use_blueprint:
path: kschlichter/inovelli_led_blueprint.yaml
input:
device:
- 9451fc663fbf33ff00dd3641596ba011
color: Purple
duration: 10 Seconds
effect: Blink Fast
LEDbrightness: 3
description: ""
It’s a simple mistake. The LEDbrightness parameter is for the LED bar—not for effects. Change it to brightness and you should be okay.
alias: Purple fast blink
use_blueprint:
path: kschlichter/inovelli_led_blueprint.yaml
input:
device:
- 9451fc663fbf33ff00dd3641596ba011
color: Purple
duration: 10 Seconds
effect: Blink Fast
brightness: 3
Ah, thank you!!! Really appreciate your help and awesome blueprint!!
I'm also having trouble with my LZW31-SN. The script "Inovelli LED Red" works perfectly, however "Inovelli LED off" doesn't seem to work at all. I cannot turn the LED bar off (but can through ZW JS UI). In order to make it semi functional, I changed the color to blue - which was working, now that suddenly the color isnt changing either. Odd that it's working one way but not the other.
Any ideas on a cause for this one?
alias: Inovelli LED Red
use_blueprint:
path: kschlichter/inovelli_led_blueprint.yaml
input:
device:
- eb29d138dc74a2631804613e4bdfa5a0
LEDcolor: Red
allowed_domains:
- light
- switch
LEDcolor_off: Red
selector_mode: any
LEDbrightness: 10
LEDbrightness_off: 10
effect: Blink Fast
duration: Forever
color: Red
brightness: 10
description: ""
alias: Inovelli LED off
use_blueprint:
path: kschlichter/inovelli_led_blueprint.yaml
input:
device:
- eb29d138dc74a2631804613e4bdfa5a0
LEDcolor: "Off"
allowed_domains:
- light
- switch
LEDcolor_off: Blue
effect: "Off"
color: "Off"
LEDbrightness_off: 0
LEDbrightness: 0
LEDnumber: All
brightness: 0
duration: "Off"
selector_mode: all
entity:
- light.front_scone
LEDnumber_effect: All
description: ""
2026-05-22 21:42:40.065 INFO Z-WAVE: [Node 138] Value updated: 112-0-13 170 => 0
2026-05-22 21:42:40.338 INFO Z-WAVE: [Node 138] Value updated: 112-0-14 0 => 0
2026-05-22 21:42:40.609 INFO Z-WAVE: [Node 138] Value updated: 112-0-16-2130706432 0 => 0
2026-05-22 21:42:40.870 INFO Z-WAVE: [Node 138] Value updated: 112-0-16-16711680 0 => 0
Is the entity name correct, or should it be light.front_sconce?
Can you run the Inovelli LED off script and send me the trace from Settings -> Automations & scenes -> scripts -> select the script -> vertical ellipsis / three-dot menu -> download trace so I can see what it's doing?
You might want to simplify both scripts to just the LEDcolor and build it back up from there. From my phone it looks like you're doing everything fine but it'll simplify the troubleshooting.
Thanks for the follow-up. I had also reached out to inovelli support on this and I've included their insight. It appears that the parameters for the Red 500 series are different from the current gen?
Would it be possible to include an update for the LZW31-SN? Your blueprint is wonderful and a massive convenience. While Inovelli's suggestion would likely work, that path would make future changes/tweaks much more difficult.
| ### Lance from Inovelli | 3:46 PM (5 hours ago) | ||
|---|---|---|---|
| to me |
|
Sorry those parameters are from the current gen switches, the blueprint you provided is not compatible with the Gen 2 switches.
Your LZW31-SN (Red 500 Series) treats Parameter 13 strictly as a Color Choice (0-255 map where 0 = Red).
The blueprint is attempting to pass Off or 0 to Parameter 13 as if it were an 800 Series or Blue Series device (which support native Off parameters or multi-LED mapping via that channel).
To achieve complete decoupling without the blueprint fighting you, you have you can try this and recommended for stability and simplicity.
Bypass the Blueprint & Use Native Home Assistant Actions (Recommended)
Because you want a simple binary status (Red for dry, Off for wet), you don't need a heavy math calculating blueprint. You can change the parameters directly using the native Z-Wave JS service call.
Instead of calling the blueprint script, use the zwave_js.set_config_parameter action in your automation:
To Turn the LED Red (Soil is Dry): Call the service to change both the On and Off brightness parameters to your desired visibility level (e.g., 5 for 50%), and set the color to Red.
YAML
action: zwave_js.set_config_parameter target: device_id: eb29d138dc74a2631804613e4bdfa5a0 data: parameter: 13 # LED Color value: 0 # 0 = Red - action: zwave_js.set_config_parameter target: device_id: eb29d138dc74a2631804613e4bdfa5a0 data: parameter: 14 # Brightness when Light is On value: 5 - action: zwave_js.set_config_parameter target: device_id: eb29d138dc74a2631804613e4bdfa5a0 data: parameter: 15 # Brightness when Light is Off value: 5
To Turn the LED Completely Off (Soil is OK): Instead of trying to change the color string to "Off", simply tell the switch to drop the LED brightness parameters to 0 (Disabled). This completely blanks the bar regardless of whether the light load itself is on or off.
YAML
action: zwave_js.set_config_parameter target: device_id: eb29d138dc74a2631804613e4bdfa5a0 data: parameter: 14 # Brightness when On value: 0 # 0% / Off - action: zwave_js.set_config_parameter target: device_id: eb29d138dc74a2631804613e4bdfa5a0 data: parameter: 15 # Brightness when Off value: 0 # 0% / Off
Please ensure you adjust both of the YAML examples I placed in to the message
The Red 500 series devices are already supported by my blueprint. I did fix a bug that was preventing brightness_off for all Red 500 Series devices. That works again and, if you update the blueprint to version 2026.05.26 which I posted about 15min ago, you should see that functionality working in your "off" script.
The Red 500 and Red 800 Series devices do support different features. I could have told you that if I'd had the information in the trace I asked for. Inovelli supports different features on each generation of each family of devices, and sometimes they change features between versions. All of that is handled by the blueprint, but that means not everything in the blueprint will work for every device. BrianHanifin has a blueprint that only supports Z-wave JS. It probably doesn't have the extra features that aren't supported by the Red 500s.
Notes on your "Inovelli LED off" script:
- The
LEDcolor_offparameter is not supported on Red 500 series devices. This setting will be ignored for any Red 500 Series devices. - The "off" effect for Red 500 Series devices is the same as "clear effect". Some other devices support an effect called "off" which is different from "clear effect." You could leave out
effect,color,brightness, anddurationto generate the same result. - Since other Inovelli devices support "off" as a valid value for the LED color it's included here and mapped to 'red'. If you don't want to change the color to red, don't pass anything for that parameter.
- Other devices support many more effects. Those are also remapped for the Red 500 Series. Chase fast and blink slow, for example, remap to chase and blink, respectively. It's an attempt to offer a reasonable and standardized experience to users with multiple generations and families of Inovelli devices (like myself).
With the update to Z2M a few days ago, I was finally able to test my ideas for merging Z2M commands into fewer payloads. The results were far better than I had expected!
- Entities running on a Z2M bridge >= 2.11.0 will merge settings into fewer payloads.
- Setting a custom color dictionary with brightness levels used to send 32 payloads across MQTT for each device. It can now be done in two payloads. .
- This should significantly reduce pressure on MQTT brokers and the Z2M network itself, especially for networks with a lot of Inovelli devices setting multiple configurations at once.
- Converting my 66 Inovelli devices from their daytime colors and brightness levels to nighttime settings used to take 90 seconds. It now takes <10 seconds.
- Entities on Z2M < 2.11.0 (or if it can't detect the version) will continue to use the old method.
Thank you for the great Blueprint. Just started using it and have a question?
Background: All switches are Red500 zwave (fan, dimmers, on/off)
I am sure that I am missing something that is documented but I just can’t get the following to work. I would like to set the LED Brightness When On and Off levels without turning off any effects that may be set previously. Can you provide me some guidance on how the 4 effect settings at the bottom of the Blueprint should be set so that I can achieve this (if possible)? Thanks in advance.
Thanks for using the blueprint! When I first started writing this script in 2020 I found that the effects on my Red 500s would clear any time something changed. I decided the default behavior would be to clear the effects, which seemed like a safe way to "fail" if something didn't send valid values for parameters. I'm reluctant to change that behavior and make everyone go update automations that have been working.
I suppose I could add an effect option called "no change" that simply doesn't send anything to the effects. On the current Red 500 firmware I think it resets the clock, even if you don't touch those parameters, so duration becomes unreliable. It might stop the effect entirely though, like it used to do. I'd have to play around with it when I get home next week and see for sure what it does these days. The result is going to be unpredictable and inconsistent across firmware versions and for those with multiple types (Red 500, Red 800, and Blue series). I don't love that but I guess if someone chooses that behavior that's up to them. Let me know if that's something you really want and I can spend some time to characterize the behavior across platforms and see if I can figure out a reasonable solution.
Thanks for the feed back. I am just starting to use your blueprint and effects and I definitely don’t want to cause automation issues for anyone else that has a working system. I ran some testing with manual parameter changes and it appears that the effect timer is stopped for about 3 seconds during a parameter change to the LED lights and then resumes. I set a 30 second effect timer and then sent 4 parameter changes to LED brightness. This caused the total time of the effect to be about 42 seconds. If I send one parameter change the effect is about 33 seconds. I didn’t test minutes, hours and longer so not sure if this issue remains 3 seconds or increases.
I can write my automations for effects to take into account for the possibility that they may be prematurely terminated. Thanks again for all your efforts.
That's much more predictable than it was. I'm going to play around with this a little. I bet I can make it work. I'll let you know.