feat(rbn): Reduce network traffic from the Reverse Beacon Network

[n7wlc]

The connection to RBN produces about 6 spots/second. If the user (client side) has not enabled the RBN, the server processes these spots even though the information is never used.

Now the RBN connection is not made until the first request comes in from the client. The connection is maintained until 5 minutes after the last request. At that point the connection is closed. Spot cleanup continues normally.

What does this PR do?

see above

Type of change

• Bug fix
• New feature
• Performance improvement
• Refactor / code cleanup
• Documentation
• Translation
• Map layer plugin

How to test

1. Comment out line 80 in server.js ("installRateLimiter();")
2. Start the server: npm run start
3. Start the client.
4. Observe server log: No lines with "[RBN]" until after it is enabled in the client.
   Note: There are no changes to the client code. Only server/routes/rbn.js

Checklist

• App loads without console errors
• Tested in Dark, Light, and Retro themes
• Responsive at different screen sizes (desktop + mobile)
• If touching server.js: caches have TTLs and size caps (we serve 2,000+ concurrent users)
• If adding an API route: includes caching and error handling
• If adding a panel: wired into Modern, Classic, and Dockable layouts
• No hardcoded colors — uses CSS variables (var(--accent-cyan), etc.)
• No .bak, .old, console.log debug lines, or test scripts included

[accius]

Thanks for this — the goal is a good one. ~6 spots/s of parsing and map churn for a feed nobody is looking at is real work on a Pi 3, and the change itself is small and readable. CI is green (format, JSON keys, Node 22 tests) and it applies cleanly to Staging.

I can't merge it as written, though, because the RBN stream isn't only consumed by the two /api/rbn/* endpoints — it's a shared server-side data source, and this PR changes that contract without the other consumers knowing.

Blocking

1. Band Openings goes dark. server/routes/band-openings.js reads ctx.rbnSpotsByDX directly from a 60 s background sampler to build its 3 h baseline — no client request involved (its header comment says the RBN cache "fills autonomously"). With this PR the map only fills while someone has the RBN layer, the RBN panel, or the IBP panel open. On a self-hosted install Band Openings would sit in a permanent warming state or show cluster-derived openings only. The test plan only watches for [RBN] log lines, so this wouldn't have shown up.

2. /api/health reports RBN as down for most self-hosters. checkRbn() in server/health.js returns down whenever the socket isn't connected, and this PR makes "not connected" the normal idle state. Anyone who never uses RBN gets a permanently degraded health endpoint. (The hosted site is unaffected — someone is always polling — and watchtower reads the same field, so it wouldn't alert there either.)

Worth knowing

3. Cold-start gap. Today the server always holds 30 min of history, so enabling RBN shows spots immediately. With lazy connect, the first request opens the socket and the panel is empty until spots accumulate — roughly the length of the chosen window. Never happens on the hosted site; on a single-user install it's visible the first time RBN is turned on after a quiet spell.

4. Minor. The error handler still reconnects unconditionally, so an idle connection that errors (rather than closes) comes back and idles out again — inconsistent with the intent. And I'd remove the commented-out maintainRBNConnection(7000) rather than leave it.

What I'd like to see

Any of these would get it over the line:

• Keep lazy connect, but make Band Openings a consumer too. Export a small touch()/ensureConnected() from rbn.js and have the band-openings sampler call it (or drive the idle timer from any reader of the spot map, not just the HTTP routes).
• Teach health the difference between "idle by design" and "down". Report ok with a detail like idle — no RBN consumers in the last 5 min when nothing has asked for spots within the TTL, and only down when a consumer wanted it and the socket isn't up.
• Or gate the whole thing behind an env flag — e.g. RBN_LAZY_CONNECT=true, default off — so the hosted instance and existing installs keep today's behaviour while Pi users opt in. That also sidesteps the cold-start gap for everyone who didn't ask for it.

Happy to help with whichever direction you prefer. 73 de K0CJH

[n7wlc]

Dear Chris, Thanks for the feedback on my PR.  I had a couple of questions. How do I enable Band Openings in the UI?  I can't find it in the settings menus.  I'd like to see how that works before I delve into that source code.  This is v26.7.4, correct?  (I should have grepped for instances of "rbn" elsewhere in the code.) In my local instance, /api/health reports "All Systems Operational".  Only when I "View as JSON" do I see that RBN is down.  So a casual user won't notice the problem.  Only delving deeper would you see the error status.  (Thanks for /api/health!  I didn't know that existed.) On #3, cold-start gap.  I thought about that.  Spots do accumulate at 6 per second, so the panel doesn't remain empty for very long.  True, the 30-min history is empty.  I'm trying to think of the use-case where the server is running on a Pi but not client, then the user starts the client wanting RBN.  (Yeah, I have one where I used a bluetooth beacon to tell when I'm in the ham shack: it turns the display on/off.  But then again I turn off almost all of the reporting and use the display to see graphically where the WSJT-X decodes are coming from.  It's a 7- in LCD display and doesn't give me much real estate to view a lot of data -- just the clock header and the map.)  On #4 where the error handler reconnects unconditionally.  That isn't really a problem.  The connection is closed or never opened.  It is not connected but idle.  So no error condition can result from the connection.  (The garbage collector might dispose of the error handler after the connection become null.) Thanks again for the feedback.  Any of the three suggestions could work.  Probably all three would be necessary given Band Openings.  Let me know how to enable Band Openings. 73 de Mike, N7WLC

On Mon, 2026-09-14 at 02:13 -0700, accius wrote: @accius requested changes on this pull request. Thanks for this — the goal is a good one. ~6 spots/s of parsing and map churn for a feed nobody is looking at is real work on a Pi 3, and the change itself is small and readable. CI is green (format, JSON keys, Node 22 tests) and it applies cleanly to Staging. I can't merge it as written, though, because the RBN stream isn't only consumed by the two /api/rbn/* endpoints — it's a shared server- side data source, and this PR changes that contract without the other consumers knowing. Blocking1. Band Openings goes dark. server/routes/band-openings.js reads ctx.rbnSpotsByDX directly from a 60 s background sampler to build its 3 h baseline — no client request involved (its header comment says the RBN cache "fills autonomously"). With this PR the map only fills while someone has the RBN layer, the RBN panel, or the IBP panel open. On a self-hosted install Band Openings would sit in a permanent warming state or show cluster-derived openings only. The test plan only watches for [RBN] log lines, so this wouldn't have shown up. 2. /api/health reports RBN as down for most self-hosters. checkRbn() in server/health.js returns down whenever the socket isn't connected, and this PR makes "not connected" the normal idle state. Anyone who never uses RBN gets a permanently degraded health endpoint. (The hosted site is unaffected — someone is always polling — and watchtower reads the same field, so it wouldn't alert there either.) Worth knowing3. Cold-start gap. Today the server always holds 30 min of history, so enabling RBN shows spots immediately. With lazy connect, the first request opens the socket and the panel is empty until spots accumulate — roughly the length of the chosen window. Never happens on the hosted site; on a single-user install it's visible the first time RBN is turned on after a quiet spell. 4. Minor. The error handler still reconnects unconditionally, so an idle connection that errors (rather than closes) comes back and idles out again — inconsistent with the intent. And I'd remove the commented-out maintainRBNConnection(7000) rather than leave it. What I'd like to seeAny of these would get it over the line: * Keep lazy connect, but make Band Openings a consumer too. Export a small touch()/ensureConnected() from rbn.js and have the band- openings sampler call it (or drive the idle timer from any reader of the spot map, not just the HTTP routes). * Teach health the difference between "idle by design" and "down". Report ok with a detail like idle — no RBN consumers in the last 5 min when nothing has asked for spots within the TTL, and only down when a consumer wanted it and the socket isn't up. * Or gate the whole thing behind an env flag — e.g. RBN_LAZY_CONNECT=true, default off — so the hosted instance and existing installs keep today's behaviour while Pi users opt in. That also sidesteps the cold-start gap for everyone who didn't ask for it. Happy to help with whichever direction you prefer. 73 de K0CJH — Reply to this email directly, view it on GitHub [1], or unsubscribe [2]. Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS [3] and Android [4]. Download it today! You are receiving this because you authored the thread.Message ID: ***@***.***>

[1] view it on GitHub #1187?email_source=notifications&email_token=ANH4ULFTH7NMB2SH7MJZT2L5O6ZB5A5CNFSNUABKM5UWIORPF5TWS5BNNB2WEL2QOVWGYUTFOF2WK43UKJSXM2LFO4XTKMJZGU4TENZXG4Z2M4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KYZTPN52GK4S7MNWGSY3L#pullrequestreview-5195927773 [2] unsubscribe https://github.com/notifications/unsubscribe-auth/ANH4ULEMWA44OXBAEAHRAEL5O6ZB5AVCNFSNUABGKJSXA33TNF2G64TZHMYTCNBVGY3TKNBUGY5US43TOVSTWNJUGQZDSNBYGIYDFILWAI [3] iOS https://github.com/notifications/mobile/ios/ANH4ULFWARN6RROLWBOWDBL5O6ZB5A5CNFSNUABKM5UWIORPF5TWS5BNNB2WEL2QOVWGYUTFOF2WK43UKJSXM2LFO4XTKMJZGU4TENZXG4Z2M4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KUZTPN52GK4S7NFXXG [4] Android https://github.com/notifications/mobile/android/ANH4ULBT3PGTPOKQPGGFAV35O6ZB5A5CNFSNUABKM5UWIORPF5TWS5BNNB2WEL2QOVWGYUTFOF2WK43UKJSXM2LFO4XTKMJZGU4TENZXG4Z2M4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2K4ZTPN52GK4S7MFXGI4TPNFSA

[n7wlc]

Dear Chris, I am going to withdraw this PR for reducing RBN network traffic. The first blocking problem is "Band Openings goes dark."   It appears that it is impossible to turn off the Band Openings feature.  I've looked through all the occurrences of band-openings, bandOpenings, etc in the client code.  I see no way to turn off this feature.  If the objective is to allow RBN traffic if Band Openings is active, then there is no point to enabling a lazy connect to the RBN feed:  the feed will always be active. Band Openings is an interesting feature that I was not aware of.  The openings are determined by continent.  I have heard many East Coast stations working Europe while I (on the West Coast) can't hear Europe at all.  A notification that Europe is open does not help a West Coast station.  (I'm sure the same happens with opposite coasts working East Asia.)  It might be better if the Band Openings regions were smaller than the entire continent.  Perhaps CQ Zone.  (With fewer spots per zone, one would need to test to see if the statistical model still holds.)  I would love this feature to work and would keep the RBN feed on, if I could receive notifications of relevant band openings. Sincerely, Mike Bass, N7WLC

On Mon, 2026-09-14 at 02:13 -0700, accius wrote: @accius requested changes on this pull request. Thanks for this — the goal is a good one. ~6 spots/s of parsing and map churn for a feed nobody is looking at is real work on a Pi 3, and the change itself is small and readable. CI is green (format, JSON keys, Node 22 tests) and it applies cleanly to Staging. I can't merge it as written, though, because the RBN stream isn't only consumed by the two /api/rbn/* endpoints — it's a shared server- side data source, and this PR changes that contract without the other consumers knowing. Blocking1. Band Openings goes dark. server/routes/band-openings.js reads ctx.rbnSpotsByDX directly from a 60 s background sampler to build its 3 h baseline — no client request involved (its header comment says the RBN cache "fills autonomously"). With this PR the map only fills while someone has the RBN layer, the RBN panel, or the IBP panel open. On a self-hosted install Band Openings would sit in a permanent warming state or show cluster-derived openings only. The test plan only watches for [RBN] log lines, so this wouldn't have shown up. 2. /api/health reports RBN as down for most self-hosters. checkRbn() in server/health.js returns down whenever the socket isn't connected, and this PR makes "not connected" the normal idle state. Anyone who never uses RBN gets a permanently degraded health endpoint. (The hosted site is unaffected — someone is always polling — and watchtower reads the same field, so it wouldn't alert there either.) Worth knowing3. Cold-start gap. Today the server always holds 30 min of history, so enabling RBN shows spots immediately. With lazy connect, the first request opens the socket and the panel is empty until spots accumulate — roughly the length of the chosen window. Never happens on the hosted site; on a single-user install it's visible the first time RBN is turned on after a quiet spell. 4. Minor. The error handler still reconnects unconditionally, so an idle connection that errors (rather than closes) comes back and idles out again — inconsistent with the intent. And I'd remove the commented-out maintainRBNConnection(7000) rather than leave it. What I'd like to seeAny of these would get it over the line: * Keep lazy connect, but make Band Openings a consumer too. Export a small touch()/ensureConnected() from rbn.js and have the band- openings sampler call it (or drive the idle timer from any reader of the spot map, not just the HTTP routes). * Teach health the difference between "idle by design" and "down". Report ok with a detail like idle — no RBN consumers in the last 5 min when nothing has asked for spots within the TTL, and only down when a consumer wanted it and the socket isn't up. * Or gate the whole thing behind an env flag — e.g. RBN_LAZY_CONNECT=true, default off — so the hosted instance and existing installs keep today's behaviour while Pi users opt in. That also sidesteps the cold-start gap for everyone who didn't ask for it. Happy to help with whichever direction you prefer. 73 de K0CJH — Reply to this email directly, view it on GitHub [1], or unsubscribe [2]. Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS [3] and Android [4]. Download it today! You are receiving this because you authored the thread.Message ID: ***@***.***>

[1] view it on GitHub #1187?email_source=notifications&email_token=ANH4ULFTH7NMB2SH7MJZT2L5O6ZB5A5CNFSNUABKM5UWIORPF5TWS5BNNB2WEL2QOVWGYUTFOF2WK43UKJSXM2LFO4XTKMJZGU4TENZXG4Z2M4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KYZTPN52GK4S7MNWGSY3L#pullrequestreview-5195927773 [2] unsubscribe https://github.com/notifications/unsubscribe-auth/ANH4ULEMWA44OXBAEAHRAEL5O6ZB5AVCNFSNUABGKJSXA33TNF2G64TZHMYTCNBVGY3TKNBUGY5US43TOVSTWNJUGQZDSNBYGIYDFILWAI [3] iOS https://github.com/notifications/mobile/ios/ANH4ULFWARN6RROLWBOWDBL5O6ZB5A5CNFSNUABKM5UWIORPF5TWS5BNNB2WEL2QOVWGYUTFOF2WK43UKJSXM2LFO4XTKMJZGU4TENZXG4Z2M4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KUZTPN52GK4S7NFXXG [4] Android https://github.com/notifications/mobile/android/ANH4ULBT3PGTPOKQPGGFAV35O6ZB5A5CNFSNUABKM5UWIORPF5TWS5BNNB2WEL2QOVWGYUTFOF2WK43UKJSXM2LFO4XTKMJZGU4TENZXG4Z2M4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2K4ZTPN52GK4S7MFXGI4TPNFSA