feat: Only enable IC-9700 spectrum scope when a Web UI session is active

[AI7BQ]

Summary

Problem statement

When running Rigplane in web mode connected to an Icom IC-9700 over LAN, Rigplane automatically enables the radio's waterfall display (Spectrum Scope). If I manually turn the scope off by pressing the M.SCOPE button on the radio, Rigplane automatically forces the waterfall back on after approximately a 30-second delay.

While this behavior is completely understandable when a user is actively viewing the Rigplane Web UI in a browser, it is problematic when the Web UI is not being accessed. The overriding of the radio's physical state prevents manual control of the radio's display when running Rigplane as a headless or background service.

Describe the solution you'd like

I would like Rigplane's web mode backend to dynamically manage the IC-9700's scope state based on client connectivity. Specifically:

1. Scope On: Only send the CI-V commands to enable and poll the spectrum scope when there is at least one active, authenticated browser/WebSocket session open to the Web UI.
2. Scope Off/Idle: When all browser sessions are closed (no active clients connected to the web server), Rigplane should stop forcing the scope state, allowing the radio's physical display settings to be controlled manually without being overridden by the 30-second background polling loop.

Describe alternatives you've considered

• Manually turning off the scope repeatedly: This is ineffective as the background sync loop overrides the manual change every 30 seconds.

Additional context

• Rig: Icom IC-9700 connected via LAN.
• Observed Behavior: The 30-second reset cycle strongly points to a background state-enforcement or hydration loop that assumes the Web UI always requires scope data, regardless of whether a client is actually connected to ingest the stream.

Log output

WARNING scope-health: all-zero frames for 14s, re-enabling scope (attempt 1/3)
INFO radio-poller: scope enabled
INFO radio-poller: scope controls fetched (receiver=0)
WARNING scope-health: all-zero frames for 15s, re-enabling scope (attempt 1/3)
INFO radio-poller: scope enabled
INFO radio-poller: scope controls fetched (receiver=0)
WARNING scope-health: all-zero frames for 18s, re-enabling scope (attempt 1/3)
INFO radio-poller: scope enabled
INFO radio-poller: scope controls fetched (receiver=0)

[morozsm]

thank you, I'm going to look into it.
But I'm not sure about one thing. As far as I remember, when SCOPE is turned off on the radio - it stops to send scope to the application.
This requires additional research.

[AI7BQ]

Your recollection is correct. If the M-SCOPE button is pressed on the radio to turn off the scope, the radio stops sending scope data to Rigplane, but about 30 seconds later Rigplane forces it back on whether or not there is a browser client attached to Rigplane. I'm requesting that Rigplane not force the scope on condition if nobody is viewing the WEB UI.

…

On Wed, Jul 8, 2026 at 2:26 PM Sergey Morozik ***@***.***> wrote: *morozsm* left a comment (rigplane/rigplane-core#1904) <#1904 (comment)> thank you, I'm going to look into it. But I'm not sure about one thing. As far as I remember, when SCOPE is turned off on the radio - it stops to send scope to the application. This requires additional research. — Reply to this email directly, view it on GitHub <#1904?email_source=notifications&email_token=BKP7Z2R55TEBQXAXPKR5AB35D24A3A5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIOJRHEZTMMZVGY22M4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KYZTPN52GK4S7MNWGSY3L#issuecomment-4919363565>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BKP7Z2SZE4ZFX476FZBQNJT5D24A3AVCNFSNUABGKJSXA33TNF2G64TZHMYTCNRWGM3TONBTGU5US43TOVSTWNBYGA3DANJXGA4TBILWAI> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/BKP7Z2QFHMJIO4Q4UFQ6NRL5D24A3A5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIOJRHEZTMMZVGY22M4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KUZTPN52GK4S7NFXXG> and Android <https://github.com/notifications/mobile/android/BKP7Z2THJMZ2NMXUJXPD4ID5D24A3A5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIOJRHEZTMMZVGY22M4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2K4ZTPN52GK4S7MFXGI4TPNFSA>. Download it today! You are receiving this because you authored the thread.Message ID: ***@***.***>

[morozsm]

Thank you, that confirms the behavior.

The problem is clear now: RigPlane's scope-health watchdog is treating the radio's M-SCOPE-off state as a failed/stalled scope stream and then re-enables the scope, even when nothing in the Web UI is actually watching the scope.

We'll fix this in the next release. The intended behavior should be client/user driven:

• if there is no active Web UI scope viewer, RigPlane should not force the radio scope back on;
• if the Web UI is using the scope and the stream stalls unexpectedly, the existing recovery behavior still makes sense;
• the Web UI should also get an explicit scope on/off control, so the scope can be turned off from the radio front panel or from the browser, and turned back on from either side without the two fighting each other.

Thanks for the clarification and the logs. This is enough to track the fix.

[AI7BQ]

I need your help please. How do I include the switch --log-level DEBUG when launching rigplane? This is what I currently use:

/srv/rigplane/.venv/bin/rigplane --backend lan --model IC-9700 web --host 0.0.0.0 --port 9999 --radio-host 192.168.1.19 --radio-user AI7BQ --radio-pass-file /srv/rigplane/passfile.conf --rigctld --rigctld-port 4532 --wsjtx-compat