Hello:
With the new firmware upgrade along with the new Hue App upgrade, there seems to be issues with hub load increase. Additionally, I cannot get into the App Integration to reconfigure it. I just get the spinning wheel that app is loading.
I did initially reconfigure the App for V2 functionality that emulates the CoCo Hue App.
Thanks for your feedback. Could you please send us a private message along with your hub id or MAC address to @support_team so we can further investigate what went wrong with your Hue integration?
Beyond the above, anything in Logs?
Currently migrating from the Coco Hue app to the updated version in the new build. I will see what happens and advise of any issues.
Lights are working fine. However, motion sensors and buttons are not updating. Event stream is connected. If I click initialize the event stream in the Hue device bridge, motion sensors and buttons respond for a minute or two and then stop responding. Event stream is still connected.
I believe the hue app is also causing my hub load to be elevated.
Please see short excerpt from log as it is very long
Unfortunately, that snippet alone isn't quite enough to be helpful. Is there a line number in the entire entry? Additionally, does any particular action on your end cause it?
There doesn’t appear to be any line number in the error log. It’s just a very long log that contains much of what is in the snippet.
No specific action that I can think of. Right now, I have both the app and dev. Bridge disabled. My hub load as a result is very low and back to normal.
The moment I enable the app and bridge, the hub load gets very elevated and it becomes almost impossible to navigate the web interface.
I suspect the issue is probably with the device bridge. But I can’t say for sure.
If there is something you could suggest or would like me to do to try and nail this down, I would be happy to try.
Did more testing this morning. Re-enabled Hue App and the Hue Bridge Device. Let it sit for a 30 minutes. Hub load fine. No logging errors.
Then re-initialized the bridge. Triggered a button and a motion sensor. Both responded for a couple of minutes and then stopped responding. Bridge load then become elevated and web interface very slow and slow responsiveness.
Looked at the logs. Only the Hue Bridge Device threw off an error exactly as I noted above. No line numbers or anything. Definitely seems to be an issue with the the Hue Bridge Device
One idea: was the Bridge set up using discovery or a manual IP? Try a DHCP reservation on your router for the Bridge if you aren't already, just to make sure the IP address isn't changing, even though it should catch up. You may also want to try switching to a set IP in the integration app instead of discovery, although that is again not something that should be a problem. But with no clues about what might be happening, it can't hurt to see if something about the discovery process might be it..,
The Bridge was setup using auto discovery when I purchased the hub a couple of years ago. I also have the IP address reserved in my router (pretty much do this with all my devices). The native hue app was working perfectly with my lights (before the new migration). I was using coco hue for the rest of my hue stuff, ie, motion sensors and buttons. That was working perfectly as well until I migrated all of those devices to the new app. As mentioned previously, my lights are working fine and are updating and controllable without issue. It's only the buttons and motion sensors
What about the advanced debug options under the app. Should I do anything with that? I did not enable debug logging of the bridge through that. Only debug via the app.
They are the same. Nothing here is likely to help, aside from maybe the option to retry the migration in the specific case that something was missed the first time around (unlikely to cause this problem, but I'm not sure what it is). I might be curious about the log output for all the device types, mostly to see what their DNIs are, which is really the only important thing migration touches on them (and definitely wouldn't apply to your new ones). 
So, I was going through the screen capturing off the debug log to post here for you (it's very large). You had asked about line numbers. At the very end of the log, I saw this.
I can send you all the screen captures of the log if you would like as it does show DNIs for all the devices, etc. But there are a lot of screen captures as it is very large.
Can you share the full entry, including the entire text plus the source (device or possibly app where it originated, and the driver name--the one piece you won't find in any of that)?
For the logs with DNIs, the most interesting things would be anything that ends with a one or two digit number instead of a long GUID-looking string (assuming you are using the V2 API). Otherwise, it's probably mostly long and boring, but something that's there to more easily catch odd cases like that. 
I'm sorry, I'm not sure what you mean by " (device or possibly app where it originated, and the driver name--the one piece you won't find in any of that)".
As for the whole log. It is quite large. There are 33 pages worth of captures. Even combining them into one pdf is still over 18MB. What is the best why to send?
The driver name is "Type" on the device detail page. The rest should be apparent from the parts of the log entry that were cut off in the screenshot above (I.e., the full entry, including where it came from, is most helpful, not just the line number or snippet of the error).
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.
Download the Hubitat app
