WTH can't we schedule one-time service calls?

Delay doesn’t survive restart. However making that an input daytime to survive restarts would be really easy.

I don’t use a delay. I use the input daytime. Hence the question.

Yes but you asked why he said it wouldn’t survive restarts, when he was replying to a script that used delays. The answer to that question is: because delays don’t survive restarts.

I was replying to “Same as the one above…” which was a reply to my post in which I explicitly mentioned I was using a helper

True! And I believe this WTH is definitely worth being a core feature, assuming that something can be done about restarts. There have been some creative and somewhat robust workarounds presented for automations to survive restarts, but it’d be really great not have to go to those lengths.

I believe the biggest issue is for implementing this is what happens when triggers would fire in the middle of the restart. Obviously you wouldn’t get the actions that were supposed to happen right then, but what should HA do once it’s fully started up? Drop those actions, run them as soon as possible (which could be significantly later than they should have), notify somehow that they were missed? I think the last time I saw any developers comment about it, the feeling was it was best to drop them and set expectations that automations can’t survive restarts.

FWIW, I only intentionally restart once or twice a month at most for updates, and with a UPS on my server, unintentional restarts happen much less frequently than that. So, for me, my script (or some better coded version of the concept) is a ‘good enough’/90% solution.

I checked what exactly I am doing in my automation. I even explicitly take restarts into account. Here’s the YAML. It uses two datetime helpers, an input boolean and an input number. Because the datetime helper includes the date it will run only once. Here’s the automation. A bit of a mix of languages and UI/YAML code but I hope you’ll be able to read through that.

alias: "Verwarming tijdelijke temperatuur "
description: Tijdelijk verwarming aan of uit zetten
triggers:
  - at: input_datetime.verwarming_uit_tot
    id: stop
    trigger: time
  - at: input_datetime.starttijd_tijdelijk_verwarming
    id: start
    trigger: time
  - entity_id:
      - input_boolean.verwarming_tijdelijk_aan
    id: aan change
    trigger: state
    for:
      hours: 0
      minutes: 0
      seconds: 5
  - entity_id:
      - input_datetime.starttijd_tijdelijk_verwarming
    id: start time changed
    trigger: state
    for:
      hours: 0
      minutes: 0
      seconds: 5
  - entity_id:
      - input_datetime.verwarming_uit_tot
    id: end time changed
    trigger: state
    for:
      hours: 0
      minutes: 0
      seconds: 5
  - entity_id:
      - input_number.tijdelijk_verwarming_temperatuur
    id: Temp change
    trigger: state
    for:
      hours: 0
      minutes: 0
      seconds: 5
  - trigger: homeassistant
    event: start
conditions: []
actions:
  - choose:
      - conditions:
          - alias: Time is right AND switch is on
            condition: and
            conditions:
              - condition: state
                entity_id: input_boolean.verwarming_tijdelijk_aan
                state: "on"
              - condition: template
                value_template: "{{in_time_interval}}"
                alias: "We're in the time interval "
        alias: On now
        sequence:
          - action: climate.set_temperature
            target:
              device_id:
                - 78443199f699942ff5371a9bdef9d30c
            data:
              hvac_mode: heat
              temperature: >-
                {{states('input_number.tijdelijk_verwarming_temperatuur')|float}}
          - action: climate.set_temperature
            metadata: {}
            data:
              temperature: >-
                {{states('input_number.tijdelijk_verwarming_temperatuur')|float}}
              hvac_mode: heat
            target:
              entity_id: climate.zone1
      - conditions:
          - alias: OR
            condition: or
            conditions:
              - condition: trigger
                id: stop
                alias: Stop trigger
              - alias: Interval changed AND we're no longer in
                condition: and
                conditions:
                  - not:
                      - condition: template
                        value_template: "{{in_time_interval}}"
                    alias: "Not in interval "
                  - or:
                      - condition: trigger
                        id: start time changed
                        alias: start changed to outside
                      - condition: trigger
                        id: end time changed
                        alias: end changed to outside
                    alias: OR
              - condition: state
                entity_id: input_boolean.verwarming_tijdelijk_aan
                state: "off"
        sequence:
          - alias: Set thermostat to auto
            action: climate.set_hvac_mode
            data:
              hvac_mode: auto
            target:
              device_id: 78443199f699942ff5371a9bdef9d30c
          - if:
              - condition: state
                entity_id: input_boolean.verwarming_tijdelijk_aan
                state: "on"
            then:
              - action: input_boolean.turn_off
                metadata: {}
                data: {}
                target:
                  entity_id: input_boolean.verwarming_tijdelijk_aan
            alias: Put temp switch to 'off' if it's on
        alias: "Back to normal "
mode: restart
variables:
  in_time_interval: >-
    {{as_local(as_datetime(states('input_datetime.starttijd_tijdelijk_verwarming')))
    <now() <as_local(as_datetime(states('input_datetime.verwarming_uit_tot')))}}

Got it; I see the script’s fields.

However, the fact remain that actions are part of either scripts or automations. So to implement your proposal, it will have to be part of an automation.

It’s highly unlikely that a third feature will be added, in addition to scripts and automations, that allows one to merely pick an action and request it to be executed at a specific time (then disappear).

Most of your request is already possible by using an automation blueprint (except not delete itself, just disable) … and I already posted links to two blueprint examples (created two years ago).

I didn’t see the full automation when I replied, so I guess I missed the restart support.
At a first glance, this should work, but I think it would be much better as a native feature.

That’s not true. Services can be called without an automation or a script. The developer tools are such an example. The backend is also able to call services, so there’s no need for an automation in order to implement this proposal.

Yes, you can manually execute one action via the UI.

Your request requires (at minimum) the ability to automatically execute an action at a specific time.

The only available “vehicle” currently designed to automatically execute actions according to specific criteria is an automation.

I don’t know what’s your definition of a “vehicle”, but the backend is capable of calling services, and could be augmented to support scheduling it. I understand you don’t like this proposal, but please stop making unfounded assumptions in an attempt to make it seem less desirable or harder to build.

Effectively duplicating what automations can already do.

Actually, I am indifferent. Your request duplicates a similar one two years ago. It hasn’t inspired anyone to implement it (for reasons that haven’t changed since two years ago).

Scenes are also replicating what automations can already do. Creating a compelling user experience might involve different mechanisms and different levels of abstractions, some of which might overlap.

A scene is like a group of (limited) actions which can be called by a script or automation as a single action.

It has no triggering mechanism or conditional logic so it’s very much not like an automation. It’s closer in functionality to a script (minus conditional logic, parameters, execution modes, etc).

1 Like

It’s a stored state, which is why transition originally didn’t work for them. Scenes closest cousin is a script, but it’s severely limited in relation to scripts.

Typically any request like this WTH will always be left up to the user via a blueprint or script. I doubt this would be added outside the conversation agent.

1 Like

I said that “Scenes are also replicating what automations can already do”, which was in reference to you saying that my proposal is duplicating what automations can already do. Yes, scripts can also do what scenes are doing, but it seems you’re arguing just for the sake of it at this point. If you really want to go down that route, then automations are also replicating what scripts do, and you could argue that automations should only have a single script call in their actions.

I’ve been with this project long enough to see similar tide shifts. Let’s hope this will be one of them.

Sorry, I just don’t see the benefit. Right now the frontend has a very relaxed validation on the yaml, adding the ability to write an entire script there would require us to build a validation engine that’s similar to voluptuous in JS, and then apply it to the tap actions. Juice isn’t worth the squeeze IMO.

Why would you need an entire script? All I’m suggesting is a single service call. There’s already a UI for this both in the developer tools, and in the script information pop-up.

The existing UI screens you mentioned only serve as rudimentary examples of the desired appearance of your proposal. There’s nothing behind those particular screens that executes the action/script at a desired time (scheduling). That’s the necessary piece of the “scheduled service call” you’re requesting (without it, it’s merely Developer Tools → Actions).

You’ve indicated that scheduling is the missing piece that would need to be built (“augmented to support scheduling”). Yet it’s what no one has bothered to do, for the past two years, largely because automations already handle scheduling.

You’re certainly free to ask for the feature but know that it’s been requested in the past and it hasn’t inspired anyone to invest their time and effort to submit a PR (to either the Architecture or Core repos). It’s likely that the obvious duplication of automations is what dissuades developers.

However, if you have the requisite software skills, I encourage you to submit the idea in the Architecture repo where it will be vetted by others. If approved, you can proceed with its development. Otherwise, you can hope this second request for it will get more traction than the first one.