Re: [Nut-upsuser] Issues with USB connectivity
Hi Simon, 2012/11/28 Simon Attwell > Thank you Charles and Arnaud for replying. > > Here’s the additional detail requested. > > joavma01:/usr/local/ups/bin # lsusb -v -d 051d:0003 > > Bus 002 Device 002: ID 051d:0003 American Power Conversion UPS > Device Descriptor: > bLength18 > bDescriptorType 1 > bcdUSB 2.00 > bDeviceClass0 (Defined at Interface level) > bDeviceSubClass 0 > bDeviceProtocol 0 > bMaxPacketSize064 > idVendor 0x051d American Power Conversion > idProduct 0x0003 UPS > bcdDevice1.06 > iManufacturer 1 American Power Conversion > iProduct2 Smart-UPS 1000 FW:UPS 08.3 / ID=18 > iSerial 3 AS1235120308 > bNumConfigurations 1 > Configuration Descriptor: > bLength 9 > bDescriptorType 2 > wTotalLength 41 > bNumInterfaces 1 > bConfigurationValue 1 > iConfiguration 0 > bmAttributes 0xe0 > Self Powered > Remote Wakeup > MaxPower2mA > Interface Descriptor: > bLength 9 > bDescriptorType 4 > bInterfaceNumber0 > bAlternateSetting 0 > bNumEndpoints 2 > bInterfaceClass 3 Human Interface Device > bInterfaceSubClass 0 No Subclass > bInterfaceProtocol 0 None > iInterface 0 > HID Device Descriptor: > bLength 9 > bDescriptorType33 > bcdHID 1.00 > bCountryCode 33 US > bNumDescriptors 1 > bDescriptorType34 Report > wDescriptorLength 515 > Warning: incomplete report descriptor > this is already a bad hint... > Report Descriptor: (length is 9) > Item(Main ): (null), data=none > Item(Main ): (null), data=none > Item(Main ): (null), data=none > Item(Main ): (null), data=none > Item(Main ): (null), data=none > Item(Main ): (null), data=none > Item(Main ): (null), data=none > Item(Main ): (null), data=none > Item(Main ): (null), data=none > Endpoint Descriptor: > bLength 7 > bDescriptorType 5 > bEndpointAddress 0x81 EP 1 IN > bmAttributes3 > Transfer TypeInterrupt > Synch Type None > Usage Type Data > wMaxPacketSize 0x0040 1x 64 bytes > bInterval 20 > Endpoint Descriptor: > bLength 7 > bDescriptorType 5 > bEndpointAddress 0x01 EP 1 OUT > bmAttributes3 > Transfer TypeInterrupt > Synch Type None > Usage Type Data > wMaxPacketSize 0x0040 1x 64 bytes > bInterval 10 > Device Status: 0x0002 > (Bus Powered) > Remote Wakeup Enabled > > joavma01:/usr/local/ups/bin # ./usbhid-ups -D -u root -a apc1000 > Network UPS Tools - Generic HID driver 0.37 (2.6.5) > USB communication driver 0.31 >0.00 send_to_all: SETINFO driver.parameter.port "auto" >0.28 send_to_all: SETINFO driver.parameter.vendorid "051d" >0.47 debug level is '5' >0.000414 upsdrv_initups... >1.022258 Checking device (1D6B/0002) (001/001) >1.022346 - VendorID: 1d6b >1.022351 - ProductID: 0002 >1.022355 - Manufacturer: Linux 2.6.37.1-1.2-default ehci_hcd >1.022358 - Product: EHCI Host Controller >1.022361 - Serial Number: :02:03.0 >1.022364 - Bus: 001 >1.022367 Trying to match device >1.022382 Device does not match - skipping >1.022393 Checking device (1D6B/0001) (002/001) >1.022431 - VendorID: 1d6b >1.022435 - ProductID: 0001 >1.022438 - Manufacturer: Linux 2.6.37.1-1.2-default uhci_hcd >1.022442 - Product: UHCI Host Controller >1.022445 - Serial Number: :02:02.0 >1.022448 - Bus: 002 >1.022451 Trying to match device >1.022455 Device does not match - skipping >1.022462 Checking device (051D/0003) (002/002) >1.059268 - VendorID: 051d >1.059277 - ProductID: 0003 >1.059281 - Manufacturer: American Power Conversion >1.059284 - Product: Smart-UPS 1000 FW:UPS 08.3 / ID=18 >1.059287 - Serial Number: AS1235120308 >1.059290 - Bus: 002 >1.059293 Trying to match device >1.059305 interrupt pipe disabled (add 'pollonly' flag to 'ups.conf' > to get rid of this message) >1.059333 Device matches >1.065694 HID descriptor, m
Re: [Nut-upsuser] CyberPower DX600E won't switch up after power
2012/12/1 Franck > Date: Mon, 26 Nov 2012 19:34:28 +0100 >> From: Arnaud Quette >> To: Franck >> Cc: >> nut-upsuser@lists.alioth.**debian.org >> Subject: Re: [Nut-upsuser] CyberPower DX600E won't switch up after power >> >> >> >> right. we need to monitor the UPS while it's shutting down... >> >> > Well I'd like to try that; but I'm 2000km from my UPS and It seems to be > problematic for me to have the test done. > > But anyway I just got this reply to my quite random inquiry to CyberPower > (wrong country) support: > > "I can only make vague guesses because I have never seen the product you > have, and I am not familiar with the software you used to generate that > data. The following values stand out to me. > > battery.voltage: 4.7 > > battery.voltage.nominal: 12 > > ups.load: 31 > > If I am interpreting them correctly your battery should be at 12 volts, > but it is only at 4.7 volts? > > And the UPS load is 31%? > > > > If the battery is at 4.7 volts it will not pass the power on self-test. It > needs to be somewhere above 10 volts (Perhaps 10.5 or 11)before it will > pass the self-test and let the ups turn on. > > > > Other possibilities. > > If you have the computers set to auto start when power is restored, they > will turn on simultaneously, if there has been a power loss that > significantly drained the batteries, they will have very little energy when > the power is restored. The power on self test checks the CyberPower’s > ability to run on battery by stopping access to wall power and forcing the > UPS on to battery power. If the batteries are very low and the auto > startup of the computers hits while they are being tested then the load of > the computers on the weak battery could cause the voltage to drop and the > self-test would fail. > > > > One or both of your computers has an Active PFC power supply and your UPS > is not a sine wave ups. If you are not familiar with this problem, just > search the internet on the terms “active pfc” and “sine” > > > > The battery in the UPS could be defective. > > > > Again. I do not know the product you are asking about so I can’t provide > an accurate diagnosis. I can only suggest possibilities. > > " > > So if the guy os right and this might be a battery problem. hem, ups.load is the load on the UPS output. what you were looking for is probably battery.charge. battery.voltage seems indeed wrong, but to me, that's another issue. yours is with the restart function, that is tied to the USB/HID data I mentioned before. monitoring these counting down should help understanding how these actually behave. it's true that being 2000kms away doesn't make things easy. but there each problem has at least 1 solution: instead of doing a full reboot cycle, we can just monitor for 10 seconds, and cancel the procedure - stop NUT after the reboot, - restart the driver in debug more (/lib/nut/usbhid-ups -D myups) and upsd (simply type "upsd" as root) in another term - then execute "upscmd -u ... -p ... myups shutdown.return" CAUTION: wait no more than 10-15 seconds!!! Otherwise, your server will crash!!! possibly monitor your unit with upsc - then execute "upscmd -u ... -p ... myups shutdown.cancel" (mention -u and -p to avoid loosing a few seconds!) -then Ctrl+C in the driver term. and send back the driver output, in compressed form. you can then restart everything as usual... cheers, Arnaud -- NUT (Network UPS Tools) Project Leader - http://www.networkupstools.org Debian Developer - http://www.debian.org Free Software Developer - http://arnaud.quette.fr ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Does NUT include support for older UPSD servers?
Charles Lepple wrote: On Dec 4, 2012, at 1:17 PM, David H. Durgee wrote: I have a network with two older systems protected by APC UPSs. Both systems run OS/2 and will continue to do so. Both systems have APC PowerChute Plus 4.2.3 installed and I can use that software to monitor and control both systems. I am also now running several linux systems, in fact I spend almost all my time on the linux systems and these OS/2 systems are servers running in the background which need to be protected. Thus I would like to be able to monitor the UPSs connected to the OS/2 systems from a linux system. Unfortunately that appears to be problematic. The PCP 4.x software appears to use Lan Server for its network protocol while the later APC software uses TCP/IP for networking. The Windows/WfWG version of 4.x lacks network support. The linux version of 4.x is not binary compatible with modern linux systems and is closed source. So if I understand correctly, it is not possible to run the later PowerChute Plus software (that supports TCP/IP) on the OS/2 systems? I have asked this on the APC forums and someone is looking to see if it exists, but if it does it is not on their FTP site. I have posted on the APC forums and they have had nothing further to suggest to me other than to check third-party software or run the OS/2 software in a virtual machine. Given this, I am posting this to ask if there is backward compatibility in your package that would permit me to monitor my UPSs connected via the OS/2 UPSD 4.2.3 software. If not, I guess I will need to look elsewhere. I don't think NUT has support for talking to PowerChute (unless it is hiding under a different name), but if we were to develop something for it, we would probably only target the TCP/IP interface. If it is possible to get the OS/2 boxes to speak the PowerChute protocol over TCP, you might have some success with apcupsd: http://old.nabble.com/APC-PowerChute-Network-Protocol-to5424978.html http://www.apcupsd.com/manual/manual.html#powerchute-network-shutdown-driver-pcnet This is all speculation, however. Another possibility is that I just found out that nut-2.4.3 was ported to OS/2 using GCC 4.3.4, but it is on a restricted access server. This might offer another solution, but then I need to have nut do the same thing PC+ is doing on the OS/2 systems. One of these systems has a P/370 card and there are Rexx scripts run by the PC+ software to inform the P/370 environment about power transitions to allow it to shut down cleanly should it be necessary. I am reluctant to change software on these systems, as they are stable and functional, but this does offer another approach to the issue. Dave ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] setup apc pcnet apc9616
Hi, please keep the traffic on the list! 2012/11/30 Periko Support > On Fri, Nov 30, 2012 at 12:01 PM, Arnaud Quette > wrote: > > > > 2012/11/30 Periko Support > >> > >> Hi friends. > >> > >> Searching for info about how to setup acp pcnet card on nut? > >> > >> Any info will be accepted, thanks!!! > > > > > > is it an SNMP card? > > if yes, then use snmp-ups, otherwise, I'll need more info. > > in all case, please report your results. > > > > cheers, > > Arnaud > > -- > > NUT (Network UPS Tools) Project Leader - http://www.networkupstools.org > > Debian Developer - http://www.debian.org > > Free Software Developer - http://arnaud.quette.fr > > > > The UPS have snmp v1 enable. > Right now with apcupsd is working but in pfsense I just have NUT them > I want to know how can I access my ups. > Any info will be appreciated. > Thanks!!! > as told, you need the snmp-ups driver. put something like the following in your ups.conf file: [myups] driver = snmp-ups port = community = for more information on snmp-ups: http://www.networkupstools.org/docs/man/snmp-ups.html there is also plenty of docs on NUT configuration for pfsense... success report is welcome since 9616 us not currently listed in our supported cards. cheers, Arnaud -- NUT (Network UPS Tools) Project Leader - http://www.networkupstools.org Debian Developer - http://www.debian.org Free Software Developer - http://arnaud.quette.fr ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] bcmxcp_usb can not communicate with Eaton Powerware 5110
2012/12/3 Jevgeni Jurtsenko > Hi Arnaud, Hi Jevgeni, > Unfortunately your patch didn't solved the problem for me. > it couldn't, since your issue is upstream to it (i.e, in kernel land) > I googled about the issue once more while setting the OS second time to > give logs you asked previously. Out of the syslog you can see that it is > being flooded with *usbfs *errors about claiming the device. One of the > suggestions was the problem with *dwc_otg *driver. However > my solution was a script, which resets usb and I'm able to get data from > UPS again.. As I mentioned above that re-plugging the usb cable solved it. > Problem is not stable ~3 fails out of 5 startups. At the moment I am using > PW5115 > > lsusb -v -d0x06da:0x0002 > > Bus 001 Device 004: ID 06da:0002 Phoenixtec Power Co., Ltd UPS > Device Descriptor: > bLength18 > bDescriptorType 1 > bcdUSB 1.10 > bDeviceClass0 (Defined at Interface level) > bDeviceSubClass 0 > bDeviceProtocol 0 > bMaxPacketSize0 8 > idVendor 0x06da Phoenixtec Power Co., Ltd > idProduct 0x0002 UPS > bcdDevice1.00 > iManufacturer 4 > iProduct 24 > iSerial 0 > bNumConfigurations 1 > Configuration Descriptor: > bLength 9 > bDescriptorType 2 > wTotalLength 34 > bNumInterfaces 1 > bConfigurationValue 1 > iConfiguration 0 > bmAttributes 0x80 > (Bus Powered) > MaxPower 60mA > Interface Descriptor: > bLength 9 > bDescriptorType 4 > bInterfaceNumber0 > bAlternateSetting 0 > bNumEndpoints 1 > bInterfaceClass 255 Vendor Specific Class > bInterfaceSubClass 0 > bInterfaceProtocol 0 > iInterface 0 > ** UNRECOGNIZED: 09 21 00 01 00 01 22 00 00 > Endpoint Descriptor: > bLength 7 > bDescriptorType 5 > bEndpointAddress 0x81 EP 1 IN > bmAttributes3 > Transfer TypeInterrupt > Synch Type None > Usage Type Data > wMaxPacketSize 0x0008 1x 8 bytes > bInterval 20 > Device Status: 0x5a08 > (Bus Powered) > ¤¤¤ > *grep usb /var/log/syslog* > Nov 25 11:41:51 raspberrypi kernel: [ 95.021492] usb 1-1.2: usbfs: > process 1862 (bcmxcp_usb) did not claim interface 0 before use > Nov 25 11:41:51 raspberrypi kernel: [ 95.021531] usb 1-1.2: usbfs: > process 1862 (bcmxcp_usb) did not claim interface 0 before use > Nov 25 11:41:51 raspberrypi kernel: [ 95.021573] usb 1-1.2: usbfs: > process 1862 (bcmxcp_usb) did not claim interface 0 before use > Nov 25 11:41:51 raspberrypi kernel: [ 95.021611] usb 1-1.2: usbfs: > process 1862 (bcmxcp_usb) did not claim interface 0 before use > Nov 25 11:41:51 raspberrypi kernel: [ 95.021653] usb 1-1.2: usbfs: > process 1862 (bcmxcp_usb) did not claim interface 0 before use > Nov 25 11:41:51 raspberrypi kernel: [ 95.021693] usb 1-1.2: usbfs: > process 1862 (bcmxcp_usb) did not claim interface 0 before use > Nov 25 11:41:51 raspberrypi kernel: [ 95.021733] usb 1-1.2: usbfs: > process 1862 (bcmxcp_usb) did not claim interface 0 before use > Nov 25 11:41:51 raspberrypi kernel: [ 95.021774] usb 1-1.2: usbfs: > process 1862 (bcmxcp_usb) did not claim interface 0 before use > Nov 25 11:41:51 raspberrypi kernel: [ 95.021815] usb 1-1.2: usbfs: > process 1862 (bcmxcp_usb) did not claim interface 0 before use > Nov 25 11:41:51 raspberrypi kernel: [ 95.021855] usb 1-1.2: usbfs: > process 1862 (bcmxcp_usb) did not claim interface 0 before use > Nov 25 11:41:51 raspberrypi kernel: [ 95.021897] usb 1-1.2: usbfs: > process 1862 (bcmxcp_usb) did not claim interface 0 before use > Nov 25 11:41:51 raspberrypi kernel: [ 95.021936] usb 1-1.2: usbfs: > process 1862 (bcmxcp_usb) did not claim interface 0 before use > Nov 25 11:41:51 raspberrypi kernel: [ 95.021976] usb 1-1.2: usbfs: > process 1862 (bcmxcp_usb) did not claim interface 0 before use > Nov 25 11:41:51 raspberrypi kernel: [ 95.022017] usb 1-1.2: usbfs: > process 1862 (bcmxcp_usb) did not claim interface 0 before use > ¤¤ > */lib/nut/bcmxcp_usb -D -u root -a ups* > Network UPS Tools - BCMXCP UPS driver 0.26 (2.6.5) > USB communication subdriver 0.22 >0.00 send_to_all: SETINFO driver.parameter.port "auto" >0.002520 debug level is '5' >0.019435 entering nutusb_open() >0.037846 device 004 opened successfully >0.039967 Can't claim POWERWARE USB interface: could not claim > interface 0: Device or resource busy >0.041162 Can't reset POWERWARE USB endpoint: could not clear/halt > ep 129: Device
Re: [Nut-upsuser] Does NUT include support for older UPSD servers?
On Dec 4, 2012, at 1:17 PM, David H. Durgee wrote: > I have a network with two older systems protected by APC UPSs. Both systems > run OS/2 and will continue to do so. Both systems have APC PowerChute Plus > 4.2.3 installed and I can use that software to monitor and control both > systems. > > I am also now running several linux systems, in fact I spend almost all my > time on the linux systems and these OS/2 systems are servers running in the > background which need to be protected. Thus I would like to be able to > monitor the UPSs connected to the OS/2 systems from a linux system. > Unfortunately that appears to be problematic. The PCP 4.x software appears to > use Lan Server for its network protocol while the later APC software uses > TCP/IP for networking. The Windows/WfWG version of 4.x lacks network support. > The linux version of 4.x is not binary compatible with modern linux systems > and is closed source. So if I understand correctly, it is not possible to run the later PowerChute Plus software (that supports TCP/IP) on the OS/2 systems? > I have posted on the APC forums and they have had nothing further to suggest > to me other than to check third-party software or run the OS/2 software in a > virtual machine. Given this, I am posting this to ask if there is backward > compatibility in your package that would permit me to monitor my UPSs > connected via the OS/2 UPSD 4.2.3 software. If not, I guess I will need to > look elsewhere. I don't think NUT has support for talking to PowerChute (unless it is hiding under a different name), but if we were to develop something for it, we would probably only target the TCP/IP interface. If it is possible to get the OS/2 boxes to speak the PowerChute protocol over TCP, you might have some success with apcupsd: http://old.nabble.com/APC-PowerChute-Network-Protocol-to5424978.html http://www.apcupsd.com/manual/manual.html#powerchute-network-shutdown-driver-pcnet This is all speculation, however. -- Charles Lepple clepple@gmail ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
