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.
Thanks’ for the clue!
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.
returns
{"entity_id":"scene.livingroom_off","state":"2024-01-23T08:28:46.404103+00:00","attributes":{"entity_id":["light.livingroom_anglepoise","light.livingroom_ceiling_light","light.livingroom_sconce_left_light","light.livingroom_sconce_right_light","light.livingroom_tree_1_light","light.livingroom_tree_2_light","light.livingroom_tree_3_light","light.livingroom_tiffany_lamp_light"],"id":"1699306916354","friendly_name":"Living Room Off"},"last_changed":"2024-01-23T08:28:46.404Z","last_updated":"2024-01-23T08:28:46.404Z","context":{"id":"01HMTPZ9Y3D2FX0ZX3M4EJR1WE","parent_id":null,"user_id":"f04f6c1a56bc4c9c80ce2bb23b46c9d2"},"timeSinceChangedMs":16721562}
regards
Steve
The mystery deepens. I saw a light go off, but the next day it was on again. The history shows it came on two minutes after I turned it off.
The logbook has scrolled, but here is a similar message 06:44:24:
So back to the original question - is there any way to further debug what might be turning on a light?
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.
If the event is not initiated in HA, then HA can’t say anything more than the event occurred.
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.
Hi @WallyR
thanks for these suggestions.
- 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.
- If it is a malfunctioning circuit then nothing is seen on the Zigbee network.
These seem to happen just after turning off a light.
- If it is power surge and the default turn on state in the bulb gets activated, then nothing is seen on the Zigbee network.
Again, these seem to happen just after turning off a light
I’m going to read the posts that @123 suggested.
I would recommend the opposite because:
-
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.
You’re right - but it might be worth trying as a diagnostic measure.
Here’s my understanding of how it works:
- 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.
In another post the OP mentions that he has 123 devices. 
Before trying to making changes to the current complex setup of groups try to just work with that/those bulb(s) that are malfunctioning.
Turn them off separately and see if that changes their behavior. KISS!
57 of them are light bulbs or sockets that act as repeaters.
Mystery solved.
Did not find out how to trace what is going on, but I finally spotted an automation issue.
I have two areas living room and sun room that form an open space. Each room has its own scenes to control the lights. However some lamps are used in scenes for the sun room as well as scenes for the living room.
When I turn off the lights for the night - I trigger sunroom_off and livingroom_off scenes. The lamps common to both scenes get two simultaneous off commands and sometimes get confused. Scenes have now been segregated and the problem resolved.
Thank you for the suggestions, I learnt more about HA / ZHA.
Steve