Hello, I am wanting confirmation of my understanding of the key word mode in the following use case. I have an automation generated by the UI. It has placed the keyword “mode” at the end with a value of “single”. New to yaml syntax and not a phyton programmer. In the automation below my understanding it is that the mode keyword here applies to the automation and has no impact on the script (courtesy of @Didgeridrew )that is called. In this automation the script will be called twice, in succession without delay. The script on the other hand has a “mode” of “parallel” which I understand will allow the script to be run more than once without waiting for prior instantiations/executions/invocations (don’t know what word HA uses) to complete.
Here is the question: Can I expect this automation to only to run once and not be allowed to run again until completed but the script to be run in parallel? Meaning in this example the two shutters will attempt to be closing at the same time.
Thank you.
Automation:
alias: Close Shutters
description: Close All Shutters
trigger:
- platform: sun
event: sunset
offset: "00:20:00"
condition: []
action:
- action: script.set_cover_position_rev3
metadata: {}
data:
target_cover_entity: cover.tsd_curtain
desired_position: 0
- action: script.set_cover_position_rev3
metadata: {}
data:
target_cover_entity: cover.bsd_curtain
desired_position: 0
mode: single
Script:
alias: Set Cover Position rev3
sequence:
- repeat:
sequence:
- action: cover.set_cover_position
target:
entity_id: "{{ target_cover_entity }}"
data:
position: "{{ desired_position }}"
- delay: 5
until:
- condition: template
value_template: >
{{ is_state_attr(target_cover_entity, 'current_position',
desired_position )
or repeat.index > 5 }}
mode: parallel
icon: mdi:curtains
fields:
target_cover_entity:
selector:
entity:
filter:
- domain: cover
description: The actual cover entity
name: Target Cover Entity
required: true
desired_position:
selector:
number:
min: 0
max: 100
name: Desired Position
description: The position to set the shutter to
required: true
description: Matt's Description
The script can have multiple instances running in parallel, but the ones from your automation will not be running in parallel, at least not as currently written. This is due to your use of the direct calling method, not the mode of the script being called.
I want the scripts to run in parallel so the shutters close at the same time. I have 6 more to add to the script. Then I will make an automation to open them all at once.
I am still have trouble getting this to work properly. I made a automation to close all of them. It worked once. Then I ran a two automations, one to open the top shutters then one to run the bottom shutters. Not all the shutters opened. Using the UI I opened the shutters that did not open and then tried the close all shutters automation. It did not close all the shutters. The automations are listed below. The “Trace Timelines” of the failed runs are also listed. I don’t really see any useful information there. How do I figure out why these are failing? My guess is that the cover entity is not reflecting the cover position properly. i.e. that shutter is actually closed (0) but reporting open (86) so the automation/script thinks it is done.
How is the value of the shutter position entity updated? Does HA poll the devices for this information? Does HA wait for the device to report it? What is the fundamental communication mechanism? Push? Pull? How can force this to happen? Is this just a hopeless effort due to underlying bugs that I a cannot fix?
For example, right now all the blinds are open but when I open the UI I see that the position for some is not correctly reported, this cover is not actually closed:
alias: Close Shutters
description: Close All Shutters
trigger:
- platform: sun
event: sunset
offset: "00:20:00"
condition: []
action:
- parallel:
- action: script.set_cover_position_rev3
metadata: {}
data:
target_cover_entity: cover.tlo_curtain
desired_position: 0
- action: script.set_cover_position_rev3
metadata: {}
data:
target_cover_entity: cover.blo_curtain
desired_position: 0
- action: script.set_cover_position_rev3
metadata: {}
data:
target_cover_entity: cover.tlf_curtain
desired_position: 100
- action: script.set_cover_position_rev3
metadata: {}
data:
target_cover_entity: cover.blf_curtain
desired_position: 100
- action: script.set_cover_position_rev3
metadata: {}
data:
target_cover_entity: cover.trf_curtain
desired_position: 0
- action: script.set_cover_position_rev3
metadata: {}
data:
target_cover_entity: cover.brf_curtain
desired_position: 0
- action: script.set_cover_position_rev3
metadata: {}
data:
target_cover_entity: cover.tsd_curtain
desired_position: 0
- action: script.set_cover_position_rev3
metadata: {}
data:
target_cover_entity: cover.bsd_curtain
desired_position: 0
mode: single
Triggered manually at September 21, 2024 at 10:19:58 AM
Execute in parallel
Script 'Set Cover Position rev3'
Set Cover Position rev3 (script.set_cover_position_rev3) started
(script.set_cover_position_rev3) turned on
Set Cover Position rev3 (script.set_cover_position_rev3) started
Script 'Set Cover Position rev3'
Set Cover Position rev3 (script.set_cover_position_rev3) started
Set Cover Position rev3 (script.set_cover_position_rev3) started
Script 'Set Cover Position rev3'
Script 'Set Cover Position rev3'
Set Cover Position rev3 (script.set_cover_position_rev3) started
Set Cover Position rev3 (script.set_cover_position_rev3) started
Set Cover Position rev3 (script.set_cover_position_rev3) started
Set Cover Position rev3 (script.set_cover_position_rev3) started
Finished at September 21, 2024 at 10:20:28 AM (runtime: 30.51 seconds)
alias: Open Top Shutters
description: Close Top Shutters
trigger:
- platform: sun
event: sunrise
offset: "-00:45:00"
condition: []
action:
- parallel:
- action: script.set_cover_position_rev3
metadata: {}
data:
target_cover_entity: cover.tlo_curtain
desired_position: 86
- action: script.set_cover_position_rev3
metadata: {}
data:
target_cover_entity: cover.tlf_curtain
desired_position: 14
- action: script.set_cover_position_rev3
metadata: {}
data:
target_cover_entity: cover.trf_curtain
desired_position: 86
- action: script.set_cover_position_rev3
metadata: {}
data:
target_cover_entity: cover.tsd_curtain
desired_position: 86
mode: single
Triggered manually at September 21, 2024 at 10:13:06 AM
Execute in parallel
Script 'Set Cover Position rev3'
Set Cover Position rev3 (script.set_cover_position_rev3) started
(script.set_cover_position_rev3) turned on
Set Cover Position rev3 (script.set_cover_position_rev3) started
Script 'Set Cover Position rev3'
Set Cover Position rev3 (script.set_cover_position_rev3) started
Set Cover Position rev3 (script.set_cover_position_rev3) started
Finished at September 21, 2024 at 10:13:37 AM (runtime: 30.32 seconds)
alias: Open Bottom Shutters
description: Close Bottom Shutters
trigger:
- platform: sun
event: sunrise
offset: "-00:45:00"
condition: []
action:
- parallel:
- action: script.set_cover_position_rev3
metadata: {}
data:
target_cover_entity: cover.blo_curtain
desired_position: 86
- action: script.set_cover_position_rev3
metadata: {}
data:
target_cover_entity: cover.blf_curtain
desired_position: 14
- action: script.set_cover_position_rev3
metadata: {}
data:
target_cover_entity: cover.brf_curtain
desired_position: 86
- action: script.set_cover_position_rev3
metadata: {}
data:
target_cover_entity: cover.bsd_curtain
desired_position: 86
mode: single
Triggered manually at September 21, 2024 at 10:14:49 AM
Execute in parallel
Script 'Set Cover Position rev3'
Set Cover Position rev3 (script.set_cover_position_rev3) started
(script.set_cover_position_rev3) turned on
Set Cover Position rev3 (script.set_cover_position_rev3) started
Script 'Set Cover Position rev3'
Set Cover Position rev3 (script.set_cover_position_rev3) started
Set Cover Position rev3 (script.set_cover_position_rev3) started
21 seconds later
(cover.bsd_curtain) turned open
Finished at September 21, 2024 at 10:15:19 AM (runtime: 30.42 seconds)
The script and automations are running as expected. But the questions you ask are no longer something Home Assistant generic, but integration specific. It depends on how the integration communicates with the covers, and if wireless technology is involved, also on robustness of the communication protocol.
For instance, Somfy RTS is known to be sensitive to multiple RF commands being fired in short succession. While it is possible to have one code sent and many covers respond, if you have them in Home Assistant as separate covers, HA will rapid fire, and covers may get overwhelmed and ignore the RF bombardment. That, combined with RTS being one way communication, the integration has no way of knowing it did not work.
You will undoubtedly have other hardware, but the example may make clear this may not be anything to do with parallel execution in scripts. But parallellism will make it worse if the blinds have this problem. Also note that having short delay between commands does not mean all blinds will wait untill the other is done. They will most likely be offset a little bit. But as said, it all depends on the technology behind the blinds and the implementation of the integration to go with it. If anyone, the code owner of the integration is the most likely to know.
Then I would not be surprised if the chitchat of 6 covers all getting commands and communicating positions back is causing collisions and messages are lost. But I think only the integration code owner can shed more light, if at all.
Do you think this is so crude an implementation that there is no confirmation of messages received such as in TCP? Rf is not bi-directional but Bluetooth is. There should be no reason why they can’t communicate reliably.
This is what does not add up. The script runs in a loop until the current_position attribute is at the desired_position. Yet the UI does not reflect this position (sometimes) what is different about where the UI is getting the position from and where the script is getting the position from?
I also have bi-directional RF equipment. Bluetooth is suseptible to many kinds of interference, and it all depends on the effort the manufacturer put in.
Inference is a layer one issue, the physical layer. That is why you have protocols to compensate. This is why the internet even works TCP acknowledges every packet.
And you assume those protocols are used. But how would you know? What happens if you use the manufacturers app to sens multiple commands quickly? If that is not possible, it is also very much possible the manufacturer did not care to protect against it.
Well that would be an incredibly poorly written not production quality app. Speaking of the app, the shutters work fine in the Tuya app so there is no “interference” This is an HA issue.
This.
In consumer and (I)oT devices I assume that ‘least effort’ actually happened I wouldn’t doubt those things try to get stat return but don’t care if the message doesn’t exactly add up. It’s sure the easiest way to write a firmware.
Hey do the thing!
*waits
Hey did you do the thing?
I$5cdD_ACTIO3$$$#…THING waits…
I$5c4$&3($78007_&&&&$#…THING!!!
*dude you there?
Meh I got other things to do whatev.
…
Define HA. If the tuya app put all the logic for resilience in the app, it may not be in the integration. Many ntegrations are built by community members in their spare time, with no help whatsoever of the manufacturer.
What is it you are trying to accomplish here? Could the script contribute to the problems? Looping and testing is not something one is expected to do in an event driven design. It would also likely perform worse than event driven.
I am trying to close the shutters. Looping and testing is required as the shutters don’t move instantaneously. The script was written by an experienced person. @Didgeridrew
