Janky behavior and occasional errors controlling groups of lights #152
Comments
|
Hmmm...I haven't seen that issue before. Do you see duplicate commands if you control lights individually vs through groups? |
|
Hmm it doesn't seem to be sending duplicates when I control an individual light, but I do see some odd behavior. It generally goes like this:
Looking at the logs I see things like this It looks like Hubitat is sending back the current value of the bulb immediately when a command is issued which causes the UI to jump back to original position (or jump all over the place for groups) until another message comes in with the result of the command. edit: Could it be the Hubitat driver for the bulbs? These are all sengled element color plus bulbs using the built in Hubitat sengled driver. |
|
I see the same error when using call service to turn on a single switch from node-red. I have a variety of Z-Wave switches in my house, and I'll see the error for any of them. I see no corresponding error in the habitat log. In fact, the command to turn the switch on/off usually works despite an error being logged. If I plug the link in my web browser, I'm able to access the JSON no problem. |
|
It looks like Hubitat is returning an error page. Do you see it every time you try to control a switch? |
No, but it does appear at least once a day during normal activity. I haven't been able to identify any patterns as of yet. I have the switches mapped as "lights" in Home Assistant's Hubitat integration. I'm playing around with converting them to straight switches. I'm hoping this might also fix an issue I have where I don't see whether an event has a type of "physical" or not. |
|
I see this JSON when I navigate to the URL in my browser. |
|
As far as the "on" command and the physical vs digital event data go, it shouldn't matter whether the device is a light or a switch. At least, Hubitat is going to send the same data over regardless of what HA classifies the device as, and both switches and lights use the same "on" command (e.g., If the error is sporadic, it could be that the Hubitat is overloaded for some reason and is returning temporary error page. I'll see about updating the communication code to output the HTML page to the debug log. |
|
Hi all, I'm experiencing the same issue actually. I haven't figured out how to gather and go through all the logs yet, but I've got basically the same setup (same bulbs, hubitat, node red, home assistant), behaviors, and issues. Happy to provide more info once I'm able to dive in further for debugging, or if someone can give me a high level overview. I also have some variety in my setup, so I can compare behaviors too. I've noticed that in node red on home assistant, if I use the call service with data, the light won't turn on (but will have the right color when next turned on). I have to send an additional empty data (the only difference) turn on call. I'd love to help debug and hopefully get this fixed :) |
It will be a bit easier to see what's going on when you enable debug logging and look at the Home Assistant log. Calling the The key things are that an If the expected commands are being sent, then lights should be updating. If they're not, there's likely an issue somewhere on the Hubitat side (either in Hubitat itself or with the light network) that I can try to work around if we can nail down what it is. |
|
Alright, I spent some more time debugging, and after getting very confused about things suddenly working, I've got some more information. At some point in my testing, I updated to v0.9.10 after reading the changelog and not thinking anything of it. Turns out it fixed a bunch of things related to this. I don't have the issue where scenes don't turn on the bulbs anymore, or the one where the call service with data wasn't turning the bulb on. I've got some logs to compare the versions too. This is on v0.9.8 turning on 3 lights using a scene with SmartBulb7 already on. All bulbs change to the set color data, but 1 and 6 do not turn on. This is on v0.9.10 turning on 3 lights using a scene with SmartBulb7 already on. All bulbs change to the set color data, and 1 and 6 now do turn on. This is on v0.9.8 turning on a light using Node-Red with the previously mentioned call service + data setup. The light does not turn on. This is on v0.9.10 turning on a light using Node-Red with the previously mentioned call service + data setup. The light now does turn on. Something else of possible interest is the settings I'm using in Hubitat for the Sengled bulbs. I think the attribute reporting interval combined with the transition time and/or prestaging might be why the color/hue/brightness bars jump around when changing. From the logs at least, it seems to match up to the 1s reporting interval, but over 3 seconds which doesn't really add up to me (lot more than 500ms as set). I also ran into the json parse error when turning off a nested group (using the off switch on an entities card with 3 lights and 1 light group which contains those 3 lights). Looks like it doesn't realize the containment and therefore sends the the commands twice, but I'm not sure why the json parse fails as it seems valid to me.... Something within the data failing validation then perhaps? Is it just that it's set as html and therefore it doesn't even try to parse as json? Is the mime type being wrong a hubitat / maker api issue, or does the request specify the return type? Anywho, thanks for working through this with me and for your changes in the latest updates! |
|
Thanks for the logs! Interesting... I'd guess some lights weren't turning on with 0.9.8 because they weren't being sent an explicit
Yeah, if the transition is implemented manually by Hubitat, or the bulbs are sending Hubitat, multiple updates while transitioning, it could result in Hubitat is sending a series of update events as each bulb settles, which could make things jump around a bit. The JSON error is very interesting. That's the first time I've actually seen data with that error (I finally added some logging for that in April, but this is the first time I've seen output from it). It looks like the message content is valid JSON, but for some reason Hubitat gave it the content type of text/html, which confused the response parser. Hopefully 0.9.10 has taken care of most of the issues. I just published 0.9.11 with a workaround for the "Unable to parse as JSON" errors. |
|
Makes sense with the transition stuff, I imagine that's a limitation of the bulb reporting then, which I imagine is either bulb firmware or the driver in Hubitat. Unfortunate but not the problem of this integration I don't think. :) Looks like the JSON error is gone too now! I imagine that's a bug in the Maker API maybe? Wonder if there's an issue open for it... Unfortunately I think I found a new problem haha. Using the built in home assistant sliders and such no longer works lol. I'm on 0.9.11 and the new Hubitat update that just came out, but I think it's the integration. Here's some logs from me clicking the slider to two different brightnesses. Looks like perhaps it's forgetting to send the brightness info and only sending the turn on command? Using scenes to change doesn't seem to work anymore either, log below (do note that bulb1 isn't responding properly and can be ignored, but the other two definitely aren't changing, only turning on) I think it might be responding to color temp changes (but not RGB color changes) with the scenes, but I didn't mess with it enough to know if it reliably is changing. Brightness definitely isn't changing, but the bulbs are turned on if off. One more round of debugging? :) |
|
Actually, I've been playing around more with manually changing colors, that seems functional but Home Assistant isn't realizing the change. I can see in the Hubitat device view that things are changing. Changing white temperature seems to work and report back properly. Brightness is not getting sent or updating. On/off works fine. |
|
The issue there happened when I refactored the light entity to use the This is fixed in v0.9.14. |
|
Thanks for all your help so far, but unfortunately I think something's still amis. I'm on Hubitat 2.3.7.145, integration v0.9.19, and HomeAssistant (core) 2024.1.1.
Log during scene change to full brightness daylight white, where all but bulb 7 are off, at minimum brightness, and blue. Only bulb 7 visually changes, but the others are at the correct settings once manually turned on. Hopefully another quick fix...? :) |
|
At quick glance, looks like my previous analysis is still the case on integration v0.9.21, just as some more info. Let me know if there's anything else I can provide. Thanks! |
|
It seems like your lights may require an Hmmm...I could have the integration just always send an If you call |
|
Current settings: After further testing, changing the duration, transition time, and the color prestaging had no effect (at least in white mode), but turning off level pre-staging changed the behavior of setLevel to now turn the bulb on. Very interesting... I'm not quite sure what to make of this yet... Thoughts? |
|
Some additional testing, disabling color pre-staging also makes the bulbs turn on when they're white and off, then set to a color. Is there a "correct" way to have things? I guess this means I can pick between manually preloading a color and then turning it on, or having it in one step but the color is slightly weird as the bulb turns on (which honestly it is either way lol, silly bulbs). Hmm... |
|
Yeah, according to this post, this might be working as intended, whoops. Good to know though. I'll keep an eye on things over the next few days and make sure everything makes sense, but maybe all is well... :) |
|
I think the integration would need more work to handle pre-staging well. Presumably it would want to wait for acknowledgement that the initial commands had completed before sending an on command. It might also need to take transition times into account. Tricky. |
I've got a bunch of smart bulbs exposed to ha via Hubitat. I have the bulbs in ha groups. When I control the groups the behavior is "jittery", the sliders for level or color temperature will jump all over the place when changed and sometimes the correct values don't get set.
Here is what I see in the logs when I tap the color temperature slider a single time on one of my light groups -- it looks like it sends both an
onand asetColorTemperaturetwice to each light.I also occasionally get an error from the integration about decoding json with an unexpected mime type. This doesn't always happen, maybe 1/10 times when controlling a group of lights.
Here are the relevant logs for the mime type error:
The text was updated successfully, but these errors were encountered: