Replies: 4 comments 5 replies
-
Hi @jhenkens, thank you for your nice feedback and your suggestion. :)
I don't know how MQTT triggers exactly work in Home Assistant, but as far as I know they're currently pretty limited. I can see you did an interesting research on this topic; I'll take some time to learn more about it and then report back here with my findings, so we can better discuss this proposal. 👍🏻
Having such support would be great, considering that Z2M considers MQTT triggers the non-legacy option. Anyway I also think it's crucial to only introduce such new integration with great usability in mind (e.g. providing users an easy way to select the Z2M topic/device). Once we've the feature design down, I'd be glad to help you in implementing it in our controller blueprints. :) Thank you so much for your suggestion and your precious time! |
Beta Was this translation helpful? Give feedback.
-
Please support Z2M-MQTT topic subscription as an alternative for the sensor based legacy triggers. Because the Z2M legacy triggers overwrite the action immediately with an empty string, often the button presses don't fire an action, because the initial action string gets overlooked somehow. As I understand it device triggers are meant mostly for UI use. The best and most elegant option when writing YAML code for button presses on Z2M devices is to use MQTT topics as triggers. This works flawless, unlike the sensor based legacy triggers. As an example here is what an automation looks like for a Z2M device, which has the friendly name "Stairs Switch": automation stairs_switch:
- alias: Stairs Switch
trigger:
platform: mqtt
topic: "zigbee2mqtt/Stairs Switch/action"
action:
- variables:
action: "{{ trigger.payload }}"
- choose:
- conditions:
- "{{ action == 'right_press' }}"
sequence:
- service: script.toggle_dark
- conditions:
- "{{ action == 'left_press' }}"
sequence:
- service: script.cycle_scene_next All inputs which would be needed for a blueprint is what the friendly name is and what device (for the button strings). |
Beta Was this translation helpful? Give feedback.
-
I'm in the same boat, just this week setting up a whole new deployment and discovering my plans to not use legacy_anything failed with my first rattle of the cage. I like the idea of supporting MQTT topics (z2m's 3rd option for triggers) as an alternative to the 1st option: Device Triggers if that can't be panned out. I'm using these ArduoSmart ERIA remotes that have 4 buttons and 4 actions only... very simple: so for this remote something like MQTT topic would be perfect. @jhenkens have you had a chance to look at using MQTT topics for triggers instead of entities? I'd like to see your work if so. |
Beta Was this translation helpful? Give feedback.
-
Hi @jhenkens, @EPMatt and @YAMLcase, since I moved from Philips Hue-Bridges to ZHA and now to Zigbee2MQTT, I'm experiencing some dropped messages for actions as well. And yes, it seems to be related on to fast updates. I know there is a way to do better and easier to config. I will share my first adjusted controllers in some days on my fork. |
Beta Was this translation helpful? Give feedback.
-
Hi,
I've found your blueprints, and found them quite helpful. However, in my current setup I'm using entirely "no-legacy" settings on Zigbee2Mqtt. This means so
action
sensors, ashomeassistant_legacy_triggers
is false. In an ideal world, there would be a way for blueprints to use the native device automation events from Zigbee2Mqtt, however I do not know how to get the discovery_id, which is needed for this to work.What I have done instead is modify the controllers to handle mqtt event triggers, and parse the rest of it that way.
It feels a bit hacky, as in order to continue to support hooks, I still have to select the device it comes from. And I do not believe there is any way to discover the topic from the device (instead, I added another input).
I guess I have two questions here.
One - any knowledge that I cannot seem to find on the ability to find the discovery_id for a given action, so I could use that instead? It seems to be some internal HomeAssistant guid, from what I can tell browsing all the MQTT messages in my setup.
Two - any interest in having Z2M-MQTT topic subscription as an integration type (to complement the existing Z2m Legacy Sensor, ZHA, and Deconz)? I can do the leg work on the controllers once we get one done in a way that looks good to you.
Beta Was this translation helpful? Give feedback.
All reactions