In the summer of 2011, one of our goals at Whitehead Light Station was to start collecting data about how much power and water we use. We started with a TED5000 from Energy, Inc, then we installed hardware from Brultech.

System Summary

Monitor:	Green-Eye Monior (GEM) ECM-1240 OW-SERVER-ENET-2 CT50 TED5000
Computer:	ionics cumulus
OS:	Debian 6
Software:	btmon.py rrdtool mysql

Release 1.1.3 of Monitoring Tools (mtools)

Fix to btmon.py in the SocketServerCollector.readbytes method, prevents spurious exception in the printing of debug messages while reading data.

Release 1.1.2 of Monitoring Tools (mtools)

Primarily fixes to btmon, including new URL for xively, fix to enersave uploader, fixes to sqlite and mysql, updated compatibility for emoncms 8.4.x, support for wattvision api 0.2, bidgely api 1.0.1. Minor code cleanup to the other utilities.

Release 1.0.3 of Monitoring Tools (mtools)

Minor update to the monitoring tools. Added MySQL support in tedmon, edsmon, and rtmon. MySQL connections default to being non-persistent - a connection is made for each data upload. This should lead to more robust performance.

thermd

Many monitoring systems are re-creating what thermd, a perl application, has been doing for years. Daniel Klein has been monitoring temperatures since 2001 with Dallas Semiconductor sensors and power since 2007 using Enersure hardware. Daniel's device comparison contains a lot of useful information about power and environmental monitoring hardware.

Web Energy Logger

The Web Energy Logger is yet another monitoring device. It is designed to work with the Web Energy Logger service run by Phil and Lisa Malone from our cool house. The hardware has a 1-wire bus (temperature only, sampled every 6 seconds), 6 pulse-output watt meters (sampled every 60 seconds), 8 dry-contact closures, and 2 analog inputs. Device configuration is done using a web server built in to the device. The device has no storage - it uploads data to any server. There is a TTL serial link for communication with a data logger. It costs about $400 for a starter kit or $555 for a kit with 10 temperature sensors.

btmon 3.0.6b3

Reworked part of the main loop logic so that btmon will deal better with flaky networks and communications. There is now a READ_RETRIES parameter that indicates how many retries should be attempted before giving up. The default value is zero, which indicates 'retry forever'. Tested on debian linux and windows 7 so far...

Apparently the most recent GEM firmware uses one bit to indicate the sign of the temperature. Once the firmware stablizes over at Brultech we can update btmon to work properly with it.

Release 1.0.1 of Monitoring Tools (mtools)

The btmon, rtmon, edsmon, and tedmon tools are now part of a package called mtools. Each is a standalone script, but at some point they will probably starting sharing some Python library code.

The 3.0.5 release of btmon includes the following:

• upload both energy and power number to oem
• added reverse-polarity option
• added copyright/licensing details
• added support for pvoutput.org

rtmon collects data from Radio Thermostat devices.

edsmon collects data from EDS One-Wire-to-Ethernet Server devices. The OWS can monitor up to 24 one-wire devices such as the DS18B20 temperature sensor.

tedmon collects data from TED5000 devices.

Each of these tools can save to RRD files or upload to various hosted services such as Smart Energy Groups or COSM.

GEM Counter Wraparound and Counter Reset

Counter wraparound is a problem when recording cumulative values for watt-seconds or watt-hours, but not differential.

On the GEM there are two counters for each channel - absolute and polarized. When the absolute counter wraps but the polarized counter does not, a cumulative calculation will be incorrect.

btmon 3.0.x records cumulative values to RRD and database.

GEM Channel Polarity

Values from btmon have a sign opposite that reported by the GreenEye Monitor Setup application from brultech, and the GEM itself. btmon uses a formula that stems from ecmread 0.1.4 - it interprets an increase of the polarized watt-second counter as positive energy. GEMSetup seems to interpret an increase of the polarized watt-second counter as negative energy.

btmon: 2 * pws - aws
gemsetup: aws - 2 * pws

Here are the polarities of two GEM channels as reported from various mechanisms.

channel	btmon	setup	list	SEG	APIWAT
31	-	+	+	+	+
32	+	-	-	+	-

btmon - values reported by btmon from GEM binary packets
setup - values reported by GEMSetup in the real-time panel
list - values reported by btcfg APISPK from GEM list packets
SEG - values reported by btcfg APISPK from GEM SEG packets
APIWAT - values reported by btcfg APIWAT

Channels 31 and 32 are each monitoring a 110V circuit, each with a split 100 CT. Each circuit is on a different leg of a single-phase panel. Each CT is installed with the L toward the load, i.e. K is toward the breaker, and the arrow points toward the load. The polarity of each channel is set to 0 (the gem default). There is a constant load on each circuit of about 250W. This is with GEMSetup v1.9 and COM firmware 1.63.

It looks like there is a bug in the GEM firmware that does the SEG calculations - the SEG output is not consistent with the other values.

btmon probably needs a configuration option to reverse the signs so that its output matches that from GEMSetup.

btmon 3.0.3 is now available

This release includes the following changes:

• upload pulse and sensor data to oem, seg, and pachube
• improve reporting of read errors when in polling mode
• include timestamp on thingspeak uploads
• change default rrd values to assume 10s sampling

Radio Thermostat

Radio Thermostat Corporation of America (RTCOA) makes a device called the Radio Thermostat - a thermostat with with option to connect to a wifi network. There are at least two models - CT30 and CT80. 3M sells a CT50 model under the Filtrete brand, available at Home Depot. LockState sells the LS-60i which is another variant.

Here are some impressions after installing the Filtrete CT50 in a building that is about 100 years old. The HVAC system consists of only a heater - a Laars mini-therm boiler installed in 1987.

• Features are basic. The CT50 supports a 7-day schedule, with each day having up to 4 periods, plus a 'holiday' schedule. It has two levels of locking.
• Luckily this device can be programmed remotely. You do not want to waste your time programming it via buttons or touch screen.
• The build quality is ok, but not great. The plastic is cheap and the stickers/silkscreening are very cheap. You do not want to put this device where it will be seen.
• The touch screen is difficult to use. Most of the controls require you to touch the item that you are controlling, so as soon as you touch it you cannot see what it is doing. For example, to lock the device you must touch the lock for 5 seconds, but then you cannot see when the device locks. To adjust the time, you must touch arrows next to the time, so then you cannot see the time that you are adjusting.
• Programming the device is difficult. The touch screen is flaky, there are many modes of operation that are not obvious, and the mechanisms for configuring the device vary. In some cases one must touch and hold, in other cases simply touch, in other cases press a mechanical button first then touch.
• Wireless setup is not bad, but definitely not obvious. First put the device into 'provisioning' mode by touching the radio tower icon. A yellow light will flash to indicate the device is in provisioning mode. At this point the device is broadcasting its own wireless network and displaying a code in the upper left corner of the display. You must bind to that network with a laptop (the network does not show up on android devices - not sure about ios devices) then point a browser to 192.168.10.1. Enter the code in the browser form and configure the device to bind to a wireless network. There is an 'advanced' link for specifying a wireless network that is not broadcasting the SSID.
• The product design is crude. The batteries are difficult to insert and remove. There is little provision for wiring clearance. There is no wiring strain relief. There is no consideration for removing the device from the wall.
• The device sticks out from the wall. It is possible to flush-mount, but the plastics, attachment points, and fasteners are not designed for this. If you do flush mount you might want to fabricate a mechanism to make the device removable.
• The infamous 'C' wire is simply a common ground/neutral. I hesitate to say 'ground', because grounding the wire might or might not work. Power is supplied from the R (or RH or RC) terminal, but to get a voltage you need the C going back to the other end of the transformer from which the R is coming. Many furnaces and boilers have a 'C' terminal. On those that do not, you need to find a way to connect to the transformer lead that is not R, on the low-voltage side of the transformer, of course.
• There are a number of hacks to get a 'C' wire to the thermostat - use an existing unused wire; hijack the 'G' wire; run a new wire; install a 24VAC transformer.

RTCOA provides android and iOS apps to monitor, control, and program the radio thermostat. To use this you must create an account at RTCOA, enter the UUID from the device, configure the device to phone home (simply enter a key provided to you by the RTCOA web site), and enter some information about the device location.

The device works without phoning home, but it seems the only way to update the firmware is to use the android or iOS app, which requires the RTCOA account and having the device phone home. There are reports of the firmware reverting to older versions, so after updating you might want to disable phoning home (or block the device with your firewall). RTCOA seems to keep a master list and automatically updates firmware, or not.

You can change the URL on the device so that it 'phones home' to your own web server, if you like.

The device has an embedded web server. Use a standard web server to configure the device, or use curl or other tools to get/set on the device directly. The API was last updated March 2012, but many of the options do not work (at least as of 24 Nov 2012 on a CT50 V1.94 with firmware 1.04.84).

The CT50 sells for less than $100. The CT80 includes more options (humidifier, dehumidifier, more programming zones), but costs around $200, which puts it into the same class as the Nest, Ecobee, TRANE, or Honeywell devices.

One-Wire to Ethernet Bridge

Embedded Data Systems makes the OW-SERVER-ENET-2, a one-wire-to-ethernet bridge. The device is simple to set up and works really well. It has three one-wire buses, each of which is powered and supports many one-wire devices. The connection interface for each one-wire bus is an RJ12 connector (only 3 of the 6 pins are used in each connector). For the ethernet side of things there is a 10BASE-T ethernet port. Power is supplied via mini-USB port.

The device has an embedded web server on it. The web server has a reasonable user interface that makes use of javascript to view current status and very basic real-time graphs of the one-wire devices. For programmed/automated access, the device provides a single XML file with current values and health of all attached devices.

The device supports many one-wire devices, including the DS18B20 temperature sensor. It also supports humidity sensors, light sensors, and pressure sensors.

Retail price is around $100. The DS18B20 temperature sensors cost $1.50 (plain DS18B20) to $2.50 (DS18B20 in waterproof enclosure with 1 meter leads) in quantities of 10 to 20.

There is also the HA7Net which supports up to 100 one-wire devices but costs about $175.

btmon 3.0.1 is now available

This release includes the following:

• force period and timeout to be int
• adjustments to default values for service upload periods
• added support for wattvision
• added 0.5 multiplier for one-wire bus (only for DS18B20?)
• added command-line and config file options for poll intervals
• added command-line and config file options for update/insert periods
• do bulk uploading for pachube/cosm
• fix off-by-one bug in thingspeak default field indexing
• do bulk uploading for seg

eMonitor4 from Powerhouse Dynamics

About a month ago Powerhouse Dynamics released the eMonitor4, the latest version of their home energy monitoring sytem. The per-circuit cost is now around $32 ($440 for 14 circuits) to $21 ($900 for 44 circuits). The hardware consists of a gateway devices, a base collection device with 14 channels, and expansion devices with 10 channels each. PhD encourages a hosted, subscription-based model for monitoring and analysis - subscription prices start at $8 per month for 14 channels. The eMonitor phones home with your data, and all of the analysis tools are hosted. However, the gateway has a web server on it, so it is possible to write your own collection, monitoring, and analysis software. PhD can not only monitor energy, but also control HVAC - it supports the Radio Thermostat CT30 and CT80.

btmon 3.0.0 is now available

Many thanks to those who helped with the beta testing.

beta 6 release of btmon, beta 1 release of btcfg

Use counter schema in RRD files in preparation for using RRD files as data source. Save and report only 32 of the 48 channels in a GEM binary packet. Adjustments to counters DB schema to accommodate large values. Minor fixes to SEG uploads to avoid upper/lower case issues. Now supports polling mode for ECM-1240 and ECM-1220 as well as GEM. Proper handling of multiple virtual ECM1240 binary packets from GEM devices. Implemented retries when polling to work around keep-alive contention when devices are multiplexed.

btmon 3.0.0-b6

The configuration tool now supports ECM-1220, ECM-1240, and GEM. It will read settings from each of these devices, and it can be used to set various parameters on each device.

btcfg 0.2.0-b1

Update: for the latest btmon and btcfg, see the Software section at the top of this page

beta 5 release of btmon

Database schema is now abstracted into an object. Added notes about upgrading from ecmread - most upgrade issues are related to database schema. Tested with ecm-1240 and various combinations of schemas and packets. Seems to be quite robust, even with 4 ECM-1240 multiplexed on a single serial line.

btmon 3.0.0-b5

Update: for the latest btmon and btcfg, see the Software section at the top of this page

beta 4 release of btmon

More fixes and features. btmon can now poll a GEM that is not in real-time mode. btmon will now automatically configure the database for MySQL and Sqlite - just start running btmon, and if the database/table does not yet exist, btmon will try to create it. Default values for all parameters have been improved. Error messages for missing parameters have been improved. Uploads have been tested for all 9 services. RRD storage now defaults to a configuration with 4 days of 30 second samples, 60 days of 5 minute samples, one year of 30 minute samples, and 2 years of 1 hour samples. With 48 channels, 4 pulse counters, and 8 sensors from a standard GEM configuration this amounts to a fixed-size storage of 162MB for 2 years of data.

btmon 3.0.0-b4
btcfg 0.1.1-b3

There are still some issues with respect to polarity, and the RRD settings are still somewhat a work in progress.

Update: for the latest btmon and btcfg, see the Software section at the top of this page

Introducing btmon.py

btmon.py is the replacement for ecmread.py, with support for the following:

• devices: Green-Eye Monitor, ECM-1240, ECM-1220
• packets: GEM, ECM-1240, ECM-1220
• collection interfaces: serial/usb, tcp/ip client or server, database
• local datastores: MySQL, Sqlite, rrdtool
• hosted services: OpenEnergyMonitor, SmartEnergyGroups, Pachube, Thingspeak, PlotWatt, PeoplePower, EnerSave, Eragy

btmon 3.0.0-b2

btcfg.py is a tool to read and write the configuration settings on a Green-Eye Monitor.

btcfg 0.1.1-b1

Update: for the latest btmon and btcfg, see the Software section at the top of this page

Smart Energy Groups expects delta, not cumulative

Smart Energy Groups expects a delta reading for energy, not a cumulative reading. Release 2.4.5 includes this change. Note that you can fix this at the server side by processing the readings when they are posted to your account at SEG.

ecmread 2.4.5-b2

Update: newer versions of ecmread.py have been released - see the link at the top of this page

TED5000 still less than desirable

We have been running two TED5000 units for about a year, each with 4 MTUs, one with a display unit.

• The gateway frequently drops off the network - the its-electric graphs show this very clearly.
• The readings are not accurate (I'm hoping to do some comparisons with the GEM we recently installed).
• The software is still horrible - we use its-electric and nagios/check_ted to collect and display data since the software that comes with the TED is so painful to use.
• The built-in graphing is flaky and poorly designed.
• The 'API' (I use that term loosely in this case) is still haphazard and incompletely thought out.
• The documentation is still horrendous, especially the troubleshooting document.
• The (built-in, non-replaceable) battery in the standalone display lasts for about 2 minutes.
• The standalone display loses contact with the gateway regularly, even when only a few feet away.
• The standalone display has a range of only about 10 feet.

The documentation and web site reflect a general inability to put coherent thoughts, descriptions, or instructions into words or pictures. Updates to the web site show a clear priority to sell devices and inability to fix underlying problems.

Pre-Release of SEG Fix

Smart Energy Groups expects a delta reading for energy, not a cumulative reading. In release 2.4.5, ecmread sends a delta reading - releases before 2.4.5 send a cumulative reading. This applies only to SEG - the other services expect a cumulative reading.

Note that you can fix this at the server side by processing the readings when they are posted to your account at SEG.

ecmread 2.4.5-b1

Update: newer versions of ecmread.py have been released - see the link at the top of this page

Unit ID and minor bugfixes

The 2.4.4 release of ecmread eliminates the Unit ID check (not all ECM-1240 have the same ID) and eliminates a redundant open on the serial port.

I'm working on support for the Green Eye and ECM-1220 devices...

Support for emoncms

As of 2.4.3-b2, ecmread supports the emoncms open-source energy visualization system from open energy monitor.

Update: newer versions of ecmread.py have been released - see the link at the top of this page

EnerSave is now Bidgely

EnerSave has changed its name to Bidgely. The change came with a (welcome) update to the web site - the interface is a lot cleaner. Unfortunately the data are still incorrect.

pachube and thingspeak

The 2.4.1-b2 release of ecmread supports pachube and thingspeak. So far it seems that these two services only accept real time data - my attempts to upload timestamped historical data have not worked. So the timestamps of uploaded data will be inappropriately clustered when uploading using this release if you read from database with a large polling interval. If you upload immediately upon reading from ECM (the normal mode of operation) the timestamps will only be off by a few seconds at most.

Update: newer versions of ecmread.py have been released - see the link at the top of this page

ecmread footprint

How much memory does ecmread use? How much of the CPU does it require?

On an Ionics Nimbus plug computer (ARM CPU, 512MB RAM), each instance of ecmread uses less than 25MB of virtual memory, less than 10MB of resident memory, nominally 0.1% of the CPU or less, and never more than 10% of the CPU. This is with 4 instances of ecmread running - two instances to collect data and save it to a mysql database, and two instances to upload data from the database to 5 hosted monitoring services.

So many monitoring services, so little time

There are many monitoring services available now, and a few of them can be self-hosted.

• Eragy
• EnerSave
• Smart Energy Groups
• OpenEnergyMonitor (self-hosting only)
• Pachube
• PeoplePower
• PlotWatt
• Thingspeak (self-hosting is possible)
• WattDepot (self-hosted only)

• Google Power Meter
• Microsoft Hohm
• Wattzon

I have started a 2.4 branch of ecmread that uses a database as the input. So I run one instance of ecmread to collect data from the ECMs and save it to a database. Then I run a second instance of ecmread to periodically collect data from the database then upload to as many services as I can.

Why a second instance? A single instance of ecmread can do both the collection and the uploads. But while I'm hacking around with all of the different APIs I would rather not interfere with the data collection.

Once we have a month or two of data in each of these services we should be able to make a qualified assessment of the capabilities. Using ecmread with multiple services also exposes weaknesses so we can make ecmread more robust.

OpenEnergyMonitor

The OpenEnergyMonitor is a wireless, open-source energy monitoring node. It has 3 CT channels, one pulse counting channel, one one-wire temperature bus, and one AC voltage channel. It is powered by 5V USB or 2 AA batteries, and is compatible with Arduino IDE.

The device is not yet available for purchase, but should be released soon. When released, the device can be purchased fully assembled for about $60, or as a kit for about $45. So that is $15 to $20 per circuit.

The site also shows the emonGLCD, a simple LCD to display current power use, generation, temperature, etc. emoncms is the hosting software. It is available on github.

Smart Energy Groups

Since late 2010, Smart Energy Groups has offered the SEGmeter, a shield for Arduino. The device has 6 power monitor channels, 1 one-wire temperature channel, a single channel reed relay, a serial interface, and an optional zigbee interface. A starter kit costs $169 and a complete package costs $695. So that is $30 to $120 per circuit.

A v2 SEGmeter is in the works. No word yet on features or availability. SEG also offers a customized wireless router running OpenWRT to make it easier to get data from the SEGmeter to the SEG servers.

The folks at Smart Energy Groups have created a bunch of widgets for recording, graphing, and reporting data. The system works with power, energy, weather, and just about any other type of data, so its a lot like Pachube or Thingspeak. Too bad all the javascript makes my 2011 computer with 8GB of memory feel like it was made in 1995.

Ed Cheung

Ed Cheung has a wonderful home automation site showing all kinds of build-it-yourself goodness. Some of Ed's systems date back to the early 1990s, and most of it is built from scratch. Note the CTs.

TCP/IP fixes for ecmread

I picked up a WIZ110SR serial-to-ethernet board for $25. ecmread was using a server socket pattern, so I modified it to use a (simpler) client pattern and tested it with the wiz device. Changes are in the 2.3.4 release of ecmread.

OOPS! The WIZ (and others?) can operate in either client mode or server mode. I assumed the WIZ would be server, so I made ecmread behave as client. Bad assumption on my part, as there are configurations where one would like the WIZ to be the client and ecmread should be the server. For example, if the WIZ is behind a firewall or NATed you'll want it to 'phone home' to ecmread instead of having ecmread attempt to contact the WIZ.

So now ecmread can act as either client or server when collecting data via tcp/ip. Changes are in the 2.3.5 release.

How does your mysql database grow?

Here are the numbers for database growth:

This is a growth rate of about 1.2MB per day with 8 ECM-1240 recording power every 30 seconds and energy every hour.

For comparison purposes, the RRD files for 56 or so circuits total less than 20MB with 7 years of storage at a one minute sampling interval.

eGauge

There is a small company in Colorado called eGauge with a 12-channel monitoring device called eGauge. It communicates with a (standard?) power-line-to-ethernet router. It looks like there is a basic but functional hosted service that graphs data in pure SVG goodness. The system is pricey at about $65 per circuit - $750 for a 12-channel eGauge and 3 CTs, with additional CTs costing $30-$70 each. The CTs are huge, btw. The web site and other materials appear to be targeted at system resellers and consultants, not end-users.

Energy Inc, Brultech, and other vendors should learn from the eGauge web interface - it is the simplest interface yet for configuring multiple channels on multiple devices. It has one page in which to perform all of the configuration, and another page in which to monitor all of the outputs. No silly wizards, nested dialogs, or confusing modalities.

How to configure ecmread with various hosted power monitoring services

Update: please refer to the guide

Fun in the clouds (or 'Power Monitoring services still suck')

Not all energy analysis providers are created equal. While consolidating the code in ecmread.py, I decided to test features of the major energy analsys service providers. My goal is to provide compatibility with these services from within ecmread.py, that way I can run a single instance of ecmread and have it upload to N different services for comparison, contrast, and redundancy. There are quite a few services in various states of growth and decay.

What am I looking for in an analysis provider?

• Cost. The service must be free. I will provide vendors with my data, and unless/until they demonstrate value I consider access to those data my payment for services. Besides, I am developing for non-profit and residential use, not commercializing.
• API. It must be stable. It must be open and developer-friendly. It must be command-line (e.g. curl) accessible for testing and automation purposes. It should not require a massive framework just to use it - this is simply a case of uploading data, not controlling a nuclear power plant.
• Services. This is still a big unknown. Probably the most value would be comparison with other users, both locally and across the country. But until we start flinging some data we'll have to wait and see.

Here are a few of the players:

Instructions for each of these services are now included in the ecmread script.

Why do companies continue to call their products 'MyXXXXX'? Nothing says "we have no marketing or design skill" faster than prefacing your product with "my". Have you learned nothing from Windows 95?

Another thing that says "we were born yesterday" is a system that requires end-users to contact your technical support. This may be unintentionally due to poorly written or error-ridden documentation. Or it may be unintentionally due to a login/registration/configuration process that assumes everything will follow a single path in a flow chart. Please make your processes self-help as much as possible. That is where you will want to end up when you get bigger anyway, so that you can focus your human resources on the end-user interactions that really matter.

How to configure ecmread with mysql on debian linux

Update: please refer to the guide

ecmread.py for multiple ECM devices

We modified ecmread.py so it will handle multiple ECM devices. This works for printing and writing to database, but it does not do anything special when uploading to WattsOn.

ecmread-2.0.0.py

See the thread about 'ecm 1240 is spitting out random values' in the ECM-1240 Support forum at brultech.com. If you need to communicate directly with the ECM, Ben at Brultech will send you the specs.

Update: newer versions of ecmread.py have been released - see the link at the top of this page

Power monitoring with Brultech: the configuration

We installed 8 ECM1240 devices on two serial buses to monitor 52 circuits. Data are collected by a dreamplug computer running debian 6. Nagios monitors everything and collects data using nagiosgraph. We are also saving data to a mysql database for loss-free (we'll see how that goes) recording and detailed analysis.

Brultech ECM1240 - first impressions

The Brultech ECM1240 devices arrived today. This is definitely do-it-yourself hardware. The folks at Brultech make it easier by pre-installing resistors if you need them. For example, if you plan to use aux 5 for power monitoring they'll install a resistor there and calibrate the ECM1240 for power monitoring rather than pulse sampling. There is a lot of assembly required.

Brultech offers a number of packages, or you can purchase the ECM and CTs separately. The CTs come in a variety of sizes and shapes, from 40 amp to 200 amp, either split or not. It is easy to insert the CT leads into the wrong gap of the ECM, only to find later that the wire did not get clamped by the screw. Be sure to leave at least 2 or 3 centimeters around each ECM for access and wires.

All of the CT leads are stripped and tinned. The leads for the split 100 CTs are shorter than the others, but it is easy enough to solder (or wire nut) extensions.

The wall warts are large and thus a pain.

The software for configuring the ECM1240 is called "ECM 1240 IA.exe". It runs only on windows. You might be able to run it in a virtual machine, but be ready for lots of putzing if you are using XP and a serial-to-usb converter. The only reason to run the configuration application is to tweak parameters such as the update interval or the power threshold. The ECM1240 works just fine right out of the box, and if you do need to modify the parameters you will probabaly only have to do it once. That is nice, because the user interface is hideous, but functional.

The documentation is workable. There is an installation guide and a user guide for the ECM. Each ECM comes with a spec sheet that tells how it is configured. The guides are pretty crude, and there is a fair amount of duplication, especially the bits about "get a qualified electrician to do the work". It could stand a couple of days with a good editor. At least it is not the convoluted nightmare that is TED.

The software for monitoring the ECM1240 is called "ECM 1240 Engine G.exe". It runs only on windows. The user interface is not something you'll want to spend any time with. In particular, it is horrible for setting up labels for each channel, especially when there are multiple ECM devices. It appears to provide every option for communicating with ECMs, but the interface modalities are not pleasant. I'm sure its mother (or father) loves it, but using it is like stepping back to 1995.

The easiest way to use these devices is to have them send data to a server somewhere, then use web-browser-based software to view the data. For those of us who need cloud-free computing, we have to write our own at this point. The web-based monitoring tools provided by Energy Inc on the TED gateway are horrendous and buggy. For Brultech they simply do not exist.

What is missing from the Brultech lineup?

• A standalone display. The ECM1220 has a crude LCD display. It would be nice if there were a larger, battery or ac powered, LCD-only device that communicates with ECM1240 (or green eye) and simply displays a small subset of the data such as total power in use.
• More channels. The ECM1240 only has 7 channels. Luckily it is possible to gang them together - up to 4 on a single serial line, or any number on a zigbee network. The green eye should remedy this - we'll see when it comes out.
• Software support for multiple devices. The existing software is oriented toward a single ECM, and sort of handles up to 4 (or perhaps 6).
• Better software. Make the configuration tool cross-platform. Stop developing the EngineG application and focus those energies on a gateway.
• A device analogous to the TED gateway. Create a web-server-in-a-box that collects data from any number of ECM and lets you discover, configure, and browse the ECM via a web browser. Provide nice JavaScript-based web pages to view the data from individual ECM, or aggregate the data. Brultech should start with a robust, well-implemented software bundle that anyone can install onto a computer, then roll that up into an embedded server that they sell as a package. That way the DIY types can feed back fixes and features, and the non-DIY just get something that works.
• A solid server partner for the hosted data option. Apparently google is not the right choice.
• Publicly searchable support archives. For some reason, access to the ECM1240 (and 1220) support forums are accessible only if you log in. That means none of the search engine bots are able to index the forums. As a result it looks like there is a lot less activity and community around the ECM1240 than there really is.
• Polish. Clean up the documentation. Simplify the web site.

It will take considerably longer to get the Brultech system up and running than the TED5000. If we were uploading to a server somewhere, then the Brultech is only slightly more difficult to configure. But since we have to write our own data collection, display, and graphing software it will take awhile. The Brultech system offers far more options and details. In particular we will be able to do temperature monitoring and water/fuel consumption monitoring with the Brultech system. And so far it looks like the Brultech system will be much more reliable than the TED5000. We'll see how the accuracies compare...

Brultech ECM 1220 and 1240

Brultech sells a device called the ECM1240. The ECM1240 has 7 channels for monitoring individual circuits and pulse devices such as water/fuel flow meters. Up to 4 ECM1240 can be multiplexed onto a single serial cable. The ECM1240 is the successor to ECM1220, which could only monitor 2 circuits. Apparently there is a successor to the ECM1240 coming soon - the GEM, or Green Eye Monitor, announced in August 2011 but not available until early 2012 - that will monitor 32 circuits in a single unit. This device also has a bus for single-wire sensors. Cost should be about $10 to $15 per circuit.

The Brultech hardware seems to be a much better deal than TED, and Brultech offers far more options for configuring a system.

At a starting point of about $180 for a single ECM1240 and boatload of CTs, Brultech has the cheapest per-circuit monitoring system (about $25 per circuit).

Debian 6 and Dreamplug

After updating the dreamplug to debian 6 (it shipped with debian 5) performance is much better. It still exhibits more pauses than the ionics devices, but they only last a fraction of a second now.

Its Electric and Plug Computers

We tried its-electric on two different marvell-based plug computers. The plug computers draw little power, but they also have limited memory and disk space.

The dreamplug is not doing well - it tends to become unresponsive after a few days, so we only run wflogger on it now. The nimbus is a champ - we run nagios, wflogger, and its-electric on it and although it is slow, it continues to chug along.

If you run java with default settings, it uses far too much memory. So we limit the jvm memory to 128M. CPU use by its-electric is tolerable, but beware that it will consume 70-90% CPU until it has processed any existing data files. When you have a few months of data (about 120 .jdb files) this takes a few minutes on a plug computer. We configure its-electric to sample less frequently in order to minimize its nominal CPU use.

Here is the command we use to invoke its-electric:

java -Xmx128M -jar its-electric-1.8.jar -g http://192.168.10.10 -m 4 -d /var/itse/db --voltage --no-serve --import-interval 0 --long-import-interval 1200 2>&1 >> /var/log/its-electric.log &

Watt Depot

WattDepot is an alternative to its-electric. It uses the same Google time series chart that its-electric uses, but it does not have some of the other views that its-electric provides. We'll see if it leaks.

Its Electric

its-electric does a fine job of collecting data from a TED5000 gateway, and it presents the data nicely using the Google time series chart. On the down side, it is rather CPU intensive when it does its sampling. Since it is java-based, it has massive memory requirements (virtual image of over 500MB, real memory footprint of at least 64MB). Also on the down side is that the Google time series chart is flash-based. The show-stopper is that it-electric leaks memory (release 1.7), so it is not feasible for use on a remote, unattended system. I have been running it on 3 systems to monitor two different TED gateways - a mac mini g4 with 512MB RAM, a dreamplug with 512MB RAM, and a eepc netbook.

This is what the memory usage looks like:

application	platform	time	VSZ	RSS
its-electric 1.7	mac mini	startup	669372	64464
Nagios 3.2.3	mac mini	startup	13132	2160
its-electric 1.7	mac mini	14 days	669956	368508
Nagios 3.2.3	mac mini	8 days	13136	1276
its-electric 1.7	dreamplug	startup	656004	64332
Nagios 3.2.3	dreamplug	startup	11480	1076
its-electric 1.7	dreamplug	1 day	655996	83600
Nagios 3.2.3	dreamplug	1 day	11480	1076

So for now I have to install a cron job that restarts its-electric every day.

More disturbing is the memory leak on the dream plug when nothing is running. Just turn on the dream plug, leave it for a few days, and you'll see free memory drop off. I have even disabled bluetooth, the wireless access point, and samba.

check_ted

I created a Nagios plugin called check_ted that will check to see whether ted5000 is working. It can record metrics from 1 to 4 MTUs as performance data.

Define a command something like this:

define command {
   command_name check_ted
   command_line $USER1$/check_ted -H $HOSTADDRESS$
 }

define service {
  use lan-service,graphed-service
  host_name ted
  service_description ted
  display_name TED
  check_command check_ted
}

The detail of its-electric is nice, but the data files start to grow quickly, which means some kind of data pruning must be done at some point. A Nagios configuration with check_ted and nagiosgraph provides a convenient way to see trend data without having to worry about disks filling up.

So we end up using Nagios/nagiosgraph to monitor trends and set thresholds for alerts, and we use its-electric for detailed data analysis.

A month with the TED5000

After running the system for awhile, and after installing another TED5000 on a 100-year-old house, I have a few more thoughts.

The hardware works well.

The software is another story. The html/javascript/css shipped with TED5000 is horrible. Energy, Inc should either open source the gateway software or provide some way for me to replace it with my own html/javascript/css. Or give me shell access to the gateway so I can install my own web pages.

Luckily Energy, Inc made it easy to get data from the gateway, and Robert Tupelo-Schneck created its electric. Its electric is far better than the stuff from Energy, Inc. But you have to run another computer to collect and display the data.

Where is the SNMP interface to the gateway? Let me talk to it via SNMP for its own network/memory/disk status as well as for all the MTU data, then I could plug it in to my Nagios infrastructure.

This is with footprints R240 and gateway firmware r452. Please, someone at energy inc. get a clue about web site design and managing software releases and downloads. The web site is a nightmare to navigate and there are no release notes easily available so no one has any way to see if a new release might actually fix the problems they are having.

A few days with TED5000

The web interface is rubbish. It is 'wizard'-like instead of being functional, which makes it confusing for the new user and tedious for anyone who has used it more than once.

The 'API' is amateur - the 'API' consists of some URLs to CGI and html pages, neither of which is comprehensive. The XML output is amateur. Neither the 'API' nor the XML output are future-proof, nor are they designed with the downstream user of the data in mind.

The load profiling sucks. The system is not able to detect when devices are turned on and off. The idea is nice, but when you have many devices that use about the same amount of power, or when the start/stop around the same time, the load profiling algorithms do a poor job of detecting them. The user interface for defining the profiles is horrible - it is modal and 'wizard'-like, and thus far more difficult to use than it should be.

The load profiling is limited to 5 devices. Or is that 10? The text says I can enter 10 devices, but the user interface limits it to 5. And why 5? Why the arbitrary limit?

The TED5000 is limited to only 4 MTUs. Why the arbitrary limitation? why not unlimited circuit monitoring? Even if I could have 10 or 12 MTUs I would have a better chance of making the load profiling work (by specifying the MTU for a load profile to help the device distinction).

The documentation is amateur. It is haphazard. It tries to be recipe-like, which is a recipe for disaster. It is poorly organized, contains a great deal of duplication, and contains many conflicting suggestions. It looks like whoever does the documentation is clueless and is only conveying second-hand something they got from someone who actually knows what is happening. On top of that they keep adding to the documentation instead of dumping the poor structure and eliminating the conflicts.

Someone should wipe out all of the existing documentation and start over, but with someone who can write properly, organize, and package/format information.

The videos are a poor attempt to re-do the documentation. I do not want to sit through (or download) a video for one tidbit of information.

This useful tidbit was buried somewhere: /stats.htm

There is a warning about irreparable damage if you leave the display unit unplugged or if you do not charge it first. Really? Who would design hardware with such user-hostile behavior? And who would think that a piece of paper in the box would prevent users from doing such normal things?

There is an 'enhanced mode', but no indication of what it is or does. And there is no indication of when the TED5000 is in enhanced mode or when it is not.

Initial impressions of TED5000

We installed a TED5000 with 4 MTUs. The documentation is rubbish. There are conflicting instructions (how long to hold the display button, whether you need both black and red or only black, black only is better than black and red so why bother with red). The documentation looks like it was written by a pre-schooler. Both english and spanish user manuals are included in a single pdf file. The documentation use screenshots that will never be able to be kept up to date.

The graphic design, web page layout, and information display is crude. The javascript and web page programming are crude. The software is buggy, for example: dispay of zip codes starting with zero; most of the graphing pages do not do what a new user would expect, nor do they provide indication of what is happening or what should happen. The software is poorly designed, for example: limit of 5 characters for description; use of wizard-style configuration which leads to uncertainty about what gets saved. The layout and process for configuring the system has unecessary modalities. Horrible use of javascript for modal dialogs. The main page uses a random assortment of dials and gauges instead of controls and indicators appropriate for the data. The main page has too many superfluous gradients, borders, margins, and other effects that distract from what really matters: the data.

The display unit hardware is complete rubbish. The screen flickers. Battery life is horrendous - we get a few minutes maximum. 300' line of sight is not true. You might get 20 feet if you are lucky. The button is not responsive, nor is it clear how it *should* behave. The device resets itself whenever you reapply power.

The CTs are HUGE. They should be much smaller. Why is there a 4 CT limitation?

The whole thing reeks of amateur software and hardware skills. And clearly whoever responds to support requests has no ability to make substantive changes - the documentation and packaging is a patchwork of band-aid fixes instead of fundamental changes to fix the broken design.

What are the options for power monitoring?

These are our requirements for power monitoring:

• Open data format and open interface for aquiring data.
• The data will be aquired and stored on a linux-based server.
• Per-circuit and/or per-device monitoring, not just whole-house monitoring.
• Infrastructure-based (in the breaker panel), not just outlet-based installation.
• Robust startup/control - must start up automatically after power failures; must not require periodic restarts.
• Must survive extreme temperature and humidity, or survive in a weatherproof enclosure.

These are the options we considered in the Summer of 2011. I really wish we could have tried enersure, but I made multple emails and phone calls to trendpoint and they never responded.