[Bug]: Light turns on when area registry updates while area is bright

[tbrasser]

System Health details

System Information

version	core-2025.12.0.dev202510310239
installation_type	Home Assistant OS
dev	true
hassio	true
docker	true
container_arch	amd64
user	root
virtualenv	false
python_version	3.13.9
os_name	Linux
os_version	6.12.29-haos
arch	x86_64
timezone	Europe/Amsterdam
config_dir	/config

Home Assistant Community Store

GitHub API	ok
GitHub Content	ok
GitHub Web	ok
HACS Data	ok
GitHub API Calls Remaining	4987
Installed Version	2.0.5
Stage	running
Available Repositories	2371
Downloaded Repositories	134

Solcast Solar

can_reach_server	ok

Home Assistant Cloud

logged_in	true
subscription_expiration	November 14, 2025 at 01:00
relayer_connected	true
relayer_region	eu-central-1
remote_enabled	false
remote_connected	false
alexa_enabled	false
google_enabled	false
cloud_ice_servers_enabled	true
remote_server	eu-central-1-11.ui.nabu.casa
certificate_status	ready
instance_id	e88a2afa97a14d5bbd05e41009ff7d10
can_reach_cert_server	ok
can_reach_cloud_auth	ok
can_reach_cloud	ok

Home Assistant Supervisor

host_os	Home Assistant OS 15.3.dev20250519
update_channel	dev
supervisor_version	supervisor-2025.10.2.dev2901
agent_version	1.7.2
docker_version	28.0.4
disk_total	468.7 GB
disk_used	346.4 GB
nameservers	2606:4700:4700::1111, 2001:4860:4860::8888, 1.1.1.1
healthy	true
supported	true
host_connectivity	true
supervisor_connectivity	true
ntp_synchronized	true
virtualization
board	generic-x86-64
supervisor_api	ok
version_api	ok
installed_addons	Matter Server (8.1.1), Advanced SSH & Web Terminal (21.0.4), Studio Code Server (5.19.3), Zigbee2MQTT (2.6.2-1), Mosquitto broker (6.5.2), SQLite Web (4.4.1), openWakeWord (1.10.0), Asterisk (5.3.2), Frigate (Full Access) Beta (0.16.2), Whisper (2.6.0), snowboy (1.2.1), Actual Budget Stable (25.10.0-alpine), MariaDB (2.7.2), Grocy (0.24.0), OpenThread Border Router (2.15.0), PS5 MQTT (1.4.0), UniFi Network Application (4.2.0), Music Assistant (BETA) (2.7.0b8), porcupine1 (1.2.0), Piper (1.6.4), vosk (1.6.1), Z-Wave JS (0.27.0), Cloudflared (6.0.3), AdGuard Home (6.0.0), EMHASS (v0.13.5), Speech-to-Phrase (1.4.1), Ollama (0.5.12), Orb (1.3.6), Music Assistant DEV SERVER (1.4.1), Ghostfolio (1.108.0), Postgres 17 (17.4-13), ESPHome Device Builder (dev) (2025.11.0-dev20251031), EMHASS-test (test)

Dashboards

dashboards	6
resources	57
views	35
mode	yaml

Network Configuration

adapters	lo (disabled), enp2s0 (enabled, default, auto), docker0 (disabled), hassio (disabled), vethe571635 (disabled), veth0214e65 (disabled), veth6ce5dd7 (disabled), veth6fb4d45 (disabled), vetha7fc5b3 (disabled), vethc473697 (disabled), veth72a6124 (disabled), vethf032759 (disabled), veth310a3af (disabled), veth81ce5a9 (disabled), veth0f20f86 (disabled), veth3cc5dc0 (disabled), vethdc86535 (disabled), vethf907379 (disabled), veth911e2af (disabled), vethe018a12 (disabled), vethb924daf (disabled), veth7b4fa42 (disabled), vethf7aed79 (disabled), vethe3c79bc (disabled)
ipv4_addresses	lo (127.0.0.1/8), enp2s0 (10.9.8.30/24), docker0 (172.30.232.1/23), hassio (172.30.32.1/23), vethe571635 (), veth0214e65 (), veth6ce5dd7 (), veth6fb4d45 (), vetha7fc5b3 (), vethc473697 (), veth72a6124 (), vethf032759 (), veth310a3af (), veth81ce5a9 (), veth0f20f86 (), veth3cc5dc0 (), vethdc86535 (), vethf907379 (), veth911e2af (), vethe018a12 (), vethb924daf (), veth7b4fa42 (), vethf7aed79 (), vethe3c79bc ()
ipv6_addresses	lo (::1/128), enp2s0 (fe80::8e0b:d3e9:4cf8:fc97/64), docker0 (fe80::acf4:92ff:fe94:e16c/64), hassio (fe80::f0dd:4eff:fe6a:d7da/64), vethe571635 (fe80::fce8:dcff:fef4:bedb/64), veth0214e65 (fe80::b865:afff:fea0:ba1c/64), veth6ce5dd7 (fe80::b4dd:1dff:fe2b:fb4/64), veth6fb4d45 (fe80::64c6:28ff:febe:109f/64), vetha7fc5b3 (fe80::74d7:8bff:fef7:b4b6/64), vethc473697 (fe80::e407:24ff:feae:6dd4/64), veth72a6124 (fe80::5c6d:52ff:fe23:bbdb/64), vethf032759 (fe80::c8b9:8aff:fe48:d62e/64), veth310a3af (fe80::d8b0:c5ff:fea3:18a1/64), veth81ce5a9 (fe80::6439:99ff:fec4:b4f4/64), veth0f20f86 (fe80::9c29:cff:fe17:741/64), veth3cc5dc0 (fe80::eccb:a3ff:fe20:b908/64), vethdc86535 (fe80::64e5:a8ff:fe1c:ae3c/64), vethf907379 (fe80::e833:9dff:fe8c:a452/64), veth911e2af (fe80::b0cc:afff:fe9d:3714/64), vethe018a12 (fe80::f868:f3ff:feed:e716/64), vethb924daf (fe80::34a0:3fff:fefd:dd19/64), veth7b4fa42 (fe80::ac3d:99ff:fede:7c68/64), vethf7aed79 (fe80::684f:efff:fe2d:fedb/64), vethe3c79bc (fe80::2cf1:49ff:fece:fa71/64)
announce_addresses	10.9.8.30, fe80::8e0b:d3e9:4cf8:fc97

Recorder

oldest_recorder_run	September 30, 2025 at 05:43
current_recorder_run	October 31, 2025 at 08:27
estimated_db_size	12804.18 MiB
database_engine	sqlite
database_version	3.49.2

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

Lights were off due to area being "bright" (template binary sensor), when anything causes device/entity to be added to area, the light turns on (and remains on)

Expected behaviour:
If not staying off, then at least turn off again quickly.

Reproduction steps

1. use area bright/dark binary sensor
2. add entity to area when area is bright
3. lights turn on and stay on

Debug logs

Adding soon

Diagnostics dump

No response

[jseidl]

Thanks for reporting, I need to investigate. Possibly related to the reloads

[hugoovf]

Hi! I wanted to follow up on this issue as I’m experiencing the same behavior. The lights remain on even when the area is bright enough and should be turning off based on the illuminance threshold.
Has there been any progress on identifying the cause? I’m happy to provide additional logs or configuration details if that would help with troubleshooting.
Thanks for your work on this integration!

[jseidl]

I still haven't had the time to look up on this. It is possible that #589 might fix that as it addresses restoring area states on reload.

Is the issue consistent, meaning every time you update the area registry, this happens? Just so I know how to reproduce for testing.

[DonkeyofDoom]

Don't know if it's fine to answer here, I have the same problem but didn't manage yet to get logs and write a full proper report. 2 of my areas turn on the lights when there's presence registered although there's also light above the set threshold (far above, got a brightness sensor that's checked to not be affected by the operated lights in the area). Reloading them mostly fixed it, but recently I even setup an automation to switch off light control in magic areas when there's light detected in the area so it doesn't trigger. Had this solved some months ago when, as I guess, the problem was that an LED linked to a TV switched on when the TV switched on and since it was in a light group with several other lights in this room, magic areas switched the whole group on even if there was light and no movement when this happened. What's going on now, I have no idea. I can have a closer look, especially if I know what to look for, if this problem is still unsolved for others and if it fits here.

[jseidl]

Hi, a few questions:

1. Does this only happens on registry updates? (just to make sure you're commenting on the right bug)
2. There are a few group types that will turn on all the other lights when one of the lights turn on (this is not magic areas) like zigbee groups. I'm not sure if Home Assistant's regular groups do the same. Are you using those?

[DonkeyofDoom]

Hi, thanks for the reply!

1. It happens when a parameter for the area that is relevant for lighting changes, like a bright area switching from empty to occupied or when presence is registered. It also happens when I reload the area in the integration menu after this change happened, so if a bright area lights up when entering it and I reload it, this doesn't make it go dark (in the past, this sometimes helped with problems as I use the calculated brightness sensor of a neighbouring area for this area and sometimes it seemed to hang or not being available for the other area for some reason and the area took the proper state after reloading the area with the physical brightness sensor and afterwards the area with the light which takes the brightness value from the other). See screenshot, in this case there's only one light in this area (no group or other entities as potential mess ups) and a threshold of 30lx with 50% hysteresis set.

2. Yes, this might have been the reason for a former problem I noticed and fortunately I figured it out and tried to tackle it by adjusting the light group set up in helpers in HA. So I guess that was part of my problem in the past, thanks as well, learned some about the internal mechanism by this.

If it's unrelated, sorry in advance, I'm struggling a little with proper structuring until I completely understood the problem or solved it, but by then, it's some Captain Hindsight level usefulness 😅