EpiSensor ZEM wireless meter

Talked to Brendan at EpiSensor on Nov 23:

Meters are calibrated together with CTs for 1% accuracy. They are available in Amperage ratings of 80A, 120A, 300A, and 600A. The CTs are non-shunted, and produce 200mA @ full scale. The CT cables can be disconnected for installation, but different size CTs cannot be used, as the meters are calibrated in hardware (perhaps you could re-scale in post-processing if you were really determined to swap -EJG).

There are 5 voltage leads for a 3-phase meter, including both a neutral and a ground. The node is line-powered by either line-line or line-neutral so it can be used with both delta and wye circuits. It can handle 0-600V gracefully, but needs a separate power source for the node above that (you would also need an electrician with medium-voltage certification).

The nodes can report at up to 1-min frequency over the ZigBee Pro network to the gateway, and the gateway can sync to the server at 1-min frequency. The nodes transmit true power, power factor, and other detailed metrics, but only store an accumulated kWh value (meaning that you would not miss any of the total energy consumption, but would lose the trending activity during the period f lost communication.) On the other hand, the gateway has 160GB of storage, and it archives all data during periods of network outage, then syncs with the server when possible.

The nodes do not have any troubleshooting indicators other than connectivity, and the interface to check the network status and view live data is through the server, meaning that the gateway must be connected before you can effectively start checking an installation. However, there is no licensing fee to run the server software yourself (requires Windows and SQL Server) so I'm hoping it would be possible to run the server environment on a laptop in order to monitor the installation, then connect the gateway to the "real" server if possible and when convenient. I believe there is an annual fee for using their hosted server.

Costs:

$1,000 - gateway

$750 - node @ qty 1 (300A 3-phase ZEM)

$675 - node @ qty 10 (next break @ 100)

$150 - air temp node (also use as repeater)

Brendan also explained that they have seen an increase in sales since Arch Rock stopped offering their (nearly identical) wireless sub-metering product line. Consequently, there is a 6-8 week lead time for their products, as they are struggling to keep up with demand.

My take: as an audit tool the ZEM gains some flexibility over Arch Rock's WattNode-based IPpower meters, as it can handle a diversity of voltage inputs. On the other hand, it looses flexibility by disallowing CT swapping (and spare CTs are much cheaper than extra meters!) The lack of an admin web interface on the gateway is annoying, but might be solved by the local-server hack. Data storage on the gateway is a huge advantage, as it means they can be installed in locations with no network access. I'll need to check out the server interface to get truly excited about it, but it sounds like a fairly useful system.

Wrapping up MATLAB/LabView Problem

So here is some final thoughts on the problem of compiling MATLAB code into C shared libraries to use with LabView; before I forget about it all now that I decided to stop worrying about it:

- The first problem is that Matlab uses a custom data type called MxArray, and one needs to create a wrapper function that takes in standard data types (doubles, integers, etc.) and calls the appropriate Matlab compiled functions with the arguments passed as MxArrays.

- After creating the wrapper, you can re-compile it all to end up with a .dll and a .h file.

- These files can be used with the function library node sub-vi in LabView, and the appropriate functions should show up. However...

- The first function to call is one that loads the global MCR (Matlab Complie Runtime or something similar), which should only be stopped after one finishes using any Matlab libraries.

- Then one can call the set of initialization functions for each matlab function complied into the shared librarry. After initializing, one can call the excecuting function, and lastly the terminate function. The initalization/termination funciton basically create a new local MCR instance for each one.

- The last step is to call the global termination, to stop the global MCR.

- This all sounds fine, until you start implementing it. It is just a PITA to get it working.

PHP server setup status

I've been trying to get the server running with the energy data visualization code I've been working on. it has not yet been a success, but here's my progress so far:

I could not get the installed version of php working with apache, though i added the necessary directives. There was no module binary for php in the apache/modules directory, but I found one elsewhere (in the php installation dir). However, that module threw some error about "garbled module" when I tried to restart the apache httpd server (using apachectl).

Next plan: install a fresh version of php which will be able to compile the module from source. Downloaded php 5, but it didn't like apache's apxs library. Then I downloaded php 4, removed the currently installed version of php 4 (using RPM) and tried to build the module. It complained that if I didn't specify a path to the mysql directory, other apache modules might not be able to access the mysql database. This might be a problem, but it's one for another day. I compiled the module, and was able to restart apache and get a php file to load properly - yeah!

However, the database code did not work; it just threw an error about not being able to connect to localhost as daemon@localhost with no password. When I explicitly included the link_identifier in the mysql_select_db function, I instead got this error:
"Client does not support authentication protocol requested by server; consider upgrading MySQL client"

I suspect that the final solution may include removing the RPM versions of apache and mysql and compiling everything from scratch. Or move the project off of cee-landscaper and onto sensor2.andrew and see if the default installation is wprking any better over there...

Compiling Matlab code into Shared Libraries

It's been a long time since our last post. Many things have happened since, and even though we intended to use this blog as a progress report log, I am starting to realize that it will be more similar to a "Lessons Learned" kind of log, at least during the early stages.

Today I spent a few hours trying to get some .m files working in LabView by compiling them into .dll shared libraries, and importing them using the new Shared Library Import Wizard that came out on v8.2 of LabView. Read lots of forum threads, and spent some time staring at the command line prompt.

So far, I've managed to compile the code by using the following:

mcc -a neededmatfiles.mat -W lib:libraryName -T link:lib filestocomiple.m

This results in a .dll and some other necessary files.

It turns out, however, that the choice of compiler (which can be configured using "mbuild -setup" is an important one. The Lcc-win32 compiler that comes with Matlab doesn't seem to be doing the work, and I've read on some forums that the Visual Studio 7.0 compiler is our best bet. So now I'm looking for a computer with it, since the "free" student version (DreamSpark) is not so easy to get.

Update (06/06/08): I might have found the solution here:
http://forums.ni.com/attachments/ni/170/7347/1/dllmatlablabview.pdf

Google Alerts and Current Transducers

I have a Google Alert for many different things. One of them is set to look for electricity monitoring devices or news. Most of the time it brings up automotive related things, but many others it shows links to interesting webpages.

Today it brought up this not so good article "How To Find The Best Green Gadgets", which in itself has a link to the Efergy smart meter.

Looking at simple technologies like this, that are only measuring current, and pairing it up with the harmonic analysis we are starting to perform on the current waveforms, I start to believe that there is hope for doing good classification of appliances with this simple to acquire data.

Categorization algorithms, take 1

With data in hand (66 events over 20 minutes from one data set with RMS volts for normalization purposes) we started post-processing the data. This will convert the raw values (of power, reactive power, etc.) to more useful metrics (of delta power, delta reactive power, etc.).

Step one was to map the human-tagged events to more precise timestamps based on transitions in real power. We took the set of all events and selected the nearest timestamp with a change in real power of greater than 5 watts, provided it was less than 4 seconds away from the event. This did a nice job of locating the events at a more precise time relative to the actual change in power, since the light switch and LabView click are not quite synchronized.

Next we wanted the changes in real power at each one of these event times. The sample rate in this data set is 20 Hz (50 ms intervals) so it's not helpful to look at inter-sample changes (though the rate of change might be useful, this method is both susceptible to noise and also will fail to capture the full jump from off-power to on-power). Instead, we discovered (with a little trial-and-error) that averaging the power from all samples in the interval 4 seconds before the event and calling that the before-power, then subtracting the after-power averaged from the 4 seconds after the event gave reasonable intervals. It was able to absorb relatively short start-up transients, but the microwave has a transient with a large spike, then a more gradual descent down to the steady operating power. This resulted in a start-up power change of +300W but a turn-off power change of -90W; reliable for comparing among on-events, but not so good for pairing on-events and off-events.

While none of the appliances we have been testing so far have similar real power consumption, we noticed that the difference between the high and low states of the fan was about 10W, similar to the difference between the on and off states of the CF bulb. We hoped that using reactive power as a secondary axis would help to differentiate those two events, as it did for Hart (1992). However, when we applied the same transformations to the normalized reactive power metrics, we found little correlation between delta-Q values within events of a given appliance transition (eg. fan changing from high to low). In fact, for the incandescent lightbulb on-to-off transition we saw +3W twice and -12W once! Investigating this oddity (and remember that such a resistive load should effect no change in reactive power at all) we discovered that the -12W delta Q transition occurred during a microwave on-cycle. This produced about 40VAR fluctuation in reactive power, so the changes we were seeing were entirely due to the microwave noise, not the light turning off.

For harmonics we are starting to filter the extracted tones to exclude frequencies outside of +/-15Hz of the 1st, 3rd, and 5th harmonics. Then we will look at the normalized 3rd and 5th (e.g., the ratio of the Nth harmonic to the 1st, or fundamental frequency) and the changes to those values around the event times. So far it is clear that some of the harmonics drop out entirely during periods that are visually correlated with certain appliance events. Hopefully the harmonics will help us to filter out some of the noise as it has helped others to isolate continuously variable loads.

More begets Onzo

More Associates has worked with the UK Design Council on energy use visualizations, and done some damn cool stuff. They have recently spun off Onzo, which is about to commercialize a home appliance for the same purpose. 

We should give them a second look. And a call. They might have some hardware for us to play with.