Bug#671444: [Nut-upsuser] Bug#671444: LiebertPSP

2012-06-11 Thread Arnaud Quette
2012/6/10 Tim Gould tgo...@reverb.com.au

 I upgraded to trunk (3652) - it worked, but again with the seemingly
 spurious RB during DISCHRG.


more than a upsd trace, we need usbhid-ups (-D) to be able to see
what's going on...
Ie, is the device actually reporting RB
(UPS.PowerSummary.PresentStatus.NeedReplacement == 1...) or not.


 -DDD output attached. RB turns up just before battery.charge.low is
 reached (around 1551 sec), at the same time LB turns up too.

 Once a slave client (on the same UPS) shuts down battery.charge goes back
 up above battery.charge.low, so LB goes away, but RB stays.

 I didn't have upsmon running on this host so it ran until the battery was
 depleted rather than shutting down.


the above use case should not be a problem, since an initiated shutdown
(master + slave) will go to the completion.
a variation, where the above result is desired, is load shedding, where you
want to shutdown non critical loads, to get more runtime for the critical
ones...


 Hope this helps, thanks, Tim.


it indeed helps, thanks Tim.

cheers,
Arnaud
-- 
Linux / Unix / Opensource Engineering Expert - Eaton -
http://opensource.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


Bug#671444: [Nut-upsuser] Bug#671444: LiebertPSP

2012-05-21 Thread Arnaud Quette
Hi Tim,

2012/5/11 Tim Gould tgo...@reverb.com.au:
 FWIW I've had this running just fine since my earlier posts. Several power 
 outages have been dealt with perfectly.

 I haven't had the time to set up and test debug logs around RB but if this is 
 the sticking point I'll try harder to find that time :)

 I'm happy to pull a fresh version and test.

thanks for your feedback.
As told in my separate answer, I've just committed Charles' patch to
the trunk (r3607).
So if you can do some testing, especially on LB/RB, I would be grateful.

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/


 On 10/05/2012, at 21:58 , Charles Lepple wrote:

 On May 10, 2012, at 4:38 AM, Arnaud Quette wrote:

 2012/5/10 Charles Lepple clep...@gmail.com:
 On May 9, 2012, at 11:27 AM, Arnaud Quette wrote:

 this thread has just popped again, but on the Debian side this time:
 http://bugs.debian.org/671444

 what's exactly the situation of fixes WRT issues?
 the last mail I have on this thread is attached below...

 Attached is a patch corresponding to the following branch:

  https://github.com/clepple/nut/tree/git-LiebertPSP-scalefactor

 At this point, it is probably safe to merge.

 it applies fine on the trunk.
 should I go ahead and merge it?

 Sure, but is it possible to build a .deb for Alastair to test, just to make 
 sure we're fixing the same problem? (I'm not sure if Debian has something 
 like Ubuntu's PPA system.)

 Aside: it is annoying that with a 16-bit field for the USB PID, companies 
 insist on reusing the VID:PID combinations for drastically different 
 firmware.

 also, does it fix all the known issues related to this scaling factor?

 The two potential remaining problems are with ups.load and the RB flag, but 
 they are not as critical as the OB/LB flags.

 It does not, however, change the subdriver to liebert-hid.

 I'm not sure to get all the whizzbang that may hide behind this comment ;-)
 AFAIK, liebert-hid seems to be for Liebert OEM manufactured by
 Phoenixtec with a limited set of data.
 while belkin-hid has a more advanced approach.
 so it's fine as you did. the problem of subdriver naming is something
 else, that will never be able to completely address due to mergers,
 OEM, ...

 In this message, Alastair cited Pier's patch which changes the subdriver for 
 10af:0001 from belkin-hid to liebert-hid. Due to the way that we match the 
 HID usages, we probably could have put the scale fixes in the liebert-hid 
 subdriver instead, but I agree that belkin-hid is probably the right mapping 
 under the hood.

 --
 Charles Lepple
 clepple@gmail



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#671444: [Nut-upsuser] Bug#671444: LiebertPSP

2012-05-11 Thread Tim Gould
FWIW I've had this running just fine since my earlier posts. Several power 
outages have been dealt with perfectly.

I haven't had the time to set up and test debug logs around RB but if this is 
the sticking point I'll try harder to find that time :)

I'm happy to pull a fresh version and test.

On 10/05/2012, at 21:58 , Charles Lepple wrote:

 On May 10, 2012, at 4:38 AM, Arnaud Quette wrote:
 
 2012/5/10 Charles Lepple clep...@gmail.com:
 On May 9, 2012, at 11:27 AM, Arnaud Quette wrote:
 
 this thread has just popped again, but on the Debian side this time:
 http://bugs.debian.org/671444
 
 what's exactly the situation of fixes WRT issues?
 the last mail I have on this thread is attached below...
 
 Attached is a patch corresponding to the following branch:
 
  https://github.com/clepple/nut/tree/git-LiebertPSP-scalefactor
 
 At this point, it is probably safe to merge.
 
 it applies fine on the trunk.
 should I go ahead and merge it?
 
 Sure, but is it possible to build a .deb for Alastair to test, just to make 
 sure we're fixing the same problem? (I'm not sure if Debian has something 
 like Ubuntu's PPA system.)
 
 Aside: it is annoying that with a 16-bit field for the USB PID, companies 
 insist on reusing the VID:PID combinations for drastically different firmware.
 
 also, does it fix all the known issues related to this scaling factor?
 
 The two potential remaining problems are with ups.load and the RB flag, but 
 they are not as critical as the OB/LB flags.
 
 It does not, however, change the subdriver to liebert-hid.
 
 I'm not sure to get all the whizzbang that may hide behind this comment ;-)
 AFAIK, liebert-hid seems to be for Liebert OEM manufactured by
 Phoenixtec with a limited set of data.
 while belkin-hid has a more advanced approach.
 so it's fine as you did. the problem of subdriver naming is something
 else, that will never be able to completely address due to mergers,
 OEM, ...
 
 In this message, Alastair cited Pier's patch which changes the subdriver for 
 10af:0001 from belkin-hid to liebert-hid. Due to the way that we match the 
 HID usages, we probably could have put the scale fixes in the liebert-hid 
 subdriver instead, but I agree that belkin-hid is probably the right mapping 
 under the hood.
 
 -- 
 Charles Lepple
 clepple@gmail
 
 
 
 
 ___
 Nut-upsuser mailing list
 nut-upsu...@lists.alioth.debian.org
 http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser




--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org