Where are the new entities for Hue (dimmer and tap) switches

[azogue]

No, it’s a feature from the Philips Ambilight TV, to link it with the Hue hub and configure some lights with the image borders, so they change in sync with the ambilight LEDs (well, with a little delay).

I don’t know if it’s available for all models, mine is relatively recent.

[Mariusthvdb (Marius)]

A ok, will check that. Ive previously tried a custom component but couldn’t get that to work (or recognize my tv in the first place at all…)

update

found it! very nice indeed. Hope this doesn’t interfere with the HA instance…

[pav (Paul Vanderperren)]

Hi @azogue,

Indeed, as I said already in my first message, monitoring the ‘raw’ HA events I already noticed the flaw in the Hue integration - causing me to conclude that your CC is merely victim of it. It should be easily reproduced & verified.

Regarding my context/config : you got it right on all accounts …

Thanks for your continued efforts & just tell if I can be of any assistance, ok ?

[azogue]

@pav

flaw in the Hue integration, not catching/firing all necessary events …

I think I got it

The timestamp used to compare does not have precision enough, so when both events (press and release) fall into the same second, and the HA update is made in the middle, so it fires a “press” event, in the next update it will get a different code (the 4002) but with the same timestamp, and it won’t fire another event, making the “press” the last and unique one.

I need to re-check it, but I’ve also experienced it myself, so the bug is real.

EDIT: A proposed fix is ready in Fix missing events for hue remotes by azogue · Pull Request #34340 · home-assistant/core · GitHub

When both events fall into different seconds, then it is working as expected, firing the 2 events:

Evento 22 disparado 14:23:

{
    "event_type": "hue_event",
    "data": {
        "id": "interruptor_dormitorio",
        "unique_id": "xxxredactedxxx",
        "event": 4002,
        "last_updated": "2020-04-17T12:23:38"
    },
    "origin": "LOCAL",
    "time_fired": "2020-04-17T12:23:39.273431+00:00",
    "context": {
        "id": "0739822965df4c9caf49bf24d237d3be",
        "parent_id": null,
        "user_id": null
    }
}

Evento 21 disparado 14:23:

{
    "event_type": "hue_event",
    "data": {
        "id": "interruptor_dormitorio",
        "unique_id": "xxxredactedxxx",
        "event": 4000,
        "last_updated": "2020-04-17T12:23:37"
    },
    "origin": "LOCAL",
    "time_fired": "2020-04-17T12:23:38.235080+00:00",
    "context": {
        "id": "c935a9292e29473c9b11850752750922",
        "parent_id": null,
        "user_id": null
    }
}

[pav (Paul Vanderperren)]

Sounds very reasonable, so I’m sure you’re spot on. Great work - doesn’t seem like a tough fix (although it’s easy for me to say so ) But as we’re talking fixing official Hue HA integration, I guess we’ll have to await next (patch) release ?

[Burningstone]

@azogue

The Hue mobile app is really good for manual setting of lights and ambiances, much better than current lovelace UI,

There are quite some nice custom lovelace cards to control the lights with popup etc.

@azogue

Moving a remote to the conbee means reprogramming it completely, and in most cases also will introduce a HA dependency for it: no more independent subsystems (remotes working with HA down)

This is not entirely true. You can bind remotes to lights in deconz and they will continue to work if HA is down and even if Deconz is down.

However the Ambilight is a valid reason to not move over to Deconz completely.

[azogue]

@Burningstone

This is not entirely true. You can bind remotes to lights in deconz and they will continue to work if HA is down and even if Deconz is down.

You are right, perhaps I was a bit extreme there
About the remote programming in the deconz, I think what I missed the most was the Hue function to rotate through scenes with the “ON” button. It may be available but I didn’t find it
However, there were very interesting options there that aren’t available in Hue, I must say.

In the end, I implemented the scene rotation inside an AppDaemon app, that’s why I said that about the HA dependence, so sorry about that.

However the Ambilight is a valid reason to not move over to Deconz completely

Totally. I suppose with time I’ll migrate everything except the bulbs in the living room, and move the hue bridge under the TV

[brendan]

@azogue
I am just reading through this now. What is the advantage of your CC over the one by robmarkcole?
Just curious as the one by robmarkcole works currently, but he has marked it as deprecated in preference for using the official integration.
I find the 5 second polling cycle of the official integration intolerable for switches and motion sensors though.

[Burningstone]

I recommend buying another zigbee router such as the ConBee that supports pushing events/states to Home Assistant and ditch the Hue hub. With the hue hub you’ll always poll the state from the hub, no matter which integration or custom component that you use. Polling can lead to missed or delayed button presses.

[azogue]

@brendan

What is the advantage of your CC over the one by robmarkcole?

After the inclusion of remote devices in HA Core, the CC from Robin was not necessary anymore, and it was doing extra calls to the hue hub just to create some entities, so we discussed how to do it better in the new context.

IMO, any HA custom integration should aim to one of 2 objectives: be included in HA Core, or evolve to be unnecessary, and what happened was a mix of both

Now, for a normal user, no CC is necessary, which is good. And there are new CC’s for those who could miss some of the old features.

About the advantages you’re asking for, I’m not sure what CC do you mean.

If you’re talking about Fast-Hue CC:

• Instead of doing additional calls to the hue (the ones done each 5s from main hue + the ones from hass-remotes ), the Fast-Hue CC modifies the 5s to any value, and even has a service to modify it anytime (it’s basically a hack over the main hue)
• It is based in modern HA, using config flows from UI, so not yaml required
• It is actively maintained

If you’re talking about Event-Sensor CC:

• It is just a way to show HA events being fired, it does not “talk” to the hue or anything else, no IO, so no extra stress for your system.
• Used with the events that the remotes fire, it won’t have false positives for state changes like the old remotes CC had
• It is based in modern HA, using config flows from UI, so not yaml required
• It is actively maintained

cc @Burningstone,

I recommend buying another zigbee router such as the ConBee that supports pushing events/states to Home Assistant and ditch the Hue hub. With the hue hub you’ll always poll the state from the hub, no matter which integration or custom component that you use. Polling can lead to missed or delayed button presses.

I suppose you’re replying to @brendan (it appeared as a reply to my msg), as I already have a conbee II stick

To @brendan, I agree 100% with @Burningstone here. If you need instant response, ditch the hue hub (if the Fast-Hue CC is not enough)

[Burningstone]

Yes this was meant for @brendan, sorry

[brendan]

Thanks for the advice.
I’ll likely look into a Conbee or other ZigBee stick, but that is a big migration for me as I started out with quite a lot of Hue devices prior to moving to Home Assistant.

[matticas]

Hi All;
I finally removed the RobMarkCole CC that was reading my Hue Dimmer Switches.
His CC had the devices as States - which meant I could use them to trigger (I don’t use) or as a Condition (used in all my motion-light automations).
I have the latest Hue Integration, and found the “devices” part to use a Dimmer to trigger an automation, but I can’t work out how to use it as a condition state?
Can someone please advise how? Do I need something to monitor the device and record in a variable somewhere? (i’m pretty useless with templating, I copy and paste a lot of stuff).
TIA

[Alamapstieks]

Am I missing something? I am on the latest HA and have been using the integrated HUE app, but this has never shown me more than just battery levels for Hue switches? I would really like to be able to fully integrate my hue switches. Do I need to drop and reinstall the Hue integration (and if I do will that no break all my Hue automations?)

Thanks

[Burningstone]

The switches don’t work with entity states, but rather with events, so you’ll only see the battery level entity for the switches.
Go to Developer Gools -> Events and then listen for the event hue_event, now you should see events whenever you press a button on the remote. This events can then be used in automations.

[Alamapstieks]

Thanks @Burningstone, seems a bit clunky but I will see if I can make it work…

[Mariusthvdb (Marius)]

using Custom integration Eventsensor will make that even easier, and, have the switches show a state/event in the frontend:

[Burningstone]

Through the UI you should also be able to work with device triggers. And now with the blueprints everything should be doable with one single blueprint for all remotes of the same type. I created one for the Hue Dimmer switch with DeCONZ, but the concept is the same for Hue.

[Hellis81]

If I use this event sensor on “hue” and add an IKEA Trådfri remote, will this integration notice the button presses?

[Mariusthvdb (Marius)]

it will notice events registered in HA. Core Ikea integration doesn’t register button presses. You need a 3d party controller for that, like the Conbee II. see Where are the new entities for Hue (dimmer and tap) switches