Missing button event triggers from Philips/Signify Hue Dimmer Switch

While migrating Hue Dimmer Switch and Hue Tap rules from the Hue bridge to OH 2.5.0.M1, I noticed that the binding seems to be missing button events. For instance, many times when short pressing and releasing button 1 of the Dimmer Switch, only the initial pressed (sometimes) or short released (mostly) is triggered, and sometimes neither.

To rule out the bridge itself or interference on the ZigBee mesh network that is causing this, I added a Dimmer Switch Rule (see below) to the bridge that triggers on initial pressed and turns on a light group as proof (as there is no accessible logging in the bridge). The light turns on but the events are mostly not properly picked up by the binding.

The Hue bridge rule I added:

{
    "name": "DimmerSwitch 12 Test on0",
    "conditions": [
        {
            "address": "/sensors/12/state/buttonevent",
            "operator": "eq",
            "value": "1000"
        },
        {
            "address": "/sensors/12/state/lastupdated",
            "operator": "dx"
        }
    ],
    "actions": [
        {
            "address": "/groups/5/action",
            "method": "PUT",
            "body": {
                "on": true
            }
        }
    ]
}

There seems to be some relation between the speed of pressing and release and the change the binding picks up all events. So I played a little with the timing parameters in the binding to see if it makes a difference. The described behaviour is with the default binding settings. When increasing the sensor polling freqency to 200ms (from its 500ms default value) and restarting the binding, the behaviour doesn’t seem to change. A few tests of short pressing Dimmer Switch button 1:

// Only event 1000 is triggered
22:20:15.390 [vent.ChannelTriggeredEvent] - hue:0820:xxxxxx:dim_test:dimmer_switch_event triggered 1000.0
22:20:15.392 [me.event.ThingUpdatedEvent] - Thing 'hue:0820:xxxxxx:dim_test' has been updated.
22:20:15.611 [me.event.ThingUpdatedEvent] - Thing 'hue:0820:xxxxxx:dim_test' has been updated.
// No events triggered, but there is some update detected
22:20:37.720 [me.event.ThingUpdatedEvent] - Thing 'hue:0820:xxxxxx:dim_test' has been updated.
22:20:37.938 [me.event.ThingUpdatedEvent] - Thing 'hue:0820:xxxxxx:dim_test' has been updated.
// Another short press and release test: only event 1002 is triggered
22:20:54.864 [me.event.ThingUpdatedEvent] - Thing 'hue:0820:xxxxxx:dim_test' has been updated.
22:20:55.117 [vent.ChannelTriggeredEvent] - hue:0820:xxxxxx:dim_test:dimmer_switch_event triggered 1002.0
22:20:55.118 [me.event.ThingUpdatedEvent] - Thing 'hue:0820:xxxxxx:dim_test' has been updated.

When increasing the polling frequency to 100ms, it looks like more events are missed as mostly only ‘Thing ‘hue:xxxx’ has been updated’ shows up in the event log, while the lights still turn on with the Hue bridge rule.

Anyone else experiencing these ‘missing event’ issues?

Hi Ron,

I have to admit: Even if I supported the implementation of the feature for the Hue binding this is the reason why I do not use it myself. Its reliability and the delays are a huge disadvantage. But I do not expect the binding itself to be the problem. These restrictions results from the Hue API.

Hi Christophe,

Thanks for confirming what I already ‘feared’. However, it makes me wonder… I recall having read somewhere that API updates were introduced by Philips to support Homekit integration. Does that mean that the reliability of the Homekit integration for sensors is lacking as well?
I did a quick read of some of the Hue API and SDK documentation and if I understood correctly, all is based on a polling mechanism with an SDK/Library that provides caching to minimize the load on the bridge. Looks like there are no callback mechanisms available directly from the bridge, only ‘locally’ through the SDK, right?

Anyway, as I planned to pair the Hue stuff to another ZigBee Hub directly connected to the OH server in the long run, this is another good reason to start that project now.