Running_script: false limit: 10

Hello Everyone,

From the latest major update to 2023.6, I am having issues with some automations and scripts. They were working fine for months with no problems until a few days ago.

Problem is that some automations and scripts issue the following message in traces screen:

running_script: false
limit: 10

I am not sure whether this message appeared before, because some of the automations and scripts reporting such message execute fine with no problems (???), and all actions execute ok. However, some of the automations and scripts are stopping at some point where they did not use to before. One of the automations that are being stop without being executed completely is the following:

alias: Riego
description: ""
trigger:
  - platform: time
    at: "19:08:00"
    enabled: true
  - platform: time
    at: "04:58:00"
    enabled: true
condition: []
action:
  - type: turn_on
    device_id: cf1684f9f3941edfc7aef516eaa9b2dc
    entity_id: switch.lumi_riego_aspersion
    domain: switch
  - service: timer.start
    data:
      duration: "0"
    data_template:
      entity_id: timer.riego_aspersion
      duration: "{{ states('input_datetime.riego_aspersion') }}"
  - wait_for_trigger:
      - platform: state
        entity_id: timer.aspersion
        to: idle
  - type: turn_off
    device_id: cf1684f9f3941edfc7aef516eaa9b2dc
    entity_id: switch.lumi_riego_aspersion
    domain: switch
  - delay:
      hours: 0
      minutes: 0
      seconds: 10
      milliseconds: 0
  - type: turn_on
    device_id: cf1684f9f3941edfc7aef516eaa9b2dc
    entity_id: switch.lumi_riego_goteo
    domain: switch
  - service: timer.start
    data:
      duration: "0"
    data_template:
      entity_id: timer.riego_goteo
      duration: "{{ states('input_datetime.riego_goteo') }}"
  - wait_for_trigger:
      - platform: state
        entity_id: timer.goteo
        to: idle
  - type: turn_off
    device_id: cf1684f9f3941edfc7aef516eaa9b2dc
    entity_id: switch.lumi_riego_goteo
    domain: switch
mode: single

That’s a simple irrigation automation based on two timers (for two zones) that I can adjust through “input_datetime.riego_aspersion” and “input_datetime.riego_goteo” helpers.

This is the traces screen where the “running_script: false limit: 10” is issued:

And this is the screen where the next step is displayed with some “null” messages are displayed. From that point, automation is not executed:

This is just a sample, as I do have some other automations and scripts with the same problem.

I have seen some similar forum topics but none of them apply to this scenary, but to specific automation problems. I have also realized that most of the problematic automations and scripts (if not all… still checking that) some sort of template is being used at some point of the automation/script. However, I haven’t seen any breaking change for this. Actually, if I execute every step manually one after another, all of them work fine.

Is there any way to increase the “limit:10” value? According to the Scripts documentation, such value can be increased, but it only applies to queued and parallel automations, and this specific automation (and most of them) are single.

Why is this message issued? What does the 10 value mean? Is it a time value, number or parallel threads or any other thing?

Also tried to disable all automations and reanabled as suggested here, but nothing changes in my specific case. Due to this, I am 100% sure that there are not any other automations being executed at the same time.

Is anyone else experiencing the same? Any way to fix this? I have been digging on this for days and I haven’t been able to figure out how to fix it or how to find a workaround.

Thanks in advance!

SĂ©sar

That’s fishy :wink:
data_template is deprecated since a while, and you’re giving conflictual duration data here.

Try (in all relevant actions)

  - service: timer.start
    data:
      entity_id: timer.riego_aspersion
      duration: "{{ states('input_datetime.riego_aspersion') }}"

Hey @koying! Thanks for your prompt feedback! Timer also works with your code (removing data_template). Unfortunately, issue persists. :frowning:

I will review all automations to update this accordingly. Anyway, any other suggestion that could help to fix this?

Wait, you start timer.riego_aspersion but wait for timer.aspersion? Is that correct?

1 Like

You are completely right. What a moron I am… :sweat_smile: After updating the entity, automation works like a charm. It usually is the most simple thing but eyes use to focus on the most complex.

Now I understand why such “wait for trigger” entry wasn’t being displayed in the visual editor, only in yaml view. The entity was not typed correctly hence the mess. Now, I will have to review other automations that are having issues. I guess I have made mistakes when updating any. Strange thing is that I think I haven’t touched this specific automation for months, but who knows… I am always trying to optimize things.

The “Running_script: false limit: 10” thing is still being issued on every timer step, but everything is executed normally so I guess those messages are part of some sort or standard warning. It would be great to understand what they really mean:

Having said that, I really appreciate your prompt feedback and solution. I will review everything, will clean-up the data_template entries and will ask for further help if needed. Thanks!

1 Like

Is there a reason why you chose to design the automation using wait_for_trigger with a State Trigger (to detect the timer’s completion) instead of the more traditional design that employs an Event Trigger (to detect the timer.finished event)?

The traditional design doesn’t employ a wait_for_trigger so the script promptly completes the actions associated with the trigger (via a choose) and doesn’t wait within the automation’s action section.

Not really. I used wait_for_trigger option because I tried it and just worked. I guess I read it somewhere when I did the automation. However, I appreciate your input and will try your approach given the way you tell it works. Sounds like it is cleaner than my option and I always try to optimize things as good as possible. Thanks!

Here’s an example of an automation employing the design I had described.

alias: Riego
description: ""
trigger:
  - platform: time
    at:
      - "19:08:00"
      - "04:58:00"
  - platform: event
    event_type: timer.finished
    event_data:
      entity_id: timer.riego_aspersion
  - platform: event
    event_type: timer.finished
    event_data:
      entity_id: timer.riego_goteo
condition: []
action:
  - choose:
      - conditions: "{{ trigger.platform == 'time' }}"
        sequence:
          - service: switch.turn_on
            target:
              entity_id: switch.lumi_riego_aspersion
          - service: timer.start
            target:
              entity_id: timer.riego_aspersion
            data:
              duration: "{{ states('input_datetime.riego_aspersion') }}"
      - conditions: "{{ trigger.platform == 'event' }}"
        sequence:
          - if: "{{ trigger.event.data.entity_id == 'timer.riego_aspersion' }}"
            then:
              - service: switch.turn_off
                target:
                  entity_id: switch.lumi_riego_aspersion
              - delay:
                  seconds: 10
              - service: switch.turn_on
                target:
                  entity_id: switch.lumi_riego_goteo
              - service: timer.start
                target:
                  entity_id: timer.riego_goteo
                data:
                  duration: "{{ states('input_datetime.riego_goteo') }}"
            else:
              - service: switch.turn_off
                target:
                  entity_id: switch.lumi_riego_goteo
    default: []
mode: single

I think it’s fairly straightforward but let me know if you need me to explain how it operates.

References:
Event Trigger
Automation Trigger Variables - Event
Choose a group of actions

1 Like

At first glance, it is easy to understand what every step does. I will try this and will see whether it is worth it to switch from my current workflow.

Will also have a look to the references you provided. I am curious to know all the benefits of your option. If I understand everything, perhaps it will help to optimize other automations and scripts. Thanks!

The primary advantage is that the automation spends very little time processing its action section. It turns on a switch, starts a timer, and done. It doesn’t spend any time within action waiting for something else to happen other than the 10-second delay.

This is useful if Home Assistant is restarted because there’s little chance of interrupting the automation while it’s busy processing its actions. In contrast, a wait_for_trigger is terminated by a restart.

1 Like

The fact of doing a “fire and forget” automation is really a great benefit and will be definitely worth it! The truth is that delays (specifically the long ones) is something that I have never liked a lot. On top of that, if restarts reduce the chances to screw an automation execution, shut up and take my money! :stuck_out_tongue_winking_eye:

The automation works fine. However, I have noticed that the {{ trigger.platform == 'event' }} condition is not displayed at all in the visual editor. Is this normal?

Apart from this, one thing I don’t like very much is that I can’t manually run this automation given the above condition. It is not a drama because there are alternatives for that, but it is something to take into account.

I can’t comment because I don’t use the visual editor (due to its quirks and limitations). Perhaps it has no way to display a Template Condition in shorthand notation. You can try changing it to this and see if that’s better for the visual editor:

      - conditions:
          - condition: template
            value_template: "{{ trigger.platform == 'time' }}"
        sequence:

I suggest you forego relying on manual execution because its usefulness is limited.

  1. There should be very little need to manually execute an automation. It’s not a comprehensive method of testing the automation (because it only executes the actions).

  2. Any automation of sufficient complexity will employ the trigger variable (even if it’s only for something simple like referencing trigger.id) Therefore it cannot be manually executed.

  3. Any automation that employs Trigger Variables cannot be manually executed. These variables are defined only if the automation is triggered by one of its triggers (not manually).

Great! :+1:t3:

1 Like

I do agree with you, generally. However, for this specific use case, sometimes I run it manually because I want to irrigate at a random moment. Actually, I have a button in lovelace for performing such operation when needed.

For the rest of your comments, well noted. Indeed all your feedback will be taken into account. I really learnt a lot with all your comments and suggestions. Thank you so much!

Add a State Trigger monitoring a Button helper. Modify the first choose condition to accept time or state.

      - conditions: "{{ trigger.platform in ['time', 'state'] }}"
        sequence:
1 Like