[Nut-upsdev] usb ups on openindiana

[Ted Mittelstaedt]

On 11/9/2013 5:24 AM, Jim Klimov wrote:
> Hello all,
>
> I am trying to set up my brother's UPS (remotely over internet)
> on an OpenIndiana-based storage box. According to him, the UPS is
> probably an Ippon Back Power Pro 600 dated around 2003 (battery
> recently replaced), and it has an USB connection.
>
> Sorry for a relatively long post with a log of my successes and
> failures, in the hopes that someone would point out what I did
> wrong. I guess this is among my first experiences with USB in
> Solaris - for a decade we had either serial or snmp UPSes :)
>
> I have found some assorted blog posts, following which I found
> that the proper driver nowadays is blazer_usb (and earlier versions
> of NUT had an ippon driver, which was AFAIK serial-only). However
> I can't get the blazer_usb driver to recognize this UPS, and there
> are some other problems. Another driver says it found the UPS, but
> I am not sure about its correctness :)
>

The NUT HCL -DOES_STATE- that this UPS is (experimental)

> Main question is if this is some mistake of mine, an OS specific
> thing, or just that this particular UPS is not supported (or maybe
> its mgmt parts are broken - who knows, so far they haven't been
> tested in any other OS)?
>

I think you have to step back from this for a moment
and re-evaluate the real goals here.

Is your goal to:

1) Get this OpenIndiana based storage box protected against power failures?

or is it to:

2) Help the NUT project change the status of your UPS from Experimental 
to Production?

If your goal is #1 then your going about this the wrong way - the best 
advise you can take would be to tell your brother to buy a supported 
UPS.  Since you have NUT already built, that would be an 
Eaton-manufactured UPS since Eaton is the main sponsor.

If your goal is #2 - which we all appreciate, thank you! - then once you 
have discovered that the UPS isn't fully supported you need to decide if 
your OK with this gear being unprotected for a while.

The track record of NUT developers adding support for drivers (or fixing 
bugs in drivers) is frankly pretty poor.  Many more bugs and
problems are reported than are ever fixed.  Mostly this is likely
because the developers don't have samples of the UPS in question.

Basically if your in your shoes - you have an unsupported UPS - then
your choices are to replace the UPS and ship the unsupported UPS off
to a developer, or to try to fix it yourself.

> For the record, here's what I did so far:
>
> 1) Installed the GCC-based development environment in OI, libusb
> and other packages that the build wanted
>
> 2) Compiled nut-2.6.5 (with the patch mentioned a week ago)
>
> 3) Installed NUT in the global zone, and defined the ups.conf entry:
>
> [ippon]
> driver = blazer_usb
> port = auto
> desc = "Ippon Pro 600 USB"
>
> [hid]
> driver = usbhid-ups
> port = auto
>
>
> 4) The interesting part is about getting USB to be found at all :)
>
> Do credit where credit is due - some helpful posts were:
> http://barbz.com.au/blog/?p=407
> http://www.mail-archive.com/nut-upsuser@lists.alioth.debian.org/msg06556.html
>
>
>
> # /usr/sbin/cfgadm -lv usb8/5
> Ap_Id Receptacle Occupant Condition
> Information
> When Type Busy Phys_Id
>
> usb8/5 connected configured ok
> Mfg: OMRON Product: 87XXUPS NConfigs: 1 Config: 0 <no cfg str descr>
> unavailable usb-input n /devices/pci at 0,0/pci103c,1609 at 12:5
>
> # prtconf -v | ggrep -B20 -A20 OMRON | egrep "value='(NAME|usb)"
>
> value='NAME= ugen0 Power' + '0=USB D3 State' +
> '3=USB D0 State'
> value='usb6da,3.0' + 'usb6da,3' +
> 'usbif6da,class3.0.0' + 'usbif6da,class3.0' + 'usbif6da,class3' +
> 'usbif,class3.0.0' + 'usbif,class3.0' + 'usbif,class3' + 'usb,device'
>
>
> So this UPS has VendorID 06DA, ProductID 0003.
>
> # rem_drv ugen
> # add_drv -i '"usb6da,3.0"' -m '* 0666 nobody nobody' ugen
>
> # dmesg | tail
> ...
> Nov 9 15:42:10 n54l usba: [ID 912658 kern.info] USB 1.10 device
> (usb6da,3) operating at low speed (USB 1.x) on USB 1.10 root hub:
> input at 5, ugen0 at bus address 2
>
> Nov 9 15:42:10 n54l usba: [ID 349649 kern.info] OMRON 87XXUPS
>
> Nov 9 15:42:10 n54l genunix: [ID 936769 kern.info] ugen0 is
> /pci at 0,0/pci103c,1609 at 12/input at 5
>
>
> However, the UPS is *usually* not found at all:
>
> root at n54l:/# /usr/local/ups/bin/usbhid-ups -DDDD -a hid
>
> Network UPS Tools - Generic HID driver 0.37 (2.6.5)
> USB communication driver 0.31
> 0.000000 debug level is '4'
> 0.001180 upsdrv_initups...
> 0.002196 No appropriate HID device found
> 0.002241 No matching HID UPS found
>
>
> root at n54l:/# /usr/local/ups/bin/blazer_usb -DDDD -a ippon
>
> Network UPS Tools - Megatec/Q1 protocol USB driver 0.09 (2.6.5)
> 0.000000 debug level is '4'
> 0.001235 No appropriate HID device found
> 0.001287 No supported devices found. Please check your device
> availability with 'lsusb' and make sure you have an up-to-date version
> of NUT. If this does not help, try running the driver with at least
> 'subdriver', 'vendorid' and 'productid' options specified. Please refer
> to the man page for details about these options (man 8 blazer).
>
>
>
> I wrote that it is *usually* not found, because early in my tests
> (i.e. soon after boot) it was actually discovered as a device on
> the USB bus, but with no details and unrecognized as a known UPS.
>
> Actually, I've tracked this down to the USB device nodes changing
> ownership from nobody:nobody to root:root during blazer_ups driver
> startup :\ I am so far at a loss as to "The why". Even weirder,
> sometimes the device links get gone as well, and this recovers them:
>
> # devfsadm -Cv
> devfsadm[5083]: verbose: symlink /dev/usb/6da.3/0/devstat ->
> ../../../../devices/pci at 0,0/pci103c,1609 at 12/input at 5:6da.3.devstat
> devfsadm[5083]: verbose: symlink /dev/usb/6da.3/0/cntrl0 ->
> ../../../../devices/pci at 0,0/pci103c,1609 at 12/input at 5:6da.3.cntrl0
> devfsadm[5083]: verbose: symlink /dev/usb/6da.3/0/cntrl0stat ->
> ../../../../devices/pci at 0,0/pci103c,1609 at 12/input at 5:6da.3.cntrl0stat
> devfsadm[5083]: verbose: symlink /dev/usb/6da.3/0/if0in1 ->
> ../../../../devices/pci at 0,0/pci103c,1609 at 12/input at 5:6da.3.if0in1
> devfsadm[5083]: verbose: symlink /dev/usb/6da.3/0/if0in1stat ->
> ../../../../devices/pci at 0,0/pci103c,1609 at 12/input at 5:6da.3.if0in1stat
>
>
> Running as root does work around the former problem, but the UPS
> is still not recognized by any of the protocols:
>
> # /usr/local/ups/bin/blazer_usb -DDDD -a ippon -u root
> Network UPS Tools - Megatec/Q1 protocol USB driver 0.09 (2.6.5)
> 0.000000 debug level is '4'
> 0.022634 Checking device (06DA/0003) (/dev/usb/6da.3/0)
> 0.045564 - VendorID: 06da
> 0.045663 - ProductID: 0003
> 0.045733 - Manufacturer: OMRON
> 0.045788 - Product: 87XXUPS
> 0.045841 - Serial Number: unknown
> 0.045899 - Bus: /dev/usb
> 0.045951 Trying to match device
> 0.046011 Device matches
> 0.046187 Trying megatec protocol...
> 0.049547 send: Q1
> 0.101572 read: (217.0 2
> 0.101674 blazer_status: short reply
> 0.101733 Status read 1 failed
> 1.266722 send: I/O error
> 1.266900 blazer_status: short reply
> 1.266956 Status read 2 failed
> 1.267648 Checking device (06DA/0003) (/dev/usb/6da.3/0)
> 1.271661 - VendorID: 06da
> 1.271763 - ProductID: 0003
> 1.271823 - Manufacturer: unknown
> 1.271877 - Product: unknown
> 1.271925 - Serial Number: unknown
> 1.271974 - Bus: /dev/usb
> 1.272020 Trying to match device
> 1.272074 Device does not match - skipping
> 1.272175 No appropriate HID device found
> 1.272256 blazer_status: short reply
> 1.272309 Status read 3 failed
> 1.272358 Trying mustek protocol...
> 1.272933 Checking device (06DA/0003) (/dev/usb/6da.3/0)
> 1.277622 - VendorID: 06da
> 1.277670 - ProductID: 0003
> 1.277693 - Manufacturer: unknown
> 1.277715 - Product: unknown
> 1.277734 - Serial Number: unknown
> 1.277756 - Bus: /dev/usb
> 1.277774 Trying to match device
> 1.277793 Device does not match - skipping
> 1.277838 No appropriate HID device found
> 1.277861 blazer_status: short reply
> 1.277885 Status read 1 failed
> 1.278143 Checking device (06DA/0003) (/dev/usb/6da.3/0)
> 1.282635 - VendorID: 06da
> 1.282726 - ProductID: 0003
> 1.282782 - Manufacturer: unknown
> 1.282829 - Product: unknown
> 1.282881 - Serial Number: unknown
> 1.282932 - Bus: /dev/usb
> 1.282979 Trying to match device
> 1.283026 Device does not match - skipping
> 1.283124 No appropriate HID device found
> 1.283224 blazer_status: short reply
> 1.283273 Status read 2 failed
> 1.283866 Checking device (06DA/0003) (/dev/usb/6da.3/0)
> 1.288638 - VendorID: 06da
> 1.288727 - ProductID: 0003
> 1.288779 - Manufacturer: unknown
> 1.288829 - Product: unknown
> 1.288881 - Serial Number: unknown
> 1.288927 - Bus: /dev/usb
> 1.288975 Trying to match device
> 1.289028 Device does not match - skipping
> 1.289123 No appropriate HID device found
> 1.289189 blazer_status: short reply
> 1.289239 Status read 3 failed
> 1.289285 Trying megatec/old protocol...
> 1.289829 Checking device (06DA/0003) (/dev/usb/6da.3/0)
> 1.290230 Failed to open device, skipping. (I/O error)
> 1.290291 No appropriate HID device found
> 1.290339 blazer_status: short reply
> 1.290388 Status read 1 failed
> 1.300475 No appropriate HID device found
> 1.300572 blazer_status: short reply
> 1.300622 Status read 2 failed
> 1.321620 No appropriate HID device found
> 1.321719 blazer_status: short reply
> 1.321772 Status read 3 failed
> 1.321827 Trying zinto protocol...
> 1.322081 No appropriate HID device found
> 1.322144 blazer_status: short reply
> 1.322192 Status read 1 failed
> 1.322417 No appropriate HID device found
> 1.322479 blazer_status: short reply
> 1.322530 Status read 2 failed
> 1.322747 No appropriate HID device found
> 1.322808 blazer_status: short reply
> 1.322860 Status read 3 failed
> 1.322909 No supported UPS detected
>

OK well what the last line says is pretty much where your at, this
UPS isn't detectable by blazer_usb.

>
> # /usr/local/ups/bin/usbhid-ups -DDDD -a hid -u root
> Network UPS Tools - Generic HID driver 0.37 (2.6.5)
> USB communication driver 0.31
> 0.000000 debug level is '4'
> 0.000342 upsdrv_initups...
> 0.021748 Checking device (06DA/0003) (/dev/usb/6da.3/0)
> 0.044606 - VendorID: 06da
> 0.044658 - ProductID: 0003
> 0.044679 - Manufacturer: OMRON
> 0.044709 - Product: 87XXUPS
> 0.044730 - Serial Number: unknown
> 0.044753 - Bus: /dev/usb
> 0.044778 Trying to match device
> 0.044805 This Liebert device (06da:0003) is not (or perhaps not
> yet) supported by usbhid-ups. Please make sure you have an up-to-date
> version of NUT. If this does not fix the problem, try running the
> driver with the '-x productid=0003' option. Please report your results
> to the NUT user's mailing list <nut-upsuser at lists.alioth.debian.org>.
>
> 0.044833 Device does not match - skipping
> 0.044891 No appropriate HID device found
> 0.044923 No matching HID UPS found
>
>
> (no idea why liebert comes up - vendor id?)
>

Probably.  According to the HCL the Liebert UPSes don't all use the 
libert driver, so looks like they have switched around their management
info over the years.

> # /usr/local/ups/bin/usbhid-ups -DDDD -a hid -u root -x productid=0003
> Network UPS Tools - Generic HID driver 0.37 (2.6.5)
> USB communication driver 0.31
> 0.000000 debug level is '4'
> 0.000739 upsdrv_initups...
> 0.022865 Checking device (06DA/0003) (/dev/usb/6da.3/0)
> 0.045791 - VendorID: 06da
> 0.045896 - ProductID: 0003
> 0.045958 - Manufacturer: OMRON
> 0.046020 - Product: 87XXUPS
> 0.046073 - Serial Number: unknown
> 0.046136 - Bus: /dev/usb
> 0.046189 Trying to match device
> 0.046282 Device matches
> 0.051733 HID descriptor, method 1: (9 bytes) => 09 21 11 01 00 01 22 1b 00
> 0.051848 i=0, extra[i]=09, extra[i+1]=21
> 0.051920 HID descriptor, method 2: (9 bytes) => 09 21 11 01 00 01 22 1b 00
> 0.051978 HID descriptor length 27
> 0.058714 Report Descriptor size = 27
> 0.058817 Report Descriptor: (27 bytes) => 06 00 ff 09 01 a1 01 09 02 15
> 00 26 ff 00
> 0.058887 75 08 95 08 81 82 09 02 95 08 91 82 c0
> 0.059102 Using subdriver: Liebert HID 0.3
> 0.059195 Entering libusb_get_report
> 0.060809 libusb_get_report: I/O error
> 0.060914 Can't retrieve Report 00: I/O error
> 0.060993 Path: ff000001.ff000002, Type: Input, ReportID: 0x00, Offset:
> 0, Size: 8
> 0.061057 Entering libusb_get_report
> 0.061850 libusb_get_report: I/O error
> 0.061954 Can't retrieve Report 00: I/O error
> 0.062024 Path: ff000001.ff000002, Type: Output, ReportID: 0x00, Offset:
> 0, Size: 8
> 0.062132 Report descriptor retrieved (Reportlen = 27)
> 0.062189 Found HID device
> 0.062245 Detected a UPS: OMRON/87XXUPS
> 0.062316 string_to_path: depth = 3
> 0.062443 string_to_path: depth = 3
> 0.062521 string_to_path: depth = 3
> 0.062588 string_to_path: depth = 3
> 0.062663 string_to_path: depth = 3
> 0.062727 string_to_path: depth = 3
> 0.062800 string_to_path: depth = 4
> 0.062867 string_to_path: depth = 4
> 0.062936 string_to_path: depth = 4
> 0.063001 string_to_path: depth = 4
> 0.063069 string_to_path: depth = 4
> 0.063133 string_to_path: depth = 4
> 0.063195 find_nut_info: unknown info type: load.off.delay
> 0.063249 find_nut_info: unknown info type: load.on.delay
> 0.063305 find_nut_info: unknown info type: load.off.delay
> 0.063381 upsdrv_initinfo...
> 0.063452 upsdrv_updateinfo...
> 0.063507 Not using interrupt pipe...
> 0.063559 Quick update...
> 0.064358 dstate_init: sock /var/state/ups/usbhid-ups-hid open on fd 7
> 0.064417 upsdrv_updateinfo...
> 0.064442 Not using interrupt pipe...
> 0.064466 Quick update...
> 2.064222 upsdrv_updateinfo...
> 2.064347 Not using interrupt pipe...
> 2.064421 Quick update...
> 4.063982 upsdrv_updateinfo...
> 4.064080 Not using interrupt pipe...
> 4.064108 Quick update...
> (this goes on forever)
>
> However (after starting upsd) it seems that the UPS is seen somehow:
>
> # /usr/local/ups/bin/upsc hid at localhost
>
> device.mfr: OMRON
> device.model: 87XXUPS
> device.type: ups
> driver.name: usbhid-ups
> driver.parameter.pollfreq: 30
> driver.parameter.pollinterval: 2
> driver.parameter.port: auto
> driver.parameter.productid: 0003
> driver.version: 2.6.5
> driver.version.data: Liebert HID 0.3
> driver.version.internal: 0.37
> ups.mfr: OMRON
> ups.model: 87XXUPS
> ups.productid: 0003
> ups.status: OB
> ups.vendorid: 06da
>
>
> I am puzzled why it is considered "OB" for example, which makes this
> information somewhat useless for automated shutdowns...
>

If you pull the plug on the UPS does the ups.status change from OB to 
something else?

> It is indeed quite possible, that this particular piece of hardware is
> just not supported by NUT and there are few-to-no problems regarding
> the OS/Software side of my setup... I'd welcome confirmations though :)
> And ideas about the volatility of device node setup (disappearance of
> symlinks and changes of ownership with blazer_usb - but not with the
> usbhid-ups driver) are also welcome.
>

Your UPS isn't supported by blazer_usb or by usbhid-ups, end of story.

There must be some sort of USB driver for Windows that came with the 
UPS, the manufacturer didn't put that USB port on there for no reason.

If you plug this UPS into a modern Windows machine does it setup as a
HID UPS device, and work?  If it does, then the best chance for support
is creating a usbhid-ups subdriver.  The process isn't that hard, it's
documented here:

http://www.networkupstools.org/docs/developer-guide.chunked/ar01s04.html#hid-subdrivers

If it does NOT setup as a HID UPS device then it's a 
serial-protocol-over-USB device and updating blazer_usb is your only 
shot.  That
probably won't happen unless you can ship the UPS to a developer or
set it up on a Linux box that a developer can SSH into, with this
UPS attached.

> Also, for the record, it is very inconvenient that starting an UPS
> driver requires an entry in the ups.conf nowadays - basically, to
> find a matching driver I'd have to make dozens of such entries and
> see if any of them works... I'm lucky I got a possible hit on my
> second attempt.
>

There is NO industry standard for autodetection of UPSes on serial
ports.  Indeed, for "dumb" contact-closure UPSes on serial ports,
autodetection would be absolutely impossible since there is no 
intelligence in the UPS to communicate back to the computer.

And for USB upses, if ALL of the manufactured UPSes out there used
the HID interface like they are supposed to, then we would have no 
problem since the usbhid-ups driver IS autodetecting, all we would have 
to do is tell people if they have a USB ups, use usbhid-ups

But what screws the pooch is that many USB UPSes use their serial 
protocol over the USB port.

Your only working with a 600VA ups plugged into 1 device so you don't
understand the issues here.  The typical production business may have
multiple servers plugged into a large ups.  They cannot have the system
that the UPS is plugged into, spewing all kinds of different 
autodetection data strings out the serial port (or USB port for serial
over USB) when that monitor system reloads the UPS daemon.  All it would
take is for one of those tests to be interpreted by some other vendors
UPS as an immediate shutdown of UPS output power to cause a huge problem.

Ted

> Thanks,
> //Jim Klimov
>
>
> _______________________________________________
> Nut-upsdev mailing list
> Nut-upsdev at lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev