<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <div class="moz-cite-prefix">Jim,</div>
    <div class="moz-cite-prefix"><br>
    </div>
    <div class="moz-cite-prefix">generic_gpio is fine for me. This opens
      some thinking about some common code parts in any kind of NUT
      driver: when we talk about status</div>
    <div class="moz-cite-prefix">handling at some point we have to have
      determination of how to transform protocol flow into true/false
      values for states and setting of states is somewhat</div>
    <div class="moz-cite-prefix">common. Actually we need to talk about
      true only. But assume this out of scope of discussion.</div>
    <div class="moz-cite-prefix"><br>
    </div>
    <div class="moz-cite-prefix">Very formal naming might be easy from
      development process set-up, but for end user name with known
      wording would be better.</div>
    <div class="moz-cite-prefix"><br>
    </div>
    <div class="moz-cite-prefix">Modris</div>
    <div class="moz-cite-prefix"><br>
    </div>
    <div class="moz-cite-prefix">On 2/22/23 18:08, Jim Klimov wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAJYg8vJEwx9bh46sJmquDn4-okPq2iXNZL-MXs2eRQR2+ZPkwQ@mail.gmail.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <div dir="ltr">
        <div>Great, thanks! <br>
        </div>
        <div><br>
        </div>
        <div>Also just for context, this sounded reminiscent of one of
          the first NUT drivers, `genericups` (for simple
          contact-closure support, with IIRC serial-port connections
          rather than GPIO).</div>
        <div><br>
        </div>
        <div>Nearby there's also a `generic_modbus" name. Wondering if
          the new driver should be (similar to) `generic_gpio`.</div>
        <div><br>
        </div>
        <div><a class="gmail_plusreply" id="plusReplyChip-0"
            moz-do-not-send="true">@Community verdict:</a> Then there
          was also an effort some years ago to name drivers with a
          `nutdrv-*` prefix... WDYT?</div>
        <div><br>
        </div>
        <div>As usual, naming is among the hardest problems in IT ;)</div>
        <div><br>
        </div>
        <div>Jim<br>
        </div>
      </div>
      <br>
      <div class="gmail_quote">
        <div dir="ltr" class="gmail_attr">On Wed, Feb 22, 2023 at 4:34
          PM MODRIS BÄ’RZONIS <<a href="mailto:modrisb@apollo.lv"
            moz-do-not-send="true" class="moz-txt-link-freetext">modrisb@apollo.lv</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>
            <div>Jim,</div>
            <div><br>
            </div>
            <div>no, there are no changes in adelsystem.<br>
            </div>
            <div><br>
            </div>
            <div>Driver's implementation is based on libgpiod, assume
              this would be natural to call driver gpio, i2c uses
              different library to communicate. Yes, any UPS with open
              collector pins should work, configuration rules will tune
              behavior needed for NUT.</div>
            <div><br>
            </div>
            <div>Just created PR <a
                href="https://github.com/networkupstools/nut/pull/1855"
                target="_blank" moz-do-not-send="true"
                class="moz-txt-link-freetext">https://github.com/networkupstools/nut/pull/1855</a>
              .</div>
            <div><br>
            </div>
            <div>Modris</div>
            <div><br>
            </div>
            <div>On 2/21/23 22:33, Jim Klimov wrote:<br>
            </div>
            <blockquote type="cite">
              <div dir="auto">Thanks, looks promising.
                <div dir="auto"><br>
                </div>
                <div dir="auto">Were there any changes to adelsystem
                  sources? (Not on PC now to check quickly).</div>
                <div dir="auto"><br>
                </div>
                <div dir="auto">Also `gpio` naming is too generic (might
                  mean helpers to talk to gpio pins, e.g. some code
                  shareable by i2c or something of the sort). Does this
                  handle GPIO UPSes in general (e.g. helped by `rules`
                  line arg), or more tightly aimed at certain models
                  like yours?</div>
                <div dir="auto"><br>
                </div>
                <div dir="auto">Style-wise, there's indeed a fair amount
                  of clean-up desireable. Can you post a PR with this
                  (or improved) codebase, at least to claim a commit in
                  git history? :) A man page would be nice.</div>
                <div dir="auto"><br>
                </div>
                <div dir="auto">Jim</div>
                <div dir="auto"><br>
                </div>
              </div>
              <br>
              <div class="gmail_quote">
                <div dir="ltr" class="gmail_attr">On Tue, Feb 21, 2023,
                  20:49 MODRIS BÄ’RZONIS <<a
                    href="mailto:modrisb@apollo.lv" target="_blank"
                    moz-do-not-send="true" class="moz-txt-link-freetext">modrisb@apollo.lv</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">Hi!<br>
                  <br>
                  I have CyberPower CyberShield CSN27U12V UPS. This
                  device don't have <br>
                  usual for UPS interface, just open collector pins. I
                  connected these <br>
                  pins to GPIO interface on Orange Pi Zero and wrote NUT
                  driver for this <br>
                  case. Any interest from NUT community to add this
                  driver to regular <br>
                  build tree?<br>
                  <br>
                  See driver code in attachment. Code is fully
                  functional, needs cleanup <br>
                  to match coding guidelines and needs more tests for
                  rules processing <br>
                  part. Driver reads GPIO line statuses and transforms
                  them to NUT <br>
                  statuses using short rules description parameter in
                  the form of status <br>
                  strings and logical operations on line values.<br>
                  <br>
                  Modris<br>
                  <br>
                  _______________________________________________<br>
                  Nut-upsdev mailing list<br>
                  <a href="mailto:Nut-upsdev@alioth-lists.debian.net"
                    rel="noreferrer" target="_blank"
                    moz-do-not-send="true" class="moz-txt-link-freetext">Nut-upsdev@alioth-lists.debian.net</a><br>
                  <a
href="https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev"
                    rel="noreferrer noreferrer" target="_blank"
                    moz-do-not-send="true" class="moz-txt-link-freetext">https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev</a><br>
                </blockquote>
              </div>
            </blockquote>
            <p><br>
            </p>
          </div>
        </blockquote>
      </div>
    </blockquote>
    <p><br>
    </p>
  </body>
</html>