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>
> 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?
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>
> 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..").Good to hear.> 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).Right, thanks for pointing out (if only all devices strictly adhered to the standard and reported it the right way...). While we tend to avoid touching the values we get from the device if not absolutely necessary, I think this can be done... it should not be overly difficult. Anyone on the list against it?> - 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.Seems reasonable to me. I'll have to look at our DDL and lists (I vaguely remember a lot of chit-chat about this kind of things in the heydays) for side effects, though. (Arno, where did you get those values from?) Hey list, thoughts on this?> 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).Sure (compressed), just tell us from what you started so that we can generate a diff. As for the diff format, we use git as VCS, so `git format-patch` is a natural candidate: https://git-scm.com/docs/git-format-patch Actually, for small patches even `git diff` will do. Otherwise, run `diff -u` on the files you modified against the original ones: http://man7.org/linux/man-pages/man1/diff.1.html Also, we have some related chapters in our developer guide: https://networkupstools.org/docs/developer-guide.chunked/ar01s03.html
> sorry for the delay, I forgot to put the automatic response (I was on holiday), here's a description of what we made and the drivers we used to start from:No problem for the delay... I fixed a few issues, and pushed your changes (amended) to this temporary branch: https://github.com/zykh/nut/tree/issue-441+legrand Let me know if I misunderstood anything...> - usbhid-ups --> we added legrand-hid subdriver to extend the support to our HID Devices (Keor SP and Keor PDU, following your dev guide)What are the exact models supported? I ask because we need to a) update the HCL and b) write (if possible/reasonable) a more precise comment alongside the USB_DEVICE() macro so that the VID:PID combo is propagated by our scripts with it. Also, is 'Keor PDU' just a commercial name, or it is indeed a power distribution unit? In case, we should signal that in 'device.type'. Now, just a few questions on the mapping: 1. Are the following items read-only? And do they change from time to time and need to be polled, or once retrieved they remain the same (i.e. they are static)? - input.transfer.low / UPS.Input.LowVoltageTransfer - input.transfer.high / UPS.Input.HighVoltageTransfer - input.transfer.low / UPS.PowerConverter.Output.LowVoltageTransfer - input.transfer.high / UPS.PowerConverter.Output.HighVoltageTransfer - battery.charge.warning / UPS.PowerSummary.WarningCapacityLimit - battery.charge.low / UPS.PowerSummary.RemainingCapacityLimit 2. Do the following ones return punctual data, or only the nominal value? If the latter, do they change, or they are static? - ups.realpower / UPS.Output.ConfigActivePower - ups.realpower / UPS.Flow.ConfigApparentPower 3. Are the following ones static? - input.voltage.nominal / UPS.Input.ConfigVoltage - input.voltage.nominal / UPS.Flow.ConfigVoltage - battery.voltage.nominal / UPS.PowerSummary.ConfigVoltage - battery.voltage.nominal / UPS.BatterySystem.Battery.ConfigVoltage 4. What's the reason for not using DEFAULT_OFFDELAY and DEFAULT_ONDELAY in the 'dfl' field of the load.off.delay and load.on.delay instant commands?> - metasys --> this driver should be replaced (if possible) with the new one we made called "Legrand_megawhad". This driver was for MetaSystem UPSs, but this company has been acquired by Legrand, so we prefer to replace the old driver with the new one, even because we solved some issue and added new models (Compatibility: Megaline and Whad / Whad HE Series)Name change: I don't think it will happen... I see your point, but I think that, at least for now, this will only annoy existing users (and, for reference, we still have drivers with 'mge' in their name, even though MGE Office Protection Systems has been part of Eaton since circa 2007, with, as far as I can remember, their products no longer branded as MGE). Maybe, we will reconsider this in future, if we rewrite the driver from scratch, or if we decide to rename all the drivers with a leading 'nutdrv_'... I extrapolated the (non-cosmetic) changes you made and applied them to the metasys driver, apart from the removal of the devices with an 'id code' < 14. Speaking of that, since you removed them: do they support the command you added (battery SOC, #8)? If not, we should make it optional. For our HCL: were those new devices you added also branded as Meta System?> - nutdrv_qx --> we added our VID:PID to Krauler subdriver (together with the patch you sent me last time)Here, too, what are the names of the supported devices?> I also attached the Megaline / Whad UPSs communication protocol as requested.Thanks, I added it to our protocol library. Just a question. The protocol only lists the devices with an 'id code' >= 11 and <= 28: what about the other ones? i.e.: - the ones already supported by the metasys driver: id < 11, - the other ones you added to the legrand_megawhad driver: 31, 32, 33.
[apparently the list didn't get the message, probably because it exceeds the 40kb threshold, so here it is in all its glory with my reply] On Mon, 3 Sep 2018 at 14:32, Gabriele TAORMINA <gabriele.taormina at legrand.com> wrote:> > Dear Daniele, > > > "I fixed a few issues, and pushed your changes (amended) to this > > temporary branch: https://github.com/zykh/nut/tree/issue-441+legrand > > Let me know if I misunderstood anything..." > > Thank you for the creation of the branch, I tried to submit some changes according to your email (I never used GitHub before, please can you check if I made it correctly?)Thanks for taking care of those issues (I added a quick review on GitHub). Now, scroll till the end of the mail... there's another question for you...> > > - usbhid-ups --> we added legrand-hid subdriver to extend the support to our HID Devices (Keor SP and Keor PDU, following your dev guide) > > > > What are the exact models supported? I ask because we need to a) > > update the HCL and b) write (if possible/reasonable) a more precise > > comment alongside the USB_DEVICE() macro so that the VID:PID combo is > > propagated by our scripts with it. > > Also, is 'Keor PDU' just a commercial name, or it is indeed a power > > distribution unit? In case, we should signal that in 'device.type'. > > > > Now, just a few questions on the mapping: > > 1. Are the following items read-only? > > And do they change from time to time and need to be polled, or once > > retrieved they remain the same (i.e. they are static)? > > - input.transfer.low / UPS.Input.LowVoltageTransfer > > - input.transfer.high / UPS.Input.HighVoltageTransfer > > - input.transfer.low / UPS.PowerConverter.Output.LowVoltageTransfer > > - input.transfer.high / UPS.PowerConverter.Output.HighVoltageTransfer > > - battery.charge.warning / UPS.PowerSummary.WarningCapacityLimit > > - battery.charge.low / UPS.PowerSummary.RemainingCapacityLimit > > 2. Do the following ones return punctual data, or only the nominal > > value? If the latter, do they change, or they are static? > > - ups.realpower / UPS.Output.ConfigActivePower > > - ups.realpower / UPS.Flow.ConfigApparentPower > > 3. Are the following ones static? > > - input.voltage.nominal / UPS.Input.ConfigVoltage > > - input.voltage.nominal / UPS.Flow.ConfigVoltage > > - battery.voltage.nominal / UPS.PowerSummary.ConfigVoltage > > - battery.voltage.nominal / UPS.BatterySystem.Battery.ConfigVoltage > > 4. What's the reason for not using DEFAULT_OFFDELAY and > > DEFAULT_ONDELAY in the 'dfl' field of the load.off.delay and > > load.on.delay instant commands? > > Keor PDU is a commercial name for a Rack UPS, in the USB_DEVICE() macro I tried to add a small description, I don't know if it's enough for you, what kind of comment would you like? > > Regarding nutdrv_qx the only VID:PID combo is for one family: "Legrand Daker DK+ 1kVA / 2kVA / 3kVA / 5kVA / 6kVA / 10kVA". This could be the description. > The items were Static, so I changed the file accordingly, i also added the DEFAULT_ONDELAY and DEFAULT_OFFDELAY. Probably i forgot it in a first time! > These are the changes related to questions Nr. 1,2,3,4 of your previous email. > Here's the link of the pull request: > https://github.com/zykh/nut/pull/1/commits/4fe226b820128018e5089408f87b76c3345ff5e2 > > Regarding the exact models supported i checked the driver.list.in and updated it with all the models: > https://github.com/zykh/nut/pull/3/commits/82dd085b4be23bb19d8477078ae9d3b8cc213130 > > > > - metasys --> this driver should be replaced (if possible) with the new one we made called "Legrand_megawhad". This driver was for MetaSystem UPSs, but this company has been acquired by Legrand, so we prefer to replace the old driver with the new one, even because we solved some issue and added new models (Compatibility: Megaline and Whad / Whad HE Series) > > > > Name change: I don't think it will happen... I see your point, but I > > think that, at least for now, this will only annoy existing users > > (and, for reference, we still have drivers with 'mge' in their name, > > even though MGE Office Protection Systems has been part of Eaton since > > circa 2007, with, as far as I can remember, their products no longer > > branded as MGE). > > Maybe, we will reconsider this in future, if we rewrite the driver > > from scratch, or if we decide to rename all the drivers with a leading > > 'nutdrv_'... > > > > I extrapolated the (non-cosmetic) changes you made and applied them to > > the metasys driver, apart from the removal of the devices with an 'id > > code' < 14. > > Speaking of that, since you removed them: do they support the command > > you added (battery SOC, #8)? If not, we should make it optional. > > Regarding the Battery SOC Data in Metasys driver, no, it's not supported from ID < 14. I mean that this UPS came out with the possibility to read SOC, but this function needs to be enabled with some commands sent through serial terminal. Furthermore, this UPS was produced ca. 15 Years ago, so we prefer to not include it in the driver.list. > Battery SOC with all the other models works perfectly. > > > For our HCL: were those new devices you added also branded as Meta System? > > Whad / Megaline / Whad CAB / Whad HE are branded Legrand > DHEA is branded MetaSystem > > > > - nutdrv_qx --> we added our VID:PID to Krauler subdriver (together with the patch you sent me last time) > > Here, too, what are the names of the supported devices? > > "Legrand Daker DK+ 1kVA / 2kVA / 3kVA / 5kVA / 6kVA / 10kVA" > > > > I also attached the Megaline / Whad UPSs communication protocol as requested. > > Thanks, I added it to our protocol library. > > > > Just a question. > > The protocol only lists the devices with an 'id code' >= 11 and <= 28: > > what about the other ones? i.e.: > > - the ones already supported by the metasys driver: id < 11, > > - the other ones you added to the legrand_megawhad driver: 31, 32, 33. > > Regarding the ones already supported (ID < 11), they are obsolete (as written produced more than 15 years ago).Do you happen to have a document describing the protocol used by them? Even an old one will do.> The ones i added (31, 32, 33) are the HE (High Efficiency) Models, we have to update the protocol we sent you with these new models. > > For any question i'm here, thanks again for all your 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 > Website: www.ups.legrand.com > Website: www.legrand.com