core: Trigger Update Coordinator: Running script requires passing in a context

I’m able to reproduce this in my home system and will look for a fix

Just dropping a note to prevent this becoming stale, as it is still occurring on 2024.2.0b1

Still there on 2023.9.2

Please don’t derail the issue to a weather sensor discussion. The documented sensor for that is just an example that causes context warning logs. And yes with a weather state trigger in stead of a time pattern is just a work around the issue:

Trigger based template sensors with particular triggers, like time, date, sun…, and an action section in the template, cause these loggings.

I hope that this gets resolved, as for other template sensors, there is no easy work around.

Same here using service: calendar.list_events .

My calendar sensor (similiar to service: weather.get_forecast ) is the only one with an hourly time pattern trigger. Since I created it, I receive an hourly error message as described above.

I have exactly the same log! Did not find why. All I did was modifying my template sensor using trigger and action to use the new forecast service

Thanks to @emontnemery who did the sleuthing!

I think the issue is simply: Not all triggers have a context (yet). 🤷 That might be by design, because not all triggers are tied to an actual event (which seems to be the rule when to generate a new context). The issue does not appear with automations, because the automation generates its own event “automation_triggered” (thus creating a new context for its actions).

The solution would be to either

• generate a new context for each template update (probably a breaking change).
• or generate a context for each trigger.

Core developers might ask to also generate an event in both of these cases.

Please don’t derail the issue to a weather sensor discussion

I agree. I mentioned this issue in my PR because the example in the Home Assistant weather docs is one case where this can occur, but changing the weather docs won’t fix the actual problem here.

You are right, Changing to the “trigger” as in your “solution” , doesn’t throw errors On the other hand, it doesn’t update either, as it seems the weather-integration doesn’t make calls to the Provider-Api, when they update information

I’ve been using my example for several days and it has been working perfectly for me. To avoid derailing this issue though, please move discussion about this to my PR.

@jaydeethree You are right, Changing to the “trigger” as in your “solution” , doesn’t throw errors On the other hand, it doesn’t update either, as it seems the weather-integration doesn’t make calls to the Provider-Api, when they update information ( Maybe the weather-integration only makes 1, at best 2 calls a day , to the cached data, from the i.e met.no integration) Below changes as in your “Fix” is not reliable, as in an hour the data is outdated, and not updated

template:
  - trigger:
      - platform: state
        entity_id: weather.home
    action:
      - service: weather.get_forecasts
        data:

On the other hand, yes the example in Weather-Integration page, does throw an error ( I have no idea how this example could end up in the Docs ) PS: i use met.no as provider

Im baffled about how a homeautomation system, can even “implement” such an unreliable weather-integration, since the “turnover” to service-call for weather. The default weather card, was previous announced that changes been made so the integration should provide 6 days instead of 5, but fact is , the card shows 5( Where As 1 is actually current, most of the hour, so it leaves us with 4 days forecast. in the default card, using met.no ) Forecast are as known “unreliable” therefore Providers updates there forecasts at-least every hour, cause i.e the Wind Changes, more rain than expected, colder doo to wind-change etc.

I Hope Devs will reconsider this Integration, as weather-forecast IS an Important feature in a homeautomation system, im pretty sure noone using HA haven’t got the weather in their installation. Everyone has ! ( They rely upon it( as much as one can ) , but most are not ware about the actual “glitch” and unreliable facts, because they don’t compare. But it seems like Devs forcing people into template-sensors, automations and own-made direct Api-calls , as currently one can not rely upon this implementation of a weather-forecast, to control anything. And the “still” constant " Trigger Update Coordinator: Running script requires passing in a context " even with the example in Docs, is unbelievable This is i assume, your suggested solution applied to Example in Docs, using met.no.

  - trigger:
      - platform: state
        entity_id: weather.forecast_home
    action:
      - service: weather.get_forecasts
        data:
          type: hourly
        target:
          entity_id: weather.forecast_home
        response_variable: hourly
    sensor:
      - name: Temperature forecast next hour
        unique_id: temperature_forecast_next_hour
        state: "{{ hourly['weather.forecast_home'].forecast[0].temperature }}"
        unit_of_measurement: °C

PS: i added " availability: “true” ", just for a test, also tried with the suggested " is_number " above ( However not in an automation ) , only for this example sensor

I don’t know the impact of providing a context for time/date/sun triggers, but just making the logging debug level would be fine for me as well (as it is working)

Unfortunately, I discovered that creating a new context within the template component makes the logbook inaccurate. For that reason, I’m leaving the PR as a draft until I have more time to get back to it or someone else finishes what I’ve started.

Creating a new context causes it to blame any change in the template sensors on the first service called in the action section, which is inaccurate. A fix I found for that is to also fire an event after we create a new context and define an async_describe_events callback to format/display the event in the logbook. Then every time any trigger fires we would spam an additional logbook entry that says nothing but ‘template block was triggered’, which is less than ideal, but prevents the logbook from associating the state change with the call_service event.

The context/logbook behavior isn’t obviously documented and I’m not super familiar, so I’m having to make sense of it as I go. There may be a better way to solve the subsequent issues that isn’t obvious to me.

Still there with 2023.10.0