Just updated, looks like the Hold Config option doesn’t work anymore.
Actually, it looks like that option is gone entirely.
Create a new automation and see if you can find the “config_hold” action in the dropdown. If you find it, let me know. Otherwise, I’ll need to remove that
Interesting I am seeing “config_held” as an option. But I also don’t see anything past double on any of my actions.
What firmware are you on? I have 2.18
2.18 as well. As a standard automation it triggers just fine.
triggers:
- domain: mqtt
device_id: 83570d3dc15ce985ca18fadc49d99ada
type: action
subtype: config_held
trigger: device
conditions:
actions: - action: light.turn_on
metadata: {}
data:
transition: 0
rgb_color:
- 255
- 0
- 0
target:
entity_id: light.bulb_kitchen_table
mode: single
Also I see the held action in MQTT Explorer and inside Home Assistant in the device pages MQTT Info.
1 Like
Well, I just figured it out. There wasn’t a trigger set for config_held in the Blueprint when you updated originally this morning. I have added it to my local blueprint and it works as expected.
FWIW I am using EMQX as Mosquito would often give me missing actions on restarts with my Aqara buttons. Also I now have some more actions, looks like I have never triggered the triple and quintuple actions on that switch, and you have to trigger once them for them to show in Home Assistant now.
1 Like
Thank you for testing that! The blueprint at the top is updated to reflect config_held and config_release now.
Hello - I recently upgraded to a Z2M 2.0+ release and after importing the new blueprint, I’m experiencing an issue with the single press config option. Previously, I had a choose under the single click config where if pressed it would do the following. However this is now causing an issue that when I click the config button it immediately turns the light on and then back off.
Single click config example:
- Is today Sun-Thurs and master bedroom display shelf is off, then turn on the display shelf light.
- Is today Fri-Sat and the rock lamp is off, then turn on the rock lamp.
- Are either the display shelf or rock lamp on, then turn off.
I’ve created a workaround to this by utilizing the double click config option, but wondering if anyone know if this is because something was updated in the blueprint to impact this ability or if this is an outcome of how things work in Z2M.
I’ll experiment with this soon, unless you beat me to it. I’ve actually had my switch “local” disabled so my toddler would stop turning the kitchen lights on and off. I can’t help but wonder if you disable local control then use this blueprint to do your actions on single press then it might work as you wanted.
1 Like
Although an option, my preference would be to not disable local control if possible. In the event my server is down, I’d prefer my switches still work minus some of the more advanced options, such as what the config button does. I appreciate you looking into it. Thanks
Hey again, I’m providing three examples of how things are either not working (examples 1 and 2) or are (example 3) and how hopefully it helps narrow down what’s going on:
Example 1: Basement Back Dimmer Switch
Note: Locally, outside the blueprint, I can turn 4 downlights in the front of my basement on/off by pressing the blue 2-in-1 up or down. I can also hold the switch up or down to brighten or dim these 4 lights.
Advanced changes with use of your blueprint:
- If I double press the front dimmer switch up, it’ll turn another 2in1 (Basement back dimmer switch) on if currently off. If off, it’ll turn the back switch on. - Still works
- Holding down the up or down will brighten or decrease brightness on both switches at the same time, if both are turned on. - Still works
- Select the config button to turn a floor lamp on if off, or off if it is currently on. - Not working
Code: Inovelli Blue 2-in-1 Blueprint Example - Front Dimmer Switch - Pastebin.com
Example 2: Basement stairwell light
I just use your blueprint on the blue 2in1 to turn a boolean on or off and run a script which turns the LED red. This ensures that the motion activated light that typically turns off after a short time is left on.
Outcome: Like the light in example 1, the blueprint for the config button quickly turns the boolean on, initates the script making the LED bar a pulsing red color, and then switches the boolean back to off and then changes the color back to the default. Due to this, the motion activated light operates as if this blueprint wasn’t used for the config button and then the stairwell lights turn off automatically with a different automation.
Code: Inovelli Blue 2-in-1 Blueprint Example - Basement Stairwell Dimmer Switch - Pastebin.com
Example 3: Basement back dimmer switch
I use this Blueprint to make use of the config button on it to turn my robot vacuum on or off depending on it’s current status. For some reason this blueprint is working fine still and isn’t causing the robot vacuum to start cleaning and then immediately go back to the dock.
Code: Inovelli Blue 2-in-1 Blueprint Example - Basement Front Dimmer Switch - Pastebin.com
I have configured this to run on a VZM31-SN
Single Click Config = 5000k, 0 Transition, Brightness 100
Double Click Config = 255/0/0, 0 Transition, Brightness 100
3x Click Config = 0/255/0, 0 Transition, Brightness 100
4x Click Config = 0/0/255, 0 Transition, Brightness 100
5x Click Config = colorloop, 0 Transition, Brightness 100
They all work except 4x. Same result on another VZM31-SN
Any ideas?
@jkosharek Woah, sure enough, I just tested 4x config and it didn’t work either. I made a test automation where every action sends me a notification with the trigger ID and config_quadruple doesn’t trigger. I also noticed up_quintuple (5x) doesn’t work either… Turns out those triggers were just missing entirely. I’m about to post an update to the blueprint to fix that.
@ThatTallGuy (sorry I didn’t reply sooner!)
For the first example, Front Dimmer Switch config_single, why not just use a “toggle” action instead of the condition check first?
#snippet from the automation with use_blueprint:
config_single:
- type: toggle # <-- try this ?
device_id: 6f83614cd5c93a36b5b8ee20e6410d4a # I pasted these IDs
entity_id: d2a8c5eb7b1c0136915529b9c57e9c2d # from your example
domain: switch
For Example 2: Basement stairwell light, I can’t help but wonder what the Trace looks like for that, like if the Boolean is getting flipped too quickly causing a second run?
For Example 3, I feel like it’s getting triggered more than once, again. Check the Traces, too.
At this point, I might suggest try to test a simpler script under each trigger to narrow down the issue that @jkosharek just mentioned.
Here’s an example of an overkill test I just did:
alias: 0 TEST Z2M v2.0 - Inovelli 2-in-1 switch + dimmer Scene Controls
description: ""
use_blueprint:
path: starbuck93/z2m-v2-0-inovelli-blue-series-2-in-1-switch-dimmer.yaml
input:
switch: 185302a48f89dc6cd88e339da70045e6
config_single:
- action: notify.notify
metadata: {}
data:
message: it worked
title: "{{ trigger.id }}"
config_double:
- action: notify.notify
metadata: {}
data:
message: it worked
title: "{{ trigger.id }}"
config_triple:
- action: notify.notify
metadata: {}
data:
message: it worked
title: "{{ trigger.id }}"
config_quadruple:
- action: notify.notify
metadata: {}
data:
message: it worked
title: "{{ trigger.id }}"
config_quintuple:
- action: notify.notify
metadata: {}
data:
message: it worked
title: "{{ trigger.id }}"
down_held:
- action: notify.notify
metadata: {}
data:
message: it worked
title: "{{ trigger.id }}"
down_release:
- action: notify.notify
metadata: {}
data:
message: it worked
title: "{{ trigger.id }}"
down_single:
- action: notify.notify
metadata: {}
data:
message: it worked
title: "{{ trigger.id }}"
down_double:
- action: notify.notify
metadata: {}
data:
message: it worked
title: "{{ trigger.id }}"
down_triple:
- action: notify.notify
metadata: {}
data:
message: it worked
title: "{{ trigger.id }}"
down_quadruple:
- action: notify.notify
metadata: {}
data:
message: it worked
title: "{{ trigger.id }}"
config_release:
- action: notify.notify
metadata: {}
data:
message: it worked
title: "{{ trigger.id }}"
config_held:
- action: notify.notify
metadata: {}
data:
message: it worked
title: "{{ trigger.id }}"
up_quintuple:
- action: notify.notify
metadata: {}
data:
message: it worked
title: "{{ trigger.id }}"
up_quadruple:
- action: notify.notify
metadata: {}
data:
message: it worked
title: "{{ trigger.id }}"
up_triple:
- action: notify.notify
metadata: {}
data:
message: it worked
title: "{{ trigger.id }}"
up_double:
- action: notify.notify
metadata: {}
data:
message: it worked
title: "{{ trigger.id }}"
up_single:
- action: notify.notify
metadata: {}
data:
message: it worked
title: "{{ trigger.id }}"
down_quintuple:
- action: notify.notify
metadata: {}
data:
message: it worked
title: "{{ trigger.id }}"
up_held:
- action: notify.notify
metadata: {}
data:
message: it worked
title: "{{ trigger.id }}"
up_release:
- action: notify.notify
metadata: {}
data:
message: it worked
title: "{{ trigger.id }}"
I am seeing the same exact behavior.
@jkosharek re-import the blueprint from the main post, it should be up to date now
1 Like
Nicely done, works great! Any thoughts on the option to add multiple switches to a single automation?
@jkosharek Do you want multiple switches to do the same actions? I only have one switch installed right now (the other one is in a box somewhere). Tell me more about the use case for that?
Yes, several switches in a room that I want the actions to do the same thing.
Do you know of the same blueprint for the red switches ( VZW31-SN)?