I suppose you could repeat the "Flash" command once every 30 seconds (or is it 15...) or so, but I suspect that won't work well with large numbers of bulbs given the rate-limts Hue recommends. Dynamic Scenes (just guessing) might be able to simulate this effect better in the future, but I haven't looked at those much yet and will probably only will once the v2 API appears to stabilize.
2 Likes
@bertabcd1234 first of all, kudos for blowing the official Hue integration out of the water. The folks at Hubitat should just adopt your integration as the official one and call it a day.
I switched my second Hue hub to CoCo recently and noticed that some lights won't turn off when instructed by a Simple Automation Rule. The lights that will stay on are pretty random every time, and I am not sure how to debug it. I see that the rule fires, most of the lights do turn off, but not all. Any advice on where to start looking?
My best advice would be to enable debug logging for the affected lights and see if the commands are called (they should be if the apps log that they are, but the driver will log things like off() of the "Off" command is called, os this is another way to tell). Second would be to see if you notice any errors. If you're using the new eventstream/push option, you may also wish to consider reverting to the "classic"/v1 Hue API to see if that helps, though it probably won't since commands to the bulbs are still using v1 anyway.
I forget if Simple Automation Rules has a metering option (I don't think so), but if it does, that might also help in case you're running into a rate limit on the Hue Bridge. Using a group (configured on Hue and imported in CoCoHue, not a Hubitat group) instead of a bunch of individual bulbs may also help--that would reduce traffic from Hubitat to Hue and ultimately from Hue to your bulbs, either of which could be an issue if the network is getting flooded (though Hue has historically handled this quite gracefully, IMHO).
The log entries above would show up under "Logs," if you aren't familiar, either Current Logs (if the page was open) or Past Logs (if it wasn't but it hasn't been long enough for them to have been purged). Keep in mind that, per Hubitat convention, debug logs auto-disable after 30 minutes.
3 Likes
Hi @bertabcd1234 .
Do you have any idea why Hue Group "All Hue Lights" does not work normally when using on and off commands.
"All hue lights" is a group which is created automatically by Hue and CoCoHue recognizes it as one of the groups available.
If I click "on" it will turn all the light on from that Hue bridge. If I click "off" it will turn all lights off. If I leave lights "off" then after a while it changes group switch automatically to "on" but lights will stay off.
Log shows it better:
It's usually less than minute when group goes on for some reason.
I was trying to use this switch in a dashboard to control all the lights by turning them on and off when needed. Actually I can still do that but status shows lights always as "on" because "off" status stays only under that one minute.
I have two hue bridges and both work same way in CoCohue.
I don't know, but it should just be parsing the data from the Bridge. What does debug logging, if you leave it enabled and capture a "creating events from map..." (or "...from SSE" if you have that enabled, and perhaps some difference between the Hue v1 and v2 API is at Play) say?
EDIT:
I just tried this with a single Hue Bridge and was not able to replicate the problem (unless something did, in fact, turn any light back on--this is an "any on," not "all on," thing). You'd be looking for a debug log entry like this if you have the new v2/push/server-sent-events option enabled:
Or you'd see a similar log entry for createEventsFromMap(...) if you don't. That shows the data coming in from the Hue Bridge, and all CoCoHue should be doing is parsing that into events--if needed.
I'm not getting same results for some reason.
All lights from that group is at the moment off.
Hue application shows group as off.
Cocohue shows group as on:
I click "on" from cocohue:
Lights turn on.
I click "off" from cocohue:
Lights turn off.
And once again:
Turn lights on from cocohue:
And if I turn them off from cocohue:
So it does not keep status when choosing either "on" or "off". I'm not sure if there is anything weird in log except that status change which does not change status of the bulbs or status of the group in hue bridge.
EDIT: well log actually says that "SSE: groups on = true" but after that it says "..create events from map from bridge, any on = false". After that it changes switch to "off.
EDIT2:
This combination causes problem:
And with this it works normally:
Shouldn't I use SSE and poll at the same time?
You can use both at the same time, and I pretty much recommend it until the v2 API matures. But your description of the issue (that polling seemed to cause the problem) made me realize what the issue could have been.
I believe I have found and fixed it in the latest release. Update available from HPM, GitHub for manual install, or ZIP bundle for one-stop manual install; details in first post for new users. This is only necessary if you use the "All Hue Lights" group, use polling, and care about its on/off state as reported in Hubitat.
Thanks!
5 Likes
It seems to work now. Great work. I'm still testing though so I let you know if I notice any issues.
1 Like
I noticed one problem but this has been around all the time. Not sure if you are able to say what is causing it.
I had a power cut in my house and when power is back hubitat starts and so does hue bridges. They all are connected, they all have ip address..
...and hue can be controlled normally from hue app but not from hubitat. Log says:
And other bridge says same:
Restarting hue bridges or hubitat hub does no resolve this. I need to reauthorize bridges and that will fix it.
Any idea what's going on and am I the only one?
Does your Hue Bridge have a static IP? That error is an HTTP timeout. Reauthorization shouldn't be needed, but it would help since it sends a discovery commmand and would find the new IP. There should be some startup logic to handle this, too, but maybe I can try delaying it a bit. It will also happen periodically on it's own. I like to have my Bridge on a "static" (actually DHCP reserved) IP address to avoid all of this.
I have noticed this since the latest platform updates (may have been there earlier though), but thought it was weird. I have rebooted everything and Hue bridge is on a static IP address. Any ideas what I may need to do here:
All of my connected lights seem to work.
Scott
This has been discussed a few times above and is noted in the 4.0 release post. It seems to be an oddity with either Hue's v2 API or Hubitat's eventstream interface, and most such messages indeed seem spurious while things continue to work.
Yep, both have reserved ip's from dhcp. So yeah.. address never changes. Maybe it should be delayed or something because not even hue bridge reboot helps.
Well that is good to know then. I have been having some weird internet issues and the last and only thing I have not replaced yet was the network switch. Didn't know if was related or not.
The a delay wouldn't help since there's no new IP address for a possibly-still-offline Bridge to discover. 
I'm not sure what to suggest but none of my installations do this. If you're using discovery or manual IP in CoCoHue setup, maybe try switching to the other and see if it helps. I have setups using both, though my primary production setup uses the latter.
Hi, just changed to manual ip address setting so I need to test this more.
I’ve not seen this issue, but I have always used manual IP addresses on both bridges since version 1. Actually only had 1 bridge back then I guess.
Hi @bertabcd1234 . I'm having problems with Google Home integration where some of the CoCoHue groups can't be used with google home.
One question for you. Is there any differences between bulb groups in CoCoHue or are they all build same way? I ask this because Google Home (for some reason) does not accept few of my bulb groups at all but all other bulb groups are fine and can be used via google home integration.
The only issue I've seen before is if a group doesn't have all its attributes set, or at least certain ones, like "color" and "colorTemperature," under "Current States." I thought I added something a while back to initialized these to default values. Running the Seth Colors and Set Colors Temperature commands once should also do it if that is the problem (if it doesn't work, try it again with the new eventstream option disabled if you happen to have turned that on...maybe there's something weird there I haven't seen?).
1 Like
Thanks. Some of the groups were missing "saturate" and "colorTemperature" attributes. After manually activating (changing) these settings they were added to groups as attributes. After that I was able to add groups to Google Home.
