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