[Project] CLA processing is laggy (want to upstream support for Modbus over USB)

[jimklimov]

Hello, got a question regarding the project rituals more than libmodbus itself at the moment: a NUT contributor implemented a patch for USB RTU for libmodbus, tested with a number of UPS devices. There is an intention to upstream this change (to avoid users having to custom-build libmodbus to get the connectivity with their UPSes), the author says he posted the CLA form some weeks ago... and is still waiting to be green-lit to propose pull requests. Can this be somehow faster? :)

References:

• apc_modbus: Support for APC Modbus protocol networkupstools/nut#2063
• https://github.com/EchterAgo/libmodbus/commits/rtu_usb

[jimklimov]

Gentle bump :)

[karlp]

What's the actual PR that was filed here? I can't see anything obvious in issues or PRs, open or closed....

[stephane]

I've just uploaded all the signed CLA to the bot.

[jimklimov]

Sorry @karlp the quick reply fell through the cracks; and thanks @stephane - this issue bubbled up in my mailbox again :)

As far as I know, there was no PR to the project posted yet regarding the rtu_usb feature, as the original author's (@EchterAgo) understanding was that a CLA must be in place before proposing code to this repository. BTW I do not see that nickname in 1c1ccc3 although per networkupstools/nut#2063 (comment) and networkupstools/nut#2063 (comment) the request was somehow posted :\

All that said, by now the code in the branch can be deemed fairly well tested in the field, several NUT users discussed building with it and eventually reported success, iterated on NUT-side improvements, etc. A slightly newer replica for NUT users who want to use their APC UPSes per https://github.com/networkupstools/nut/wiki/APC-UPS-with-Modbus-protocol instructions is maintained at https://github.com/networkupstools/libmodbus/tree/rtu_usb (same as the @EchterAgo's code, plus a README update).

[jimklimov]

On a side note, per networkupstools/nut#1671 and #659 here, there were other developments for NUT drivers that needed more libmodbus capabilities than currently provided by the project's main codebase.

If this recent activity is a sign of rekindled interest to the library from its maintainers, it would be great to also have "modbus-ASCII" and "read device identification" points solved in the core and not in a mish-mash of forks and cherry-picks :)