There I was, thinking I was taking the next leap in my smart home journey. Coming from a stable Hubitat controlled system, I wanted a bit more power and flexibility. I wanted to be able to say I was using HA and part of the elite club. I decided to take the plunge. And now my home is possessed.
I joke bit it really is the case, specifically with my lights. I have the majority of my smart devices still connected to Hubitat and controlling my lighting. However, my lights are all connected via a Hue bridge (remnants of how they were originally set up) so HA has access through the Hue integration. I have no automations within HA controlling any of them whatsoever, yet HA is turning some off and on as if it is possessed. There is no rhyme or reason. I have groups where just 1 of the lights will randomly turn off leaving the other on. Some will just turn on occasionally. So bad I’ve had to disable the Hue integration so my wife doesn’t kill me. Checking the logbook, there are many entries of “Light turned on triggered by service Light: Turn on” or the equivalent off, but I have nothing set to trigger that and cannot find what is calling it. I am going to try enable some type of debug logging (if you call it that in HA) if I can figure out how and see if I can get more info. Until then, I will have to stall on my HA transfer
Should also note that I have my zigbee channel 5 away from the others and not close to my wifi so feel confident it shouldn’t’ be interference from HA that is causing this.
If anyone has had similar or can steer me down a good path to find out, it would be appreciated.
This is very weird behaviour, never seen anything like it in many years of HA. But then again, I havent tried linking multiple Home automation systems to the same Hue bridge.
Besides the log you could also check to see what automations where last executed around the time, but normally if an automation changed a light it would be mentioned in the log as such, plus what triggered the automation:
The log entry would be what you see when a light is for instance controlled from a dashboard. When a light is controlled from the outside (and HA just receiving the change) it does not mention the light.turn_on service for me. But that may differ per integration I guess though.
Does the weird behaviour coincide with moments when either system did control the light, say a couple of minute later? If more than one shstem is integrating with the hue bridge, I would not rule out some strange interference between the two. If a command is executed, but the light does not report success back, one of the systems might think it failed and revert the state of the light, thereby also undoing the command after some timeout. I also do not know what happens if multiple systems do a request simultanously.
If HA is talking to the Hue bridge (and Hubitat too?), how do you know HA is doing it, and not just reporting what it sees?
Huh? Did you mean 15? I do not think there exists a Zigbee channel 5 (I do know Chanel nr 5 - in that case your Zigbee smells nice and expensive ), For Wifi 5 is not a recommended channel, likely to overlap somewhat with the most common default Zigbee channel (15). Are you aware both use different numbering systems, so you should use a graphic to see which overlap?
However, having Home Assistant talk to HUE will not add to the Zigbee communication. It will send more wifi data though. How many devices are on the hue bridge? Could the hue be overwhelmed with two home automation systems frequently polling?
My experience with Hue bridge is very, very outdated so things might have changed. In the past integrating with hue was far from ideal since the state of the devices was not pushed to the home automation system, requiring frequent polling of all states to reduce delays. But then still it wasn’t good enough for motion detectors.So I moved away from it and bought myself a separate USB zigbee coordinator and never regretted the move.
Sorry, I meant it is 5 channels away from the others. E.g. HA is on 15 and Hubitat on 20. I just meant that, even though HA is communicating with the Hue bridge over ethernet, I doubt there was interference with hue controlling the lights due to interference from my HA zigbee dongle
That is what is throwing me. I can see lights changing state from controlling them through other means, but not that the service is called, implying HA is doing it.
Haha… ignore the zigbee channels. I was just trying to rule interference out as that is usually one of the first things people say. I don’t think it has anything to do with that.
My thoughts exactly. It’s saying something turned it on but nothing is there indicating what that was. I’ve enabled debug logging now so will see what that says. But morphy’s law now in that they are not misbehaving today yet.
No. I’ve been sitting in a room and about half an hour later the one light will just turn off.
I don’t for certain but it is a really big coincidence that I only got the strange behaviour after adding HA. That plus the fact that it says service turned it on rather than just saying it turned on leads me to believe it’s something in HA
When I first started there was a lot of talk around bulbs breaking the zigbee mesh so the advice then was to keep bulbs seperate. This is why I used the hue bridge. Well, that and the fact that the app is easy to make a quick change of lights. I have been considering moving everything to HA. When you say a “separate USB zigbee dongle”, do you mean you are running your bulbs off HA but on a separate zigbee network. I didn’t know that was possible.
What you should not do is put a bulb behind a physical switch that unsuspecting people turn off, killing the power to the bulb. But any coordinator hates that. Keep smart bulbs always powered. Then the mesh stays most stable.
Putting the bulbs on a different coordinator puts the bulbs on a different mesh. The other mesh will then have way less routers, leading to a weaker mesh. Similar to having all the bulbs off power. So imho one mesh is always best, dust do not kill power to routing devices.
It will say that for anything that turns on the light. Alexa does it too - and Alexa hunches will drive you up the wall because of this very same thing. Something is influencing lighting, ha just told you it happened. Yes it may very well be due to your new config (did you create an inadvertent loop or race somehow?)
If ha is connected to the system and Hubitat makes a lighting change you will see:
Service turned on light foo
So if you suspect ha making things nuts temporarily disconnect ha If it continues it’s not HA.
Yes we harp on interference first because that’s almost always the problem. Here I doubt it’s that. But I also don’t think it’s HA either m it sounds like swapping things over to the new mesh may have both meshes running weak. But there’s not enough here yet to know.
That’s not how it is working for me. I tested switching the lights from the Hue app, Hubitat and Google, and all just say “turned on” and “… off”.
It is only this ghost behaviour that says service turned off, etc.
All this said, since I disabled and now re-enabled the Hue service, nothing has happened. Maybe just lucky now or possibly an issue that was resolved with that process. Time will tell.
), For Wifi 5 is not a recommended channel, likely to overlap somewhat with the most common default Zigbee channel (15). Are you aware both use different numbering systems, so you should use a graphic to see which overlap?
