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
I think I found the issue. The RMoRobert.CoCoHueGenericStatusDevice.groovy file on line 32 makes reference to RMoRobert.CoCoHue_Common_Lib that is not part of the bundle.
Ah yes, looks like I made a mistake creating the Bundle. That driver actually isn't even used anymore, and there's a new (RGB only bulb) driver that wasn't added.
I've re-uploaded the Beta 3 bundle and would encourage anyone who tried it before to try it again, though it probably won't make much of a difference (if you don't use this driver) if it already updated your app and bridge driver code.
Yeh I definitely hit the done a couple of times for good measure, I have now updated to the first beta 3 and still throwing the error - light la are working as expected so no a massive concern.
Appreciate all the work you put into this app and keeping it updated.
Just to be clear, which error? If it's the warning (not error ) from the screenshot above, does debug logging show more information when you hit "Done"? And do any of those lights in particular (not just lights in general) work? The only reason I can think of that this would happen is if they just aren't there anymore, but then I don't think you'd ever get this message in the first place.
OK, nevermind, if this the same issue, I found where I'm marking this conversion as successful even if it errors out the first (and only) time. I'm moving that up where it should only happen if it was actually successful now, at least in terms of receiving some data back from the Bridge. There's actually way to make it retry now if you want (Advanced Options > Advanced Debug Options... > Retry Migration), but it's also harmlessly recovering from this -- as long as the V2 Hue API keeps the V1 IDs around -- so for now it's not a problem per se, just something I'm logging because I'd really prefer for it not to happen.
CoCoHue 5.0 Beta 4 is available as a bundle (bundle only for now, not in HPM; see below for install instructions) for anyone interested in testing. This release has the V2 API conversion fix discussed above (re-conversion may be necessary once if this failed for you before; use the Advanced Options > Advanced Debugging Options page to try), plus some other minor changes that should improve the app/drivers (or at least have no visible changes).
Something is still wrong with groups. Not able to add new groups that I created on the Hue bridge. Old groups that are already imported work fine, but show up like this in the app.
I can look at it later, after I get home from work, but unfortunately, I forgot to check this after the last update, so don’t know if it had been working with the third beta,, but it was not working in the first two versions either. I would not have known if I had it looked in the app because everything appears to be functioning normally and all devices have the V2 DNI.
Thanks! I did some more testing with this and think I figured out what's going on. (Seems to be a problem fetching room/zone data with the V2 API enabled.) New beta soon to address...
Trying again with another beta of 5.0 for anyone interested in testing. I've included all information about what's new in 5.0 again, how to upgrade, and more below:
CoCoHue 5.0 Beta 6 is available as a bundle (bundle only for now, not in HPM; see below for install instructions) for anyone interested in testing. Compared to the previous beta, this beta includes fixes for adding groups when using the V2 API, as discussed above, plus some extra debug/logging options that might make figuring this kind of thing out easier in the future (fairly buried, but I'll help anyone get there if I need to ).
I would consider this release-candidate quality.
How to install 5.0 beta:
This version is available only as a bundle (ZIP file) while in beta. To install:
On the desired hub, go to Settings > Backup and Restore and choose Create and Download to create and download a new local backup. Save the downloaded file. Restoring a hub backup is the only way to return to CoCoHue 4.x if you decide to downgrade and are using the V2 API option in the app.
On the desired hub, navigate to Bundles (in the developer menu), select Import ZIP, and choose the file downloaded above.
When the import is complete, navigate to Apps, find your CoCoHue install, open the app, and select Done on the main page. Wait a few seconds or more for the upgrade to complete.
Repeating information from before
Changes from 4.x include:
More use of Hue V2 API throughout if enabled
If you have this option enabled, open the CoCoHue app after upgrading and hit "Done" to upgrade the app settings, etc. to the new version (you will get warnings about DNIs in your logs if you don't; this is the app harmlessly recovering, not an error, but some day it might not be able to do that anymore...)
As a result of this: CoCoHue light, group, and motion sensor DNIs will change to use the Hue API V2 ID instead of the V1 ID, which means downgrading is not possible by simply reinstalling the old/app driver code (you will need to restore a hub database backup).
Removal of deprecated features:
Pre-staging preferences (long deprecated)
Pre-staging commands (alluded to a few posts above) -- neither of these features ever worked very will given that neither version of the API has a way to actually do this, and the driver keeping track (which is how these used to work) becomes problematic for groups, among other reasons these were never a good idea
Motion sensor devices will no longer work unless the V2 API option is enabled in the CoCoHue app (which has long been recommended)
Hue Labs activators (Hue suggests moving to replacement features, including dynamic scenes--which can be activated from CoCoHue, though the ability to enable the dynamic part if available and currently paused, is not yet available)
I am hoping that most users will not notice any changes. If you rely on any deprecated futures, CoCoHue 4.2 should be stable at this point and will remain available indefinitely, as mentioned above. Otherwise, I think these changes will set the stage for future changes that enable continued use of the V1 API for all Bridge users (currently--Hue does say they'll remove this from new firmware eventually, but anyone still using the original Bridge can only use it) while making it possible to continue add V2 functionality with less legacy code to worry about for those cases.
Quick update: I replaced beta 5 in the post above with beta 6, which has one small change for V2 API users in that it adds more data to the state of group child devices when created.
If you've already migrated, please go to Advanced Options > Advanced Debugging Options and run the "Retry Hue V2 API Migration" button there once sometime after updating to beta 6. This probably won't end up mattering for a while, but if/when some update is released in the future that relies on this (I eventually plan to look at using the V2 API for sending commands to the Bridge--all of this is preparation to make that possible), you'll avoid errors months from now or whenever.
Sorry, forgot to push the changes I committed to GitHub. Should be there now!
EDIT: I'm still seeing some problems creating groups with the V2 API enabled now that I'm testing this more. I see what's happening--another fix to come!
Something strange going on with the beta since V2 for me, I have one group of lights that refuse to turn off in every version since V2 (including V6) - a soon as I roll back to V2 everything is sweet again.
In the log below it’s is the lounge lights - log shows the command sent from room lighting but the lights do not turn off.
Groups appear to be fixed after following your instructions above. No errors or oddities in the logs after looking this morning. Thanks for your excellent work!
Can you enable debug logging on the actual device and see what it says? Also, ignore Room Lighting for a minute and see it the commands work directly from the device detail page.
Great! Bad news is I have another fix in the next beta that will need anyone who's already changed (and is using V2) to click a button for a one-time fix--used the internal room or zone ID to make these devices instead of the group ID like I intended. Maybe hold off on upgrading for anyone who hasn't yet.
) from the screenshot above, 
