[Nut-upsdev] Adding drivers to NUT?

[Stefano PONGILUPPI]

Dear Daniele,


nice to meet you, I'm a collegue of Gabriele.


The problem with "blazer_usb" driver ("blazer_ser" works correctly) is related to the following commands:

- "F" and "I": when the KRAULER subdriver check these UPS answers it uses wrong constants to check the lenght of the received packets, so these commands are considered as "not available" by NUT. In particular, without the availability of the "F" command, is not possible for NUT to calculate the battery capacity level. In my opinion this is a problem of the driver, because our UPSs respect the communication protocol document from Megatec and also because the blazer_ser works fine. We have tested different UPSs models but the problem is the same.

- "Q1": in this case the problem is only relative to the debug mode ("short answer"); in normal mode it works correctly.

- "battery.voltage high/low: the values used in the formula are not correct, indipendently by the UPS used.


In other words, we are in a difficult situation: we can not use the Krauler subdriver because it doesn't work correctly, and we can not create another subdriver inside blazer_usb because we are using the same VID/PID used by Krauler and our UPSs don't report the manufacturer/product.

This is the reason because we have asked about the possibility to create a new driver, very similar to the Krauler one but with the right modifications, otherwise we don't know how to integrate some our UPSs, based on blazer_usb, in your software.



Best regards


Stefano PONGILUPPI
UPS Marketing Manager - Software Tools
Phone: +39 0522207039
Mobile: +39 3666290924
FAX: +39 0522207005
Address: Via Rodano, 1 - Reggio Emilia - 42124 - IT
e-mail: stefano.pongiluppi at legrand.com<mailto:stefano.pongiluppi at legrand.com>
WebSite: ups.legrand.com<http://www.ups.legrand.com>
WebSite: <http://www.legrand.com> www.legrand.com<http://www.legrand.com>
[1499681553761_PastedImage]
Please consider your environmental responsibility before printing this email



________________________________
Da: Daniele Pezzini <hyouko at gmail.com>
Inviato: giovedì 26 luglio 2018 01:21
A: Gabriele TAORMINA
Cc: nut-upsdev at alioth-lists.debian.net; Thierry DESTRUEL; Stefano PONGILUPPI
Oggetto: Re: [Nut-upsdev] Adding drivers to NUT?

> some of our devices uses Voltronic Q1 protocol and we tried the Krauler
> Subdriver (it was the one with the right "commands", Q1, F, etc.), but the
> issues were 2:
> - first: the Krauler Subdriver expects a different number of bytes in answer
> because in debug i see "Short Reply" (if i send Q1 to the UPS it will answer
> with 47 Bytes, CR terminated), from what i understand there is something
> wrong with the last byte that somewhere is not counted (because if i use a
> serial terminal and send Q1 the UPS answer correctly with the number of
> bytes required)

We've already seen devices that don't terminate their replies with a
CR on USB and, if this is the same issue, it's already on our radar:
https://github.com/networkupstools/nut/issues/441
I'll try to find some time to fix it by the end of the week: I'll
update you when the fix is ready, so that you can test it.

> - second: the battery voltage low and high (estimated) were not acceptable
> for our UPSs because the % level will never reach the 100% and the voltage
> estimation was wrong.

Well, we tend to recommend users not to rely too much on calculated
values (i.e. the ones not directly reported by the device itself).

That said, users can always set their own values for
'battery.voltage.{high,low}' and fine-tune calculations.
Plus, we can always add a note here or there and recommend using
certain values to have a slightly less inaccurate estimate for a given
device.
See:
- https://networkupstools.org/docs/man/nutdrv_qx.html#_battery_charge
- the various 'default.battery.*' and 'override.battery.*' items,
'runtimecal', 'chargetime' and 'idleload', here:
https://networkupstools.org/docs/man/nutdrv_qx.html#_extra_arguments

If you still can't find acceptable values, and you have any idea on
how to improve our calculations, we're open to contributions.

> - third: we have products with VID and PID: FFFF 0000, this is a problem
> because the combination is occuped by Krauler and in this way it will match
> each time with the wrong subdriver (krauler instead of our).

So the issues were 3, actually...
Now, with the aforementioned fix in place, I don't think we need
another USB subdriver, but, were it absolutely necessary, we could
switch on the iManufacturer/iProduct strings, if your devices report
them.

________________________________

Ce message, ainsi que tous les fichiers joints à ce message, peuvent contenir des informations sensibles et/ ou confidentielles ne devant pas être divulguées. Si vous n'êtes pas le destinataire de ce message (ou que vous recevez ce message par erreur), nous vous remercions de le notifier immédiatement à son expéditeur, et de détruire ce message. Toute copie, divulgation, modification, utilisation ou diffusion, non autorisée, directe ou indirecte, de tout ou partie de ce message, est strictement interdite.


This e-mail, and any document attached hereby, may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized, direct or indirect, copying, disclosure, distribution or other use of the material or parts thereof is strictly forbidden.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/nut-upsdev/attachments/20180726/03548838/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Outlook-1499681553.png
Type: image/png
Size: 4654 bytes
Desc: Outlook-1499681553.png
URL: <http://alioth-lists.debian.net/pipermail/nut-upsdev/attachments/20180726/03548838/attachment-0001.png>