What version of Spook are you using?
5.0.0
What version of Home Assistant are you using?
Core 2026.7.3 (Frontend 20260624.6)
The problem
The problem
Since the script action inspector was added in 5.0.0 (#1282), scripts created from blueprints that support multiple integrations raise script_unknown_service_references repairs for actions belonging to integrations that are not installed.
My case: the Inovelli LED Settings and Effects Blueprint (kschlichter/Home-Assistant-Inovelli-Effects-and-Colors), which supports Z-Wave JS, ZHA, Zigbee2MQTT, and Matter. I run Zigbee2MQTT only; ZHA is not installed and never has been. All 11 scripts derived from this blueprint are flagged for:
zha.issue_zigbee_cluster_command
zha.set_zigbee_cluster_attribute
The scripts run correctly and the ZHA code is never reached.
Cause
The blueprint iterates a fixed list of device_type/call_type combinations. The first step inside the repeat sequence is a bare condition that halts the iteration when no entities of that type were resolved (line 2497 of blueprints/script/kschlichter/inovelli_led_blueprint.yaml):
- condition: template
value_template: "{{ (repeat.item.entities | count >0) or (repeat.item.effect_entities | count >0) }}"
The ZHA calls appear in later steps of that same sequence. A runtime trace confirms the gate works — the ZHA iterations stop at the condition:
Iteration 11 of 15 with item: {'device_type': 'VZM30SN', 'call_type': 'zha', 'effects': 0, 'entities': []}
Repeat at step 2: Running script sequence
Repeat at step 2: Test condition template: False
Iteration 12 of 15 with item: {'device_type': 'VZM31SN', 'call_type': 'zha', 'effects': 0, 'entities': []}
Repeat at step 2: Test condition template: False
Iteration 13 of 15 with item: {'device_type': 'VZM35SN', 'call_type': 'zha', 'effects': 0, 'entities': []}
Repeat at step 2: Test condition template: False
Only the Zigbee2MQTT iteration proceeds to a service call:
Iteration 8 of 15 with item: {'device_type': 'VZM30SN', 'call_type': 'z2m', 'effects': 'off', 'entities': ['light.kitchen_island']}
Repeat at step 2: Test condition template: True
...
Executing step call service
async_find_services_in_sequence in custom_components/spook/entity_filtering.py has no handling for SCRIPT_ACTION_CHECK_CONDITION. It handles only call-service, choose, if, parallel, and repeat; a condition step falls through the loop body and iteration continues into every subsequent step:
for step in sequence:
if step.get(CONF_ENABLED) is False:
continue
action = cv.determine_script_action(step)
if action == cv.SCRIPT_ACTION_CALL_SERVICE and CONF_SERVICE in step:
called_services.add(step[CONF_SERVICE])
...
At runtime a bare condition: step terminates the sequence when false. Statically, the walker treats everything after it as unconditionally reached. It also recurses into all arms of choose/if for the same reason.
This is not specific to this blueprint or to ZHA. Any blueprint that dispatches across integrations — a normal pattern for portable blueprints — produces these false positives for every integration the user does not have, once per derived script.
Why ignoring is not a good workaround
The issue ID is the entity ID:
self.async_create_issue(issue_id=entity.entity_id, ...)
The action names live only in translation_placeholders, so an ignore is keyed to "unknown actions in this script", not to the specific actions. If a genuinely broken action later appears in the same script, async_get_or_create reuses the ID, updates the text, and preserves dismissed_version — the real problem stays hidden. Ignoring 11 scripts permanently disables action-level detection on all 11.
Anything in the logs? Paste it here!
Nothing relevant — the scripts execute without errors. The trace excerpts above are from a normal run with script debug logging enabled. The only symptom is the repair.
What version of Spook are you using?
5.0.0
What version of Home Assistant are you using?
Core 2026.7.3 (Frontend 20260624.6)
The problem
The problem
Since the script action inspector was added in 5.0.0 (#1282), scripts created from blueprints that support multiple integrations raise
script_unknown_service_referencesrepairs for actions belonging to integrations that are not installed.My case: the Inovelli LED Settings and Effects Blueprint (kschlichter/Home-Assistant-Inovelli-Effects-and-Colors), which supports Z-Wave JS, ZHA, Zigbee2MQTT, and Matter. I run Zigbee2MQTT only; ZHA is not installed and never has been. All 11 scripts derived from this blueprint are flagged for:
zha.issue_zigbee_cluster_commandzha.set_zigbee_cluster_attributeThe scripts run correctly and the ZHA code is never reached.
Cause
The blueprint iterates a fixed list of device_type/call_type combinations. The first step inside the repeat sequence is a bare condition that halts the iteration when no entities of that type were resolved (line 2497 of
blueprints/script/kschlichter/inovelli_led_blueprint.yaml):The ZHA calls appear in later steps of that same sequence. A runtime trace confirms the gate works — the ZHA iterations stop at the condition:
Only the Zigbee2MQTT iteration proceeds to a service call:
async_find_services_in_sequenceincustom_components/spook/entity_filtering.pyhas no handling forSCRIPT_ACTION_CHECK_CONDITION. It handles only call-service,choose,if,parallel, andrepeat; a condition step falls through the loop body and iteration continues into every subsequent step:At runtime a bare
condition:step terminates the sequence when false. Statically, the walker treats everything after it as unconditionally reached. It also recurses into all arms ofchoose/iffor the same reason.This is not specific to this blueprint or to ZHA. Any blueprint that dispatches across integrations — a normal pattern for portable blueprints — produces these false positives for every integration the user does not have, once per derived script.
Why ignoring is not a good workaround
The issue ID is the entity ID:
The action names live only in
translation_placeholders, so an ignore is keyed to "unknown actions in this script", not to the specific actions. If a genuinely broken action later appears in the same script,async_get_or_createreuses the ID, updates the text, and preservesdismissed_version— the real problem stays hidden. Ignoring 11 scripts permanently disables action-level detection on all 11.Anything in the logs? Paste it here!