Hello, and thanks for the clarifications.
As described, the change does not seem to be too complex on the NUT
project's side, the PR posted below took about an hour with some research
and this write-up, so I'm not sure I can put a price tag on it :) A
donation at https://opencollective.com/networkupstools or
https://github.com/sponsors/networkupstools would be welcome though, more
so a recurring one.
The technicalities about it have several correct answers, depending on
the situation:
* If your testbed has NUT v2.8.1 (packaged or otherwise available), its
`usbhid-ups` driver should newly support a `subdriver` option -
specifically to help gauge support of existing code paths for `vendorid`
and `productid` values that are not yet built into the binaries as known
supported handlers for these devices. So hopefully (this feature was not
extensively tested yet) you can in fact run `usbhid-ups -s test -x
port=auto -x vendorid=0483 -x productid=a430 -x subdriver="cyberpower"
-DDDDDD -d 1` and get a detailed log of NUT driver start-up (devices found,
matching attempts tried and if they succeeded, first device data walk...)
and eventually a list of collected data points similar to what the `upsc`
client would report in production.
* If you can build NUT from sources on a system (PC, SBC...) connected to
an UPS for the testing, this would be best for practical testing (if the
proposed change works out of the box) and for possible iterations on the
modified code (especially if the first attempt does not get it right, or if
there would be some more work needed beside "knowing" a couple of new
IDs)
:)
The Wiki article
https://github.com/networkupstools/nut/wiki/Building-NUT-for-in%E2%80%90place-upgrades-or-non%E2%80%90disruptive-tests
details custom builds of NUT for testing from the build workspace (not
necessarily installing into the OS) and prerequisites for a number of
platforms based on experience with the NUT CI farm summarized at
https://networkupstools.org/docs/user-manual.chunked/_build_prerequisites_to_make_nut_from_scratch_on_various_operating_systems.html
/ https://github.com/networkupstools/nut/blob/master/docs/config-prereqs.txt.
I've posted the anticipated change set as a pull request
https://github.com/networkupstools/nut/pull/2312 so to build it from
sources per instructions in Wiki, you would need to clone the PR's source
branch, e.g.:
:; git clone https://github.com/jimklimov/nut -b cyberenergy nut
Hope this helps,
Jim Klimov
On Thu, Feb 15, 2024 at 5:24?AM <abeyoungh at gmail.com> wrote:
> Hello Jim,
>
>
>
> Thanks for your prompt reply and happy lunar new year.
>
>
>
> I think my situation is first one. Actually I am from CyberPower
> UPS manufacture. In the past, CyberPower UPS works well with NUT. Today, I
> want to use another VID/PID to fulfill ODM business rather than CyberPower
> brand UPS. My engineer will apply standard USB power device description
> like as CyberPower?s USB design. The only difference is VID/PID. What I
> request is someone could help me finish following two items.
>
> 1. Offer the beta NUT version that should include below requirement to
> me. I will test it by myself.
>
> I. New VID "0x0483", PID "0xA430"
>
> II. Corresponding existing (sub-)driver "usbhid-ups"
>
> III. Manufacture "CyberEnergy"
>
> 1. Once the beta NUT is compatible with new UPS, help me pull request
> until formal NUT support my new VID/PID device.
>
>
>
> Can you help me or suggest proper person to complete above? How much
> should I pay for this, please let me know if anything that I should notice.
>
>
>
> Thank you very much and look forward your further feedback,
>
> Eric Hsu
>
>
>
> *From:* Jim Klimov <jimklimov+nut at gmail.com>
> *Sent:* Wednesday, February 7, 2024 4:10 PM
> *To:* abeyoungh at gmail.com
> *Cc:* nut-upsdev <nut-upsdev at alioth-lists.debian.net>
> *Subject:* Re: [Nut-upsdev] NUT supports new VID/PID
>
>
>
> Hello and welcome!
>
>
>
> It really depends on what it really means to "add support":
>
>
>
> If the needed abilities are already present in an existing driver and
> its sub-driver (`usbhid-ups` as you say, if this uses a HID protocol, or
> `nutdrv_qx` likely otherwise), and the issue is just about adding the IDs
> to the suitable handler so it "knows" it is compatible during
device
> detection, then it is trivial. In fact, if you go to NUT GitHub Wiki page
> to look for "Building in-place" instructions, you can experiment
locally
> and post a pull request with a checked-working change set.
>
>
>
> If this issue is however about adding a new (or extending an old)
> (sub-)driver, then I really hope some of the list members can help with the
> investigation and coding.
>
>
>
> Hope this helps,
>
> Jim Klimov
>
>
>
> On Wed, Feb 7, 2024, 07:50 abeyoungh--- via Nut-upsdev <
> nut-upsdev at alioth-lists.debian.net> wrote:
>
> Hi all,
>
>
>
> I am looking for someone who help me request NUT to supports power
> device which has unregistered VID/PID. I will pay you for your service.
>
>
>
> Detail requirement
>
> 1. New VID "0x0483", PID "0xA430"
>
> 2. Corresponding driver "usbhid-ups"
>
> 3. Manufacture "CyberEnergy"
>
>
>
> I have no idea to handle this. If need more information, please let me
> know, thanks.
>
> _______________________________________________
> Nut-upsdev mailing list
> Nut-upsdev at alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://alioth-lists.debian.net/pipermail/nut-upsdev/attachments/20240215/5960ecc6/attachment.htm>