Ikea On/Off switch - Missing properties

[FranzToepfer]

Hi, I ask for support in regards of Ikea On/Off switch:

• Actually I'm running iobroker docker container on a raspi 4B.
• In a parallel container deconz is running
• Within iobroker Deconz adapter is used to communicate with the deconz zigbee network
• To avoid dedciated deconz docker container, I gave the Zigbee iobroker adapter a trial
• Stopped deconz container, mapped USB device into iobroker container, installed the adapter and Tada - able to teach in several devices

So up to this point, very smooth migration, big thank you.

But unfortunately devices seem to be configured very different from Deconz. Ikea On/OFf is just a good example:

• Last Updated property completely missing
• Button clicks implemented as boolean keys - Deconz instead publishes ButtonPressed event and thus allows more flexible logic
• For Long Click events, implementation in adapter is like a one-click button
• Short click properties instead are implemented as real switch, remaining in On/Off state unless changed

As properties of the decive are different between Deconz adapter and Zigbee adapter, one may not easily migrate from one to the other.

Question - Any plans to add the missing properties, respectively adaot existing properties to follow the implementation of Deconz adapter (which in my perspective is very comfortable one the one hand as providing events as is and further provides more details per device)?

[arteck]

Ikea On/Off switch ???

[arteck]

Any plans to add the missing properties - which properties.. we have all what you need .. different to deconz yes .. but you have all messages and states .. I see no need here

[FranzToepfer]

Alright, I need to get more specific. The device I'm actually referring to is Ikea E1743 switch. Where for other devices situation is similar.

Which properties are missing? Just as I wrote, Deconz e.g. provides some more information, used to compose specific logic in Node Red. Changing to the Zigbee adapter those properties will be missing, causing efforts to redesign this logic:

• LastUpdated (information when last clicked, useful in Node Red to distinguish between real clicks and artificial clicks, just resulting from restarting adapter instances)
• ButtonPressed (just for the moment of clicking the button the numeric click ID will be published, for long + short click both)
• ButtonPressed also might be left out, if both clicks (long and short) would be provided as lets say virtual keys, just TRUE for the moment when clicked. This is the case for LONG click only, where for SHORT click not

Hope this will be bit more specific. Likewise, for other devices I see similar behavior. e.g. Ikea Tradfri Motion Sensor E1745. Also there, for example no LastUpdated information (good to have this to see when last motion detected in a specific room)

[asgothian]

Question - Any plans to add the missing properties, respectively adaot existing properties to follow the implementation of Deconz adapter (which in my perspective is very comfortable one the one hand as providing events as is and further provides more details per device)?

Short answer: not at this time.

Long answer: The "lastUpdated" state in deConz is required, as the adapter needs to distinguish between hardware related updates and updates generated by the data in the deConz software and in the ioBroker Adapter being out of sync. For the zigbee Adapter, this information can be accessed at any state using the 'timestamp' attribute. In a trigger, you can even obtain the timestamp attribute for the old value to determine how long ago the last change was.

Mapping the various possible buttons to a single numeric coded ButtonPressed state is a lot of work, so I do not see this coming in. The single states allow for a much more streamlined use of triggers for exactly the event you want, rather than having a trigger which fires every time any button is pressed which then forces you to go through a list to see which action that is supposed to be.

A.

[FranzToepfer]

Thanks for your feedback.

Referring to "lastUpdated" state, I did not know the background stuff, thanks for pointing this out. Sure, I may just catch the TIMESTAMP provided with each message and track it manually in a user data field on ioBroker. This will fullfill my requirement, to see when sensor last updated.

Regarding the buttons, well, in my outside perspective I thought the button always publishs a numeric code, which will be encoded into button up/down etc. by the adapter. Seems to be wrong way of thinking. Let me rephrase my requirement here a bit:

• For LongUp and LongDown Zigbee adapter provides information like for a push-button (hey, actually LongUp clicked). For the moment of clicking, the corresponding property is in state TRUE, but falls back to FALSE afterwards
• For ShortUp and ShortDown the adapter behaves differently, implemented as 2-state switch. Clicking ShortUp, property will be set to TRUE and remains TRUE, unless ShortDown clicked
• In some situations this might be helpful, when dealing with a 2-state-light switch e.g.
• In my case, these buttons are used for shutter control, where I react on single button clicks
• Finally, my question is, whether an additional property may be provided for ShortUp/ShortDown providing information when actually clicked (similar to Long clicks)

Maybe providing this might be possible, as additional property, not impacting existing implementations?

[asgothian]

This behaviour is based on the messages the device sends to the zigbee network. And while it is technically feasible to add such an additional property, it is something we want to move away from, as it requires in-adapter code to modify device behaviour - something which has generated a huge amount of work in the past.

if you are curious, you can set a trigger to the "msg from zigbee" state and log what the zigbee network sends as telegrams. You will notice that on this particular button, the message sent does not offer the press / release scenario for short press.

A.