[Nut-upsuser] NUT - General Concept Question

Fri Mar 3 13:02:37 UTC 2017

>
> I think you would need a level-shifter to do RS-232 serial with a RPi, and
> you may need to fiddle with the cable if modem control lines are involved,
> but it should be possible.
>

To solve the level shifting problem I've used the following little card
from SparkFun Electronics.

https://www.sparkfun.com/products/11189

This is being used for a Tripp-Lite which didn't require modem control
signals if I recall correctly.

--Larry

On Thu, Mar 2, 2017 at 9:57 PM, Charles Lepple <clepple at gmail.com> wrote:

> On Mar 2, 2017, at 1:46 PM, Garrett Michael Hayes
> <Garrett at VerbalImaging.com> wrote:
> >
> > I would like to set up a Linux host as a central monitoring system for
> UPSs throughout our network.  I’d like that system to be able to see the
> various UPSs basically in one of two ways:
> > 1)      Tapping into a native network interface on the target UPS (such
> as some larger APC and Tripp-Lite UPSs we have)
> > 2)      Talking to a Raspberry Pi connected to the UPS via a USB or
> serial cable (for lower end UPSs that don’t have network capability)
>
> One of the design goals of the NUT drivers is that they provide their
> status and measurements using a common naming scheme. There is a SNMP
> driver that covers most the APC and Tripp-Lite MIBs, so that should cover
> case 1. (The three-phase names are similar to the single-phase names.)
>
> I have done a fair amount of testing with a Raspberry Pi and USB, and it
> is no worse than USB on a PC, so that covers at least part of case 2. I
> think you would need a level-shifter to do RS-232 serial with a RPi, and
> you may need to fiddle with the cable if modem control lines are involved,
> but it should be possible.
>
> I will point out that we sometimes run into regressions with firmware
> upgrades on SNMP network cards, but often it is something that can be fixed
> by downgrading the firmware, or bugging this list to fix the NUT side.
> Also, there are some Tripp-Lite USB models which seem to have trouble
> keeping a connection up long-term. Either way, we do have an extensive
> collection of sample datasets here, if you are interested in seeing the
> sort of values you can expect (and problems that users have noticed) on a
> Vendor/Model basis: http://networkupstools.org/ddl/
>
> > I’m interested in monitoring and alerting, not so much in making changes
> to the UPS settings or shutting down computers, etc.
> >
> For monitoring, you would run "upsd" plus the model-specific driver(s) on
> a nearby system.
>
> If you are monitoring over the network, fewer hops between driver and UPS
> network card would be best. USB pretty much means the machine with the USB
> host port must run upsd, although as you pointed out, that machine can be
> an embedded system. If your USB UPS reports a unique serial number (as seen
> in "lsusb" or kernel message logs; the 16-bit user-definable Tripp-Lite
> unit ID seen in their GUI doesn't meet the criteria), you can even have
> several USB UPSes monitored by one upsd.
>
> From there, you have a number of choices for polling the data from upsd.
>
> NUT comes with "upsmon", a basic shutdown/alerting tool, but you can
> always define the shutdown command to be something innocuous like
> /bin/true, and/or give each UPS a "power value" of zero. You can use upsmon
> for "raw" notifications - reporting an event as soon as it happens,
> basically. If you want to "de-bounce" an event (that is, only send an email
> if the power is out for more than 30 seconds), you can configure upsmon to
> call "upssched" to start a timer, and trigger an action if the timer hasn't
> been stopped.
>
>  * http://networkupstools.org/docs/man/upsmon.html and
> http://networkupstools.org/docs/man/upsmon.conf.html
>
>  * http://networkupstools.org/docs/man/upssched.html and
> http://networkupstools.org/docs/man/upssched.conf.html
>
> It has been a while since I last set up the NUT CGI components, but I
> suspect you can just list each UPS in the template for upsstats, and add in
> upsimage references where you want graphs:
>
>  * http://networkupstools.org/docs/user-manual.chunked/
> ar01s02.html#_cgi_programs
>  * http://networkupstools.org/docs/man/upsstats.cgi.html
>  * http://networkupstools.org/docs/man/upsimage.cgi.html
>
> You can ignore upsset for a read-only dashboard.
>
> We don't have a lot more documentation on the CGI scripts (other than
> reference material), so if you don't feel comfortable setting this up from
> scratch, you might want to see if any of the monitoring systems listed here
> would be quicker to configure for your dashboard idea:
> http://networkupstools.org/projects.html#_network_management_systems_nms_
> integration
>
> (I personally use collectd, since it gathers stats on other subsystems
> that I care about in addition to NUT. I either use kcollectd to view the
> RRD files locally in X, or I have set up collection3.cgi for remote
> viewing.)
>
> You could probably configure the monitoring system to alert you to various
> UPS conditions as well.
>
> One thing that hasn't been mentioned yet is that you can prototype all of
> this by using the dummy-ups driver. This driver simply reads values
> repeatedly from a file, and you can edit that file to simulate events like
> short power glitches. Again, you can consult the DDL site listed above to
> pull sample values for a model similar to one that is deployed, and test
> the entire driver/upsd/upsmon stack on a laptop or VM without needing
> actual UPS hardware. If you use an automation system like Ansible, it
> should be fairly easy to create templates for all of the configuration
> files (including setup of the RPi nodes), and just change the host list
> when it is time to deploy to the production system.
>
> Let us know how it goes.
>
> (opinions are my own - I do not speak for my employer, etc, etc.)
>
> --
> - Charles Lepple
> https://ghz.cc/charles/
>
>
>
> _______________________________________________
> Nut-upsuser mailing list
> Nut-upsuser at lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
>

-- 
Larry Fahnoe, Fahnoe Technology Consulting, fahnoe at FahnoeTech.com
           Minneapolis, Minnesota       www.FahnoeTech.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20170303/d5c79edd/attachment.html>