As someone who "was" using the switch function of scenes, modifying my rules to use only the button fuctionality was really easy. I say "switch" to "buttons" only especially if it would potentially simplify code and/or enhance performace.
1 Like
Lutron scenes have state in systems higher level than Caséta. And you can get the RL app to reflect the scene state even if you use a Lutron scene button.
I appreciate all the feedback on this! I've released an update with a breaking change, so please read if you use scenes and haven't been following:
CoCoHue 5.1
- Removed switch capability (and related on/off commands) from CoCoHue Scene driver. *To activate a scene, use the "Push" command with button number 1, e.g.,
push(1). - Removed preferences and related code to the above from scene and group drivers and app code.
- As before, if anyone depends on "legacy" behavior, CoCoHue 4.2 remains available (see first post)
- Existing users, if you use scene devices from CoCoHue on Hubitat and depend on the switch state or commands, please:
- change any uses of the
on()command on the scene device topush(1)("push button 1") to activate the scene - change any uses of the
off()command on the scene device to do whatever it is you actually want to do, likely anoff()command on the associated group (room/zone) or lights; and look at group or light states instead of the scene states if you previously relied on the status of the scene activator device
- change any uses of the
See first post for how to obtain.
Hue, unfortunately, does not -- so I think it's time to finally rip the bandage off in this integration. 
In the process, this removes considerable complexity in some parts of the scene and group code as well as quite a bit in general for both of these drivers and the app. (The Hue V2 API does have an attribute that looks promising for reporting state, but that's not what anything I can find says it's supposed to mean, and there's still no command to "deactivate" a scene, so it doesn't fully solve the switch capability problem in the driver, either...)
2 Likes
I have found a problem with migration from 4.x motion sensor devices to 5.x motion sensor devices (the DNI was picking the wrong Hue ID to use at the end of the DNI after the last "/" character). For new upgrades, this is fixed in 5.1.1. For existing users, one fix is to restore a backup from 4.x and re-upgrade, although I realize at this point that this may not be practical for many. The other solution is to:
- Go to the Select Sensors page in the CoCoHue app
- Add any existing sensors as "new" sensors, as they should now show up in this list.
- Swap the device network ID (DNI) of the old and new devices.
- Remove the device from your hub that now has teh "old" DNI.
That is assuming you want an easy way to keep the sensors in any apps you might have already been using them in; another way is to simply add the devices like new (steps 1 and 2), then swap them out in all apps yourself, and remove the old devices after that.
If this is a problem for anyone (maybe you have a lot of sensors?), there would technically be a way to automate this with some option in the app, but I'm not sure how many people are affected by this enough to warrant that trouble. But this should avoid issues going forward. Sorry for the trouble, and thanks as always for the reports!
Oh, and CoCoHue 5.1.1 has been released with this change. 
3 Likes
68 posts were split to a new topic: [FEEDBACK] CoCoHue 5.1 update
CoCoHue 5.1.2 has been released with a small change but one that may help users who relied on pieces of the 4.x scene behavior:
- Added "momentary switch" commands to the CoCoHue scene driver, meaning:
- An "on" can now be used to activate the scene; this calls a
push(1)(push button 1), which would still be my recommendation; - An "off" command does not do anything -- Hue has no concept of "de-activating" a scene, so this is consistent with that (turn off the group or light devices instead)
- The "switch" state will automatically revert to "off" 2 seconds after being turned on by default, though other options are available if you want something else for some reason; this default behavior is what makes it "momentary."
- An "on" can now be used to activate the scene; this calls a
As usual, installation instructions are in the first post.
6 Likes
I think this broke something with regards to RL.
Seems like the "push" got borked somehow, can't a scene using button or switch.
If you're using HPM, try a repair, or manually re-install the scene driver. A small typo was fixed shortly after the upload, and you may have caught the old version.
1 Like
Yep, that fixed it
1 Like
Also made another quick change without implementing the version for HPM (sue me): I took out the capability "Momentary" line from the scene driver since I see it has a different push() implementation that PushableButton, and I really need the latter for scene devices to work on the device detail page (which it was overriding).
IIRC, that was added as a workaround for some dashboard a bit ago, but with Switch back, that shouldn't be needed. Anyone who made that change might need to revert (or add this line to the driver), but ultimately, this makes it more similar to what it was before, too.
3 Likes
@bertabcd1234 - I noticed even after reverting back to an earlier backup (I believe pre-v5, but I could be wrong) that I was still having issues with lighting automations (mostly RL) firing. As always I was both not as methodical as I should have been and have not read enough before embarking on this, so going into this very much ill-informed (my own fault).
One thing that did surprise me was that most of my motion sensors appeared to be detected with different ID's / DNI's at some point in recent days. You quite likely have mentioned this before, so happy to be pointed to an earlier post or something similar, just wanted to mention it in case it was something new.
Yes, sounds like you caught the fix in 5.1.1.
2 Likes
So, big question: previously, I was able to toggle a scene with a button push.
That went away recently, and I could only activate a scene with a button push.
With the changes introduced today, and a switch being allowed, will I be able to toggle again, os will that come back in the future?
No; you will still need to turn off the group (room/zone) or light that you actually want to turn off.
Added "momentary switch" commands to the CoCoHue scene driver, meaning:
An "on" can now be used to activate the scene; this calls apush(1)(push button 1), which would still be my recommendation.
Perfect! This restores easy integration with Alexa, Google Home, ActionTiles, etc. Thank you!
2 Likes
@bertabcd1234 I was wondering if there is an issue with the battery level reporting on the hue motion sensors? The other readings as in light, motion and temp seem to be working. The battery level always shows the same value no matter if you put in new batteries or not.
Seeing these 3 entries in the logs.
dev:2762024-09-24 09:37:06.730 AMdebugnot handling: key type = value motion
dev:2762024-09-24 09:37:06.729 AMdebugnot handling: key owner = value [rid:cc8c7f2f-7041-4320-b005-0860c4e10fb2, rtype:device]
dev:2762024-09-24 09:37:06.727 AMdebugnot handling: key id = value c603241b-1d54-46b6-beb9-4bf35f851724
dev:2762024-09-24 09:37:06.725 AMdebugcreateEventsFromMapV2([id:c603241b-1d54-46b6-beb9-4bf35f851724, id_v1:/sensors/56, motion:[motion:true, motion_report:[changed:2024-09-24T15:37:07.644Z, motion:true], motion_valid:true], owner:[rid:cc8c7f2f-7041-4320-b005-0860c4e10fb2, rtype:device], type:motion])
dev:2762024-09-24 09:38:57.397 AMdebugnot handling: key type = value temperature
dev:2762024-09-24 09:38:57.395 AMinfoKitchen Motion Sensor temperature is 69.08°F
dev:2762024-09-24 09:38:57.394 AMdebugnot handling: key owner = value [rid:cc8c7f2f-7041-4320-b005-0860c4e10fb2, rtype:device]
dev:2762024-09-24 09:38:57.393 AMdebugnot handling: key id = value ed89b946-14a6-40a8-a1f7-5af9b2b34aef
dev:2762024-09-24 09:38:57.392 AMdebugcreateEventsFromMapV2([id:ed89b946-14a6-40a8-a1f7-5af9b2b34aef, id_v1:/sensors/58, owner:[rid:cc8c7f2f-7041-4320-b005-0860c4e10fb2, rtype:device], temperature:[temperature:20.6, temperature_report:[changed:2024-09-24T15:38:58.251Z, temperature:20.6], temperature_valid:true], type:temperature])
dev:2762024-09-24 09:45:05.993 AMdebugnot handling: key type = value light_level
dev:2762024-09-24 09:45:05.992 AMdebugnot handling: key owner = value [rid:cc8c7f2f-7041-4320-b005-0860c4e10fb2, rtype:device]
dev:2762024-09-24 09:45:05.990 AMdebugnot handling: key id = value d9fc216e-7a64-4aff-b4ce-3174d5319c03
dev:2762024-09-24 09:45:05.988 AMdebugcreateEventsFromMapV2([id:d9fc216e-7a64-4aff-b4ce-3174d5319c03, id_v1:/sensors/57, light:[light_level:14785, light_level_report:[changed:2024-09-24T15:45:06.890Z, light_level:14785], light_level_valid:true], owner:[rid:cc8c7f2f-7041-4320-b005-0860c4e10fb2, rtype:device], type:light_level])
Seeing this Error in the logs now.
dev:2762024-09-24 09:44:32.930 AMerrororg.codehaus.groovy.runtime.metaclass.MissingMethodExceptionNoStack: No signature of method: user_driver_RMoRobert_CoCoHue_Motion_Sensor_679.logsOff() is applicable for argument types: () values: Possible solutions: notify(), debugOff() (method logsOff)
I'm not aware of any, but if you see something in logs about "battery" being ignored, that would be a better clue. More likely, your sensor probably just hasn't reported a new value yet that the Bridge has seen or could therefore report over the API. (I only look at eventstream events for these, not polling, though I suppose that would be possible to add, too...)
Nowhere in my code calls or schedules such a method, at least not in the current version, so you must have either been using another driver at some point or upgraded from an older version that might have (still don't remember that, but it's possible ) before the scheduled job ran. It should be a one-time thing only. I'd just hit "Save Preferences" and make sure your logging settings are set as you want.
Looks like that error went away.
I looked at the device page for the sensor, clicked on Events, and the only thing I saw was the following pic.
Looks like it was quite a while back for the battery level. Battery is still at 22%.
EDIT: Went to the device page for the bridge and selected Initialize and then a Refresh. Battery level for the sensor went from 22 to 100. 
Thanks Robert.
Is there any way to update the names of the scene names?
I have changed a zone name, and therefore all the scenes in that zone also changed names, and now there's different names in hubitat compared to hue.
Can this be updated automatically somehow or should I just go ahead and manually rename them?
There is no automated way to do this, so you'd have to rename them yourself. But the "Select Scenes" page will show you the current names on Hue and Hubitat if that is helpful for matching anything up.
1 Like
