@kschlichter - have opened an issue on Github. Thanks
I’ve used this a few times now to control the Reds that I have (the older LZW31-SNs at least) and it works well. I have tried it on the following, using the exact same script parameters, with different types of errors:
VZW31-SN:
Executed: December 13, 2024 at 11:49:03 AM
Error: expected int for dictionary value @ data['value']
VZM31-SN:
Executed: December 13, 2024 at 11:52:02 AM
Error: invalid literal for int() with base 10: 'fast_blink'
VZM35-SN:
Looks successful, but nothing happens on the switch itself. I see this in the script steps on an action:
Step Details:
Executed: December 13, 2024 at 11:53:10 AM
Result:
params:
domain: mqtt
service: publish
service_data:
topic: zigbee2mqtt/Office Fan Switch/set
payload:
led_effect:
color: '85'
duration: '10'
effect: fast_blink
level: '220'
target: {}
running_script: false
Step Config:
data:
topic: zigbee2mqtt/{{ states[repeat.item].attributes.friendly_name }}/set
payload: >-
{"led_effect":{"color":"{{ color_set[color] }}","duration":"{{
duration_values[duration] }}","effect":"{{ effects }}","level":"{{
(brightness * 256 / 10) | int }}" }}
action: mqtt.publish
Changed Variables:
repeat:
first: true
index: 1
last: true
item: fan.office_fan_switch
Edit:
This is the basics of what I’m executing, just changing the entity between the various options:
action: script.inovelli_led_script
data:
entity:
- fan.office_fan_switch
duration: 10 Seconds
effect: Blink Fast
brightness: 8.6
color: Green
Hi, thanks for creating this. I’m hoping you can help me figure out an issue. I created a new script (via the blueprint) that seems to end instantly. No matter what I put under duration, it stops instantly and sets the non-effect values. (I’ve been running the script by clicking the ‘run script’ item in the menu for the script.) Should I expect that the effect should trigger for the duration or do I need to run it another way?
@hoyt, I think this is a bug. I hope I can carve out some time to move one of my switches to Z2M and play with it this weekend.
Can you tell me which device you’re using, how it’s connected if it’s a Blue Series (ZHA, Z2M), what the options are that you selected, and then the debug info like in comment 106 above?
Let me know if there’s any data I can provide or test with. Happy to help out because I really appreciate your great work!
Just realized what you wrote conflicts with that I would have expected. I’m using ZHA, not Z2M. I see now that the switch attempted to do a Z2M communication, but I don’t know why.
That’s strange. The script depends on HA to tell it how the device is attached. For me, if I have Z2M running it’ll grab devices by default while the ZHA integration needs to be put into inclusion. Is it possible the device went into pairing and got picked up by Z2M? I’d start with the Z2M dashboard and see if the device is listed there. If not, check that it’s still in ZHA under “Settings” → “Devices” → “Zigbee Home Automation” → “NN devices”.
I don’t even have the Z2M add-on installed.
Here’s the screenshot of the fan.office_fan_switch
device:
I wonder if the “Change device type” integration screws it up?
You have the weirdest problems, @hoyt. Navigate to “developer tools” → “template”, paste this code at the top of that text box on the left and tell me what it gives you. There may be a LOT of blank lines between entities, so be sure you scroll all the way down and give me the full list (delete the blank lines though!).
I think I see the problem in my code. I didn’t have Z2M set up at the time and I can see where I assumed any Blue Series device entities that weren’t in the list of ZHA entities must therefore be integrated through Z2M. That’s flawed logic and an unforced error on my part. My guess is that the entity for your “Switch (Hidden)” option is not showing up in the list of ZHA entities and my script is trying to pass Z2M values to it. It won’t be hard to fix this weekend (finding the time is going to be the difficult part) but in the meantime, I bet if you make it visible again or disable it entirely as I’ve done in the screenshot below instead of just turning off visibility the problem will go away.
{% for ent in integration_entities('zha') %}
{% if ent.split('.')[0] == 'fan' and 'office' in ent %}
{{ ent }}
{% endif %}
{% endfor %}
Disabled entity:
I’m only getting the one entity back with that template:
That item (fan.office_fan_control_fan
) is the VZM36 that’s in the fan canopy, not the switch on the wall.
Exactly what I was hoping you’d say. It isn’t listed in the ZHA entities, so my script is assuming it’s Z2M. It’s an easy fix. In the meantime, unhide it or disable it and your errors should go away.
Ok, I guess that makes sense - the fan.office_fan_switch
isn’t really provided by ZHA, it’s just a pointer to the “real” entity from ZHA? The switch.office_fan_switch
is real though:
So if I execute the script against that entity (or the device?), shouldn’t it find the right section? I tried this both before and after un-hiding the switch
entity:
action: script.inovelli_led_script
data:
entity:
- switch.office_fan_switch
duration: 5 Seconds
effect: Blink Fast
brightness: 9.6
color: Green
When I do that and look at the script trace, it goes from this at the top:
All the way to the bottom without hitting any of the actions:
the
fan.office_fan_switch
isn’t really provided by ZHA, it’s just a pointer to the “real” entity from ZHA?
It’s provided by ZHA but it isn’t reported as being provided because it’s hidden.
I wonder if the “Change device type” integration screws it up?
Yes; that would be a problem. The script is looking for a fan.something
entity on the VZM35-SN. Without that, it’s going to fail.
The script is not working with Zigbee2MQTT 2.0.0. I’ll try to figure that out this weekend.
There’s a new release which is compatible with Zigbee2MQTT 2.0.0. It also has a breaking change for all Blue Series devices—ZHA and Z2M!
*** BREAKING CHANGE ***
If you’re using Blue Series devices this change impacts you. The script was previously setting LED brightness levels colors at the individual LEDs. This overrides the parameter which controls the LED bar as a single, uniform option. I’ve fixed the logic for how this is done, which means LED color and brightness levels only need one service call for each option, instead of eight (one for treating the LED bar as a single unit and one for each of the seven LEDs). This should speed things up but the individual LEDs need to be cleared so they don’t override the single unit setting. In order to do that, call the script (or set up an instance of the blueprint) with these settings:
area:
- all
LEDnumber: All
LEDcolor: All Clear
LEDcolor_off: All Clear
LEDbrightness: 7
LEDbrightness_off: 2
That should set all of your LED bars to red. Once that’s done, your old automations and blueprints should work just fine. This is a one-time issue.
Kevin, my blue series vzm31-sn switches no longer appear in the Devices category of the blueprint (using Z2M). When I try the fix you posted above, using the Entity, it doesn’t change anything. Seems like my blue series switches are stuck on the LED setting from before the Z2M break changes. Any thoughts?
I think I’ve fixed the device selection. Re-import the blueprint and try it again. If you’re still not seeing the devices turn red after running the all clear
send me trace info from comment #106 above.
Hi!
Thanks for putting this together and maintaining it. I’ve recently installed a bunch of Inovelli switches and your blueprint looks like just what I need, but I can’t import it. HA displays this error after clicking import:
Invalid blueprint: extra keys not allowed @ data['blueprint']['input']['LEDbrightness']['example']. Got '6' extra keys not allowed @ data['blueprint']['input']['LEDbrightness_off']['example']. Got '2' extra keys not allowed @ data['blueprint']['input']['LEDcolor']['example']. Got 'Blue' extra keys not allowed @ data['blueprint']['input']['LEDcolor_off']['example']. Got 'Blue' extra keys not allowed @ data['blueprint']['input']['LEDnumber']['example']. Got 'All' extra keys not allowed @ data['blueprint']['input']['area']['example']. Got 'Family Room, 7d7a44fe4d0f4bee947c430d2714e45c' extra keys not allowed @ data['blueprint']['input']['brightness']['example']. Got '8' extra keys not allowed @ data['blueprint']['input']['color']['example']. Got 'Red' extra keys not allowed @ data['blueprint']['input']['device']['example']. Got '0249abdc634c12cbf6cdc06d7a507495' extra keys not allowed @ data['blueprint']['input']['duration']['example']. Got 'Off' extra keys not allowed @ data['blueprint']['input']['effect']['example']. Got 'Pulse' extra keys not allowed @ data['blueprint']['input']['entity']['example']. Got 'light.office, fan.guest_room' extra keys not allowed @ data['blueprint']['input']['floor']['example']. Got 'downstairs,upstairs, outside' extra keys not allowed @ data['blueprint']['input']['group']['example']. Got 'group.lights_and_switches, 0249abdc634c12cbf6cdc06d7a507495'
It looks angry about the ‘example’ key. I’m using HA 2025.1.2
I’ve fixed that and set a new release. Sorry about that. Thanks for using my blueprint!