feat(atx): surface extension board responsiveness in ATX power control - #1526
feat(atx): surface extension board responsiveness in ATX power control#1526ilyongnoh-ux wants to merge 1 commit into
Conversation
When the ATX extension board is unpowered, miswired or broken, it never sends a status line over serial. The UI showed only grey LEDs, giving no hint that the board itself is not responding (see jetkvm#327 and similar community reports). Track the unix time of the last status line received by the ATX worker (reset on mount) and consider the board responsive if a line arrived within the last 10 seconds: - ATXState gains a `responsive` field (existing fields unchanged). - getATXState computes it from the last-line timestamp; the atxState events pushed right after a line is read report responsive=true, and the periodic/connect MQTT snapshots use the same helper so the retained topic does not flap. - The ATX power control UI polls getATXState every 5 seconds while open and shows an amber warning when the board is not responding, suggesting to check the RJ-12 cable and board power. Controls stay enabled so the user can still try. The message is localized for all supported locales. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
|
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 111eb94b72
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| HDD: ledHDDState.Load(), | ||
| Power: ledPWRState.Load(), | ||
| HDD: ledHDDState.Load(), | ||
| Responsive: atxBoardResponsive(), |
There was a problem hiding this comment.
With the default MQTT debounce_ms of 500, this snapshot still goes through publishATXState, whose debouncer only republishes on Power/HDD changes or the first frame and otherwise returns early for unchanged LED states. When the board stops sending lines but the last Power/HDD values are unchanged, the periodic snapshot computes Responsive: false here but no retained atx/state update is emitted, so MQTT/Home Assistant keeps reporting the board as responsive until an LED transition or MQTT manager restart. Publish responsiveness-only changes outside the HDD debounce path or include Responsive in the debounce change detection.
Useful? React with 👍 / 👎.
2 participants
What
When the ATX extension board is unpowered, miswired, or the RJ-12 cable is bad, the board sends no status lines at all — but the UI shows only greyed-out LEDs, indistinguishable from "PC is off". Users cannot tell that the board itself is not talking to the device, and several reports of exactly this have gone unresolved for a long time.
How
atxLastLineTime, reset on mount).ATXStategains a backward-compatibleresponsivefield (existing fields untouched): true if a line arrived within the last 10s. TheatxStateevents pushed by the worker set it to true (a line just arrived);rpcGetATXStateand both MQTT snapshot publishers compute it via a shared helper so the retained topic doesn't flap.getATXStateevery 5s while open and shows an amber warning above the controls whenresponsive === false: "No response from the ATX extension board. Check the RJ-12 cable and board power." Buttons stay enabled. Older backends (field absent) show no banner.localization/I18N_BEST_PRACTICES.md.Testing
Deployed on a JetKVM (v2, system 0.2.8, 0.5.8-based build) with an ATX board that is genuinely unresponsive (0 bytes on the extension UART since boot): the banner appears in the popover and updates with the 5s poll; the rest of the UI is unaffected. UI build (paraglide compile + tsc + vite) passes.
🤖 Generated with Claude Code