[Nut-upsuser] Bug#671444: LiebertPSP

[Arnaud Quette]

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