[FEAT] Device Heartbeat and Configurable Health Notifications for Meshtastic and MeshCore Nodes

[maxhayim]

Is your feature request related to a problem? Please describe.

MeshMonitor displays device information and telemetry for Meshtastic and MeshCore nodes, but there is no centralized way to receive proactive notifications when a monitored device is about to fail, stops reporting, or reaches a configurable health threshold.

I use several mobile and fixed radio devices around the house. Some are battery-powered, and I currently have to manually check MeshMonitor to make sure they do not run out of power or disappear from the network.

MeshMonitor already has web notifications and already receives some device telemetry and last-heard information. It would be useful to use those existing systems to provide configurable device-health and heartbeat alerts.

Examples include:

• A node’s battery falls below a configured percentage or voltage
• A node has not been heard from within a configured period
• A node stops sending telemetry or heartbeat data
• A node reconnects or returns online
• A solar node is losing battery over time instead of charging
• A node reports an unusually high temperature
• A node’s channel utilization or noise floor reaches a configured level
• A device restarts unexpectedly or its uptime resets

Without these notifications, a battery-powered or remote node may remain offline for hours or days before the operator notices.

Describe the solution you'd like

Add a Device Health, Heartbeat Monitoring, or Node Alerts feature for both Meshtastic and MeshCore sources.

Users should be able to create per-node or global notification rules using telemetry and last-heard data already available in MeshMonitor.

Possible notification conditions could include:

• Battery percentage below: configurable percentage
• Battery voltage below: configurable voltage
• No heartbeat or telemetry received for: configurable number of minutes or hours
• Node not heard for: configurable number of minutes or hours
• Node returned online: enabled or disabled
• Temperature above or below: configurable threshold
• Noise floor above: configurable threshold
• Channel utilization above: configurable threshold
• Uptime reset detected: enabled or disabled
• External power lost: when supported by the device telemetry
• Battery not charging during expected solar hours: optional advanced condition

Notifications should use MeshMonitor’s existing web push notification system so alerts can reach phones, tablets, and computers that have notifications enabled.

Example notifications:

Low Battery Alert

MTDL Base has reached 20% battery.
Last voltage: 3.62 V
Last heard: 2 minutes ago

Heartbeat Lost

MTKL Solar has not been heard from for 45 minutes.
Last heard: 2:14 PM
Last battery: 54%

Node Restored

MTKL Solar is reporting again.
Offline duration: 52 minutes
Current battery: 51%

The feature should support:

• Per-node thresholds
• Default thresholds applied to all nodes
• Separate settings per source
• Meshtastic and MeshCore nodes
• Web push notifications
• Notification cooldowns
• Recovery notifications
• Enable or disable each alert type
• Quiet hours
• Alert history
• Test notification button

A heartbeat should not necessarily require a new packet type. MeshMonitor could use the node’s existing telemetry, status, advertisement, or last-heard updates as proof that the device is still alive.

The system should avoid repeated notifications for the same condition. For example, a low-battery alert could be sent once when the battery crosses below the threshold and then again only after a configurable cooldown or after the device recovers and falls below the threshold again.

Describe alternatives you've considered

I currently open MeshMonitor and manually check the node list, telemetry values, battery levels, and last-heard times.

Home Assistant automations could potentially monitor some Meshtastic data, but that requires a separate platform and does not provide a unified solution for both Meshtastic and MeshCore nodes already managed by MeshMonitor.

Device-specific applications may provide some battery information, but they require checking each node individually and may not work for remote nodes connected directly to MeshMonitor.

A scheduled external script could query the MeshMonitor API and send notifications, but native support would be easier to configure, more reliable, and available to all MeshMonitor users.

Additional context

My primary use case is monitoring several battery-powered and mobile devices around the house so they do not silently run out of power.

The intended flow would be:

Meshtastic or MeshCore node
          ↓
Telemetry, advertisement, or heartbeat
          ↓
      MeshMonitor
          ↓
Threshold and stale-device evaluation
          ↓
Web push notification
          ↓
Phone, tablet, or computer

This could build on existing MeshMonitor functionality where applicable, including:

• Node telemetry
• Battery information
• Last-heard timestamps
• Source connection status
• Existing web notifications
• Meshtastic device metrics
• MeshCore device status and telemetry

Not every device or firmware reports every metric. The UI should only offer alert conditions supported by the available data, or clearly indicate when a metric has never been reported.

Environment

• Host OS: N/A
• Deployment type: Docker
  • Container version: MeshMonitor v4.14.0
  • Container image/tag: N/A
• Networking customizations: N/A
• Database backend: N/A
• Node types: Multiple Meshtastic and MeshCore devices
• Node connection types: Multiple
• Virtual Node client: N/A

[Yeraze]

Triage

Not a duplicate of any single existing issue — but it overlaps substantially with notification features that already shipped, and it's a broad ask, so let me lay out what's already there before scoping the new parts. Classifying as Feature Request.

Already shipped today (Meshtastic and MeshCore)

• Low-battery alerts — lowBatteryNotificationService.ts: percent threshold (Meshtastic) or mV threshold (MeshCore), ~24h cooldown, hourly poll (delivered via [FEAT] Alert on low battery for remote nodes #3305, [BUG] Meshcore - Notify on Low Battery #4020, and related reports).
• Node inactivity/offline alerts — inactiveNodeNotificationService.ts: configurable stale-hours threshold, per-source, cooldown, opt-in monitored-node list (delivered via [FEAT] Node Inactivity Alerts #864).
• Web push delivery, service worker, per-user/per-source preferences — NotificationsTab.tsx.
• Test-notification button — already in Settings → Notifications.

So "battery below X%", "not heard from in N minutes", "web push", "cooldowns", and "test notification" are all live today — worth checking Settings → Notifications before further design work, in case this closes part of the gap already.

Genuinely new asks in this issue

• Node recovery ("back online") notification — not implemented.
• Temperature / noise-floor / channel-utilization threshold alerts as dedicated notification toggles.
• Uptime-reset / unexpected-reboot detection.
• External-power-lost detection.
• Solar-not-charging-over-time detection (a solarMonitoringService exists but only for forecasting, not this).
• Per-node threshold overrides (today's thresholds are global-per-user, not per-node).
• Quiet hours.
• Alert history log/UI (deliveries are logged server-side but not surfaced anywhere).

Fit with project direction

Good fit, and there's a better substrate for it than more one-off services. MeshMonitor's generic Automation Engine (#3653, src/server/services/automation/) already ships condition primitives for telemetry.temperature, channelUtilization/airUtilTx, a generic action.notify, and cooldownSeconds/cooldownScope. Rather than growing the current one-bespoke-service-per-condition pattern to cover 8 more alert types, the cleaner path is likely:

1. Extend the Automation Engine's condition/trigger set to cover the remaining raw signals this issue asks for: noise floor, uptime-reset/reboot, external-power-lost, node-recovery/online-transition, solar-charging-trend.
2. Add the missing cross-cutting infra once, shared by all alert types rather than rebuilt per-type: quiet hours (a user-level suppression window), per-node threshold overrides (the engine's variable system already has node/sourceNode scopes that could be reused here), and an alert/run history view (the engine already logs to automation_runs — this is mostly a UI surfacing job, not new plumbing).
3. Ship a "Device Health" starter template/preset so this doesn't require hand-building a graph in Advanced Mode — keeps parity with how simple the existing Settings → Notifications toggles are today.

Before I turn this into a build plan

• Which of the "genuinely new" list above matters most to you? Node-recovery and per-node overrides look like the smallest, highest-value slice; noise-floor/uptime-reset/external-power/solar-charging are more speculative (depends on what your specific hardware actually reports — not every firmware/board exposes all of these).
• Is Advanced-Mode automation building an acceptable place to land this (with a friendlier preset on top), or is a dedicated Settings-tab UI (matching the existing Low Battery / Inactivity sections) the experience you're expecting?

Happy to turn this into a phased implementation plan once scope is confirmed — flagging the size here since "all of the above" is a multi-week effort, not a single PR.

-- Authored by Roger 🤓

---

Generated by Claude Code

[Yeraze]

Have you looked at Automation Engine? I believe many of these can be constructed from Automation Engine triggers.

[maxhayim]

Have you looked at Automation Engine? I believe many of these can be constructed from Automation Engine triggers.

I looked at it, but I still find the current setup confusing for this use case.

My goal is simple: choose a device or node from any supported mesh service, set a low-battery, offline, or health threshold, and receive a web notification when it needs attention.

I should not have to determine whether that belongs under regular Notifications, the Automation Engine, Apprise, a mesh-message action, or a service-specific configuration page.

Some of the pieces may already exist, but they appear to be split across different areas and implemented differently depending on the mesh service.

I think this should be a universal Device Health and Heartbeat Alerts feature that works consistently across all supported mesh services, including Meshtastic, MeshCore, and future integrations.

A user should be able to:

• Select any supported device or node
• Set low-battery or low-voltage thresholds
• Set an offline or not-heard timeout
• Enable recovery notifications when the device returns
• Set temperature, uptime-reset, noise-floor, or other supported telemetry thresholds
• Choose Web Push, Apprise, or other available notification methods
• Apply default rules globally or override them per device
• See which metrics are supported by each service or device

The interface should normalize service-specific telemetry where possible, while clearly showing when a metric is unavailable.

Prebuilt Automation Engine templates could help, but the main user experience should be universal and straightforward rather than requiring users to build separate service-specific automations for the same basic monitoring goal.