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 :) 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)? 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 at 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 # /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?) # /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... 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. 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. Thanks, //Jim Klimov
Hi Jim As per NUT HW compatibility list, the driver should be blazer_usb: http://www.networkupstools.org/stable-hcl.html We are currently merging a new driver to replace blazer_* and would also appreciate feedback on this if you can. Cheers, Arno -- (sent from my eeePad... please excuse my brevity) Le 9 nov. 2013 14:25, "Jim Klimov" <jimklimov at cos.ru> a ?crit :> 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 :) > > 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)? > > 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 at 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 > > > # /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?) > > # /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... > > 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. > > 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. > > 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 >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20131109/024f8810/attachment-0001.html>
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 at 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
On Nov 9, 2013, at 1:54 PM, Ted Mittelstaedt wrote:> 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.[...]>> 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?Ted brings up a good point here.> 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.For option #1, if you are looking to buy local, Powercom might be another option (going by the country code on your email address). They have provided protocols and development hardware: http://www.networkupstools.org/acknowledgements.html#_ups_manufacturers> 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.This was the mantra of Russell Kroll, the NUT project founder. Practically speaking, turning NUT developers into owners of the hardware doesn't scale well. You need to find a developer who is willing to take on a new project, and shipping them an UPS is probably not economical unless you already have a large number of these UPSes deployed. We'll do what we can to help you debug this remotely.>> 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^ This is somewhat promising, since "(217.0 2" is the beginning of a valid Megatec protocol response. (Incidentally, this pretty much rules out the usbhid-ups driver, since HID PDC packets are almost never ASCII strings.) What concerns me is that the reply seems to be exactly 8 characters, which is the maximum hardware packet size of low-speed USB. Can you add "subdriver = ippon" to the ups.conf section for this UPS?>> 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?Pretty sure this won't change, and the OB is just the default value here.>> 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:The problem is that most USB-to-serial converters show up as USB HID devices, but not as a Power Device Class (PDC) HID device (which is the HID class that the usbhid-ups driver is trying to use). HID devices are easy to access from userspace in older versions of Windows, so many manufacturers do that to avoid going down the rabbit hole of a kernel driver.> http://www.networkupstools.org/docs/developer-guide.chunked/ar01s04.html#hid-subdriversThe HID report descriptor is only 29 bytes, so it is too short to have any of the HID PDC elements that the above link talks about.>> 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.If you think that is inconvenient, try writing a driver from scratch with no documentation on the protocol. We are open to suggestions on how to make this easier, but I think that time might be better spent developing a better installation diagnostic procedure. Most people are going to only try a handful of drivers at most, and when they find the right one, they can just continue to use that version of ups.conf.> 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.... and these USB-to-serial converters are often not recognized by existing kernel drivers. If they were, users could just open the tty /dev node, and continue to use the serial-based NUT drivers.> 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.Incidentally, we have had reports of ModemManager doing that sort of auto-detection, and interfering with NUT. -- Charles Lepple clepple at gmail