[Nut-upsuser] Bug#671444: LiebertPSP

[Tim Gould]

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

-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.

Hope this helps, thanks, Tim.

On 21/05/2012, at 20:46 , Arnaud Quette wrote:

> Hi Tim,
> 
> 2012/5/11 Tim Gould <tgould at 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 R&D - 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 <clepple at 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 at gmail
-------------- next part --------------
A non-text attachment was scrubbed...
Name: upsd.liebertPSP.3652.log.gz
Type: application/x-gzip
Size: 61489 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20120610/20b3032b/attachment-0001.bin>