As cc’ed by @Mariusthvdb, my POV on this
Last hue update now does some extra things:
- It register as devices the Hue dimmer switch and the Hue Tap switch,
- and in doing so it also enables device triggers to build automations from UI based on button presses.
- For battery powered remotes (the Hue dimmer), it also adds a battery level entity.
That follows the general approach of mirroring real objects with “devices”, and expand their states as separate entities.
feels rather inadequate not having an entity in the states for an entity in real life…
It has now a device. It is like the motion sensors, which get into HA as 1 device with multiple entities (binary sensor for motion, temperature and light level sensors, etc.)
With official integrations, I believe anything like a button typically doesn’t have an entity that reflects the button press state. Events are used for that.
Exactly. In fact, this feature has been “inspired” (mostly copied) from the deCONZ ZigBee integration.
Having a sensor for the button press itself probably wouldn’t work with the Hue integration since the integration uses polling. Light, sensor, etc. states and events are updated every 5 seconds, so if you had a button press entity and you pressed the same button that was pressed before, the state likely wouldn’t change (it would go from up to down to up so quickly that it would likely be between polling cycles). That would make automations that are supposed to trigger on specific state changes likely not fire in that case.
That is totally true. The same zigbee remote device would work much better under a Conbee stick than in the Hue bridge, as deCONZ has pushing ability, so no button presses are lost.
BUT, that does not make this feature unusable. You need to take into account a possible delay of 0 to 5 secs between button press and HA action, but that is not the end of the world: the “hold” button press action is specially useful to create automations on devices that already are configured for simple presses on the Hue app.
I think OP was concerned that that was the only way the button presses could be used in automations.
The “hue_event” is always fired and can be used directly. Device triggers use it internally and they are just an easier way to do things from the UI.
@azogue has made a custom component event sensor, will give that a shot soon now this is in Core Ha.
There are some people (myself included) that want to “see” or record the state of the remotes in the house, so HA events are not enough. For those nerds I created that very simple custom integration to create a “sensor” entity from some specific event.
- It is not needed to use the remotes in automations (better use the integrated device triggers)
- It can be used for any kind of remote or other HA event emitter. In my case, I use it for all my remotes. Some are integrated in the hue bridge (they have the polling known delay) and others in the deconz (those have an instant response).
