I have not looked at helpers but unfortunately the open and close automation are while loops because the POS tuya Bluetooth gateway and motors don’t just open or close if you tell them once. You have repeat the action until the finally respond.
Ah I see so its kind of a band aid. Is it a signal strength issue?
You can create a script that calls multiple automations vs automation/scene, then reference that script in button card.
I think it has something to do with the devices being in some kind of sleep mode. Definitely a band aid and something to come back to.
Everything I read talks about automations calling scripts not scripts calling automations. How do you call an automation in a script?
You can use the UI to accomplish the setup. Click ADD Action, scroll to the bottom, click other actions and select Automations.
Add all the automations you want to trigger under choose entity Make sure you choose Automation: Trigger not Automation: Turn on
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
I agree, but he is running loops. The blinds are non-responsive so there is an underlying issue.
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
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…
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”.
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.
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
@mekaneck @LiQuid_cOOled Finally made a little time to work on HA 
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.
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:
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
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.
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
@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?
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.
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:
{% ... %}for Statements{{ ... }}for Expressions to print to the template output{# ... #}for Comments not included in the template output
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
@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.
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
``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.
It’s probably worth taking a step back and look at what I think your end goal should be:
- A script that accepts variables and can open or close whichever cover entity is passed in as a variable
- Either 1 automation that calls the script 8 times, each with a different cover entity; OR: 8 automations that each call the script once
- 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.