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
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?
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.
Yes, I believe it is this longstanding issue mentioned above:
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.
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.
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 ?
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?
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)
}
2 Likes
From what I can see it looks to be roughly the same, apart from a slightly longer ping time of 10 in CocoHue.
That said, I only have my hue dimmer switches through AH, not my groups and scenes. Not sure if that would reduce the data being sent back from the Hue bridge.
With debug logging on AH, messages seem to come through as individual events..... maybe it's the polling in CocoHue that is producing the large message?
I use WebCore to handle the automation of the lights thru httpPut calls directly to the Hue Bridge. The CocoHue Groups on Hubitat will then have to wait until the next poll to be updated. As my house is completely over-automated, I've occasionally run into problems caused by this delay in the updating of the CocoHue devices (caused by the Hue Bridge not pushing events). To reduce my server load, I choose to have CocoHue poll the Bridge only every minute.
So....I added the following a new command, "setSwitchState" to my CocoHue Groups device code to allow me to immediately change the switch state of a group when I send I command to the Bridge. You can call the command in WebCore and in RM after turning the group on or off via an automation. Just send a string param of "on" or "off" when you call the command.
In the metadata of the code, add:
command "setSwitchState"
and in the body, add:
void setSwitchState(newState) {
if (device.currentValue("switch") != newState) doSendEvent("switch", newState, null)
}
In my code, when I receive an update for a light, I push a refresh, so that I can get the group updates. I recommend asking for such a feature from coco hue if it doesn’t do similarly. I am sure the developer is open to enhancement ideas.
Yes, that was another option, but this has the advantage of not updating every one of my lights, groups, and scenes.
How so? The event stream from hue does not send all the changes for groups and lights when a group is updated. A refresh forces all devices to update /sync up with hue. So, what I do, is I queue up a refresh to run 250ms in the future for the whole hue system. If other messages are being processed, the refresh canceled and a new refresh scheduled so that the last refresh happens 250ms after the last message is received. As long as you aren’t using hue animations that change something very aggressively this guarantees all devices are updated.
I have a pending update that when a group is updated, that I refresh all the lights in the group, and another that when a light is updated, I refresh all the groups that the light is in, so the updates require less overall processing and run faster, but this only serves to reduce HE hub load, and doesn’t impact processing.
Either way, this is off topic now. I have not looked at coco hue code. What I do is to parse one line At a time, and to queue up the messages to to processed shortly after receiving them. It is possible, that I did this because of how a hue sometime breaks up messages and sometime aggregates them, and this ensured a consistent solution to simplify parsing. Maybe that is where they differ and where issue arises? Maybe it has to do with how many devices and groups are changing at once?
Without getting into the details, you cannot deny that my solution is substantially less chatty than sending two separate commands to the hub. More importantly, the state change is instantaneous.
I am not challenging anything here. I am just trying to provide some additional insight. The how so (typo had it as how do) was in regards to the less updates reference. I am just curious.
1 Like
All,
I've just released an update, version 4.1.3, with some changes that mostly affect group processing (but could affect any time the eventstream includes multiple devices in the payload). So, if you were one of the people who noticed group states were not updating on/off or other easy attributes (so not necessarily RGB color...) right way, this should help. 
(Thanks to the user who noticed the underlying cause, who I don't know if is on the forum.)
As usual, for updates, you can:
- Find the update in Hubitat Package Manager (easy); or
- Download the latest bundle ZIP from the repo (above, easy if you prefer manual install); or
- Update the CoCoHue Bridge driver, which is really the only file that changed this time (if you manually installed all app/driver pieces)
Let me know if there are any issues!
6 Likes
Can you use a CocoHue scene as a trigger in Rule Machine?
If activated from Hubitat and done via a button commands like push(1), yes. Other methods (e.g., switch state) or activation from outside Hubitat are less reliable or won't work at all.
1 Like
I think that the last update has caused a problem with Hue groups in Motion Lighting. I have checked my logs and Events, which show that CoCoHue is turning groups back on milliseconds after ML turns them off. Let me know if you need any logs, I can send you whatever you need once I’m back at my computer.
Interesting. I'm not using Motion Lighting, but I'm not able to reproduce this by sending an "Off" command to the group, which I imagine is all ML should be doing, too. For troubleshooting, the most helpful pieces would be Logs isolated to the CoCoHue Bridge device and the group device in question (the app or "member bulb" logs may or may not be helpful too if these aren't alone, but it would probably be cleaner to start with that).
1 Like
