Morning weather briefing

Some hardware links on this page are affiliate links. As an Amazon Associate I earn from qualifying purchases. We may earn a commission if you buy through them, at no extra cost to you. See the affiliate disclosure.

A weather card on a wall dashboard does not help when you are still in the other room deciding what to wear. This workflow builds a short forecast once in the morning — today’s high and low, rain chance, wind, in °C or °F — from whatever weather entity you already have, and pushes it to Companion. The same briefing can fire from an NFC tag or a dashboard helper if you want it again later. Link buttons can open a dashboard path or a forecast page you choose.

The weather entity, tag id, and URLs are blueprint inputs. Do not publish a home address, a latitude, or a tag id from a real sticker.

What problem it solves

You want one readable push at a set time, from the weather integration you already trust, with units that match how you think, and a way to pull the same text on demand without leaving a helper stuck on.

How it works

1. Triggers — a daily time (pack default 07:00), an optional tag trigger for one NFC id, and an optional input_boolean turning on. Any of the three runs the same sequence. Leave the tag and the helper empty if you only want the clock.
2. Helper resets first — if the boolean started the run, turn it off immediately so the dashboard control behaves like a button. Do this before the forecast call so a slow integration cannot leave the toggle on.
3. Forecast — weather.get_forecasts with type: daily and the response stored in a variable. The first forecast entry is “today” for the integrations that follow the current service (Met.no and the other core weather integrations). The blueprint does not scrape a website.
4. Fields — high (temperature), low (templow), rain chance (precipitation_probability), wind (wind_speed plus the entity’s wind_speed_unit). Condition text is included when the attribute exists. A missing key becomes “n/a” in the message; the automation does not fail the run.
5. Units — you pick °C or °F. The template reads the entity’s temperature_unit and converts only when the request differs from the native unit. A US setup that already reports °F stays °F; it is not converted and then converted back. Wind is left in the integration’s own unit and labeled.
6. Push — one Companion notification. Optional actions are URI buttons: an internal dashboard path, and an external forecast URL. Both are inputs. Blank means that button is omitted. An optional place label is text in the title only. It does not move the weather entity. A second city needs a second weather entity and a second automation.

The tag id in the blueprint is the id Home Assistant shows after you write the sticker in Companion (Settings → Tags). It is not a serial number printed on the sticker, and it does not belong in a published screenshot.

Hardware notes

• No new sensor required. A weather.* entity that supports weather.get_forecasts is the whole data source. Open Developer Tools → Actions, call the service on your entity with type: daily, and confirm temperature, templow, and precipitation_probability show up before you debug the blueprint.
• Companion. The push target. URI actions need Companion; a plain notify service still gets the text and skips buttons it does not understand.
• NFC. Optional. Writable NTAG215 stickers are the usual blank tags Companion can program. Metal surfaces block many of them. One tag id per automation instance.
• Helper. Optional input_boolean on a dashboard. The blueprint turns it off. You do not need a script in the middle.

Snippet

The pack ships a blueprint. Inputs replace the weather entity, the notify service, and any tag id:

trigger:
  - platform: time
    at: !input briefing_time
    id: clock
  - platform: tag
    tag_id: !input tag_id
    id: tag
  - platform: state
    entity_id: !input request_boolean
    to: "on"
    id: button

action:
  - if:
      - condition: trigger
        id: button
    then:
      - service: input_boolean.turn_off
        target:
          entity_id: !input request_boolean
  - service: weather.get_forecasts
    target:
      entity_id: !input weather_entity
    data:
      type: daily
    response_variable: wx
  - variables:
      day: "{{ wx[weather_entity]['forecast'][0] }}"
      native: "{{ state_attr(weather_entity, 'temperature_unit') }}"
      high: >
        {% set v = day.temperature %}
        {% if v is none %}n/a
        {% elif unit_choice == native %}{{ v | round(0) }}
        {% elif unit_choice == '°F' %}{{ (v * 1.8 + 32) | round(0) }}
        {% else %}{{ ((v - 32) * 5 / 9) | round(0) }}
        {% endif %}
      low: >
        {% set v = day.templow %}
        {% if v is none %}n/a
        {% elif unit_choice == native %}{{ v | round(0) }}
        {% elif unit_choice == '°F' %}{{ (v * 1.8 + 32) | round(0) }}
        {% else %}{{ ((v - 32) * 5 / 9) | round(0) }}
        {% endif %}
  - service: !input notify_service
    data:
      title: "{{ place_label or 'Forecast' }}"
      message: >
        High {{ high }}{{ unit_choice }} · low {{ low }}{{ unit_choice }}
        · rain {{ day.precipitation_probability | default('n/a') }}%
        · wind {{ day.wind_speed | default('n/a') }}
        {{ state_attr(weather_entity, 'wind_speed_unit') }}
      data:
        actions:
          - action: URI
            title: Dashboard
            uri: !input dashboard_path
          - action: URI
            title: Forecast
            uri: !input forecast_url

unit_choice, place_label, weather_entity, and the two URIs are inputs. Drop an action from the list when its URL input is blank — a URI of "" is not a useful button. The pack’s full template does that.

Setup outline

1. Confirm the weather entity returns a daily forecast from Developer Tools (step in Hardware notes). If forecast is empty, fix the integration before you import anything.
2. Optional: create the request boolean. Optional: write an NFC sticker in Companion and copy its tag id from Settings → Tags.
3. Import the blueprint. Fill the weather entity, notify service, time, unit, and whichever of tag, boolean, place label, and URLs you want.
4. Run the automation once from the UI. The phone should show high, low, a rain percent, and wind. Tap each URI button you configured.
5. Toggle the helper and confirm it snaps back off. Scan the tag and confirm a second push. Set the clock trigger to a minute from now if you want to see the unattended path the same day.

Troubleshooting

• Message is all n/a. weather.get_forecasts returned no daily entries, or the template read forecast.forecast from an older service shape. Call the service in Developer Tools and match the keys you actually get (temperature, templow, precipitation_probability, wind_speed).
• Temperatures look doubled (a hot day shown as 150). The integration is already in °F and the template converted again. The pack converts only when unit_choice differs from temperature_unit.
• Tag scan does nothing. The blueprint has a different id than Settings → Tags, or the sticker was written as a plain URL the phone opened in a browser. Re-write it from Companion.
• Helper stays on. The turn-off is after a failing forecast call, so the sequence aborted. Reset the boolean first, and use the default filters so a missing attribute does not stop the run.
• URI button missing. That input was blank, or the notify service is not Companion. The text still sends.
• Wrong city. The place label is a title string. The numbers come from the weather entity. Add another entity for another place; do not expect the label to change the forecast.

Credits

Based on the community blueprint Configurable Daily Weather Report. This write-up is an original overview of a morning (or on-demand) briefing that uses weather.get_forecasts, a single unit conversion, and phone link buttons.