Low-Power Control Systems

I wanted to apply the excellent monitoring, alerting, and status-management features of Nagios to renewable energy devices.

Here is the result, updating in real-time… (use credentials ‘guest’ and ‘password’).

At the site named ‘lee’, Nagios is monitoring the voltages and temperatures of three separate battery banks. This is a real site and real data.

At the site named ‘site01’, Nagios is monitoring the voltages and temperatures of various power generators. This site is a software simulation that I wrote to provide varying data against which to test solutions to the many challenges power device monitoring presents to ‘off the shelf’ systems like Nagios.

How well does it work? It works well, though I’m developing both the software and hardware further, naturally.

How it works in outline

• Voltages and temperatures are sensed using three MS-TV 1wire sensors
• The 1wire network is managed by an SlugOS/BE-flashed NSLU2 running owfs
• On the NSLU2, an ash script averages three one-minute-interval readings for each parameter and writes the data into a file.
• Every four minutes, the same ash script securely uploads the data file to the Nagios server
• A perl script on the Nagios server processes the datafile for:
  • timeliness
  • validity
  • formatting
  • then processes each parameter in the file against the site’s required thresholds for each parameter (eg under-voltage, over-voltage, under-temperature, over-temperature), then:
  • writes its findings in Nagios’ host and service formats to the Nagios command pipe function
• Nagios processes the data with reference to the site’s Nagios configuration, which specify the usual Nagios parameters such as check times, contact details, etc.

It’s clear from the above that the perl script does the hard work. Much of that hard work is about determining the cause of any timing delays and passing a reasonable judgment to Nagios of the cause. It is trying to address the ‘connectivity breaks’ challenge described in the Design Decisions discussion and, in test, is proving surprisingly successful.

The 1wire approach works well, is well-documented, and is relatively quick to deploy. However, to free the system of the limitations of 1wire sensors – for measuring current for example – I’ve moved on to building an Arduino-based sensor network.

Arduinos offer much broader electrical connectivity options at the expense of precision, restricted TCP/IP connection security, and the need to write custom Wiring code (C code variant). I’ll discuss how that is working after further testing.

You're welcome to use this monitor for your own stuff if you want to. Here's what you need to do:

1. Use sensors to grab the data you want monitored, and
2. Scp/pscp/Winscp/sftp the data in text-file format to the monitor server,
3. Writing the data file into your home directory of the account you ask me to create for you on the monitor system

In more detail that means:

1. Attach the appropriate sensors to your equipment
2. For each device you've attached sensors to, write their output into a text file in the following format:
   1. DeviceXX, [timestamp (in either UT format or Unix epoch format], Reading1, Reading1's units, Reading2, Reading2's units, 'Comment'
   2. If you want more than one device monitored, periodically write their sensors' output into a single text file like this example:

  Device01, [timestamp (in either UT or Unix epoch formats], 26.35, volts, 7, Amps, 'Wind Generator'
  Device02, [timestamp (in either UT or Unix epoch formats], 25.02, volts, 19.34, deg C, 'Battery bank'

SolarEdge: Commercial supplier of panel monitoring kit