Hello,
My homeassistant / node-red setup has been pretty stable but recently I seem to have introduced a bug and am running out of ideas on what to check next.
At the end of the day, I press a button, all the living room lights fade out and the hallway lights come on. I leave the room and retire for the day. When I comeback in the morning I find one of the livingroom lights has been on for ten hours.
I can see in the history, that an automation (my button press handled in node red) turned off the lamp, but then 5 seconds later the lamp is back on but no indication of the trigger.
The device info shows scenes but no scripts refer to the this lamp
The command is sent to all the lights to turn off.
Home assistant sets the light states as off in anticipation (its optimistic).
Communication with one of the lights fails and it does not turn off.
At the next polling interval (5 seconds later above) home assistant reads the light states and sees one of them on, so it sets the state as such and logs it. This looks to home assistant like something outside home assistant turned on the light, hence there is no context (“turned on by…”) in the log. Where as in actual fact it was a failed communication and the light never actually tuned off.
Instead of a scene you could use a script that:
turns the lights off
delay
checks if all lights are off
if not loop back to the start (unless this is the 5th try, in which case stop).
If it can be a malfunction in the communication, then can also be a malfunction in the circuitry for turning the lamp of, which pevents it from staying off.
If the bulb has another way, like a vendor app, of being controlled then that can also have programmed setting to turn the light on again without HA knowning what sparked the change.
I’ll keep an eye out for this - instead of leaving the room, letting the lights dim behind me, I’ll hang around and see if one stays on or one comes back on.
The issue re-occurred last night whilst I was watching.
Press the button to fade out the lights in the living room over ten seconds. By the end of the ten seconds one light was still on. The history does indeed show the light went off when in fact it remained on.
I use Node Red in my automations and already record the scene as it is activated. Ideally I would like to iterate over the lights defined in a scene and compare them to their current statuses. Can Node Red query what is in a scene?
The get entities node can list the entities in a scene, but not the details. For the turn_off scene that’s not really an issue.
Based on what you explained, I don’t think anything is turning the light back on, it simply failed to turn off when the command to turn off was issued. That’s a symptom of a communication problem with the lighting technology being used.
Do all of the lights being turned off use the same integration? Or do they use several integrations? List the integration(s) they use, notably the one employed by the light(s) that fail to turn off.
They are all Hue bulbs connected with the ZHA integration.
In some cases I have seen the lights turn off only to find they are back on again a few minutes later. The log book entries only show turned on (no indication of the trigger).
If I was in this situation, I would suspect that my Zigbee network is the culprit.
When the scene is executed, numerous individual ‘turn off’ commands are transmitted, one per light, and the network fails to deliver all of them successfully to each light.
In other words, executing a scene that involves many lights is like a stress test for your Zigbee network.
There are extensive guides for improving Zigbee communications posted elsewhere in the forum.
The bulbs in question are connected via ZHA using the Home Assistant Yellow Zigbee Antenna. These are older Hue bulbs, so they only communicate via Zigbee (no Bluetooth). So should HA be able to see everything?
Even if a remote linked to the bulb sends a command to turn on the bulb, then HA would log that as a button press on the event bus and not as a trigger for the turn on event.
If it is a malfunctioning circuit then nothing is seen on the Zigbee network.
If it is power surge and the default turn on state in the bulb gets activated, then nothing is seen on the Zigbee network.
Yes, and this can be made much worse by using Zigbee groups (I think you mentioned groups in your other post?). When a group command is issued it is blasted out to all nodes in the network, just to make sure every device in the group gets it. This can swamp the network very quickly, particularly is several are issued in quick succession. If you’re using Zigbee groups, you might try HA groups instead.
Even if a remote linked to the bulb sends a command to turn on the bulb, then HA would log that as a button press on the event bus and not as a trigger for the turn on event.
I don’t think any remote is bound to one of the problematic bulbs - I looked in Manage Zigbee Device can see anything selected under Bindings > all the bindable groups.
Only one "turn off " command is needed to turn off all members of a Zigbee group. Regardless of how many members in the Zigbee group, only one command needs to be transmitted.
A Home Assistant group transmits a “turn off” command to each member of the group. The more members in a group, the more commands need to be transmitted.
The network can only distribute one message at a time.
A single, broadcast message, containing the group command, is heard by all devices.
The members of the group act on the command and non-members ignore it.
Compare one broadcasted message versus a Home Assistant group transmitting one unicast message per device; if there are ten devices, that’s ten consecutive messages.
As said before, indicative of Zigbee communications errors. Two scenarios I think might happen:
The turn_off command does not reach the bulb. The bulb stays on. At first, HA is optimistic and shows off. At some point, HA gets the actual status of the bulb and turns the state in HA back to on to match the real state of the bulb.
The turn_off command has reached the bulb, but HA does not get the confirmation. Thinking it has been over optimistic that the off command has worked, HA turns the state back on (maybe triggering the on command to the bulb in the process? This is a guess, but I’ve seen behavior that suggests this is the case).
Your logging also seems to indicate there may be a very long time between the off command and the state turning on. That is weird for the above scenario’s (but not proof that communication is fine).
That points more in the direction of a power interruption (loose wire, briefly disconnecting when someone slams a door or just temperature changes). A lot of bulbs default to on when power is interrupted. This is often a setting. But if there’s a faulty connection, it really needs to be fixed to prevent fire. Changing the setting is not fixing the real problem.
