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: [email protected]<mailto:[email protected]>
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 <[email protected]>
Inviato: giovedì 26 luglio 2018 01:21
A: Gabriele TAORMINA
Cc: [email protected]; 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.
_______________________________________________
Nut-upsdev mailing list
[email protected]
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev
