[Bug]: Overhead lights turning on when Sleep mode active

[lnlyssg]

System Health details

System Information

version	core-2026.3.1
installation_type	Unsupported Third Party Container
dev	false
hassio	false
docker	true
container_arch	null
user	abc
virtualenv	false
python_version	3.14.2
os_name	Linux
os_version	6.8.0-94-generic
arch	x86_64
timezone	Europe/London
config_dir	/config

Home Assistant Community Store

GitHub API	ok
GitHub Content	ok
GitHub Web	ok
HACS Data	ok
GitHub API Calls Remaining	4993
Installed Version	2.0.5
Stage	running
Available Repositories	2859
Downloaded Repositories	74

Home Assistant Cloud

logged_in	false
can_reach_cert_server	ok
can_reach_cloud_auth	ok
can_reach_cloud	ok

Dashboards

dashboards	3
resources	44
views	6
mode	storage

Network Configuration

adapters	lo (disabled), enp3s0 (enabled, default, auto), tailscale0 (disabled), br-02b9b50e1b22 (disabled), br-1de244ec2844 (disabled), br-76a42e6c00e9 (disabled), docker0 (disabled), br-d18ea03928ea (disabled), br-214c410d493b (disabled), br-7f18929121a4 (disabled), br-8c9e73454760 (disabled), br-c7bdb94dbf85 (disabled), veth8ead3f5 (disabled), vetha9eff71 (disabled), veth61334dc (disabled), veth8e584fe (disabled), veth506f0bb (disabled), veth6932c90 (disabled), vethb80baef (disabled), veth562d40b (disabled), vetha4479a2 (disabled), vethf0ae92e (disabled), veth37d6b9c (disabled), veth69c6889 (disabled), veth7c4d95d (disabled), vethd437289 (disabled), veth0ec45e4 (disabled), vethe92d73b (disabled), veth6b5cfcb (disabled), vethdf8a395 (disabled), vetha25aef8 (disabled), vethf34310d (disabled), veth3cf81c6 (disabled), veth9edee10 (disabled), veth7d1fb51 (disabled), vethbfd8964 (disabled)
ipv4_addresses	lo (127.0.0.1/8), enp3s0 (192.168.4.46/22), tailscale0 (100.80.0.5/32), br-02b9b50e1b22 (172.24.0.1/16), br-1de244ec2844 (172.18.0.1/16), br-76a42e6c00e9 (172.20.0.1/16), docker0 (172.17.0.1/16), br-d18ea03928ea (172.19.0.1/16), br-214c410d493b (172.22.0.1/16), br-7f18929121a4 (172.26.0.1/16), br-8c9e73454760 (172.21.0.1/16), br-c7bdb94dbf85 (172.23.0.1/16), veth8ead3f5 (), vetha9eff71 (), veth61334dc (), veth8e584fe (), veth506f0bb (), veth6932c90 (), vethb80baef (), veth562d40b (), vetha4479a2 (), vethf0ae92e (), veth37d6b9c (), veth69c6889 (), veth7c4d95d (), vethd437289 (), veth0ec45e4 (), vethe92d73b (), veth6b5cfcb (), vethdf8a395 (), vetha25aef8 (), vethf34310d (), veth3cf81c6 (), veth9edee10 (), veth7d1fb51 (), vethbfd8964 ()
ipv6_addresses	lo (::1/128), enp3s0 (fd01:a79d:a60:4efe:9e5c:8eff:fe83:d064/64, 2a0a:ef40:9bc:1900:9e5c:8eff:fe83:d064/64, fd8e:37f6:5d66:1:9e5c:8eff:fe83:d064/64, fe80::9e5c:8eff:fe83:d064/64), tailscale0 (fd7a:115c:a1e0:ab12:4843:cd96:626a:3527/128, fe80::76f5:8abb:b0a4:6c6b/64), br-02b9b50e1b22 (fe80::dc12:9fff:fe2a:386/64), br-1de244ec2844 (fe80::18b9:d2ff:fe1a:2cb5/64), br-76a42e6c00e9 (fe80::60e4:a8ff:fe79:b8ba/64), docker0 (fe80::40f9:2bff:fe2c:3ae5/64), br-d18ea03928ea (fe80::64d0:7eff:fe3d:a982/64), br-214c410d493b (fe80::8024:2eff:feec:4eea/64), br-7f18929121a4 (fe80::3c83:a5ff:fe44:250d/64), br-8c9e73454760 (fe80::4cfd:d1ff:fef3:c558/64), br-c7bdb94dbf85 (fe80::448b:5ff:fe5e:1d22/64), veth8ead3f5 (fe80::344e:1aff:feb4:7d3d/64), vetha9eff71 (fe80::d8a8:b7ff:fee6:a258/64), veth61334dc (fe80::3c9b:daff:fe58:f11a/64), veth8e584fe (fe80::8c17:7dff:fe39:d3b7/64), veth506f0bb (fe80::d87d:34ff:fe19:2a53/64), veth6932c90 (fe80::6873:8aff:fe7a:692c/64), vethb80baef (fe80::74a4:8fff:feb2:69ab/64), veth562d40b (fe80::1cc2:14ff:fe27:15be/64), vetha4479a2 (fe80::5c21:15ff:fe11:a456/64), vethf0ae92e (fe80::f8da:beff:fea0:214/64), veth37d6b9c (fe80::d4fe:30ff:fed3:a328/64), veth69c6889 (fe80::841e:d1ff:fea3:7824/64), veth7c4d95d (fe80::c46d:1eff:fe09:46b7/64), vethd437289 (fe80::1005:9ff:fe58:e13b/64), veth0ec45e4 (fe80::5844:66ff:feeb:1d65/64), vethe92d73b (fe80::8c09:80ff:fe49:49ab/64), veth6b5cfcb (fe80::1c9e:8cff:fea0:d29b/64), vethdf8a395 (fe80::f4d7:aff:fe66:7df2/64), vetha25aef8 (fe80::a838:50ff:fe0e:6253/64), vethf34310d (fe80::fca0:84ff:fe2a:49d1/64), veth3cf81c6 (fe80::9c88:5aff:fecd:bbed/64), veth9edee10 (fe80::10ca:53ff:feab:4888/64), veth7d1fb51 (fe80::8f8:2aff:fe5a:ca5c/64), vethbfd8964 (fe80::147f:fff:fe8f:f847/64)
announce_addresses	192.168.4.46, fd01:a79d:a60:4efe:9e5c:8eff:fe83:d064, 2a0a:ef40:9bc:1900:9e5c:8eff:fe83:d064, fd8e:37f6:5d66:1:9e5c:8eff:fe83:d064, fe80::9e5c:8eff:fe83:d064

Recorder

oldest_recorder_run	5 March 2026 at 20:47
current_recorder_run	14 March 2026 at 21:48
estimated_db_size	3645.25 MiB
database_engine	sqlite
database_version	3.49.2

Sonoff

version	3.10.2 (71e47be)
cloud_online	4 / 4
local_online	4 / 4

Checklist

• I have enabled debug logging for my installation.
• I have filled out the issue template to the best of my ability.
• This issue only contains 1 issue (if you have multiple issues, open one issue for each issue).
• This issue is not a duplicate issue of any previous issues..

Describe the issue

I'm struggling to debug this one as it has all been working fine up until last week and I haven't made any changes to Magic Areas.

I have two rooms with light control enabled - kitchen and landing, both have motion sensors, sleep mode toggles (from Adaptive lighting) and overhead lights defined. For both rooms the Sleep lights are empty and up until recently no lights were turning on in either room when sleep mode was enabled and presence was detected. From out of nowhere the kitchen lights have now started turning on (since around 10th March) but the landing continues to work as expected and the light remains off at night.

I've tried enabling/disabling pretty much every option in the light groups config to get it working including setting a separate sleep light (a DnD light on a smart plug) but the main overhead lights still turn on no matter what I do. I ran the debug logs through Claude and it seems to think there's a race condition... I take everything LLMs say with a grain of salt as I've seen far too many hallucinations to blindly trust them but I've included the relevant snippet further below in case it is actually helpful.

Reproduction steps

1. Enable Magic Areas light control, leave sleep light empty (or set a different light completely)
2. Add a sleep toggle in Advanced area state
3. Enable sleep toggle
4. Enter room - lights should remain off but they turn on

Debug logs

There is no "paste/drop/click to add files" option for this field - I'll add the debug logs in the next stage instead. This is what Claude suggests may be the issue:

It's the same race condition as before, but now we can see exactly what's happening. The crucial lines are:

Line 39111-39114 (SyncWorker_6, the first to process the event):
Overhead Lights: Assigned states: ['occupied']
Has priority states? False  ← evaluated BEFORE Sleep Lights group is known
Group should turn on!  ← fires the lights

Line 39261-39262 (SyncWorker_61, a later thread):
Sleep Lights: Assigned states: ['sleep', 'occupied']  ← wait, what?

Multiple threads are simultaneously evaluating the same kitchen area state change event. The first thread (SyncWorker_6) evaluates the Overhead Lights and asks "are there any priority states active?" — but at that exact moment the Sleep Lights group hasn't registered itself yet, so the answer is "no priority states", and it fires. A few microseconds later, SyncWorker_31 correctly sees dark as a priority state and noops. But SyncWorker_6 already won the race.

Diagnostics dump

home-assistant_magic_areas_2026-03-16T10-11-23.787Z.log

[jseidl]

Sorry for the delay getting back to you on this, been quite busy at work.

It's quite weird that it works differently on two areas configured the same.

Whenever you can reproduce this error, can you please provide

• Screenshot of the area state (developer tools is best as it shows all attributes) for the kitchen (verify that sleep state is there)
• Screenshot of the history for the light that turns on (overhead?)

[joneshf]

Heya! I'm also in this situation. 3 of the 5 areas that have both overhead lights and sleep lights work like before (only turning on sleep lights), 2 of the 5 areas that have both overhead lights and sleep lights work as described in this issue (turning on overhead lights and sleep lights). I did just update from Home Assistant 2026.2.3 to 2026.3.4 yesterday. So it's possible that something in 2026.3.x is causing this. I know they changed something about the lights, but I'm not sure what.

[joneshf]

I did:

# ha core update --version=2026.2.3
Processing... Done.

Command completed successfully.

And all 5 of the areas that have both overhead lights and sleep lights are working as before (only turning on sleep lights). So it seems there's something broken in 2026.3.x.

[lnlyssg]

I originally discounted the upgrade to 2026.3 as I didn't notice the issue until a few days after I'd upgraded but it's possible I just hadn't realised it was an issue. Most of the changes in 2026.3 for lights were about removing deprecated options but there was also an update for Python too.... given what Claude suggested to me above regarding race conditions in threads I googled for python 3.14 and threads and there's a bunch of posts about changes to free threading that could be relevant?

[jseidl]

Whenever you folks can reproduce this error, can you please provide

• Screenshot of the area state (developer tools is best as it shows all attributes) for the kitchen (verify that sleep state is there)
• Screenshot of the history for the light that turns on (overhead?)
• Screenshot of the light group's attributes (for both overhead and sleep light group entities)

This will help me have a better idea on what could be going on.

A new release of HA just came out today, can you folks update and let me know if that still happens?

[lnlyssg]

I've just updated to HA 2026.4 and there's a chance it may be fixed based on some initial testing. I'll carry out more real-world tests later and report back.

[joneshf]

It'll be a few weeks for me to update to the 2026.4.x versions; but yes, I'll eventually update and see how it goes.

Sorry for the delay, but I no longer install the first couple of versions of a series because too much stuff regularly breaks in the first couple of versions, and my setup needs to be more reliable these days. That's why I didn't run into this issue with the 2026.3.x series until last week.

[joneshf]

Okay, so good news, bad news.

• Good news: I reproduced this issue on 2026.2.3.
  • That means it's either not actually related to the 2026.3.x series, or upgrading to 2026.3.4 caused something to change in the state in a way that doesn't change back when downgraded to 2026.2.3.
  • Complete unrelated to this issue, the default overview dashboard crashes for me now and I think it's because updating to 2026.3.4 gave me this change, and it seems to not go away now that I'm back on 2026.2.3. All that to say, the state getting messed up after an upgrade and not restoring on a downgrade is a real thing that affects even plain old Home Assistant.
  • That also means I'm okay with upgrading to a newer version, since being on 2026.2.3 isn't going to stop this bug from happening, apparently.
• Bad news: I reproduced this issue on 2026.2.3
  • That means that either this bug has been latent or not reported for a bit, or it's as hinted above that once you upgrade to 2026.3.x something changes in a way that a downgrade won't fix.

The latest iteration of this issue is affecting 1 of the 6 areas with both overhead lights and sleep lights (added one more area since my last message). I checked the 1 area that's having the issue against 2 others that are not, and modulo the underlying entities in each area:

• All of the entity states look the same for each area:

  Entity states without occupancy

  
  Entity states with occupancy

  

• All of the settings look the same for each area:

  Main Hallway (the area with the issue)

  
  Office Hallway

  
  Owner's Bedroom Hallway

  

• The activity only shows the area with the issue turning on:

  Activity

  

• All of the "Light Control" switches are enabled for each area.

So yeah, I don't see anything that's visible that would explain this issue.

[joneshf]

Also, this might be related, or it might be a completely different issue. But I've noticed lately (meaning at least a couple of times in the past 3-4 days) that some areas would not have the correct states. An area that had a door sensor or motion sensor or something would lose that sensor after some hours. Sometimes reloading the area would get the sensor to come back. Other times restarting Home Assistant would be necessary to get the sensor to come back. Maybe the state is all messed up from the upgrade then downgrade. Or something it's something else entirely.

[LeighBicknell]

For what it's worth this is still an issue in 2026.4.1.

I have also come across what could be a related issue with lights not turning off when the sleep state is removed:

#612 (comment)

I haven't raised it as a defect yet, in case i'm just misunderstanding the intended behavior.

[LeighBicknell]

I did some digging in the older 4.3.1 version - the functionality is very different.

In 4.3.1:

• The overhead lights do not come on if occupancy is detected when they are not bound to any states/triggers - good
• The sleep lights do not come on unless the area is occupied before the sleep switch is turned on. Even if the sleep settings do not require occupancy - bad
• In the above scenario, the sleep lights do turn off when sleep switch is turned off - which does not happen in 4.4 (for me) - good
• When occupancy is removed, and sleep is on, but settings dictate occupancy is not required, the sleep lights do turn off - bad

[lnlyssg]

Unfortunately the problem has now returned for me after replacing a Hue bulb that had died - I removed the old bulb in the kitchen, added a new one and now the lights are turning on again. A thought I had after the problem returned - the lights in the kitchen are part of a Zigbee group but the landing light isn't, could this be relevant?

[joneshf]

I doubt it depends on the protocol or whether it uses a feature of said protocol (Zigbee groups). My lights that were affected are Lutron Caséta dimmer switches.