Nut upsuser - Nov 2016 - Questions about Eaton 5E 1, 100W 2, 200VA 6-Outlet UPS

On Oct 25, 2016, at 8:08 PM, Michael Evans wrote:
> 
> It seems that the UPS I bought is actually served by the blazer_usb driver.
> 
> USB ids 06da:0003 (lsusb DB thinks it's a "Phoenixtec Power Co.,
Ltd 1300VA UPS", but this has apparantly been re-used by Eaton
5E2200USB-LA)
> 
> It's sold as an Eaton 5E 1,100W 2,200VA 6-Outlet UPS
> 
> SKU: 147140 Mfr Part #: 5E2200USB-LA UPC: 743172064875
> 
> http://www.microcenter.com/product/470131/5E_1,100W_2,200VA_6-Outlet_UPS
Thanks, this info is useful.
 
> "The Eaton 5E is an essential line interactive UPS that provides cost
effective and reliable power protection against power outages and bad power
quality. Thanks to its small size the 5E can be installed easily in a business
environment or at home."
> 
> 
> 
> I can only assume that the usbhid-ups driver guesses the manufacturer as
the first whole name in the data-strings if it doesn't reccognize it.
Yes, and it is grabbing that from the USB string descriptors mentioned in the
Device Descriptor:

  iManufacturer           3 
  iProduct                1 

(If lsusb has write access to that USB device - usually when running as root -
it will retrieve and display those string descriptors after the numbers.)
> Additional research in to the USB device ID lead to news articles from
2008(!) about Eaton aquiring Phoneixtek.  I'm not sure if this is some UPS
that's been sitting on a shelf for years or not . . . :(
I would be surprised if the entire unit was sitting on the shelf, but the
simpler chips are likely older designs.
> # cat >> /etc/udev/rules.d/99-nut.rules << "HEREDOC"
> 
> SYSFS{idVendor}=="06da", SYSFS{idProduct}=="0003",
MODE="664", GROUP="nut"
> 
> HEREDOC
This should be covered by one of the rules in the udev file that NUT installs.
Maybe check the path that is detected by ./configure? It's controlled by
"--with-udev-dir=PATH".

Also, was this needed for the Arch package? There was an issue with
Debian/Ubuntu packages where the installed file was the wrong priority (well, it
was initially correct, then something changed around it).
> 
> # udevadm control --reload-rules
> 
> I think I recall hearing systemd ate udev?
> 
> # systemctl daemon-reload
> 
> Then I disconnected/reconnected the UPS, since that was faster than looking
up re-triggering udev rules.
> 
> 
> # cat >> /etc/ups/ups.conf << HEREDOC
> 
> [eaton5e]
>         driver  = blazer_usb
>         port    = auto
>         vendorid = 06da
>         productid = 0003
> HEREDOC
New work is being done on nutdrv_qx rather than blazer_*, but fortunately it is
fairly similar to configure:

   http://networkupstools.org/docs/man/nutdrv_qx.html
> 
> I still need to perform the following calibrations:
> 
> default.battery.voltage.high = value
> Maximum battery voltage that is reached after about 12 to 24 hours
charging. If you want the driver to report a guesstimated battery.charge, you
need to specify this (see BATTERY CHARGE).
> 
> default.battery.voltage.low = value
> Minimum battery voltage just before the UPS automatically shuts down. If
you want the driver to report a guesstimated battery.charge, you need to specify
this (see BATTERY CHARGE).
> 
> runtimecal = tShigh,pLhigh,tSmed,pLmed  (timeSeconds and 'percent
load' high/low)
> 
> 
> The first doesn't sound that difficult, it's mostly just waiting. 
The second and third values... THOSE are a lot more difficult with older
incandescent light bulbs difficult to find.
> 
> 
> 
> # echo Re-testing with the 'stable' version of NUT
> 
> upsc eaton5e at localhost
> battery.charge: 100
> battery.voltage: 27.40
> battery.voltage.high: 26.00
> battery.voltage.low: 20.80
> battery.voltage.nominal: 24.0
> device.type: ups
> driver.name: blazer_usb
> driver.parameter.pollinterval: 2
> driver.parameter.port: auto
> driver.parameter.productid: 0003
> driver.parameter.synchronous: no
> driver.parameter.vendorid: 06da
> driver.version: 2.7.4
> driver.version.internal: 0.12
> input.current.nominal: 18.0
> input.frequency: 59.9
> input.frequency.nominal: 60
> input.voltage: 121.3
> input.voltage.fault: 121.3
> input.voltage.nominal: 120
> output.voltage: 121.0
> ups.beeper.status: enabled
> ups.delay.shutdown: 30
> ups.delay.start: 180
> ups.load: 0
> ups.productid: 0003
> ups.status: OL
> ups.type: offline / line interactive
> ups.vendorid: 06da
> 
> 
> 
> 
> 
> 
> # echo blazer_usb while powered ON ; a single older LCD monitor as load.
> 
> battery.charge: 100
> battery.voltage: 27.80
> battery.voltage.high: 26.00
> battery.voltage.low: 20.80
> battery.voltage.nominal: 24.0
> device.type: ups
> driver.name: blazer_usb
> driver.parameter.pollinterval: 2
> driver.parameter.port: auto
> driver.parameter.productid: 0003
> driver.parameter.synchronous: no
> driver.parameter.vendorid: 06da
> driver.version: 2.7.4-151-g9209e18
> driver.version.internal: 0.12
> input.current.nominal: 18.0
> input.frequency: 59.9
> input.frequency.nominal: 60
> input.voltage: 121.3
> input.voltage.fault: 121.0
> input.voltage.nominal: 120
> output.voltage: 121.3
> ups.beeper.status: enabled
> ups.delay.shutdown: 30
> ups.delay.start: 180
> ups.load: 0
> ups.productid: 0003
> ups.status: OL
> ups.type: offline / line interactive
> ups.vendorid: 06da
> 
> 
> 
> # echo blazer_usb while TURNED OFF
> 
> # upsc eaton5e at localhost
> battery.charge: 100
> battery.voltage: 26.30
> battery.voltage.high: 26.00
> battery.voltage.low: 20.80
> battery.voltage.nominal: 24.0
> device.type: ups
> driver.name: blazer_usb
> driver.parameter.pollinterval: 2
> driver.parameter.port: auto
> driver.parameter.productid: 0003
> driver.parameter.synchronous: no
> driver.parameter.vendorid: 06da
> driver.version: 2.7.4-151-g9209e18
> driver.version.internal: 0.12
> input.current.nominal: 18.0
> input.frequency: 0.0
> input.frequency.nominal: 60
> input.voltage: 121.0
> input.voltage.fault: 121.0
> input.voltage.nominal: 120
> output.voltage: 0.0
> ups.alarm: Shutdown imminent!
> ups.beeper.status: enabled
> ups.delay.shutdown: 30
> ups.delay.start: 180
> ups.load: 0
> ups.productid: 0003
> ups.status: ALARM OL FSD
> ups.type: offline / line interactive
> ups.vendorid: 06da
Thanks, we'll add this to the DDL:

http://networkupstools.org/ddl/
> 
> On Tue, Oct 25, 2016 at 10:45 AM Michael Evans <mjevans1983 at
gmail.com> wrote:
> I recently purchased a UPS from
> http://www.microcenter.com/product/470131/5E_1,100W_2,200VA_6-Outlet_UPS
> 
> It's sold as an Eaton 5E 1,100W 2,200VA 6-Outlet UPS
> 
> SKU: 147140
> Mfr Part #: 5E2200USB-LA
> UPC: 743172064875
>  
> "The Eaton 5E is an essential line interactive UPS that provides cost
effective and reliable power protection against power outages and bad power
quality. Thanks to its small size the 5E can be installed easily in a business
environment or at home."
> 
> Network UPS Tools upsc 2.7.4-151-g9209e18
> 
> The git development version was required to get any communication with the
UPS; however a number of surprises awaited me.
> 
> upsc eaton5e at localhost
> device.mfr: CTN
> device.model: USB UPS
> device.type: ups
> driver.name: usbhid-ups
> driver.parameter.pollfreq: 30
> driver.parameter.pollinterval: 2
> driver.parameter.port: auto
> driver.parameter.productid: 0003
> driver.parameter.synchronous: no
> driver.parameter.vendorid: 06da
> driver.version: 2.7.4-151-g9209e18
> driver.version.data: MGE HID 1.41
> driver.version.internal: 0.41
> ups.mfr: CTN
> ups.model: USB UPS
> ups.productid: 0003
> ups.status: OB
> ups.vendorid: 06da
Hmm, I'll see if we can add a warning if those IDs are passed to usbhid-ups.
(We have a few special cases for other confusing label-versus-OEM naming
situations.)

https://github.com/networkupstools/nut/issues/334
> The Manufacturer, model, and data presented are... not at all what I
expected.
> 
> The particular model I selected has a 20A style plug.  While I can plug it
in, I've no other devices with such a plug so I can't actually confirm
it's making proper contact.
> 
> It would be nice if someone more aware of the state of the UPS industry
could comment on if this UPS is Eaton 'branded' as a result of some
licencing deal and/or merger; or if this UPS happens to be a counterfeit.
I think you mentioned this elsewhere, but it is not unusual for vendors to use
different controllers for different model classes. I was only aware of the MGE
and Powerware lines for Eaton, but then again, I don't buy new equipment
often.
> I'd also like to know if I should be expecting to see things like the
line quality, UPS load, and maybe even a battery voltage (if not remaining time
estimate) from a 'lower end' UPS.
For instance, compare http://networkupstools.org/ddl/Eaton/Powerware_3105.html
and http://networkupstools.org/ddl/Eaton/Powerware_5110.html - some of that may
be due to deficiencies in the driver, but the more typical failure mode is to
print an incorrect value rather than omit a value.
> [3111733.168501] usb 3-3: USB disconnect, device number 6
> [3111737.564994] usb 3-3: new low-speed USB device number 7 using xhci_hcd
> [3111737.763574] hid-generic 0003:06DA:0003.0002: hiddev0,hidraw0: USB HID
v1.11 Device [CTN USB UPS] on usb-0000:00:14.0-3/input0
> [3111737.921670] usb 3-4: new low-speed USB device number 8 using xhci_hcd
> [3111738.085069] usb 3-4: device descriptor read/64, error -71
> [3111748.351251] usb 3-4: device descriptor read/64, error -110
> [3111748.614619] usb 3-4: new low-speed USB device number 9 using xhci_hcd
> [3111748.777993] usb 3-4: device descriptor read/64, error -71
> [3111764.040752] usb 3-4: device descriptor read/64, error -110
> [3111764.304017] usb 3-4: new low-speed USB device number 10 using xhci_hcd
> [3111764.305692] usb 3-4: Device not responding to setup address.
> [3111764.508782] usb 3-4: Device not responding to setup address.
> [3111764.710658] usb 3-4: device not accepting address 10, error -71
> [3111764.870704] usb 3-4: new low-speed USB device number 11 using xhci_hcd
> [3111764.871490] usb 3-4: Device not responding to setup address.
> [3111765.074047] usb 3-4: Device not responding to setup address.
> [3111765.277350] usb 3-4: device not accepting address 11, error -71
> [3111765.278466] usb usb3-port4: unable to enumerate USB device
We're trying to better understand why xhci_hcd has a hard time with 1.5
Mbit/sec USB. It has mostly shown up with other UPS brands, but I wouldn't
be surprised if it was the same root cause as this. While switching to a better
cable or adding a hub would make these problems go away in the past, that has
not been the case with more recent motherboards.
> 
> Linux 4.7.4-1-ARCH #1 SMP PREEMPT Thu Sep 15 15:24:29 CEST 2016 x86_64
GNU/Linux
> 
> Bus 003 Device 006: ID 06da:0003 Phoenixtec Power Co., Ltd 1300VA UPS
> Device Descriptor:
>   bLength                18
>   bDescriptorType         1
>   bcdUSB               1.10
>   bDeviceClass            0 
>   bDeviceSubClass         0 
>   bDeviceProtocol         0 
>   bMaxPacketSize0         8
>   idVendor           0x06da Phoenixtec Power Co., Ltd
>   idProduct          0x0003 1300VA UPS
>   bcdDevice            5.01
>   iManufacturer           3 
>   iProduct                1 
>   iSerial                 0 
>   bNumConfigurations      1
>   Configuration Descriptor:
>     bLength                 9
>     bDescriptorType         2
>     wTotalLength           34
>     bNumInterfaces          1
>     bConfigurationValue     1
>     iConfiguration          0 
>     bmAttributes         0xa0
>       (Bus Powered)
>       Remote Wakeup
>     MaxPower              100mA
>     Interface Descriptor:
>       bLength                 9
>       bDescriptorType         4
>       bInterfaceNumber        0
>       bAlternateSetting       0
>       bNumEndpoints           1
>       bInterfaceClass         3 Human Interface Device
>       bInterfaceSubClass      0 
>       bInterfaceProtocol      0 
>       iInterface              0 
>         HID Device Descriptor:
>           bLength                 9
>           bDescriptorType        33
>           bcdHID               1.11
>           bCountryCode            0 Not supported
>           bNumDescriptors         1
>           bDescriptorType        34 Report
>           wDescriptorLength      27
>          Report Descriptors: 
>            ** UNAVAILABLE **
>       Endpoint Descriptor:
>         bLength                 7
>         bDescriptorType         5
>         bEndpointAddress     0x81  EP 1 IN
>         bmAttributes            3
>           Transfer Type            Interrupt
>           Synch Type               None
>           Usage Type               Data
>         wMaxPacketSize     0x0008  1x 8 bytes
>         bInterval              12
> 
> _______________________________________________
> Nut-upsuser mailing list
> Nut-upsuser at lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

I can't seem to get the longer battery tests to actually run:

test.battery.start
test.battery.start.deep

Both appear to leave the battery voltage at line-power levels; while the
quick test does have a notable voltage delta.

Are there any other tests I can perform or ways that I can help gather data
to get the longer tests supported?






I borrowed a 60W light bulb (instead of one of the new weird ones that
stores are now selling to drive people to just try an LED light).

For the 1100W/2200 VA 5E model a 60W light registers as a ups.load of ~2
(clearly truncated; I guess this correlates to approximately floor((100 *
60)/2200))

It took me a while to remember that I needed to configure upsd.users and
use a completely different command ( upscmd instead of upsc ) to interact
with the UPS and get it to run a battery test.

In my case   upscmd eaton5e test.battery.start.quick   allowed me to see a
maximum default.battery.voltage.high of 26.5

(This typically reads at ~27.50 (27.20 - 27.80) while on line power)

It took me a bit of effort to arrange a larger load that I don't care
about, but after setting it up this weekend I have an initial test load of
'33' (which the light bulb calibration says should be approximately the
same as 16 * (60 watt bulb unit)).

Next the actual battery test

upscmd eaton5e test.battery.start.deep
Username (root): *****
Password: *****
OK

Though the output appears to indicate that it is not running the test:

battery.voltage: 27.60
device.type: ups
driver.name: nutdrv_qx
driver.parameter.pollfreq: 30
driver.parameter.pollinterval: 2
driver.parameter.port: auto
driver.parameter.productid: 0003
driver.parameter.synchronous: no
driver.parameter.vendorid: 06da
driver.version: 2.7.4-151-g9209e18
driver.version.data: Q1 0.07
driver.version.internal: 0.28
input.frequency: 59.9
input.voltage: 120.3
input.voltage.fault: 120.3
output.voltage: 120.3
ups.beeper.status: enabled
ups.delay.shutdown: 30
ups.delay.start: 180
ups.load: 33
ups.productid: 0003
ups.status: OL
ups.type: offline / line interactive
ups.vendorid: 06da


upscmd eaton5e test.battery.start
Username (root): *****
Password: *****
OK

I thought that might have worked, but it too still rests on line power.


The test.battery.start.quick command does, BRIEFLY (~1min), put it on to
battery.

battery.voltage: 26.30
device.type: ups
driver.name: nutdrv_qx
driver.parameter.pollfreq: 30
driver.parameter.pollinterval: 2
driver.parameter.port: auto
driver.parameter.productid: 0003
driver.parameter.synchronous: no
driver.parameter.vendorid: 06da
driver.version: 2.7.4-151-g9209e18
driver.version.data: Q1 0.07
driver.version.internal: 0.28
input.frequency: 59.9
input.voltage: 120.3
input.voltage.fault: 120.3
output.voltage: 120.0
ups.beeper.status: enabled
ups.delay.shutdown: 30
ups.delay.start: 180
ups.load: 29
ups.productid: 0003
ups.status: OL CAL
ups.type: offline / line interactive
ups.vendorid: 06da
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20161101/806be551/attachment.html>

> On Oct 31, 2016, at 10:15 PM, Michael Evans <mjevans1983 at
gmail.com> wrote:
> 
> Are there any other tests I can perform or ways that I can help gather data
to get the longer tests supported?
> 
The "test.battery.start" command takes a parameter in seconds
(defaults to 600):

https://github.com/networkupstools/nut/blob/v2.7.4/drivers/nutdrv_qx_blazer-common.c#L286

It is possible that 600 seconds is too long for your model.

All of these NUT instant commands get converted to one- or two-character
commands to be sent to the UPS:

https://github.com/networkupstools/nut/blob/v2.7.4/drivers/nutdrv_qx_q1.c#L40

It is probably worth a quick check to see if the vendor software has any
documentation on the battery test options.

The battery test commands are likely to stop before the battery gets drained too
much. You can also use a power strip or circuit breaker to cut the input power
to determine runtime.