Fixing a 30-Second Lag in My Home Assistant Light Counter

I’ve been chasing a small but stubborn bug in my Home Assistant setup for the past few days: a sensor that counts how many lights are on around the house, which kept lagging 20 to 30 seconds behind reality. The lights themselves updated instantly. My sensor didn’t. Here’s what was actually going on, and how I fixed it for good.

The starting point: too many “lights” that aren’t bulbs

My first attempt at a “lights on” counter was a simple template that looped over every light.* entity in Home Assistant and counted the ones that were on. It sounded simple until I actually looked at what shows up under the light domain in my setup: room groups, Hue zones, PoE switch status LEDs, camera indicator LEDs, and even a roller shutter that someone had registered as a light entity.

To filter all of that out, I started with a growing list of rejectattr filters matching on friendly name and entity_id fragments like “Group”, “Zone”, “PoE”, or “Shutter”. It worked, mostly, until a light called “Bathroom” kept slipping through. Turned out it was a light group, not a single bulb, and no amount of name-based filtering was going to be a durable fix.

Switching to an explicit allowlist

Rather than keep blocklisting every new type of junk entity that showed up, I flipped the approach: I created a Home Assistant group containing only the entities I consider “real” single bulbs, the same pattern I already use for tracking if any of my cameras is offline.

group:
  real_lights_on:
    name: Real Lights ON
    entities:
      - light.bulb_3
      - light.color_temperature_light_1
      - light.dimmable_light_1
      - light.hue_ambiance_spot_1
      - light.zigbee_wallswitch_toilet
      # ...and around 50 more, hand-picked

With that in place, my template sensor became a simple count and list of “on” entities within that group, using Home Assistant’s expand() function. Clean, accurate, and finally free of PoE switches and shutters pretending to be lights.

The real mystery: a 20 to 30 second delay

Once the counting logic was solid, a new problem showed up. Toggling a light in the Hue app updated the light’s own state in Home Assistant instantly, but my counter sensor lagged behind by 20 to 30 seconds before catching up.

I started digging through the logbook history for the sensor and noticed something odd: every single update landed within a fraction of a second of the top of the minute, like clockwork. That is not how push-based updates behave. A light toggled at a random second should trigger an update at that same random second, not always exactly on the minute.

Why Home Assistant fell back to polling

The root cause turned out to be a quirk of how Home Assistant figures out which entities a template depends on. When you write a template that iterates a whole domain (states.light) or expands a large group, Home Assistant tries to statically analyze the template once at load time to build a list of entities to watch for instant push updates.

For dynamic patterns like states.light or expand(), that static analysis isn’t always reliable. When it can’t confidently resolve a dependency list, Home Assistant silently falls back to a safety-net poll, once every 60 seconds, instead of erroring out. That fallback is exactly what produced my minute-aligned update pattern.

The fix: explicit triggers, not automatic detection

I already had a working precedent for this exact problem. My “windows open” sensor uses an explicit dictionary of entity IDs checked one by one with is_state(), and it has always updated instantly, because every dependency is spelled out directly in the template rather than inferred.

For the lights counter, typing out 50-plus explicit checks felt excessive, so I went with a slightly different version of the same idea: an automation with an explicit state trigger on every single-bulb light entity, which forces an instant refresh of the sensors using homeassistant.update_entity.

automation:
  - alias: "Lights - Force Refresh Count Sensors"
    triggers:
      - trigger: state
        entity_id:
          - light.bulb_3
          - light.hue_ambiance_spot_1
          - light.zigbee_wallswitch_toilet
          # ...all ~50 tracked bulbs
    actions:
      - action: homeassistant.update_entity
        target:
          entity_id:
            - sensor.lights_count_on
            - sensor.lights_show_on

The moment any tracked light changes state, the automation fires and forces both sensors to recalculate immediately, completely bypassing Home Assistant’s unreliable automatic dependency detection.

The result

The two sensors, sensor.lights_count_on and sensor.lights_show_on, now update the instant a light changes, matching what I see on my dashboard cards in real time. No more 30-second gap between reality and the sensor.

The lesson

If a Home Assistant template sensor seems to update on a fixed schedule rather than reacting to the actual state changes, check whether it depends on a whole domain or an expand()d group. Those patterns are convenient to write, but Home Assistant can’t always guarantee instant updates for them. An explicit dependency list, whether written directly into the template or enforced through a trigger-based automation, is the reliable fix.