Thinking about the problem of having lots of sensors spread over the house all talking over RF12B modules to a single central emonBase (or Rasp PI etc.) and how they should all interact.
I'm liking the idea that they could all use the MQTT-S protocol, http://mqtt.org/MQTTs_Specification_V1.0.pdf
which is designed for this type of scenario (only using ZigBee modules).
However, I'm also thinking that the sensors should just broadcast what they are monitoring and then let the receiver interpret and do what it wants with the data (not always just blindly upload or display on GLCD etc.)
You could for instance have a couple of sensors against your hot water tank or solar tube, central heating pipes etc. all sending temperature data along with a description/code of what the data relates to.
This way, if there is 1 or several sensors, it doesn't matter to the receiver, its simply listening for packets to arrive and doing something with the data.
Don't think I'm explaining this very well :-)
Lets go with an example, the data "packet" could have a two bytes (16 bits) to start indicating what the value relates to
The "A" could be the sensor type (range of 4096 values) and the "B" bits (16 values) the measurement type/scale for instance
"A" values could be:
and the "B" values could be
The next few bytes could then contain the reading/value, along with the time/date taken (linux timestamp?) if available.
Probably needs a packet length byte in there to help processing.
Once this is done, any new sensors coming on board are automatically known to the emonBase and it can start "doing stuff" with the values its receiving without additional coding.
Additionally, new devices can simply listen for the relevant packets they want for instance the famous solar power hot water heater problem, could listen for exported power data packets, along with temperature of the hot water etc.
Open-source tools for energy monitoring and analysis. This project uses the GNU General Public Licence