Skip to main content
NestGrid logoNestGrid

Smart Home Earthquake Alert Automations You Can Set Up

No consumer hub receives ShakeAlert as a native trigger, so earthquake automations in 2026 come down to three source types: phone EEW apps, USGS/EMSC feed integrations, and the GeoShake network. Find the one that fits your hub and copy the ready-to-run recipes for Home Assistant, Google Home, Apple Home, and Smart Life/Tuya — with honest latency, false-alarm behavior, and verification status.

If you are building a smart home earthquake preparedness kit in 2026, the first limit is not the siren, the light bulb, or the smart plug. It is the trigger. No mainstream consumer hub gives you ShakeAlert as a native automation event, so the realistic choice is narrower than most diagrams make it look: phone early-warning apps, earthquake feed integrations, or a dedicated seismic device that exposes an automation entity.

That distinction matters in the hallway, not just in the app. A phone alert can be authoritative and still fail to turn on your stair lights. A USGS feed can be useful and still arrive on a polling schedule. A GeoShake entity can trigger a hub routine, but its latency and consensus behavior are vendor-published, not independently confirmed by NestGrid yet. Treat every recipe below as a response layer, not as a certified life-safety warning system.

Diagram of phone alerts, cloud earthquake feeds, and seismic sensor stations feeding a smart-home hub with lights, siren, camera, and plug actions

The 2026 trigger map: three paths, three ceilings

Before copying an automation, label the source. The same response action — lights on, siren, camera recording, heater off — means very different things depending on whether it came from a phone EEW alert, a five-minute feed poll, or a local seismic network confirmation.

Source pathWhat it can doWhat it cannot honestly claimBest use
Phone EEW apps: MyShake, Android Earthquake AlertsDeliver authoritative alerts to supported phones in covered areasDo not become native Home Assistant, Google Home, Apple Home, or Smart Life automation triggersHuman warning: drop, cover, hold on; wake the person, not the hub
USGS / EMSC feed integrationsExpose earthquake event data to Home Assistant or custom dashboardsShould not be described as early warning; Home Assistant’s USGS integration polls every 5 minutes [1]Awareness automations, post-event logging, non-critical notifications
GeoShake networkExposes a hub-triggerable earthquake state through supported integrationsVendor-reported behavior only; no NestGrid Confirmed status yetResponse automations: lights, siren, TTS, camera, selected power cutoff

If you are still shopping for hardware, keep the buying decision separate from the automation recipe. NestGrid’s earthquake safety smart-home device guide and home earthquake safety device guide are the better place for device planning. Here, the question is whether a signal can actually drive an automation.

Phone EEW apps: strongest warning source, weakest hub trigger

MyShake and Android Earthquake Alerts belong on the phone of anyone in their supported region. MyShake states that alerts are issued for magnitude 4.5 or larger earthquakes, that alerts often arrive seconds before shaking, and that users farther from the epicenter may receive more than 30 seconds of warning; its U.S. West Coast coverage is California, Oregon, and Washington [2]. Google describes Android Earthquake Alerts as an early-warning and detection system that can send alerts to Android users before shaking reaches them in supported areas [3].

For automation, the catch is brutal and simple: the alert lands on the phone. It does not appear as a native trigger in Google Home, Apple Home, Home Assistant, or Smart Life/Tuya. You can use the phone as the alerting device; you should not pretend the hub heard the same warning.

  • Status label: authoritative phone alert, not a native smart-home trigger.
  • Likely latency: designed for seconds-before-shaking warning where coverage and distance allow; no hub automation latency because no native hub trigger is available.
  • False-alarm behavior: governed by the phone alert system, not by your smart-home routine.
  • Best smart-home pairing: use it alongside separate hub automations, not as the invisible trigger for them.

A practical setup is mundane but worth doing: keep MyShake or Android alerts enabled on the phones that sleep near people, disable battery settings that silence emergency notifications, and test household notification volume. Then build hub-side response routines from one of the other two source paths. That is less elegant than a single flowchart, but it avoids the dangerous fiction that a phone-only warning automatically becomes a whole-home action.

Home Assistant: where feed awareness and early warning get confused

Home Assistant gives you the most room to build, and therefore the most room to mislabel the result. The native USGS Earthquake Hazards integration uses the geo_location platform, offers 20 feed types, supports minimum_magnitude and radius options, and updates by polling every 5 minutes [1]. That is useful context. It is not earthquake early warning.

Recipe A: USGS feed awareness notification

Use this when you want Home Assistant to tell the household that a nearby event has appeared in the USGS feed. Do not use it to make shaking-time decisions.

LabelValue
SourceHome Assistant USGS Earthquake Hazards integration
PlatformHome Assistant
Likely latencyPolling-based; the integration documents a 5-minute polling interval [1]
False-alarm behaviorFeed-driven awareness; not a local confirmation system
Verification statusDocumented integration behavior; recipe not NestGrid Confirmed
alias: Earthquake feed awareness - nearby USGS event
mode: single
trigger:
  - platform: event
    event_type: state_changed
condition:
  - condition: template
    value_template: >
      {{ trigger.event.data.entity_id is string
         and trigger.event.data.entity_id.startswith('geo_location.')
         and 'earthquake' in trigger.event.data.entity_id }}
action:
  - service: notify.mobile_app_your_phone
    data:
      title: "Earthquake reported nearby"
      message: >
        A USGS earthquake feed entity changed near Home Assistant.
        Check official alerts and local conditions before taking action.

The condition above is intentionally conservative and generic because entity names vary by feed and installation. After installing the integration, inspect Developer Tools → States and tighten the condition around your actual geo_location entities, magnitude attributes, and radius choice. If the automation wakes people at night, it should say “reported” or “feed update,” not “incoming shaking.”

Recipe B: USGS feed turns on a low-risk scene

A feed update can still do something concrete. Turn on entry lights, save a camera bookmark, or send a speaker announcement after the event appears. Keep actions reversible and low-risk.

alias: Earthquake feed response - lights and announcement
mode: restart
trigger:
  - platform: event
    event_type: state_changed
condition:
  - condition: template
    value_template: >
      {{ trigger.event.data.entity_id is string
         and trigger.event.data.entity_id.startswith('geo_location.')
         and 'earthquake' in trigger.event.data.entity_id }}
action:
  - service: light.turn_on
    target:
      entity_id:
        - light.hallway
        - light.entry
    data:
      brightness_pct: 100
  - service: media_player.volume_set
    target:
      entity_id: media_player.kitchen_speaker
    data:
      volume_level: 0.7
  - service: tts.speak
    target:
      entity_id: tts.home_assistant_cloud
    data:
      media_player_entity_id: media_player.kitchen_speaker
      message: "Earthquake reported by feed. Check official alerts and local conditions."

If you already use Home Assistant for storm or heat alerts, the pattern will feel familiar. The same caution used in tropical depression alert automations and extreme heat watch vs warning automations applies here: the feed category decides the automation category.

GeoShake: the only hub-triggerable earthquake entity in this source set

GeoShake T1 compact plug-and-play seismic sensor station

GeoShake is the path that changes the automation conversation, because it exposes an earthquake state a hub can act on. The company says the GeoShake T1 has a median detection-to-phone latency of 2.3 seconds, can provide 5 to 20 seconds of warning for events tens of kilometers away, and does not let a single device raise the alarm alone [4]. Those are vendor-published claims, not NestGrid Confirmed results.

For Home Assistant, GeoShake says its HACS integration requires Home Assistant 2024.11 or newer and exposes an Earthquake sensor that turns ON only for network-confirmed events where 3 or more stations agree. The ON duration is configurable, with 120 seconds described as the default, and the entity exposes attributes including intensity class, station count, maximum PGA, and distance. The alert radius defaults to 0, meaning all events, and distance is measured from the Home Assistant home location [5].

LabelValue
SourceGeoShake network-confirmed earthquake entity
PlatformHome Assistant through HACS; Smart Life/Tuya through supported device signals
Likely latencyVendor-published 2.3 s median detection-to-phone latency; hub latency not independently reproduced by NestGrid [4]
False-alarm behaviorVendor describes 3+ station consensus; a single device does not raise the alarm alone [4][5]
Verification statusVendor-reported; no NestGrid Confirmed status yet

Recipe C: GeoShake turns on exit-route lights and announces

This is the cleanest Home Assistant earthquake response recipe in the current set because the trigger is an earthquake entity, not a feed scrape. Replace the example entity_id with the actual GeoShake Earthquake sensor in your Home Assistant instance.

alias: GeoShake earthquake response - lights and voice
mode: restart
trigger:
  - platform: state
    entity_id: binary_sensor.geoshake_earthquake
    to: "on"
action:
  - service: light.turn_on
    target:
      entity_id:
        - light.hallway
        - light.stairs
        - light.entry
    data:
      brightness_pct: 100
      transition: 0
  - service: media_player.volume_set
    target:
      entity_id: media_player.living_room_speaker
    data:
      volume_level: 0.8
  - service: tts.speak
    target:
      entity_id: tts.home_assistant_cloud
    data:
      media_player_entity_id: media_player.living_room_speaker
      message: "Earthquake alert. Drop, cover, and hold on. Exit lights are on."
  - service: camera.record
    target:
      entity_id: camera.front_entry
    data:
      duration: 120
      lookback: 5

The 120-second camera duration pairs with GeoShake’s documented default ON window, but do not assume your entity uses that default. Check the integration settings, then watch the entity state and attributes in Developer Tools before attaching anything louder or riskier.

Recipe D: GeoShake cuts selected loads

Cutting power is useful only when the device on the other end is safe to interrupt. A smart plug feeding a decorative lamp is different from a refrigerator, medical device, network rack, garage door opener, sump pump, or anything with a restart hazard. Keep the list small.

alias: GeoShake earthquake response - selected load cutoff
mode: single
trigger:
  - platform: state
    entity_id: binary_sensor.geoshake_earthquake
    to: "on"
action:
  - service: switch.turn_off
    target:
      entity_id:
        - switch.space_heater_plug
        - switch.iron_plug
        - switch.workbench_tool_strip
  - service: notify.mobile_app_your_phone
    data:
      title: "Earthquake response ran"
      message: "Selected plugs were turned off. Verify appliances and wiring when safe."

For plug selection and failure behavior, reuse the same thinking from NestGrid’s Home Assistant smart plug recipes, grid emergency auto-shedding guide, and leak-sensor smart-plug flood response recipe. Earthquake triggering changes the reason for the action, not the electrical reality of the load.

Optional variant: unlock a smart lock only if the trade-off fits your household

GeoShake lists smart-lock unlock among possible safety automations, but that should not make it a default. Auto-unlocking can help if doors bind, someone needs to enter, or household members are moving fast. It can also create a security problem, interact badly with pets or children, or unlock during a false or distant alert. If you use it, make it a deliberate variant and notify everyone when it runs.

alias: GeoShake earthquake response - optional lock variant
mode: single
trigger:
  - platform: state
    entity_id: binary_sensor.geoshake_earthquake
    to: "on"
condition:
  - condition: state
    entity_id: input_boolean.allow_earthquake_auto_unlock
    state: "on"
action:
  - service: lock.unlock
    target:
      entity_id: lock.front_door
  - service: notify.mobile_app_your_phone
    data:
      title: "Front door unlocked by earthquake automation"
      message: "GeoShake-triggered unlock ran because the household opt-in toggle was enabled."

The input_boolean is not theater. It gives the household a visible opt-in switch instead of burying the most controversial action inside YAML that nobody remembers during a retrofit.

Smart Life and Tuya: use network Shock State, not local Lock Shock

GeoShake’s Smart Life/Tuya behavior needs careful labeling. The vendor says the sensor exposes two signals: network Shock State and local Lock Shock. It explicitly recommends building safety automations on the network signal, not the local signal [5].

SignalMeaning for automation
Network Shock StateUse this for earthquake response routines; vendor-recommended for safety automations [5]
Local Lock ShockDo not use as the primary safety trigger; it is local device behavior, not the network-confirmed state [5]

A reasonable Smart Life/Tuya routine is simple: when network Shock State changes to the earthquake alert state, turn on exit-route lights, turn on a plug-in siren if you have one, and turn off a short list of safe-to-interrupt plugs. Keep any door-unlock action in a separate routine so it can be disabled without breaking the rest of the response.

  1. Create an automation with GeoShake network Shock State as the trigger.
  2. Add lights first: hallway, stairs, entry, garage path, or exterior egress lighting.
  3. Add audible alerting only if the siren or smart plug returns to a safe state after the event.
  4. Add load cutoff only for devices you have already judged safe to interrupt.
  5. Create a separate optional lock routine if your household accepts that trade-off.

Google Home and Apple Home: useful response layers, missing native ShakeAlert triggers

Google Home and Apple Home are good at response: lights, speakers, cameras, plugs, and scenes. The missing piece is the same one we started with: they do not receive ShakeAlert as a native automation trigger. If your earthquake signal stays on the phone, the home routine does not know about it.

For Google Home, the most defensible setup is a parallel one: keep Android Earthquake Alerts active on the phone, then use a supported bridge or device path only when it exposes a real trigger into the Google ecosystem. Do not build an article-of-faith routine that assumes a phone notification will fire a household scene unless you have tested the exact bridge behavior on your account and devices.

For Apple Home, the same ceiling applies. iPhone alerts can warn the person. HomeKit scenes can prepare the space. The missing native bridge between official earthquake warning and Apple Home automation remains the reason to label the setup as response support, not early warning.

PlatformRealistic 2026 recipe
Google HomeUse phone EEW for human warning; use compatible bridge/device triggers only when they expose a testable earthquake state; run lights, speakers, cameras, and plugs as response actions.
Apple HomeUse iPhone alerts for human warning; use Home scenes for manual or bridged response where available; do not assume official EEW becomes a HomeKit trigger.

EMSC custom integration: useful information, not safety control

The Earthquake Monitor custom integration for Home Assistant, distributed through HACS, reads the EMSC real-time feed and exposes attributes such as distance, bearing, and country. In a May 2026 Home Assistant community thread, the author described it as informational only and said it should not control safety-relevant systems [6].

That still leaves room for harmless automations: dashboard cards, mobile notifications, history logging, or a spoken “earthquake reported” message after an event appears. It should not be the trigger that cuts equipment, unlocks doors, or tells people shaking is imminent.

What the response scene should actually do

The best earthquake automation is not the longest one. It is the one that still makes sense when the hub is slow, the internet is down, a bulb missed a command, or someone is half-awake and barefoot.

  • Exit-route lights: turn on hallway, stair, entry, and garage-path lights to 100% with no transition delay.
  • Audible alert: use a speaker announcement or plug-in siren only if it will not trap the household in panic noise after the event.
  • Camera recording: record front entry, garage, or utility-room cameras for later review, not for real-time decision-making during shaking.
  • Load cutoff: turn off only pre-approved plugs such as a space heater, iron, workbench strip, or small pump where interruption is safe.
  • Locks: keep auto-unlock separate, opt-in, and visible.
  • Notifications: include the trigger source in the message — phone EEW, USGS feed, EMSC feed, GeoShake network, or manual scene.
Smart home at dusk responding to an earthquake signal with lights, speaker glow, and alarm indicator

Put the label in the automation name, not just in your memory. “GeoShake network earthquake response” is much safer than “earthquake alarm.” “USGS feed awareness” is clearer than “quake warning.” Six months later, after a hub migration or a power outage, that wording will matter.

Power failure deserves its own expectation check. If the hub, router, Wi-Fi access point, speaker, or smart plug loses power during or after shaking, parts of the routine may not run or may come back in the wrong state. Use the power-outage reconnect troubleshooting guide to decide which devices need UPS support, local control, or post-outage checks.

A verification label to attach to every earthquake automation

Every recipe should carry five fields. If you cannot fill them in, the automation is not ready to trust.

FieldExample
SourceGeoShake network-confirmed earthquake entity; USGS feed; EMSC feed; phone EEW only
PlatformHome Assistant, Google Home, Apple Home, Smart Life/Tuya
Likely latencyVendor-published seconds; feed polling interval; phone-only warning; unknown bridge delay
False-alarm behaviorNetwork consensus, feed report, local signal, or phone alert system
Verification statusVendor-reported, community-reported, documented integration behavior, or NestGrid Confirmed

As of Q3 2026, none of the earthquake source/hub pairings in this article has NestGrid Confirmed status. That does not make them useless. It means the label should stay visible until independent reproduction catches up with the recipe.

The honest verdict is narrow but usable: a smart home can respond to earthquake signals in 2026. Phone apps remain the stronger human-warning path where supported. USGS and EMSC feeds are awareness layers. GeoShake is the one path here that exposes a hub-triggerable earthquake entity, with promising vendor-published behavior and the usual need for verification. None of them turns a consumer hub into a certified life-safety warning system.

References

  1. USGS Earthquake Hazards — Home Assistant
  2. MyShake FAQ — MyShake
  3. Android Earthquake Alerts — Google Crisis Response
  4. GeoShake T1 — GeoShake
  5. Integrations — GeoShake
  6. Earthquake Monitor Custom Integration — Home Assistant Community Forum, May 2026

Related reading

Feedback / Question

Did a step not work as written? Let us know so it can be corrected.

Blogarama - Blog Directory