[Nut-upsuser] TrippLite AVR550U start on power

[Steven Bixby]

Hello, all...  a followup to my question.   After lots of poking, prodding,
research, teeth gnashing and hair tearing, I have a working solution.

The gist:
I set up nut pretty much by the documentation, then changed it to avoid the
native shutdown sequence and use a custom one that apparently works fine
with the AVR550U.

Here are the details:


   - nut.conf
      - MODE=standalone
   - ups.conf
      - maxretry = 3
      [ups]
              driver=usbhid-ups
              port = auto
              desc = "TrippLite AVR550U"
      - upsd.conf
      - LISTEN 127.0.0.1 3493
      - upsd.users
      - [upsmon]
              password = pass
              upsmon master
              actions = SET
              actions = FSD
              instcmds = ALL
      - upsmon.conf
      - RUN_AS_USER xxxx
      MONITOR ups at localhost 1 upsmon pass master
      MINSUPPLIES 1
      # This makes the built-in shutdown a no-op
      SHUTDOWNCMD "echo \"Shutdown\" | wall"
      # Converts notification (of ONBATT) to scheduled events
      NOTIFYCMD /sbin/upssched
      POLLFREQ 5
      POLLFREQALERT 5
      HOSTSYNC 15
      DEADTIME 15
      # Does not matter for our setup but required for upsmon to run
      POWERDOWNFLAG /etc/killpower
      # Removes all of the default 'wall' output from UPS events,
      #   adds a EXEC event that actually performs the shutdown
      NOTIFYFLAG ONLINE       SYSLOG
      NOTIFYFLAG ONBATT       SYSLOG+EXEC
      NOTIFYFLAG LOWBATT      SYSLOG
      NOTIFYFLAG FSD          SYSLOG
      NOTIFYFLAG COMMOK       SYSLOG
      NOTIFYFLAG COMMBAD      SYSLOG
      NOTIFYFLAG SHUTDOWN     SYSLOG
      NOTIFYFLAG REPLBATT     SYSLOG
      NOTIFYFLAG NOCOMM       SYSLOG
      NOTIFYFLAG NOPARENT     SYSLOG
      RBWARNTIME 43200
      NOCOMMWARNTIME 300
      FINALDELAY 5
      - upssched.conf
      - # Names actual shell script which runs
      CMDSCRIPT /etc/nut/forceshutdown.sh
      PIPEFN /etc/nut/upssched/upssched.pipe
      LOCKFN /etc/nut/upssched/upssched.lock
      # Handlers to start or cancel timer based on battery signals
      # Note that 'onbatt' is a command line parm for shutdown
      #   script, but is not actually observed in the script
      AT ONBATT * START-TIMER onbatt 5
      AT ONLINE * CANCEL-TIMER onbatt
      - forceshutdown.sh  -- my custom script, doesn't case...esac the
   parameters since it's dedicated to shutting down
      - #! /bin/sh
      /bin/upscmd -u upsmon -p pass ups at localhost load.off.delay 30
      sudo /sbin/shutdown -h +0
      - users & permissions on files/folders to suit everything
   - PC is set up to boot on power


Works great!   Maybe not in the spirit of nut, especially since we're
essentially using the mains power to turn on/off the whole system.

I'll be happy to answer questions if anyone has them.    At some point I'd
also like to learn more about nut and add more support for the AVR550U to
help with the "restart on power" aspect that triggered this whole
conversation.  But, at the moment I'm overwhelmed with getting this project
done.




On Mon, May 20, 2019 at 4:12 PM Charles Lepple <clepple at gmail.com> wrote:

> [please use reply-all to include the list]
>
> On May 20, 2019, at 5:30 PM, Steven Bixby wrote:
> >
> > I have a TrippLite AVR550U that my company uses several individual Linux
> boxes in one large system, all running Ubuntu 18.04LTS, and all will be
> using the package version of nut - 2.7.4.    In my scenario, our usage case
> is for the PCs to all shut down, followed by the individual UPSes, when
> mains power is removed from the whole system.  (This isn't a typical setup
> for UPS, but it's what we designed for our needs.)
> >
> > I have a basic "standalone" setup running OK - I can pull the plug, the
> PC shuts down, followed by the UPS, and everything is great.  Except...
> When reapplying the mains power, the UPS isn't starting the load back up.
> I have to force it to start from the panel button, which is a requirement.
> >
> > Linux isn't my native environment; one of the PCs in our system does run
> Windows, and using TrippLite's PowerAlert software, I can configure the UPS
> to auto restart on power -- and it works very well.   So, I *know* there's
> something that can be sent to the UPS to configure for auto-start.
> >
> > Alas, in three days of struggles with everything, I still haven't found
> the answer to this problem.  Hopefully it's just a configuration parameter
> I've missed.  Or if nothing else, I can adjust the nut source to push the
> command(s) - if I can figure it out.    I'm about to try to use
> Wireshark+USBCap on Windows to trace what's going to the TrippLite when
> this setting is changed -- I've just had very little luck with WS/USBCap in
> the past, just too much information to sort through.
>
> Does the output from "upsc" look similar to this?
> http://new.networkupstools.org/ddl/Tripp_Lite/AVR750U.html
>
> I don't think we have a listing of valid NUT instant commands for the
> model mentioned in that variable dump (or the AVR550U, for that matter),
> but both variables and commands could help debug this problem.
> https://networkupstools.org/stable-hcl.html#footnotes
>
> If the delay settings look reasonable, and "upscmd name-of-ups
> shutdown.return" doesn't do the trick, we will need to do some more digging.
>
> I'm wondering if it is this issue seen on a BCPERS450:
> https://alioth-lists.debian.net/pipermail/nut-upsuser/2018-January/011020.html
>
> Probably a bit easier to read the thread here:
> https://www.mail-archive.com/nut-upsuser@lists.alioth.debian.org/msg10430.html
>
> It's been a little while since I used Wireshark to capture USB on Windows,
> but let me know if there's something I can help with.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/nut-upsuser/attachments/20190523/71d850fe/attachment.html>