christian/Nextcue
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Companion module 0.1.5: settings save even before Resi answers

Browse Source 
While the connection wasn't connected, nothing in its settings could be
saved. The saved decoder showed as "??" because the list only fills once
Resi answers, and a cue refresh that had never been saved showed as 0, below
its minimum. Either blocks Save, including the login change that would have
fixed the connection. That's how North Attleboro's connection stayed on a
locked login.

- The saved decoder is always a choice, "(not connected to Resi yet)" until
  Resi answers.
- An upgrade script fills settings an older connection never saved with
  their defaults (and leaves a complete one alone).
- Event details are read once per event instead of on every cue refresh:
  one Resi request fewer every few seconds on a shared account.
- Cue requests share the login/rate-limit hold-off; "Loaded N cues" and
  repeated cue-refresh failures are logged once, not every few seconds.
- "inf0" in the decoder info poll label.

source/config_test.js covers all of it (6 tests; the first fails on 0.1.4).
backoff_test.js 5/5 and the estimator matrix still pass.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This commit is contained in:
christian
2026-10-07 17:27:34 -04:00
co-authored by Claude Opus 5.5
parent 1a658875bc
commit 0327d6a9f8
9 changed files with 218 additions and 19 deletions
Download Patch File Download Diff File Expand all files Collapse all files
source/HELP.md
+14
View File
@@ -241,3 +241,17 @@ seconds, and each restart signed in again from scratch, outside the hold-off.
yet … will keep trying", starts the account poll, and the hold-off paces retries
- once Resi answers, the configured decoder is picked up automatically
- saving new credentials clears the old hold-off and starts over
## Settings that always save (0.1.5)
While the connection wasn't connected to Resi, its settings couldn't be saved at all:
the saved decoder showed as "??" because the list only fills once Resi answers, and a
cue refresh that had never been saved showed as 0, below its minimum. Either one blocks
Save in Companion, including the login change that would have fixed the connection.
- the saved decoder is always offered, as "(not connected to Resi yet)" until Resi answers
- an upgrade step fills any setting an older connection never saved with its default
- event details are read once per event instead of on every cue refresh, which is one
Resi request fewer every few seconds
- cue requests share the login/rate-limit hold-off, and "Loaded N cues" and repeated
cue-refresh failures are logged once, not every few seconds