In that case, you can do either setup (emonPi + TX, or 2xTX).
To hardwire the system, use a Pi(s) serially connected to the (or both) emonTX(s).
I’d be inclined to use the emonPi Solar Bundle with AC PS (you can choose to use your own 5V DC supply). That bundle comes with 2CTs, you can use the second CT on the emonTX. Also get an emonTX (with AC PS - DC same choice) serially connected to one of your RPis (all you need is to make a short cable or use breadboard leads).
Thanks guys for your advice, being a skinflint, could I just use two emonPi - Raspberry Pi Energy Monitoring Shield Add-on KIT(s) on my existing RASPI’s?
My shopping list would be:
2 x emonPi - Raspberry Pi Energy Monitoring Shield Add-on KIT
2 x CT’s
2 x Plug in VT’s
2 x emonSD - Pre-loaded Raspberry Pi SD card
I already have suitable 5V 2.5A RASPI PSU’s, and RASPI Model 3 B+ (s)
If I install one system in the Shed on the solar AC output, and one at the consumer unit, then connect the two RASPI ethernet ports back to my server/router I assume I can then use Emon CMS to provide the web based GUI - All for around £100 - Thoughts?
Yes is the short answer - note there is no case for that shield.
You will need to set it up so that one is a ‘master’ for storing and visualising (though actually you could do it both ways for data replication). Come back when you have them to walk it through.
Do you mean 2x AC/AC sensor to confirm power flow direction?
I often call those v.t’s - voltage transformers - to differentiate from current transformers. Never to be confused with a c.t. that has an internal burden and outputs a voltage, that is STILL a c.t.
The Monitoring Shields look like a good & economical solution.
It appears this is a new product offering – maybe not a new development but the ‘guts’ of the old EmonPi unit?? – so a proven component. And no doubt there’ll be a subsequent add to this forum thread which will clarify.
You will have noted the Optical sensor vs CT discussion above. The Monitoring Shield accepts an Optical sensor. Using this at the PV end would cost £19 and save the £21 for a CT and AC/AC voltage sensor.
Pulse counting is accurate. As dawn breaks and the first few generated watts start to flow, the CUM pulse count recorded by emon every few seconds does not change at every sampling. It changes every nth sample but that quickly changes becoming continuous as the sun rises. And if you are visualising data at say 5 or 10 min intervals then you won’t even see this. But the pulse count will have accurately recorded that tiny first flush of generated power.
Whereas an inaccurate CT which measures instantaneous current (from which instantaneous power is calculated) will be even more inaccurate at the low generation levels at dawn & dusk. All CT’s are inaccurate – it’s just a matter of degree and cost. Furthermore power flow is calculated from instantaneous current & voltage values sampled every circa 10 secs – this of itself is an approximation. And, to cap it all, the AC/AC voltage sensor is inaccurate to some extent.
As an aside – I recently became aware that smart meter clocks drift (my son’s is 6 mins slow) and so that can complicate precise comparisons between downloaded smart meter 30 min data and emon recorded data. If connected to the internet, emon time is accurate internet time. Also smart meters use GMT throughout the year whereas emon visually presented data switches to BST when appropriate – but this is selectable.
Yes it is the emonPi board on it’s own so no cost of assembly - they are doing a soft launch.
Strictly, GMT no longer exists - replaced by UTC.
Actually by default emonCMS displays data in the Browser Timezone, but yes selectable.
Or go the whole hog and get an optical sensor and hook it up to your Pi and read the flashes with python or Node-Red.
@borpin
Does that mean that at the PV end, you could dispense with the Monitoring Shield and just connect the Optical sensor directly to the RPi?
How do you do that?
Are there any Forum links?
Thx
RPi direct pulse input: Directly connecting to Optical Pulse Counter with RPi? - #2 by pb66
Did that not show up with a search?
I’d have never found that!
I’d probably deploy Node-RED, easy to do and then send on the MQTT messages. I have a spare sensor here so I’ll order up a couple of RJ45 mounts and breakout pcbs and see how it goes.
@IanHampton - you might want to consider this - even cheaper!
Thanks again guys, order now placed, I also splurged for the rather nice cases, one with a display for the consumer unit end and a blank Emon pi case at the pv end…
Will update you once I receive the bits and commence installation.
Cheers,
Ian
A bit late now and also a bit left-field, but if you have/can get smart meters you could use a CAD and read them directly. There may also be a way to read your inverters directly?
Just a thought.
Adam
No, you cannot access the data - there is no API made available to do so. There are a number of threads here on that.
That’s what the CAD is for. Whilst it’s true there’s not one currently that gives direct local access, there are some that allow you to access indirectly via a cloud server. I currently get gas readings every 30 minutes and electricity import/export every 11 or 12 seconds ish.
It used to be an acronym for Computer Accelerated Disaster. 
Agreed but you said…
You cannot read the data directly.
“Directly” as in data from the metering devices themselves as opposed to “indirectly” via a device which infers the value externally. The data still comes from the meter, how it gets to where it’s going is a different matter. For the purpose of the original question that’s good enough.
“Can’t” should be “There’s no way to at the moment” since there’s no reason why a CAD couldn’t make its data available via USB or the LAN, other than there isn’t one ( that I know of ) that does that ( yet ) if we must be pedantic.
Anyway…
It stands for “Consumer Access Device”… the CAD reads the data directly from the meters then gives access to that data in some fashion. Ideally that would be locally but currently they tend to send it to a cloud server somewhere which you can then access ( or have the data pushed back to you via something like MQTT. )
And a few other TLAs (and FLA).