<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>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.</p>
    <p>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.</p>
    <p>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.</p>
    <p>But instead of that NUT elected to write a shim that spawns
      apcuspd.  <br>
    </p>
    <p>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.</p>
    <p>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.</p>
    <p>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.</p>
    <p>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.</p>
    <p>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.</p>
    <p>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.<br>
    </p>
    <p>Ted<br>
    </p>
    On 1/3/2023 9:13 AM, Jim Klimov via Nut-upsdev wrote:<br>
    <blockquote type="cite"
cite="mid:CAJYg8v+ebiJYjS2_QAmx34+_JmypPCA1-q=z9qBRm6EnjEafeA@mail.gmail.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <div dir="ltr">
        <div>UPDATE: As commented in <a
href="https://github.com/networkupstools/nut/issues/139#issuecomment-1369527363"
            moz-do-not-send="true" class="moz-txt-link-freetext">https://github.com/networkupstools/nut/issues/139#issuecomment-1369527363</a>
          I've stashed a one-off copy of their history at <a
            href="https://github.com/networkupstools/apcupsd"
            moz-do-not-send="true" class="moz-txt-link-freetext">https://github.com/networkupstools/apcupsd</a>
          using GitHub importer for SVN sources to grab the current
          state of <a href="https://svn.code.sf.net/p/apcupsd/svn"
            rel="nofollow" moz-do-not-send="true"
            class="moz-txt-link-freetext">https://svn.code.sf.net/p/apcupsd/svn</a>
          just in case (so it does not evaporate as abandonware).</div>
        <div><br>
        </div>
        <div>Further browsing revealed that:</div>
        <div><br>
          * Last release was 3.14.14 (2016-05-31) <a
href="https://sourceforge.net/projects/apcupsd/files/apcupsd%20-%20Stable/3.14.14/"
            moz-do-not-send="true" class="moz-txt-link-freetext">https://sourceforge.net/projects/apcupsd/files/apcupsd%20-%20Stable/3.14.14/</a>
          with a couple more commits tracked at <a
href="https://sourceforge.net/p/apcupsd/svn/HEAD/tree/branches/Branch-3_14/"
            moz-do-not-send="true" class="moz-txt-link-freetext">https://sourceforge.net/p/apcupsd/svn/HEAD/tree/branches/Branch-3_14/</a>
          (up till 2017-05-06)<br>
          * Last announced release was 3.14.13 (2015-02-03) per <a
            href="https://sourceforge.net/p/apcupsd/mailman/apcupsd-announce/"
            moz-do-not-send="true" class="moz-txt-link-freetext">https://sourceforge.net/p/apcupsd/mailman/apcupsd-announce/</a><br>
          * The mailing list community is quite active however, archive
          maintained at <a
            href="https://sourceforge.net/p/apcupsd/mailman/apcupsd-users/"
            moz-do-not-send="true" class="moz-txt-link-freetext">https://sourceforge.net/p/apcupsd/mailman/apcupsd-users/</a></div>
        <div><br>
        </div>
        <div>More and more I'm thinking this is less of a poaching and
          more of a rescue mission...</div>
        <div>Would anyone please get your hacker hats on and mercifully
          save that protocol-support code in a maintained project? :)<br>
        </div>
        <div><br>
        </div>
        <div>Jim</div>
        <div><br>
        </div>
      </div>
      <br>
      <div class="gmail_quote">
        <div dir="ltr" class="gmail_attr">On Tue, Dec 27, 2022 at 6:47
          PM Jim Klimov <<a href="mailto:jimklimov@gmail.com"
            moz-do-not-send="true" class="moz-txt-link-freetext">jimklimov@gmail.com</a>>
          wrote:<br>
        </div>
        <blockquote class="gmail_quote" style="margin:0px 0px 0px
          0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
          <div dir="auto">Cheers all,
            <div dir="auto"><br>
            </div>
            <div dir="auto">  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).</div>
            <div dir="auto"><br>
            </div>
            <div dir="auto">  Per <a href="http://www.apcupsd.org/"
                target="_blank" moz-do-not-send="true"
                class="moz-txt-link-freetext">http://www.apcupsd.org/</a>
              and <a
href="https://sourceforge.net/p/apcupsd/svn/HEAD/tree/branches/Branch-3_14/"
                target="_blank" moz-do-not-send="true"
                class="moz-txt-link-freetext">https://sourceforge.net/p/apcupsd/svn/HEAD/tree/branches/Branch-3_14/</a>
              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?</div>
            <div dir="auto"><br>
            </div>
            <div dir="auto">  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...</div>
            <div dir="auto"><br>
            </div>
            <div dir="auto">WDYT?</div>
            <div dir="auto">Jim Klimov</div>
            <div dir="auto"><br>
            </div>
          </div>
        </blockquote>
      </div>
      <br>
      <fieldset class="moz-mime-attachment-header"></fieldset>
      <pre class="moz-quote-pre" wrap="">_______________________________________________
Nut-upsdev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Nut-upsdev@alioth-lists.debian.net">Nut-upsdev@alioth-lists.debian.net</a>
<a class="moz-txt-link-freetext" href="https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev">https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev</a>
</pre>
    </blockquote>
  </body>
</html>