Hi,
Sometimes I find my hub in an inconsistent situation. (some automations do not work)
when I check the Web UI, I see the 2 notifications:
- Zigbee network offline
- High CPU Load
This sometimes happen in 2-3 days uptime , sometimes in a week of uptime. And when I reboot the hub the problem goes away and hub performs normally.
Then I check the "runtime stats" on the UI.
I see that the internal "Hue Bridge Integration" uses the CPU mostly.
Please see the output below, this is after a 3 hour uptime:
Is this normal for Hue bridge ?
And if it is normal, then what is causing my Hub perform bad ?
This is a C4 hub with firmware: 2.2.7.126
Likely corrupt db. make a backup and download to your pc. Do a soft reset and restore the file you saved to your pc. This will ensure a clean db. I'd also upgrade to the latest firmware. (Thats just me though)
1 Like
If you feel comfortable with updating to 2.2.8, please do so.
2.2.8 has some performance improvements over 2.2.7.
2 Likes
well actually this is not new. It has been happening for the last 2 months. And when it occured first I did clean DB method. It did not solve the issue.
Also at first it was an older firmware then I upgraded at least 2 times.
I just did not do the last update. I'll do it now but I'm not sure it will solve the problem.
really ? I did not notice it in the release notes.
but I will try the update.
They refer to it as “various performance enhancements” at the end of the 2.2.8 release notes.
4 Likes
I have exactly the same issue, and under the same circumstances.
I always run the latest update as soon as it's available and reloading the db or rebooting either the HE or the Hue hub does not fix the problem.
The Hue is on a different Zigbee channel than the HE setup, and most of my Zigbee lights are on the Hue.
Hue commands from HE are often ignored or very delayed; the same lights controlled form the Hue app directly work essentially instantaneously.
Wonder if anyone has any ideas about this.
What are you using? The built in integration or cocohue? I reccomend cocohue and make sure both your hubitat and hue bridge have static ip's
1 Like
Both are on static IPs.
I was using the built in integration.
I have 'converted' to the cocohue and am testing it.
The performance seems identical, so far. Dreadfully slow to activate the function from the HE side to the Hue side.
I will wait to see if the HE cpu load warning messages come back, or if the zigbee radio gets turned off again.
Strange, my connection to hue is instantaneous. I'd say as fast as my Lutron integration. I wonder what else is at play here.
1 Like
My Hue integration is also as 'fast' as my Lutron integration ... as long as I am manually 'doing' it (controlling the Hue-attached bulb) from the HE user interface.
In the troublesome situation, HE is 'doing' it from an automation step, which is triggered by manually changing the state of a physical Zwave wall switch. The Zwave controlled light of course comes on quickly, and the event shows up in the log simultaneously.
This is a new Zooz ZEN77 switch (700 series).
But the automation step that is supposed to then turn on the Hue attached bulb across the room takes anywhere from 15 seconds to a minute or sometimes never.
There is a 'matching' automation command to turn the Hue bulb off when the Zwave physical switch is turned off, but that is also impaired, although seemingly differently.
Dumb question. Have you tried a different switch (even a zigbee outlet) as the trigger to see if it changes anything? What happenes if you use a virtual switch as the trigger then hit the virtual switch?
1 Like
That's not a dumb question! It's one of the next completely logical ideas ... which of course I already tried.
The virtual switch is as fast to operate the Hue bulb as it is when I (a) directly control the Hue bulb 'presence' in HE or (b) control the Hue bulb from the Hue app.
It's only the physical-switch-triggered process that goes awry.
One additional step I have not yet tried is to set the physical switch toggle to operate a virtual device, see how fast THAT works, then maybe map that virtual device to the desired automation.
This is spaghetti style automation of course, but if it works, hey. I will see.
Another option may be to group the lights instead and see if that improves speed. So group the lights, then have the switch turn on the light (btw I assume it's not a smart bulb attached to a smart switch is it?)
Nothing complicated here. No cascaded smart devices, no fancy pants anything.
It's simply a Zwave wall dimmer on one side of a room trying to turn on a bulb on the other side of the room. And then off again.
This oughta just work.
Why do I see dozens of entries in my log for the dimmer manual activation? Shouldn't there be just one?
Hmm. More sleuthing is needed. I do know this used to work well before the rash of recent HE upgrades.
Check driver, also perhaps re pair the device? (Running out of spitballs here)
I tried using the ZEN77 driver as supplied in HE and also the generic Zwave dimmer drivers 'plus' and 'smart' with no change in effect.
(This doesn't have any security enabled, if that was something you're wondering.)
Next thing to do is to alter the trigger device to be a different device. That will isolate the problem to either the ZEN77 generally, or, to THIS particular one.
1 Like
I was thinking I've seen anomalous behavior that repairing seems to correct..
That is next on the list. Partially due to doing so being a huge pain in the butt. This switch is just out of proximal hub range, so I have to drag out a long cable and a battery, and do it all fast so as not to have the Zwave mesh try to rebuild.
Hmmmm... that makes me think about maybe throwing a beaming repeater into the mix if you don't have one already (Ring v2 seems awesome) If it's routing direct that could be a problem instead of routing through a closer device. I mean you shouldn't have problems pairing from a distance (I only ever pair locks next to the hub) Again just spitballing here. I'm sure you've though of most of this.
