alert_channel default (2) silently fails for users without a configured second channe #152

New Issue

2026-10-05T01:26:09+02:00

adam commented

2026-10-05 01:26:09 +02:00

Ran into this while testing the EC alerts feature (SpudGunMan/meshing-around#342), but it's not EC-specific — it affects every alert type that goes through handleAlertBroadcast(): NOAA wx alerts (wxAlertBroadcastEnabled), FEMA/iPAWS (ipawsAlertEnabled), USGS volcano alerts (volcanoAlertBroadcastEnabled), and EC alerts all funnel through the same line:

emergency_responder_alert_channel defaults to 2 (config['emergencyHandler'].getint('alert_channel', 2) in modules/settings.py). Most Meshtastic setups only actively run channel 0 (longfast) — configuring extra channels is the exception, not the norm. If a user hasn't set up channel 2, sends to it just silently go nowhere — no error, no log warning, nothing. I spent a while thinking the whole EC alert feature was broken before realizing it was just going to a channel I don't have. An American user enabling NOAA or FEMA alerts for the first time would hit the exact same wall.

If 2 was chosen deliberately for a reason (e.g. keeping alerts off a noisy default channel on your own setup), that context might be worth a comment in config.template so others don't hit the same confusion. Otherwise, a couple options that might help:

Default alert_channel to whatever [general] defaultChannel is already set to, since that's guaranteed to exist
Or just add a clearer comment in config.template next to alert_channel warning that it must match a channel actually configured on the node
Optionally, log a warning if a send to that channel fails, so it's at least debuggable

Happy to test whichever approach you'd prefer.

Ran into this while testing the EC alerts feature (SpudGunMan/meshing-around#342), but it's not EC-specific — it affects every alert type that goes through handleAlertBroadcast(): NOAA wx alerts (wxAlertBroadcastEnabled), FEMA/iPAWS (ipawsAlertEnabled), USGS volcano alerts (volcanoAlertBroadcastEnabled), and EC alerts all funnel through the same line: emergency_responder_alert_channel defaults to 2 (config['emergencyHandler'].getint('alert_channel', 2) in modules/settings.py). Most Meshtastic setups only actively run channel 0 (longfast) — configuring extra channels is the exception, not the norm. If a user hasn't set up channel 2, sends to it just silently go nowhere — no error, no log warning, nothing. I spent a while thinking the whole EC alert feature was broken before realizing it was just going to a channel I don't have. An American user enabling NOAA or FEMA alerts for the first time would hit the exact same wall. If 2 was chosen deliberately for a reason (e.g. keeping alerts off a noisy default channel on your own setup), that context might be worth a comment in config.template so others don't hit the same confusion. Otherwise, a couple options that might help: Default alert_channel to whatever [general] defaultChannel is already set to, since that's guaranteed to exist Or just add a clearer comment in config.template next to alert_channel warning that it must match a channel actually configured on the node Optionally, log a warning if a send to that channel fails, so it's at least debuggable Happy to test whichever approach you'd prefer.

adam closed this issue

2026-10-05 01:26:09 +02:00

adam commented

2026-10-05 01:26:10 +02:00

Yea it's to lower the chance of too much data on a public channel, 2-3 bots same network lots of alerts and all.

Yea it's to lower the chance of too much data on a public channel, 2-3 bots same network lots of alerts and all.

adam commented

2026-10-05 01:26:11 +02:00

Closing issue, as there is no way to tell the channel didn't deliver that I know off hand.

Closing issue, as there is no way to tell the channel didn't deliver that I know off hand.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: adam/meshing-around#152