[Nut-upsdev] Can we just import apcupsd code?

Ted Mittelstaedt tedm at mittelstaedt.us
Wed Jan 4 22:02:26 GMT 2023


Why does it need to be saved?  It compiled just fine on current OS.  The 
apcupsd for windows code is not 64 bit.  But it is 64 bit for all other 
platforms.  There are at least 2 forks of it one in brazil and one a guy 
did for 100% windows build instead of a cross-compile from linux to windows.

NUT has had access to the source for the modbus code in apcupsd for 6 
years now and could have used it to write a nut-specific driver for apc 
upses.

There is also someone who reverse-engineered the native communications 
microlink protocol for apc upses, which could have been used to write a 
nut driver for apcupses that don't have modbus firmware.

But instead of that NUT elected to write a shim that spawns apcuspd.

The biggest issue right now with APCupses is that supposedly at one time 
the modbus code worked over USB but recently APC made a change that 
allegedly broke that.

But that is ridiculously difficult to trace down because all SMT model 
APC upses that support modbus come with serial ports as well as USB and 
most people running modbus with them use a USB-to-serial port dongle if 
they run into this so there's a lack of good bug reporting on this.

The cheap APC upses are USB output only and don't support modbus but do 
support UPS-HID over USB and apcupsd works with that - the majority of 
APC users buying cheap UPSes on the apcupsd mailing list ignore the 
recommendations to get higher quality UPSes and buy the cheap APC 
garbage and just get UPS-HID on a USB cable.

I have commit rights for the apcupsd sourceforge repository but I don't 
have control of apcupsd.com /apcupsd.org domains, the prior maintainer 
is still paying for those and has not responded to my queries on that.  
Because of that I can't modify the website for apcupsd.com and that is 
where all users go.

I don't see the point in releasing a new version for the sake of 
upreving the version number and since the website wouldn't be updated 
anyway with new download links most users would just continue 
downloading the 14.14 version.

If you really want to support APC upses you would be far wiser to take 
the reverse-engineered microlink code and write a nut driver for that.

Ted

On 1/3/2023 9:13 AM, Jim Klimov via Nut-upsdev wrote:
> UPDATE: As commented in 
> https://github.com/networkupstools/nut/issues/139#issuecomment-1369527363 
> I've stashed a one-off copy of their history at 
> https://github.com/networkupstools/apcupsd using GitHub importer for 
> SVN sources to grab the current state of 
> https://svn.code.sf.net/p/apcupsd/svn just in case (so it does not 
> evaporate as abandonware).
>
> Further browsing revealed that:
>
> * Last release was 3.14.14 (2016-05-31) 
> https://sourceforge.net/projects/apcupsd/files/apcupsd%20-%20Stable/3.14.14/ 
> with a couple more commits tracked at 
> https://sourceforge.net/p/apcupsd/svn/HEAD/tree/branches/Branch-3_14/ 
> (up till 2017-05-06)
> * Last announced release was 3.14.13 (2015-02-03) per 
> https://sourceforge.net/p/apcupsd/mailman/apcupsd-announce/
> * The mailing list community is quite active however, archive 
> maintained at https://sourceforge.net/p/apcupsd/mailman/apcupsd-users/
>
> More and more I'm thinking this is less of a poaching and more of a 
> rescue mission...
> Would anyone please get your hacker hats on and mercifully save that 
> protocol-support code in a maintained project? :)
>
> Jim
>
>
> On Tue, Dec 27, 2022 at 6:47 PM Jim Klimov <jimklimov at gmail.com> wrote:
>
>     Cheers all,
>
>       Every now and then there are questions about how NUT drivers for
>     APC devices are behind apcupsd, especially for modbus where most
>     data is served in the past decade (compared to USB HID on same
>     media, at least).
>
>       Per http://www.apcupsd.org/ and
>     https://sourceforge.net/p/apcupsd/svn/HEAD/tree/branches/Branch-3_14/
>     latest release was 2016 and latest commits overall in 2017, and it
>     is also GPLv2 - maybe it would be right to port their logic as a
>     NUT driver proper?
>
>       We have had several modbus drivers added by community members in
>     the past year or two, so there is precedent and first lessons
>     learned for the general integration...
>
>     WDYT?
>     Jim Klimov
>
>
> _______________________________________________
> Nut-upsdev mailing list
> Nut-upsdev at alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/nut-upsdev/attachments/20230104/76f0de9a/attachment.htm>


More information about the Nut-upsdev mailing list