Looking at the various code samples for emonTx/base/lcd it all appears very hard coded at the moment.
I'm thinking the base should accept readings/commands from the sensors and also be able to transmit computed/summed values over to GLCD for display, but I don't really like the idea that you have to keep changing/compiling the code base everytime you deploy a new sensor.
Support for multiple emonTx devices seems non-existant as well.
Whats the direction for development for the protocol for these devices to talk together?
I think the directions are:
1) have two DIP switches implemented in the future emonTX-es for address configuration and enabling the different functions (i.e. CTs, one wire port, pulse port, AC port). these can be hooked to a single analog input using similar to this approach: http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1267115381
2) have the emonTX send a payload structure like this:
byte 1: payload type identification byte : lets say CT1 raw reading
byte 2: number of data bytes to follow : 2
byte 3 .. data
byte 4 ... data
byte 5 payload type identification byte : VCC battery level reading
byte 6 number of data bytes to follow : 2
byte 7 .. data
byte 8 ... data
byte 5 payload type identification byte : 0xFF : stop further processing, this is the last in the chain
These can be chained and a 0xFF may mean LAST. as part of the payload, the bits of this identification will specify what the emonBase should expect to find in the payload. Types will be like:
a) CT1 reading (raw)
b) DS18B20 reading (discover automatically all connected temp. sensors)
c) VCC reading (battery)
and so forth
The calibration for each emonTX ID should be done on the emonBase via WEB UI
Processing the RAW emontx values should also be done on the emonBase
these are just quick ideas
Yes, like the idea, who's going to build it?
Perhaps using a standard protocol (just over the RFM12) would be a good idea, saves re-invent the wheel and all that.
I am building it, it do not need dip switches as the will be id confirable by net.
check out https://github.com/pcunha-lab/emonTxFirmware/tree/master/emonTx_Interrupts
I am mobile now, later i explain better.
I wonder if implementing MQTT-S would be a better solution in the long term, allowing auto discovery of sensors and emonBase becomes a MQTT-S "gateway"?
I like the MQTT idea also, check out a paper that I found on the subject being discussed:
Open-source tools for energy monitoring and analysis. This project uses the GNU General Public Licence