[Nut-upsdev] Adding drivers to NUT?

[Daniele Pezzini]

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