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....
{"trigger":{"start":{}}}
OR
{"trigger":{"stop":{}}}
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.
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.
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.
Weird, I thought I fixed that one before beta 2, but downloading my own code again and looking at that, I can see where I didn't. Next beta.
Yep, still my guess on that one...haven't seen it myself lately but have some more ideas to dig into if it does (or some ideas to at least work around it if it's problematic).
The "no rooms" thing was a different issue. Do those devices actually function? If not, I can see where the error is coming from. Otherwise, they should continue to work, though I'm not sure why they didn't convert to the new format. Hitting "Done" in the app again should make it try (actually, did you do this at all yet?). Enable debug logging for more information (in the app; the Bridge wouldn't hurt but might have more than you need for now) if it doesn't.
You are the best! That fixed groups and apparently scenes that I didn’t realize hadn’t updated either. Everything now has a V2 DNI. Zero errors after the update.
The bundle processing isn't updating all the driver & app code on my hub. A few files do get updated. Is there supposed to be a new entry on the Bundles page? One does not show up for me. I verified the ZIP files are valid ZIP files (on a Mac). I've tried both via the downloaded ZIP file and via URL. I'm on 2.3.9.177
