Yes - that's how it got the user details for the hub...
I think that bit worked but still stuck on that page.
Hue hub on latest firmware
Unifi networking - same subnet no vLANs - I dont know if this is a SSDP issue but it shows as off below
@kevin, I can take another look at the discovery process, but have you tried the manual IP (in CoCoHue) method if your Bridge has a static or reserved IP address? It's possible that this method would work better (turn off discovery when adding the Bridge in the app).
@mark.oswell, I I suspect your issue was just needing to press "Done" in the app after the upgrade, which I mentioned in the release notes and documentation but am open on ways to make clearer if that was an issue.
1 Like
I did and that's how I got this far with a username being picked up after pressing the Hue hub button and with the above screenshots showing that username and bridge/authorised true
Thanks for the information! I think I found and fixed the bug that prevented the bridge authorization pages from updating. This in version 4.0.1, which is now available via the usual installation methods (HPM, manual, or — new for v4 — the bundle ZIP).
The only change is during bridge discovery or manual addition, so if you are an existing v4 user, there is no reason to upgrade if you don't want to.
Also, another note for new v4 upgraders (this is not necessary after the first upgrade to any 4.x version, just the first time): be sure to open the app and hit "Done" to complete the upgrade..
3 Likes
Great , that's working now 
I cant vouch for the hub discovery as mine completed on a manually entered IP but everything is looking good.
I’m seeing around eighty to one hundred events per hour on each of my two bridges.
EDIT: I should have also mentioned that I have not seen any ill effects from this behavior in the several months I’ve been using the beta (and prebeta).
2 Likes
It shouldn't happen at all unless your Hue Bridge truly disconnects, so I'm not sure what to say for what is "normal." 
On the two Bridges and three hubs I've tested this on, sometimes I see it a few times a minute but other times not for hours at a time. I wouldn't be worried about something that only happens every minute or few. But this is just the Eventstream information coming into the Bridge driver from Hubitat, so it appears either something is odd about Hue's implementation or the library Hubitat is using to receive this stream.
I'm hoping this will get sorted out as the API matures if it is indeed a Hue oddity; in the meantime, it hasn't actually caused any problems for me (but the driver does resort to some "old" behavior if the status is reported as disconnected so you don't have to wait for a poll to get an update for changes made from Hubitat, for example).
1 Like
Just out of interest, does the V2 API support dynamic scenes?
It does, but I'm not quite there yet with the implementation. (I will also have to buy such a device to test...)
1 Like
Doesn’t that just require a (or multiple) color bulb?
The connect/disconnect thing has been constant for me (every ~2 minutes in the logs) since updating over the weekend, but I haven't noticed any ill effect. Last night, I disabled polling altogether, and so far so good.
Robert - thanks for navigating this API update -- I imagine it's a challenge (to say the least) between the API itself being muddy thus far in these early stages and some potential ism's with the HE integration itself. Overall, this seems like a great direction for Hue to go (API-wise), so I'm excited to see it happening!
ETA - just re-enabled 1-minute polling... Of course I come across an issue right after a public declaration lol. Maybe just a coincidental fluke, but re-enabling polling seems to have corrected it. Onward!
1 Like
Wait...yes. 
However, I was thinking of the new "gradient" things the v2 API can also work with, and that's something I can't test myself.
3 Likes
That’s on you 
But seriously, I do see events getting missed. It seems more common if it’s been a while since the last event. Also, groups only update on/off (an apparent api limitation) and seem to be slower to update than individual bulbs.
Ha, yep, agree on all observations there... The missed events are rare but were nonexistent prior to update, and group stuff is a wee bit slower. That slower-group thing really doesn't bother me, but I'm hopeful the missed-event thing will get sorted out (again, I realize that's all out of Robert's hands right now - I know he's doing the best he can with the info currently available, and I appreciate it!). I'm confident it'll all get cleared up sooner than later.
1 Like
Just curious, are the "missed" events just one for the event stream, and if so, do they get fixed with the next poll, or are they just gone? (That shouldn't happen, but I figured I'd ask--and it's one of the reasons I didn't recommend completely disabling polling yet.)
Also, are the commands being sent from Hubitat, or are they coming from something external? There's sort of something I could do for the first issue, but probably not much for the latter. If you're curious, with the v1 API, I set the Hubitat bulb state based on the command that was sent as soon as the Bridge responds that the HTTP request was successful, whereas I don't when using the v2 API since it should come in with the event stream (in my testing, doing both sometimes resulted in double events because they came in around the same time and the platform probably couldn't filter out the not-really-changed one). But I do wait a few seconds after event steam "disconnections" before truly considering it disconnected in light of the spurious disconnection reports the interface reports--so if it really did disconnect, some events might be "missed" until the next poll, even for commands sent from Hubitat (which is not normal with API v1).
In my case, it was 3 hue bulbs, a hue light strip, and a Hue-plug based fixture (all in main bedroom) that I turn all on/off with a Pico via Hubitat. I noticed the missed on/off events today after I turned off polling late last night.
When I re-enabled 1-minute polling, it was all back to working well, albeit a tad bit slower - maybe that was when it happened to catch the polling (or event-stream coming back on after a brief disconnect)? Or perhaps it's all in my head and I just never noticed a delay before... Hard to say... Either way, the delay was just a few seconds at worst so far - nothing too crazy.
coming from Hue dimmers or Homekit in my situation.
My Hue Outdoor Sensor stopped working when upgrading to v4. It still works well in Hue app, but stopped communicating with HE. This is what the log shows from the time of update ("Ulkoanturi" is the device name):
I tried resetting the sensor and readding it to Hue and HE. Hitting refresh in CoCoHue app’s “Select Motion Sensors” gives this in log:
CoCoHue can see the sensor, but selecting it and hitting next results in this:
Is there a fix for this / can I rollback to previous version?
I will try to find a fix. If you want to roll back in the meantime, the best way is with a hub database backup as described in the release notes.
1 Like
