Philips 324131092621 - MQTT Actions Changed

[srnoth]

What happened

With version change from 1.17.0 to 1.17.1, the MQTT actions for the Philips Hue Remote (324131092621) changed from using a - to a _ e.g. on-press is now on_press.

This beaks automations based on MQTT messages, but easily fixed with swapping the "-press" for "_press" in yaml.

Additionally, when holding one of the buttons, an on_press is now received immediately, followed by an on_hold. Previously as long as the button was held, there would be no on_press action sent.

Not sure of a fix for this - it means that we cannot have independent "hold" automations, separate from the "press" automations. The "press" automation is now triggered alongside every "hold".

What is even more strange is that under zigbee-herdsman-converters/devices.js, the entry for 324131092621 still shows the "exposes" actions with the "-" (as was the case previously).

exposes: [e.battery(), e.action(['on-press', 'on-hold', 'on-hold-release', 'up-press', 'up-hold', 'up-hold-release',
 'down-press', 'down-hold', 'down-hold-release', 'off-press', 'off-hold', 'off-hold-release'])],

Debug info

Zigbee2MQTT version: 1.17.1
Adapter hardware: Conbee II
Adapter firmware version: 26680700

[srnoth]

Example of the MQTT for a "hold" action:

Message 4 received on zigbee2mqtt/remote.office/action at 8:57 PM:
on_release
QoS: 0 - Retain: false

Message 3 received on zigbee2mqtt/remote.office/action at 8:57 PM:
on_hold
QoS: 0 - Retain: false

Message 2 received on zigbee2mqtt/remote.office/action at 8:57 PM:
on_press
QoS: 0 - Retain: false

[Koenkk]

The actions with - are the legacy once. The non-legacy contain _. Did you disable the legacy integration by setting legacy: false in your configuration.yaml? If yes this breaking change is expected.

[srnoth]

@Koenkk thanks that explains the - to _ change.

But is it also expected that the press action is now included every time you have a hold action? It means we can no longer assign separate automations to the hold action.

[Koenkk]

It means we can no longer assign separate automations to the hold action.

Why not? You can trigger your automation when receiving e.g. on_hold

[srnoth]

Why not? You can trigger your automation when receiving e.g. on_hold

That is correct that we do still have the _hold actions which can be assigned to separate automations, but with the new triggers what ever I have assigned to the _press actions will also be triggered, where as before the _hold automations could be triggered independently.

For e.g. I use the on_hold and off_hold actions to turn the heater in a particular room on and off, separate from the light controls. As is is now I cannot turn the heater on (on_hold) without also turning the lights on (on_press) since that action is triggered immediately prior to the on_hold.

With the legacy triggers when holding a button, only the corresponding -hold action would be triggered, allowing me to control the heater without changing the state of the lights.

[Koenkk]

I see, so there are two solution here:

• When receiving a press wait for X seconds, if no hold is received send on_press. Down side this would delay every on_press.
• After a hold don't send a on_release but on_hold_release. In your automations you can use on_release for the single press (instead of on_press).

[srnoth]

I think option two is best as you wouldn't have any arguments over how long the delay should be. People who don't utilize the on_hold functions can use the instant trigger of on_press, and those who do need independent on_hold functionality can use on_release like you said - which is only delayed as long as the time it takes to press and release the button.

[Koenkk]

Done!

Changes will be available in the latest dev branch in a few hours (https://www.zigbee2mqtt.io/how_tos/how-to-switch-to-dev-branch.html)

[srnoth]

@Koenkk just got the latest dev installed. The new actions work perfectly. Thanks so much!