Add frequency slot lookup to Radio Config and channel delete to Channels

[kendelmccarley]

Summary

• Adds a Slot ↔ Frequency lookup field to the Radio Config tuning pane so slot numbers can be entered directly without manual
  frequency lookups
• Adds a contextual Delete Channel button to the Channels card that appears when a non-primary channel row has focus

Why

These changes make it easier to develop and test multiple LoRa channel configurations. The Meshtastic slot numbering is the common currency when coordinating frequencies with other operators, but the dashboard previously only accepted raw MHz values, requiring a manual table lookup every time. Being able to delete an entry will ease development and testing.

Type

• Feature

Testing

• Local only

Hardware:

• Pi: Raspberry Pi (RAK V2)
• Concentrator: RAK2287 / SX1302
• Node/radio: --
• Region: US
• OS: Raspberry Pi OS (Linux 6.12.75+rpt-rpi-v8)

Impact

No config schema changes. Slot field is a pure UI convenience — only the resolved frequency_mhz value is written to config on save. Delete Channel removes the row from the DOM; the channel list is only committed on "Save Channels".

AI-assisted?

Yes — developed with Claude Code (Anthropic). Logic reviewed against Meshtastic firmware formula and validated against the slot tables in docs/RADIO-CONFIG-EXPLAINED.md.

[KMX415]

Thanks Kendel: this is exactly the kind of PR I want to see. Slot lookup has been overdue (operators coordinate by slot number, not MHz), and the crypto-keys cleanup is a real bug I'd missed. You also already wrote the whole thing against the v0.7.1 file split (radio_config_card.js, r-* BEM prefixes, r-field--slot as a modifier on the existing block), which is a nice surprise given v0.7.1 only landed today.

Slot formula crosses out clean: US LongFast slot 20 = 902.0 + 0.125 + 19*0.25 = 906.875 MHz, matches ConcentratorChannelPlan.for_region("US") defaults. The boundary tolerance (Math.abs(raw - n) < 0.001) is the right guard for between slots. The focus/blur dance with setTimeout(..., 0) for the delete button is the right pattern, not a kludge.

Two small asks before merge:

1. The crypto fix reaches into a private attribute.

_crypto._keys.clear() couples the route handler to CryptoService's internal storage. Could you add a public method on CryptoService and call that instead?

def clear_channel_keys(self) -> None:
    """Drop all non-default channel keys."""
    self._keys.clear()

Then update_channels does _crypto.clear_channel_keys(). Same behavior, no encapsulation break.

2. Regression test on the cleanup.

Without one, the bug grows back the next time someone refactors update_channels. Something like: after update_channels removes a channel, that channel's PSK is no longer reachable via crypto.get_all_keys().

Optional but appreciated: if you have a node on a non-US region around (or a friend with EU_868 / ANZ hardware), one cross-region slot sanity check would lock the formula in across all six bands. US is solid; EU and ANZ are where the band-start values diverge.

Thanks again: this is the good version of an AI-assisted PR.

[kendelmccarley]

Yes, I ran into the key cleanup issue about five minutes after submitting the PR. I had two identical channels, with the resulting behavior that Ch 0 could TX and Ch 1 grabbed all the RX. When I deleted the duplicate channel, the second channel's key remained and it was swallowing received messages. That fix has been pushed back to my fork.

I also added the slot number to config.yaml, with logic to resolve any conflict between slot number and frequency in the favor of the frequency. This keeps the change from breaking existing installations. Using the formula to calculate frequency should eliminate the need to set the default in each region, so that change was made as well. Although I can't see a reason it wouldn't work correctly, the change is untested through a new install.

[KMX415]

Thanks for the fast turnaround Kendel, and for going above and beyond on the schema work too. The clear_channel_keys() refactor is exactly what I was hoping for, and the bug repro you described (Ch 0 TX, Ch 1 RX swallowing messages from the deleted Ch 1's stale key) is a great catch.

The slot-in-config schema work in a3491c1 is also genuinely thoughtful. The priority order (explicit MHz wins, then slot, then regional default) is the right shape, and it mirrors the max_duty_cycle_source explicit vs derived pattern that just landed in v0.7.1. Backward compat looks intact too: existing Meshpoints with frequency_mhz set in their local.yaml keep that, and ones without it fall through to _REGION_DEFAULT_FREQ which returns the same values they had before.

One small note for future cleanup (no need to block this PR): _REGION_FREQ_START and _REGION_DEFAULT_FREQ mirror values that already live in hal/concentrator_config.py::_REGION_BAND_LIMITS_HZ and radio/presets.py::REGION_DEFAULTS. Three sources of truth for the same numbers is a slow drift risk over time. Worth picking one canonical source eventually and having the resolver consume it. Easy to file as a follow-up cleanup, no rush.

I'll do a quick fresh-SD validation on EU_868 on my end before merging, since you flagged the multi-region piece as untested and I have the hardware for it. That way you don't have to chase region-by-region.

Really appreciate the work on this one. Both the slot lookup and the channel deletion (and the bug you caught while building it) are genuinely useful.

P.S. Apologies for the earlier version of this comment. AI is dumb sometimes. The above is what I should have led with.

[KMX415]

CI green and hardware-validated end-to-end. Merging this shortly.

Tests run:

1. CI on commit 8cdd2fa: lint clean, full pytest suite green including 15 new tests for the resolver in tests/test_radio_frequency_resolver.py (covers all 6 supported regions, both fallthrough and explicit-MHz paths, plus a region-table coverage check against setup_wizard.SUPPORTED_REGIONS).

2. Hardware regression on an existing US Meshpoint: switched to your branch, set an off-default frequency_mhz: 905.0 in local.yaml. Boot banner showed Frequency 905.000 MHz / SF11 / BW250 (US). NodeInfo TX at 905 MHz, 723ms airtime, no errors. Confirms explicit MHz wins over region default, which is the regression case to catch first since every existing in-wild Meshpoint has explicit MHz pinned.

3. Fresh-install on a wiped Pi: removed local.yaml and the SQLite DB, re-ran meshpoint setup, selected region: EU_868. Boot banner showed Frequency 869.525 MHz / SF11 / BW250 (EU_868). NodeInfo TX at 869.525 MHz, 764ms airtime. Confirms the new fresh-install path works (wizard writes only region, resolver fills frequency from _REGION_DEFAULT_FREQ).

4. Channel delete UI on the same fresh-install Pi: focus a non-primary channel row, delete button appears, click removes the row, save persists. mousedown preventDefault correctly keeps focus alive while the click lands.

The schema change you bundled in a3491c1 was beyond the PR's original scope, but it's backward-compatible (existing yaml configs with explicit MHz are preserved by the resolver), it simplifies the radio config for fresh installs, and it fixes a latent bug where new EU/IN/etc. installs were getting 906.875 by default. I'd been wanting to make this exact change. Thanks for taking it on.

Plan: merging to main without a version bump. The improvements will ride along with the next feature release (v0.7.2), so the changelog will credit this work then.

Thanks for the work and the patience through review.