Zigbee bulbs changing state to "on" by themselves while staying off

I don’t know exactly how to summarize a topic for this one. Some many months ago I discovered a pattern to two of the lights at home where “every” morning these same two lights require me to turn them on twice to actually turn on. Some more digging and it turns out that at 00:15 almost every night (although not every night) these two lights change status to on while remaining off. At first I did not realize this behaviour was caused by a state change as I mostly use physical switches to turn lights on. I have mostly IKEA Trådfri (Zigbee) lamps and for all of them there is a wall switch with a shelly behind in detached mode (most of them running ESPHome) and using the service: light.toggle in ESPHome to toggle the light. For the two affected lamps there are no automations including them, and the log only shows that the light switched state by itself (it would seem) as there are no triggers showing from service calls or automations (that these two lack). I don’t know where to look. I am running “the sonoff stick” with ZHA which I updated to some current firmware way back when I bought it closely after release. Its always the same two lights and I have at least a ducin more IKEA trådfri bulbs not acting like this. The two bulbs are of different models, are in different locations in the house (different sides of the coordinator even) and it always affects either both lights or none of them. One could have thought of a faulty bulb they are two affected ones and they switch states at the same time in the logs. The lights/bulbs that are acting out are of the following models.

  • TRADFRI bulb E27 WS opal 1000lm
  • TRADFRIbulbE27WWclear250lm

This sound very strange. I can think of a few things you have not mentioned, even you might have checked.

  1. Earlier automations including the 2 bulbs, have there been any?
  2. Any automation happening at 00:15
    The problem could be a “hidden” automation in “automation.yaml”, not showing up in the GUI. Check is easily done, open the automation.yaml in notepad and search for the entity name of the bulb. If not found, look for the same in scenes.yaml

There have been a lot of changes to the FW on the sonoff 3.0 Plus zigbee stick. Try a new version of the FW. Im using 20221226, however on Z2M.

Thank you @khvej for your input. I have searched the automations for the entity names and I was in deed wrong about none being there. There is one automation for each bulb and they are both enabled. Both automations are merely triggered by an IKEA 5 button remote each. The automations are almost identical in difference that one has dimming, both use light.toogle as a service. So the question about these would then be, could both these automations be triggered simultaniously at the same time every day and leave both these lights in akward state? I’ll try disabling them just for fun and see if the behaviour is gone. I could not find any entry that matches the string “00:15” in automations.yaml but who knows with a setup as old as mine (Been running home assistant for what feels like forever). Just came to think about AppDaemon and Node-Red that I have used more in the past. I don’t think I have anything related there but it’s worth taking a look. Although! worth pointing out again, should a trigger through the service.light not always show in the logbook?
I will also take your advice and update the firmware on the coordinator. :slight_smile:

One other idea. If you have any “zigbee bindings”. This will not show in HA as actions, as it is all handled directly in the zigbee mesh. Normally bindings are related to button presses, hence not a specific time. However in an old setup something might be there from old time. If you do not use bindings, maybe delete the zigbee groups/bindings to eliminate this possibility.
In regards to searching for the time, try and search for “minutes: 15” as the GUI will write the timestamp like this

I have now updated the coordinator to your same version (still the latest). Unfortunately updating the coordinator did not solve it. Looking now a bit at the bindings. This is something I’m not familiar with. Posting a screenshot of eachs bulbs bindings to get your thoughts. Also of a third light that does not act out.

Office Roof

Kitchen Table

And lastly a bulb that does not act out. This one is part of a zigbee group of 5 bulbs.

It seems the bulb that works fine has all the same groups the Office bulb has and the two existing bindings for the Kitchen table are also covered by the working bulbs bindings. So there is nothing special about these two that act out.
I also noticed looking at the timestamps a bit more in detail the last days that the time the two bulbs switch to a wrongful state is not the exact same second. It can even differ a few minutes but always at around the same time every day. Kitchen Table was “turned on” this morning at 12:00:19 and Office Roof at 12:03:27.

Agree the bindings look quite standard.

That the time is differing a little from day to day make a hidden automation less obvious, as an automation would run precisely:-)

Just to be sure, that light does not actually turn on, it only change the state in HA, right?

I do not have any IKEA lamps, so do not have any experience. Same with ESPHome, which might also trigger the change?

To get some more advises, I would include the “zigbee” tag, and repost. There are a lot of very knowledge people following the “zigbee” tag. Not sure they also follow the ZHA, with the limited number of responses.

Thanks. I’ll try a repost.
Yes, the bulbs change to state “on” but do not actually turn on. In the morning when I try to turn them on by clicking on a switch in the room it firsts toggles the light to “off” state and then on a second click to “on”, this time with the light on. It does not matter if it’s switched from ESPHome, it’s the same thing from the UI too. Bulb shoes as being on already and needs to be turned off to be able to be turned on again. The mention of ESPHome was because of how I mostly use manual switching of lights and how I’ve experienced/discovered this problem, but maybe just confusing to mix it in here. Although I guess any details could be worth mentioning as the problem is hard to explain.