Re: [Nut-upsuser] Cyberpower CP850PFCLCD 120% battery charge

2011-04-01 Thread Arjen de Korte

Citeren Charles Lepple clep...@gmail.com:

in the current version of cps-hid.c, it looks like  
FullChargeCapacity, DesignCapacity and CapacityMode are unmapped.


This is intentional. The capacity mode determines the units in which  
FullChargeCapacity and DesignCapacity will be reported. Generally,  
this will be '2' so values are reported in percent (%). In many cases  
they will read 100% at all times (I have yet to find a UPS where the  
FullChargeCapacity drops with aging batteries).


Or, it could be that the firmware designers confused the  
RemainingCapacity value with AbsoluteStateOfCharge, which is allowed  
to be greater than 100%. (Pages 36-38 of the PDC spec.)


That could also be the case. Given the fact that this is a highly  
loaded UPS (56%), it wouldn't be strange that you would need more than  
81% charge left if you set the low battery level to a runtime  
remaining of 300 seconds.


Are two -D flags sufficient to see the report descriptor  
information and relevant reports?


With just two '-D' flags, you'll get a dump of all HID paths that are  
supported by the UPS. We need three '-D' flags however to see the raw  
report descriptor, which I would like to archive for future use.


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 CP850PFCLCD 120% battery charge

2011-04-01 Thread Arjen de Korte

Citeren Justin Ellison jus...@techadvise.com:


When I tested it out tonight, I made a point to watch the LED on the
unit in comparison to the battery.charge indicator from nut.  Almost
instant I unplugged it, battery.charge went from 120 to 91, and
immediately fell in sync with what the LED was showing.


In that case, we should probably just clamp the value to 100%.

Another thing is that the battery voltage doesn't seem to change at  
all, it is fixed at 16.0 V (due to an internal conversion factor of  
2/3 that is needed on some other models).


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] Startup timing issue with CyberPower CP425HG UPS

2011-04-01 Thread Arun
--- On Thu, 3/31/11, Charles Lepple clep...@gmail.com wrote:

 From: Charles Lepple clep...@gmail.com
 Subject: Re: [Nut-upsuser] Startup timing issue with CyberPower CP425HG UPS
 To: Arun twelvefortyf...@yahoo.com
 Cc: nut-upsuser@lists.alioth.debian.org
 Date: Thursday, March 31, 2011, 7:25 PM
 On Mar 30, 2011, at 9:46 PM, Arun
 wrote:
 
  I'm not sure how to fix this, other than to perhaps
 start the ups service from the udev rules file if a known
 USB UPS device has been found, but that seems like a rather
 ugly way to go about this. Does anyone have any thoughts?
 
 I have had a sneaking suspicion that in some situations,
 starting a USB driver from hotplug or udev might work
 better, and this is definitely one of those cases.

Yeap. IMO an even better option (if technically feasible) would be for the 
driver to try and reconnect to the UPS every few seconds. It seems to do this 
well if it loses connectivity after having established the initial connection, 
but not at all at startup.

 
 Before you get too far into this, you probably want to make
 sure that when power returns, your UPS will wait until the
 battery is charged to some threshold before powering on its
 outlets. Otherwise, if the power goes off-on-off (with a
 shutdown after the first power failure), the UPS might try
 to start the computer up with a discharged battery, and due
 to the delay in connecting to the UPS, NUT would not get the
 low battery signal in time to shut down properly the second
 time.

Good point. Unfortunately this UPS is not very fancy, and immediately powers on 
its outlets when the power resumes.

 
 The other trick is that the current NUT USB drivers will
 attempt to reattach to a device if it disappears. Especially
 during testing, it is helpful to be able to unplug and
 re-plug the UPS into the USB port. For this to work, the
 udev script could kill the driver which is waiting around
 for the UPS to come back. (That would only do the right
 thing on a single-UPS system.) Alternatively, you could
 check in the udev script to see if any of the USB drivers
 are running (look for the PID files, and run kill -0 to
 see if the process is still around without actually
 terminating it).

I did a couple of tests and it looks like driver recovers well once the UPS is 
reconnected to the system. Unfortunately it doesn't seem to try to reconnect at 
all at startup.

 
 On the other hand, you can also look into whether your
 startup scripts have configurable dependencies, and tell the
 NUT init.d script to start after the USB service has fully
 initialized. Not sure how that works in Fedora.

Me neither. I don't know if there is a USB service per se in Fedora; USB 
devices announce themselves individually as they are connected to the system. 
Most USB devices (the kbd, mouse, another UPS I tested) register with the 
system *before* the init.d script starts, it's just this one UPS that registers 
much later for some reason.

 

___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser