Nut upsuser - May 2014 - Masterguard UPS A3000

Hi,

I'm trying to talk to an old Masterguard UPS A3000 so I can determine 
current load and status etc, to determine the best replacement options.

After a fair amount of google fu, and attempting different things, this 
is where I have ended up.

First, environment:
OS: Linux (Debian Stable)
NUT Version: 2.7.2-1 (Debian unstable package)
UPS details (on the rear lable):
Manufacturer: Masterguard GmbH  11-04 (assuming this means manufactured 
in November 2004)
UPS Type: UPS A3000
Rated Power: 3000VA/2100W

Extra Battery:
Chloride Power Protection
Model: BP ACTIVE 3000
Product Code: 570227.101 B
Manufacturer: Masterguard GmbH  07-05 (assuming this means manufactured 
July 2005)
UPS Type: BP A3000

/lib/nut/usbhid-ups -DDDD -a upsA -x vendorid=06da -x productid=0002
Network UPS Tools - Generic HID driver 0.38 (2.7.2)
USB communication driver 0.32
    0.000000    debug level is '4'
    0.000421    upsdrv_initups...
    0.327536    Checking device (2109/0700) (010/002)
    0.327652    - VendorID: 2109
    0.327677    - ProductID: 0700
    0.327689    - Manufacturer: unknown
    0.327701    - Product: unknown
    0.327719    - Serial Number: unknown
    0.327730    - Bus: 010
    0.327742    Trying to match device
    0.327764    Device does not match - skipping
    0.327784    Checking device (1D6B/0003) (010/001)
    0.327809    - VendorID: 1d6b
    0.327834    - ProductID: 0003
    0.327852    - Manufacturer: unknown
    0.327865    - Product: unknown
    0.327877    - Serial Number: unknown
    0.327889    - Bus: 010
    0.327903    Trying to match device
    0.327916    Device does not match - skipping
    0.327934    Checking device (06DA/0002) (003/004)
    0.348101    - VendorID: 06da
    0.348161    - ProductID: 0002
    0.348181    - Manufacturer: Phoenixtec Power
    0.348206    - Product: USB Cable (V2.00)
    0.348231    - Serial Number: unknown
    0.348243    - Bus: 003
    0.348255    Trying to match device
    0.348300    Device matches
    0.355100    HID descriptor, method 1: (9 bytes) => 09 21 00 01 21 01 
22 51 00
    0.355190    i=0, extra[i]=09, extra[i+1]=21
    0.355223    HID descriptor, method 2: (9 bytes) => 09 21 00 01 21 01 
22 51 00
    0.355243    HID descriptor length 81
    0.368093    Report Descriptor size = 81
    0.368193    Report Descriptor: (81 bytes) => 05 8c 09 01 a1 01 85 01 
09 03 15 00 25 01
    0.368223     75 08 95 01 b1 82 85 02 09 02 15 00 25 01 75 01 81 82 
75 07 81 83 85 02 09
    0.368249     02 75 01 b1 82 75 07 b1 83 85 03 09 04 15 00 26 ff 00 
75 08 81 82 85 03 09
    0.368266     04 b1 82 85 04 09 05 15 00 26 ff 00 75 08 b1 82 c0
    0.368311    Using subdriver: Liebert HID 0.3
    0.368328    Entering libusb_get_report
    0.371093    Report[get]: (2 bytes) => 01 00
    0.371186    Path: 008c0001.008c0003, Type: Feature, ReportID: 0x01, 
Offset: 0, Size: 8, Value: 0
    0.371206    Entering libusb_get_report
    0.374094    Report[get]: (2 bytes) => 02 00
    0.374189    Path: 008c0001.008c0002, Type: Input, ReportID: 0x02, 
Offset: 0, Size: 1, Value: 0
    0.374219    Report[buf]: (2 bytes) => 02 00
    0.374243    Path: 008c0001.008c0002, Type: Feature, ReportID: 0x02, 
Offset: 0, Size: 1, Value: 0
    0.374261    Entering libusb_get_report
    0.377094    Report[get]: (2 bytes) => 03 00
    0.377189    Path: 008c0001.008c0004, Type: Input, ReportID: 0x03, 
Offset: 0, Size: 8, Value: 0
    0.377220    Report[buf]: (2 bytes) => 03 00
    0.377243    Path: 008c0001.008c0004, Type: Feature, ReportID: 0x03, 
Offset: 0, Size: 8, Value: 0
    0.377257    Entering libusb_get_report
    0.380099    Report[get]: (2 bytes) => 04 00
    0.380191    Path: 008c0001.008c0005, Type: Feature, ReportID: 0x04, 
Offset: 0, Size: 8, Value: 0
    0.380234    Report descriptor retrieved (Reportlen = 81)
    0.380257    Found HID device
    0.380273    Detected a UPS: Phoenixtec Power/USB Cable (V2.00)
    0.380292    string_to_path: depth = 3
    0.380312    string_to_path: depth = 3
    0.380331    string_to_path: depth = 3
    0.380351    string_to_path: depth = 3
    0.380366    string_to_path: depth = 3
    0.380385    string_to_path: depth = 3
    0.380400    string_to_path: depth = 4
    0.380430    string_to_path: depth = 4
    0.380450    string_to_path: depth = 4
    0.380466    string_to_path: depth = 4
    0.380482    string_to_path: depth = 4
    0.380497    string_to_path: depth = 4
    0.380512    find_nut_info: unknown info type: load.off.delay
    0.380526    find_nut_info: unknown info type: load.on.delay
    0.380540    find_nut_info: unknown info type: load.off.delay
    0.380561    upsdrv_initinfo...
    0.380578    upsdrv_updateinfo...
    0.632013    libusb_get_interrupt: Connection timed out
    0.632074    Got 0 HID objects...
    0.632102    Quick update...
    0.632169    dstate_init: sock /var/run/nut/usbhid-ups-upsA open on fd 5
    0.632198    upsdrv_updateinfo...
    0.882976    libusb_get_interrupt: Connection timed out
    0.883065    Got 0 HID objects...
    0.883094    Quick update...
    2.634017    upsdrv_updateinfo...
    2.885664    libusb_get_interrupt: Connection timed out
    2.885684    Got 0 HID objects...
    2.885693    Quick update...
    4.635801    upsdrv_updateinfo...
    4.887353    libusb_get_interrupt: Connection timed out
    4.887372    Got 0 HID objects...
    4.887381    Quick update...
Same every 2 seconds until...
   32.660814    upsdrv_updateinfo...
   32.912022    libusb_get_interrupt: Connection timed out
   32.912041    Got 0 HID objects...
   32.912051    Full update...
   34.662519    upsdrv_updateinfo...
   34.913720    libusb_get_interrupt: Connection timed out
   34.913741    Got 0 HID objects...
   34.913751    Quick update...
Same every 2 seconds until the next full update every 30 secs
   64.938109    Full update...
   66.688885    upsdrv_updateinfo...
   66.939770    libusb_get_interrupt: Connection timed out
   66.939791    Got 0 HID objects...
   66.939801    Quick update...
   68.690645    upsdrv_updateinfo...
   68.942461    libusb_get_interrupt: Connection timed out
   68.942482    Got 0 HID objects...
   68.942492    Quick update...

egrep -v ^\#\|^$ /etc/nut/ups.conf
maxretry = 3
[upsA]
        driver = usbhid-ups
        port = auto

Can anyone provide a suggestion on how I can get some more information 
from this UPS?

PS, front panel indicators show:
Green LED at the bottom (looks like Grid Power)
Vertical bar of 5 LED's, all 5 flashing green (all together) probably 
indicating the battery is fully charged, but has an error
Orange LED (probably indicating battery error
Vertical bar of 6 LED's, bottom LED is green, the rest are off. Probably 
indicates load.

This part of the question is more related to general UPS best 
practice/advice, I would really appreciate the advice of more 
experienced people.
Currently, I have two of these UPS's each with one additional battery, 
each powering one rack of equipment coming from 2 x 15A circuits. If all 
equipment in rack A fails, then services can continue (with some manual 
intervention). If all equipment in rack B fails, then no service is 
available (since the switch is in Rack B, and adding a redundant switch 
is outside the scope for now).

I am looking to replace with either:
A) 1 x APC Smart UPS RT 3000VA SURTD3000XLI with three extra batteries 
(Cost is $X)
B) 1 x APC Smart UPS RT 6000VA SURT6000XLI with two extra batteries 
(Cost is $X + 6%)
C) 2 x APC Smart UPS RT 3000VA SURTD3000XLI each with one extra battery 
(Cost is $X + 17%)

I have the following thoughts in mind:
1) Even with two units, there is a 50% chance of continued service, and 
  with investment in additional hardware, then this could be 100%
2) With two units, there will be an unbalanced power draw, so one UPS 
will fail first, therefore total power supply before some equipment 
fails will be less than it needs to be.
3) The advantage of 2 x UPS is if the UPS itself fails, and doesn't 
passthrough power even without any filtering/etc, then one rack will 
still survive. Same goes for one power circuit failure. However, chance 
of UPS failure should be very low, and if one circuit fails, then likely 
both will fail at the same time, since both come from the same powerline.
4) Taking cost into consideration, and current load requirements, I'm 
guessing that option A would provide a longer time on battery than any 
other solution? Considering that each of the current 3kVA UPS are each 
running at 1/6 load (ie, 16%, or 33% if both racks on the same 3kVA UPS)

Which would you suggest as the best option? Other brands/models/etc? Any 
other advice?

Thank you for your time and any advice.

Regards,
Adam

-- 
Adam Goryachev Website Managers www.websitemanagers.com.au

On May 26, 2014, at 11:42 PM, Adam Goryachev wrote:
> /lib/nut/usbhid-ups -DDDD -a upsA -x vendorid=06da -x productid=0002
Try the nutdrv_qx driver? It should work without specifying the
vendorid/productid.

(I can see where the Liebert USB VID might lead you to try usbhid-ups, but the
stronger link is that the serial Phoenixtec protocol is usually stuffed into a
HID-based USB-to-serial converter, which usbhid-ups doesn't support. And
USB-to-serial-via-HID is a total abuse of the HID protocol, et cetera, but
that's a rant for another day.)

I'm probably not the best person to comment on the second half of your
question, at least as far as recommendations on splitting the load between the
UPSes. I will say that I am wary of APC now that they have introduced their
proprietary Microlink protocol, and have apparently stripped down the HID PDC
support on the legacy comms card.

We should probably add this warning to the usbhid-ups man page as well:

http://www.networkupstools.org/docs/man/apcsmart.html#_supported_hardware

It's not just NUT - this affects Apcupsd:

http://forums.apc.com/thread/5374

Until recently, I would have recommended MGE/Eaton. They haven't made the
same design mistakes as APC, but we can no longer expect the same amount of
information and support that we had before.

Tripp Lite has tested many of their USB HID UPSes against NUT, and posted the
results to the list last fall:

http://article.gmane.org/gmane.comp.monitoring.nut.user/8173

I haven't personally tried their recent hardware, but at the moment, this
seems like the most promising avenue for vendor support.

-- 
Charles Lepple
clepple at gmail