Ikea Tradfri Keypad and button capture woes

[Kitar]

Ikea in their wisdom have decided that a button once pressed should stay pressed for eternity. In HS I can capture the keypress by using "if ...ZbReceived:Keypad1:Power changes and becomes Any Value" . HS must be triggered by receiving the message, and not by detecting a CHANGE in value as it implies.

HS events are fine but I am trying to do this in Node-Red, with a fixed button value there is no trigger. KPD1:Power button remains fixed at 2.
Is there a simple way to have buttons revert to a different state once the they have been inspected? Are Tasmota rules the only way to handle this?

Another option is to not use a HS device change, but use a direct MQTT message received command. But it seems to me if HS can find a trigger then Node-Red should also be able to.

[Michael McSharry]

As I understand each press of the button generates the same payload and you need a means to simulate a button release message after some fixed period of time.

mcsMQTT will write to the device with the same payload value if the LAST CHANGED MISC property is not set. This is Edit tab setting. HS will trigger on a device being set even if it does change. The event action would be to set the value to 0 or whatever and this would then look to node red as a pulse when the button is pressed.

The version of the plugin in the updater or any subsequent version explicitly supports the LAST CHANGED logic rather than depending upon a HS.

[Kitar]

Thanks Michael.
I was going to set the device to a value but there is no feature/device drop down list. Is this by design?

I am sending an MQTT command to alter the button value. This triggers the event again so I use "do not re-run event for 1sec" and it all works.



Is this the checkbox you are referring to: My events behaved the same way with this checked or unchecked.

[Michael McSharry]

I was going to set the device to a value but there is no feature/device drop down list. Is this by design?

The Devices page UI only has controls for devices that have Pub topics defined. If you did define a Pub topic and used the control for this device then it would not matter since the device is only updated by mcsMQTT based upon the Sub topic payload.

This does not prevent you from setting the DeviceValue directly using one-line script. I think HS4 is still using the HS3 scripting so this event action of script in-line would be %hs.SetDeviceValueByRef(1234,0,false) where 1234 is the device reference number and 0 is the value you want to set the device.

Is this the checkbox you are referring to: My events behaved the same way with this checked or unchecked.

Yes it is and you are correct that the value is written unconditionally. It will only affect the LastChange property. If you only set the device to one value then LastChange with checked checkbox would show the LastChange as the time when the button was first pressed rather than when most recently pressed. If you do change the value such as shown above then it does not make much difference how this checkbox is set.