How to Set Up Tornado Warning Alerts in Home Assistant

Start with the source, not the siren effect. A Home Assistant tornado-warning automation is only as useful as the thing that tells it a warning exists. If that source polls slowly, watches the wrong geography, or exposes alerts in a shape your template barely understands, the rest of the setup can look perfect and still fire late, fire noisily, or not fire at all.

For tornado-warning smart home alerts, the practical Home Assistant choice is the nws_alerts HACS component: it is alert-first, zone-aware, and designed to expose active National Weather Service alert details to automations. It should still sit on top of Wireless Emergency Alerts on phones and a NOAA Weather Radio. Home Assistant can make the house harder to ignore; it is not the primary life-safety channel.

Choose the alert source before writing the automation

The four common routes look similar only after the alert has arrived. Before that, they are very different plumbing.

That last judgment is not an IFTTT-bashing exercise. It is a timing judgment. Tornado warnings are not the place to ask a free hourly poller to be the first thing in the chain. If IFTTT is in the stack at all, it belongs behind WEA, NOAA Weather Radio, and a faster local automation path.

The built-in NWS integration has a different problem. It is official, documented, and useful, but the documented shape is a weather integration: API key string, optional METAR station, weather entity, cloud polling, and disabled-by-default sensors. That is not the same as an alert-first sensor whose state and attributes are meant to answer “what active warning applies to my location right now?”

Find the NWS area you actually want to watch

Do not point the automation at a vague city name if the integration supports the official NWS geometry. Use the zone or county identifier that matches your home, or use GPS/device_tracker targeting where the component supports it. The nws_alerts README lists zone ID, county ID, GPS coordinates, and device_tracker targeting methods. Zone and county identifiers look like INZ009 or INC033, depending on whether you are using a forecast zone or county-style code. [1]

• For a fixed house, prefer the exact NWS zone or county code you intend to protect.
• For a mobile household member, device_tracker targeting can make sense, but it adds dependency on location updates.
• For testing, keep your production location separate from any temporary test location so you do not leave the home pointed at the wrong county after a successful experiment.

This is also where you decide how narrow the automation should be. The recipe below filters for Tornado Warning as the event. A tornado watch, severe thunderstorm warning, flood warning, or winter alert should not flash the whole house unless you deliberately add those events.

Configure nws_alerts as the trigger sensor

Install and configure the nws_alerts custom component through HACS, then confirm the entity name and attributes in Home Assistant Developer Tools. The important behavior to verify is simple: the sensor state represents the number of active alerts, and the attributes contain the active alert details your automation can inspect. [1]

If your installed version exposes the NWSCode filtering added in release 6.6, use it to narrow the sensor toward tornado-related alerts before the automation sees them. Keep the automation-side Tornado Warning condition anyway. Sensor-level filtering reduces noise; automation-level filtering protects the action path if the sensor later exposes more than you expected. [1]

Home Assistant automation: tornado warning only, then lights, speakers, and phones

Create a light group for the fixtures you are willing to flash at night, and use explicit notification targets. Do not start with every bulb in the house. A hallway, bedroom lamp, kitchen light, or dedicated alert lamp is easier to restore and less likely to punish the household during a test.

The automation below watches a configured nws_alerts sensor, requires the active-alert count to be above zero, and then searches the active alert attributes for the exact event text “Tornado Warning.” It does not match Tornado Watch. Replace the entity IDs and notification services with your own.

# NestGrid metadata:
# Source: nws_alerts HACS sensor attributes plus Home Assistant local actions
# Status: Confirmed for nws_alerts state/attribute behavior; Workaround for light restore using a temporary scene
# Version/date: nws_alerts README current as cited; light-restore caution informed by HA Community blueprint thread, Nov 2024
# Confidence: High for the trigger/filter pattern; medium for restore behavior across all light integrations

alias: Tornado Warning - House Alert
id: tornado_warning_house_alert
mode: single

trigger:
  - platform: state
    entity_id: sensor.nws_alerts

condition:
  - condition: template
    alias: Sensor has at least one active alert
    value_template: >
      {{ trigger.to_state is not none and (trigger.to_state.state | int(0)) > 0 }}

  - condition: template
    alias: Active alert attributes include Tornado Warning
    value_template: >
      {% set alert_blob = trigger.to_state.attributes | to_json %}
      {{ 'Tornado Warning' in alert_blob }}

action:
  - variables:
      alert_headline: >
        {{ trigger.to_state.attributes.get('headline',
           'Tornado Warning issued for your configured NWS area.') }}
      alert_message: >
        Tornado Warning for your configured NWS area. Take shelter now.

  - service: scene.create
    data:
      scene_id: before_tornado_warning_alert
      snapshot_entities:
        - light.bedroom_lamp
        - light.hallway
        - light.kitchen

  - repeat:
      count: 8
      sequence:
        - service: light.turn_on
          target:
            entity_id:
              - light.bedroom_lamp
              - light.hallway
              - light.kitchen
          data:
            brightness_pct: 100
        - delay: "00:00:01"
        - service: light.turn_off
          target:
            entity_id:
              - light.bedroom_lamp
              - light.hallway
              - light.kitchen
        - delay: "00:00:01"

  - service: scene.turn_on
    target:
      entity_id: scene.before_tornado_warning_alert

  - service: tts.speak
    target:
      entity_id: tts.home_assistant_cloud
    data:
      media_player_entity_id:
        - media_player.kitchen_speaker
        - media_player.bedroom_speaker
      message: "{{ alert_message }}"

  - service: notify.mobile_app_your_phone
    data:
      title: "Tornado Warning"
      message: "{{ alert_headline }}"
      data:
        push:
          sound:
            name: default
            critical: 1
            volume: 1.0

  - service: notify.mobile_app_second_phone
    data:
      title: "Tornado Warning"
      message: "{{ alert_headline }}"

The scene snapshot is there because blinking-light automations can be surprisingly rude. A maintained Home Assistant blinking-lights blueprint exists and is useful, but community discussion around that blueprint includes restore quirks, especially around lights that were initially off. Treat restore behavior as something to test with your exact bulbs and integrations, not as a solved property of all lighting stacks. [6]

If you already have a reliable flashing blueprint, script, or alert-light package, you can replace the light section with a script call. Keep the filter in front of it. The expensive part of a bad tornado automation is not the YAML style; it is the wrong event making the whole house panic.

Make the filter stricter if your attributes are structured

The broad attribute search above is intentionally tolerant because users may see different attribute shapes after installation or version changes. If your nws_alerts entity exposes an alerts list with an event field, use that instead. It is cleaner because it matches the event field rather than any text in the alert blob.

# NestGrid metadata:
# Source: nws_alerts active alert details exposed as attributes
# Status: Confirmed for the existence of alert attributes; local adaptation required for your exact attribute names
# Version/date: nws_alerts README current as cited
# Confidence: Medium until verified in Developer Tools on your installation

condition:
  - condition: template
    alias: At least one structured alert is exactly a Tornado Warning
    value_template: >
      {% set alerts = state_attr('sensor.nws_alerts', 'alerts') or [] %}
      {{ alerts | selectattr('event', 'eq', 'Tornado Warning') | list | count > 0 }}

Only use that stricter version after you have confirmed the attribute is really named alerts and the event key is really event in Developer Tools. If either name differs, the template will quietly evaluate to false and your lights will stay polite at the worst possible time.

Raw REST is viable, but it is fussy plumbing

A raw REST sensor is a legitimate workaround if you do not want HACS or need to inspect the NWS API response directly. The community pattern uses api.weather.gov/alerts/active?zone=... with a 5-minute scan interval, stores features as attributes, and then builds templates or notifications from those attributes. The same community example calls out the need for a proper User-Agent header with an app name and contact email so the request is not treated as anonymous scraping. [3]

# NestGrid metadata:
# Source: Home Assistant Community raw api.weather.gov REST pattern
# Status: Workaround
# Version/date: Community thread, Aug 2024
# Confidence: Medium; depends on NWS response shape, zone choice, and template hardening

sensor:
  - platform: rest
    name: NWS Active Alerts Raw
    resource: https://api.weather.gov/alerts/active?zone=INZ009
    scan_interval: 300
    headers:
      User-Agent: "YourHomeAssistantWeatherAlert/1.0 [email protected]"
      Accept: "application/geo+json"
    value_template: >
      {% if value_json is defined and value_json.features is defined %}
        {{ value_json.features | length }}
      {% else %}
        0
      {% endif %}
    json_attributes:
      - features

template:
  - binary_sensor:
      - name: NWS Tornado Warning Active
        unique_id: nws_tornado_warning_active
        state: >
          {% set features = state_attr('sensor.nws_active_alerts_raw', 'features') or [] %}
          {{ features | selectattr('properties.event', 'eq', 'Tornado Warning') | list | count > 0 }}
        attributes:
          headline: >
            {% set features = state_attr('sensor.nws_active_alerts_raw', 'features') or [] %}
            {% set matches = features | selectattr('properties.event', 'eq', 'Tornado Warning') | list %}
            {% if matches | count > 0 %}
              {{ matches[0].properties.headline }}
            {% else %}
              none
            {% endif %}

The defensive parts matter. The template uses “or []” so a missing features attribute does not become a fatal None-value problem. It checks the match count before reading matches[0], because indexing an empty list is the kind of failure that only shows up when the alert path is already under stress.

Once that binary sensor exists, the earlier automation can trigger from binary_sensor.nws_tornado_warning_active changing to on instead of directly inspecting sensor.nws_alerts. The trade-off is the 5-minute scan interval and more template ownership. That is acceptable for some power users; it is not cleaner than using an alert-focused integration.

Hubitat users get a useful comparison path

Hubitat’s NOAA Weather Alerts community app is worth studying even if Home Assistant is the main build here. The app thread covers event-specific tornado watch/warning selection, severity/urgency/certainty settings, TTS targets through Music Player, Echo Speaks, and Google devices, repeat behavior, and test alerts. It also includes a maintainer warning that selecting ALL options can cause false or NULL API responses. [5]

That warning translates directly to Home Assistant thinking: do not select everything just because the UI allows it. A tornado-warning automation should know which event it is waiting for. Broad subscriptions are fine for dashboards and logs; they are a bad default for lights, speakers, and phones at 2 a.m.

For mainstream speaker behavior, keep this recipe layered with the broader NestGrid guides to tornado warning smart home setup, speaker-native weather alerts, Google Nest severe-weather workarounds, and smart-light flashing across platforms. Keep the center here on the Home Assistant alert-source and tornado-only automation path.

Test the path without waiting for a local tornado warning

A tornado automation that has never seen an alert is just a diagram. Test both halves: first the local actions, then the data-source path.

First test the outputs

Temporarily duplicate the automation, remove the tornado condition, and trigger it manually from Home Assistant. Confirm the lights flash, the snapshot restore is acceptable, every speaker you named actually speaks, and every phone receives the push. Then delete the duplicate. Manual action testing does not prove the NWS path works, but it catches bad entity IDs and bad household choices without involving weather data.

Then test the source and filter path with an active-alert location

Use api.weather.gov/alerts/active/count to find a location that currently has any active alert, then point a temporary test sensor at that location. This is not a claim that your home has a tornado warning; it is a way to prove your polling, attributes, and event filter can see a real NWS active alert object. [7]

1. Open api.weather.gov/alerts/active/count and identify a zone or county that currently has active alerts. [7]
2. Create a temporary nws_alerts configuration or temporary REST sensor for that active-alert location. Do not overwrite your production home configuration.
3. Inspect the resulting entity in Developer Tools. Confirm the state changes above zero and the attributes contain the event name, headline, or feature data your templates expect.
4. For this temporary test only, change the event string from Tornado Warning to the active event you found. Run the test and confirm the automation path fires.
5. Restore the production zone/county and restore the exact Tornado Warning filter before leaving the system armed.

If the test sensor sees the active alert but the automation does not fire, the problem is probably your template. If the sensor never sees the active alert, the problem is probably the target code, request headers, polling configuration, or component setup. That distinction is the whole reason to test with a real active alert object instead of only pressing “Run actions.”

Where this setup stops being responsible

A Home Assistant layer can make a tornado warning harder to miss: lights blink, speakers announce, and phones buzz. It cannot guarantee that the NWS alert has been issued at the moment you expect, that api.weather.gov is reachable from your network, that your Home Assistant box has power, that Wi-Fi is up, that every speaker is available, or that a phone notification breaks through its current state.

Keep phone WEA enabled. Keep a NOAA Weather Radio where it can wake people. If the Home Assistant server is part of your emergency stack, also understand its power-outage and offline behavior. The automation is the house reacting physically to information; it is not the authority that makes the warning real.

References

1. nws_alerts, GitHub
2. National Weather Service (NWS), Home Assistant
3. NWS.weather.gov Custom Alert Pushes, Home Assistant Community, Aug 2024
4. Get NOAA Weather Alerts via IFTTT notifications, IFTTT
5. [RELEASE] NOAA Weather Alerts, Hubitat Community
6. Custom Blinking Lights Blueprint, Home Assistant Community, Nov 2024
7. api.weather.gov/alerts/active/count, api.weather.gov