AI assistance is a home assistant coding game changer

Share your Projects!
1

While I’m certainly not the first to notice this, I just wanted to share my experience recently using AI to finally assemble some of the complex automation ideas that have been floating around in my head but that I did not have the YAML or Jinga skills to create without significant homework and trial and error. I started with ChatGPT and moved to Claude-ai - which I think is better at it on the free level, because it doesn’t forget what you said 5 questions ago. I’m pretty comfortable with complex UI automations and scripts, but this has really opened up the power of templates, packages and sensors for me.

As with all things AI, they key is in how you talk to it, and I’ve learned a few helpful things that others may find useful. First, spend some time to write (and save) a very detailed and personalized prompt. The AI can actually help you develop that too if you ask it what it needs to know. Mine starts with: “I’m developing advanced home automation features and need assistance with device selection, automation logic, and code generation. Please help me establish the context for ongoing discussions about my smart home setup.” I then describe in broad detail my devices, hubs, brands, general approach to automation, existing services/automations, how I’ve structured my config.yaml file, and what my expectations are for generated code (my HA and hubitat versions, check against recent updates and changes, etc). I use this stock prompt to start every new conversation for a new project (since it tends to use up the free tokens for a given chat quickly). After that, it’s relatively easy to input the needs of the current project and get useful output with minimal need for correction and clarification.

I moved to this approach after some painful back and forth with chatGPT and numerous errors on my first attempt at using AI help.

This is far from having the AI think for you, since I found I needed to figure out very clearly spelled out asks in order to get something that works. I have used it to explore general ideas (like, what are the different approaches to integrate my 3 zone HVAC system into a home with lots of south facing windows, automated blinds, weather forecast services and in yard weather station in order to have my blinds and HVAC settings adjust automatically to account for current and anticipated weather conditions). However, once embarking on the details I’ve found it best to plan the overall final approach myself, so that I can follow the logic for troubleshooting and tweaking. I’ll then have the AI figure out how to work out many of the details by breaking it down into smaller, specific asks.

Some examples in my case:

I needed to extract hourly variables from my weather forecast service (like hourly temp, rainfall, conditions) to use in automation rules. In browsing the forums I knew it was possible, but that the code requirements had changed in the last couple years and there were a ton of threads with people working out the details of how to get it to work, with old broken code. I fed Claude my setup, the attributes of my weather service, told it the output sensors I wanted. It didn’t work initially. I then pointed it towards a few recent (very long) forum discussions on what was and wasn’t working recently and asked it to revise based on that information. Bam- fully functioning list of 2 dozen template sensors that worked after a copy and paste. Even if I figured out myself exactly how to do that with a lot of reading, it would have taken forever to write the code.

I’ve gotten better at the prompting, so I’ll share my most recent example that went very smoothly.

Here was my prompt:

That worked.
New project.
Using a similar approach in a new package, I would like to generate some template sensors that extract the current modes and setpoints on my Lennox thermostat. I will need a group of sensors for each of three zones. The data is currently available in 3 different thermostat devices (representing the 3 zones) in the Lennox integration. They are labeled:
system_2nd_floor
system_main_floor
system_basement

I would like to extract sensors for each zone that display the current setting for each of the attributes listed below. Beside each I have written the sample format of the output sensor to create. Modify the labels for each zone as appropriate:
hvac mode: lennox_mainfloor_system_mode
hvac action: lennox_mainfloor_action
Fan mode: lennox_mainfloor_fanmode
current fan state (on or off): lennox_mainfloor_fanstate
current preset mode: lennox_mainfloor_preset
target temp high: lennox_mainfloor_cool_below_setpoint
target temp low: lennox_mainfloor_heat_above_setpoint

Default to unavailable if data cannot be pulled.

For context, below is the sample attributes file as found in developer tools for the entity climate.system_main_floor

hvac_modes:
  - "off"
  - cool
  - heat
  - heat_cool
min_temp: 4.5
max_temp: 37
target_temp_step: 0.5
min_humidity: 15
max_humidity: 45
fan_modes:
  - auto
  - "on"
  - circulate
preset_modes:
  - schedule IQ
  - summer
  - winter
  - spring/fall
  - save energy
  - away
  - cancel hold
  - cancel away mode
  - schedule hold
  - none
current_temperature: 22.5
target_temp_high: 22.5
target_temp_low: 19
current_humidity: 37
humidity: 20
fan_mode: circulate
hvac_action: idle
preset_mode: none
allergenDefender: false
damper: 0
demand: 0
fan: "off"
humidityMode: humidify
humOperation: "off"
tempOperation: "off"
ventilation: false
heatCoast: false
defrost: false
balancePoint: none
aux: false
coolCoast: false
ssr: false
zoneEnabled: true
zoningMode: zoned
friendly_name: System_main floor
supported_features: 158

10 seconds after hitting enter, it spit out a completely functional package I could copy and paste into my packages directory:

# Lennox Thermostat Sensors Package
# Extracts current modes and setpoints from Lennox thermostat integration

sensor:
  # Main Floor Zone Sensors
  - platform: template
    sensors:
      lennox_mainfloor_system_mode:
        unique_id: lennox_mainfloor_system_mode_sensor
        friendly_name: "Lennox Main Floor System Mode"
        value_template: >
          {% if states('climate.system_main_floor') not in ['unavailable', 'unknown'] %}
            {{ state_attr('climate.system_main_floor', 'hvac_mode') }}
          {% else %}
            unavailable
          {% endif %}
        icon_template: mdi:thermostat
        
      lennox_mainfloor_action:
        unique_id: lennox_mainfloor_action_sensor
        friendly_name: "Lennox Main Floor Action"
        value_template: >
          {% if states('climate.system_main_floor') not in ['unavailable', 'unknown'] %}
            {{ state_attr('climate.system_main_floor', 'hvac_action') }}
          {% else %}
            unavailable
          {% endif %}
        icon_template: mdi:thermostat-auto
        
      lennox_mainfloor_fanmode:
        unique_id: lennox_mainfloor_fanmode_sensor
        friendly_name: "Lennox Main Floor Fan Mode"
        value_template: >
          {% if states('climate.system_main_floor') not in ['unavailable', 'unknown'] %}
            {{ state_attr('climate.system_main_floor', 'fan_mode') }}
          {% else %}
            unavailable
          {% endif %}
        icon_template: mdi:fan
        
      lennox_mainfloor_fanstate:
        unique_id: lennox_mainfloor_fanstate_sensor
        friendly_name: "Lennox Main Floor Fan State"
        value_template: >
          {% if states('climate.system_main_floor') not in ['unavailable', 'unknown'] %}
            {{ state_attr('climate.system_main_floor', 'fan') }}
          {% else %}
            unavailable
          {% endif %}
        icon_template: mdi:fan
        
      lennox_mainfloor_preset:
        unique_id: lennox_mainfloor_preset_sensor
        friendly_name: "Lennox Main Floor Preset"
        value_template: >
          {% if states('climate.system_main_floor') not in ['unavailable', 'unknown'] %}
            {{ state_attr('climate.system_main_floor', 'preset_mode') }}
          {% else %}
            unavailable
          {% endif %}
        icon_template: mdi:calendar-clock
        
      lennox_mainfloor_cool_below_setpoint:
        unique_id: lennox_mainfloor_cool_below_setpoint_sensor
        friendly_name: "Lennox Main Floor Cool Below Setpoint"
        value_template: >
          {% if states('climate.system_main_floor') not in ['unavailable', 'unknown'] %}
            {{ state_attr('climate.system_main_floor', 'target_temp_high') }}
          {% else %}
            unavailable
          {% endif %}
        unit_of_measurement: "°C"
        device_class: temperature
        icon_template: mdi:thermometer-chevron-down
        
      lennox_mainfloor_heat_above_setpoint:
        unique_id: lennox_mainfloor_heat_above_setpoint_sensor
        friendly_name: "Lennox Main Floor Heat Above Setpoint"
        value_template: >
          {% if states('climate.system_main_floor') not in ['unavailable', 'unknown'] %}
            {{ state_attr('climate.system_main_floor', 'target_temp_low') }}
          {% else %}
            unavailable
          {% endif %}
        unit_of_measurement: "°C"
        device_class: temperature
        icon_template: mdi:thermometer-chevron-up

  # 2nd Floor Zone Sensors
      lennox_2ndfloor_system_mode:
        unique_id: lennox_2ndfloor_system_mode_sensor
        friendly_name: "Lennox 2nd Floor System Mode"
        value_template: >
          {% if states('climate.system_2nd_floor') not in ['unavailable', 'unknown'] %}
            {{ state_attr('climate.system_2nd_floor', 'hvac_mode') }}
          {% else %}
            unavailable
          {% endif %}
        icon_template: mdi:thermostat
        
      lennox_2ndfloor_action:
        unique_id: lennox_2ndfloor_action_sensor
        friendly_name: "Lennox 2nd Floor Action"
        value_template: >
          {% if states('climate.system_2nd_floor') not in ['unavailable', 'unknown'] %}
            {{ state_attr('climate.system_2nd_floor', 'hvac_action') }}
          {% else %}
            unavailable
          {% endif %}
        icon_template: mdi:thermostat-auto
        
      lennox_2ndfloor_fanmode:
        unique_id: lennox_2ndfloor_fanmode_sensor
        friendly_name: "Lennox 2nd Floor Fan Mode"
        value_template: >
          {% if states('climate.system_2nd_floor') not in ['unavailable', 'unknown'] %}
            {{ state_attr('climate.system_2nd_floor', 'fan_mode') }}
          {% else %}
            unavailable
          {% endif %}
        icon_template: mdi:fan
        
      lennox_2ndfloor_fanstate:
        unique_id: lennox_2ndfloor_fanstate_sensor
        friendly_name: "Lennox 2nd Floor Fan State"
        value_template: >
          {% if states('climate.system_2nd_floor') not in ['unavailable', 'unknown'] %}
            {{ state_attr('climate.system_2nd_floor', 'fan') }}
          {% else %}
            unavailable
          {% endif %}
        icon_template: mdi:fan
        
      lennox_2ndfloor_preset:
        unique_id: lennox_2ndfloor_preset_sensor
        friendly_name: "Lennox 2nd Floor Preset"
        value_template: >
          {% if states('climate.system_2nd_floor') not in ['unavailable', 'unknown'] %}
            {{ state_attr('climate.system_2nd_floor', 'preset_mode') }}
          {% else %}
            unavailable
          {% endif %}
        icon_template: mdi:calendar-clock
        
      lennox_2ndfloor_cool_below_setpoint:
        unique_id: lennox_2ndfloor_cool_below_setpoint_sensor
        friendly_name: "Lennox 2nd Floor Cool Below Setpoint"
        value_template: >
          {% if states('climate.system_2nd_floor') not in ['unavailable', 'unknown'] %}
            {{ state_attr('climate.system_2nd_floor', 'target_temp_high') }}
          {% else %}
            unavailable
          {% endif %}
        unit_of_measurement: "°C"
        device_class: temperature
        icon_template: mdi:thermometer-chevron-down
        
      lennox_2ndfloor_heat_above_setpoint:
        unique_id: lennox_2ndfloor_heat_above_setpoint_sensor
        friendly_name: "Lennox 2nd Floor Heat Above Setpoint"
        value_template: >
          {% if states('climate.system_2nd_floor') not in ['unavailable', 'unknown'] %}
            {{ state_attr('climate.system_2nd_floor', 'target_temp_low') }}
          {% else %}
            unavailable
          {% endif %}
        unit_of_measurement: "°C"
        device_class: temperature
        icon_template: mdi:thermometer-chevron-up

  # Basement Zone Sensors
      lennox_basement_system_mode:
        unique_id: lennox_basement_system_mode_sensor
        friendly_name: "Lennox Basement System Mode"
        value_template: >
          {% if states('climate.system_basement') not in ['unavailable', 'unknown'] %}
            {{ state_attr('climate.system_basement', 'hvac_mode') }}
          {% else %}
            unavailable
          {% endif %}
        icon_template: mdi:thermostat
        
      lennox_basement_action:
        unique_id: lennox_basement_action_sensor
        friendly_name: "Lennox Basement Action"
        value_template: >
          {% if states('climate.system_basement') not in ['unavailable', 'unknown'] %}
            {{ state_attr('climate.system_basement', 'hvac_action') }}
          {% else %}
            unavailable
          {% endif %}
        icon_template: mdi:thermostat-auto
        
      lennox_basement_fanmode:
        unique_id: lennox_basement_fanmode_sensor
        friendly_name: "Lennox Basement Fan Mode"
        value_template: >
          {% if states('climate.system_basement') not in ['unavailable', 'unknown'] %}
            {{ state_attr('climate.system_basement', 'fan_mode') }}
          {% else %}
            unavailable
          {% endif %}
        icon_template: mdi:fan
        
      lennox_basement_fanstate:
        unique_id: lennox_basement_fanstate_sensor
        friendly_name: "Lennox Basement Fan State"
        value_template: >
          {% if states('climate.system_basement') not in ['unavailable', 'unknown'] %}
            {{ state_attr('climate.system_basement', 'fan') }}
          {% else %}
            unavailable
          {% endif %}
        icon_template: mdi:fan
        
      lennox_basement_preset:
        unique_id: lennox_basement_preset_sensor
        friendly_name: "Lennox Basement Preset"
        value_template: >
          {% if states('climate.system_basement') not in ['unavailable', 'unknown'] %}
            {{ state_attr('climate.system_basement', 'preset_mode') }}
          {% else %}
            unavailable
          {% endif %}
        icon_template: mdi:calendar-clock
        
      lennox_basement_cool_below_setpoint:
        unique_id: lennox_basement_cool_below_setpoint_sensor
        friendly_name: "Lennox Basement Cool Below Setpoint"
        value_template: >
          {% if states('climate.system_basement') not in ['unavailable', 'unknown'] %}
            {{ state_attr('climate.system_basement', 'target_temp_high') }}
          {% else %}
            unavailable
          {% endif %}
        unit_of_measurement: "°C"
        device_class: temperature
        icon_template: mdi:thermometer-chevron-down
        
      lennox_basement_heat_above_setpoint:
        unique_id: lennox_basement_heat_above_setpoint_sensor
        friendly_name: "Lennox Basement Heat Above Setpoint"
        value_template: >
          {% if states('climate.system_basement') not in ['unavailable', 'unknown'] %}
            {{ state_attr('climate.system_basement', 'target_temp_low') }}
          {% else %}
            unavailable
          {% endif %}
        unit_of_measurement: "°C"
        device_class: temperature
        icon_template: mdi:thermometer-chevron-up

I’ve really been enjoying this process and excited about what it opens up. By reading what is generated (and yes at times doing a lot of error troubleshooting with the AI), I feel I’m also getting a much better grasp of using the code myself, and finding where problems might lie. It is definitely a faster way to code, but you still need to put in the mental effort and time upfront to frame exactly what you need, and your own smart home context to make it work in.

Overall I’m a bit of a skeptic about AI hype, but I watched a few videos about how to use it and how not to use it, and applying those principles has made a huge difference in getting my complex automations off the ground. Hope someone else finds this helpful!

1 Like
2

With one major flaw.

It is using the legacy template sensor platform instead of the new template integration. Only the new integration is getting updated and support for new features. e.g. try adding a state_class to those sensors and see what happens.

Rather than relying on LLMs trained on outdated data try putting as much effort into reading the documentation and asking relevant questions of the very helpful volunteers on this very forum. You will end up actually understanding what you are doing rather than relying on a broken crutch.

Or if you prefer to go through life not understanding anything just keep doing what you are doing but do not use LLMs to help others on this forum or you will be banned: Want to help others? Leave your AI at the door - Home Assistant

6 Likes
3

Well, thanks for the tips, the link to the guideline and for veiling some of the hostility. :slight_smile:

I’m well aware you can’t recognize an error that you don’t know about and that’s the biggest downfall of over-reliance on AI. Lord knows in my own field of expertise I spend most of my time telling other people what they don’t actually understand. However, moving forward in the complexity of home assistant is a daunting endeavor for someone doing it as a hobby. I have spent days of my life reading online forums and documentation on countless technical things (like this and others) I have dabbled in over the years. On this forum, like many other systems in constant evolution, the greatest challenge is that there is so much persistently available outdated information it is hard to wade through and know if you’re reading the stuff that is most up to date, especially looking into niche questions. Ironically I suppose that’s the same reason the AI fails here…

I also don’t like to bug people with questions if I can find the answers, and many support forums are full of RTFM advice when one does. That said I’ve largely found people helpful here when I have reached out.

But if this is also an offer to help, I’m happy to be pointed towards the most up to date documentation that addresses the difference between the old and new templating format and will help me specifically identify what is outdated in this code. I started this endeavor reading about templates once I realized that’s how to make variables from existing entities, but found it very difficult to wrap my brain around what they were actually doing or when I should even be using one. I think I have some grasp now from trial and error (with and without AI), so maybe I’ll be better able to digest the changes.

4

i use this chatGPT for homeassistant and is a game changer, the only need to do before is tell him what HAOS are you using , i was using node-red before , but with this ChatGPT is been so easy to make an automation with just a few ideas , i dont recomend copy and paste but is a great tool to understand YAML , for you to make you own

1 Like
5

Old: https://www.home-assistant.io/integrations/template/#legacy-sensor-configuration-format

New: https://www.home-assistant.io/integrations/template/

2 Likes
6

Thanks very much. I will have a read through to see that I’m grasping what I’m building, although since I can’t do this full time I’ll still rely on helpful shortcuts, and learn while doing and observing the result. Thanks to the community for providing the expert oversight- I won’t pretend I have it where I don’t.

This format seems to be working as well and looks to fit the modern integration.

template:
  # Main Floor Zone Sensors
  - sensor:
      - name: "Lennox Main Floor System Mode"
        unique_id: lennox_mainfloor_system_mode_sensor
        state: >
          {% if states('climate.system_main_floor') not in ['unavailable', 'unknown'] %}
            {{ state_attr('climate.system_main_floor', 'hvac_mode') }}
          {% else %}
            unavailable
          {% endif %}
        icon: mdi:thermostat
        
      - name: "Lennox Main Floor Action"
        unique_id: lennox_mainfloor_action_sensor
        state: >
          {% if states('climate.system_main_floor') not in ['unavailable', 'unknown'] %}
            {{ state_attr('climate.system_main_floor', 'hvac_action') }}
          {% else %}
            unavailable
          {% endif %}
        icon: mdi:thermostat-auto
7

The construction you are using for the state template is kind of a bodge used for Template sensors created in the UI where there isn’t currently a way to define an availability.

Since you are setting these up in YAML, best practice is to use the availability configuration variable. This is especially true for sensors with a defined unit_of_measurement. Having the state template resolve to the string “unavailable” instead of using availability can cause the sensor to error.

template:
  # Main Floor Zone Sensors
  - sensor:
      - name: "Lennox Main Floor System Mode"
        unique_id: lennox_mainfloor_system_mode_sensor
        state: "{{ state_attr('climate.system_main_floor', 'hvac_mode') }}"
        availability: "{{ has_value('climate.system_main_floor') }}"
        icon: mdi:thermostat
2 Likes
8

This is the key point. If you don’t understand what you are doing, you can’t give AI the prompts it needs to produce viable results. It’s a tool, not a substitute for skills.

There are professional AI developers on the forum - have a look at this:

I believe their view is that AI is closer than you might think to being able to build stuff for HA, but it will need prompts pages - yes pages - long.

Sorry you felt that the forum response was (a bit) hostile. :grin:

It’s just that this comes up a lot, and it often ends in frustration and sometimes shouting matches.

2 Likes
9

Gott it in one Jack.

Pages and pages of context.

Honestly there’s a lot of value here for this kind of work. It’s probably what we will see as valid ai use for the near future.

If I lock an AI in on a description of how to create a valid trigger template sensor (using fez’s well known pattern.) I will - and have - absolutely used it to spin up three more with unique_id attached. (those things are a pain) but… I also know enough about a trigger text sensor to know if it’s BS or not.

Thats the problem. Most don’t and the folks who turn to an LLM first are also not the ones to catch a hallucination.

I have no problem using Ai. I do it hourly or more but. If you are going to post for others then call out where it can and will fail so others know where to watch out.

Im working on a super controller script (Cabinet CRUD, sounds cool huh) that turns a Fez style trigger text sensor basically into a disk drive for ai use. Yes I’m using Ai for the script it’s a beast but I’m not writing with it, I’m analyzing miniscule bits of code with the ai. Figuring out what’s wrong editing a line or two and using the ai to basically UAT my work fast. (note automated testing. This is the game changer. Small tiny commits with a quick rollback - you make amazing progress fast…)

But, Im not flinging a six word prompt to build NASA.

Friday’s party is a long rambler post because we learn more about these things every day.

For this problem. Yaml Gen… A one-shot model like gpt 4.0 or a light reasoner like 4.1 high would eat this job for lunch If… The grounding is sound. If not may the lord have mercy on your soul.

You MUST give it an example of what you want as output, describe the task very clearly and then an absolute metric ton of grounding (how to and how not to) build a script because most LLMs flat out forget HA jinja is NOT jinja. :). It’ll sneak python lambda in there every chance it gets and use outdated structures every time unless you specify otherwise.

Guess how many folk don’t.

1 Like
10

@DocNaes using availability like this (@Didgeridrew’s post) is critical for numerical sensors because outputting anything that isn’t numerical will cause errors.

You’ll also need to include state_class, device_class, and a proper unit_of_measurement for them to be considered a numerical entity for long term stats and proper history.

11

Thanks very much, I will revise the templates accordingly. This is certainly the depth and detail of the template formatting knowledge that currently escapes me, a lowly UI automator for the most part. :slight_smile: Appreciate the tips.

@petro thanks, and yes it did generate all 3 properties you mention for my numerical sensors, as well as in my revision of the forecast sensors.

Appreciate the input and insight from those of you doing this a lot longer than me. Having struggled through on my own for a couple weeks with a vague vision of what I was trying to do, I was excited at how much more progress I could quickly make when I finally decided to see if current AI iterations were of any help in figuring out what I needed to do and how to do it. Perhaps my share was over-hasty given the experience already present here, but it does feel like a personal breakthrough when you start to figure out how to properly prompt to get usable, time saving results without sending them back for error revisions over and over. And when errors such as these are identified it is much easier to go back and regenerate everything with the corrected parameters than to manually edit pages of sensors.

I hardly consider myself an early AI adopter, and remain well aware of it’s tendency to be over-confident and not recognize when it’s wrong, but I think it’s important to start to learn how to use it. Feels like working on my smart home is a low risk/ high return area to start feeling that out. I mean are we not here to find ways to have technology do things for us faster than we could do on our own? Like turn out the lights and check if the doors are all locked? If I abandoned smart home automation every time it didn’t work the way I expected I wouldn’t be in the hobby very long. I’m looking at learning how to properly use AI the same way.

I read something about a university prof approaching this by instead of banning LLM’s, having his students have one write an essay for them and then grade it themselves to see how many mistakes it made. I think that’s the right perspective for the learning direction of the future.

That said, I can understand the topic being sensitive for many reasons. The rapid enshitification of the internet thanks to engagement driven AI bots is a real problem- I can only imagine what it does to forum moderators.

12

I see state_class missing on all of them and you’re outputting non-numerical values to the state. Thats why I mentioned it.

1 Like
13

What state class do you use for string variables? I have a mix of those and numerical ones. Here are 2 samples with as near as I can tell the correct modern format:

      - name: "Lennox Main Floor System Mode"
        unique_id: lennox_mainfloor_system_mode_sensor
        state: "{{ state_attr('climate.system_main_floor', 'hvac_mode') }}"
        availability: "{{ has_value('climate.system_main_floor') }}"
        icon: mdi:thermostat

      - name: "Lennox Main Floor Cool Below Setpoint"
        unique_id: lennox_mainfloor_cool_below_setpoint_sensor
        state: "{{ state_attr('climate.system_main_floor', 'target_temp_high') }}"
        availability: "{{ has_value('climate.system_main_floor') }}"
        unit_of_measurement: "°C"
        device_class: temperature
        state_class: measurement
        icon: mdi:thermometer-chevron-down

Cheers.

14

state class and device_class are only for numerical sensors.

2 Likes
15

Thanks. While I’m here I might as well ask about the format of my weather forecast sensor extraction package. Again it’s working and I’ve updated the output sensors as per the advice on this page, but I still have code errors returned in my template trigger. I feel like the approach is not ideal and probably also outdated, although I’ve had a tough time wrapping my head around the current recommended forecast service extraction technique, and tried several others that failed.

I think the hourly and daily forecast sensor creation method is correct, and the trigger section is calling up the forecast every hour to update it, but that it could be better implemented. I’ll just paste the trigger section and the code of the first hourly output sensor.

I’ve got a handful of legacy syntax errors as well as a string match one on the trigger entity ID.

# Template sensor that fetches and stores forecast data
template:
  - trigger:
      - platform: state
        entity_id: weather.mycity_forecast
      - platform: homeassistant
        event: start
      - platform: time_pattern
        hours: "/1"
    action:
      - service: weather.get_forecasts
        target:
          entity_id: weather.mycity_forecast
        data:
          type: hourly
        response_variable: hourly_data
      - service: weather.get_forecasts
        target:
          entity_id: weather.mycity_forecast
        data:
          type: daily
        response_variable: daily_data
    sensor:
      - name: "Hourly Weather Forecast"
        unique_id: hourly_weather_forecast
        state: "{{ now().isoformat() }}"
        attributes:
          forecast: "{{ hourly_data['weather.mycity_forecast'].forecast }}"
          last_updated: "{{ now().strftime('%Y-%m-%d %H:%M:%S') }}"
      - name: "Daily Weather Forecast"
        unique_id: daily_weather_forecast
        state: "{{ now().isoformat() }}"
        attributes:
          forecast: "{{ daily_data['weather.mycity_forecast'].forecast }}"
          last_updated: "{{ now().strftime('%Y-%m-%d %H:%M:%S') }}"

  # Modern Template sensors that extract specific forecast values
  # Hourly Temperature Forecasts
  - sensor:
      - name: "Forecast Temperature 1H"
        unique_id: forecast_temperature_1h_sensor
        state: "{{ (state_attr('sensor.hourly_weather_forecast', 'forecast')[0].temperature | round(1)) if state_attr('sensor.hourly_weather_forecast', 'forecast') and state_attr('sensor.hourly_weather_forecast', 'forecast') | length > 0 else none }}"
        availability: "{{ has_value('sensor.hourly_weather_forecast') }}"
        unit_of_measurement: "°C"
        device_class: temperature
        state_class: measurement