New Home Monitoring –part 2New Home Monitoring – part 2

*********
Notice –the protocol to be used has pretty much completely changed. I am adopting the aProtocol described on the OpenKontrol web site

aProtocol is essentially a hub polling devices,it does allow for devices to announce events but in the main it is polling.
The aProtocol is still work in development,I have joined the team to help make it into a robust home monitoring and automation protocol.
*********

Now that I have decided on the hardware (JeeNode V4 for nodes and Arduino for data logger) I have started to look at the data format and protocols between the nodes/sensors and the data logger. It is clear that there are three basic types of data to be dealt with

a) Current reading (sensor to data logger ). This includes events (e.g. PIR trigger or Battery Low).

b) Totals &counts (sensor to data logger). Note:totals/counts are never cleared down (unless the node is reset),the receiver of the data needs to keep track of the last total and subtract it. This makes it easy to get total for last 15 minutes,total for day etc.

c) Requests and instructions (data logger to sensor)

Low level protocol will ensure message integrity (CRC check or similar). If the sending message requests it then the receiver will ack the message (most messages will not use this – see message descriptions).

Some means to assess transmission quality (number of missing packets) is needed. The low level transmission protocol will send an incrementing sequence number (byte) with every message. Each node will also track the last sequence number received from the data logger. The data logger will keep a table;for every node the last sequence number sent and received will be stored.

The basic mode of operation is that nodes will send out data at predetermined time intervals (say every x seconds – but may differ for some sensor types),if a message goes astray or is corrupted then this is not important and we will get the value next time. Whilst this is not completely accurate (for example for energy readings) in that some values may be lost it is good enough for monitoring purposes. We require to know if some messages have arrived successfully so these will request an ack,(and re-transmission if no ack is received) in these cases the receiver should be able to accept the same message more than once without issues as the ack may be lost.

All sensor to data logger messages will be broadcast (destination node 0) – this facilitates having more than one listener – although only the data logger will ack (if ack is requested).

All messages will be in the following format:12 bytes,human readable ascii to facilitate debugging (32 bit values will be sent as hex). Numeric information will be zero padded to the left (e.g. 123 will be sent as 00000123).
Message Format

Message Types

Some sensor IDs are reserved for special use. These are:(lowercase letters)

Sensor Types