Re: [Nut-upsuser] CyberPower Value 2200E-GP

2010-12-19 Thread Arnaud Quette
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

2010-12-18 Thread Arjen de Korte

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

2010-12-18 Thread David Varley
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

2010-12-18 Thread Charles Lepple

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

2010-12-17 Thread David Varley
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

2010-12-17 Thread Arjen de Korte

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

2010-12-17 Thread David Varley
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

2010-12-16 Thread Arjen de Korte

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

2010-12-16 Thread David Varley
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

2010-12-15 Thread David Varley
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: