if switch to chrome i donât have the issueâŚ
Thanks for that info. Safari on Mac is troublesome. Trying to reproduce this issue.
That was a good decision
1 Like
It is updating the state, just not in the web UI unless you press ON or OFF in Hubitat. I tested with a Hue Dimmer that is activating scenes. Iâm able to turn the light OFF with the dimmer and immediately back on with Hubitat and vise versa, even though it says in the web UI that the state has not changed.
Maybe it can be fixed, but honestly itâs not a big deal for me, because I know my automation is going to work correctly and with fast response time. The web UI isnât for daily control. The Mobile app will need to be responsive, but the way the web UI is responding I find perfectly acceptable for building and testing automations.
Controlling the lights works fine, but you would have trouble creating rules that depend on a lightâs state. For example, âturn on light A and set it to 50%, but only if itâs currently offâ. That kind of rule would prevent an automation from messing with a light that had been turned on manually. It wouldnât be reliable if Hubitat doesnât update the states of Hue lights.
I think you misunderstand what I was saying.
For example:
- You open the Hue app on your phone and you also have the Hubitat web UI with the Hue Integration for the same light.
- You turn the light ON with the Hue app
- Immediately try to turn the light OFF with Hubitat.
- Do the opposite.
Even though the Hubitat web UI is not displaying that the light is ON or OFF when itâs controlled by the Hue app, it does have the updated state. If it didnât, you would not be able to immediately do the opposite with one over the other. In other words, if Hubitat thought the light was still OFF when the Hue app turned it ON, then pressing the OFF button in Hubitat would do nothing, because it would think the light was still OFF, but it doesnât.
I understand the words ON and OFF are not updating when the Hue app is changing the state, but that will not affect automation. Try building an automation with RM. It will work as expected.
The hub should sync with bridge and keep states updated. Donât have the refresh interval off the top of my head, but its a few seconds.
1 Like
Ah, I did misunderstand what you were saying, but after investigating a bit more, the Hubitat web UI does accurately reflect what the hub thinks the light state is. I created a rule to toggle a Z-Wave switch when a Hue light's switch state changed. The on/off state value in the UI always updated at the same time the rule fired.
That implies that Hubitat is actually trying to be efficient by only sending commands that will change the current state. Instead, the hub appears to send the command you tell it to when you hit a button regardless of what state it thinks the device is in. If I hit 'off' in the Hue app and 'on' in the Hubitat UI at almost the same time for a light, the light will briefly dim and then turn on again. That would imply that the hub received a state update before the light had even finished transitioning to off, which seems unlikely.
In any case, Hubitat does eventually update Hue device states, but the refresh seems to be on the order of 30-40 seconds, which is kind of a lot.
Itâs all so new, Iâm still testing and adjusting my existing rules which no longer need virtual switches to control Hue and added Stringify flows I was also using to compensate for inadequacies with ST Smart Lighting rules that wouldnât always fire when I wanted them to.
So far, my test are showing that RM and Hue Integration are working exactly as Iâm expecting. 
2 Likes
@patrick: Is it intended that when you change the color temperature for a currently off bulb, the bulb also turns on automatically? I noticed this for Hue bulbs but this may affect other color/temperature adjustable bulb drivers too.
This is causing some issues in my automations. I have a Circadian color lighting app that manages my entire houseâs lighting. It is supposed to periodically correct bulb temperatures and colors so that they always turn on in the correct settings. However, on Hubitat, every adjustment results in all lamps turning on.
On ST, this is not the case and color as well as temperature adjustments are reflected in attributes, but without turning the bulb. Would it be possible to align Hubitat with that approach too, please?
When setting up Pico mapping with Hue Integration, Iâm able to adjust brightness level by selecting several bulbs, but not by selecting the group. Is that intended behavior?
Tested with both Button Controllers app and ABC app by @stephack. Same result for each, cannot brighten or dim a Hue groups.
I just tested this with my remotec. Brightness adjustments do work. The problem is with the device refreshes. The first button press increments the level correctly, but because the device status does not update immediately, the second button press is calculating the new level based on the old value. Therefore nothing changes.
If you wait a couple of seconds and press again, it will increment the level correctly.
Try this with the device page open and look at the level while hitting the button. You will see that the level only adjusts when the device updates its level value. This is ânormalâ but a bit of a pain. Hopefully we can get near instant hue device reporting in the future.
1 Like
We could likely have a great debate on this, but yes changing a bulb attribute will turn it on.
I see what youâre saying. If I use a group, I have to wait 6 seconds before I can press a button again to level up/down, otherwise the next press does nothing and forces me to wait another 6 seconds.
However, when I select each of the individual lights in that same group and not the group itself, then I can rapid-fire click the button and the lights will level up/down with almost no pause between levels. This is so much faster than the Node.js setup was!
1 Like
I have not seen this to be the case. I also have a circadian app running on ST that updates color temp throughout the day. I had to set it up to only adjust the color temp of lights that were already on, because updating attributes of lights that were off would turn them on.
I also just tried this out in the ST app; updating an attribute there will also cause a light to turn on.
We'd love to have near instant reporting as well. But hue bridge api doesn't support any change notification. So polling is the only option. You can create a rule to do a refresh more aggressively if you want to overcome our default refresh poll.
Itâs been requested literally hundreds of times over the last 4 years. Philips is completely uninterested in supporting push notifications. RaspBee is listed as an alternative though, here:. Reacting to tap switches | Page 3 | Philips Hue API
We could likely have a great debate on this, but yes changing a bulb attribute will turn it on.
I have not seen this to be the case. I also have a circadian app running on ST that updates color temp throughout the day. I had to set it up to only adjust the color temp of lights that were already on, because updating attributes of lights that were off would turn them on.
That's odd, let me investigate further then. Thanks for your responses.
Cause the same logic seems to work fine on ST and not on Hubitat. So I assumed this may have been the issue.
@jason0x43 Could you please confirm if you were using just the device screen or some app like webCoRE/grrovy code to change the bulb temperature?
That was my understanding as well, but I can't imagine ST is polling as fast as they'd need to for the app to update so quickly. I mean, I consistently see the ST app update light states within 1 second of changing them in the Hue app. It'd be interesting to know what they're doing.
Instant Hue state updates aren't (currently) a huge issue for me, I just noticed the discrepancy between the ST's Hue implementation and Hubitat's, and wondered if maybe I was missing something.
For my "just tried this out in the ST app" statement, I was using the ST device screen for a Hue light.
