Re: [Nut-upsuser] CyberPower Value 2200E-GP
Regarding my observation that the processes keep running after I sudo service nut stop, I found this isn't exactly the case. I think what happens is that if I forget the sudo in front of the command, it comes up with the Stopping Nut Tools... Done line, as if it worked, however it actually failed and the processes are still running. If I then start the services again, it actually starts another instance, that is there are two copies of the usb driver running. (And leaving complaining messages in the log!) If I then stop the services (correctly, with the sudo) one still remains, and it can only be stopped with an explicit kill command. This is what I was seeing. As far as setting the shutdown command in a script run when hibernating, I did this. I created a script, 48nut, in /etc/pm/sleep.d, as follows: #!/bin/sh # If we are hibernating due to power-fail, initiate a delayed UPS shutdown and then stop the nut services # If we are thawing after this event, start the nut service # DAV 17DEC10 if (test -f /etc/killpower) then case $1 in hibernate|suspend) echo Initiating UPS Powerdown Sequence /sbin/upsdrvctl shutdown echo Stopping nut service service nut stop ;; thaw|resume) service nut start ;; *) exit $NA ;; esac fi Unfortunately it didn't work, perhaps the service is stopped before the shutdown has a chance to take effect. In /var/log/pm-suspend.log. On hibernate I see: /etc/pm/sleep.d/48nut hibernate hibernate:Initiating UPS Powerdown Sequence *Startup timer elapsed, continuing...* Network UPS Tools - UPS driver controller 2.4.3 Stopping nut service * Stopping Network UPS Tools ...done. success. /usr/lib/pm-utils/sleep.d/49bluetooth hibernate hibernate:not applicable. Then on thaw I see: /usr/lib/pm-utils/sleep.d/49bluetooth thaw hibernate:not applicable. /etc/pm/sleep.d/48nut thaw hibernate: * Starting Network UPS Tools however the shutdown never occurs, and after the thaw the nut services are not running! If I have the shutdown command in the script, but not the command to stop the nut services, then the UPS does shut down. So, for now I'm going back to my single line SHUTDWNCMD which actually worked. David ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
[Nut-upsuser] online zinto usv
Hello, today I'm fighting with a Online Zinto 1000 (lsusb.txt) produced by Phoenixtec/Eaton ;-) http://www.eaton.com/EatonCom/OurCompany/NewsandEvents/NewsList/CT_141334 I have tested different drivers without success (please see attachments usbhid-ups.txt, bcmxcp_usb.txt, blazer_usb.txt) The help got unfortunately time outs (explore.txt) http://www.networkupstools.org/doc/2.2.0/hid-subdrivers.html Have you an idea for my problems? Mit freundlichen Grüßen Carsten Network UPS Tools - Generic HID driver 0.34 (2.4.3) USB communication driver 0.31 /lib/nut/usbhid-ups -a zinto -x vendorid=06da -DD -x explore nut-explore.txt 0.00 debug level is '2' 0.000706 upsdrv_initups... 0.121349 Checking device (1D6B/0001) (002/001) 0.121378 - VendorID: 1d6b 0.121389 - ProductID: 0001 0.121399 - Manufacturer: unknown 0.121408 - Product: unknown 0.121417 - Serial Number: unknown 0.121427 - Bus: 002 0.121436 Trying to match device 0.121452 Device does not match - skipping 0.121474 Checking device (06DA/0601) (001/005) 0.143508 - VendorID: 06da 0.143530 - ProductID: 0601 0.143550 - Manufacturer: ONLINE 0.143560 - Product: ZINTO 0.143569 - Serial Number: unknown 0.143579 - Bus: 001 0.143588 Trying to match device 0.143611 Device matches 0.149519 HID descriptor length 27 0.158535 Report Descriptor size = 27 0.158626 Using subdriver: EXPLORE HID 0.1 0.161540 refresh_report_buffer: expected 2 bytes, but got 8 instead 0.161568 Path: ffa4.ffa6, Type: Input, ReportID: 0x00, Offset: 0, Size: 8, Value: 0.00 0.161585 Path: ffa4.ffa7, Type: Output, ReportID: 0x00, Offset: 0, Size: 8, Value: 0.00 0.161677 Report descriptor retrieved (Reportlen = 27) 0.161689 Found HID device 0.161701 Detected a UPS: ONLINE/ZINTO 0.161712 find_nut_info: unknown info type: load.off.delay 0.161723 find_nut_info: unknown info type: load.on.delay 0.161733 find_nut_info: unknown info type: load.off.delay 0.161753 upsdrv_initinfo... 0.161769 upsdrv_updateinfo... 0.412579 libusb_get_interrupt: Connection timed out 0.412614 Got 0 HID objects... 0.412625 Quick update... 0.412721 dstate_init: sock /var/run/nut/usbhid-ups-zinto open on fd 5 0.412746 upsdrv_updateinfo... 0.663875 libusb_get_interrupt: Connection timed out 0.663909 Got 0 HID objects... 0.663920 Quick update... 2.415153 upsdrv_updateinfo... 2.665335 libusb_get_interrupt: Connection timed out 2.665367 Got 0 HID objects... 2.665378 Quick update... 4.416828 upsdrv_updateinfo... 4.667774 libusb_get_interrupt: Connection timed out 4.667808 Got 0 HID objects... 4.667819 Quick update... ^C 6.293200 Signal 2: exiting 6.293236 upsdrv_cleanup... Bus 001 Device 005: ID 06da:0601 Phoenixtec Power Co., Ltd 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 0x0601 bcdDevice0.00 iManufacturer 3 ONLINE iProduct1 ZINTO iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 34 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xa0 (Bus Powered) Remote Wakeup MaxPower 100mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 3 Human Interface Device bInterfaceSubClass 0 No Subclass bInterfaceProtocol 0 None iInterface 0 HID Device Descriptor: bLength 9 bDescriptorType33 bcdHID 1.11 bCountryCode0 Not supported bNumDescriptors 1 bDescriptorType34 Report wDescriptorLength 27 Report Descriptor: (length is 27) Item(Global): Usage Page, data= [ 0xa0 0xff ] 65440 (null) Item(Local ): Usage, data= [ 0x04 ] 4 (null) Item(Main ): Collection, data= [ 0x01 ] 1 Application Item(Local ): Usage, data= [ 0x06 ] 6
Re: [Nut-upsuser] CyberPower Value 2200E-GP
Citeren David Varley davidavar...@gmail.com: As far as setting the shutdown command in a script run when hibernating, I did this. I created a script, 48nut, in /etc/pm/sleep.d, as follows: #!/bin/sh # If we are hibernating due to power-fail, initiate a delayed UPS shutdown and then stop the nut services # If we are thawing after this event, start the nut service # DAV 17DEC10 if (test -f /etc/killpower) then case $1 in hibernate|suspend) echo Initiating UPS Powerdown Sequence /sbin/upsdrvctl shutdown echo Stopping nut service service nut stop This won't work. In order to send a poweroff command to the UPS, the drivers must be restarted from scratch. Therefor you must run 'service nut stop' before doing that, otherwise the backgrounded drivers will not have exited. It also is a good idea to put a 'sleep 2' between the two commands, to give the drivers some time to respond to the KILL signal they receive: echo Stopping nut service service nut stop sleep 2 echo Initiating UPS Powerdown Sequence /sbin/upsdrvctl shutdown Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] online zinto usv
Citeren Carsten Burkhardt c.burkha...@b-c-s.de: The help got unfortunately time outs (explore.txt) http://www.networkupstools.org/doc/2.2.0/hid-subdrivers.html Have you an idea for my problems? Looking at the VendorID and ProductID, it is likelt that this device is recognized as a /dev/tttyUSB(0|1...) device. As such you should probably point the blazer_ser or megatec drivers to this port. Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] upsdrvctl doesn't seem to start with init.d
2010/12/16 Zach La Celle lace...@roboticresearch.com I can run upsdrvctl start and it starts fine. On computer boot, however, it doesn't start properly. I'm trying to find the logs which would give more detail, but I'm not sure where they are. I see no logs in /etc/nut or /var/log. try running directly your driver in debug mode (as root), ie: $ /path/to/apcsmart -DDD -a upsname and send us back the output. have you also verified device privileges? (ie ls -l /dev/ttyS0 or something like that) cheers, Arnaud -- Linux / Unix Expert RD - Eaton - http://powerquality.eaton.com Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org/ Debian Developer - http://www.debian.org Free Software Developer - http://arnaud.quette.free.fr/ Permission settings were as follows: ups.conf, upsd.conf, upsd.users, upsmon.conf, upssched.conf: 640, root.nut hosts.conf, nut.conf, upsset.conf, upsstats.conf, upsstats-single.html: 644, root.root I tried changing them all to root.nut and 644. It's hard to know what works and what doesn't, because when I start the process manually it seems to work fine. The output of /lib/nut/apcsmart -DDD -a rack3ups when run as root is: Network UPS Tools - APC Smart protocol driver 2.03 (2.4.3) APC command table version 2.1 0.00 debug level is '3' 0.046913 Attempting firmware lookup 0.133912 Not found in table - trying normal method 0.133922 APC - Attempting to find command set 0.705908 APC - Parsing out command set 0.705925 UPS supports variable [ups.model] 0.849914 UPS supports command [load.on] 0.849925 UPS supports variable [input.quality] 0.893910 UPS supports variable [battery.packs] 0.949928 UPS supports command [test.panel.start] 0.949943 UPS supports variable [battery.voltage] 1.025917 UPS supports variable [ups.temperature] 1.097916 UPS supports command [calibrate.start] 1.097927 UPS supports command [calibrate.stop] 1.097936 UPS supports variable [ups.test.interval] 1.149916 UPS supports variable [input.frequency] 1.221911 UPS supports variable [input.transfer.reason] 1.257912 UPS supports command [shutdown.stayoff] 1.257922 UPS supports variable [input.voltage] 1.333914 UPS supports variable [input.voltage.maximum] 1.405916 UPS supports variable [input.voltage.minimum] 1.481917 UPS supports variable [output.voltage] 1.559161 UPS supports variable [ups.load] 1.629912 UPS supports command [shutdown.return] 1.629923 UPS supports command [test.failure.start] 1.629933 protocol_verify: 0x56 [V] unrecognized 1.629940 UPS supports command [test.battery.start] 1.629947 UPS supports command [test.battery.stop] 1.629955 UPS supports variable [ups.test.result] 1.673913 UPS supports command [load.off] 1.673925 UPS supports variable [ups.firmware] 1.757914 UPS supports variable [ups.id] 1.849918 UPS supports variable [battery.charge.restart] 1.890663 UPS supports variable [battery.charge] 1.965911 UPS supports variable [battery.voltage.nominal] 2.013911 UPS supports variable [battery.runtime] 2.089915 UPS supports variable [battery.alarm.threshold] 2.121912 UPS supports variable [input.transfer.low] 2.173914 UPS supports variable [ups.mfr.date] 2.265911 UPS supports variable [ups.serial] 2.405916 UPS supports variable [output.voltage.nominal] 2.457913 UPS supports variable [ups.delay.shutdown] 2.505911 UPS supports variable [battery.runtime.low] 2.549915 UPS supports variable [ups.delay.start] 2.597914 UPS supports variable [input.sensitivity] 2.633914 UPS supports variable [input.transfer.high] 2.681913 UPS supports variable [battery.date] 2.773917 APC - About to get capabilities string 4.913922 Supported capability: 75 (D) - input.transfer.high 4.914006 Supported capability: 6c (D) - input.transfer.low 4.914061 Supported capability: 65 (4) - battery.charge.restart 4.914090 Supported capability: 6f (D) - output.voltage.nominal 4.914105 Supported capability: 73 (4) - input.sensitivity 4.914125 Supported capability: 71 (4) - battery.runtime.low 4.914147 Supported capability: 70 (4) - ups.delay.shutdown 4.914166 Supported capability: 6b (4) - battery.alarm.threshold 4.914184 Supported capability: 72 (4) - ups.delay.start 4.914202 Supported capability: 45 (4) - ups.test.interval 4.914219 APC - UPS capabilities determined Detected SMART-UPS 2200 [YS0234212126] on /dev/ttyUSB0 4.957916 update_info_all: starting 7.027656 update_info_all: done 7.027694 dstate_init: sock /var/run/nut/apcsmart-rack3ups open on fd 5 7.067659 update_info_normal: starting 7.935414 update_info_normal: done 8.877741 new connection on
Re: [Nut-upsuser] upsdrvctl doesn't seem to start with init.d
2010/12/17 Zachary LaCelle lace...@roboticresearch.com 2010/12/16 Zach La Celle lace...@roboticresearch.com I can run upsdrvctl start and it starts fine. On computer boot, however, it doesn't start properly. I'm trying to find the logs which would give more detail, but I'm not sure where they are. I see no logs in /etc/nut or /var/log. try running directly your driver in debug mode (as root), ie: $ /path/to/apcsmart -DDD -a upsname and send us back the output. have you also verified device privileges? (ie ls -l /dev/ttyS0 or something like that) cheers, Arnaud -- Linux / Unix Expert RD - Eaton - http://powerquality.eaton.com Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org/ Debian Developer - http://www.debian.org Free Software Developer - http://arnaud.quette.free.fr/ Permission settings were as follows: ups.conf, upsd.conf, upsd.users, upsmon.conf, upssched.conf: 640, root.nut hosts.conf, nut.conf, upsset.conf, upsstats.conf, upsstats-single.html: 644, root.root I tried changing them all to root.nut and 644. have you also verified *device* privileges? (ie ls -l /dev/ttyS0 or something like that) and how are you setting these (ie using udev, rc.local, ...) It's hard to know what works and what doesn't, because when I start the process manually it seems to work fine. if the boot time problem still occurs, check around device privileges, udev startup (before NUT) if used to set *device* privileges. cheers Arno ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] upsdrvctl doesn't seem to start with init.d
Citeren Zachary LaCelle lace...@roboticresearch.com: It's hard to know what works and what doesn't, because when I start the process manually it seems to work fine. Have a look at this bug report and check if this might be the problem: https://bugzilla.redhat.com/show_bug.cgi?id=544121 Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] CyberPower Value 2200E-GP
On Fri, 17 Dec 2010 17:41:39 +0100, Arjen de Korte nut+us...@de-korte.orgnut%2bus...@de-korte.org wrote: Citeren David Varley davidavar...@gmail.com: As far as setting the shutdown command in a script run when hibernating, I did this. I created a script, 48nut, in /etc/pm/sleep.d, as follows: #!/bin/sh # If we are hibernating due to power-fail, initiate a delayed UPS shutdown and then stop the nut services # If we are thawing after this event, start the nut service # DAV 17DEC10 if (test -f /etc/killpower) then case $1 in hibernate|suspend) echo Initiating UPS Powerdown Sequence /sbin/upsdrvctl shutdown echo Stopping nut service service nut stop This won't work. In order to send a poweroff command to the UPS, the drivers must be restarted from scratch. Therefor you must run 'service nut stop' before doing that, otherwise the backgrounded drivers will not have exited. It also is a good idea to put a 'sleep 2' between the two commands, to give the drivers some time to respond to the KILL signal they receive: echo Stopping nut service service nut stop sleep 2 echo Initiating UPS Powerdown Sequence /sbin/upsdrvctl shutdown Best regards, Arjen Arjen, now I'm a bit confused. In your script you are saying to shut down nut before issuing the upsdrvctl command to tell the UPS to start a delayed shutdown. But as shutting down nut causes the usbhid-ups driver to exit, I thought that would prevent the command being sent to the UPS? I know that if I just have the upsdrvctl shutdown command without telling the nut service to exit, the UPS shuts down after the 60 second delay. I can understand adding the delay after giving the shutdown command and before stopping the services, but not the other way around. What am I missing here? Thanks, David ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
[Nut-upsuser] Comet EXtreme 6 and mge-utalk
Hi Sabine and Christoph, I've just committed a few changes to mge-utalk (r2749). can you please try a snapshot and report back the results: http://new.networkupstools.org/download.html#Snapshots cheers, Arnaud -- Linux / Unix Expert RD - Eaton - http://powerquality.eaton.com Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org/ Debian Developer - http://www.debian.org Free Software Developer - http://arnaud.quette.free.fr/ ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
