feat(radio): remote reboot button in Radio Setup (#3334)

[jensenpat]

Summary

Closes part of #3334.

Adds a Reboot Radio button to the Radio Information group of the Radio Setup dialog, directly beneath the Options row. Confirmation dialog gates the destructive action; on accept, AetherSDR sends radio reboot to the connected FlexRadio, closes the setup dialog so the panadapter is visible, then drops into the unexpected-disconnect path so the existing 3-second reconnect timer brings the link back when the radio finishes booting.

What's in scope vs. out of scope

Issue #3334 requested two commands:

Requested	Status	Reason
radio reboot	✅ implemented	Confirmed real — FlexLib/Radio.cs:2575 (Radio.RebootRadio() → SendCommand("radio reboot"))
radio reboot initialize (factory reset)	❌ not implemented	The subcommand does not exist. No SendCommand("radio reboot initialize"), no FactoryReset/Reinitialize method anywhere in the FlexLib v4.2.18 source tree. SmartSDR factory reset is a front-panel / utility-menu operation, not exposed on the TCP ASCII API. The issue author's AI assistant appears to have hallucinated it.

If FlexRadio adds a reinitialize subcommand to a future firmware revision, we can wire the second variant behind the same button machinery — but shipping a command the radio doesn't understand would silently fail and mislead operators into thinking they triggered a factory reset.

Implementation

RadioModel::rebootRadio() (new, src/models/RadioModel.h/.cpp):

• Sets the new m_rebootInProgress flag
• Sends radio reboot via the standard sendCommand() path
• QTimer::singleShot(250ms, forceDisconnect) — lets the TCP write flush before tearing the socket down
• forceDisconnect() deliberately does not set m_intentionalDisconnect, so the existing 3-second m_reconnectTimer engages and brings us back once the radio finishes booting

Toast suppression (m_rebootInProgress):

• During reboot, the TCP retry loop fires Connection refused once every ~3 s while the radio is still booting. Without suppression that produces ~5–6 toasts before the radio comes back. The flag gates the emit connectionError(...) in RadioModel::onConnectionError() so the user gets a clean reconnect experience.
• Cleared in RadioModel::onConnected() (next successful handshake) and in disconnectFromRadio() (user-initiated disconnect, so future errors aren't silently suppressed across an unrelated reconnect).
• Not cleared in connectToRadio() — the reconnect timer calls that on every retry, and the flag must stay on across those retries until the handshake actually completes.

RadioSetupDialog (src/gui/RadioSetupDialog.cpp):

• New QPushButton added at row 3, column 0 of the Radio Information grid (directly under the Options row at row 2)
• Red themed styling (#3a1a1a bg, #ffb080 text, #6e3030 border) to mark it as destructive
• QMessageBox::warning confirmation with Ok / Cancel — defaults to Cancel
• On accept: m_model->rebootRadio() followed by close() so the dialog dismisses immediately and the reconnect overlay is visible against the panadapter

Why no separate "Actions" top-level menu

The issue suggested a top-level Actions menu. The Radio Information group is the natural home for radio-level lifecycle controls (it already houses Remote On, multiFLEX, FlexControl toggles, and lives alongside firmware-update controls in the same dialog), and a dedicated menu for a single command would be premature surface area. If future work adds more remote-management commands (e.g. profile management, network reconfig), an Actions menu can absorb them and the reboot button can move with them — but a one-item menu isn't worth the discoverability cost today.

Risks / caveats

• SmartLink: the command itself transports fine (it's a plain TCP ASCII line, SmartLink is transparent at that layer), but the reconnect path is not SmartLink-aware — it retries the direct TCP endpoint, not a fresh SmartLink handshake. SmartLink users will likely need to reconnect manually after a reboot. Out of scope for this PR; can be tracked separately if it becomes a friction point.
• No backup path: if the reboot wedges the radio's network stack, the operator loses their only remote out. The confirmation dialog warns about the disconnect but does not (yet) call this out — happy to add a stronger warning line if maintainers prefer.

Test plan

• Local build (RelWithDebInfo, macOS arm64) — clean
• Manual verification on connected radio: button visible under Options; confirmation gates the action; dialog closes on confirm; radio reboots; reconnect dialog appears; reconnect completes once radio is back
• Confirmed multiple Connection refused toasts during the reboot window are suppressed (issue feat: remote Reboot and Reboot+Reinitialize commands for connected FlexRadio #3334 follow-up)
• Verify behavior when Cancel is selected on the confirmation (no command sent, dialog stays open)
• Verify button is sensibly disabled / no-op when not connected (currently rebootRadio() early-returns; the button itself is not greyed — could be tightened)
• Verify behavior on disconnect mid-reboot (intentional disconnect should clear m_rebootInProgress so future errors surface)

💻 Generated with Claude Code (Opus 4.7) with architecture by @jensenpat

[aethersdr-agent]

Thanks @jensenpat — nice, tightly scoped change. The reasoning in the PR description is unusually thorough and saved me from re-deriving most of the flag-lifecycle invariants. Especially appreciated calling out that radio reboot initialize was hallucinated rather than just shipping it.

A few non-blocking notes for consideration:

1. m_rebootInProgress can latch indefinitely if the radio never comes back. onConnectionError is the only place errors surface, and it's gated by the flag — but onConnected() is the only clear path. If the reboot wedges the radio's network stack (the risk the PR description already calls out), the 5 s reconnect timer (RadioModel.cpp:523 — minor: PR description says "3-second", code is setInterval(5000)) keeps firing forever with every refused connect silently swallowed. Operator sees no toasts at all and may not realise the radio is stuck.

A simple fix: time-bound the suppression with a one-shot from rebootRadio():

QTimer::singleShot(60'000, this, [this] {
    if (m_rebootInProgress) {
        m_rebootInProgress = false;  // fail open — surface real errors again
    }
});

60 s comfortably covers a healthy 6000/8600 boot but flips the UX from "silent forever" to "silent for one minute, then you find out something's wrong."

2. Button not disabled when disconnected. You already flagged this in the unchecked test-plan items — worth mentioning that RadioModel::connectionStateChanged(bool) already exists and is used elsewhere in this dialog, so wiring rebootBtn->setEnabled(isConnected) would be a one-liner. The early-return in rebootRadio() makes it safe-but-silent today; the disabled state would make it discoverable.

3. Race-free by construction — but worth a sanity check. rebootRadio() schedules QTimer::singleShot(250, this, &RadioModel::forceDisconnect) with this (the RadioModel) as receiver. The dialog's synchronous close() happens immediately after; the timer is parented to the model, not the dialog, so it survives. ✅ I traced this just to make sure the close-then-fire ordering didn't open a window where the dialog could be re-shown and confuse anything. It does not.

Nothing here is a merge blocker — (1) is the only one I'd be slightly nervous to ship without, because it changes a "minor inconvenience on success" into a "permanent silence on failure." But happy to defer to your judgement on whether to add it now or as a follow-up.

---

_{🤖 aethersdr-agent · cost: $12.9655 · model: claude-opus-4-7}

[rfoust]

Built locally from PR head 3b38b628 on macOS arm64:

• git diff --check main..HEAD passed
• cmake -B build -G Ninja -DCMAKE_BUILD_TYPE=RelWithDebInfo passed
• cmake --build build --parallel 8 passed

I found one merge blocker before I would be comfortable landing this.

RadioModel::rebootRadio() currently guards on the LAN socket only:

if (!m_connection || !m_connection->isConnected()) {
    return;
}

That excludes SmartLink/WAN sessions even though RadioModel::isConnected() already treats m_wanConn as connected, and sendCmd() already routes through m_wanConn. Result: in a WAN session the user can confirm Reboot Radio, the setup dialog closes, but no radio reboot command is sent.

I think this needs one of two explicit choices before merge:

1. Support WAN command send by guarding with isConnected() and keeping the existing sendCommand("radio reboot") path, then adjust the confirmation text because WAN reconnect is manual today.
2. Make this intentionally LAN-only by disabling/hiding the button for WAN and saying so in the UI/PR description.

Related smaller issue: the button is also enabled when fully disconnected. In that case rebootRadio() returns and the dialog still closes. It should probably initialize from m_model->isConnected() and subscribe to connectionStateChanged(bool).

Protocol scope looks right: local FlexLib v4.2.18 confirms Radio.RebootRadio() sends radio reboot, and I found no reboot initialize, FactoryReset, or Reinitialize command in the FlexLib zip.

[ten9876]

@jensenpat — pushed a fix-up commit (8b16b3f) addressing the four open review items, following the same pattern we landed on for #3286. Intentionally on top of your branch so the original feature attribution stays clean. Happy to revert if you'd rather take a swing yourself.

Summary:

1. WAN guard fix (@rfoust blocker) — rebootRadio() now gates on isConnected() instead of m_connection->isConnected(), so SmartLink/WAN sessions actually send the command.
2. Confirmation text (@rfoust) — splits into LAN vs. WAN paths; the WAN message explains that SmartLink sessions don't auto-reconnect today and the operator will need to reconnect manually.
3. Button enabled-state (both reviews) — setEnabled(m_model->isConnected()) at construction + subscribed to connectionStateChanged so disconnect/reconnect transitions disable/re-enable the button live. Discoverable rather than silent.
4. 60s fail-open safety timeout (@aethersdr-agent) — added the QTimer::singleShot(60'000, …) from the bot's review verbatim, with a comment explaining the failure mode it guards against.

Local build clean. @rfoust — when you have a moment, this is ready for a re-look against your earlier CHANGES_REQUESTED. I think all four of your items are addressed but you're the closest to it.

[rfoust]

Retested after the fix-up commit and after updating this branch onto current upstream/main. Local current-main merge build passed on macOS arm64, and manual test confirms the reboot flow works. The previous blocker is addressed: rebootRadio() now gates on RadioModel::isConnected(), which covers both LAN and SmartLink/WAN, and sendCmd() already routes WAN commands through m_wanConn. The button enabled-state and WAN-specific reconnect wording also look correct. Good to merge once CI is green.