[Nut-upsuser] How to get started (Windows)

[Charles Lepple]

On Sep 14, 2016, at 9:29 AM, Jeff Bowman <jeff.bowman at intexx.com> wrote:

>  C:\Users\Admin>upsc ups at localhost
>  battery.charge: 100
...
>  ups.status: OL

If ups.status follows the state of line power, the driver is working (and upsc talks to upsd, so that connection is working as well).

> So this all represents significant progress. But we're not out of the woods yet.
> 
> When I run 'upsdrvctl start' I still get the 45-second hang and then only this:
> 
>  C:\Users\Admin>upsdrvctl start
>  Network UPS Tools - UPS driver controller Windows-v2.6.5-5-7-g72f380c
>  Network UPS Tools - Generic HID driver 0.38 (Windows-v2.6.5-5-7-g72f380c)
>  USB communication driver 0.32
>  interrupt pipe disabled (add 'pollonly' flag to 'ups.conf' to get rid of this message)
>  Using subdriver: APC HID 0.95
> 
> It doesn't display the UPS model as indicated on p.21 in the PDF documentation:

Unfortunately, the text on that page (from NUT 2.4.1) does not reflect the current (2.6.x/2.7.x) state of the driver code. Someone must have changed it from a printf() to a debug log statement. Noted: https://github.com/networkupstools/nut/issues/316

> In fact I'm sure it's not:
> 
>  C:\Users\Admin>usbhid-ups.exe -a ups -DD
> 
>  ...
> 
>  0.063421  libusb_get_report: libusb0-dll:err [control_msg] sending control message failed, win error: A device attached to the system is not functioning.
>  0.063421  Can't retrieve Report 89: Input/output error [A device attached to the system is not functioning. ]
>  0.063421  Path: UPS.ff8600fd, Type: Input, ReportID: 0x89, Offset: 0, Size: 8
> 
>  0.063421  libusb_get_report: libusb0-dll:err [control_msg] sending control message failed, win error: A device attached to the system is not functioning.
>  0.063421  Can't retrieve Report 90: Input/output error [A device attached to the system is not functioning. ]
>  0.063421  Path: UPS.ff8600fc, Type: Output, ReportID: 0x90, Offset: 0, Size: 8

Path components starting with "ff.." are vendor-specific, and are not covered by the HID PDC spec. We try to make use of as many as we can, but if they are not implemented, the driver continues on, and simply doesn't publish a value for them in the upsc output.

In this case, they are not even real HID reports. Search for ModbusRTURx and ModbusRTUTx in MPAO-98KJ7F_R1_EN.pdf (I am having trouble linking to it directly, but it shows up at the top of a Google search for that filename. Because NUT does not currently implement Modbus[*], you can ignore them.

[*] https://github.com/networkupstools/nut/issues/139

The remaining service startup issues are going to need the help of a Windows developer, though I would be surprised if they couldn't be worked around with a script. A number of ideas have been thrown around for reviving the NUT windows port; see https://github.com/networkupstools/nut/issues/5 for instance.