Renewable Energy Monitor

This page describes the renewable energy monitoring system whose output is visible here (use credentials ‘guest’ and ‘password’).

Monitor solar/wind powered battery banks, micro-generators, diverse low-power and related environmental parameters with the accuracy, capacity and speed with which the IT industry monitors servers.

Sends email alerts to owners of remote renewable energy devices and batteries when parameters like voltage, current, temperature, etc, go out of pre-set ranges.

Two methods:

1. At the remote site, sensor data from '1wire' sensors is periodically gathered and pre-processed by a low-power Linux device, formatted, and then securely copied across the Internet to a central monitoring server. There, each new payload of sensor data is checked against pre-set thresholds to determine if a warning or critical condition exists. The results are piped into Nagios, which displays status on a web page and produces notification emails if necessary. This method is used to monitor sites 'lee' and 'site01 at the link below. Copy of the NSLU2 sensor processing script is here.

2. At the remote site, sensor data is gathered and pre-processed by an Arduino microcontroller, then posted across the Internet to the monitoring server using standard Web protocols. There, the incoming data is re-formatted into a datafile. Each new file of sensor output is checked against pre-set thresholds to determine if a warning or critical condition exists. The results are piped into Nagios, which handles status display and notification emails. This method is used to monitor sites 'site02' and 'site03' at the link below. Copy of the Arduino sensor processing code is here.

There is.

The system has to handle many problems – some old, some new. Eg:

• Acquiring different kinds of sensor data
• Smoothing sensor data
• Reliability in normal, warning and critical conditions
• Low power
• Ability to monitor remote sites for long periods
• Be easy to set up
• Be easy to understand
• Be fast but not over-sensitive
• Be flexible
• Be highly configurable for different sites' needs

So that you can balance price, power and flexibility according to your requirements.

Method 1 above - NSLU2 + 1wire sensors - lets you pre-process the sensor data as much as you want before sending it to the monitoring server. Using 1wire sensors and a re-flashed Linksys NSLU2 opens up the range of 1wire sensors for a cost typically under £100. Here are the scripts

Method 2 above - Arduino + sensors - is even cheaper and the microcontroller's digital and analog input pins accept input from most cheap, common electronic sensors - even passive resistor dividers. Pre-processing is as easy with, for example, Arduino's Wiring language and programming interface.

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.

At site02, an Arduino reports the voltage and current measured in a 12V diversion/dump controller by an AttoPilot Current and Voltage Sensor.

At site03, an Arduino reports the voltage and current measured in a 24V diversion/dump controller by an AttoPilot Current and Voltage Sensor.

It works well, though I’m developing both the software and hardware further, naturally. Within days of getting the first version running, it warned me of a dislodged battery charger lead. It has since warned me several times of power outages and dislodged leads.

That varies slightly depending what type of sensors you are using.

NSLU2 + 1wire sensors

• 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. That file looks like this:

  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'

Arduino + electronics sensors

• Voltages and current, or whatever are sensed using any sensor with an electrical output from 0-5V
• The sensors' output is fed to the Arduino's analog or digital input pins
• Code on the Arduino periodically samples the inputs and posts the data using HTTP to the Nagios server. Those posts look like this:

  HEAD /cgi-bin/post.py?s=site02&p=<PASSWORD>&d=Device01&t=<TIME>&&Volts=26.350053&Amps=15.769345&n="'Wind+Generator'"
  HTTP/1.1\nHost: domain.com

• A python script on the Nagios server sanitises this incoming data, reformats it and writes it to the above datafile format ready for processing by the Perl pre-processor

In both cases, the uploaded data is now on the Nagios server, where:

• 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.
• Built-in Nagios customer-alerting functions send Warning and Critical alerts by email.

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 judgement 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, its sensors 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.

1. Add SMS alerts to Nagios - Done
2. Add email and SMS alert acknowledgement capability to Nagios
3. Continue work on reducing sensor nodes' power consumption
4. Continue work on automating setup of new node configuration in Nagios
5. Continue to improve the Arduino code's flexibility by modularising it further
6. Continue to improve AttoPilot Current and Voltage Sensor sensors
7. Write and test Arduino code to use Senis' BBMXX-KIT-I current sensor
8. Modify the Perl pre-processor to store data-readings in a (Redis) database - Done

SolarEdge: Commercial supplier of panel monitoring kit