[Nut-upsdev] Adding drivers to NUT?

Gabriele TAORMINA gabriele.taormina at legrand.com
Tue Jul 31 14:44:18 BST 2018


Dear Daniele,

I have some news regarding the Driver: I applied the patch you sent me (https://github.com/zykh/nut/tree/issue-441) and it works correctly (obviously in Level 5 of Debug I see "missing CR...etc..").

As for now there are 2 modification I'd like to suggest you:


- For Online Type UPSs the Megatec protocol describes that the battery voltage is provided in the form of V per Cell, not V per block, but the driver doesn't care because I see 2.21V instead of 36V in UPSC (Battery.voltage). I think that this should be corrected so the customer can see the string voltage and not the single Cell voltage (Megatec 0.06).


- About battery low and high guesstimation the formula uses these values:

batt.volt.low = 104 * batt.volt.nom / 120   (for a 12V VRLA --> 10.4V batt.volt.low)
batt.volt.high = 130 * batt.volt.nom / 120   (for a 12V VRLA --> 13V batt.volt.high).
In my opinion these values are not correct (a 12V lead acid battery can be charged up to 13.8V while discharged to 9.6V)

Instead I would suggest:
batt.volt.low = 100 * batt.volt.nom / 120   (for a 12V VRLA --> 10V batt.volt.low)
batt.volt.high = 135 * batt.volt.nom / 120   (for a 12V VRLA --> 13.5V batt.volt.high)
with this correction we have also some "Safe Margin", I mean that more or less all the UPS I tested will charge and discharge the batteries at those values.
I would like also to ask you if for this first time we can send you the sources instead of the Diff patch and for the future we will study how to send it in the format required (if you have any link explaining the diff, etc. please send it, it will be useful for me).

The question from Stefano Pongiluppi (my colleague) has been solved because we'll not use Blazer anymore.
Thanks again for the support!



Best Regards,

Gabriele Taormina

UPS Strategic Business Unit

Field Application Engineer

Phone:     +39 0522/207046

Fax:           +39 0522/207005

Address:  Via Rodano 1 - Reggio Emilia - 42124 - Italy

Email:       gabriele.taormina at legrand.com<mailto:gabriele.taormina at legrand.com>

<mailto:gabriele.taormina at legrand.com>Website:  www.ups.legrand.com<http://www.ups.legrand.com/>

Website:  www.legrand.com<http://www.legrand.com/>

[1506322600142_legrand-vector-logo.png]



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

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

OK, if, as I am inclined to think, the cause is simply the lack of the
closing CR, once the GitHub issue I mentioned before is fixed, these
problems should disappear in nutdrv_qx (while we could easily apply
the same set of changes to blazer_usb, or change the expected length
to not consider the closing CR, I don't want to touch it right now, as
it already works with USB devices that don't terminate the Q1 reply
with a CR and these other things are not critical, and I want to keep
an easy way for users to get back to the current working behaviour,
just in case...).

Please, try nutdrv_qx from this branch:
https://github.com/zykh/nut/tree/issue-441
A log of the driver started with a debug level of 5 would be useful.

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

Are you sure blazer_usb complains in debug mode even with the Q1
reply? What version are you using? Because, unless the USB read fails,
it shouldn't, if the reply only lacks the closing CR...
This should only be a problem with nutdrv_qx (and it should now be
fixed in the branch I just linked).

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

Can you elaborate a bit more on this one?
Do you have any suggestion on how to improve our calculations?

________________________________

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/20180731/4c81fe3f/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Outlook-1506322600.png
Type: image/png
Size: 4655 bytes
Desc: Outlook-1506322600.png
URL: <http://alioth-lists.debian.net/pipermail/nut-upsdev/attachments/20180731/4c81fe3f/attachment-0001.png>


More information about the Nut-upsdev mailing list