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
19 posts were split to a new topic: Question on how to use CoCoHue 5.x scene activator with Room Lighting
6 posts were split to a new topic: Question about red LED on Hue Motion sensors
Sorry to pump this up once again but I'm still having weird issues with Hue Switches.
I'm trying to solve the issue where button presses from Switches are slow.
There is no clear clue what is causing this but I noticed something.
When I press switch button and when it works normally log looks like this:
Then when I'm facing issues with button press turning lights on in few seconds delay, log looks like this:
I'm not sure do you remember the whole story behind this but when I have Use V1 API on then the issue is worse than now. Delay could be something between 5-20seconds. When V1 API is disable which means that API V2 is enabled I have just few seconds delays and not all the time.
For me it seems that that delay happens everytime when I'm pressing button and bridge is polling (30sec intervals)
Anyone else seeing the same thing?
I don't see any evidence of button presses in your log entries above at all (the most helpful debug logging would come from the bridge and the button device, not the app, which seems to be all there is above).
I don't see anything concerning in your second set of log entries either; that would be the normal result of polling. Is your interval set to 30 seconds? That would match the distance between the entries you highlighted. If you're using the V2 API, as you are from your screenshots, you probably don't need to poll that often, though it shouldn't cause problems. If the delays line up with this 30-second polling interval, you're probably experiencing the result of the driver waiting until all the processing from the poll data is complete before your button events go through -- just as one possible guess.
