Zigbee siren not responding to ZHA warning device warn service

Start with the compatibility gate: if the siren path is wrong, the automation is dead before it starts. This recipe depends on Home Assistant, HACS, the NWS Alerts custom integration, speakers that can accept TTS, and a siren that can be driven locally instead of hoping a cloud service stays awake during the storm [1][2][5].

• Home Assistant with HACS installed, because NWS Alerts is a custom integration, not core HA [1].
• A location source for the alert feed: NWS zone ID, county ID, or GPS coordinates from a device tracker entity [1].
• A compatible Zigbee siren path that exposes the IAS WD cluster for `zha.warning_device_warn`; Tuya-based sirens are a different path and do not behave like native ZHA sirens [2][5].
• Speakers for TTS announcement, whether that is Alexa, Google Home, or another media player that Home Assistant can address.
• Smart lights you are willing to blast red at 2 a.m. without arguing with anyone in the room.

How the chain works

The useful version is short and boring in the right way: an NWS Alert sensor detects a Tornado Warning, a template sensor filters out everything else and survives bad states, and the automation fires three outputs in sequence: red flashing lights, TTS on speakers, and a siren on a compatible Zigbee device [1][3]. The point is not drama; the point is to keep the weak links visible before the weather does it for you.

Install the NWS Alerts sensor

Install NWS Alerts through HACS, because this is a community-maintained integration and not a core Home Assistant feature [1]. It supports three ways to define location: a NWS zone ID, a county ID, or GPS coordinates pulled from a device tracker entity [1]. The practical upside is that the integration polls api.weather.gov every 60 seconds, which is fast enough for a local alert chain that you want to trust before the television graphic catches up [1].

• Use the location method that is easiest to maintain in your setup. Zone ID is usually the least annoying if you already know your warning area.
• Do not bury the sensor in a complex helper maze yet. Get the raw alert entity working first.
• If the sensor never updates, fix the feed before writing any automation. Broken source data only gives you a more elegant broken automation.

Template around the bad states

This is where people usually build something that looks fine until two warnings overlap. The community thread on NWS alerts shows the same failure pattern again and again: the sensor attributes can come back as an array when multiple alerts are active, and code that assumes a single dictionary quietly falls apart [3]. Add an `unavailable` guard too, because a weather sensor that is not healthy should not be treated as a real zero.

template:
  - binary_sensor:
      - name: NWS Tornado Warning Active
        unique_id: nws_tornado_warning_active
        state: >
          {% set alerts = state_attr('sensor.nws_alerts', 'alerts') %}
          {% if is_state('sensor.nws_alerts', 'unavailable') or alerts in [none, 'unknown', 'unavailable'] %}
            false
          {% else %}
            {% set items = [alerts] if alerts is mapping else alerts %}
            {{ items | selectattr('event', 'equalto', 'Tornado Warning') | list | count > 0 }}
          {% endif %}

Swap `sensor.nws_alerts` and the `alerts` attribute name if your entity is labeled differently. The logic is the part that matters: normalize the payload, filter only Tornado Warning, and make the state fail closed instead of pretending the feed is healthy when it is not.

Build the automation actions

Do the actions in the order that makes the room wake up correctly: lights first, speaker volume second, TTS third, siren last. The volume step matters because a TTS call into a zero-volume speaker is the kind of failure that looks like a success if nobody hears it. Use multiple speaker entities if you want whole-home coverage, but keep the control plane in Home Assistant instead of pushing the trigger logic out to a cloud assistant.

alias: Tornado Warning - Whole Home Alert
mode: single
trigger:
  - platform: state
    entity_id: binary_sensor.nws_tornado_warning_active
    to: 'on'
action:
  - service: light.turn_on
    target:
      entity_id: light.all_lights
    data:
      rgb_color: [255, 0, 0]
      brightness_pct: 100
      flash: long

  - service: media_player.volume_set
    target:
      entity_id:
        - media_player.living_room_speaker
        - media_player.kitchen_speaker
    data:
      volume_level: 0.8

  - service: tts.speak
    target:
      entity_id:
        - media_player.living_room_speaker
        - media_player.kitchen_speaker
    data:
      media_player_entity_id:
        - media_player.living_room_speaker
        - media_player.kitchen_speaker
      message: 'Tornado warning. Move to shelter now.'

  - service: zha.warning_device_warn
    target:
      entity_id: siren.basement_siren
    data:
      warning_type: emergency
      duration: 60
      strobe: true

The siren call above only works on a device that actually understands `zha.warning_device_warn`. The Home Assistant docs for that service are explicit about the warning action and its siren parameters, so the device choice matters more than the YAML around it [2].

Choose a siren path that can actually answer

Only sirens that expose the IAS WD cluster work natively with `zha.warning_device_warn`, which is why generic Zigbee siren shopping gets messy fast. Frient's SIRZB-110 has a Works with Home Assistant certification baseline, which is the cleanest proof point in the set [4]. Community reports also put Neo and Heiman HS2WD models in the same general lane when the cluster support is there, while Tuya-based sirens are a different path entirely and usually need Zigbee2MQTT plus a Tuya converter instead of the native ZHA warning service [5].

• Frient SIRZB-110: best baseline if you want the least guesswork [4].
• Neo and Heiman HS2WD: community-tested in the ZHA warning-device lane when the right cluster is exposed [5].
• Tuya outdoor sirens: do not assume native ZHA support; plan on Zigbee2MQTT and the relevant Tuya converter path [5].
• If the device cannot take the warning call locally, it is the wrong siren for this recipe.

Test it like it is not a drill

Run a safe test before you trust any of it at 2 a.m. Trigger the automation from a temporary test state or a controlled alert condition, then confirm that Tornado Warning is the only event that trips it, that the `unavailable` branch stays silent, and that a second overlapping alert does not collapse the template into `None` [3].

• Confirm the lights flash red across the groups you actually care about.
• Confirm speaker volume is raised before TTS, not after.
• Confirm the siren fires on the intended device and stops after the duration you set.
• Confirm watches and lower-severity alerts do not trigger the whole-home sequence.

Once that works, stop there. The result is a local, more resilient tornado alerting stack inside Home Assistant, not a life-safety certification. It still depends on upstream NWS data, Home Assistant, your network, device batteries, and power, and no consumer Zigbee siren turns that into a guarantee.

References

1. NWS Alerts — GitHub
2. zha.warning_device_warn — Home Assistant Docs
3. Severe Weather Alerts from the US National Weather Service — Home Assistant Community
4. frient joins Works with Home Assistant — Home Assistant Blog, Sep 2, 2025
5. Zigbee comparison of sirens — Home Assistant Community