Where can I find that?
edit: Blueprints - Google Docs
1 Like
Ultimately I would luv what the original poster proposed.
I have a much simpler use case.
I must instantiate a Blueprint and a Timer for each instance of the Blueprint, and then using the input select the timer.
In this case the timer is really just a helper instance entity used only as part of the blueprint instance.
I am new to Home Assistant … is there a way to dynamically create entities like a timer ?
3 Likes
In thinking about blueprints I want to build I quickly came to realize that this is a necessary feature for maintainable and easy to use blueprints. I hope we see something like this soon!
and here I am 5 days later, frustrated that I can’t make anything more than trivial automations using blueprints due to the limitations. The concept of blueprints is great but the current version is just too limited to do much beyond simple things.
If I’m understanding this correctly, the Lovelace part would fit my current needs nicely. I have a layout card with a button on the left and a schedule on the right, so the wife can change schedules for her lights from the mobile app. I have gone through a few iterations and every time I get a new layout that I like, I have to copy it several times. It would be nice to define the YAML once and place it on my dashboard several times, only selecting the entity for each instance.
1 Like
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.
1 Like
@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.
1 Like
Sounds good to me. I am a software developer, but python is not exactly my first language. I can hack my way through it in a pinch.
Did anyone tried a template based packages?
Like, create a whatever Package you need - where everything required would be theoretically localized, but make it a cookiecutter template?
Hard to update, not real class/instance relation, etc., but still…
Came here looking for helpers to solve a problem.
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.
4 Likes
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.
3 Likes
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 
2 Likes
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.
2 Likes
You can use MQTT discovery to create entities in blueprints as well. I do it in some of mine.
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.
Do you have an example of this somewhere?
1 Like
Am I hearing right? That bluebrints are about to get a revamp and not just to include my original suggestion but to include complete dashboards…?
I’ve seen work on templates as blueprints, don’t know of anything else. (personally)