> 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. _______________________________________________ Nut-upsdev mailing list [email protected] https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev
