I've been looking over the documentation and several installation guides for NUT, and I'm starting to get a little bit of a feel for what it is. But I'm still not clear whether what I'd *like* to accomplish is actually practical using NUT. Perhaps someone here can tell me if they've done something similar, or if I'm way off base. 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) I'm interested in monitoring and alerting, not so much in making changes to the UPS settings or shutting down computers, etc. My dream result at this point would be a central system that: A) Gives me a single "pane of glass" to see the current status of my UPSs on a web page B) Sends me emails when power related events happen at a UPS (loss of utility power, low battery, etc.) Am I barking up the wrong tree? Or does this sound like something that NUT can provide? Garrett Michael Hayes -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20170302/61717d4a/attachment-0001.html>
On Thu, 2 Mar 2017, Garrett Michael Hayes 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) > > I?m interested in monitoring and alerting, not so much in making changes > to the UPS settings or shutting down computers, etc.I think it would be much easier to write a central monitoring script which talks to the instances of upsd monitoring the UPS units. Let upsd do all the hard work of talking to the UPS's. Roger
Garrett, I hope you're not barking up the wrong tree because that's exactly what I'm working toward. The web display was pretty straightforward. I haven't worked out the email notification part yet but it seems like it should be doable. -Charles From: Nut-upsuser [mailto:nut-upsuser-bounces+fairfaxc=missouri.edu at lists.alioth.debian.org] On Behalf Of Garrett Michael Hayes Sent: Thursday, March 02, 2017 12:47 PM To: nut-upsuser at lists.alioth.debian.org Subject: [Nut-upsuser] NUT - General Concept Question I've been looking over the documentation and several installation guides for NUT, and I'm starting to get a little bit of a feel for what it is. But I'm still not clear whether what I'd *like* to accomplish is actually practical using NUT. Perhaps someone here can tell me if they've done something similar, or if I'm way off base. 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) I'm interested in monitoring and alerting, not so much in making changes to the UPS settings or shutting down computers, etc. My dream result at this point would be a central system that: A) Gives me a single "pane of glass" to see the current status of my UPSs on a web page B) Sends me emails when power related events happen at a UPS (loss of utility power, low battery, etc.) Am I barking up the wrong tree? Or does this sound like something that NUT can provide? Garrett Michael Hayes -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20170302/dd203f6e/attachment.html>
Roger, Thanks. I think that may be what I was trying to say, but not expressing adequately. In other words have UPSD running on a Pi at the UPS and reporting back to some central system. Doing it by "push" from the Pi or "poll" from the central system is pretty much a wash as far as I'm concerned. Is that what you are suggesting? Or did I misunderstand? GMH -----Original Message----- From: Nut-upsuser [mailto:nut-upsuser-bounces+garrett=verbalimaging.com at lists.alioth.debian.org] On Behalf Of Roger Price Sent: Thursday, March 02, 2017 4:24 PM To: nut-upsuser Mailing List <nut-upsuser at lists.alioth.debian.org> Subject: Re: [Nut-upsuser] NUT - General Concept Question On Thu, 2 Mar 2017, Garrett Michael Hayes 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) > > I?m interested in monitoring and alerting, not so much in making changes > to the UPS settings or shutting down computers, etc.I think it would be much easier to write a central monitoring script which talks to the instances of upsd monitoring the UPS units. Let upsd do all the hard work of talking to the UPS's. Roger
Thanks, Charles! Any pointers on the web stuff would be greatly appreciated. I've done almost nothing with web setups in Linux except follow some scripts for packaged stuff like RT, Zenoss and WordPress. Garrett From: Fairfax, Charles A. [mailto:FairfaxC at missouri.edu] Sent: Thursday, March 02, 2017 4:27 PM To: Garrett Michael Hayes <Garrett at VerbalImaging.com>; nut-upsuser at lists.alioth.debian.org Subject: RE: NUT - General Concept Question Garrett, I hope you're not barking up the wrong tree because that's exactly what I'm working toward. The web display was pretty straightforward. I haven't worked out the email notification part yet but it seems like it should be doable. -Charles From: Nut-upsuser [mailto:nut-upsuser-bounces+fairfaxc=missouri.edu at lists.alioth.debian.org] On Behalf Of Garrett Michael Hayes Sent: Thursday, March 02, 2017 12:47 PM To: nut-upsuser at lists.alioth.debian.org<mailto:nut-upsuser at lists.alioth.debian.org> Subject: [Nut-upsuser] NUT - General Concept Question I've been looking over the documentation and several installation guides for NUT, and I'm starting to get a little bit of a feel for what it is. But I'm still not clear whether what I'd *like* to accomplish is actually practical using NUT. Perhaps someone here can tell me if they've done something similar, or if I'm way off base. 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) I'm interested in monitoring and alerting, not so much in making changes to the UPS settings or shutting down computers, etc. My dream result at this point would be a central system that: A) Gives me a single "pane of glass" to see the current status of my UPSs on a web page B) Sends me emails when power related events happen at a UPS (loss of utility power, low battery, etc.) Am I barking up the wrong tree? Or does this sound like something that NUT can provide? Garrett Michael Hayes -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20170302/d395b823/attachment.html>
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/
> > 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>