Yes, same here. Well, it was a disconnect of the event stream that would foul Homekit usage. I discovered many do what I also found as a solution in the meanwhile. . .
While the even stream still disconnects (sometimes not for hours, but commonly it occurs about once an hour), I don't notice it.
Next time this happens. Go to the Hub driver, and click connect the refresh. If this works, then you are experiencing the same issue as me and others.
Thank you @armand, Not sure why I was ignoring the actual Hub devices while looking for a solution. Everything is working perfectly at the moment. No doubt because I'm looking right at them... But I will try refreshing the hub driver as you suggest when they decide to misbehave again.
Does it tell me anything that BOTH my hubs appear to misbehave at the same time?
Thank you @bob.t , I'll try the refresh option suggested by @armand first and, if I don't get the results I'm hoping for, I'll try your detailed suggestion.
Chiming in here. I have the same issue where the "advanced hue bridge" goes offline almost daily. But the default "hue bridge" stays connected. Clicking on "connect" in the app device brings it back online. Reading this thread I didn't see if you can have both apps installed and running? Could that be an issue. I need the advanced version as it supports the 4 button remotes. I'll enable debug logging and see if I can get more information.
I'm not running multiple apps/instances, but they both can be utilized at the same time. Can't speak to the pros/cons of the practice.
What do you mean by "both apps"?
The code supports having multiple instances of the app installed, so long as each instance is talking to a different Hue hub. This is not a problem. The event stream is just a web call to the hub that never closes, so the code picks up events in near real time.
It is painfully obvious that everyone is using the event stream. I'm going to just put a toggle to enable/disable it, and if enabled I will keep it online. I will get this out ASAP
The watchdog timer should be fixed. The refresh and watchdog timers use a cron scheduler now, instead of frequent unsubscribe/runIn events. Also, the bug was fixed that prevented the hub device from determining the current state of the system. I fixed this by implementing some code from my Roku driver that tracks state in volatile state memory, which enables me to read a previously set state w/o having to wait for the HE system to commit the change to the internal state DB.
TL/DR; this should be fairly solid now. Next is to work with HE devs to determine why their system is disconnecting the eventStream on what appears to be a random occurrence.
Encouraging, and appreciated.
Just updated, it's bedtime here. I presume a reboot isn't called for (?).
@bob.t and @armand for context here is what I mean.
When I first bought the C-8 I installed the built-in Hue bridge Integration;
Hue Bridge Integration | Hubitat Documentation
I used that with a few Hue light bulbs for a few months. All worked well.
I thought I would get a little fancy with my home setup and I purchased some Hue dimmer switches;
Hue Dimmer Switch (latest model) | Philips Hue EN-CA (philips-hue.com)
I noticed that the built-in app does not support the dimmer switches, only if you use them as a zigbee devices. I wanted to use them through the Hue Smart hub as I've had hit or miss success with some zigbee devices directly with Hubitat (Namely sonoff)
So I did some searching and installed this [Advanced Hue Bridge Integration] and used it for the dimmer switches. Works great. Then I noticed a day or 2 later the dimmer switch was not responding. I checked the Hue smart hub, switches were there and working, checked Hubitat and the [Advanced Hue Bridge] and saw it was "offline"
So this is where I'm at. I have both integrations installed and running. The built-in is running my lights, the advanced is running my dimmer switches. I haven't noticed the built-in go offline.
Yes I know I could move everything into the [advanced hue bridge] ie; the lights. and remove the built-in version. But I haven't gotten around to that as I just wanted to see if the dimmer switches would work on the advanced.
That is why I have and asked if both the built-in and the advanced can run at the same time.
I hope I explained this properly. Please feel free to ask me any more details. I'll be happy to provide and help in anyway.
btw, @armand thank you and I appreciate your work.
Canuk,
I use those Hue 4-button dimmers too. I wanted to eke something slightly different from them than Hue offers, so I use them installed in HE. The only disappointment is dimming lags severely making dimming unusable, so I simulate dimming changes.
It got a little complicated at a point, using them for a lighting group PLUS as an off for a 2nd light or group of lights in the same room that are also controlled by Lutron Rotary Aurora's. But in the end my goals were attainable.
Just saying. . . this works well for me with one instance of AHBI alone. I recently replaced two motion sensors that seemed to have stopped Zigbee drops, and while the Hue still has disconnects Armand's update works better now to regain itself w/o intervention.
No reboot required. But you will want to use the Save Settings feature of the hub device to activate the new schedules. There does not appear to be a way to migrate this over automatically. A reboot, or save settings will update the schedulers.
The built-in Hue integration does not go offline, because it does not implement the event stream service for push notifications that last I checked. Their code only uses the refresh mechanisms to query the state of the groups and lights. Their systems is the same as mine, if you only used the refresh, and no event stream, except that my system allows for refreshing a single device, and I support scenes -- this is the reason I originally created my driver, to support scenes, and per-device refresh.
The two systems do not collide with each other. You may use them both if you wish. The reason mine was going offline is because the HE hub is calling a method in my code to tell me the event stream was stopped. I do not know why it is doing this. I created a watchdog timer to monitor this, and keep the hub online, but code had a bug that was resulting in occasional failures to reconnect. This should be fixed now. Let me know if the problem persists.
Between @armand 's update and @bob.t 's suggested reconnection rule (I added a notification so I would know when it is invoked) my system appears to have settled down and is consistently reporting states back to Hubitat so my other, dependent rules are now working properly.
So Thank You!
Now, on to the next issue. Every now and then the Hue lights associated with one or both of my bridges just decide they want to be off and will turn themselves off no matter how or how often they are turned back on. I can turn them on via a rule, via the Hue Smart Switch or via the iConnectHue app and they will stay on for no more than 10 seconds and then turn off again.
When I look at the events for the lights, they point at the Hue bridge device as being responsible.
I've turned on both verbose and debug logging for the hub and below is what I'm seeing. I tried it twice because one set of logs seemed to indicate a problem with connection where the other does not.
I can gain relief from the issue if I reboot the hubitat hub but the issue will start again after the reboot cycle completes.
Power Cycling the Hue bridges also does not help.
This issue usually happens at night, and usually after I have run some relatively complicated scenes (I craft all my scenes as hubitat rules and then invoke them via virtual switch so I can change/control everything as needed). I've been using most of the scenes for many months now and they are definitely not running at the time the lights start misbehaving.
By the next morning things seem to be OK again.
My wife is sure I'm messing with her as she'll turn on some lights with the wall-mounted hue switch and then they turn off once she's entered the room.
While this issue is going on today, it is affecting ONLY hub bridge 1, lights on the 2nd bridge are working normally.
This is my unfiltered log where I am turning on a single light using a hubitat dashboard where the light subsequently turns off again after about 3 seconds. Pretty much all of my rules have logging enabled for exactly this kind of issue and I don't see anything interfering with the Hue light.
If anybody can make this make sense I'd appreciate it. I really do not know what I'm looking at here:
I can provide any logging needed to help fix this.
I would be happy to help. Can you DM me? I don't like polluting this with user specific trouble-shooting.
I will need to know what light is problematic, the details of that light, so I can link it back to the logs, and the logs during the event.
Thanks.
The way the system is supposed to work, is that the code never commands anything on/off based on parsed data from the hue hub. It can be the hue hub has an automation that is turning it off, or that some other automation in the HE is turning it off. It's possible my code is doing it, but I cannot foresee what that might be, because I should never be sending on/off event to the hue hub based on status change received by the hue hub.
Thank you @armand. So what I did last night was applied the new HE update to 2.3.6.135 and applied your update (1.4.6 I think?) Removed the built-in app/device moved all Hue devices over to the advanced app. Everything seems to be working right now. I'll monitor and report any issues.
This might just be a placebo effect on me, but it seems like the light status updates take longer to show. ie; If I turn on a Hue bulb with the iPhone Hue app, it won't show that status change in HE for a while. Probably a config/setting on my end. But with one less app/device driver talking to my actual Hue Smart Hub, I could tune the timings more aggressively.
Make sure to turn on the watchdog. When off, the watchdog checks the connection every minute? And when turned on, it checks every 10 seconds. When a connection is reset, the hub device issues a full refresh to make sure everything is in sync.
The hue hub is only capable of a limited number of requests per second, so you want to make sure you aren’t outpacing the hub. As for hue initiated state changes, make sure debug logging is turned off (this is a cpu hog) and watch the logs for on/off events. For groups, hue only sends on/off — no color change events, so I have to query the group to get that. This can result in a lag. For lights, more data is sent but still not everything, so I have to query the lights and groups to update their states here too, which can cause a lag, if the attribute you want is not one the hue provides in the event stream. If you have refresh turned on, don’t be too aggressive — this is just a safety net to try and keep things in-sync in case any messages failed to process. I use 10 minutes.
If you have not done so, you may want to reboot your hub to drop any erroneously running code from working memory that does not automatically get cleaned up by updating drivers and apps.
To narrow this down, watch the logs and see from turning on a light to the log caching it was turned on, how long did it take. If you have rules interacting with the integration — like reconnecting, or forcing a refresh, this can slow things down. Now that the watchdog timer is working correctly you should trust it to do its job naturally. Sending alert messages when the system goes offline and doesn’t go back online within a tolerance of 20 seconds would impact performance much but if doing it immediately, and if you have network issues that cause frequent drops, then this can overload the HE hub
ok, I've configured the settings as you recommended and rebooted. Will keep you posted if anything weird happens.
Sounds good.
Hi @armand
I'm experiencing an unusual issue using the Advanced Hue Integration on a my new C8 hub.
For no apparent reason, any Hue light or light group turned on, switches off after about a second - this happens when triggered via a rule or if the virtual switch is manually activated on the Hubitat hub.
When the above problem state manifests, even turning any light on (or all the lights) in the in the Hue app itself, something on the Hubitat hub turns them off within a second.
This has now occurred about tree times in the past two months on my C8 hub, but never on my C7 after a migration from the C7 to C8.
Troubleshooting followed;
It's almost as if there is a rule that has a trigger to turn off all Hue lights as soon as it detects any one of them turning on, but I definitely do not have any rule close to that, the problem disappears after a Hubitat hub restart and other non-Hue lights are not impacted.
I've turned on diagnostic logging as there was nothing of note in the logs before.
Any other ideas please?
By chance were any of the lights at 1% dim level when you turned them off? It hasn't happened to me in a while but that was somewhat of a regular issue with some of my lights that I would turn off at 1% at sunrise (nightlights). When the rule would turn them back on later they would just turn off immediately. Sometimes just one bulb, sometimes multiple.
However I moved a bunch of my light automations over to HomeKit to take advantage of adaptive lighting and it hasn't happened since.
But I do have a recurring issue of when dimming to 1% the light in my bedroom using alexa it will almost always shut the light off. Sometimes I have to ask her 2-3 times before it actually stays on. I'm not sure if thats due to the integration or not. Could just be stupid alexa too.
Download the Hubitat app
