I had the same issue. I was able to resolve it by running through the setup process (after hub linking) without doing anything else. Basically, my goal was to get the app installed before it decided to refresh. That worked, and once the app was installed I went back and added bulbs and groups. With the app installed and in the apps list, I no longer get 404's when the Hue integration app refreshes.
Scenes are on the agenda, just didnât make this initial release. We debated on how to handle groups. We decided to follow the way Hue Groups works and try to stay in sync.
1 Like
Should the integration be keeping track of light state? I noticed that the Hue device states in Hubitat donât seem to be updating if I do something outside of Hubitat (e.g. turn off a light with the Hue app), at least not reliably, and not very quickly.
I could create a polling rule like I have for some of my zwave switches, but apparently thereâs a more efficient way to get status info directly from the hub. Whatever the ST hub is doing, it shows state updates within a second or two when a light is updated outside of ST.
The ST hub just spams poll every 5 seconds, as far as I know. 
Iâm on a macOS High Sierra and Safari
HmmmmâŚit seems faster than that. When I toggle a light in the Hue app, the ST app on my phone shows the light change state literally within 1 second (sometimes 2).
It could be a push notification of some sort then. Interesting.
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.
