Environment
- Automation Inspector add-on 1.1.2
- Home Assistant Core 2026.7.4 (HAOS 18.1)
Summary
Automations created from a blueprint that uses Jinja namespace() variables get flagged with a missing entity that is actually a namespace attribute, not an entity.
Repro
Any automation instantiating the popular Blackshome sensor-light.yaml blueprint. The blueprint builds its service call data like this:
{% set light = namespace(data={}) %}
{% if 'use_transition' in include_light_control %}
{% set light.data = dict(light.data, **{ 'transition': light_transition_on }) %}
{% endif %}
...
{{ light.data }}The inspector picks up light.data from the rendered config and reports it as a missing light. domain entity. In my setup every automation based on this blueprint (5 of them) gets light.data [missing], which puts them all in the "with issues" bucket and drowns out real findings.
Expected
Tokens that originate from Jinja expressions should not be treated as entity references. A namespace() attribute like light.data is indistinguishable from an entity id by regex alone, so the parser probably needs to skip candidates found inside {% set ... %}/{{ ... }} blocks when the identifier matches a variable assigned in the same template, similar to what was done for trigger.entity_id/repeat.item in #17.
Related observation
Service names listed in a repeat.for_each list (e.g. looping over notify.mobile_app_a / notify.mobile_app_b and calling action: "{{ repeat.item }}") are also reported as missing entities in 1.1.2. Looks adjacent to the closed #1/#17. I worked around it by rewriting to explicit service calls, but mentioning it since it is the same class of false positive.
Happy to test a fix build.
Environment
Summary
Automations created from a blueprint that uses Jinja
namespace()variables get flagged with a missing entity that is actually a namespace attribute, not an entity.Repro
Any automation instantiating the popular Blackshome
sensor-light.yamlblueprint. The blueprint builds its service call data like this:The inspector picks up
light.datafrom the rendered config and reports it as a missinglight.domain entity. In my setup every automation based on this blueprint (5 of them) getslight.data [missing], which puts them all in the "with issues" bucket and drowns out real findings.Expected
Tokens that originate from Jinja expressions should not be treated as entity references. A
namespace()attribute likelight.datais indistinguishable from an entity id by regex alone, so the parser probably needs to skip candidates found inside{% set ... %}/{{ ... }}blocks when the identifier matches a variable assigned in the same template, similar to what was done fortrigger.entity_id/repeat.itemin #17.Related observation
Service names listed in a
repeat.for_eachlist (e.g. looping overnotify.mobile_app_a/notify.mobile_app_band callingaction: "{{ repeat.item }}") are also reported as missing entities in 1.1.2. Looks adjacent to the closed #1/#17. I worked around it by rewriting to explicit service calls, but mentioning it since it is the same class of false positive.Happy to test a fix build.