I created a Home Assistant custom integration that exposes services for creating persistent helper entities programmatically — from automations, scripts or blueprints — without needing to use the UI or restart HA.
Hope this helps anyone else.
Feedback is very much appreciated!
Kudos on the integration. Would love to see this expanded to allow for dynamic and temporary (short-lived) helpers. An automation system I used many years ago did this - the system would auto-generate temporary helpers in the automation itself when you told it to.
Example…
In the automation, you command it to ‘create Temp Helper → Timer’ (or whatever helper type you need). At automation runtime, the system creates the Helper (generates a random name with timestamp) and assigns it a variable within the automation. This variable is used wherever you need inside the automation so the system recognizes the variable is the temp-helper. When the automation is finished, the system auto-deletes the Helper.
Benefit of temporary helpers…
From the user’s perspective, it greatly reduces the current Home Assistant pattern of creating and maintaining a large collection of permanent helpers (especially Timers, Counts, etc)
Thank you for the feedback!
I understand your idea and how my integration could help, however I fear that this would over-complicate things as helper are actually not designed to be used as temporary variables.
Have you heard about this integration?
I used this extension since a while and it is working really good, especially if you want to counters and timers.
Though, I will think about your suggestion.
Best Regards!
After some deep diving, Helper Manager integration is the best basis for the soliton. Saver is targeted to solve persistence but not lifecycle management - and Saver cannot be used in Jinja templates; a valuable/important need.
Helper Manager is already very close to solving a gap in Home Assistant variable design: the lack of persistent, and dynamically created variables.
Native Home Assistant variables provide these capabilities:
{{ my_variable }}
Native variables have significant limitations:
creating real Home Assistant Helpers from native HA variables, to make them persist state and be managed
The ideal workflow would combine native variables with dynamically managed Helpers:
Automation starts
|
|
Create temporary persistent variable
|
|
Automation receives entity reference
|
|
Use variable normally in Jinja/templates
|
|
Automation completes
|
|
Temporary variable is automatically deleted
Example concept:
variables:
alert_id: "{{ context.id }}"
action:
- helper_manager.create:
type: input_text
name: "alert_{{ alert_id }}"
temporary: true
- ... automation logic ...
- helper_manager.delete:
entity_id: "{{ created_helper }}"
The automation would receive the generated entity ID and use it like any other variable:
{{ states(created_helper) }}
Allow helpers to be created with a temporary flag:
temporary: true
The integration would track:
When the automation/script exits:
Helper Manager would automatically remove temporary helpers.
This would provide garbage collection similar to programming languages.
Because the helper exists as a real HA entity:
Example:
HA restart
|
Find unfinished temporary helpers
|
Restore automation state
|
Continue execution or notify user
Today, advanced Home Assistant users often create many permanent Helpers only because they need persistent state:
These helpers remain forever even though they only support a single automation.
A temporary persistent variable system would provide:
Helper Manager is already solving the hardest technical problem: dynamic creation of persistent Home Assistant entities .
The next step would be adding a lifecycle layer that turns those dynamic Helpers into temporary persistent variables :
Native Variables
+
Dynamic Helper Creation
+
Automation Lifecycle Tracking
+
Automatic Cleanup
This would fill a gap in Home Assistant’s current automation engine.