Refresh SYS_WIFI_STATUS state 5 like every other state #59
Loading…
Reference in a new issue
No description provided.
Delete branch "fix/state-5-refresh"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
State 5 now refreshes on the 5 s interval like any other state, and section 8.1's
exception for it is gone. UF-12 made state 6 sticky and refreshing because a
consumer that missed the first frame still needs to see it, and a failed join is
no different.
A join that never started still reports 5 then 0 and leaves the radio off, so
nothing refreshes with the radio down. The 30 s AP fallback still takes over from
a refreshing state 5.
No codec change, so no vector case and no regeneration.
Tested with
pio test -e native(412 cases), both node builds andhost_sim.CCS-UF-15
One wording point on the spec sentence, plus a note on the description length.
The PR body runs to six paragraphs of rationale. CLAUDE.md asks for a subject and a couple of lines: the decision and the one-sentence rule are enough, the UF-12 comparison and the per-test notes are not.
@ -481,3 +481,2 @@**0x05 `SYS_WIFI_STATUS`** - broadcast on each state change, including state 0 asthe radio goes off, and every 5 s in between while the radio is up. State 5 isnot repeated while the link stays failed.the radio goes off, and every 5 s in between while the radio is up, whatever the"while the radio is up, whatever the state" is ambiguous exactly where this change lands: in state 5 the radio is not up, so a second implementation can read this as still excluding 5 — the bug being fixed. Bound the refresh by the state instead, e.g. "and every 5 s in between in any state but 0".
Both points actioned. The section 8.1 sentence now says what the code does and agrees with section 11's state 6. No further findings.