Re: [Nut-upsuser] CyberPower Value 2200E-GP
2010/12/18 Arjen de Korte nut+us...@de-korte.org nut%2bus...@de-korte.org Citeren David Varley davidavar...@gmail.com: Given all this, no doubt it is somewhere obvious, when you know where to look. But I was not planning to be a developer, just a user, and I have a huge stack of work in front of me and Xmas coming up, and I would really like to get this nailed down and move on, so if you could please point me to the required documentation I would be most grateful. I'm very sorry, but we seem to have an issue with building the distribution packages. It has been in the sources since nut-2.4.0, but I only just found out that we failed to put it in the source tar ball. It's attached to this message. My apologies... FYI, as of 2.6.0 (and the current trunk), this content is part of docs/config-notes.txt. and, as pointed by Charles, it's available as chapter 6, Configuration notes in the user manual. cheers, Arnaud ___ 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
Citeren David Varley davidavar...@gmail.com: 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. Yes. But as shutting down nut causes the usbhid-ups driver to exit, I thought that would prevent the command being sent to the UPS? There are two ways to make a UPS kill it's output: - send a command to a backgrounded driver through upsd to tell it to shutdown (through the web interface or upscmd for instance) - starting the driver with '-k' flag on the command line (this is the method that upsdrvctl shutdown uses, see 'man 8 nutupsdrv') 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. There will be two drivers fighting for control over the same UPS. This will not work at all for serial devices (since the port will be locked by the backgrounded driver). In case of USB connected ones, you might be lucky that the driver started with the '-k' flag will have control over the USB interface long enough to send the shutdown command, but this is not reliable. You should not take your chances here. 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? You missed reading the docs/suspend-to-disk.txt file, where it is explained how you should set this up. If you want to know the details about this, start reading the remainder of the documents in docs/ before asking. 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
Arjen de Korte nut+us...@de-korte.org nut%2bus...@de-korte.org wrote: ... You missed reading the docs/suspend-to-disk.txt file, where it is explained how you should set this up. If you want to know the details about this, start reading the remainder of the documents in docs/ before asking. Best regards, Arjen Arjen, That document would be really useful to know about! I started out wanting to use this package, and I installed the packaged version for my OS in the usual way, and read all the man pages. No mention of suspend there. I read through the online documentation on the web site. Nothing there, either. So I downloaded the source to the latest stable release, and I read everything in the /docs folder. Nothing there, no suspend-to-disk.txt or any mention of suspend. It was only at this point that I finally made my first request to the list for help! Ok, now you told me there is a docs/suspend-to-disk.txt file, I looked further. In the development release files on the web site. No, not there. Can Google find it for me? No, it seems it hasn't been indexed anywhere either. Given all this, no doubt it is somewhere obvious, when you know where to look. But I was not planning to be a developer, just a user, and I have a huge stack of work in front of me and Xmas coming up, and I would really like to get this nailed down and move on, so if you could please point me to the required documentation I would be most grateful. Regards, David ___ 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 Dec 18, 2010, at 7:21 AM, David Varley wrote: So I downloaded the source to the latest stable release, and I read everything in the /docs folder. Nothing there, no suspend-to- disk.txt or any mention of suspend. It appears that suspend-to-disk did not make it into the 2.4.3 tarball. Here it is in the new User Manual: http://buildbot.networkupstools.org/~buildbot/cayenne/docs/latest/website/output/docs/user-manual.chunked/ar01s06.html#_using_suspend_to_disk ___ 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
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
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] 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
Re: [Nut-upsuser] CyberPower Value 2200E-GP
Citeren David Varley davidavar...@gmail.com: I've just set up a CyberPower Value 2200E-GP on a system running Lucid AMD64, with the current NUT package via apt-get, and it seems to be working fine for me with the usbhid-ups driver, so I guess it can go in the HCL? Probably. We'll just need a little more information like the 'upsc' output for this UPS (to see if we need to add additional mappings). I'm using the system to host several virtual servers under KVM, and to make things simple I set it up to hibernate rather than shutdown, that way all the guest OS don't have to be shutdown, they just carry on happily from where they were after power is restored. To achieve this I timed how long it take to go into hibernation (30-40 seconds), and set the UPS to shutdown after 60 seconds via the driver offdelay setting. I then set: SHUTDOWNCMD /sbin/upsdrvctl shutdown;/usr/sbin/pm-hibernate and under test it works well. I'm don't know if there is a better or right way to do this, obviously the heuristically determined off delay is a bit of a risk, and as the system doesn't actually shut down perhaps there will be other problems with NUT? The /etc/killpower flag isn't deleted, for instance. Remember that the 'upsd' server will latch the FSD (forced shutdown) flag when it has detected an OB LB condition. The only way to reset this, is to restart NUT. Otherwise after resuming, NUT will immediately shutdown again. Many systems will allow you to run scripts when going into hibernation and after resuming. You'll want to stop NUT when hibernating and restart it when resuming (this will take care of the /etc/killpower flag as well). I'd prefer to run the 'upsdrvctl shutdown' command from the hibernation script as well. Also remember that there is a slight risk that if hibernation fails, the UPS will power off anyway. If that worries you, it might be better to stick with a full shutdown of the system. I've attached the output of *usbhid-ups -DDD -a 2200LCD* as there seem to be several errors reported in there. I can see the subdriver doesn't find the serial number, for example, while the pwrstat code supplied by CyberPower does. There are some issues with the usbhid-ups driver in nut-2.4.3. Most of these have been resolved in the development version of NUT. I would be grateful if you could try out this. Most (if not all) of the errors you're seeing now should be fixed. We could add some code to add reading the serial number, but we really need it before claiming the device (which seems to be broken in either your UPS or the version of libusb you're using). 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
Arjen, I've appended the output of upsc I'll keep in mind your warning about the upsd server latching the FSD flag and requiring a restart, however I'm just running the packaged Ubuntu/Lucid version at this stage so I don't have too much flexibility. NUT seems to be set up as a service, so that it starts correctly on system boot, however it was probably assumed it would run until a system shutdown as the scripts don't handle stopping the service. When I : *sudo service nut stop* the NUT processes continue running. I doubt I'll have a chance to spend more time on this before Christmas. Regards, David da...@xeno:/etc/nut$ upsc 2200...@localhost battery.charge: 100 battery.charge.low: 10 battery.charge.warning: 20 battery.mfr.date: CPS battery.runtime: 3270 battery.runtime.low: 300 battery.type: PbAcid battery.voltage: 13.9 battery.voltage.nominal: 24 device.mfr: CPS device.model: Value 2200E device.type: ups driver.name: usbhid-ups driver.parameter.offdelay: 60 driver.parameter.ondelay: 70 driver.parameter.pollfreq: 30 driver.parameter.pollinterval: 2 driver.parameter.port: auto driver.parameter.productid: 0501 driver.parameter.vendorid: 0764 driver.version: 2.4.3 driver.version.data: CyberPower HID 0.3 driver.version.internal: 0.34 input.transfer.high: 263 input.transfer.low: -96 input.voltage: 240.0 input.voltage.nominal: 230 output.voltage: 240.0 ups.beeper.status: enabled ups.delay.shutdown: 20 ups.delay.start: 30 ups.load: 14 ups.mfr: CPS ups.model: Value 2200E ups.productid: 0501 ups.realpower.nominal: 296 ups.status: FSD OL ups.test.result: Done and passed ups.timer.shutdown: -60 ups.timer.start: 0 ups.vendorid: 0764 ___ ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
[Nut-upsuser] CyberPower Value 2200E-GP
I've just set up a CyberPower Value 2200E-GP on a system running Lucid AMD64, with the current NUT package via apt-get, and it seems to be working fine for me with the usbhid-ups driver, so I guess it can go in the HCL? I'm using the system to host several virtual servers under KVM, and to make things simple I set it up to hibernate rather than shutdown, that way all the guest OS don't have to be shutdown, they just carry on happily from where they were after power is restored. To achieve this I timed how long it take to go into hibernation (30-40 seconds), and set the UPS to shutdown after 60 seconds via the driver offdelay setting. I then set: SHUTDOWNCMD /sbin/upsdrvctl shutdown;/usr/sbin/pm-hibernate and under test it works well. I'm don't know if there is a better or right way to do this, obviously the heuristically determined off delay is a bit of a risk, and as the system doesn't actually shut down perhaps there will be other problems with NUT? The /etc/killpower flag isn't deleted, for instance. I've attached the output of *usbhid-ups -DDD -a 2200LCD* as there seem to be several errors reported in there. I can see the subdriver doesn't find the serial number, for example, while the pwrstat code supplied by CyberPower does. Cheers, David Results for CyberPower Value 2200E-GP (Their pwrstat utility reports Serial: BFF7104#7N5) sudo /lib/nut/usbhid-ups -DDD -a 2200LCD Network UPS Tools - Generic HID driver 0.34 (2.4.3) USB communication driver 0.31 0.00 debug level is '3' 0.001882 upsdrv_initups... 0.221831 Checking device (1D6B/0001) (005/001) 0.221884 - VendorID: 1d6b 0.221891 - ProductID: 0001 0.221897 - Manufacturer: Linux 2.6.32-26-server uhci_hcd 0.221903 - Product: UHCI Host Controller 0.221909 - Serial Number: :00:1d.3 0.221915 - Bus: 005 0.221920 Trying to match device 0.221937 Device does not match - skipping 0.221948 Checking device (0764/0501) (004/015) 0.243852 - VendorID: 0764 0.243865 - ProductID: 0501 0.243871 - Manufacturer: CPS 0.243877 - Product: Value 2200E 0.243883 - Serial Number: unknown 0.243888 - Bus: 004 0.243893 Trying to match device 0.243960 Device matches 0.243984 failed to claim USB device: could not claim interface 0: Device or resource busy 0.246013 detached kernel driver from USB device... 0.253853 HID descriptor, method 1: (9 bytes) = 09 21 10 01 21 01 22 8b 01 0.253870 HID descriptor, method 2: (9 bytes) = 09 21 10 01 21 01 22 8b 01 0.253876 HID descriptor length 395 0.306863 Report Descriptor size = 395 0.306885 Report Descriptor: (395 bytes) = 05 84 09 04 a1 01 09 24 a1 00 85 01 09 fe 0.306896 75 08 95 01 15 00 26 ff 00 b1 22 85 02 09 ff b1 22 85 03 05 85 09 89 b1 22 0.306907 85 04 09 8f b1 22 85 05 09 8b b1 22 85 06 09 2c b1 22 85 07 75 08 95 06 25 0.306918 78 09 83 09 8d 09 8e 09 8c 09 29 09 67 b1 22 85 08 75 08 95 01 65 00 09 66 0.306929 81 a2 09 66 b1 a2 09 68 75 10 27 ff ff 00 00 66 01 10 81 a2 09 68 b1 a2 09 0.306940 2a 26 58 02 81 a2 09 2a b1 a2 85 09 75 08 26 ff 00 05 84 09 40 67 21 d1 f0 0.306951 00 55 06 b1 22 85 0a 09 30 b1 a2 65 00 55 00 09 02 a1 02 85 0b 75 01 95 06 0.306962 25 01 05 85 09 d0 09 44 09 45 09 42 09 46 09 43 81 a2 09 d0 09 44 09 45 09 0.306973 42 09 46 09 43 b1 a2 75 02 95 01 81 01 b1 01 c0 85 0c 05 84 09 5a 75 08 15 0.306984 01 25 03 b1 a2 85 0d 09 fd 15 00 26 ff 00 b1 22 c0 05 84 09 1a a1 00 85 0e 0.306995 05 84 09 40 75 08 67 21 d1 f0 00 55 07 b1 22 85 0f 75 10 26 07 01 09 30 b1 0.307006 a2 85 10 09 53 75 08 15 a0 25 a0 b1 22 75 10 09 54 16 07 01 26 07 01 b1 22 0.307016 c0 09 1c a1 00 85 12 09 30 15 00 b1 a2 75 08 65 00 55 00 85 13 09 35 b1 a2 0.307027 85 14 09 58 25 06 b1 a2 85 15 09 57 75 10 15 ff 26 ff 7f 35 c4 47 c4 ff 1d 0.307038 00 66 01 10 b1 a2 85 16 09 56 b1 a2 85 17 09 6e 75 01 15 00 25 01 35 00 45 0.307048 00 65 00 b1 a2 09 65 b1 a2 75 06 b1 01 85 18 75 10 09 44 26 c2 01 66 21 d1 0.307056 55 07 b1 a2 c0 c0 0.307133 Using subdriver: CyberPower HID 0.3 0.310846 refresh_report_buffer: expected 2 bytes, but got 8 instead 0.310858 Report[err]: (8 bytes) = 01 01 98 0d 2c 01 64 00 0.310870 Path: UPS.PowerSummary.iProduct, Type: Feature, ReportID: 0x01, Offset: 0, Size: 8, Value: 1.00 0.314846 refresh_report_buffer: expected 2 bytes, but got 8 instead 0.314859 Report[err]: (8 bytes) = 02 02 98 0d 2c 01 64 00 0.314869 Path: UPS.PowerSummary.iSerialNumber, Type: Feature, ReportID: 0x02, Offset: 0, Size: 8, Value: 2.00 0.318844 refresh_report_buffer: expected 2 bytes, but got 8 instead 0.318856 Report[err]: (8 bytes) = 03 04 98 0d 2c 01 64 00 0.318866 Path: UPS.PowerSummary.iDeviceChemistry, Type:
