Make service data responses easier to access with templates

Ever since 2023.9, the official way to access weather data (or really any service response data) in a template is by going into your configuration.yaml and writing something like this:

  - action:
      - service: weather.get_forecasts
          type: daily
          entity_id: weather.home
        response_variable: daily
        - platform: state
          entity_id: weather.home
      - name: "Today's Forecast Hi/Lo"
        unique_id: "Forecast_HiLo"
        state: >
          {% if daily['weather.home'].forecast[0].temperature != None %}
          {{ daily['weather.home'].forecast[0].temperature }}°F / {{ daily['weather.home'].forecast[0].templow }}°F
          {% else %}
          Low: {{ daily['weather.home'].forecast[0].templow }}°F 
          {% endif %}

then you can use this entity you created to have weather forecast data anywhere else.

This, however, has a few problems that are linked with / cause other problems:

1. (Lack of) Debugging
If you want to debug your templates, you would usually write them in the template editor tab of developer tools.
In there, you can’t use service responses as template variables. You can use the service tab and copy and paste the response, then go back to your template tab and {% set daily = [whatever your response data is] %}. This is also a struggle as you have to convert your service data to one line for that to work (as far as I can tell, feel free to correct me if there’s another, easier way).

The only way I’ve found to try and debug this is to try and make a script that calls your desired service and feeds the result of your desired template into a input_text helper. This is just way

2. No UI Support
This may be another whole feature request, but you can’t call services (as an action) through the template helper that you can create through the UI.
This means you have to restart your home assistant (or reload your yaml, which sometimes causes certain custom integrations to break) every time you make a change and you don’t get any sort of error message if something doesn’t work (except the system logs, sometimes).

I get it, this is definitely an advanced feature and the UI is more geared towards casual users, but it’s clear the UI has some amazing benefits over the configuration.yaml. Also, just because I’m an “advanced user” doesn’t mean I don’t like my home being organized in a nice way :slight_smile:

3. Having to add a trigger
Your action (in this case, a service call) can only be run whenever you also have a trigger specified. This means your template sensor can’t auto-update (which is a very nifty feature) based off what your template gets the state of. This adds a bunch of extra unnecessary code that you might need to debug when a feature already exists that calculates the correct trigger for you.

4. Only in configuration.yaml
You can only have an action associated with a template sensor in your configuration.yaml. This means you can’t use templates with service response data anywhere else in your home assistant instance, like in dashboards, custom cards, or (as already mentioned) the template developer tools.

Right now, this is only a small problem, as there are only a select few types of data that can be accessed with service responses. But as home assistant makes more data only accessible through services (as I suspect they are going to do for performance reasons), the problem will grow bigger and bigger.

So, what can we do about it?

This is the section I’m probably going to need your (the communities’) most help with, since I’m not familiar with what libraries home assistant uses in their code and what is feasible with those libraries. However, I think it boils down to:

Add a function that provides service responses

I don’t know how it’s going to work with the state machine and how templates usually only display data and don’t perform actions, but I think this is the best path. Something like {% set daily = service_data('weather.get_forecasts', target='weather.home', forecast_type='daily') %} seems like a simple and elegant solution to this problem.

This all comes from a place of love for home assistant. I love new features that improve performance (like service responses) and I love them being used by more and more different things in home assistant. I also love how much home assistant can do (for FREE!) and how many advanced features can now be done through the UI versus a few months ago.

I probably made at least 10 factual and spelling errors throughout this essay of a forum post and probably missed a tool or something to make at least one of my issues much better or even completely solved. This also probably could even be three separate feature requests or may even be considered a duplicate of this post (which you should see for more discussion):

I think the purpose of that post was a little different (trying to stop the implementation of this new feature instead of improving it.)

Thanks community, dev team, and everyone who maintains the forum, website, and everything else related to this amazing software :heart:
Let me know anything I messed up so I can improve for next time.

I agree this would make things easier in various places. The function would not fix the fact it won’t trigger on forecast changes. Luckily, these will probably not change very quickly.

1 Like