Hi, Yes everything is correct on that page
1 Like
Are you sure? 
From the logs above, I don't see how they could be (the advanced debugging output you must have found in the app). I'm guessing the migration picked the wrong ID to assign to the device, which would explain other problems in the past, but I'll have to look into that more.
For now, re-adding the devives and swapping their DNIs manually might work (or just swapping the actual devices in any apps you use them in).
Okay, I'll try that tomorrow and report back tomorrow.
Thanks for your help.
Not to beat a dead horse, but in my post above I should've clarified that the menu should be empty/null (or it should only contain any sensors that you don't want to add to CCH).
In my first 5.x conversion (initial release), the "old" entry for my Outdoor sensor was still listed on that page (so everything initially appeared fine), but the "new" entry was in that menu -- I had to integrate the new one and swap it in for my old one (which I then deleted away).
1 Like
A post was merged into an existing topic: [RELEASE] CoCoHue: Hue Bridge Integration (including scenes!)
Yes, I was talking about how you report the status of a group. I guess the limitation is that there are only 2 states for a switch – on or off. Unfortunately, just those 2 aren’t accurate for a group. I can easily understand that if 1 light of a group is on, you can’t call the group off, so it ends up being called on. But really the group is neither on or off – some are on and some are off. I did a clumsy work-around in my app for now. Thanks again.
Yeah, the switch attribute doesn't allow any other values, and AFAIK the V2 API doesn't even report any other state (which really mirrors how the Hue app displays the "main" switch for the group as a whole; the V1 API actually did report an "any" and "all" state but I went with "any" to match this behavior, a lucky choice since since it's consistent with V2 behavior), so I don't think there is any other way to do this.
But sending an "off" command to a group that is already fully or partially off should still result in the desired outcome.
1 Like
All motion sensors re added to Hubitat and all working ok 
2 Likes
Greetings! I have been a longtime user of CoCoHue. It's an excellent app which is a huge boost over the native Hue connectivity. In the most recent update, it seems that presetColorTemperature() has been removed? All of my rules that used this custom action silently broke and in fact would fail in the middle of the rule leaving some very mysterious conditions around the home. I no longer can find this custom action in any of the devices. I also tried using the standard Hubitat "Color Temperature: " rule action (not the setColorTemperature() but instead the native Hubitat rule machine action) and this turns on my bulbs when it is sent which breaks nearly every rule that I have written that includes a Hue bulb. What options do I have to fix this? Am I missing something in my setup? This functionality appears to have been dropped in the 4.x->5.x change.
Thanks!
1 Like
Yes, this is in the release notes. There is no native Hue support for this, so everything wad faked in the driver and was not easy to maintain (or reliable if you mixed group and individual lights, among other problems). This change offers considerable simplification of the app and drivers, especially with two API versions to worry about now.
You are welcome to continue using version 4.2 if it better matches your needs. This information is also the release notes, in a post a bit above this one, the first post, or the Github repo.
The two things (RM action and device command) you describe are ultimately the same thing--the action uses this command. This behavior for the command is standard Hubitat behavior.
2 Likes
I get your frustrations, but the 5.x release notes were pretty darn clear about what the deal was in terms of all that.
You can roll back to the previous version using a backup,
1 Like
I'm sorry the change is not to your liking. However, I strongly recommend reading the release notes before upgrading (which does not happen on its own — someone had to do it, even if it's setting up automatic updates in HPM, which I also do not recommend in general but particularly not for anything of complexity like this). I made note of this there, and it's accessible both here and in HPM (before upgrading) if that is what you are using.
Additionally, as I've noted multiple times above, you are welcome to continue using version 4.2 if it meets your needs better. There is a link to this code in the first post, as well as a discussion several posts above. As noted in the release notes, you'll need a corresponding hub backup if you're using the V2 API.
But: have you tried to resolve this issue? There shouldn't be any loss of actual functionality, just a different — now more clear and consistent — way of doing it. If you need help figuring out how to re-do any particular app configuration, I or someone here would be happy to help. You would be the first case so far where there was no solution if that is the case, but I'm certainly willing to listen if there is a compelling case to bring switch functionality back. If that happened, it would almost certainly be only as a "momentary" switch that automatically turns off after a few seconds (with no other options like in 4.x; again, Hue does not track scene state, so there is no actual state to report, and I really wish this was never implemented in such a way as to imply that there were in the first place...).
I very intentionally created this integration as open-source, so if you don't mind the complexity, you're also welcome to fork it and maintain such changes yourself. 
If not, please keep in mind that CoCoHue is something I created and have maintained for almost 5 years entirely in my free time, and such changes have considerable impact to my enjoyment and continued participation in these efforts.
Despite all the above, I have tried to make it easy to stay on 4.x if so desired; while it is unlikely to receive future updates, this series has been around for a while, seems to work well for most users, and should be considered a stable choice if that is your preference.
Good luck with whatever you choose!
5 Likes
I just did a complete re-install of ActionTiles on my C7. The new CoCoHue scenes show up as valid "momentary" buttons that I can add to my ActionTiles panels and when I tap one of the tiles they do activate the scene properly.
However, I get this error message in the Hubitat log which is preventing me from having Rule Machine activate other events whenever a CoCoHue scene is activated:
The problem is that ActionTiles just recognizes the CoCoHue scene as a button device that you can add as a tile. You can't configure it otherwise such that when you tap on the tile, it specifically presses button "1." It just presses the button, period, thus the error you see above in my Hubitat log.
Any ideas on how to fix this? I can do a workaround by creating a virtual switch in Hubitat that when turned on will push button 1 on the CoCoHue scene. I can then set the virtual switch to turn off automatically but otherwise I haven't found a way to make the new scenes work properly with ActionTiles. Is there a way to update the CoCoHue scene driver on Hubitat such that whenever the button is tapped, by default it taps button "1"? This would fix the issue with ActionTiles.
You need to specify a button number (I'd use button 1, although in the current version it doesn't actually matter -- it may in the future). I don't use AT, so I don't know how to do this specifically, but there should be a way...
While that is the full explanation, to expand on possible implications, the switch capability on Hubitat entails the "on" and "off" commands plus the "switch" attribute (as you might see under "Current States" on the device detail page). There was also some additional discussion on this above.
This is a compelling use case, so thanks for sharing (though I encourage you to do so more thoughtfully in the future with people who are volunteering their time and efforts for you). It has been brought up before, along with one workaround, though that entails some effort.
I'll repeat this proposition if anyone else has a similar use case and is OK with the limitations and possible confusion that may result (e.g., meaningless "switch" state and an "off" command that is basically un-implementable):
For the remaining issues:
A change in CoCoHue cannot possibly affect, much less break, the Hue mobile app, so something else is going on here for you.
A push(1) command works to turn on a scene. This has been the case since the introduction of scenes into CoCoHue, was extensively tested on its introduction years ago, and remains a successful mechanism to activate scenes (given that it is now the only option in 5.1 I have seen no contrary reports above).
If this doesn't work for you, your automation app was configured incorrectly. Without knowing any more information about your particular setup, I can't say in what way, but if you share more details, someone may be able to help.
Continued use of version 4.2 is certainly a viable solution, and I have tried to make this option very easy to find (in the first post and several above, the readme, and a dedicated branch on GitHub). This doesn't have to be a "for the moment" thing if it works fine for you as-is.
But if you want to upgrade, switching switch commands to button commands would be a leg up in upgrades to 5.x, even if any switch commands are added back in the future -- buttons have always worked, always will, and have long been my recommended method for activation.
4 Likes
Ignoring any thoughts not relevant to the very specific issue at hand (I have many...), I have twice mentioned a proposal that may work for many of these uses cases, but I have not received any feedback on this to know for sure. It would be an easy change (in fact, one I already have tried on a test hub) and one I might consider in a future update if it would fit the need.
I would again strongly advise against automatic updates for this package, if not in general, particularly in what is now apparently a commercial environment.
5 Likes
That’s true.
Have you thanked @bertabcd1234 or any of the other community developers recently for all the hard work they do? For free. For the benefit of strangers on the internet.
6 Likes
Please be agreeable even when you disagree. Name calling and personal attacks are against our community rules. If you disagree with someone who volunteers their time to offer and maintain an app or a driver that others enjoy, you may consider providing constructive criticism that the developer may or may not implement.
4 Likes
Disagreeing doesn't mean name calling. It's perfectly fine to disagree with an idea, but address the idea itself, and avoid insulting those who provide reasoned counter-arguments, however they can.
3 Likes
Perhaps we are reading a different post. Nobody was calling anyone names.
