[RELEASE] CoCoHue: Hue Bridge Integration (including scenes!)

bertabcd1234 · January 18, 2023, 5:13am

CoCoHue is something I work on in my free time, simply shared for others to use if they wish, and as such, I do not make a habit of guaranteeing any specific features or timelines for it. My other post was intended to suggest "maybe." That is more likely a "definitely" if Philips commits to removing the v1 API and Matter doesn't pan out to take over all of this anyway (not holding my breath on that last thing, and I think they'll get a lot of backlash for the first and might change their timing or possibly mind entirely on that, too...).

But, as usual, I'll look when I have time -- and trust that they aren't going to change anything, as last I saw, the v2 API was still "early access," "experimental," and is documented as "not yet feature complete." So, honestly, the motivation to move entirely to it really isn't there at the moment.

abuttino · January 19, 2023, 6:10pm

I developed decided to get this project rolling again, and added the ability to choose between 2 entertainment areas.

LupoLoopy · January 29, 2023, 5:11pm

Would it be possible to pull battery status of motion sensors into Hubitat please @bertabcd1234 ?

It appears to be exposed by the API:

"35": {
"state": {
"presence": false,
"lastupdated": "2023-01-29T17:02:25"
},
"swupdate": {
"state": "noupdates",
"lastinstall": "2022-12-08T20:26:50"
},
"config": {
"on": true,
"battery": 100, <-------------------------
"reachable": true,
"alert": "none",
"sensitivity": 2,
"sensitivitymax": 2,
"ledindication": false,
"usertest": false,
"pending": []
},
"name": "Hue motion sensor - Doorway",
"type": "ZLLPresence",
"modelid": "SML001",
"manufacturername": "Signify Netherlands B.V.",
"productname": "Hue motion sensor",
"swversion": "6.1.1.27575",
"uniqueid": "NAUGHTY,NAUGHTY,VERYNAUGHTY",
"capabilities": {
"certified": true,
"primary": true
}
},

bertabcd1234 · January 29, 2023, 5:30pm

It should, so if it's not, I don't know what's going on but could take a look to see if anything changed...

LupoLoopy · January 29, 2023, 5:34pm

Interesting! Not coming through for me. Any logs I can share?

bertabcd1234 · January 31, 2023, 1:18am

I know I had this working at one point but must have changed something that broke it a while back. I believe I've figured out what that was. I've released:

CoCoHue 4.1.4:

fix for missing attributes (e.g., battery) on motion sensors with v1 API
small tweaks to HTTP error handling

The second change affects all drivers, so for manual installers, you'll want to update everything (I'd recommend the app too just to make sure you're all current, though there really wasn't anything there). The motion fix is mostly in the Bridge driver, but I'd again recommend updating everything.

For others, either HPM or the bundle .ZIP are the recommended installation methods, and they should both be updated now.

rlithgow1 · January 31, 2023, 11:37am

I notice 4.1.3 is the latest in the repository. Am I missing something? In the code it states it's 4.1.2 ,

bertabcd1234 · January 31, 2023, 3:21pm

It seems there could be a couple reasons you're seeing that, but no problems as far as I can tell:

I must have accidentally typed "4.1.3" in the comment for the commit to GitHub, so you'll look at that if you see GitHub. That should have said "4.1.4" but won't affect anything functionally.
There are lots of pieces to CoCoHue (apps, drivers, and libraries--though I'm not using the libraries publicly yet), and not every piece gets any changes or a version bump during revisions; the version number I'm using for the "package" as a whole is the highest individual app or driver version. I think all the drivers had changes last time and should be 4.1.4 now, but looking at the app, it hasn't been touched the last couple revisions and looks to be at 4.1.2, which is normal. I know this might be confusing, but I feel like it's probably the best in terms of being easier for me and for anyone who manually installs--no need to change anything if nothing really changed in that piece.

If you use HPM, it should update everything as specified in the manifest (which I also updated). The .ZIP bundle should have them all as well. Manual install, again, should too--you just might see different versions in different pieces but will be OK as long as you actually have the latest file from GitHub.

Hope this helps!

Ken_Fraleigh · January 31, 2023, 6:12pm

I finally had time to update again. As soon as ML turns off the Hue lights, they come back on at 1%. This happens with my Motion Lighting apps that have Hue light groups. It goes away if I downgrade to 4.1.2.
From the CoCoHue group:

From the ML app:

From the CoCoHue group events page:

I hope this is helpful.

bertabcd1234 · January 31, 2023, 7:01pm

I have one idea, though I don't recall making any changes that should affect this. It looks like it might be related to the v2 API (server-sent events/event socket/push). If you disable that option, does it fix things?

Ken_Fraleigh · January 31, 2023, 9:07pm

No. It still has the same behavior. Goes to 1% right after the off is sent.

bertabcd1234 · January 31, 2023, 9:23pm

What about if you disable the option and run the Disconnect command on the bridge to make extra sure? Also, if it keeps happening even then, is it immediate or only after a poll?

Ken_Fraleigh · January 31, 2023, 10:55pm

That stopped it. After a poll, it stays off as well.

bertabcd1234 · February 2, 2023, 2:06am

I've released a small update, version 4.1.5, with a tweak to "level" attribute parsing for the v2 (instant) API. This might fix your problem — or at the very least fixes what could be an issue for someone.

For anyone manually updating, the only changes are in the bulb drivers (and underlying libraries, though those are incorporated into the public versions). HPM or Bundle ZIP are recommended, as above.

Ken_Fraleigh · February 2, 2023, 2:25am

I had to do an HPM repair to get the update. It isn’t showing up as having an update.
Also, that seems like it did the trick! Thank you so much.

bertabcd1234 · February 2, 2023, 2:34am

Oops, forgot to update the driver versions in the HPM manifest file (would have affected anyone already on 4.1.4 only), but repair should definitely work -- or it should be good for everyone now.

And great to hear!

Ken_Fraleigh · February 2, 2023, 2:48am

I spoke too soon. Now instead of 1%, it is turning on to 0% as soon as ML turns off the lights, preventing them from visibly turning on with motion.

bertabcd1234 · February 2, 2023, 2:55am

I'm not sure what could be going on there. The specific logs I was looking at were these:

From the bottom up, first it got the message that group 5 (Master Bathroom Vanity, it seems) was off, then it got level 0.0, which I was originally parsing as 1 instead of 0 because the v1 API never reported 0, and either the v2 API didn't in my testing or was changed at some point. But that will now get converted to 0. (Thinking about this more, I'm not sure that's the right approach; maybe it should just be ignored. Or, IMHO, not reported like this in the API; v1 didn't do this, and it seems unnecessary because "on" is what you can look at to get the switch state...)

Anyway, the very last/top entry here is something calling "setLevel." That's not CoCoHue but must be some other app. I'm guessing that's your ML instance, but I can't say why. Could something in that ML onfiguration be causing this oddity?

Ken_Fraleigh · February 2, 2023, 3:41am

Seeing that it’s 100%, that was probably from me hitting the wall switch because I couldn’t see. My ML instance has been very reliable (I try to stick with the KISS principle). I’m having the same issue on my other hub (also a different Hue bridge) with another ML rule using Hue lights. This did go away when I reverted back to 4.1.2, so it was something in 4.1.3 that broke my setup.

If you need me to experiment, let me know, I just don’t know how to code this.

bertabcd1234 · February 2, 2023, 3:47am

I can try releasing this modification myself since I think it's the right idea anyway, but if you wanted to test yourself: whatever bulb driver this is, there should be a line like this a couple dozen lines after the void createEventsFromSSE(Map data) { line:

     case "dimming":
        eventName = "level"
        eventValue = scaleBriFromBridge(value.brightness, "2")
        eventUnit = "%"
        if (device.currentValue(eventName) != eventValue) {
           doSendEvent(eventName, eventValue, eventUnit)
        }

For me in the current RGBW bulb driver, this starts at line 362. If you replace this line (line 366 for me, but could be different for you):

if (device.currentValue(eventName) != eventValue) {

with this:

if (device.currentValue(eventName) != eventValue && eventValue > 0) {

it would be one way to do what I'm thinking.