Order of websocket events

[snozzlebert]

I've a Hue dimmer switch linked to a group with one light. There are no rules configured in the REST api.
When I press the off button, the light is turned off as excepted and I get the following websocket events:

{"e":"changed","id":"3","r":"lights","state":{"on":false},"t":"event"}
{"e":"changed","id":"23463","r":"groups","state":{"any_on":false},"t":"event"}
{"e":"changed","id":"4","r":"sensors","state":{"buttonevent":4000,"lastupdated":"2017-08-07T21:25:30"},"t":"event"}
{"e":"changed","id":"4","r":"sensors","state":{"buttonevent":4002,"lastupdated":"2017-08-07T21:25:30"},"t":"event"}

I would expect at least the event of the first button press before the event of the new light state. For example:

{"e":"changed","id":"4","r":"sensors","state":{"buttonevent":4000,"lastupdated":"2017-08-07T21:25:30"},"t":"event"}
{"e":"changed","id":"4","r":"sensors","state":{"buttonevent":4002,"lastupdated":"2017-08-07T21:25:30"},"t":"event"}
{"e":"changed","id":"3","r":"lights","state":{"on":false},"t":"event"}
{"e":"changed","id":"23463","r":"groups","state":{"any_on":false},"t":"event"}

The same thing holds for turning on the lights and dimming (up/down). I get the new light state before the sensor state.

[ebaauw]

The Hue dimmer switch works differently from other switches. When your press and release a button, it actually sends three ZigBee messages:

1. A ZigBee attribute reporting message from the 0xFC00 cluster for the press button event (x000). The gateway receives this, updates the cached sensor state, issuing the corresponding event notification.
2. A ZigBee command to the 0x0006 (On/Off) or 0x0008 (Level Control) cluster of the associated group. The gateway listens in on this command, and updates the cached light and group states, issuing the corresponding event notifications. The lights in the group receive this command and update their state.
3. A ZigBee attribute reporting message from the 0xFC00 cluster for the release button event (x002). The gateway receives this, updates the cached sensor state, issuing the corresponding event notification.

I suppose it depends on your system and ZigBee network load, whether 1) or 2) reaches the bridge first. I'll do some ZigBee sniffing to confirm whether this is the actual order in which the ZigBee messages are sent.

Other switches only send 2) (either on press or on release) and the gateway reverse engineers the button event from the command, so you would always see the button event notification first.

[ebaauw]

The same thing holds for turning on the lights and dimming (up/down). I get the new light state before the sensor state.

For dimming that's odd. What lights are you dimming? I don't see any light state messages for my Philips lights when pressing the DimUp or DimDown buttons. This makes sense, as the gateway cannot predict the new light state because it's relative to the current state (same for the Trådfri remote On/Off button, which sends a toggle command). So it doesn't update the cached state and therefore it doesn't issue any notification.
I would expect messages from IKEA or OSRAM lights that support attribute reporting. Then the light actively reports it new state to the gateway, which updates its cached state, issuing the corresponding event notification.

[snozzlebert]

Thanks for the explanation.
I was wrong about the DimUp/DimDown, an external rule triggered and fired a scene recall. After disabling this is only see 2000/2002 and 3000/3002.
I always get the light event before the sensor event (4 routing devices: 3 Philips color lights, 1 OSRAM plug and 5 end devices and a ConBee). I close the issue because this is not related to the REST plugin/websocket.