Ensure reliable context.entity_id propagation for state change events following service calls. #1888
Unanswered
Thorsten1982
asked this question in
Core functionality
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
Describe your core improvement
The core improvement required is to ensure that the entity_id of the service-calling entity (e.g., an automation or script) is reliably and consistently preserved in the context.entity_id field of the resulting state_changed event for the target entity (e.g., a light).
This needs to be implemented as a fundamental behavior of the Home Assistant Core's state machine when processing service_call events.
Desired outcome: When automation.presence_manager calls light.turn_on, the light's state change event must contain context.entity_id = 'automation.presence_manager'
Current limitations
Currently, the context.entity_id is often unreliable or missing (null) in the state_changed event, particularly when the service call originates from an automation triggered by a non-user event (like a sensor or a physical switch automation).
Null Issue: When an automation calls a service, the context.entity_id on the target entity's state change often reverts to null, failing to trace the origin of the command.
Forced Workarounds: This lack of reliable propagation forces developers of complex automations and Blueprints (like our Manual Override in Presence Control) to implement cumbersome and brittle workarounds:
Time Correlation: Checking the time difference between the trigger and the light change (as_timestamp(now()) - as_timestamp(light.last_changed)).
Complex Negation Logic: Negating all possible conditions of the automatic action (e.g., NOT (Presence ON AND Lux LOW AND Override OFF)).
Manual Trigger Mapping: Creating dedicated triggers for every possible physical switch, which must then be mapped in the main automation.
These workarounds significantly increase complexity, are prone to timing errors, and degrade Blueprint portability.
Technical benefits
Implementing reliable context propagation will yield several technical benefits:
Simplified Logic: Allows developers to use a single, reliable template condition for distinguishing automatic vs. manual actions:
YAML
Improved Debugging & Tracing: Provides clean and consistent trace data (context_id and context.entity_id) throughout the execution chain, making it easier for users and developers to debug complex interdependencies.
Enhanced Reliability: Eliminates the dependency on time-based logic and external factors, ensuring automations behave consistently across different hardware and system loads.
Better Blueprint Development: Enables the creation of more robust and universal Blueprints that do not need to rely on complex input fields for mapping every possible external trigger.
Additional context
The Manual Override pattern (preventing an automatic turn-off if the user manually activated the light) is a core requirement for almost all presence-based lighting solutions. The current limitation on context.entity_id is the single biggest blocker to creating a clean, universally reliable Blueprint for this pattern. Solving this issue would drastically improve the quality of community-shared solutions.
Beta Was this translation helpful? Give feedback.
All reactions