for my alarm I have a while loop which runs until the alarm is disabled.
this while loop toggles all my lightswitches(25) sends rtttl messages to 4 devices.
and sends an alarm sound to my doorbell,
this happen every 1 second.
but during this loop the interface is terribly slow.
an to "System monitor load " grows over 1.
any reason why this is happening? I would I be able to identity why it’s becomes this slow?
Sounds pretty busy. 
Have you tried a slower loop to see if that makes a difference?
How long does the loop go on for?
Post the yaml
no,
I will do that later, not everyone at home fancies my alarm testing when they are at home
untill I disable it.
repeat:
while:
- condition: not
conditions:
- condition: state
entity_id: alarm_control_panel.home_alarm
state: disarmed
sequence:
- continue_on_error: true
data:
url: >-
http://<credentials>@192.168.180.21:8080/cgi-bin/play.cgi?/app/sound/warning.pcm
subdir: /config/www/images/doorbell/
filename: alarm.txt
overwrite: true
action: downloader.download_file
- continue_on_error: true
data:
tone: siren:d=8,o=5,b=100:d,e,d,e,d,e,d,e
action: esphome.lamp_kamer_voor_rtttl_play
- continue_on_error: true
data:
tone: siren:d=8,o=5,b=100:d,e,d,e,d,e,d,e
action: esphome.switch_kamer_achter_rtttl_play
- continue_on_error: true
data:
tone: siren:d=8,o=5,b=100:d,e,d,e,d,e,d,e
action: esphome.lamp_slaapkamer_rtttl_play
- continue_on_error: true
data:
tone: siren:d=8,o=5,b=100:d,e,d,e,d,e,d,e
action: esphome.bathroom_light_rtttl_play
- continue_on_error: true
target:
entity_id:
- switch.lamp_slaapkamer_relay_2
- switch.keuken_tafel
- switch.keuken_fornuis
- switch.keuken_aanrecht
- switch.lamp_hal
- switch.lamp_voordeur
- switch.lamp_overloop
- switch.lamp_bijkeuken
- switch.lamp_zolder_1
- switch.toilet_light_lamp_toilet
- switch.lamp_garage_achter
- switch.schemerlamp
- switch.lamp_roldeur
data: {}
action: switch.toggle
- continue_on_error: true
data: {}
target:
entity_id:
- light.bulb_kamer_achter_bulb_kamer_achter
- light.bulb_kamer_voor_bulb_kamer_voor
- >-
light.texas_instruments_cc1352_cc2652_z_stack_3_30_build_20210708_kast_lamp
- light.plafond_slaapkamer_light
- light.dimmer_bathroom
action: light.toggle
- delay:
hours: 0
minutes: 0
seconds: 1
milliseconds: 0
- continue_on_error: true
data:
url: >-
http://<credentials>@192.168.180.21:8080/cgi-bin/play.cgi?/app/sound/warning.pcm
subdir: /config/www/images/doorbell/
filename: alarm.txt
overwrite: true
action: downloader.download_file
- continue_on_error: true
data:
tone: siren:d=8,o=5,b=100:d,e,d,e,d,e,d,e
action: esphome.lamp_kamer_voor_rtttl_play
- continue_on_error: true
data:
tone: siren:d=8,o=5,b=100:d,e,d,e,d,e,d,e
action: esphome.switch_kamer_achter_rtttl_play
- continue_on_error: true
data:
tone: siren:d=8,o=5,b=100:d,e,d,e,d,e,d,e
action: esphome.lamp_slaapkamer_rtttl_play
- continue_on_error: true
data:
tone: siren:d=8,o=5,b=100:d,e,d,e,d,e,d,e
action: esphome.bathroom_light_rtttl_play
- continue_on_error: true
target:
entity_id:
- switch.lamp_slaapkamer_relay_2
- switch.keuken_tafel
- switch.keuken_fornuis
- switch.keuken_aanrecht
- switch.lamp_hal
- switch.lamp_voordeur
- switch.lamp_overloop
- switch.lamp_bijkeuken
- switch.lamp_zolder_1
- switch.lamp_toilet
- switch.lamp_garage_achter
- switch.schemerlamp
- switch.lamp_roldeur
data: {}
action: switch.toggle
- continue_on_error: true
data: {}
target:
entity_id:
- light.bulb_kamer_achter_bulb_kamer_achter
- light.bulb_kamer_voor_bulb_kamer_voor
- >-
light.texas_instruments_cc1352_cc2652_z_stack_3_30_build_20210708_kast_lamp
- light.plafond_slaapkamer_light
- light.dimmer_bathroom
action: light.toggle
- delay:
hours: 0
minutes: 0
seconds: 1
milliseconds: 0
here is the loop,
everything is specified twice, because my toggles need to get back to the original state afterwards, probably this can be done smarter using scenes, but I never checked how that should work.
Do your lights have a flash option? That might cause less traffic than toggling them on and off.
action: light.turn_on
data:
flash: long
target:
entity_id: light.all_kitchen_lights
It looks like you are doing too much stuff on every loop.
Take a look at the automation trace to see what steps are using the most time.
Lots of continue_on_errors. Does that mean that you get a lot of failed commands as well as the slow interface? You don’t say what kind of lights you have, but if they’re Zigbee you may be flooding the network.
Generally speaking, long loops are not a good idea. If HA restarts for example, the automation will not trigger again. You might be better off with something that triggers every 30 seconds (say) while the alarm is on, and toggles the lights once.
Edit: What are you running all this on, by the way?
Id even go so far as to redesign. You can absolutely molasses good hardware if it’s not operating in the framework of the system.
HA at its core is a state engine. It operates on triggers. It does THAT amazingly well and would eliminate the issue. You just have to refactor to base your things on events not loops.
Can you clarify what the following action is doing?
- continue_on_error: true
data:
url: >-
http://<credentials>@192.168.180.21:8080/cgi-bin/play.cgi?/app/sound/warning.pcm
subdir: /config/www/images/doorbell/
filename: alarm.txt
overwrite: true
action: downloader.download_file
it’s downloading warning.pcm and saving it as /config/www/images/doorbell/alarm.txt. Doesn’t really make sense to me…
I could maybe introduce this for my esphome lights, not for my zigbee once,
it’s only like 25 requests, it does not sould like a lot to me,
also if the request takes time it wouldn’t mean it impacts performance
no I don’t, but even if one fails it should always continue.
the issue with this setting however is that you don’t know if one fails.
I know, but at the moment this is not my concern,
HA Yellow with RPI4 4GB
I am not sure how, and at that point I need the event to be triggered every second.
It triggers the warning sound on the doorbell, this can be done using a get request. I think the content is empty but the download_file action requires a filename.
I could indeed make the changes, but the current approach wouldn’t justify the performance issue I’m facing.
Well, yes… I think that’s what we’re all saying.
You might be better off using one of the following instead of trying to perform multiple file overwrites every loop:
As Jack mentioned before you may be flooding your Zigbee mesh. It would be best use Zigbee groups and call actions on those instead of calling them on all the devices individually.
Regarding the rtttl actions, why not set those up as a on-device automations attached to template switches. That would significantly reduce the number of action calls you are making from you HA automation. You would just need to turn the switches on at the start and off at the end.
I find that VERY difficult to believe.
Describe what you’re actually trying to do rather than how you believe it should be done…
Let’s start there. (and yeah that loop is absolutely hammering your system)
Rest Requests seems better indeed,
the only downside is, I need to pre-configure it instead of making it up in the automation.
it’s actually only 2 zigbee calls, 1 to a group and 1 single, the rest of the devices are esphome,
but this is the only screnario where I want to combine the devices.
I think this is the way to go, also for the esphome switches.
My plan is to flash all the lights, and make some noise, on devices so anyone trespassing wouldn’t be comfortable.
I also send some notifications but that is a one time action before the loop starts
All those lights/switches in a single call does not make it a single zigbee call. In fact, pretty much every service call on multiple entities is always separate by the time it gets to the “controller” unless you use zigbee groups or zwave multicast.
[quote=“bkbartk, post:4, topic:904660”]
ESPHome
- switch.lamp_slaapkamer_relay_2
- switch.keuken_tafel
- switch.keuken_fornuis
- switch.keuken_aanrecht
- switch.lamp_hal
- switch.lamp_voordeur
- switch.lamp_overloop
- switch.lamp_bijkeuken
- switch.lamp_zolder_1
- switch.toilet_light_lamp_toilet
- switch.lamp_garage_achter
- switch.schemerlamp
- switch.lamp_roldeur
- light.bulb_kamer_achter_bulb_kamer_achter
- light.bulb_kamer_voor_bulb_kamer_voor
- light.plafond_slaapkamer_light
Zigbee
- >-
light.texas_instruments_cc1352_cc2652_z_stack_3_30_build_20210708_kast_lamp
- light.dimmer_bathroom
so only 2 zigbee calls
FYI,
I found that there were automations on some status changes of switches and lights. I changed only trigger those if the alarm is disarmed.
Next to that When I find the time I will apply your suggestions.
I’ve found a similar problem when trying to send alot of zigbee commands to multiple devices at once. I didn’t notice the UI lagging out, but the logs would be full of errors saying that the devices did not respond.
In my case, I was trying to create a smooth colour transition on some RGB bulbs using the following script, but it just doesn’t scale well once you start targeting multiple devices:-
alias: Colour Loop Lights
sequence:
- if:
- condition: template
value_template: "{{ counter is not defined or counter == 0 }}"
then:
- stop: Counter is zero
- if:
- condition: template
value_template: "{{ targetid is not defined }}"
then:
- stop: No target entity id provided
- repeat:
count: "{{ counter }}"
sequence:
- data_template:
xy_color: "{{ colours[((startingseed+repeat.index) % (colours | count))] }}"
transition: "{{ transition if transition is defined else 1 }}"
target:
entity_id: " {{ targetid }}"
action: light.turn_on
- delay:
milliseconds: "{{ (transition*1000) if transition is defined else 1000 }}"
- delay:
hours: 0
minutes: 0
seconds: 1
milliseconds: 0
variables:
colours: |-
{{ [[0.217,0.077], [0.157,0.05], [0.136,0.04], [0.137,0.065],
[0.141,0.137], [0.146,0.238], [0.151,0.343], [0.157,0.457],
[0.164,0.591], [0.17,0.703], [0.172,0.747], [0.199,0.724],
[0.269,0.665], [0.36,0.588], [0.444,0.517], [0.527,0.447],
[0.612,0.374], [0.677,0.319], [0.701,0.299], [0.667,0.284],
[0.581,0.245], [0.477,0.196], [0.385,0.155], [0.301,0.116]] }}
startingseed: "{{range(0,(colours | count)-1) | random}}"
mode: parallel