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.
Energy saving is not just about insulation but measurement and control. This blog documents a project to explore and utilise the XBee to help understand the energy usage in a typical home. By so doing learn Java and take advantage of the rapidly internet of things!
Wednesday, 27 November 2013
Monday, 4 November 2013
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);
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.
Subscribe to:
Comments (Atom)