Nut upsuser - Jan 2023 - Calling volunteers for Modbus driver refactoring (and asking for your thoughts on this)

Hello all,

  During holiday revision of issues (hoping to tie up loose ends and get to
NUT v2.8.1 soonish), an old https://github.com/networkupstools/nut/issues/50
ticket came to my attention - that some years ago "we" (as NUT
community)
wanted to create an unified driver for devices with a Modbus connection --
similar to `nutdrv_qx` doing everything about Megatec Qx protocol family
(USB/Serial), `snmp-ups` or `usbhid-ups` with subdrivers for vendor nuances
over a common playground...

  In the end what happened over the past years was that several independent
drivers were made or proposed from scratch (some efforts listed at
https://github.com/networkupstools/nut/issues/50#issuecomment-1369803950
comment) for modbus-capable devices - great thanks to everyone involved!

  Now it may be beneficial to get back to the original plan, to maintain
just one copy of the common codebase and redefine the recently contributed
drivers as subdrivers to that single umbrella -- but this needs volunteers
with developer chops and the devices to refactor against.

  One more question is whether it is at all reasonable and possible? I
gather there are Modbus protocol variants over Serial, USB and TCP
connections at least, with binary and ascii dialects (latter dysfunctional
in existing libmodbus releases, but still). Is there actually sufficient
overlap of existing drivers that conversion to a single binary with
extensible subdrivers would be beneficial and would deduplicate something,
or are they better off independent?

  Another question is whether someone would undertake an extension to
`nut-scanner` to detect devices that NUT modbus drivers can support (given
the plethora of Modbus transports)?

WDYT?
Jim Klimov
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://alioth-lists.debian.net/pipermail/nut-upsuser/attachments/20230103/8d127a12/attachment.htm>