Hue bridge is detected, and all bulbs attached to it as well. But no dimmer switch. In hue application I have dimmer switch linked, but not assigned to anything (if that changes anything). I can capture the data somehow using rest api, but this does not seem to be very reliable. I’d prefer ‘the hue integration’ method.
The only entity created for the switches by the Hue integration is a battery entity, so you won’t see an entity with the button press state. However, you can use a device trigger in the automation UI editor, or listen to hue_event to find button press event data and use an event trigger in an automation.
Thank you for pointing to this. Looks very handy. But this is only meant to be used if you have the dimmer buttons paired via the hue bridge. Which I don’t.
i however cannot see the switches states in automation neither, and battery entities for my dimmer switches are not present. Now, I have installed the @robmarkcole code through HACS, however I’m not sure whether this one is ‘active’ as if I understood correctly, the HA already contains an implementation of Hue bridge.
My dimmers are paired with hub, they are however not connected to any action inside the Hue application (meaning I get data from them through rest - I see on the API web page any action I do to these dimmers), I just don’t see them in HA (even as states)
The present hue integration in ha does not see switches.
Therefore i use the custom component for remotes from robmarkcole.
Switches appear as remote.[your_hue_name] in your ha.
instead of the CC hueremote, which ‘hammers the Hue Hub’ you’d best be using the new integrations devices and events, and if you want, bring these forward into the front-end with the https://github.com/azogue/eventsensor
that way you are 100% sure no extra traffic between Hue and HA is occurring, and you use the core devices, which in the end is better, and gives you the security of the Core dev’s development attention
remember CC are not supported. As of late we have most Hue devices in core and with some very active 'great contributors ’ like @azogue , we get the best of both worlds !
I hear you, maybe a different list then with all events from devices? I don’t know, but it tends to be confusing as it is right now. Devices have entities and events are kinda “hidden” so for people new to HA it’s a little confusing. I don’t have that much experience with other systems out there, just one. And to me the whole entities list is already something I was wondering about what to do about. Isn’t just the device list enough and if you want to see entities or events from a device wouldn’t it be far more logical to just click on the device and get all there is to work with from that device?
Also if events aren’t logical to be called an entity why is an automation an entity then? because that is even more illogical in my eyes.
It is, I think it comes through the different implementation of wireless remotes from different integrations, e.g. Deconz uses events and I think ZHA uses states for the exact same device.
Because you can turn/on off an automation and an automation can have a state, whereas a wireless remote only has events, you can’t turn them on/off and they don’t have a state.
well, it depends on you pov.
a wireless remote ( what’s in a name ) is no more than a wireless switch, hence the toggle the remotes show (ok, and a few more possible actions). As such, the representation of a remote could just as well be a switch or a couple of sensors.
Depends on what you want to represent. The last event, or the state the entity it controls is currently in.
I find it more confusing that my Apple remote does have a switch, even though it cant switch /on/off the appletv…
one could argue the state of the remote should be its last button event. As the hueremotes (previously huesensor CC) uses. It would be much more selfexplanatory than the current implementation. Or as the new eventsensor does.
Adding it to recorder/history provides a perfect history of last button events.
the states can be used in automations/sensors. Of course events can too, but are a bit trickier to find and check in the frontend…
I assume that will be the “method” going forward, but I simply don’t like it. I’d rather have an entity that has online/offline as a state and the last button press as an attribute, because as I said before, the remote is not in the state “long press on button” when you long press the on button.
This would be solved as well with my approach, however I’m wondering for what you need this data?
Dear All,
thanks for fruitful hints. At the end it appears, that I have resolved ‘partially’ this situation by going out of Rpi4 (which originally hosted home assistant) to something more reliable (hp proliant microserver + debian + home assistant).
It seems that using ‘default’ implementation of HA (no custom component for hue) I can see switches, I can trigger the actions, but the triggering is very unreliable. While android hue application sees the buttons instantly, the HA triggers the actions ‘randomly’ - meaning sometimes yes, sometime no, sometimes after a significant delay.
Is there anything particular I shall investigate to fix this?
