Perfect! Thanks very much.
@bertabcd1234 - Just to update you that v3.0 is working well and really getting a massive benefit from the Hue Motion Sensors, all 17 of them.
If you could capture the Battery level that would be extremely helpful, so I can track if any batteries need replacing and have HE inform when they need replacing.
Thank you so much for this App, it makes my life much much simpler 
Hello, everyone. I'm having two different Hue/CoCoHue issues I wanted to get some feedback on. I'll describe them in two different posts on this same thread to avoid any cross-talk between the two issues.
ISSUE 1: HUE BULBS NOT ALWAYS HONORING THE REQUESTED LEVEL ON FIRST TRY
Is anyone seeing behavior where their Hue lights will turn on, but the requested level is not honored on the first try? This strikes me as an issue on the Hue Bridge side of things and not CocoHue, but wanted to run it by the community to get some feedback.
Background & Environment: I am running CoCoHue 3.0preview1 currently, but experienced this on the previous release version as well. I wrote my own motion lighting application, and am controlling 21 different Hue Groups. I have not imported any lights, scenes, motion sensors, or activators. I have 4 different Hue Bridges due to the number of bulbs. I have color psuedo-staging enabled, I have level psuedo-staging disabled.
What I do when motion is no longer detected after a definable period of time is:
- setLevel(1, x) where x is a a definable transition speed (almost universally 10 seconds, although groups like pantry and close I skip this and simply turn off), and
- off() to turn the group off
When motion is detected, I:
- setColorTemperature(y) where y varies depending on the time of day relative to sunrise & sunset, and
- setLevel(z) where z varies between 3-100 depending on the time of day based on Hubitat mode and relative to sunrise & sunset; I omit a transition timer here which relies on the value defined on the Hubitat device
- NOTE: I am not using .on(), I rely on .setLevel(z) combined with level psuedo-staging disabled to turn the lights on.
What I "sometimes" (maybe ~1-2% of the time?) experience is as follows (let's say I'm setting level 100):
- Hubitat/CoCoHue requests the Hue Bridge turn on sets level 100,
- Hubitat believes this has been performed successfully; the device in Hubitat says switch: on, level: 100, BUT
- The lights DO turn on, but do NOT honor the level; they are still at level 1
When motion re-triggers before dimming, I have my app reassert the motion detected behavior mentioned above -- I again request the desired CT and level with setColorTemperature(y) and setLevel(z). Once I do this, the Hue lights DO ramp up tothe requested level.
Anyone else experience anything like this, or have any feedback on how to fix it? Perhaps I should simply follow up my setLevel(z) with a second setLevel(z)? If there any harm in sending a second setLevel(z) before the bulbs have actually ramped up to the requested level, or do I need to use runInMillis() to wait until the device-defined transition timer has finished?
Thanks in advance for any insight.
ISSUE 2: HUE BULBS NOT ALWAYS HONORING THE HUBITAT DEVICE-DEFINED transition time
As I described in my previous post, I wrote a motion lighting app yadda yadda yadda. When turning the Hubitat device/Hue Group on, I use setLevel(z) and rely on the Hubitat device-defined transition time.
Three of my Hubitat devices/Hue Groups -- a kitchen pantry and two walk-in bedroom closets which trigger by a door sensor rather than a motion sensor -- have a transition time of "ASAP" defined so that the light will immediately turn on.
What I occasionally experience -- and I haven't yet quite got a read on the triggering condition(s) -- is that the light does not turn on "ASAP", it fades up. It does seem to happen fairly frequently after some period of sitting idle. For example, right now as I was writing this up I opened the kitchen pantry door and the Hue bulb faded up instead of immediately turning on. But immediately after I opened/closed the door 5 times in a row, the Hue bulb always honored the "ASAP" transitoin time and immediately turned on.
Also worth noting that I use off() to turn these particular and skip the setLevel(1, x) dimming process I describe in my previous post, but they always fade down and never turn off ASAP. This isn't as big of an issue since the door is closed and it's probably only even noticed since I've spent the last couple of weeks staring at rooms and doors as I've been developing and tuning my motiong lighting app.
Does anyone have any thoughts on how I could get the "ASAP" transition time to behave more consistently? For these bulbs I'm only using setColorTemperature(y), setLevel(z) and off(). I do not use setLevel(1, x) as I do on the other 18 Hue Groups to dim the lights first.
Thank you for any insight.
For reasons I haven't figured out yet, I have seen some Hue bulbs turn on to a low level for noticeably longer than normal before ramping up to my intended target level (even though the transition time is the default 400ms--and it's not a gradual fade up but looks more like an "oops"). I don't know what could be causing that, as with logging turned on, all I'm seeing is a single command map (JSONified) getting passed to the Bridge devices with the contents I'd expect, the same thing that has been working for over a year for me. This actually sounds a bit like the second issue you noted. I haven't figured out what's going on there, but again I can't see what would be causing this on the CoCoHue side given that logs show a single command with the expected contents getting sent to the Bridge. (If you're familiar with the Hue API, turn on debug logging for the affected device and you'll see the JSON in Groovy Map form that gets sent to the Bridge for that device.)
I've never seen them not actually do what is requested, which it sounds like you're saying with the first issue. I did notice the "21 groups" thing. Hue recommends limiting commands on a Bridge network to 10 per second for bulbs or 1 per second for groups. If you have multiple bulbs and groups that you're trying to control, could that explain the problem? (But I have to say that even pushing these limits, I still don't think I've seen problems--Hue is pretty reliable.) It does look like you'd have at least two commands per bulb, given that setColorTemperature() and setLevel() will both send a command to the bulb (or group).
I'd be curious what happens to the device state in Hubitat after the next time the Bridge is refreshed/polled ("Refresh" on the CoCoHue Bridge device will do this). The Hubitat state will get updated to level: 100 if the command "went through" from an HTTP perspective (so it doesn't naïvely assume it just worked but also doesn't really get what Hue thinks the state is, at least not immediately). However, polling the Bridge will get the state from Hue. I'm not sure what could be done either way, but at least this would tell you what Hue thinks. 
There is a quick fix for this above that it looks like you said you already made, but if not, doing it should fix the problem (just a one-line change in one driver). But I'll get to it eventually.
On a related note, I'm not really sure I'd trust battery reporting. This is notoriously unreliable for Zigbee and Z-Wave devices in general. Hue at least uses alkaline batteries here with a discharge curve that is probably more predictable than that of lithium batteries a lot of sensors use now, but the advice from most people for devices in general is still not to rely on it too much. Just something worth noting!
Thanks
Looking at it is more weird ...
Both HE Hubs 7 - running the same cocohue - copied and pasted from he the one where the batteries all show ok
The newer one 6 of the 17 fail to show a battery level.
Digging into it
@bertabcd1234 Does CoCoHue support changing colors for IKEA bulbs paired to the Hue hub? Cant get it to work with the included HE Hue app.
No, not at the moment, or at least not directly via Hubitat's "Set Color" commands and similar. Ikea's bulbs, or at least the ones I've used, only support the CIE XY color model, not the HS (hue/saturation) model that Hubitat uses. I have also not found a reliable way to convert to and from these models (and yes, anyone who's reading this and thinks they've found something, I've Googled the same things you did -- try it with real bulbs and see how close you get ). That being said, if I find a way to make the unreliable conversion I have now work slightly better, I'll consider releasing something for it, or at least maybe at least an "XY-only" driver, though I'd really prefer to make it part of the regular RGBW driver if I can.
What you can do is create a scene on Hue, import that scene into Hubitat from CoCoHue, and then activate that scene to get the Ikea bulbs to the specified color or color temperature. Their color/CT is still unlikely to display correctly in Hubitat, but at least it's a way you can reliably recall specific settings for these bulbs given their lack of alternative color (or CT) model implementations. I'm not sure that they're technically deficient--I don't know what the Zigbee spec really requires--but can say every other bulb I've used that supports CT did indeed implement the Zigbee commands for that, report its nature as such, and if color/RGB, implemented at least HS color if not also XY, so they're definitely a bit odd in the real world regardless. A common theme with Ikea's Zigbee products, it seems.
1 Like
@bertabcd1234 Thanks for a very thorough reply! Allow me to address your questions and weigh in with some additional findings.
I agree that this appears to be a Hue Bridge issue (perhaps API-specific?), and not a CocoHue issue. I'll elaborate on this below:
A couple of comments:
- I do have 21 groups, but they are spread amongst the 4 Hue Bridges (1 for each floor, 1 for outside).
- Each of my groups contains the bulbs for that room. So for example, Hue Group "1F Kitchen" does have 9 bulbs in it, but that group is imported in to Hubitat by CoCoHue as a single group, and that single group is interacted with from Hubitat (on, off, level, CT) as a single device.
- If I'm correctly following along, it does sound like I am technically violating the "2 commands per second to a single group" guidance (setLevel and setColorTemperature to a Hue Group device). I have tinkered with a number of variations on these two commands; at first I was doing a setLevel then following up 2 seconds later with setColorTemperature, but I landed on my current setup (color psuedo-staging enabled, always setting the CT before turning the group on). Benefit to current setup is that the transition from $currentCT to $newCT (if different) will take place in tandem/at the same rate as the requested (or default, if not requested) 'on' transition time. This approach has seemed to work real well and is not jarring on the eyeball, but I'm open to changing it up if you think there might be an issue.
Ok, so I ran in to the issue again this morning, and was able to check on a couple of these items in realtime. Here's what I found:
BACKGROUND
- Hue Group "1F Powder Room" is imported to Hubitat via CoCoHue as a "Hue Group"
- Hue Group "1F Powder Room" contains 3 bulbs (on this specific Hue Bridge).
OBSERVED: ACTUAL & HUBITAT
- I entered my 1F Powder Room and motion was triggered.
- Based on the time of day, my app requested setColorTemperature(6500) followed by setLevel(100) on the Hubitat CoCoHue Group device "1F Powder Room (Hue Group)".
- Observed light level was 1 (not 100) on all 3 bulbs
- Hubitat considered the device "on", with level 100 and CT 6494
- I stayed real still so I wouldn't trigger another motion (which would send a new setLevel(100) and setColorTemperature(6500))
- After 2 additional minutes (I am using 1 minute bridge refresh timer) the level of the bulbs did not change; stayed level 1 even after refresh cycle.
OBSERVED: HUE APP (the interesting part)
- I never manage the Hue bulbs from the Hue app, but in the spirit of troubleshooting I fired it up to see what it thought. Here's what I found interesting:
- The Hue app considered 1 of the bulbs to be at 100%, and the other 2 to be at 1%. I am certain, though, that this was not the case -- all 3 bulbs were at 1%.
- After some period of time, the Hue app "refreshed" and saw all 3 bulbs at 1%. NOTE: I'm not 100% certain about this because I'm putting this together based on my Hubitat "Past Logs", but: It appears that the CoCoHue/Hue Bridge resync (again, default 1 minute timer) set the Hubitat CoCoHue Group device back to 1%.
- I then purposely triggered motion so that new setLevel(100) and setColorTemperature(6500) commands were sent; immediately, the Hue Group (ie, all 3 bulbs) ramped up to 100%.
Considering Hubitat & CoCoHue have no visibility in to the fact the Hue Group contains 3 bulbs (they only see these 3 bulbs as a single Hue Group), I don't see any way this Hue misbehavior could possibly be Hubitat or CoCoHue.
Do you happen to know if the Hue app itself uses the same API that CoCoHue interacts with? Prior to my migration to Hubitat & CoCoHue, I never saw this when managing Hue bulbs from the Hue app. So from a 20k foot view, I have a hunch that perhaps the Hue app doesn't use the same Bridge API that CocCoHue does, and that the Hue misbehavior might be specific to the Bridge API. I'll get a tcpdump/packet capture rig setup, so I/we can compare what's actually put on the wire to the Hue Bridge in order to compare that with reality. I'm fairly confident we'll see the correct commands from CoCoHue/Hubitat, the Hue Bridge acknowledging those commands, but then the Hue Bridge simply executing on the commands incorrectly.
I guess for the time being, I should pursue a workaround. Is there a way for me to fetch the the configured transition time of the CoCoHue Group device from groovy? My thought was to follow-up my setLevel(x) with a second setLevel(x) +100ms after the first one should have completed. So for example, if I programmatically determine that a CoCoHue Group device has 400ms transition time configured, I could follow up 500ms after my first setLevel(x) and re-send the desired setLevel(x) -- a delay before ramp-up to 100% is better than no ramp-up at all.
My assumption is that the Hue app uses the HTTP/HTTPS API (which I assume are identical other than the protocol) given that it can also work with a few third-party Hue Bridge emulators, but maybe they have a proprietary connection mechanism and the the HTTP(S) API for "fallback" (though I've never heard of that before).
I'm not sure what you mean with "fetch from Groovy" regarding the transition time. In the driver, you can read the value of the preference field, but you have to be in that same driver or the parent app (I sometimes forget what is and isn't accessible from parent drivers vs. parent apps). So, if you're looking at another app or custom rule, this isn't do-able--at least not without modification to the code to expose it in a usable fashion, like an attribute.
New Hubitat user. Recently switching from ST. This App has worked much nicer than the native Hue app. Thank you for all the work you have put into this.
2 Likes
Greetings, all! For those using the 3.0 beta/preview or who want to try, I just released 3.0 Preview 2, available if you're using HPM with the beta option selected or manually install from the beta folder at: CoCoHue/beta at master · RMoRobert/CoCoHue · GitHub. I seem to have problems getting HPM to "see" the newer beta, so you may need to do a repair or manual install (not sure if this is a current HPM limitation or something I did wrong, but I can't see what that would be).
Here are the only notable changes:
- Motion sensor battery reporting bug fix (reported above; thanks!)
- Option to specify port for Bridge HTTP API; shouldn't be needed with "official" Bridge, but I noticed this small change also makes this integration work with DeCONZ like a Hue Bridge (HTTP, no websocket) and might also help DIYHue users if that ever runs on a non-standard port
I still want to test the Bridge discovery and manual addition process (the second change above may have affeted how that works) and do some more testing before I consider this the "final" 3.0 version, so I've kept this with a "preview" designation for now. I have more ideas in mind (adding a few more options to match Hubitat's "Advanced" Zigbee bulb driers), but those may or may not make it into 3.0.
2 Likes
Any suggestions on why Cocohue Hue Sensors are getting updated running on one HE but not on the other?
ie The Heating HE using cocohue has:-
The other has
Did you happen to manually edit any of the DNIs? The DNI in your first screenshot (I assume that's the one that isn't working?) is longer than it should be. They will not work if changed. If you didn't, I'd still be curious how the extra text got into that device's DNI, but the ":9b" portion looks like what doesn't belong if these are the exact same sensor from the same Bridge on both Hubitat hubs, so removing that might help. I could tell more if there were debug logs from the Bridge device during a refresh.
Nope
I am not touching DNIs - ever - leaving well alone
Actually I need to check all the Hue Sensors coming in through on the Heating HE Hub.
I'll enable logging and try a refresh, I only spotted it because it is on a Dashboard and it is the Outdoor temp
Yeh ALL Hue device updates at least over 24 hours old
Both CoCoHue connectors to both Hue Hubs not getting updates
Turned on debugging
Hue Hub 1
dev:5352021-02-09 22:27:03.101 debugReponse valid
dev:5352021-02-09 22:27:03.098 debugChecking if valid HTTP response/data from Bridge...
dev:5352021-02-09 22:27:03.091 debugParsing light states from Bridge...
dev:5352021-02-09 22:27:03.071 debugReponse valid
dev:5352021-02-09 22:27:03.068 debugChecking if valid HTTP response/data from Bridge...
dev:5352021-02-09 22:27:03.065 debugParsing group states from Bridge...
dev:5352021-02-09 22:27:03.029 debugRefresh...
dev:5352021-02-09 22:26:22.560 debugReponse valid
dev:5352021-02-09 22:26:22.557 debugChecking if valid HTTP response/data from Bridge...
dev:5352021-02-09 22:26:22.554 debugParsing group states from Bridge...
dev:5352021-02-09 22:26:22.528 debugReponse valid
dev:5352021-02-09 22:26:22.525 debugChecking if valid HTTP response/data from Bridge...
dev:5352021-02-09 22:26:22.521 debugParsing light states from Bridge...
dev:5352021-02-09 22:26:22.475 debugRefresh...
dev:5352021-02-09 22:26:18.567 debugDebug logging will be automatically disabled in 1800 seconds
dev:5352021-02-09 22:26:18.563 debugInitializing
dev:5352021-02-09 22:26:18.560 debugUpdated...
Hue Hub 2 HE logs
dev:1052021-02-09 22:30:59.461 debugReponse valid
dev:1052021-02-09 22:30:59.448 debugChecking if valid HTTP response/data from Bridge...
dev:1052021-02-09 22:30:59.444 debugParsing group states from Bridge...
dev:1052021-02-09 22:30:59.430 debugReponse valid
dev:1052021-02-09 22:30:59.427 debugChecking if valid HTTP response/data from Bridge...
dev:1052021-02-09 22:30:59.423 debugParsing light states from Bridge...
dev:1052021-02-09 22:30:59.371 debugRefresh...
dev:1052021-02-09 22:30:21.113 debugReponse valid
dev:1052021-02-09 22:30:21.110 debugChecking if valid HTTP response/data from Bridge...
dev:1052021-02-09 22:30:21.104 debugParsing light states from Bridge...
dev:1052021-02-09 22:30:21.075 debugReponse valid
dev:1052021-02-09 22:30:21.072 debugChecking if valid HTTP response/data from Bridge...
dev:1052021-02-09 22:30:21.069 debugParsing group states from Bridge...
dev:1052021-02-09 22:30:21.029 debugRefresh...
Not sure how to read these
Using CoCoHue to the same 2 Hue Hubs - Hue 1 and Hub 2 but from my 2nd HE
and they are working all great updates coming well from both Hue Hubs
So don't cocohue works on both Hue Hubs on the Master HE and both fail on the Heating HE
Hmm, I didn't put quite enough logging there for it to be helpful here, but the other thing you could do is turn on debug logging for the sensor and see if anything comes through for that when you do a refresh. If not, I'll have to add more logging to get better information here. One thing you can also try if it's easy enough is to remove and re-add the sensor, which should fix any DNI oddities (if I had to guess, that might be why it's not getting events generated, but I don't know why that would have happened).
