Lights random turn on in HA UI (but not physically)

I tried finding similair problems and hopefully solutions, but it seems others have their lights turning on physically too, which is not the case in my situation. Correct me if i am wrong of course.

I’m experiencing the weird problem that my ikea GU10 LED bulbs random get the turned-on state in HA. The lights itself don’t physically turn on however. This happens in both rooms where i have these bulbs. The lights are in a single fixture which is controlled using the same physical switch.

The fixture in the diningroom contains 5 LED bulbs and they turn on on random times:
bulb 1: turned on at 08:32:24, was turned off by an automation at 10:00:00 and turned on at 10:02:25.
bulb 2: turned on at 08:48:45, was turned off by an automation at 10:00:00 and turned on at 10:50:11.
bulb 3: turned on at 08:32:23, was turned off by an automation at 10:00:00 and turned on at 10:32:03
bulb 4: turned on at 08:22:23, was turned off by an automation at 10:00:00 and turned on at 10:05:59
bulb 5: turned on at 08:32:24, was turned off by an automation at 10:00:00 and turned on at 10:02:25

The logbook only states ‘EetkamerspotXX Light turned on’, so no indication where the action came from (e.g Google Assistant or automation), and as said, the light itself is not turned on for real, only in the UI in HA. I have no other automations than the one which turned them off at 10:00.

I’m running HAOS on a NUC (Home Assistant 2023.4.1 / Supervisor 2023.04.0 / Operating System 9.5 / Frontend 20230406.1 - latest) and i use a SONOFF ZigBee 3.0 USB Dongle Plus, TI CC2652P for controlling my zigbee devices.

Does anyone recognise this problem and maybe even have a solution for it?

Hi, does the state stay to ON and what happens if you really turn them ON and OFF?
Which integration do you use?

Hi Nick, thanks for your reply, i use ZHA for controlling the devices. The state stays on, until I or an automation sends the turn lights off command. When I use a remote (using an automation) to turn the lights on, the lights go on, regardless of the state in the UI. When I first use the UI to turn the light off, it stays off, when I use the UI then to turn it on, the light turns on.

Following this topic. I just started seeing this behavior as well: ZigBee lights “turned on” in UI by itself (same log entry as OP) but lights aren’t on. HA in Docker, SkyConnect on Z2M 1.30.3.

‘good’ to see it’s not a specific ZHA or Sonoff issue then, hopefully anyone has gotten this issue before and has now solved it so we can do so too

Maybe this can help: Guide for Zigbee interference avoidance and network range/coverage optimization

I’m having the same problem since 2023.3 → 2023.4 with some Ikea lights (via ZHA/Conbee). I notice the “on” event comes shortly after an automation turns them off.

Are any of you by chance also using the HomeKit integration? I heard something about a bug in iOS 16.4 that causes bulbs that are off with a brightness of 0% to report at 100% incorrectly. Wondering if related.

Not using homekit, so no match there. I have my nuc situated on am way different place then my wifi devices, it’s connected by cable, the dongle is connected using a long USB cable and had a distance of around 50cm from the nuc and the 433 transmitter. Seems I have done the right things to prevent interference.

Perhaps a different match is that our affected lights are in a group?

I had defined groups, but I removed them for both rooms because I thought that could cause the problem. I can confirm that with the groups gone, the problem still occurs. It’s now simply a fixture with 5 led bulbs in then, by change all smart ones

Since a few days I too experience this issue.
On zha/sonoff on a PI4.

HA says it is on, but in fact it isn’t.
The third light in this group stays off. All Ikea bulbs.
It will light up if I toggle it twice


It’s interesting to see that people are having same issues as I am, even with ZHA. I always thought it has something to do with Z2M and/or SkyConnect.

Let’s say a problem shared is a problem halved, but better would be knowing the reason and solution of course. Hopefully someone encountered and solved it so we can do so too

With my Ikea lights, once I disabled the automation that was turning them off with a transition (even if they weren’t on), I stopped having the problem.

I switched this (which blindly targeted all lights in the area):

   - service: light.turn_off
     data:
       transition: 5
     target:
       area_id: '{{ area_name(trigger.entity_id) | regex_replace(find='' '', replace=''_'',
         ignorecase=False) | lower }}'

To this (which only targeted lights in the area that were actually on):

   - service: light.turn_off
     data:
       transition: 5
     target:
       entity_id: '{{ expand(area_entities(area_name(trigger.entity_id))) | selectattr(''state'',''equalto'',''on'')
         | selectattr(''domain'', ''eq'', ''light'') | map(attribute=''entity_id'')
         | list }}'

It seems in my case that the 5 second fading out transition (when not even on) is what put mine in that weird state.

FWIW, I also have a 1 second “Default light transition time” set on ZHA.

1 Like

Guys, to find the reason behind this and if you are experiencing this because of a common problem, it can help to compare some things like:

  • hardware you run HA on
  • installation type of HA
  • integration you use
  • coordinator
  • since when (which release) you have this problem

Just and idea…

Thanks, seems like a possible cause. I am going tot try this for the next days. I disabled the automation which simply tried turning all lights at sunrise (except for the toilet light :innocent:) and replaced it with one that is turning of lights are actually on. Will let you know in a few days

Update1: day 1, no lights turned ‘on’ yet, most of the time it happened every day and in the early morning. Will track for a couple of days to rule out luck

Update2: day 2, same result, none of the lights turned on while not being on physically. Currently my family is less present then normal, so this is also a difference in the situation, but i am starting to get up my hopes. Maybe one of the other can try this too to see if it solves the issue for them?

Update 3/last: 28-4, after a couple of days the light keep behaving as they should. I think calling the service lights for turning everything off while some/most/all lights are already off is a bad practise after all. The solution as suggested seems to work for me. I will therefor mark the proposed solution as the solution for my problem. Thanks again!

Good point Nick.

I’m running HA Container on a Pi 4, using ZHA with a ConBee II. I only started noticing this problem on 2023.4.x… I THINK the first version of which I upgraded to from 2023.3.x was 2023.4.4.

Hardware: NUC on Ubuntu
Installation type: Docker
Integration: zigbee2mqtt
Coordinator: Skyconnect
Since: Converted from ZHA/old Zigbee stick to z2m/Skyconnect

I’ve been having the issue of phantom lights turn “on” in HA but not really “on” in real life. I’ve been trying to track down not just the why, but how and from what source. I have MQTT explorer running and finally caught a situation where the light “turned on” in HA.

image
HA’s history shows the light was turned on at 3:18pm:

image
Looking at MQTT, there is no associated “turn on” at 3:18pm.

Do you have a automation which turns off all your lights at once without checking whether they are in an on-state?

For me the solution was to change my automation which turns of all my lights of based on the sunrise to an automation which turns off online lights which are in the on-state. Did not have any issues anymore since I changed it

I do not have an automation that turns off any ZigBee light (I have one for Kasa light switches).