Module M7 - Alarms & Status

Files: packages/grow_alarms.yaml (this module). Reads flags already raised by packages/grow_core.yaml, grow_climate.yaml, grow_light.yaml, grow_air.yaml, and grow_irrigation.yaml - no changes needed to any of those files.

Note on phase numbering

Per the Phase 0 plan’s table this is the second half of Phase 8 (“Energie & vollständiges Alarm-Modul”) - the Energy half (M6) shipped 2026-08-27/28; this module is the “vollständiges Alarm-/Fehlerzustandsmodul mit allen drei Kanälen” (Push/Persistent/E-Mail, R9) that was left for later.

What this module is - and isn’t

This is not a new fault detector. Every fault it reports already exists and already fires its own persistent_notification inside the module that found it:

• binary_sensor.grow_core_setup_incomplete - Dashboard 1 mapping issues (Core, M0).
• input_boolean.grow_climate_control_paused - Climate’s safety pause (Climate, M1, R7: “aktiv alarmieren, manuell übernehmen” on sensor/actuator failure).
• input_boolean.grow_light_top_fault / grow_light_undercanopy_fault - a light group didn’t confirm an on/off command within 15s (Light, M3).
• input_boolean.grow_exhaust_fault / grow_intake_fault / grow_co2_fault / grow_circulation_fault - same pattern for Air (M4/M5).
• input_boolean.grow_irrigation_failsafe_tripped - substrate VWC fell below the failsafe threshold (Irrigation, M2).

What this module adds is the two notification channels no other module has ever used: mobile Push (notify.<device>) and E-Mail (SMTP), fired as one consolidated alert whenever the combined “is anything wrong” signal changes state - on top of, not instead of, each module’s own persistent notification. R9 requires all three channels running in parallel, not as alternatives to each other.

What counts as “active”

binary_sensor.grow_alarms_active (device_class problem) is on if any of the flags above are on. sensor.grow_alarms_summary holds the count as its state and the human-readable list as its active_alarms attribute - both are read by the notification automation and the Alarms dashboard view.

Deliberately excluded: VWC Lock being active, CO2 dosing staying dormant because no sensor is mapped, a module’s master switch simply being off. Those are normal/expected states, not something to be woken up for.

Notification channels

Persistent Notification

Always available, no setup. A single consolidated notification (notification_id: grow_alarms_active) is created/updated on every change, separate from each module’s own per-fault notification.

Push (Mobile App)

Five devices were found registered under the Mobile-App integration when this was built (2026-08-28, Settings -> Devices & Services -> Mobile-App): notify.ipad, notify.iphone_2, notify.iphone_2_2, notify.iphone_von_elena, notify.iphone_von_elena_15_pro. Each has its own toggle on the Alarms view, all default on.

Two pairs look like possible duplicates:

• iphone_2 vs iphone_2_2 - only iphone_2_2 showed a recent “Gesendet” (sent) entry in its Activity log when checked; iphone_2 had none, suggesting it may be a stale registration from an earlier app install.
• iphone_von_elena (an older iPhone12,5) vs iphone_von_elena_15_pro (an iPhone16,1) - looks like a phone upgrade left the old device registered too, but this wasn’t confirmed via activity history.

Rather than silently guessing and dropping one, both stay on by default - if Send Test Notification only reaches one device of a pair, turn the other’s toggle off here. To actually remove a stale device from Home Assistant (optional cleanup, not required for this module to work): Settings -> Devices & Services -> Mobile-App -> open the stale device -> the ”…” menu -> Delete.

If a toggled-on device’s notify.* service no longer exists (e.g. you delete the device later), that one push call fails silently (continue_on_error: true) and every other channel still fires - a stale toggle degrades gracefully instead of blocking the whole alert.

E-Mail (SMTP)

No SMTP/E-Mail integration was found configured on this instance when this module was built (2026-08-28 check of Settings -> Devices & Services). input_boolean.grow_alarms_email_enabled therefore defaults off, and input_text.grow_alarms_email_notify_service defaults to the placeholder notify.smtp (the service name Home Assistant’s built-in SMTP integration normally creates).

To actually use this channel:

1. Settings -> Devices & Services -> Add Integration -> search “E-Mail” (the built-in SMTP notify integration) -> enter your mail provider’s SMTP host/port/credentials. This project never sees or handles those credentials - you enter them directly into Home Assistant’s own integration setup.
2. Confirm the exact service name it created (Developer Tools -> Actions, search “notify”) matches the text field on the Alarms view - update the field if your instance names it differently.
3. Turn “E-Mail Enabled” on.

Until both the integration exists AND the toggle is on AND the service name field actually looks like notify.<something> (checked via a regex guard), the automation and the test script both skip the email call entirely rather than erroring - same “optional, dormant until configured” pattern used for CO2 dosing (Air, M5) and VWC Lock (Irrigation, M2).

Testing the pipeline

Tap Send Test Notification (Alarms view, or script.grow_alarms_send_test_notification) any time to send a test alert through every currently-enabled channel, without waiting for or faking a real fault - the fastest way to confirm device tokens are still valid and SMTP credentials are correct after first setup or after changing anything.

Recovery notifications

The automation fires on both the rising edge (something just broke) and the falling edge (everything just cleared) of binary_sensor.grow_alarms_active, sending ”🚨 … Alarm active” / ”✅ … All clear” respectively - the same auto-recovery-with-notification shape already used by the Irrigation failsafe and the Light/Air fault watchdogs, just consolidated across every module in one place.

Rollout checklist

1. Deploy packages/grow_alarms.yaml, check config, restart (new helpers need one the first time).
2. Re-import dashboards/dashboard_2_control_panel.yaml (new “Alarms” view) and dashboards/dashboard_3_log.yaml (new logbook card).
3. On the Alarms view, review the 5 push toggles - turn off any device you don’t want alerts on, and mute whichever one of each possible-duplicate pair (see above) doesn’t actually receive anything.
4. Tap Send Test Notification and confirm you receive it on every channel you expected (persistent notification always; push on whichever devices are toggled on; email only if you’ve completed the SMTP setup above).
5. Leave “Notifications Enabled” on (it defaults on, unlike other modules’ master switches - see packages/grow_alarms.yaml header comment for why: this module never commands an actuator, only reads state and notifies, so there’s nothing unsafe about it running from first deploy).
6. Optional: set up the E-Mail/SMTP integration per the section above if you want that third channel active too.