I’m trying to integrate some zigbee2mqtt buttons/switches into a blueprint. Despite my efforts to read the documentation I’ve come to the conclusion that I can’t define an mqtt device trigger as a user selectable input trigger for a blueprint, despite being able to do this if I create a normal automation - WTH - why is this?
Yes you can. What did you try?
here’s over 50 examples on the forums.
https://community.home-assistant.io/search?q=mqtt%20%23blueprints-exchange
I’m new around here so forgive my ignorance if I’ve mislooked something, but I’m specifically talking about triggers, and not states.
If I create an automation I have the ability to select a device and a trigger on that device look so:
But when creating a blueprint I cannot find the selector that allows me to select the same thing.
That’s a device trigger, don’t use a device trigger, use an MQTT trigger as the trigger. It’s the same thing, but you’re not selecting a device.
You can still use a device trigger if you want to, but you’d have to use a device selector and a select selector.
You’d have to view the device trigger in yaml, and point the device selector’s result to the appropriate filed same with the select selector.
Thanks for your help @petro, I’ve made it work using an MQTT trigger - but I think my WTH still stands - using an MQTT trigger instead of a device trigger makes it a bit harder for the user to use the blueprint, rather than easier.
You can still do it with a device trigger, but you have to know how to blueprint device triggers and understand what !includes do and how to use them.
You can blueprint any trigger in home assistant. You just have to understand the underlying systems. Usually beginners don’t try to touch blueprints before understanding selectors and yaml.
I’m familiar with !includes as I’m already using them in this snippit where I have a selector for the light:
input:
target_light:
name: Lights
description: The lights to control
selector:
target:
entity:
domain: light
action:
- choose:
- conditions:
- condition: trigger
id: "on"
sequence:
- service: light.turn_on
data: {}
target: !input target_light
alias: Turn On
- conditions:
- condition: trigger
id: "off"
sequence:
- service: light.turn_off
data: {}
target: !input target_light
alias: Turn Off
The bit that doesn’t seem to exist in the selector in the blueprint for the mqtt device trigger so that I can use it as the input.
Have you got an example of using the correct selector for an MQTT device trigger?
select selector.
Show me the yaml for your MQTT device trigger and I’ll show you the blueprint yaml.
This expects the author to provide a list of options and the user to select from one of those - would we need to dynamically create the list of options?
Here’s the yaml generated by the Automation UI - it’s the same mqtt device trigger from the previous screenshot:
description: ""
mode: single
trigger:
- platform: device
domain: mqtt
device_id: f0b3aab869996e9790cf777a120a00c6
type: action
subtype: single_left
discovery_id: 0x54ef4410000d0438 action_single_left
Just for clarity, I want the user to be able to use the UI selector to find their device (through the auto-discovery), rather than have the user type in the device_id and ieee number of the zigbee device.
device selector
mqtt_device:
device:
integration: mqtt
manufacturer: ...
model: ...
select selector
mqtt_action:
select:
options:
- single_left
automation trigger
trigger:
- platform: device
domain: mqtt
device_id: !input mqtt_device
type: action
subtype: !input mqtt_action
This doesn’t work - the trigger doesn’t work without the discovery_id line.
If that’s required, then you have add that as a text input.
Thanks for all your help with this but I think this shows why it’s a “WTH”.
The automation UI allows the user to quickly select the device trigger but the blueprint UI doesn’t allow the user to do the same thing.
I understand it’s possible to workaround the issue using some clever techniques as you’ve kindly shown.
My man, you keep defending this WTH like I closed it. It’s still open 
This has been one of the biggest WTH’s since I installed HA. After seeing how handy it is to set them up using blueprints, I ordered a box of four and six button Aqara Opple switches and two Symfony remotes. It took 3 frustrating Sunday’s to learn:
- There’s no convenient way to create a blueprint with prepopulated lists of trigger names for a specific device
- If enabling
homeassistant_legacy_triggersin Z2M config, blueprints “work”, but actions are triggered sluggishly and button presses don’t always register (I assume polling is used)
The switches are still in the box after ~2 years. Of course I could have set them up the tedious way or just use Node-RED like I did for my previous 433Mhz switches these were supposed to replace. But I haven’t done it as one of the selling points of HA to me was the ability to configure basic things like switches using the mobile UI, so that it’s easy to gradually fine tune them in an adhoc manner.
3 Likes
I’ve stumbled on this thread because I’m trying to use device_triggers with zigbee2mqtt. I’m currently using topic with z2m and it works, but having read ( [Home Assistant | Zigbee2MQTT](https://z2m device trigger)) that MQTT device trigger is the recommended way to do it, I tried to create a blue print. However, I can’t find a way to automate (in the blueprint) the creation of discovery_id. Is there any way from blueprint to access that info and put it into a variable?
1 Like
I don’t believe there is a built-in solution to this yet. Recently I ran across this HACS addon that can do this based on it’s own blueprint format: GitHub - Sian-Lee-SA/Home-Assistant-Switch-Manager: Switch manager is a centralised component to handle button pushes for your wireless switches. This includes anything passed through the event bus. The component relies on switch blueprints which is easily made to allow GUI configuration of your switches and their button pushes. This helps remove clutter from the automations..
The addon is the closest thing I’ve encountered so far in my search to find a solution to what I described just above. The UI is actually much simpler than the built-in one for the specific task of mapping smart light switches to actions. I recommend to check it out. There wasn’t a Z2M blueprint for my Aqara Opple switches but it was a breeze to create my own based on the deCONZ blueprints.
A bit frustratingly though, it only solves the the trigger part :). It has the same lack of ability as the built-in automation system, to smootly dim the lights while holding a button down (or rotating an IKEA Symfony remote.
Controller X on the other hand does a great job of dimming and fast response times. But it’s designed only to map a controller to a single light, which does not make much sense to use with a 3-gang switch. My switches have 3x2 buttons, each with supporting single, long, double and triple press support. I’d rather use it to have basic controls to 6 different lights. It also requires YAML configuration which is exactly the type of thing I was hoping to get away from. 
If only these two would join their efforts, they could be on their way to create a perfect solution to this seemingly obvious home automation task 
. This type of simplicity seems to still only be available within spefiic ecosystems (e.g. Zigbee) or between products of a single proprietary brand.
My switches are still waiting in their boxes, even though I’d likely be able to do this in Node-RED within one or two evenings. There seems to always be something more interesting to do than this mundane task I’ve already went through a few times with other types of switches. 
I stumbled upon this problem too. I’ve been puzzled on how to do this properly. This is a complete headache. The best solution I’ve found yet is this:
blueprint:
name: Toggle with 2 btn
description: Toggle light with Aqara 2 btn switch
domain: automation
input:
switch_entity:
name: Switch
selector:
entity:
integration: mqtt
domain: sensor
button:
name: Button
description: Which button to map the light on
selector:
select:
options:
- left
- right
trigger_variables:
switch: !input switch_entity
button: !input button
trigger:
- platform: template
value_template: "{{ is_state(switch, ['single_' + button, 'single_both']) }}"
The issue I have with this is that it seems sometimes the automation does not trigger. Maybe the state is activated too shortly? I don’t really know, but it’s not awesomly stable. Plus I would rather do the selection using a device and not an entity for this.
This exact thing was a no go for me. I’ve done plenty of switch to light mappings in Node-RED and the button presses just work “always” or nearly always. 5-20% failure rate I experienced with my attempts using the default automation was just way too frustrating to use. Hopefully I’ll have some time and inspiration to give this yet another shot during the summer holiday as I’ve still got them Aqara switches in a box. I doubt it though as my old Node-RED based combo of a few Mi-Light RGBW remotes and cheap 433MHz switches just work too good to get myself to do this. 