idowell-hid: add GoldenMate 1000VA/800W LiFePO4 (USB ID 06da:ffff)

[bshor]

Summary

GoldenMate ships the same -BMS- firmware with an identical 291-byte HID descriptor across multiple USB vendor/product IDs. The 075d:0300 variant was already added to this subdriver in #3015. This PR adds 06da:ffff (Phoenixtec VID), which was previously falling through to the generic Phoenixtec/Liebert HID subdriver.

Device: GoldenMate 1000VA/800W Sinewave UPS with LiFePO4 Battery (230Wh), USB ID 06da:ffff, manufacturer string -BMS-, product string Smart-Battery.

Problem: Without this change the device matches Phoenixtec/Liebert HID 0.41 and reports battery.runtime = 599940 seconds — a firmware placeholder value. The iDowell subdriver mappings (which were already extended for the identical 075d:0300 firmware) handle this device correctly.

Evidence that HID descriptors are identical: Both devices report the same 291-byte report descriptor (05 84 09 04 a1 01 ...), the same 28 HID objects, and the same LogMax < LogMin quirks in ReportID 0x01 and 0x02.

Tracked in #3501.

Changes

• drivers/idowell-hid.c: add 06da:ffff to the USB device table
• data/driver.list.in: split GoldenMate entry into two lines with correct model names, USB IDs, support level 2, and issue links

[github-actions]

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

[jimklimov]

Hello, thanks for the contribution, but it would not work the way it is originally posted, I think (might hijack devices not intended for this subdriver) - see also mge-hid.c which also deals with PHOENIXTEC_VENDORID.

To make the PR acceptable, you would need to:

• actually define the vendor ID in the subdriver source (this is used by parser into udev rules, nut-scanner helper data, etc.), and refer to it from the ...device_table[]:

/* Phoenixtec Power Co., Ltd */
#define PHOENIXTEC_VENDORID     0x06da

...
    { USB_DEVICE(PHOENIXTEC_VENDORID, 0xffff), NULL },

• Revise the idowell_claim() method to do something like what mge_claim() does to pick assumed-handled devices by vendor/product strings, and defer others to liebert-hid as the default sink.
• Bump the IDOWELL_HID_VERSION
• Adding a bullet point in NEWS.adoc would be a nice touch :)
• While at it, adding a Signed-off-by line into the commit comment would be another nice touch, see https://github.com/networkupstools/nut/wiki/Code-contributions,-PRs,-PGP-and-DCO

Looking forward to getting this merged (mergeable) :)

[AppVeyorBot]

✅ Build nut 2.8.5.4863-master completed (commit 1f91f12f6a by @bshor)

• artifacts
• A 7-zip archive with built NUT for Windows debug binaries is temporarily available: NUT-for-Windows-x86_64-SNAPSHOT-2.8.5.4863-master.7z

[AppVeyorBot]

✅ Build nut 2.8.5.4863-master completed (commit 1f91f12f6a by @bshor)

[bshor]

Thanks for the detailed review! I've force-pushed a revision that addresses all the points:

• Named vendor ID: added #define PHOENIXTEC_VENDORID 0x06da and use it for the 0x06da:0xffff device-table entry instead of the bare literal.
• Guarded claim: reworked idowell_claim() to mirror mge_claim()'s approach — on the shared PHOENIXTEC_VENDORID it now only claims the GoldenMate by its firmware strings (manufacturer -BMS- / product Smart-Battery) and returns 0 otherwise, so AEG PROTECT NAS still goes to mge-hid and everything else on 0x06da falls through to liebert-hid as the default sink. The 0x075d iDowell VID is unique, so it stays claimed unconditionally. (Probe order is mge -> idowell -> liebert, so this intercepts only GoldenMate before liebert.)
• Version: bumped IDOWELL_HID_VERSION to 0.21.
• NEWS.adoc: added a bullet under the usbhid-ups driver updates.
• DCO: the commit is now Signed-off-by.

I don't have a second 0x06da (AEG/Liebert) device on hand to confirm the deferral empirically, but the string gate is conservative — please let me know if you'd prefer a tighter match (e.g. requiring both strings).

[AppVeyorBot]

❌ Build nut 2.8.5.4865-master failed (commit 2e2fc643f6 by @bshor)

• artifacts (if any)

[AppVeyorBot]

✅ Build nut 2.8.5.4866-master completed (commit 7b439e97bc by @bshor)

• artifacts
• A 7-zip archive with built NUT for Windows debug binaries is temporarily available: NUT-for-Windows-x86_64-SNAPSHOT-2.8.5.4866-master.7z

[AppVeyorBot]

✅ Build nut 2.8.5.4866-master completed (commit 7b439e97bc by @bshor)

[jimklimov]

Looks great, thanks!

Out of curiosity, was AI involved in this PR or is it all a manually investigated and made change?

[bshor]

Definitely AI assisted -- Claude Code Opus. I'm overseeing it, but it's handling most of the work.