Nut upsuser - Sep 2016 - How to get started (Windows)

> I suspect you will want the newer version for production (there was some
> issue regarding the popups when certain events happen), but let's get
this
> version working first before changing another variable.
Appreciate that. Agreed.
> For reference, I think the source code to NUT.exe is here:
> https://github.com/networkupstools/nut/blob/Windows-v2.6.5-
> 5/scripts/Windows/wininit.c
OK, we're getting closer. That little tidbit helped a lot.

Yes, that's the source to NUT.exe. And yes, NUT.exe runs the other processes
as I'd earlier suspected:

  run_drivers();
  run_upsd();
  run_upsmon();

A quick glance through the code reveals a startup switch -N (run in non-service
mode). I did that, having stopped the service first, and then ran 'upsd
-D' as requested. This time I got an error message dialog window: "The
program can't start because LIBEAY32.dll is missing from your
computer."

BINGO. With that my nose went to the ground.

(FYI the reason we didn't get that dialog before is because Windows services
can no longer interact with the Desktop. Pre-Win8 they could, but that
capability has been removed. Now that we ran NUT.exe at the command line, we
could see it. So thanks for that source code tip.)

I poked around StartPage a bit, finding that LIBEAY32 is a component of
OpenSSL-Win32. Further searching led me here:

  http://docwiki.embarcadero.com/RADStudio/Berlin/en/OpenSSL

I tried Option 2, but that site is down. So I used this instead:

  http://web.archive.org/web/20160826051001/http://indy.fulgan.com/SSL/

(Wonderful thing, that WayBack Machine.)

I decided on the latest x86 version available there,
openssl-1.0.2h-i386-win32.zip. I extracted the two files, LIBEAY32.dll and
SSLEAY32.dll, to .\NUT\bin and tried upsd again. Success!

  C:\Users\Admin>upsd
  Network UPS Tools upsd Windows-v2.6.5-5-7-g72f380c
  listening on 127.0.0.1 port 3493
  Connected to UPS [ups]: usbhid-ups-ups

...and this:

  C:\Users\Admin>upsmon
  Network UPS Tools upsmon Windows-v2.6.5-5-7-g72f380c
  UPS: ups at localhost (master) (power value 1)
  Using power down flag file C:\killpower

...and this:

  C:\Users\Admin>upsc ups at localhost
  battery.charge: 100
  battery.charge.low: 10
  battery.charge.warning: 50
  battery.runtime: 3420
  battery.runtime.low: 120
  battery.type: PbAc
  battery.voltage: 27.2
  battery.voltage.nominal: 24.0
  device.mfr: American Power Conversion
  device.model: Smart-UPS C 1000
  device.serial: 3S1520X04472
  device.type: ups
  driver.name: usbhid-ups
  driver.parameter.pollfreq: 30
  driver.parameter.pollinterval: 2
  driver.parameter.port: auto
  driver.parameter.vendorid: 051d
  driver.version: Windows-v2.6.5-5-7-g72f380c
  driver.version.data: APC HID 0.95
  driver.version.internal: 0.38
  ups.beeper.status: disabled
  ups.delay.shutdown: 20
  ups.firmware: UPS 10.0 / ID=1005
  ups.mfr: American Power Conversion
  ups.mfr.date: 2015/05/14
  ups.model: Smart-UPS C 1000
  ups.productid: 0003
  ups.serial: 3S1520X04472
  ups.status: OL
  ups.timer.reboot: -1
  ups.timer.shutdown: -1
  ups.vendorid: 051d

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:

  e.g. Detected EATON - Ellipse MAX 1100 [ADKK22008]

I don't know whether that's significant. I'm guessing it is.

Now here's the real problem. When I run 'NUT.exe -N' I get this:

  PS C:\Users\Admin> Get-Process *ups*

  Handles  NPM(K)    PM(K)      WS(K) VM(M)   CPU(s)     Id ProcessName
  -------  ------    -----      ----- -----   ------     -- -----------
       60       8      908       3896    42     0.00   3280 upsd
       84       9     1344       5328    49     0.09   3348 upsmon
       58       7     1696       4600    47     0.00   4916 usbhid-ups

I know that sounds good, but when I run NUT.exe as a service upsd and upsmon
don't start:

  PS C:\Users\Admin> Get-Process *ups*

  Handles  NPM(K)    PM(K)      WS(K) VM(M)   CPU(s)     Id ProcessName
  -------  ------    -----      ----- -----   ------     -- -----------
       58       6     1612       4484    26     0.02   3380 usbhid-ups

This also explains the errors in the Event Log when stopping the service:

  Error stopping upsd (2)
  Error stopping upsmon (2)

They never started in the first place, so they couldn't be stopped.

Here's the full output of NUT.exe -N:

  C:\Users\Admin>nut -N
  Running in non-service mode

  EventLog : Starting

  EventLog : Starting drivers

  EventLog : Starting upsd

  Network UPS Tools - UPS driver controller Windows-v2.6.5-5-7-g72f380c
  Network UPS Tools upsd Windows-v2.6.5-5-7-g72f380c
  Network UPS lTiosotlesn i-n gG eonne r1i2c7 .H0I.D0 .d1r ipvoerrt  03.43983 
(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
  EventLog : Starting upsmon

  EventLog : upsd - Startup successful

  Network UPS Tools upsmon Windows-v2.6.5-5-7-g72f380c
  UPS: ups at localhost (master) (power value 1)
  Using power down flag file C:\killpower
  EventLog : upsd - User upsmon at 127.0.0.1 logged into UPS [ups]

Back to the problem. I certainly wouldn't mind skipping the service
altogether and just running 'NUT.exe -N' in production, but that
suspends input and halts processing as it drops into polling mode. I can't
have a script hanging like that. I'll look into making an async call, but I
shouldn't have to be doing such things. Same goes with running the
client/server components individually.

However when do I run NUT.exe as intended, as a service, the client/server
components don't start. With no indication as to why not.

See the dilemma?

And given the absence of the discovery/announcement of the UPS model under
'upsdrvctl start' as previously discussed, I'm still not 100%
confident it's working correctly.

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

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.

> >  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).
This is very good news. Thank you for the clarification.
> > 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
Got it.
> Because NUT does not currently implement Modbus[*], you can ignore them.
Very good, will do.
> 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.
I ended up creating a Startup Task to run 'NUT -N' using Windows'
Task Schedulder (taskschd.msc). It doesn't block other startup processes and
it appears to work well. (In the Task settings I took care to disable the option
to kill the task if it runs past [x] days.)
> A number of ideas have been thrown around for reviving the NUT
> windows port; see https://github.com/networkupstools/nut/issues/5 for
> instance.
I'm just grateful that it exists at all. I appreciate the work everyone has
done.

And I appreciate your assistance on this issue. It sounds as though I'm
cleared to begin my testing and start moving into production. I think you might
agree.