I don’t use MQTT, so I’m not as familiar with it. But, at least in theory, all events that can be detected using a new style device type trigger should be able to be done with the more traditional type of trigger, too. Once you figure out how to substitute you current trigger with the one I referenced, then you can use the trigger variable I also referenced in my last reply. Something like:
- choose:
- conditions:
- condition: template
value_template: "{{ trigger.payload... }}"
For the same zigbee button :
my manual automation :
- id: '1567689190101'
alias: bedlicht aan
trigger:
- platform: mqtt
topic: zigbee2mqtt/ikea_button1/click
payload: 'on'
action:
- data:
entity_id: light.light_ikea1_light
service: light.turn_on
Created with the automation editor :
- id: '1595945774178'
alias: test1
description: ''
trigger:
- device_id: 245279fcc1a241e78c427431c325d8a3
discovery_id: 0x000d6ffffeac1f8a click_on
domain: mqtt
platform: device
subtype: 'on'
type: click
condition: []
action:
- data: {}
entity_id: light.light_ikea1_light
service: light.turn_on
mode: single
Thanks!
@callifo, in that case, then maybe this:
- trigger:
- platform: mqtt
topic: zigbee2mqtt/ikea_button1/click
- choose:
- conditions:
- condition: template
value_template: "{{ trigger.payload == 'single' }}"
sequence:
- service: switch.toggle
data:
entity_id: switch.coffee_machine
- conditions:
- condition: template
value_template: "{{ trigger.payload == 'hold' }}"
sequence:
- service: switch.toggle
data:
entity_id: switch.dishwasher
Same here v0.113.1
http://192.168.200.210:8123/frontend_latest/chunk.cf565e41b8a8dce0642a.js:133:238 Uncaught TypeError: Cannot read property 'header' of null
Great, looking forward to the new action. Have waited a good while for the sub-second delays, so I can wait a bit longer for that 
after updating to 113.2 just now, the first thing I hear is quite disheartening. the template that has been working for ages all of a sudden makes the tts speak %20 on each space in:
- service: script.intercom_message
data_template:
message_en: >
Good {{states('sensor.part_of_day')}}, Home-assistant Rpi4 is back up and running since
{{as_timestamp(now())|timestamp_custom('%d %b %X')}} and it is
{{states('sensor.temp_current')}} degrees.
has anything changed that might have caused this? Ive tried it in various languages, but the result is the same.
the template is parsed as it should:
I have the same issue, using TTS for door sensors, automation using Node-red.
Same here with all my TTS alerts (door, weather, alarm).
I’ll have a look tonight and see whether my button has these sort of topics; can’t say I had thought to look at the zigbee2mqtt mqtt structure before.
Percent 20 percent ftw
Same here - family and I find it quiet funny that Google sounds a 22|bit|percentage|bonkers|22.
Can’t see anything that has caused this in the changes but I’m sure the top guys will sort it out soon enough.
Have you tried it without a template and just hardcoded text, to see if it is actually the template that’s the issue? TTS to my Alexa devices is working fine via the custom Alexa Media Player notify platform with and without templates, so it may be that it is nothing to do with the template and something to do with the Google TTS platform (if that’s what you’re using).
Edit: Found this issue on GitHub:
I updated to 113.1 on sunday successfully. Everythings running smooth. But I do not have any issue logs since then. Even failing scripts during development haven’t been added. Yesterday I had an entry in homeassistant.log regarding a depricated configuration entry but it wasn’t shown in the frontend. Has anything been changed in handling of log entries?
Yeah thanks. Saw the GitHub issue.
Haven’t tried it without template yet, but seems the issue is clear, so I’ll wait it out for now.
Hope the devs fix this per 113.3 …
I can confirm that also without template the issue is there…
Interestingly enough, typing any text at Google Translate and hitting the speaker symbol yields the expected result 
https://translate.google.com/#view=home&op=translate&sl=en&tl=nl&text=This%20is%20a%20test
I usually wait till the weekend to do an update so if I need to fix anything I’ve got plenty of time. This time, however, I did the update on a weeknight and everything broke! HA was starting up but nothing was loading. To make matters worse my wife’s sister was staying with us for a couple of days. I lost a lot of WAF when they couldn’t turn the tv or the lights on!
I narrowed it down to my sensor.yaml file and then went through them all one at a time. The problem ended up being that I had a sensor with a scan interval set to .1 (dont ask). Have now changed it to:
scan_interval:
milliseconds: 100
and all is good again!
Thanks for all your hard work devs
That is a ridiculously fast scan interval.
Yea I know, maybe I’m going about it the wrong way but its the only way I can get my light switch as responsive as I want it!
its a press switch (not toggle) connected to a digital input of a relay module set up like this:
- platform: snmp
name: "Living Room Switch"
host: 192.168.1.100
port: 161
community: public
baseoid: 1.3.6.1.4.1.42505.8.2.1.1.7.0
scan_interval:
milliseconds: 100
then an automation which switches the lights when the state switches from 0 to 1. The faster the scan interval the less I have to hold the press switch down!
Feel free to correct me. I’m pretty new.
And I actually can’t reproduce here if I trigger the tts.google_translate_say service manually (on 0.113.0) 