Description
The current UI-based Template Sensor Helper only provides a single “State template” field. This prevents a systematic debugging workflow and creates a major technical bottleneck for complex logic. Since Jinja2 variables are local to their block, they are lost once the state is rendered.
The Core Problem: Impossible to debug without system fragmentation
In the current UI implementation, it is impossible to “re-build” or duplicate logic within the same entity because there is no attribute field. This leaves users with only two bad options:
- Entity Fragmentation: To monitor “internal” variables (like
is_critical_discharge), I am forced to create a separate template sensor for every single variable I want to debug. - Forced Restarts: While UI Helpers can be created on the fly, managing complex debug-sensors or cleaning up “helper-clutter” often forces a system restart to maintain a clean configuration. This destroys the seamless “UI-first” experience.
Example of the “Re-build” (Nachbau) wall: If I define my state logic using descriptive variables for debugging:
`Code-Snippet{% set is_critical_discharge = soc_reached_bottom and timeout_reached and batt_pwr < -80 %}
{% set is_illegal_active_state = is_error and batt_pwr < -1 %}
{% if is_illegal_active_state or is_critical_discharge %}
error_critical
{% else %}
standby
{% endif %}`
I have no way to inspect the value of is_critical_discharge in the Developer Tools to verify why the sensor triggered, unless I leave the UI flow, create redundant entities, and potentially restart the core.
Proposed Solution
- Dedicated Attribute Template Field: Add an optional YAML-based attribute field to the UI Helper, identical to the “State attributes” field in Developer Tools > States.
- Variable Persistence: Ideally, allow a shared logic block (like
variables:in trigger-templates) so that a calculation can be performed once and used in both the state and multiple attributes.
Benefits
- Zero-Restart Debugging: Users can monitor the “internal life” of a complex sensor via attributes in the Developer Tools without cluttering the system with dummy entities.
- Structural Integrity: Eliminates the need to maintain the same complex calculation logic across multiple separate sensors.
- Parity: Brings the UI Helper to functional parity with the YAML-based template integration, supporting a modern, stable, and UI-driven workflow.