It turns out the “decluttering-card” available in HACS does exactly what I wanted. Yea! Custom cards for the win.
That said, I do still see the benefit in what was described in this thread. In a previous iteration, I created a blueprint (well, I modified someone else’s blueprint) to create schedules for multiple devices, but I had to separately create datetime helpers and boolean helpers for each instance of the blueprint. It would have been great if they all could have been defined in one place, including the card to show them in Lovelace.
@SteveDinn not sure if you are a software engineer, but the concept I am proposing is based on object oriented principles. Localising helpers could see them completely hidden (private) or exposed to allow the user of the blueprint to change them based on the helper type.
Each instance of the blueprint would hold its own copy of those helpers and therefore how they are set in one, would not impact how they are set in another.
I maintain a few blueprints and often I want to store state information across separate runs of the automation. E.g in this one I want to know if the last trigger turned something off or on: Toggle between a scene and the pre-scene state. In another automation I would like a zigbee ‘button_release’ action to stop a ‘button long-press’ ‘repeat_while’ loop in the previous run of the automation.
For all of these I want access to some global variable/state. Creating a hidden ‘input_boolean’ within the blueprint would be quite an elegant way of doing this.
The good news is that this is in the current roadmap for Blueprints. (see V3)
The bad news is that it probably has since the beginning of the roadmap and nothing has been done.
We likely need a community member to step up and figure this out to get it done…
Since it’s on the roadmap, there a good chance it could be approved if it were developed…
Anyone have the chops to pull something like that off.? Not me, that’s for sure.
I’ve been digging the forms for some time until I found this issue (and I’m glad I have not duplicated it ).
I personally have some blueprints that use some input helpers, and I’m quite tired of having to create them manually one by one every time I want to activate the automation for a new light.
Now I see it’s still not possible, although I hope we see these features soon enough
Was just searching to see if it was possible to utilize helpers or any other sort of persistent variable that was localized to a blueprint and stumbled upon this thread. This would make sharing Blueprints with less technical users so much easier. It would also de-clutter “traditional” helpers by keeping BP specific helpers out of the general helpers UI, and insuring that they were removed along with a BP if it is removed. All in all, it would be a huge step forward in my opinion.
I did create my own component called dynamic.
It can create various Input_XXX types and timers.
In the hass boot event for my blueprint
… I create my helper components. (Or reregister previously created components);It use the blueprint instance ID in creating the ids for the helper entities.
The blueprint instance ID is available via the “this” trigger variable so you can setup triggers for these dynamically created entities even before they are created. Which is needed for setting up automation triggers. NOTE trigger variables have limited template functionality You can’t query to find entities to setup triggers. You need to know (or in my case derive) the entity ID’s use to trigger the automation.
That is the better way for persistent storage that are not needed on the UI.
But there are times I use an input_XXX and/or a timer that provide user interaction for the blueprrnt component. They are instantiated with the blueprint.
I would luv it if there was a standard way to create any entity that you could statically create in the configuration.yaml file. I.e. a service, that includes the ID of the entity to be created and the same arguments you would put in your config file to statically create the entity. Knowing the ID before creating or registering the entity is what enables the entity to be used as an automation trigger. Using the blueprint instance ID, which is available as a trigger_variable via “this”, and templates to generate the corresponding helper IDs, allows you to create the IDs for these helper entities.
You would then setup your automation triggers using these IDs and create/register the helpers using this new service in the HASS startup event for the blueprint instance.
I do manually group these helper entities on my dashboards. I have not thought much about automating this … it’s pretty simple with existing tools.
Linking blueprint instances with the corresponding helper entity IDs is what is the most complicated part of the process.
I would luv to retire my limited “Dynamic” component.
).
