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

[azogue]

@pav

That may be as it is, but I guess that doesn’t prevent the device triggers built upon these selectively ‘registered presses’ be error-prone because of missed presses (because the release may just as well be missed as the click) … ?

It shouldn’t, as the bridge always stores the last action (–> the ‘release’ event).
It could happen that ‘the photo’ of 1 update gets in the middle of an action (in that case the ‘click’ is processed), but in the next update it would get the release. So the release is not lost, only will have a lot of delay! (a full update interval).

Aah, don’t we all hate to have to resort to polling devices

Yes, we do

In my case, I moved part of my zigbee gear to one conbee stick (connected to the RPI4 running HA).
In particular, I moved the motion sensors and 3 of 6 remotes, and also a pair of rooms with lights that I never control with the Hue app (to maintain a second zigbee mesh to support those sensors), and I’m very happy with the results.

I didn’t move everything, as the alternative is not without setbacks:

• The Hue mobile app is really good for manual setting of lights and ambiances, much better than current lovelace UI,
• The Philips Ambilight + Hue integration for the TV, can’t miss that
• Some little things, like Hue labs ‘candles’ simulations and alike.
• 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)

But as it looks like Philips is never going to give us a pushing API, if instant response is in need, that is the way to do it.

[azogue]

@Mariusthvdb

does your new CC for setting the polling interval conflict with the latest version of CC Huesensor, where polling is set fixed in the CC?

Yes, of course. But there are details:

• HueSensor CC is already deprecated, and had the remotes removed, so it only implements things that are already in main hue. It works with its own schedule update, so no, it doesn’t have any conflict. But there is no reason to use it now.
• HueRemotes CC in the last version is sharing the data update coordinator with the main hue, and changing it to its own fixed fast refresh rate, so yes, if you also use the new CC it will go crazy changing the update interval between the 2 values (remote CC vs fasthue CC). So don’t use both!

The reason to make fasthue is to make HueRemotes CC unnecessary, as the only real feature that is adding now is the fast refresh rate. With fasthue you have a dynamic refresh rate, independent for each bridge, plus UI config without HA restart, and it is basically a hack to change the fixed 5s scan_interval.

My motivation to implement it was just to hack my hue integration to poll the 3 remaining remotes in the hue network faster than /5s (2s for me is perfect, as I have automations triggering on hold button releases, and simple presses configured in Hue app).

As I don’t use anything more to talk with the Hue bridge (only HA + Ambilight TV + ocasional manual usage of Hue app), and I know my system is very stable even polling at 1Hz, that is the best configuration for me.

Combined with the eventsensor CC to create sensor entities for all remotes (hue + deconz zigbee meshes), because I like to see the history of button presses, that is by far the optimal combination for me, and I think it may be useful for anyone complaining about the 5s polling of hue, as it will not extra-hammer the hub nor create any interference with the main hue (what it does is equivalent to manually edit the components/hue/sensor_base.py file to change the 5s to anything >= 1s)

[Mariusthvdb (Marius)]

thanks @azogue

thanks for confirming

@azogue

if you also use the new CC it will go crazy changing the update interval between the 2 values (remote CC vs fasthue CC). So don’t use both!

I feared as much. Think this warrants a warning on both repo’s since people might not realize this.

Since 108.4, I’ve noticed my Hue system go much more reliable, and the constant going ‘unavailable’ of the core Hue entities seems to have calmed down enormously !
So, because of that, I’ve taken out the CC Huesensor/remote integrations completely. I do miss some ‘attributes’, most prominently the ‘config.on’ for the binary_sensors, which I need to be able to switch the motion sensors on/off.

if we would have the ‘config.on’ attribute in core we could simply create a template switch. Or maybe even a core switch would be even better…

Without it we need solutions like this:

      corridor_office_sensor_motion_switch:
        friendly_name: 'Corridor office motion sensor switch'
        command_on: >
          curl -X PUT -d '{"on":true}' "http://192.168.1.212/api/dmredactedQq/sensors/28/config/"
        command_off: >
          curl -X PUT -d '{"on":false}' "http://192.168.1.212/api/dmredactedQq/sensors/28/config/"
        command_state: curl http://192.168.1.212/api/dmredactedQq/sensors/28/
        value_template: >
          {{value_json.config.on}}

to switch from within HA Lovelace frontend, in backend automations/logic.

But other than that, the system indeed seems very reliable, hope that is here to stay.

I have 2 more wishes to go into core: the hue device_tracker, with its attributes, and the daylight sensor, which I now make using

  - platform: command_line
    name: Hue Daylight
    command: !secret hue_daylight_command
    value_template: >
      {{'on' if value_json.state.daylight == True else 'off'}}
    json_attributes:
      - state
      - config
      - name
      - type
      - modelid
      - manufacturername
      - swversion
    scan_interval: 300

Your eventsensor is working beautifully, and, since I don’t use the remotes to control from within HA, but simply want a monitoring system, it suffices 100%. Again: thanks!

A bit hesitant to test the polling adjustment in fasthue, now my system has finally stabilized, but as I read your suggestions in the repo, it doesn’t hurt, and taking it out brings back the system to its core state

Cheers.

[azogue]

@Mariusthvdb

I feared as much. Think this warrants a warning on both repo’s since people might not realize this.

It won’t break anything, it is just a silly thing to do (set a scan_interval of X in one CC and another Y in the other)

A bit hesitant to test the polling adjustment in fasthue , now my system has finally stabilized

If you don’t need to poll faster why would you try it? Try always to reduce complexity, not the opposite

I have 2 more wishes to go into core: the hue device_tracker, with its attributes, and the daylight sensor, which I now make using

You won’t see me trying to implement that, sorry. For me (and others) it has no sense, as they are virtual sensors (no real devices involved) and they don’t solve anything that is better solvable other way.

• What do you need from the daylight sensor that you cannot get from the sun component, which is much more powerful?
• There are lots of better tracking tools available in HA that the one implemented by the Hue bridge, IMHO. For example, have you tried the mobile_app tracking system?

[azogue]

@Mariusthvdb

I do miss some ‘attributes’, most prominently the ‘config.on’ for the binary_sensors, which I need to be able to switch the motion sensors on/off.

BTW, why do you need to tell the motion sensor to turn off/on (or even just the bridge, not sure about how that feature works, if at device level or at bridge level)

If it is just to ignore the binary sensors in some automations, it is a better solution to use HA input_boolean entities to make that kind of toggles, IMHO.

[Mariusthvdb (Marius)]

@azogue

why do you need to tell the motion sensor to turn off/on

because in several scene’s in my HA logic, I don’t want the motion sensors to be sensing motion.
Ive set the motion sensors thresholds and sensitivity in the App. When watching a movie, I dont want my auditorium motion sensors to trigger the lights, so turn then off automatically in my Movie script. After that, when asleep, I want them to watch over the house again, and turn them on.

@azogue

What do you need from the daylight sensor that you cannot get from the sun component, which is much more powerful?

as said, I like to monitor the internal logic of Hue. Hue uses this to calculate their routines, and for the sake of being able to correlate to these, it is very nice to have the identical sensor in Ha available.

@azogue

There are lots of better tracking tools available in HA that the one implemented by the Hue bridge, IMHO. For example, have you tried the mobile_app tracking system?

again, Hue uses it for the routines home/away, which can be streamlined into Ha using the tracker. And monitored.

other than that I use different tracking tools of course. Life360 is the best for now, especially considering the flaws the mobile_app is experiencing at the moment (seems to be an issue with iOS versioning, many people have posted, not so many dev;'s have replied). Not to mention the impact the mobile_app has on the device…and Ha for that matter, with all the sensors being created.

[pav (Paul Vanderperren)]

Hi @azogue,

It shouldn’t, as the bridge always stores the last action (–> the ‘release’ event).
It could happen that ‘the photo’ of 1 update gets in the middle of an action (in that case the ‘click’ is processed), but in the next update it would get the release. So the release is not lost, only will have a lot of delay! (a full update interval).

My - admittedly limited - testing seems to contradict this. Having both your CC and Robin’s for the time being running in parallel I can compare results : while being in unisono let’s say 3 out of 4 times, I notice ‘your’ sensor now and then missing a beat, in the sense where its state ends in ‘click’ iso ‘release’ - thus NOT getting the release status and certainly not ‘catching up’ after any update interval (see enclosed image where the top sensor is Robin’s, and yours is underneath).

So I still stand behind my saying that it now and then will be missing the remote’s action. At the same time I also still think your (much appreciated) CC simply is the ‘victim’ of the flaw in the Hue integration, not catching/firing all necessary events …

Oh well, over to Zigbee2mqtt I guess - at least with my remotes, because as it happens there’s a brandnew Philips TV with Ambilight waiting to be unpacked & installed

[azogue]

@pav

while being in unisono let’s say 3 out of 4 times, I notice ‘your’ sensor now and then missing a beat, in the sense where its state ends in ‘click’ iso ‘release’ - thus NOT getting the release status and certainly not ‘catching up’ after any update interval

mmm, that is bad! I’ll try to reproduce it and fix it in HA Core, as I assume the problem is that there is no HA event with the “4_click_up” press, right? (so it is not related to eventsensor, which is a very simple CC).

Supposedly, there is some logic around the bridge 'lastupdated' timestamp, to decide if the remote state is a new one. In the change from “press” to “release” that field should be updated, and then another event should fire. I’ll try to check that logic.

BTW, just to understand the context, your config is as follows, right?

• main Hue in HA >= v0.108
• Robin’s Hass-remotes CC, so the new one (not the old “Hass-sensors”), and last updated in past month, but not this week.
• EventSensor CC showing remotes by monitoring hue_event

at least with my remotes, because as it happens there’s a brandnew Philips TV with Ambilight waiting to be unpacked & installed

Enjoy
We have the ambilight always on, and at afternoon/night, to see some movie or tv show, we use the Hue+Ambilight feature and it’s gorgeous

[Mariusthvdb (Marius)]

@azogue

Hue+Ambilight

can’t believe I missed that… having a full Hue setup and ambilight tv… what exactly are you referring to here? Is that core HA/Hue?

[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