Nut upsuser - Oct 2014 - Return on experience with an Emerson/Liebert GXT3

Hi

On 10/02/2014 02:39 PM, Charles Lepple wrote:> On Oct 1, 2014, at 9:03 PM,
paul.chavent at fnac.net wrote:
> 
>>> It should run as user "nut" in Debian. You may want to
reinstall the nut-server package, and check the post-inst error messages to make
sure that the "nut" user is created, and that it is in the
"nut" group as well.
>>
>> The user nut and the group nut have been created..
> 
> Ah, right, because you are using the Debian upsdrvctl with a hand-compiled
driver. I would recommend copying the whole Debian ./configure line, including
the part that sets the default user and group to "nut".
>>
>>> Not sure that is where the "user" declaration is being
parsed. upsdrvctl just passes arguments to the drivers via the command line
(including "-u", although that is not read from the configuration
file, but from upsdrvctl's command line).
>>
>>
https://github.com/networkupstools/nut/blob/master/drivers/upsdrvctl.c#L60
>>
>> I'm quite sure that it is the place where the config file is
parsed...
> 
> What I should have said is that upsdrvctl is not where the "user =
" is being interpreted (although you are correct, it is parsed and
ignored). I was thinking of this line in the driver core:
> 
> https://github.com/networkupstools/nut/blob/master/drivers/main.c#L295
> 
>> And the init script of the debian package don't explicitly append
"-u nut" in wheezy. See the attached patch in my first message.
> 
> Since we don't ship that init file in the generic NUT source package
anymore, that will need to be discussed with the Debian maintainers - probably
at http://bugs.debian.org
> 
My bad. The user global directive is parsed by the driver, not by the upsdrvctl.
And the debian init script doesn't need any changes, my settings had been
messed up. All is working out of the box now.
Hopefully, you know the code better than me :)
>>> There are some fixes that were added in 2.6.4 to try and work
around incorrect exponents in the voltages. You can try starting the usbhid-ups
driver directly, adding "-DDD" to see if any messages are logged about
"assuming correction factor =". It could be that we did not cover all
the different ways those values could be wrong.
I've tried both belkin-hid and liebert-hid drivers. You can finds logs of
the belkin-hid in attachment. I don't see any "assuming correction
factor =" messages.

However. Could you give me some more hints please ?

(1) appart the liebert_line_voltage and liebert_config_voltage functions, i
don't see any differences in the belkin-hid and liebert-hid drivers.
Why not move all liebert related functions in the liebert-hid driver ?

(2) i don't understand how the driver selection is done ? if i just add the
vendorid/productid to the liebert_usb_device_table, the lookup seems to stop in
the belkin driver (perhaps because belkin_claim got "possibly
supported" and that the "productid" value is present ?).
How do you suggest to implement the addition of this device ? 
(for my tests, i commented the belkin lookup entry to force the usage of the
liebert one).

(3) in the hid report, we have several items with the same name (see attached
lsusb dump).
How it is handled by the lookup table ? Is there any indexing possible ?

(4) would it be usefull to add missing items to the driver's hid to nu
lookup table (even in the the unmapped part) ? Do you recommend me to work on
the liebert or on the belkin file ?

Thanks for your help.

Regards.



-------------- next part --------------
A non-text attachment was scrubbed...
Name: usbhid-ups-belkin-driver.log
Type: text/x-log
Size: 30906 bytes
Desc: not available
URL:
<http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20141003/92c08dfd/attachment-0002.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lsusb.log
Type: text/x-log
Size: 14129 bytes
Desc: not available
URL:
<http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20141003/92c08dfd/attachment-0003.bin>

On Oct 3, 2014, at 7:50 AM, paul.chavent at fnac.net wrote:
> Hi
> 
> On 10/02/2014 02:39 PM, Charles Lepple wrote:> On Oct 1, 2014, at 9:03
PM, paul.chavent at fnac.net wrote:
...
>>>> There are some fixes that were added in 2.6.4 to try and work
around incorrect exponents in the voltages. You can try starting the usbhid-ups
driver directly, adding "-DDD" to see if any messages are logged about
"assuming correction factor =". It could be that we did not cover all
the different ways those values could be wrong.
> 
> I've tried both belkin-hid and liebert-hid drivers. You can finds logs
of the belkin-hid in attachment. I don't see any "assuming correction
factor =" messages.
This is what I was referring to (from the belkin-hid log):

   1.325782	Report[buf]: (5 bytes) => 05 53 00 48 00
   1.325799	Path: UPS.PowerSummary.ConfigVoltage, Type: Feature, ReportID: 0x05,
Offset: 16, Size: 16, Value: 0
   1.325814	ConfigVoltage = 0 -> assuming correction factor = 1e+08

You may need to bump the debug level to 5 to see the full exponent processing
(cf get_unit_expo() in libhid.c). Please gzip the log - it will be big.
> However. Could you give me some more hints please ?
> 
> (1) appart the liebert_line_voltage and liebert_config_voltage functions, i
don't see any differences in the belkin-hid and liebert-hid drivers.
> Why not move all liebert related functions in the liebert-hid driver ?
I would prefer not to move things around too much, unless we can get people to
test the other models. I realize it is annoying that the subdriver names do not
match the brands, but the idea is that the matching happens automatically.
> (2) i don't understand how the driver selection is done ? if i just add
the vendorid/productid to the liebert_usb_device_table, the lookup seems to stop
in the belkin driver (perhaps because belkin_claim got "possibly
supported" and that the "productid" value is present ?).
> How do you suggest to implement the addition of this device ? 
> (for my tests, i commented the belkin lookup entry to force the usage of
the liebert one).
Right, in usbhid-ups.c, the liebert_subdriver entry is after the
belkin_subdriver.
> (3) in the hid report, we have several items with the same name (see
attached lsusb dump).
> How it is handled by the lookup table ? Is there any indexing possible ?
I will have more time to look at this later, but at a quick glance, I did not
see what you were referring to (the lsusb dump, while comprehensive, is hard to
parse). Bear in mind that many vendors duplicate Input and Feature HID elements.
> (4) would it be usefull to add missing items to the driver's hid to nu
lookup table (even in the the unmapped part) ?
Sure, although the unmapped entries are just for debugging - we will want to
eventually rename them to official NUT names, or comment them out again before
checking the driver in to version control.
> Do you recommend me to work on the liebert or on the belkin file ?
Probably belkin-hid.
> Thanks for your help.
Thanks for testing!

-- 
Charles Lepple
clepple at gmail