Thanks @TrystanLea
Key thing is the matrix and. I suggest, common naming.
e.g.
What do I need/what is best to communicate
Right now I have to say it is bewildering and was my reason for starting the table 
Whoops!
I haven’t got an entry for the emonTH V1 in the table! I think the change between V1 and V2 was that the V2 revision adds support for SI7021 temperature and humidity measurement, but the wireless remains the same. So I think the V1 entries in the table will be the same as for the V2.
And … yes …
But JeeLib might not. There were some emonTHs produced with the RFµ module ('328P + RFM12B), which requires a patched JeeLib but is fine with my rfmTxLib and rfm69TxLib. I can’t speak for the LPL.
@Robert.Wall
Thanks for the correction.
Are the RFu module units externally identifiable by the user as such?
Could they be referred to as emonTH V0?
Do any other early devices have RFu modules?
Sorry, I didn’t notice that
Very easily - there’s the main pcb, on it the RFµ pcb with processor, on this the RFM12B.
No, they were V1.4. V1.5.2 had the '328 directly on the main board, according to the schematic I have.
The PCB drawings etc should be in the docs (old or new).
Thanks @borpin I’ve merged the pull request and pulled it through to the docs: https://docs.openenergymonitor.org/electricity-monitoring/networking/433-format-vs-device.html
I’ve updated the emonTx3 entries.
Should we provide these as links perhaps? and rather than available link directly to the firmware?
Thanks.
Was it correct otherwise?
emonTH V1 probably needs adding.
The only issue there is if the FW updates. Link to the folder perhaps and then clarity on the naming convention.
Alternatively, a link to the docs entries for firmware for the device (again naming needs to be consistent).
A link back from each device to this table might not go amis either.
[edit]
Moving this up a level and saying RFM Networking might help users as well.
[edit2]
It need an H1 for the whole page and the H1 moved to H2 for the top section (for the new page)
I will go through this properly again.
Here are the emonPi_CM firmwares (again fairly provisional at this point - though all available from the emonPi update tool):
https://github.com/openenergymonitor/emonpi/releases/tag/16-02-23
both LowPowerLabs and Native variants.
I have made a couple more modifications to the table, I think it’s mostly correct now but is still very much in flux.
The emonTH is running with rfm69TxLib using the ‘native’ message format.
If anyone requires it, it should be easy enough to make the RFM12B transmit using the LPL message format, with a moderately simple change to rfmTxLib, but transmit power will be fixed and it won’t participate in the automatic power reduction nor will it re-transmit a failed message (because it doesn’t receive at all and so will ignore the request).
I’ve added a firmware and configuration page to the emonPi documentation, mirroring the same layout/format as seen in the emonTx3 documentation:
Once Im happy that the documentation and releases are all in place I will do a proper forum announcement.
Credit to @Robert.Wall for most of the work behind this. Robert built the JeeLib Native firmwares and produced the associated configuration documentation. I’ve just made a set of relatively small modifications to enable the use of the LowPowerLabs format and adjusted the configuration documentation a little to reflect this.
There are a couple of things that I need to look at again for serial configuration consistency.
I disabled the ability to change a temperature sensor’s address or position in both the emonTx4 and emonTx3 firmwares (it’s still available in the emonPi_CM firmware). I also changed the api for turning temperature sensing on or off. This resulted from changing the way the serial configuration in parsed, I added more strict checking of command and parameter lengths - but I would like to look at this again as Im sure there’s a way to achieve both and keep a consistent api throughout.
I’ve combined the LowPowerLabs emonTh2 firmware with the jeelib native and classic variants so that there is only a single firmware to maintain. The latest version is 4.1.0 and is available in the main emonth2 repository here: https://github.com/openenergymonitor/emonth2/tree/master/firmware. Again mostly Roberts work on the rfm69n version, I’ve just added #defines to switch between the radio formats, and a #define for ATTINY support.
Latest release: Release 4.1.0 · openenergymonitor/emonth2 · GitHub
Documentation firmware page: Firmware — OpenEnergyMonitor 0.0.1 documentation
Documentation configuration page: Configuration — OpenEnergyMonitor 0.0.1 documentation
Again I will do a proper announcement again, after completing the remaining firmwares.
In the interfacer?
[edit]
Lets not forget those poor folk on a emonTH1 
(it still works )
How about a top level section for Connecting it Together - can’t think of a better title - there must be one
In this include
There is probably quite a bit of duplication, so this could bring that all together.
Just a thought
not forgotten!
no in the sketch itself.
Yes great, will have a think about this.
How about Interoperability?
I’ve been looking at firmware for my emonTH and have just installed Platformio.
I’ve been looking at the Using Platformio page, a couple of observations:
Thanks!
