Extend Blueprints to include Helpers, multiple Automations/Scripts and Lovelace

Solutions often consist of multiple parts to solve a problem. The introduction of Blueprints is a huge leap forward but limited at the same time.

Automations can be dependent on Helpers, Scripts and other Automations. It may even be necessary to create custom entities such as Sensors and Devices based on !inputs to utilise the platforms true capabilities.

I’m seeing the Blueprint as more of a class definition that can describe attributes and methods locally. Each use_blueprint: is creating an instance of that class and the elements within are unique/local to it.

This would make importing a Blueprint much more straightforward. Blueprint providers/developers would not have to issue multiple parts to their solution, nor describe how consumers would need to create/manage custom entities.

Adding Lovelace cards would allow the Blueprint to provide a default UI to work from that could be used by reference or duplicated into a View for modification.

Even if not shared, having a more complete/substantial Blueprint will allow for more efficient local reusability.

Pseudo Blueprint - don’t judge my YAML or it’s validity. It’s the concept I’m highlighting here.

blueprint:
  name: Blueprint as a Solution
  domain: automation
  input:
    motion_entity:
      name: Motion Sensor
      selector:
        entity:
          domain: binary_sensor
          device_class: motion

  helpers:
    input_boolean:
      name: helper_name
      initial: on
      icon: mdi:iconname
    input_select:
      name: helper_state
      options:
        - Option A
        - Option B
        - Option C
        - Option D
      initial: Option A
      icon: mdi:iconname

  sensors:
    basedoninput:
      friendly_name: 'Based On Input'
      value_template: >
        {{ something(using(the(!input motion_entity))) }}
      icon_template: mdi:iconname

  scripts:
    - first_script:
        alias: 'Turn Off'
        sequence:
        - condition: state
          attribute: current
          entity_id: !local helper_name
          state: 'on'
        - service: light.turn_off
          entity_id: !input light_target
    - second_script:
        alias: 'Turn On'
        sequence:
        - condition: state
          attribute: current
          entity_id: !local helper_name
          state: 'off'
        - service: light.turn_on
          entity_id: !input light_target

  automations:
    - first_automation:
        trigger:
          platform: state
          entity_id: !input motion_entity
          from: "off"
          to: "on"
        action:
          - service: light.turn_on
            target: !input light_target
          - wait_for_trigger:
              platform: state
              entity_id: !input motion_entity
              from: "on"
              to: "off"
          - delay: !input no_motion_wait
          - service: light.turn_off
            target: !input light_target
        mode: single

    - second_automation:
        trigger:
          platform: state
          entity_id: !input motion_entity
          from: "on"
          to: "off"
        action:
          - service: light.turn_off
            target: !input light_target
          - wait_for_trigger:
              platform: state
              entity_id: !input motion_entity
              from: "off"
              to: "on"
          - delay: !input no_motion_wait
          - service: light.turn_on
            target: !input light_target
        mode: single

  cards:
  - type: grid
    cards:
      - type: button
        tap_action:
          action: call-service
          service: !local script.first_script
        entity: !input light_target
      - type: button
        tap_action:
          action: call-service
          service: !local script.second_script
        entity: !input light_target

The one unspoken word in your description is “packages”.

A solution that relies on a combination of resources, such as various integrations, automations, scripts, etc, can be distributed as a package. However, the current distribution method is ‘copy-paste’ with manual customization (in YAML).

Your Feature Request is effectively asking for a ‘blueprint package’, namely a means to easily distribute and configure a package. That would be a significant enhancement because it would allow authors to easily distribute complete solutions (consisting of more than a single automation).

10 Likes

Yes and no. A Package still ends up as a number of standalone entities within your HA instance.

I’m proposing an encapsulated approach. If I were to delete one thing that was installed by a Package, it could potentially break lots of stuff.

By encapsulating the Blueprint in a single entity. You protect all the parts and provide a consistent way to update/maintain.

I’ve not used Packages, but I assume you just end up with raw entities. With the approach I am proposing you would access using blueprint.name.entity.

A subtle but important difference.

3 Likes

Except it wouldn’t as a ‘blueprint package’.

The current implementation of a blueprint automation stores the ‘reference’ automation within the blueprint. All automations instantiated by the blueprint (the ‘clones’) simply contain input data; internally they all refer back to the blueprint’s ‘reference’ automation. The same principle would apply to a ‘blueprint package’.

Anyway, if you look at balloob’s roadmap for blueprints, we are very far away from blueprint packages.

2 Likes

I’ll take a look

The big difference with using blueprints to deploy something that looks like packages is the ability for the user to customize the result at deploy time. Packages are a fixed quantity, it’d be great if we could mix the benefits of both solutions together to allow the user some control over exactly what’s happening when the solution is instantiated.

2 Likes

Exactly… Right now I’m just finalising my first blueprint. But I have to create three helpers for each use of it. Those helpers should be embedded in the Blueprint, the same if there were script dependencies.

I think it would also make sense to hide them from the main views as they will likely not work on their own and will break the automation if they were deleted by accident.

3 Likes

I developed the HASwitchPlate project around the use of packages and while they work great, they’re really hard for the end user to digest and obviously require the user to understand YAML. Any modifications require the user to dig deep into an increasingly hard-to-understand collection of automations to figure out where to make a change. Blueprints could radically simplify this approach with the ability to add multiple automations along with associated “helper” components.

Your request as outlined in the OP is spot-on for what I’m looking for and it would be a game changer for HASP users. Packages don’t solve the problem in a way your suggestion would.

3 Likes

To expand on that a bit - currently, when a user deploys a HASP with the deployment script they get a set of 140 automations created for them which, along with a bunch of helper entities, rolls out a fully-configured device. The base package, without examples, totals over 3200 lines of YAML across 13 files.

What would be far better for my users would be something like a base package which includes some core functionality that users don’t really need to customize. Then, allow the user to select from a list of blueprints that allow the user to define functionality on a per-screen or per-button basis.

So, for example, on page 1 there is a set of 4 buttons. Currently, there is a set of automations which put labels on those buttons at device connect or Home Assistant start, some which handle button state, some which push out font and color information, and one which picks up a specific button press and triggers a scene in response. Of those, the only thing the user really would care about is the label being applied and the scene being triggered when the user presses the button.

With a package-based approach to blueprints, I could hide all that other complexity in the blueprint YAML. The user would only have to select the button, enter the text, and decide which scene is being triggered as a result. If I have a repository of blueprints to choose from, I could make a bunch that perform various functions and the user could select them from a list.

So, page 1 top button selects a scene. Button 2 shows me the outside temperature. Button 3 locks the front door, etc. Blueprints are so close to offering me a way to give HASP users a menu-driven UI to customize their device.

The idea put forward in the OP would take it to that place.

6 Likes

Found this because I want the same thing.

My use case is to have a blueprint that has automations to send a notification with actions and handle all the callbacks for those actions.

One doesn’t make sense without the other so it would be great if I didn’t have to define two or three extra automations independently each time I used the blueprint.

2 Likes

The idea of including helpers is also interesting. I implemented my own thermostat for my IR-controllable heat pump with automations, temperature sensors, and a bunch of helper entities.

Then I had to duplicate the entire thing for my downstairs. The ability to blueprint it to avoid this duplication would be fantastic!

3 Likes

I’ll note an addendum to my post above - I was able to make the concept work using the existing blueprint system. Getting multiple automations bundled into a single blueprint was a matter of triggering on all of the combined ways one could trigger any of the set of automations I previously used, then utilizing choose to select the desired sequence of actions depending on the trigger.

Helpers are more difficult. In my case I can rely on MQTT being available, so I make use of publishing persistent MQTT discovery messages and then leveraging the created entity as a helper. It’s not a great solution but it can work.

Still, having the ability to define helper objects in the blueprint would be a huge benefit.

1 Like

I thought about exactly this solution, but stopped short of actually implementing it. It seems like more of a hack to me and could lead to fairly unmaintanable automations.

I like the way you’re thinking though :slight_smile:

1 Like

You aren’t kidding about that! The “core” blueprint for my project replaced dozens of automations, but as a result it now looks like this.

Thankfully, the new automation debugging tools have made troubleshooting these things a fair bit easier.

Yeah, I have no time for that :slight_smile:

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