As of 2.3.075 the shortcut buttons no longer fire multiple messages for each press, and a new double press “off” command is introduced. This makes automations much simpler.
Checking software version numbers in ZHA:
Device page of the device in question
3 dots next to “RECONFIGURE” → Manage Zigbee Device
If you want to update your firmware then you may find this link useful. But beware, your other Tradfri products are likely to be updated during the process and there are some breaking changes, particularly with the binding behaviour of the on/off switches.
blueprint:
name: ZHA - IKEA Tradfri Shortcut button
description: Control anything with the ikea shortcut button
source_url: https://https://community.home-assistant.io/t/zha-ikea-tradfri-shortcut-button-firmware-2-3-075-or-greater/402565
domain: automation
input:
shortcut_button:
name: Device
description: Select an IKEA shortcut button
selector:
device:
integration: zha
manufacturer: IKEA of Sweden
model: TRADFRI SHORTCUT Button
button_short:
name: Single click
description: 'Choose action(s) when short pressed:'
default: []
selector:
action: {}
button_double:
name: Double click
description: 'Choose action(s) when double pressed:'
default: []
selector:
action: {}
button_long:
name: Long click
description: 'Choose action(s) when long pressed:'
default: []
selector:
action: {}
button_release:
name: Release Long Click
description: 'Choose action(s) (if any) when releasing long press. This will run in a separate call of the automation so in "single" mode it may be suppressed by the long-press action if that takes some time. It cannot easily be used to stop a long-press action, for that - use mode: "restart instead" '
default: []
selector:
action: {}
automation_mode:
name: Automation Mode
description: 'The [mode](https://www.home-assistant.io/docs/automation/modes/) for this automation. Default is "single" - further actions are blocked whilst the automation is running. Choose "resart" if you want the long-press action to stop on release.'
default: single
selector:
select:
options:
- single
- restart
- queued
- parallel
mode: !input 'automation_mode'
max_exceeded: silent
trigger:
- platform: event
event_type: zha_event
event_data:
cluster_id: 6
device_id: !input 'shortcut_button'
- platform: event
event_type: zha_event
event_data:
cluster_id: 8
device_id: !input 'shortcut_button'
action:
- variables:
command: '{{ trigger.event.data.command }}'
cluster_id: '{{ trigger.event.data.cluster_id }}'
endpoint_id: '{{ trigger.event.data.endpoint_id }}'
args: '{{ trigger.event.data.args }}'
- choose:
- conditions:
- '{{ endpoint_id == 1 }}'
- '{{ cluster_id == 6 }}'
- '{{ command == ''on'' }}'
sequence:
- choose:
default: !input 'button_short'
- conditions:
- '{{ endpoint_id == 1 }}'
- '{{ cluster_id == 6 }}'
- '{{ command == ''off'' }}'
sequence:
- choose:
default: !input 'button_double'
- conditions:
- '{{ endpoint_id == 1 }}'
- '{{ cluster_id == 8 }}'
- '{{ command == ''move_with_on_off'' }}'
sequence:
- choose:
default: !input 'button_long'
- conditions:
- '{{ endpoint_id == 1 }}'
- '{{ cluster_id == 8 }}'
- '{{ command == ''stop_with_on_off'' }}'
sequence:
- choose:
default: !input 'button_release'
Edit 1: On my install at least, the ‘wait_for_trigger’ is never triggered and the automation times out.
Edit 2: 2023-07-02 Edited post instructions for checking firmeware version for the new UI.
Edit 3: Added “max_exceeded: silent” back into version 2 to stop cluttering logs.
2023-07-02 Version 2 release:
Removed the “wait_for_trigger:” and “timeout” blocks as I am not sure what they were achieving
The automation will only trigger on “cluster_id” 6 and 8. So it will no longer trigger on device “checkin” which will simplify logbooks, debugging and traces.
Automation mode is now user-configurable
Button release action is now configurable. Useful for making something happen after the long press has finished. Such as saving a device state or toggling a config variable.
To update either just click the Import Blueprint button above or see the guide here.
Thank you for this! Just noticed my double click actions stopped working, and the new “off” events coming from the button. Was about ready to rewrite this thing myself, but glad to see your working fix beat me to it
judging by your error it is not seeing this as a dictionary, no idea why! What version of HA are you using, and I’ll have a look through the breaking changes.
Probably, but not with this blueprint. IIRC a “Stop” command is sent on release. So you could trigger a loop that starts with move_with_on_off and ends when a “stop” message runs.
Thank you! I couldn’t figure out how to include a trigger in my automation created from your blueprint. So I have the loop being stopped by an input_boolean helper being toggled on, and having a separate automation detect the release command and toggle the helper. I added in a bit of a delay (350 ms) in the loop for increasing the brightness and it works perfectly like I want.
If you happen to know how I could include the zha_event as a trigger in the automation created from your blueprint, that would be great to simplify things.
Since I’ve written this untested I would suspect that these bits would cause issues as I don’t remember the cluster_id and command for the release command I have checked and these are correct.
The automation runs in single mode (which means it can’t be triggered until the last run has finished) which may cause issues with the stop command being blocked, so you may want to try other modes. And/or remove all the wait for trigger blocks as I am not sure they achieve anything and cause the automation to stay in the ‘running’ state for longer.
Example:
An example of a version that dims a light until the button is released. Automation Mode: restart is doing the work of ‘stopping’ here - when the button is released the automation is triggered again (but performs no action) which interrupts the previous run which was doing the dimming.
If you wanted the button to switch between dimming and brightening, you could create a choose block in the repeat loop that relies on a hidden input boolean and toggle the boolean in button_release. Another solution would be to use a choose block but decide based on the current brightness of the light.
Thank you for pointing this out. Now fixed in Edit 3.
This shouldn’t have caused any failures, it was expected behaviour of single mode, I have added max_exceeded: silent back in to silence these log messages.
Unfortunately not as I run ZHA, however with the new events entity introduced in 2022.8 this blueprint will likely become much simpler/obsolete when ZHA and Z2M implement it.
