Skip to content

nutdrv_hashx: add opt-in USB monitoring for Keen 2000 - #3737

Draft
khalilyamoun wants to merge 3 commits into
networkupstools:masterfrom
khalilyamoun:keen-2000-hashx-usb-monitor
Draft

khalilyamoun wants to merge 3 commits into
networkupstools:masterfrom
khalilyamoun:keen-2000-hashx-usb-monitor

Conversation

@khalilyamoun

Copy link
Copy Markdown

Adds experimental USB monitoring to nutdrv_hashx for the HashX status tunnel observed on an nJoy Keen 2000 (0764:0601). It requires both port=auto and usb_monitor. The USB ID is shared by other devices, so a complete valid protocol response is required before publishing telemetry.

The USB path sends only the B status query, drains queued input with a bounded limit, reassembles and validates length-prefixed replies, and marks failed or malformed exchanges stale. Complete zero-load replies are preserved. It registers no USB instant commands and sends no session, settings, battery-test, beeper or shutdown commands. The patch includes protocol/transaction tests, the manual, NEWS and an explicitly experimental one-star HCL entry.

One controlled AC-mode USB handoff was tested on one unit after an existing PowerMaster+ session. The driver exited successfully with no status-query errors. Six readings agreed with a nearby passive vendor frame within the comparison tolerances: input 241 V, output 243 V, load 6%, charge 100%, battery 27.2 V and runtime 2400 s. The nearby frame reported 27.1 V battery voltage; the other five values were identical. Samples were not synchronous. NUT reported OL HB and charger state resting.

PowerMaster+ polling was verified restored afterward. An immediate eight-second observation found no new polls; a later 30-second passive audit captured 15 complete replies and 15 exact successful status queries, with no frame errors or kernel drops. Both vendor services were active and current vendor readings matched the latest passive frame. This establishes current monitoring availability, without proving uninterrupted protection during startup. The experimental driver was not left deployed.

Validation against upstream base 1a8369f:

  • USB/serial, serial-only and USB-only builds passed. Dual-transport make check passed all 14 tests, including 551 checks in the new protocol suite.
  • The standalone suite passed 551 checks with strict C99 warnings treated as errors and with AddressSanitizer/UndefinedBehaviorSanitizer. The offline capture analyzer passed 13 tests.
  • Updated manual rendering, HCL generation/formatting, make distcheck-light, clean-base patch application and git diff --check passed. distcheck-light permits placeholder prebuilt manuals; the changed manual was separately rendered with a2x.

Cold startup, reconnect/timeout recovery and battery/low-battery status semantics remain unvalidated. Replies have no transaction ID, so a response arriving after the queue drain cannot be conclusively correlated with the new query. USB shutdown is unavailable. Historical intermittent zero-load readings with usbhid-ups were not reproduced; this provides an alternative telemetry path and does not establish a defect or fix in the current HID decoder.

Related report: nJoy Keen 2000 compatibility, #2650.

Contribution preparation used AI assistance from OpenAI Codex (GPT-6; the exact runtime variant is not exposed in this session).

Add bounded HashX status transport for explicitly enabled USB monitoring.
One Keen 2000 AC-mode handoff matched nearby vendor readings; cold startup,
reconnect, battery operation and shutdown remain unvalidated or unavailable.

Signed-off-by: Khalil Yamoun <khalil.yamoun@gmail.com>
@github-actions

github-actions Bot commented Oct 7, 2026 •

Copy link
Copy Markdown

Preparing a ZIP file with standard source tarball and another tarball with pre-built docs for commit e7c9c99 ...

@jimklimov jimklimov added enhancement USB serial port Incorrect or missing readings On some devices driver-reported values are systemically off (e.g. x10, x0.1, const+Value, etc.) AI For good or bad, machine tools are upon us. Humans are still the responsible ones. labels Oct 7, 2026
@jimklimov jimklimov added this to the 2.8.6 milestone Oct 7, 2026
@jimklimov

Copy link
Copy Markdown
Member

Thanks, got a quick reply from CI: it seems the spelling dictionary and/or checked text should be updated.

To clarify, when you mention "the HashX status tunnel" - does it use additional information from an additional physical link, or for this device everything can go over USB and the port=... indeed is not required to point to a serial port name?

Comment thread drivers/nutdrv_hashx.c
USBFreeExactMatcher(hashx_reopen_matcher);
USBFreeRegexMatcher(hashx_regex_matcher);
hashx_usb_free_device();
return;

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Related to the question whether it is strictly USB-or-Serial vs. possibly USB-and-Serial (in the latter case, it should not return here and fall through to ser_close instead).

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, it is USB or serial for each driver instance. The USB branch returns from upsdrv_initups() before ser_open(), so no serial descriptor is opened in that mode. That is why cleanup returns after releasing the USB resources.

@khalilyamoun

Copy link
Copy Markdown
Author

Thanks! Everything for this monitoring mode goes over USB; there is no second physical link or serial port. By "tunnel" I meant the HashX B\r status request/reply carried in the USB interrupt reports and decoded by the existing status parser. So port=auto is intentional here, with usb_monitor selecting that path.

I also found the spelling failures: HashX, nJoy, handoff and unvalidated in the new documentation. The proper names belong in the dictionary, and the other wording can be cleaned up.

@github-actions github-actions Bot deleted a comment from AppVeyorBot Oct 23, 2026
@github-actions github-actions Bot deleted a comment from AppVeyorBot Oct 23, 2026
…and dictionary [networkupstools#3737]

Signed-off-by: Jim Klimov <jimklimov+nut@gmail.com>
@github-actions github-actions Bot deleted a comment from AppVeyorBot Oct 26, 2026
@github-actions github-actions Bot deleted a comment from AppVeyorBot Oct 26, 2026
@AppVeyorBot

Copy link
Copy Markdown

✅ Build nut 2.8.5.5918-master completed (commit b72f5c02ab by @jimklimov)

@AppVeyorBot

Copy link
Copy Markdown

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

AI For good or bad, machine tools are upon us. Humans are still the responsible ones. enhancement Incorrect or missing readings On some devices driver-reported values are systemically off (e.g. x10, x0.1, const+Value, etc.) serial port USB

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants