[Nut-upsuser] Return on experience with an Emerson/Liebert GXT3

Fri Oct 3 11:50:08 UTC 2014

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>