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

[Jim Klimov]

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

I think I wrote something to that effect in the earlier posts, so nice to
hear someone else feels that way - more so, a member of that project! :)

The repo copy saved in NUT organization was more about ensuring that code
is available for wannabe porters who would make a real NUT driver covering
more APC devices (likely not myself - short on time, hardware and skill for
that).

Thanks,
Jim



On Wed, Jan 4, 2023, 23:23 Ted Mittelstaedt via Nut-upsdev <
nut-upsdev at alioth-lists.debian.net> wrote:

> 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 listNut-upsdev at alioth-lists.debian.nethttps://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev
>
> _______________________________________________
> 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/1d02f14e/attachment-0001.htm>