[Nut-upsdev] Adding drivers to NUT?

[Daniele Pezzini]

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