On Sep 14, 2016, at 9:29 AM, Jeff Bowman <[email protected]> wrote:
> C:\Users\Admin>upsc ups@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. _______________________________________________ Nut-upsuser mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
