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.