Repository navigation
Conversation
|
Preparing a ZIP file with standard source tarball and another tarball with pre-built docs for commit 6e4f62a ... |
reklrekl
force-pushed
the
ugreen-hid-subdriver
branch
from
October 18, 2026 23:35
aca9d38 to
d9a5ee6
Compare
reklrekl
force-pushed
the
ugreen-hid-subdriver
branch
from
October 23, 2026 17:54
d9a5ee6 to
7accc5c
Compare
…sue networkupstools#3779] The US2000 hardcodes several HID feature reports (ups.load and input.voltage are always 1, battery.runtime is 0xFFFF on mains, the PresentStatus bits behind LB are never set) and pushes its real telemetry as a 64-byte Input report with ID 0x71 that nothing in its report descriptor describes, so hid2nut cannot reach it. Keep the standard PDC mappings for the values that are correct and decode the 0x71 frame for the rest: output.current, ups.load, input.voltage, output.voltage, battery.current, battery.charger.status, battery.temperature and battery.type. The frame layout is mapped for the US2000 only. Siblings share 2b89:ffff and push a different layout, so the vendor decoder is gated on the USB product string; an unrecognised device still claims the subdriver and keeps every standard PDC mapping. Also register the VID:PID in the upower hwdb. Tested on a US2000 on mains and on battery; no sibling model available. opencode (Muse Spark 1.3, DeepSeek V4.1 Flash) assisted with the subdriver and the firmware analysis. Signed-off-by: reklrekl <reklrekl@users.noreply.github.com>
reklrekl
force-pushed
the
ugreen-hid-subdriver
branch
from
October 23, 2026 19:41
7accc5c to
6e4f62a
Compare
|
✅ Build nut 2.8.5.5902-master completed (commit 82d1fb8917 by @reklrekl)
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Adds a
ugreen-hidsubdriver for the Ugreen US2000 (72 W DC UPS,2b89:ffff), which no subdriver claims today —usbhid-upsfails with"Manufacturer or model not supported!" unless
subdriver=Arduinois setby hand. Problem statement and firmware evidence: #3779. Full
reverse-engineering write-up:
https://github.com/reklrekl/ugreen-ups-re
Why
The device's HID feature reports are partly hardcoded by its firmware:
ups.loadis always1,input.voltageis always1, andbattery.runtimeis0xFFFFwhile on mains. ThePresentStatusbitsbehind
LBhave no code path at all, soLBcannot be raised from thisdevice. Its real measurements are pushed instead — as a 64-byte HID Input
report with ID
0x71that nothing in the device's report descriptordescribes, and which
hid2nuttherefore cannot reach.What
Standard PDC feature-report mappings are kept for the values that are
correct (
battery.charge,battery.voltage,battery.runtime, thePresentStatusflags, the delay timers). The0x71frame is decodedfor
output.current,ups.load,input.voltage,output.voltage,battery.current,battery.charger.status,battery.temperatureandbattery.type. The VID:PID is registered in the upower hwdb.LBis deliberately not synthesized: withbattery.chargelive, the coreignorelboption plusbattery.charge.lowcovers that case.Shared VID:PID
2b89:ffff— please reviewSiblings share these IDs but push a different telemetry layout (the US3000
pushes subtype
0x03frames; see #2987). The subdriver therefore claims onVID/PID alone, so a sibling attaches and keeps every standard PDC mapping
instead of falling through to "unsupported", and gates the vendor decoder
on the USB product string so a non-US2000 gets no values decoded at
another model's offsets.
Effect on existing setups: a sibling configured with
subdriver=Arduinoisunaffected, because an explicit
subdriveris resolved by name before theclaim()loop runs. In auto mode2b89:ffffcurrently matches nosubdriver at all, so no working configuration is downgraded.
-x exploreusers would now get this subdriver instead of
explore-hid. If themaintainers prefer the claim be strict on the US2000 product string, that
is a one-line change.
Testing
US2000 on NUT 2.8.5 master, mains and on battery.
Not tested against the US3000 or any other sibling — no such hardware
available.
AI Disclosure
opencode (Muse Spark 1.3, DeepSeek V4.1 Flash) assisted with the
subdriver and the firmware analysis.
General points
Described the changes in the PR submission or a separate issue, e.g.
known published or discovered protocols, applicable hardware (expected
compatible and actually tested/developed against), limitations, etc.
There may be multiple commits in the PR, aligned and commented with
a functional change. Notably, coding style changes better belong in a
separate PR, but certainly in a dedicated commit to simplify reviews
of "real" changes in the other commits. Similarly for typo fixes in
comments or text documents.
Use of coding helper tools and AI should be disclosed in the commit
or PR comments (it is interesting to know which ones do a decent job).
As with other contributions, a human is responsible and thanked for the
quality and content of the change, and is presumed to have the right to
post that code to be published further under the project's license terms.
Especially with involvement of AI, including modern IDE coding aid,
please be sure to revise that proposed code and documentation changes
follow NUT code style guide -- this helps portability across the decades
worth of supported systems. Notably, avoid Unicode characters where ASCII
text is expected (C sources and headers, manual pages and other
acsiidocinputs). Particularly AI is keen on adding
mdashcharacters instead ofplain ASCII double-dash (which renders into the long dash where applicable).
Please star NUT on GitHub, this helps with sponsorships! ;)
Frequent "underwater rocks" for driver addition/update PRs
Revised existing driver families and added a sub-driver if applicable
(
nutdrv_qx,usbhid-ups...) or added a brand new driver in the othercase.
Did not extend obsoleted drivers with new hardware support features
(notably
blazerand other single-device family drivers for Qx protocols,except the new
nutdrv_qxwhich should cover them all).For updated existing device drivers, bumped the
DRIVER_VERSIONmacroor its equivalent.
For USB devices (HID or not), revised that the driver uses unique
VID/PID combinations, or raised discussions when this is not the case
(several vendors do use same interface chips for unrelated protocols).
For new USB devices, built and committed the changes for the
scripts/upower/95-upower-hid.hwdbfileProposed NUT data mapping is aligned with existing
docs/nut-names.txtfile. If the device exposes useful data points not listed in the file, the
experimental.*namespace can be used as documented there, and discussionshould be raised on the NUT Developers mailing list to standardize the new
concept.
Updated
data/driver.list.inif applicable (new tested device info)Frequent "underwater rocks" for general C code PRs
structure layout and alignment in memory, endianness (layout of bytes and
bits in memory for multi-byte numeric types), or use of generic
intwherelanguage or libraries dictate the use of
size_t(orssize_tsometimes).Progress and errors are handled with
upsdebugx(),upslogx(),fatalx()and related methods, not with directprintf()orexit().Similarly, NUT helpers are used for error-checked memory allocation and
string operations (except where customized error handling is needed,
such as unlocking device ports, etc.)
Coding style (including whitespace for indentations) follows precedent
in the code of the file, and examples/guide in
docs/developers.txtfile.For newly added files, the
Makefile.amrecipes were updated and themake distchecktarget passes.General documentation updates
Added a bullet point into
NEWS.adoc, possibly alsoUPGRADING.adocif there is something packagers or custom-build users should take into
account (new driver categories, configuration options, dependencies...)
Updated
docs/acknowledgements.txt(for vendor-backed device support)Added or updated manual page information in
docs/man/*.txtfilesand corresponding recipe lists in
docs/man/Makefile.amfor new pagesPassed
make spellcheck, updated spell-checking dictionary in thedocs/nut.dictfile if needed (did not remove any words -- themakerule printout in case of changes suggests how to maintain it).
Additional work may be needed after posting this PR
Propose a PR for NUT DDL with detailed device data dumps from tests
against real hardware (the more models, the better).
Address NUT CI farm build failures for the PR: testing on numerous
platforms and toolkits can expose issues not seen on just one system.
the changed codebase.