I’m about to dive into openenergymonitor - I’ve just had my small PV array installed and ready to start looking at the stats in detail, but then realised with a bit of tweaking I can do so much more. So my openenergymonitor journey begins!
Currently, I’m unable to do much due to the layout in the meter cupboard and how the PV has been wired into the Consumer Unit - until I get the CU replaced I have time to scope things out properly and not rush into it with possibly the wrong setup. Just for info, I’m based in the UK with a standard single phase supply.
I’m currently thinking that I’d have one CT clip for the Solar generation, one for house consumption, a pulse meter for the meter (if new UK smart meters have a pulse output?) connected up with the AC-AC adaptor. There would be two sockets so a DC supply would be available for extra power.
Price wise, it looks like there is a significant cost advantage for the emonTX (with either the WiFi module or emonBase board) compared to the emonPi. That said, the overall cost of the hardware isn’t a big deal but it’d be nice to understand a bit more about the use cases each is designed for.
What would be the actual advantages of the emonPi solution over either type of emonTX solution? My thoughts are that once the emonTX is setup, it can be left running with no intervention required. I’m always cautious that a RasPi solution may never come back cleanly if the power is lost and could always need some intervention. If I were to setup an emonBase for local logging at least I could have that indoors and work on it at my desk if ever needed.
It’s a good question, the main feature that the emonPi has that the EmonTx does not is the display that helps with initial setup, in particular finding the ip address of the pi. That said it’s not too hard to find the ip address of the pi using tools such as the android app ‘fing’ if your comfortable with that - and in many cases the hostname emonpi.local works fine without the need for ip address discovery.
The EmonTx gives 2 additional CT inputs and also more recently thanks to @Robert.Wall has improved firmware that monitors continuously providing greater accuracy.
If you’re not fussed about the display and could make use of the additional inputs on the EmonTx it sounds like the EmonTx & EmonBase approach would be better suited to your requirements. As you say you can keep the EmonBase in a more convenient location.
Just to add that an emonPi and an emonBase both use a Raspberry Pi and all use the SD card - with the inherent problem you allude to regarding improper shutdowns. The Pi’s emonCMS system has been set up so that the risks are minimised - but they’re the same whichever you choose.
Thanks for your responses guys! I probably am leaning towards the EmonTX route but certainly not forgetting the EmonPi yet. I do love it’s just a single solution and I’m very familiar with the whole Pi ecosystem, but something keeps making me look at the EmonTX as a solution that can be setup and left.
I have a RasPi in the loft as an ADS-B receiver and I dread software update time! It not coming back online properly is not uncommon unfortunately.
Would having a 3rd CT be beneficial in my case? I have the choice to move to a Type 1 or a Type 2 solar setup (I’ll literally be having a full rewire of main feed and meter cupboard soon) - so I guess a 3rd CT could go on the main feed to the house and the system cover generation, consumption and import. But would this be redundant having a pulse sensor also present on the new meter?
Hello @Biohead, the EmonTx with an emonBase route is still the same in terms of being Pi based. It runs the same Linux + emoncms stack that the emonPi runs.
If you use the ESP8266 wifi adapter you can post to emoncms.org directly but there are quite a few advantages to local logging, see: 2. Log Locally - Guide | OpenEnergyMonitor for a discussion of the local vs remote options.
As it seems an appropriate question, does the emonPi support the continuous monitoring that is relatively newly available on the emonTX? I have found quite a few references to continuous monitoring on the Pi, but these all date from 2015/2016 and I don’t know if they’re still relevant.
I’m coming around a bit more to the Pi solution, especially given the benefits of local logging - and it doesn’t seem particularly difficult to reimage the SD card and setup again (that’s a current pain point of my ADS-B Pi receiver - it can take hours to get running again).
No unfortunately not, in addition to energy monitoring the emonPi firmware also includes code to receive data using the RFM69 radio and this is currently incompatible with the continuous monitoring firmware.
yes, or more precisely, we do not have an EmonPi version of the CM code that supports receiving data via the RFM69 radio. You could upload firmware based on the CM library without this feature to an EmonPi but it would then not received data from radio nodes…
You can of course have an emonTx and emonBase, to give you local logging with an emonTx for energy data collection.
I noticed this doesn’t seem to have an answer:
Your pulse input will not record export properly, if at all - at least not with any meter type we’re aware of - because most meters either do not flash the LED when exporting, or flash without discriminating between export and import.
If you have an infra-red data link on your meter, it might be possible to interrogate it that way. But I know of no off-the-shelf solution for that.
Your pulse input will not record export properly, if at all - at least not with any meter type we’re aware of - because most meters either do not flash the LED when exporting, or flash without discriminating between export and import.
I’d be relying on 1 CT for generation and 1 CT for consumption, with the pulse meter being an additional data source for import. Although I didn’t take into consideration that some meters may handle import/export in different ways. I’ll wait until the smart meters are actually installed to determine what behaviour it exhibits.
If there are no radio nodes, and purely using the emonPi to do all monitoring, I guess there is no downside to loading a CM sketch?
I would disable the RFM module by commenting out the lines where JeeLib is called in the sketch - that’s any function beginning rf12_
A simplified sketch that’s closer to the demonstration sketches bundled with emonLibCM and using RFM code without the receive part of JeeLib has now sent 2 million messages for me without failing, so I’m fairly convinced the problem is not with the library.
