Adds support for on/off events from scenes (if using the v2 API/eventstream/SSE option -- this information is in that data, no more heuristics like v1 necessary, though those are still there)
Tweaks to the setLevel() command to work better with the current/new Hubitat mobile app and possibly web-based API endpoints
Minor changes and preparation for additional v2 API use in the future.
If you want to upgrade to what will likely be version 5.x in the future and are currently using version 3.x or older, you will need to upgrade to version 4.x in between. (I am making some changes in 5.x that will not be compatible with direct upgrades from 3.x and older versions. I'm guessing this would not affect many people since 4.x has been available for quite some time and anyone interested in updating probably has already...but if not, now is a good time to consider doing so.)
This may be the last release in the 4.x series, with possibly breaking changes in the 5.x series to include the removal of deprecated features, including Hue Labs activators, effects (I'll look into dynamic scenes to compensate), prestaging preferences (possibly the commands too--never really like how they were sort of faked to start, unless anyone feels strongly), and possibly other changes. The v4.x series will remain around indefinitely for anyone who likes things as-is; it's been around for a while and (even if possibly not maintained) I'd consider it pretty stable at this point.
I received this small error today from CoCoHue, not sure what weird and wonderful event caused the network error, but my eye went right to "communiating"
dev:4392024-08-21 08:36:54.046 PMwarnError communiating with Hue Bridge: HTTP 408
That's a timeout, which could be for a number of reasons, including your bridge being offline (or too slow to respond for some reason), having changed IP address and the hub hasn't caught up yet, or other causes.
Yeah, definitely a timeout. I had just pushed an update to my Ubiquiti UDR, and there was a brief intermission while the gnomes in the udr changed the reel.
With regard to "Mimic Presence" which is available as a built-in automation, I have been able to get to it via the API using... GET https://<ip address>/clip/v2/resource/behavior_instance
This lists all the scripts and automations which have been instantiated.
I can then start/stop the automation using.... "PUT https://<ip address>/clip/v2/resource/behavior_instance/<instance id> with the body....
{
"pm_state": "stopped" (or started)
}"
I understand if you are not really interested in adding support for "behaviors" to your app.
For now I can just (I think) use the Rule Machine for starting/stopping the automation. I thought I would post this here in case anyone else was trying to do something similar.
Thanks for the information! I may look into that some day (no guarantees) but can say for the moment I am concentrating on other features and changes. One thing that has changed since I wrote the above last year is that I would probably not recommend Hue Labs for this anymore, although if you keep a version of CoCoHue and Hue Bridge settings where it was/is working, it should at least continue to do so--but that doesn't sound applicable to this automation in the first place.
Quick questions: Would it be possible/wise to install Beta 1 on my test hub while 4.1.9 is installed and running over on my main C-7? Does the Bundle assume/require that an earlier version is already installed?
If there's some method for me to force an update on its DNI (and that of my other long-installed Hue bulbs), lemme know, and I'll give it another go. Otherwise, I don't really use Hue Scenes and won't miss this module.
NOTE: Clicking "Done" on that error page then throws me (unexpectedly) into the "Select Button Devices" config dialog.
After uploading the Bundle and clicking Done in the main app, I then clicked "Select Bulbs" and noticed all the listed devices were unselected (whereas in v5b1 I had 1 - "Fireplace" - selected). So I ticked "Fireplace" and proceeded, in hopes that v5b2 could work its magic updating the DNI to V2 format. The Logs above show that there may have been a hiccup in that process.
Further evidence of a hiccup is that I wound up with both an old and new copy of "Fireplace" under Devices:
I'll continue poking at this a bit to see what's what, which device functions, whether any Debug logs of interest get thrown.... but will close by noting that returning to Apps > CoCo Hue put me back onto this screen:
...which at first seemed to hang there, but clicking "Refresh Bridge List" got the drop-down list to appear, which includes my Hue Bridge, and clicking Next led to a successful-looking message akin to "Your bridge already registered", so that was good.
EDIT1: I proceeded to remove the "old" copy of my Fireplace (bulb) device, leaving the "new" intact. This appears to have eradicated the Error condition from Debug Logs. I might also note that the updated V2 style DNI for the "new" device is confirmed:
I think I see the cause of this, though it should only happen if you do not have any Rooms set up in Hue (I do and could not easily test this on my production Hue Bridge, but at some point I'm going to test with a totally new setup...). The next update should fix that.
Selected ... from before? Selections on the "Select Lights" and similar pages are not meant to persist--any new selected devices will get created when you use "Next" to navigate back to the main page, and the memory of which devices were selected will be erased, not that they would show up in that list after being created anyway. If you're getting out of this page via some other means (browser back/forward button?), I would not recommend that, though the same should ultimately be true.
My guess is one has a V1 Hue ID (usually one or two digit number after the last "/" in the DNI) and the other a V2 Hue ID (a lengthy GUID-looking ID after the last "/" in the DNI), probably because one never got converted. I know at least the latter is true from the screenshot you shared. Not sure why the former would have stayed instead of getting converted, though the error in your very first screenshot might have cut that process short.
BTW, once V2 is successfully enabled, the app will no longer recognize V1 ID devices as being the same--so it will happily let you add it again. In your case, I think it should have not marked the conversion as successful (that uncaught error would have prevented the rest of the code from running) and tried again if you hit "Done," though without seeing the application state in between, I can't tell at this point. I might restore to 4.x and try the next beta if you still have a hub backup from then just to rule out any problems an earlier beta may have inflicted.
FYI, that same device (bulb) remains functional as-is back in 4.1.9 on my primary hub. (It's nice that the Hue Bridge is agnostic about such shenanigans. The good news is that most CoCo users will not be implementing the upgrade in such an intentionally edge-case way as mine.) All this testing has been done on my dev hub so as not to necessitate any backup/restore moves.
Background: I’ve been using this app since version 1 with the parent/child setup (2 Hue bridges connected) and was on the latest version 4 when I upgraded to the beta. I didn’t notice any major issues, but none of my Hue groups on either bridge are getting the V2 DNI update, and new groups created on the bridge aren’t seen by CoCoHue (bulbs and buttons are seen and can be added). Bulbs and button devices were updated to V2 DNIs.
I rolled back to a previously saved database and once again reinstalled the beta, but then only the button got the V2 DNI update. So, I restored the database that was only missing the group DNI update and that is where I am now. Everything seems to be working fine and the only thing that doesn’t push updates is the color temperature on group devices.
I don't suppose you had debug logging on in the app when you upgraded and hit "Done"? If so, that should give you a play-by-play of each device it's trying to update, including the old and new DNIs (or whether it was not found in the new Hue data--possible if this was a group added to Hubitat and removed from Hue, but I suppose you'd know that).
Any errors in Logs? Is this still true if you hit the "Refresh Group List" button on this page or "Next" your way out and back in?
In the next version, I'll add additional logging options to the app or Bridge that should help pinpoint the problem here if not.
In the meantime, if you feel comfortable doing so, somewhere around line 413 there should be a couple line like this (among many similar ones scattered throughout the code, so this is the specific one -- for context, it's inside the Groovy method void parseGroupStatesV2(List groupsJson)):
// Uncomment this line if asked to for debugging (or you're curious):
//log.debug "groupsJson = $groupsJson"
If you uncomment that second line like this:
// Uncomment this line if asked to for debugging (or you're curious):
log.debug "groupsJson = $groupsJson"
then there should be more output in the logs for the Bridge device then that may also help.
Yes. Tried this several times. I’ll see if there is anything useful in the logs. Unfortunately, I installed the first version the day that you posted it and have been too busy to look at the finer points until today, so useful info is probably buried. I could have been happy being blissfully ignorant since everything still works. I’ll enable the debug logging.
BTW: all of these groups still work
I am also getting the same as above in my logs.
Was there any case of this found, I did see above something to do with no rooms setup in hue, but i definitely do.
Sorry, I should have mentioned that I am on beta 2.
This is the only new error that I have encountered (under CoCoHue-Hue bridge integration 1 and same error under Hue bridge integration 2):
Still getting the same json errors as before; almost exclusively on the bridge with the most bulbs connected. I understand that this is likely Hubitat cutting short the response.
