What is the best way (or any way) to run(trigger) multiple automations?

Configuration
7

Triggering automations manually (through the UI or via a service call) is generally bad practice. It can be helpful during troubleshooting but that’s really the only reason you’d want to do this. It will skip the triggers and also the conditions (unless you explicitly tell it not to via the skip_conditions attribute) which can cause errors depending on how your automation is set up. But the primary reason not to do this is because that is the entire reason scripts exist. The action portion of an automation is essentially a script.

What you should do instead is move all the actions out of your shutter automations and put them into scripts. Then you can call those scripts from your automations. And you can also call those scripts from buttons in the UI.

And you can probably set up your script so that it accepts variables so you only need a single script to operate any one of your 8 shutters. And then you can have a single automation call the single script 8 times, each time passing along a different entity for it to control.

2 Likes
8

I agree, but he is running loops. The blinds are non-responsive so there is an underlying issue.

9

Whether or not the underlying issue is present or fixed, the way to do this is still to put the actions into a script. There’s no issue with running the while loop in a script and the script can be set to run in parallel mode so it can be called repeatedly while it is already running.

1 Like
10

Yes, his scheduled automations can call scripts as well. Feel free to take point on this one.

I don’t think the automation trigger is going to be used enough to do damage.

I’d also question why calling automations from a script is even an option? As you said, it is “generally bad practice.” I do believe there is a more direct solution…

11

Interesting approach. I can try it. Thanks.

However I would like to know why I posted does not work regardless if it is “bad practice”.

12

The underlying issue is that in the official tuya integration the Bluetooth gateway is not supported but I can get the blinds to work. Gateway and the blinds are 10’ from each other so it is not a signal strength issue. Tuya just sucks basically. Bluetooth is not supported in Tuya local either.

image
image2278×746 42.8 KB

13

Oh, I get it after looking into Tuya. I think @mekaneck is making a good suggestion. Switching the blind action to a conditional script to control the open/close of the blinds is more streamlined. As he mention , you can then use that script in your automaton/s.

1 Like
14

@mekaneck @LiQuid_cOOled Finally made a little time to work on HA :grinning: So I made and tested a script to open a shutter as first step. I now what to do what you suggest may be possible and pass an entity name (I think in my case that will be a device name) to the script. So, as you suggest, I can have one script and call it 8 times. The script uses a while loop because the was the Tuya gateway and Bluetooth motor operate if you send a command it simple does not always perform the action. Why that is, is another issue entirely and I work around this by simply repeating the request until it has done it. So… In the script you see that I have a device which I want to be a variable (field? I am assuming you mean field as I cannot find references to “variables”). I request the condition of the device (state?) and then I perform an action on the device (service?). Using the UI editor I was able to create a field for the device but have no idea how to reference that field (device) and test its condition. Can you help me out with this? Your assistance is most appreciated.

image
image1092×984 29.2 KB

alias: Shutter Close TSD
sequence:

  • repeat:
    sequence:
    - device_id: 33987e567e2a38a29983b732ac887b87
    domain: cover
    entity_id: 22f87aebedaae5bed71f6a4d3524628f
    type: set_position
    position: 0
    - delay:
    hours: 0
    minutes: 0
    seconds: 1
    milliseconds: 0
    while:
    - condition: device
    device_id: 33987e567e2a38a29983b732ac887b87
    domain: cover
    entity_id: 22f87aebedaae5bed71f6a4d3524628f
    type: is_position
    above: 1
    below: 100
    mode: parallel
    max: 10

Then here is the beginning of my script with field:

image
image1340×994 38.2 KB

15

Here’s the relevant part of the documentation you’ll want to read: Scripts - Home Assistant

The “fields” aren’t particularly well-documented; you only need them if you want to call your script from the UI (either from a card on your dashboard that allows it, or from developer tools > services).

In a script, you’ll need to use templates to handle variables. But you don’t need to do anything special; you essentially just assume they exist. When you call the script (from an automation, another script, or from the UI), that is when you have to do something special in order to pass those variables along.

The docs I linked should show exactly what you need to do in order to call a script and pass variables. In your case you’ll want to use the script.turn_on service so that your automation doesn’t wait for it to complete before it moves on. The example using the script.turn_on service shows fields but those can be omitted if you don’t intend to run it from the UI. And you can see that the script example a little above that uses {{ title }} and {{ message }} to reference those passed variables.

If you still need more help just ask. But also if you post code please format it properly. Three backticks (```) before and after the block of code.

1 Like
16

Thank you for your reply @mekaneck . I did read the documentation you linked prior to posting but could not make the leap from what was written to my situation. probably because I don’t know yaml.
Maybe I am thinking about fields wrong and you can set me straight.
When I think of a variable (field) I am thinking my script is like a function that I am passing a parameter to. In my case I want to pass a device name, the name of my shutter motor so I can then ask the position of that motor (is it correct in to call that a state in HA nomenclature?) and then set the position of that motor if it is not the position that I want.

Where and how is the connection of a template to a script? How do I reference a template in the script UI?

This sentence: “In a script, you’ll need to use templates to handle variables.” I am unable to understand how to do this or what the template needs to contain.

The examples show yaml and I have been earlier admonished for not using the UI editor so I just cannot make the leap from that yaml to the UI editor, I don’t know yaml. Meaing looking at yaml and somehow knowing what the looks like in the UI editor is not something I am able to do with my current level of understanding. My day job is C# coding and Typescript using sophisticated stacks like Remix so the yaml is completely foreign to me. Can I do want I want in the UI editor or do I need to make a side trip and learn yaml first? The interaction between the different parts of HA and the communication scheme is really not like anything I have encountered from my data base and rest api world. Thank you again any additional assistance is appreciated.

17

Yes that is correct

In HA, all entities have states. The state is what represents the current state of the entity. For a cover, the possible states would be open, closed, opening, closing, unavailable, and unknown. It is not possible for a cover entity to have any state besides those. However, entities can also have attributes. Attributes hold additional information and can really be anything. For a cover that supports being partially open, it could have an attribute called position which holds the current position of the cover. So the state might be open while the position attribute is 50. I recommend you go to developer tools > states and search for the entities that represent your blinds, and see what the state is and see what attributes they have. You will need to understand this to create a working script or automation.

To create a template you will have to type it in using your keyboard. You can do this in the script editor UI but the UI will just give you a place to type it. You also need to know where templates are allowed and where they are not allowed. The docs (usually) specify this.

—

To start, we can make a simple script that uses the “set_position” command. We can make it more complex later by adding the “while” loop but we’ll hold off for now. In HA, commands are known as a services and the supported services for covers are listed here. And we know what can be templates in service calls from this documentation. (The quick answer is that pretty much everything in a service call can be templated.)

And you may wonder why these services look different from what you shared from your script earlier, which lists devices. You should avoid devices as described here.

So in the script editor, create a new script, enter a name for it, and add an action. The action is “call a service”. The service to select is “cover: set position”. Since we are going to reference a variable, we need to use templates, and so this is about as far as we can get before we have to start typing things out. So click the 3 dots to the right of the text “call a service: ‘Cover set position’ on”. In that menu you can choose “edit in YAML”

Now you have some text that should look like this:

service: cover.set_cover_position
data: {}

In the cover documentation linked above, where it discusses the cover.set_position service call, there is an example you can just copy from. Paste the relevant text into your script, replacing the text that was there. So you now have:

service: cover.set_cover_position
target:
  entity_id: cover.demo
data:
  position: 50

Instead of copying this over, you could have chosen a cover entity and entered a position in the UI before switching over to YAML. Either way you do it, you want to get the data structure and spacing correct before we start adding templates.

So now we don’t want to issue the service call to cover.demo. Instead, we want it issued to whatever variable we pass into this script. So now we replace it with a template that references a variable. We can do the same thing with the position as well:

service: cover.set_cover_position
target:
  entity_id: "{{ my_cover_entity }}"
data:
  position: "{{ desired_position }}"

You can now save the script and exit the editor. Your script is set up to accept variables. Specifically two variables; one called my_cover_entity that should contain the entity_id of a cover, and the other called desired_position that should contain an integer between 0 and 100.

1 Like
18

@mekaneck Thank you for that detailed response. I do appreciate it. So you see my script below. Are the items circled in red what HA would call templates? What the rest of world might guess them to be called variables?

image
image994×540 41.2 KB

I attempted to test this in Developer Tools but the script does not appear correctly there. What I am doing wrong? I watched a video that suggested I would be prompted for the “template values”? if I ran the script here but of course that does not work at least for one reason that the script does not appear correctly. Also what dashboard card could I use that would prompt me for the “template” variable values? Thank you.
image
image2024×852 40.6 KB

19

Yes, a template is anything that uses Jinja syntax, which is called out here in the docs, which links to the Jinja docs. Essentially anything that begins and ends with curly brackets is going to be a template. Directly copied from that last link:

The variable is just the my_cover_entity text, but the variable can’t be used unless it is inside a template. And it uses double curly brackets because we need that variable to be provided as an output of the template. So what you circled are variables inside templates.

If you want the UI to display a field to enter the variables into, you need to set up “fields” in your script. If you don’t plan to use the UI to call your script you don’t need fields. Fields are just spaces in the UI to input stuff to populate variables.

The way to call your script from an automation or from another script (or from the UI when you don’t have fields) is to define the variables during the service call. You have two ways to call the service, either blocking (waits for the script to complete before moving to the next step) or non-blocking (calls the script and the keeps going). For your purposes you probably want non-blocking which means you use the script.turn_on call (instead of calling the script directly using script.my_script_name which is blocking). We can look at the example from the docs that uses the script.turn_on service:

# Example configuration.yaml entry
automation:
  trigger:
    platform: state
    entity_id: light.bedroom
    from: "off"
    to: "on"
  action:
  service: script.turn_on
  target:
    entity_id: script.notify_pushover
  data:
    variables:
      title: "State change"
      message: "The light is on!"

So if you want to call your script from the services section of developer tools and you want to pass along variables, you use what was in the “action” section above and modify it for your needs. It would look something like this:

service: script.turn_on
target:
  entity_id: script.set_cover_position
data:
  variables:
    target_cover_entity: "cover.my_cover_entity"
    desired_position: 0

And just for completeness, if you wanted to call it with the blocking method, it would be this:

service: script.set_cover_position
data:
  target_cover_entity: "cover.my_cover_entity"
  desired_position: 0
1 Like
20

@mekaneck Thank you for your response. I created fields because I want to provide input at the time of execution of the script. When creating the fields in the UI I was presented with a choice of “selectors”, I made my best guess at that as I don’t know how to find a definitive answer for the templates created.

However I still cannot run this from the developer tools service tab. What do I have configured wrong that is preventing this from working? Thank you.

image
image2094×1472 119 KB

sequence:
  - service: script.turn_on
    target:
      entity_id: "{{ target_cover_entity }}"
    data:
      position: "{{ desired_position }}"
mode: parallel
icon: mdi:curtains
fields:
  target_cover_entity:
    selector:
      entity: {}
    description: The actual cover entity
    name: target_cover_entity
  desired_position:
    selector:
      number:
        min: 1
        max: 100
    name: desired_position
    description: The position to set the shutter to
``
21

You should concentrate on getting the script working without fields before you try it with them. Your screenshot shows you are on the services tab but in YAML mode, and fields have no effect unless you are in UI mode.

I would suggest staying in YAML mode on the services tab, and simply copying the code from my previous reply (either the second to last block or the last block), and seeing if it works. Change the name of the cover entity as needed.

Edit: I’ll try to say this again but more clearly: the way to pass information into a script at runtime is with variables. Fields simply give you a pretty UI to add those variables. You can pass in variables without a pretty UI. So stop worrying about a nice user interface when you don’t have the guts functioning behind it.

22

It’s probably worth taking a step back and look at what I think your end goal should be:

  1. A script that accepts variables and can open or close whichever cover entity is passed in as a variable
  2. Either 1 automation that calls the script 8 times, each with a different cover entity; OR: 8 automations that each call the script once
  3. 8 different buttons that you can place on your dashboard that each call the script and pass along a different cover entity

You should already have item #1, although we didn’t yet add in the repeat….while loop. This script is called script.set_cover_position

The next easiest thing to figure out is item #3. Because once you are able to figure out how to call script #1 from the services tab in developer tools, you just take that exact code and have a button in your dashboard call the same service with that same code.

Then you can create automations that call the script #1, and again they are going to use that exact same code for the service call.

Finally, if you really want to call script #1 from the UI for some reason, you can add fields and get that working. Though I don’t really understand why you’d want to do that.

1 Like
23

@mekaneck I have taken a long time to reply here but it is not because of a lack of interest.

Recent releases have caused my automations to become unreliable. Of the eight shutters, typically one, sometimes two, do not open (am) or close (pm). There seems to be no pattern to the failures as to which shutter fails. The automations ran perfectly before. I know it is not a hardware or signal strength issue as they work perfect with Tuya App. It is just in HA Just keeping what I have running has keep me from making any progress with other things I want to do in my home.

My end goal is to get my shutters to work reliably under HA control. With respect to your numbered items.

  1. Yes, with modification. The script must accept the position. The devices are not binary and I don’t use them in that way. Due to position in the home and mounting positions. Some are open at 86% and some 14% Some are closed at 0% and some are closed at 100%.
  2. One automation that calls the script 8 times each time on a different entity with a different position to be set.
  3. Two buttons. One button that will set all to specific positions unique to each shutter. This positions can be “hard coded”. This is represent “all close” and another button with other positions that will represent 'all open" Quotes because open means 100% in HA and that is not meaningful in this use case. Like wise closed means 0% which again is not meaningful in this use case.
  4. An automation that does what the above buttons do in the AM and PM respectively.

I am setting aside the while loop for now. For testing purposes I will just keep running (a reasonable amount of times) the script until it works as this is what happens when just set position from developer tools, eventually if works after one or more attempts.

With all that out of the way, where I am in this process is a have a script which has templates for the entity and the position. However I don’t know how to test this script, more specifically how to get values into it for the specific cover and position.

This is were I got lost in your replies, you seemed to go in a couple of different directions. So my question here is how do I run, i.e. pass values into this script and test it. Thank you.

alias: Set Cover Position
sequence:
  - target:
      entity_id: "{{ target_cover_entity }}"
    data:
      position: "{{ desired_position }}"
    action: script.turn_on
mode: parallel
icon: mdi:curtains
fields:
  target_cover_entity:
    selector:
      entity: {}
    description: The actual cover entity
    name: target_cover_entity
  desired_position:
    selector:
      number:
        min: 1
        max: 100
        step: 1
    name: desired_position
    description: The position to set the shutter to
    required: true
24

@mekaneck I made a small change to the script and now I am prompted to enter the values when I run the script from the script editor. So that question is answered. Unforuntely the script did not run and there was an error message as shown below. Also the modified script is listed below also.
What does the error message mean?
Thank you.

alias: Set Cover Position
sequence:
  - target:
      entity_id: "{{ target_cover_entity }}"
    data:
      position: "{{ desired_position }}"
    action: script.turn_on
mode: parallel
icon: mdi:curtains
fields:
  target_cover_entity:
    selector:
      entity: {}
    description: The actual cover entity
    name: target_cover_entity
    required: true
  desired_position:
    selector:
      number:
        min: 1
        max: 100
        step: 1
    name: desired_position
    description: The position to set the shutter to
    required: true

error running script
error running script1318×1700 122 KB

25

I got rid of this error but when I run the script it does not change the position of the shutter.

26

When you use the script.turn_on action, you have to list the variables under a variables: key. This is different from how you’d list variables if you instead called the script directly using the script.my_script_name action.

See the very last example in this section, immediately prior to the blue “note”.

The error simply means there are only certain keys that can be specified under the data: key (that is part of action: script.turn_on). “Position” is not a valid key. (But variables: is :wink: )

1 Like