Archived Forum

Certainly, from what you write, the emonTx V2 is more attractive in terms of the availability of I/O pins, than the V3.

As far as analogue inputs are concerned, you are limited to the 6 that the Atmel 328P provides - unless of course you build your own signal conditioning front end to a more powerful processor. For temperature, the DS18B20 uses a One-Wire bus, so many devices can be connected to one I/O pin. I cannot give you a number, it depends on the configuration of the sensor network as well as cable lengths, but it's said to be larger (in number or area covered) if you use the correct external bus driver i.c. There is much data about this on the Maxim website.

The basic Arduino / emonTx with 6 analogue inputs would, I think, be on the edge of acceptable performance. Given that you would be measuring temperatures relatively infrequently, those are not likely to have a significant effect on performance.

You don't say how you intend to measure water and gas. If these are flowmeters that output a pulse at a variable rate, or instruments that send serial data by infra-red or hard-wired connection, then you might find you need a separate processor for that.

How do you intend to transmit and collate the data? That could have an influence on your choice.

Thanks for your input.

I found a portmap for the emonTX V2 (http://openenergymonitor.org/emon/emontx/reference%20).
Seems like there are 4 digital and 2 analog/digital (Arduino PWM) available, for these eventual measurements. 

For the water flow I intend to use what is proposed at http://www.seeedstudio.com/forum/viewtopic.php?f=4&t=989&p=3632 .
The problem is that I require an interrupt pin, which are used by other emonTX functions.
At least there, that would mean a seperate Arduino or use of Raspberry Pi GPIO where multiple inputs.
Gas and HVDC would most probably be pulse based as well.

Data would not be sent via RFM12B in a multi-person environment, for privacy reasons.
Instead I would directly use the emonTX shield in conjunction with NanodeRF/Arduino.
All data would then be sent to a web-hosted emonCMS server.

Another reason for not using radio, especially if you have a large number of data nodes, is collisions in the RF band. The absence of a radio would free up a few I/O pins and an interrupt pin (but only one).

All the analogue pins are available on the NanodeRF, but I've never tried to run the Ethernet stack as well as the energy monitor sketch. If it would fit into memory, I suspect the 'discrete sample' sketches might run when merged with the Ethernet code, but I would not like to say the same thing about the 'continuous' sketches.

I am running a modified version of the continuous monitoring sketch on an Uno +  Ethernet clone which is publishing results using MQTT. This is monitoring 4 CT clamps and reporting all readings. Works like a dream ;-).

http://openenergymonitor.org/emon/node/5922

I bow to your experience.

Hardly! I wouldn't have gotten anywhere without your help and that of Robin!

Thanks! But what I meant was I hadn't tried that particular combination, and while I could not foresee a problem with running Ethernet to send the data between sets of discrete samples, I wasn't certain that there would be enough slack processor time for the Ethernet with continuous sampling. You confirmed that there was. I think I'd seen your post, but it hadn't registered in my brain. So thanks again for chipping in. I'll make a note in my personal FAQ file.

My pleasure - that sketch is now running Robins PV router logic as well and seems to be humming along just fine. Amazing what you can do with those little uP's!

Thank you sumnerboy for confirming that Ethernet and continuous sampling can work at the same time (Ethernet stack as well as the energy monitor sketch indeed just fits into memory of the Nanode RF).
Now I just need to plan my setup in terms of available pins.

Also have some insight when exploring the MQTT module, which I will definitely make use of for remote control.