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

[razorwing]

@bertabcd1234 Here is what I get in the log when I do a refresh on the cocohue hub.

dev:49482022-11-18 02:51:20.857 PMdebugcreateEventsFromSSE([id:e69041d7-32d2-43fc-a33a-b89bd62c7de3, id_v1:/sensors/15, light:[light_level:17126, light_level_valid:true], owner:[rid:93f5a59a-8597-4f9d-8bae-09d45df99b3f, rtype:device], type:light_level])

[bertabcd1234]

Is that the only entry? IIRC, the v1 API splits these out into different IDs, and it's possible the other ones (which might include battery) just aren't getting matched to this device.

[anon47916022]

Hey Robert, what do you make of this? "Master Bath Overhead" is a group in Hue. I'm using RL to manage the group. I've noticed this pattern where any time an RGB color is set, the driver comes back with these additional events about being set to CT and color Sodium.

[bertabcd1234]

Can't tell without debug logs, but I'm guessing Hue is only reporting the xy color instead of hue/sat color; Hubitat cannot work with the former natively, but there is usually still a CT value in that data, which CoCoHue will latch onto instead. I've been looking at ways to reliably convert this, especially as the Hue v2 API uses it more, but I haven't found anything reliable yet.

[anon47916022]

I'll throw debugging on and come back with more logs.

[anon47916022]

Here we go. I enabled debugging and just used the "Set Color" tile from the device page to set Red (255,0,0).

[bertabcd1234]

Yep, that's what's happening. I haven't seen color commands from Hubitat be seen as xy before, only Hue scenes and other things from the Bridge.

[anon47916022]

Well...I had a weird issue with Room Lighting for this room last night. I think this caused the problem. Normally, it wouldn't be an issue, but the stars aligned.

[NEW APP] Room Lighting

Will the RL instance show "not active" until the lights report back? Maybe there was a delay in the table updating that caused the problem. Looking over the logs again, I see that the instance did finally flip to "active" at 12:36:05...almost a full minute after the activation even at 12:35:06. The two events to turn the lights off just happened to come in during that one minute window.

RL Setup

<a class="lightbox" href="https://community.hubitat.com/uploads/default/original/3X…

So, basically, the table in RL doesn't update until the groups flip their switch state to "on" which you can see in the logs doesn't happen until after those CT entries. So, there's a delay between the activation event and the instance going "active."

Normally, that's not an issue, but I managed to hit an edge case last night. The RL instance deactivation event happened while the status was waiting to be updated from the lights. That caused the lights to not turn off on their own. So order was:

1. Motion event to activate RL instance.
2. Commands go out to light groups.
3. Lights come on, but switch state doesn't update.
4. Motion goes inactive. Since the table isn't updated from the lights, the "off" action is skipped.
5. The switch states updates and the RL instance goes "active."

[CurtisZM]

What would be a good way to have activate CoCoHue scenes in Google Home?
RM?

[bertabcd1234]

Doesn't the scene device work directly if exposed to Google Home as a switch? But there's really no need to use Hubitat for this; Hue has a native Google Home integration, unless you're on the v1 Bridge that is no longer supported for this.

[CurtisZM]

I just used Hubitat. I'll give that a try. Thank you.

[dan-edge]

Has anything related to hue groups changed recently ? I’ve noticed that all of my hue groups added via Cocohue no longer react to the on / off command. However other commands such as “flash” still work. This is both through the UI and in rules.

I’ve reauthorized the bridge and given both a reboot but no change ..

[bertabcd1234]

I am not able to replicate this problem. Any errors in Logs?

[dan-edge]

Error from Hue Bridge: [type:901, address:/groups/9/action/on, description:Internal error, 404]

This is the error I see interestingly other commands such as flash work

[bertabcd1234]

Interesting. Causal Googling suggests that's an error on the bridge (as I guess it says) and not with the command being sent, but I'm not sure why. If you're doing a lot at the same time, maybe slow it down to see if you're hitting a rate limit?

[sburke781]

Hi @bertabcd1234,

I've started seeing this error appear in the logs on my HE hub where I run CocoHue. Any ideas? The JSON output immediately after the error message is quite long. I can send it you in a PM if you like.

[bertabcd1234]

Yes, I believe it is this longstanding issue mentioned above:

@bertabcd1234

If a large number of events are received all at once (e.g., if turning off an "All Hue Lights" group--whether inside or outside of Hubitat), either the Hue Bridge or Hubitat (haven't figured out which yet) seems to cut off the data, usually resulting in malformed JSON and the inability to parse the events. Thus, I do not recommend completely disabling polling at this point.

As far as I can tell, this is something odd with how Hubitat's eventstream library is handing this incoming data or perhaps with how the connection options are being specified on my part, though if it's the latter, I haven't been able to figure out anything that works (there are very few combinations that do; I suspect this might be a side effect of specifying rawData: true, but it doesn't work at all without that). The issue is that the eventstream data gets split up among multiple calls to parse() in the driver instead of coming in all at once, and then each chunk is generally invalid (on its own) and causes this error when trying to parse it.

I've only seen this when large amounts of data are sent at the same time, e.g., when turning off or setting color/CT on all Hue lights or at least large room or zone. Data should eventually catch up via polling (which I recommend keeping enabled still for this reason) or, should they happen on affected devices, other changes on the eventstream interface.

[sburke781]

Ok, thanks. That may be possible (large number of changes). Weirdly I have turned the eventstream option off and it still seems to happen.

Also, and I can't confirm this 100% just yet, but I wonder if it may coincide with elevated load and temperature on my hub. Still working through the logs and figures before I can be sure. Still a good chance it is unrelated. I started to see the elevated load at 2-3am earlier this week, so wouldn't expect too much to be happening with the lights at that time.

[sburke781]

I am wondering whether @gopher.ny 's comments on the original eventstream / websocket conversation may be relevant. He spoke about making changes late last year. Did these platform changes get applied @gopher.ny ?

EventStream / WebSocket closes immediately after connect to Hue bridge

Multiline data: handling will be in the next beta iteration. Driver will get a \n delimited string put together from the consecutive data: lines.

EDIT: Actually, that seems to be a different problem, multi-line vs long text....

I am also using the Advanced Hue integration by @armand. I don't see the same error come up there, could there be a difference in the way the two (Advanced Hue and CocoHue) are handling the eventstream data?

[armand]

@sburke781

I am also using the Advanced Hue integration by @armand. I don't see the same error come up there, could there be a difference in the way the two (Advanced Hue and CocoHue) are handling the eventstream data?

Odd. I thought burt and I came up with the same solution.

@bertabcd1234, feel free to compare my code against yours. I put my connection manage inside my hub driver.

    String url = "https://${parent.getBridgeHost()}/eventstream/clip/v2"

    String apiKey = parent.state.username.trim()
    Map headers = ['hue-application-key': apiKey, Accept: 'text/event-stream']

interfaces.eventStream.connect(url, [
        ignoreSSLIssues: true,
        rawData: true,
        pingInterval: 5,
        readTimeout: 3600,
        'headers': headers])

And my parser:

if (type == 'data') {
            Map hubEvents = [:]
            parseJson(message).each { event ->
                if (this[SETTING_DBG_ENABLE]) {
                    log.debug "Parsing event: ${event}"
                }

                Map data = event.data[0]
                switch (event.type) {
                    case 'add':
                        addEventHandler(data)
                        break
                    case 'delete':
                        deleteEventHandler(data)
                        break
                    case 'update':
                        updateEventHandler(data).each { nid, props ->
                            hubEvents[nid] = hubEvents[nid] ?: [(nid): [:]]
                            hubEvents[nid] << props
                        }

                        break

                    default:
                        if (this[SETTING_DBG_ENABLE]) {
                            log.warn "Unhandeled event type: ${event.type}"
                            log.debug "$event"
                        }
                }

            }
            
            hubEvents.each { nid, props ->
                def child = parent.getChildDevice(nid)
                parent.setHueProperty(child, props)
            }