I understood your solution, but what I’m really looking for ist is a more generic way, where I can select an object in the GUI as an action, which let me select the different values for room, shutter and so on like this:
But I don’t know how to define something else. I can create a Blaupause (blueprint) with the needed fields, but I cannot call a blueprint as an action. So how to define an object, which can be defined and called multiple times in an automation with different parameters.
The background for that is to do similar things like Homematic does. And its an idea for migration to HA:
It must be as easy as possible, no YAML knowledge for creation of an automation, IF such kind of action type can be offered at automation creation time.
Yes, youre right concerning the knowledge for the builder of those kinds of templates.
For the User who builds automations from those kinds of templates it should be as easy as possible.
Your first example showed me that you where using
“service: cover.set_cover_position”
This service can be selected when defining actions and has an GUI for that.
And my question is, how to create such a service with my individual parameters (and of course with the needed knowledge), so that an easy enduser can select this service in an automation action?
I learned a lot. Just to make more clear what the goal is:
In old Homematic CCU you can define programs, which are similar to automations in HA. And I’m looking for a migration strategy.
The first part of a Homematic program is like the trigger and condition part of an automation and easy.
The second part is the action list when trigger fires.
And the action list consists of multiple entries, each having
a) select entity b) target value c) timer delay
And now I am looking for a service, which allows the calling of a service lets say “homematic.entity_action”. That call should run asynchronously from the next action.
Building a custom service looks like sophisticated, I have to go deeper into that.
But when that service is build, it could be used by every administrator, who can define a Homematic program today and in an further step it could be possible to write a migration tool, that migrates a Homematic program to a HA automation, producing the YAML-Code for that.