Small enhancements to file naming and recording

A few posts ago I set out the design objectives for the software development and this included things like recording the results in a database. Well those objectives are still there and look achievable thanks to sites like the Java tutorial site Home and Learn.

In the meantime I've decided that structuring the output for the spreadsheet app provided by Google would be a good idea. This is available free to everyone with a Google account and it's companion software provides graphing which takes care of the visual presentation of the results.

With this software in mind the results gained from the logging node(s) will now be saved in files created each day with the date as the name.  So the latest version of the logging software has implemented these requirements and can be found here. (Unfortunately, there is a bug to be sorted and that is the fact that the date doesn't update from the first time it is is returned from the Date function. I'm sure it's a simple problem arising from my lack of Java expertise).

The software that has been developed is almost usable for simple applications like degree day calculations and fuel monitoring but my ambitions are much greater than this. The reason for this work was the the work on energy saving measures on the project house but these ran into problems when analysing the effects as things such as the weather. A task that requires simultaneous recording from multiple nodes. Ok instrumentation exists that I could buy but I can't afford this and anyway the knowledge gained should be valuable. Especially if it develops into control and perhaps assessing and integrating products from other sources.

Consequently, the next development of the software will receive the readings from a logging node over a specified time interval, average them if necessary and then record the average for the time period for each node to file. This will allow measurements from multiple nodes to be easily graphed and compared easily.

Logging Readings to File

Progress is being made albeit slowly due to time constraints.

The basic program that obtains a temperature reading from the Xbee has been modified to

Include the system message logging output configuration in the body of the code.
Record the system message output in a log file.
Record the temperature readings in a file.

It's not in anyway refined at the moment. Just enough to test the code and my Java programming. The code can be found here.

The next objective is to further develop the log file recording for the Xbee measurements. The measurements will be stored in a file per day. The readings will be written with a specified frequency such as once every half hour or hour. If readings are being received more frequently they will be averaged over the period.

An Overview of the Basic Temperature Logging Code.

It's been some time since my last post so in order to pick up from where I left off here's a very brief overview of the cutdown version of the software used to communicate with the remote XBee with the TMP36 temperature sensor. The software code to which it refers can be found here.

It doesn't explain the intricacies of the object hierarchy being used to communicate with the XBee although this is important. This documentation can be found here. In brief there is an object class called Xbee which is used to communicate with the Xbee module. Then there are a set of classes that model the data packets returned by the XBee. The classes are often hierarchical and designed to make it possible to drill down into the returned data.

And so to overview of the software code.

Tell the compiler where to find the software classes referenced in this program. (import statements)

Create an object that represents an XBee module.(XBee xbee = new XBee();)

Display a window to communicate through. (although logging is output to the console as well).

Create a font.

Setup the logging and output to the console.

Open the serial port to the Xbee connected to the computer that will communicate with the remote battery powered XBee. (xbee.open(mySerialPort, 9600);)

Put a grey background on the window

Create an object to store the data returned from the XBee and the address of the sending XBee. (SensorData data = new SensorData();)

Wait for a response from the XBee connected to the computer.(XBeeResponse response = xbee.getResponse();)

Check the response is a packet carrying data from a remote XBee.(if (response.getApiId() == ApiId.ZNET_IO_SAMPLE_RESPONSE  && !response.isError()))

Get the address and save it.(int[] addressArray = ioSample.getRemoteAddress64().getAddress();)

Get the data and save it.(value = ioSample.getAnalog0();)

Convert the voltage measured by the remote XBee from the TMP36 into a temperature.(float temperatureCelsius = (data.value-500)/10;
)

Go back to waiting for a response and do it all again.

Property Files and Log4j Logging Facility

Isn't it irritating when documentation suggests that a subject is easy but for some reason you can't quite understand it. Well that's how it's been with Log4j, the logging facility being used to debug and understand the temperature sensor code. But now I seem to be getting my head around it. It's important because communication with the XBee's can be quite involved and so a facility to examine the dialogue between nodes will be important. So what have I been struggling with?

Well first of all I've been missing a general description of how the operating system interacts with Java and Processing. By that I mean the reporting of errors and events used by Log4j. I still haven't got a detailed handle on it but probably good enough for now.

I'm familiar with a facility called Syslog which is to be found in many operating systems and in particular Unix (where I think it originated from). Syslog is an operating system process that aggregates  messages generated by the many and various processes running simultaneously on a computer. The output of Syslog is usually collected in a file and the messages are categorised into levels TRACE, DEBUG,  INFO, WARN, ERROR, FATAL. I've never thought about how these messages are generated until now.

Not surprisingly it would seem that the authors of the operating system processes include the messages in the code and assign them to the above categories. These are directed to a logging process, in this case Syslog,  where they can be output and filtered as required. Well this is how Log4j would appear to work.

This is the code to be found in Code02

Properties log4jProperties = new Properties();
  log4jProperties.setProperty("log4j.rootLogger", "ERROR, myConsoleAppender");
  log4jProperties.setProperty("log4j.appender.myConsoleAppender", org.apache.log4j.ConsoleAppender");
  log4jProperties.setProperty("log4j.appender.myConsoleAppender.layout", "org.apache.log4j.PatternLayout");
  log4jProperties.setProperty("log4j.appender.myConsoleAppender.layout.ConversionPattern", "%-5p %c %x - %m%n");

  PropertyConfigurator.configure(log4jProperties);

The first line creates a new Property object log4jProperties. The Property object is used in Java to make configuration tasks easier. For example it's commonly used to load and save program preference settings. Equally it can be called on to configure Log4j and probably in the future the settings for the project code.

log4jProperties is then loaded up with settings for Log4j using the setProperty method. Finally the property file is passed to PropertyConfigurator via the configure method to configure and start Log4j.

Encoded within the XBee support software being used by the software i.e.

import com.rapplogic.xbee.api.ApiId;

import com.rapplogic.xbee.api.PacketListener;

import com.rapplogic.xbee.api.XBee;

import com.rapplogic.xbee.api.XBeeResponse;

import com.rapplogic.xbee.api.zigbee.ZNetRxIoSampleResponse;

are messages that are output to the Log4j process. As configured above, all messages up to ERROR will be output to the Console (log4jProperties.setProperty("log4j.rootLogger", "ERROR, myConsoleAppender");)

creating an output as follows

INFO  com.rapplogic.xbee.api.XBee  - sending packet to XBee 0x7e,0x00,0x04,0x08,0x01,0x48,0x56,0x58

DEBUG com.rapplogic.xbee.RxTxSerialComm  - serialEvent: 11 bytes available

DEBUG com.rapplogic.xbee.RxTxSerialComm  - Ignoring serial port event type: 1

DEBUG com.rapplogic.xbee.api.InputStreamThread  - About to read from input stream

DEBUG com.rapplogic.xbee.api.InputStreamThread  - Read base10=126,base16=0x7e,base2=01111110 from input stream

Changing ERROR to one of the other levels enables the output to be filtered accordingly and in fact this facility can be extended to filter by object class and much more.

So with the logging facility more or less understood the next step is to start looking at getting data from the XBee node and process the results. 

Log4j Configuration Now as Part of Code

I've chosen to move the configuration of the logger, log4j, into the code and not use the log4j.properties file. However, this is only a temporary move for ease of management. When the code is 'finished' the configuration will be moved out again into the properties file where it is best kept.

Looking ahead, familiarity with the property file usage is likely to be important. It is envisaged that a property file will be used as the means of configuring the software and by so doing avoid having to create a configuration entry form.

The reference source for the in line configuration was found here.  

http://www.avajava.com/tutorials/lessons/how-do-i-configure-log4j-with-properties.html?page=1

The modified code can be found here.

Problem Locating log4j.properties File Now Fixed.

The problem with log4j finding it's property file in Processing has now been fixed.

log4j wasn't finding the file because the value passed by the dataPath("") statement doesn't include a closing \ character. The simple fix is to append it to the file name. Therefore the command becomes

PropertyConfigurator.configure(dataPath("")+"\\log4j.properties");

(The double \\ to print a single \ is required by java because a single \ has other purposes and can be read about here).

Stripped Down Version of Code

The initial code contains graphics that I don't envisage using and tends to over complicate. So the stripped out version can be found here.

Although it works it highlights the next area of work. That is the logging facility. This allows debugging to a very detailed level and I'm sure it will be invaluable later. However, as currently configured it outputs too much information. It's controlled by a configuration file so the entries in this file will have to be investigated.

Starting Point For Coding

I've got some experience of program development and object orientated coding but not Java. So I'm using the code published by Rob Faludi as my starting point. As pointed out in earlier posts it's Java but within the more comfortable development environment called Processing.

It's definitely a jump into the deep end but I guess that's inevitable given the scope of the project. The code which can be found here has some comments to help understanding provided by Rob Faludi and I've added some more in red. Hopefully, my comments are broadly correct!

Design Considerations

Although the immediate objective is to get one node up, running and logging it’s important to try and assess where the project might go next. It’s particularly true of programming in order to save much time consuming software rewriting and to ensure the programs have a suitable structure.

So what follows is a short analysis of the project

What: To measure and record the temperature at a location.

From this simple statement a surprising number of topics arise.

measure	Units	Celcius
	Accuracy	0.5 deg
	Device	XBee node identifier
	Frequency	variable
record	Data storage system	Could be a simple flat file or a relational database system
	record specification	date, time, temperature
location	where	node location

So, looking at the table above, the measurement process encompasses the TMP36 sensor, how it is to be used in practice and the XBee’s analogue to digital conversion(DAC). Then there are the calculations to be performed on the returned data to convert a voltage value into a temperature. Also, if 0.5 degrees is chosen as the required accuracy then this needs to be checked against the TMP36’s sensitivity and XBee DAC conversion process.

In terms of recording the data then it’s important to record more than just temperature. It’s important to know when and where the temperature was measured and probably by which sensor.

Looking ahead, if the project continues, there will be multiple sensors of various types and this suggests a structured database rather than a separate file for each XBee node (or measurement point since an XBee has multiple inputs). (The open software MySQL looks a good candidate for a database solution especially since there is good documentation for using it with Java).

Why: To correlate the effect of temperature on energy consumption

The main objective of the project is to measure, record, compare and analyse. With two sources of data this will not be so hard but it can quickly be envisaged that if the sources of data grow in number, the data will have to be saved and structured in a very flexible and organised way.

When: For specified periods of the day

It is anticipated that the measurement process will be continuous and the specified periods of interest will be selected at the time of analysis from the recorded data.

Where: Inside and outside

The most obvious temperatures to measure are inside and outside but this could, for example, be as varied as a pipe temperature or air temperature. This highlights that multiple nodes will be required. (No problem because an XBee network can in theory support over 4 billion nodes). But it also raises questions about construction. If a node is outside it will need protecting from the elements. Not a programming issue but very important all the same.

How: Using a wireless network.

At the moment the wireless network will be using XBee’s. But as mentioned in previous posts there are alternatives that could be much less expensive. With that in mind it might be wise to keep the software interface that collects data from the nodes as modular as possible. Being wireless also implies battery powered and battery life will be important.

XBee’s do have a facility whereby they can sleep and use minimal power but to use this facility requires configuration.

Preparing the Xbees

This purpose of the blog is to document my work on managing energy usage around the home. At the same time I'm also learning how to harness the potential of the incredible range of low cost devices which enable computers to interact with the real world. But there is a massive amount of information to sift through and decisions to make so these posts document the course taken and where possible share my findings. So, back to the work in hand.

Having obtained the XBees and extras to connect them to a PC and power supply etc,  it's necessary to prepare them. This is especially necessary because they are capable of working in a variety of ways and is the reason why they may appear more expensive that similar devices.

For example, they have the capability to form a complex wireless mesh network and this requires the nodes within the mesh to adopt specific roles. Hence they need some initial configuration to set up the role they will be performing and this applies even in a simple point to point application. The roles are co-ordinator, router or end node.

The method of doing this is explained in detail in  Building Wireless Sensor Networks by Robert Faludi and I would expect on the Digi web site.(although probably not as succinctly!). It's not a complex process but too detailed to cover here. It requires some support software from Digi, who manufacturer the XBees. This software can be found here. This software downloads the firmware to the Xbee as required by the role it is to perform.

A Valuable Resource - Building Wireless Sensor Networks by Robert Faludi

The technical content of a wireless sensor network is immense because it spans electronics to software development. So without guidance from others my work would be impossible. Although there is an amazing resource on the web I decided I needed a book and that was  Building Wireless Sensor Networks by Robert Faludi.

It's an invaluable aid, was the starting point of my project and is a constant reference.

The Software Environment

Before starting this departure into developing my own data collection and control tools I looked around for available products. There was plenty of activity in the energy management field but nothing that quite fitted. I wanted a toolbox not a particular solution and so that's what the work is about. So, the first objective is recording outside temperature in order to produce degree day data to correlate against gas consumption.

Processing

Processing has been chosen because it is Java based and therefore offers portability between platforms. If all goes well this attribute will make the move onto a Raspberry Pi running Linux easier in the future. But for now the development is taking place on Windows.

Processing was chosen for the reason that it attempts to simplify the software development process and is well supported. In particular, with respect to the interfaces between program and sensors, program and user. These tend to be very technical areas and so any simplification is welcomed.

Processing is available at www.processing.org

XBee Libraries

Work of this type is not possible without a great many clever and generous people who make the very technical areas accessible to others. By that I mean Processing and the software libraries that interface to the many and various bits of hardware. Without this software the hardware would be unusable to all but the very expert who program at machine level.

For this project the functionality of the XBee electronics is made accessible through the XBee libraries obtained from  http://code.google.com/p/xbee-api/  

So with those two free downloads development can commence!

Components

A description of the components being used was posted in March. Here's a list just to recap. The supplier was Proto-PIC

PC Unit

XBee 2mW Series 2

XBee Explorer USB (in case)

Remote Unit

XBee 2mW Series 2

XBee Wireless Shield

Temperature Sensor, TMP36

Battery Holder, 4AA

JST Jumper, 2Wire

Reverse side of shield showing clearly marked connection points

The wireless shield is the small circuit board with headers to accept the XBee. The shield provides the power regulation and means of connecting external devices. However, this is where some challenges lie for those not so familiar with practical electronics(myself!). The first challenge is making connections.

A battery holder was chosen with a terminated lead. That is a "polarized termination, square configuration plug" on the end of the lead.  Therefore, by soldering a 2Wire JST Jumper onto the shield connection to the battery was made more convenient. An alternative could have been to solder the battery lead directly onto the shield but the plug approach allows for a certain amount of future reconfiguration.

Finally, the PC to which the XBee Explorer is connected is a standard Vista laptop with USB port. The PC can be of very modest specification and originally I was using a very old XP laptop which was OK but because it was slow booting etc I decided to use another PC. 

Project Environment

The initial evaluation pointed to the Raspberry Pi and JeeNode devices as the development platform. However, because I already have a Windows PC and two XBee modules then these will be the starting point. This might seem a complete contradiction but for the following reasons.

• The development environment will initially use Processing which is built on Java
• The objective will be to use Processing as a learning tool only
• The approach will be modular to allow for future changes 

Since Raspberry Pi is supports Java it is hoped the future migration will be away from Processing into a more generic Java framework. (I could be underestimating Processing).

A swap to JeeNodes or even something else will be possible if a modular approach is taken.

More information on Processing can be found at www.processing.org

A Project Overview

Previous posts have already outlined the basic components of the project. Namely the XBee to remotely obtain temperature data from a TMP36 sensor. However, the overall goal for the XBee is as follows.

The requirement is to be able to automate temperature and gas consumption measurement. The former task being the easiest and so is the starting point.

The objective is to be able to routinely collect data such that, for example, outside and inside temperatures can be easily correlated against energy consumption. Once collected it can then be analysed and presented in an informative manner. The system for doing this must be wireless and the sensors must be battery powered. Ideally the central recording unit will be capable of being remote from the sensors i.e. capable of using the internet for connectivity.  

Work recommences!

The purpose of this blog is to look at practical energy saving issues associated with everyday living. However, this is a large subject area, too much for one person to cover, and so some focus is needed. So at the top of the priority list is the need to identify areas that make significant financial savings with the minimum investment.

Needless to say some of the greatest outgoings are associated with the home. So that remains the focus of the blog and I have used my very typical home in the east midlands as a case study and recorded my findings in a web site www.conserveandsave.co.uk.

As the work progressed it became apparent that significant losses were being incurred through some surprisingly easy to fix sources. However, in general they were not obvious sources and were only discovered as a result of the detailed scrutiny resulting from the project. For most people these areas of energy inefficiency would go unnoticed. So how could this situation be remedied?

One way of doing this is measurement and controls and I drew comparison to my car which achieves significant efficiency gains over older models by virtue of the electronic engine management. Now a standard part of even the cheapest car, the ECU  measures multiple parameters thousands of times a second to provide just the right amount of fuel for any given situation. How different to a house! In comparison the majority of houses are primitive, often having only bi-metal strip room stats and no accurate means of measuring and controlling the energy flow.

Consequently, the focus of work has begun to look at measurement and control. Accurate readings were required for the work on the project house, in order to measure how efficiently the energy was being consumed. Unfortunately, this relied on readings that were impractical to obtain on a routine basis which led to interest in automating the process. This is why the following posts will be quite heavily devoted to this subject.

Work temporarily suspended. Moving house!

For those following this blog then apologies for the lack of recent activity. I'm moving house but progress is hoped to continue soon.

Making a start with XBee modules

After careful choice my decision was to go for JeeNodes and Raspberry PI. Well I've started with the X Bee wireless modules! The reason being that I'd already bought a pair some months ago so rather than waste the money I'm going to start with these. It shouldn't matter too much if I design the software to be modular and allows for these to be swapped out at a later date. The image shows just how tiny they are.

XBee2 wireless module

However, to make use of them requires a power supply and an additional device to measure temperature. The operational, wireless temperature measurement XBee is pictured below.

XBee with power regulator and TMP36

Unfortunately providing power is not as simple as connecting a battery. A stabilised power supply is required and is provided by a small voltage regulator. The XBee is plugged into a socket on this device which converts the 6V from the battery pack into 3.3V required by the XBee. It also provides a means of connecting external components like the TMP36 temperature probe. This tiny probe outputs a voltage that is proportional to temperature that the XBee measures and transmits back to a base station. Here is the base station XBee.

XBee with USB connection

This XBee is fitted into an adapter that provides a USB connection for communication with a PC and  enables the many facilities and capabilities of the XBee to be configured.

The world of wireless devices seems to be going through rapid development at the moment and the choice of devices certainly becomes wider by the day; partly as the technology develops and partly as my knowledge expands. For example, the XBees cost approximately £20 each but when browsing the Maplin site these devices were found at £3.99. They are by no means the equal or same as the Xbee of JeeNode but they could possibly be useful for some very low cost applications.

Then there are products like the Sensor drone which could be a platform for future work and the RFduino which packages the Arduino with Bluetooth into a tiny package.  And these introduce the topic of which wireless technology to use. Whereas the XBee uses the same wireless spectrum as WiFi, the JeeNode uses another. Fortunately, they all tend to have their niches and a sophisticated system will probably incorporate several of them.

Raspberry Pi is the platform of choice.

Although closer to a decision on an energy monitoring system for the project house the more I research, the more I discover alternative solutions!  However, the JeeLabs JeeNode still looks favourite for the remote wireless data logging devices. The basic cost is approximately 18.50 euros but to this must be added a few extra components such as a case and battery supply. The next step is deciding on the central management system which appears to be a choice between an Arduino or Raspberry Pi based system. Both have their advantages and disadvantages. The requirement is to log readings, record in a data base and process to calculate such information as degree days from the raw data. Also important is the ability to manage the system remotely, via a browser if possible which implies TCPIP network connectivity.

The Arduino is a very popular platform designed specifically for interfacing with sensors and for controlling external devices. It is programmed through a special program, an integrated development environment (IDE) that runs on a PC. Overall very good for dedicated control applications with a large user community but I think want more flexibility than that. 

The Raspberry Pi, on the other hand, is a more general purpose platform. It runs Linux which is an operating system that is used extensively for commercial IT systems. It is a computer that can be both a development and operating environment in one and so doesn't need an external IDE. Overall, it probably has less support currently for control and management applications and looks more complex to program. That said, support information and products for the Raspberry Pi monitoring system have been found so the convenience of everything in one low cost unit is the deciding factor.

Despite an extensive range of available products one area that does not seem well covered is the packaging of the various electronic devices. The electronics will need housing in suitable cases. One intriguing solution that was found was to convert an Airwick room freshener to house a JeeNode. Details can be found here.

My automated energy monitoring requirements.

I've spent the last few weeks searching the internet for solutions to my automated monitoring requirements and, as is so often the case with the internet, have been overloaded with results. As with anything IT the pace of change is staggering and it's easy to get side tracked, especially by the emerging technologies So I've got to be quite clear and focussed in what I want.

This is what I think I need!

Temperature Sensors
Two wireless temperature sensors; one inside and one outside. I want them neatly packaged, battery powered and at least one will have to be weatherproof.

Meter Reader
A device which can read a conventional gas meter. This is quite a problem because it has to either read the digits or count the revolutions of the red pointer. Devices like this do exist but it has to be affordable

Data Logger
I need a central system to collect the data from the sensors. This could be my PC but that gets switched off and on. So practically, it has to be an independent system.

Firstly, of the many solutions available they categorise into commercial and private (not amateur because the knowledge level encountered never ceases to amaze me). Now the commercial solutions tend to be expensive whereas the private ones were ultra low cost but required packaging. As this energy saving work is a non commercial venture the private solutions are certainly the most attractive if the packaging problem can be overcome.

One of the most appealing solutions is offered by The Open Energy Monitor Project but I also like the approach of RFXCOM.

The Open Energy Monitor Project is based on an open, collaborative hardware and software development philosophy which has to be attractive but the building blocks may require me to have a little more equipment than I ideally require. But the prices look really affordable.

On the other hand RFXCOM has perhaps a more commercial rather than collaborative bias but have specialised in interfacing to mass produced products from other manufacturers. One example are Oregon temperature sensors which because they are mass produced are inexpensive and packaged for the consumer market.

Further considerations relate to the wireless standard to adopt of which there appear to be competing options. The other big decision is the choice of data logger. Should it be Arduino or Raspberry Pi based? Time to do more thinking and research.

Automating the meter reading process

My pre-occupation to date has been with monitoring and saving the energy used for heating. The reason for this is that I want a comfortable house to live in but at the same time relaxed in the knowledge that no energy is being wasted. As I've found it's not easy to identify where the heat energy is going. I'm leaving electricity monitoring until later because I consider this to be more straight forward and a lot about the self discipline of switching things off. And because it's winter it's much worse to be cold than, say, in darkness!

I've made considerable progress in demonstrating that a lot of valuable information can be extracted from some simple measurements. Information that can be used to make informed decisions to invest hard won earnings. However, the problem I'm now experiencing is that my manual observations are too labour intensive and contain inaccuracies. I now need to automate the process so that they reflect changes such as the boiler controller being manually overridden  or the room thermostat adjusted.  The graph of gas consumption vs degree days (difference between inside and outside temperature) illustrates this.

In a simple world heat loss is directly proportional to temperature difference and so the graph should be a straight line. In the real world wind makes a difference by creating ventilation losses and lowering the insulation value of the walls. And there's also heat gain from the sun etc.

It certainly looks possible to put a value on these effects and by so doing estimate the value of controlling ventilation losses or applying a wall treatment. (reference to earlier post). The trouble is much of the scatter in the graph is from the reading errors and hence the need for some automated help. I'm hoping that implementing an automated system wont be too difficult because there appear to be a number of expert communities on the internet developing some very promising systems. Here's hoping I can find something affordable and usable!

Why a house should work more like a car!

Alongside my energy saving work I've got problems with my car that's caused me to study in more detail how a modern car works. The problems I'm experiencing relate to the electronic management of the engine but it's occurred to me how the homes we live are years behind the technology used in most of the cars we drive every day and take for granted.

A modern car uses a wealth of sensors to gather data from many parts of the drive, chassis and engine components to make sure it is running safely and efficiently. For example, the engine management computer, in order to optimise efficiency, measures parameters such as the air flow entering the engine, the inlet manifold temperature and its pressure many times a second to control the fuel flow, turbo pressure and recycled exhaust gas . The electronics and components to achieve this are cheap and mass produced. So if this advanced energy saving technology can be applied to even the most standard of cars I'm sure similar systems would make a significant contribution to energy usage in homes.

What do smart meters offer the consumer?

I've just visited an elderly relative who has just had smart meters and the obligatory table top display installed. Now if you can detect a slight tinge of scepticism in my writing then you're right. So why do I feel like this?

Well I'm interested in smart meters because my energy and cost reduction work at home (documented at  www.conserveandsave.co.uk) requires me to take daily readings from the gas meter. It would be so much better if I could automate this and a smart meter would appear to be the answer. My expectation has been that these meters will have an interface that is open for use by the consumer but I'm confused and a little dismayed by my first research.

I may have misunderstood what I've read but the initiative seems to be focussed towards the energy supplier. With respect to the data from the meter it will be communicated to an independent company that will disseminate the data collected to authorised organisations. I couldn't find any information regarding an open interface from which I could directly obtain consumption data. (I hope the intention is not to have to apply to access it via the internet from this company!) However, the mechanism for local access must be there because it is being used by the table top display. It's not a revolutionary concept either. Since 2000 it was introduced in cars which through legislation must include a standardised open interface from which data such as engine temperature, speed, fuel used, fault codes etc. can be obtained to check correct operation and efficiency.

I hope my fears that this initiative is founded on bureaucracy and big business is ill founded!