i have installed an EmonTx with 4 CTs and the WiFi add on in order to monitor energy use by 4 high usage circuits in our new house (eg ASHP, MVHR/ASHP water heating, summerhouse heating and exercise pool).
I have this working with the Emoncms.org service and I’m familiarising myself with all the setup / display / tracking options.
When I first connected the EmonTx I found I had inputs with keys E1…E4 and P1…P4 which I assume relate to the 4 CT inputs, Vrms and a few other system inputs.
I haven’t found explanations for the Es and Ps - so are these Energy (Wh) and Power (W) respectively?
When I associate these with Feeds I would like to be able to view the pattern of Power usage over time for each circuit and the hourly/daily/monthly/yearly accumulation of Energy that has been consumed for each. So how should I set these feeds up to do that? I am confused by the log, kwh, +inp etc designations.
One of my CTs (ASHP) seems to be returning a low but negative input number when it is not active but a high positive number when active. There is no PV or other generation on this circuit so how can that be?
Apologies if I haven’t found the place where this is all documented (if it is)! Knowledgeable guidance welcomed!
That is indeed correct. The power is average over the reporting period - 10 s unless you’ve changed it, and energy is the accumulated energy since the emonTx was last powered up or reset.
I’m not very familiar with emonCMS processing (either the local version you can have on a Raspberry Pi or emoncms.org - and bear in mind there are detail differences between the two, so always say ‘emoncms.org’ when asking). Basically, what happens is an input arrives on the inputs page, there you can do various operations on it (multiply or add a constant, or add another input or feed). If you select the process, the ‘help’ note in blue explains. The result of each computation is (with a few exceptions) passed onto the next operation. No input data is stored, to permanently store the value at any point in the chain, you log to a feed, when you get to choose the type of feed. Don’t choose an interval that is shorter than the rate at which the data comes in - you’ll get NULL values in the feed that cause havoc with the graphs. You can convert power to energy (though you now have energy directly from the emonTx - it hasn’t existed previously).
You can then create a dashboard on which you can display the value now of a feed, and/or graph it to display it in various ways. I suggest you play with the various “widgets” and “visualisations” to see what each does.
Is the c.t. very close (i.e. touching or nearly so) another cable carrying a relatively high current? That could be the answer, the other possibility is it’s noise picked up somewhere in the system - possibly from the ESP8266 or the 5 V power supply. You could use “allow positive” in the input processing to allow only the wanted positive values to pass through to be logged to the feed.
I understand your position. Documentation here often isn’t in the place you’d expect, and is sometimes hard to find (even for me, and I’ve been around here for years) and sometimes, it only exists in the forum.
Seeing how I have been benefitting so much from the help offered here recently, I’ll try my best to put something back in for others with words from a newbie
Within the emoncms / Inputs page, click on the spanner next to the Input line you are interested in (say ASHP). I found clicking on the “Add process:” log blue button easiest, give the new Feed a name in the box to the left of the word Engine, select a duration (probably 10s for most things other than temps) and then Add.
Then click on the blue “Add process:” kWh icon and do the same thing but this time add something like _kWh to the end of the Feed name.
Other processes can be added by using the “Log to feed” dropdown box and then selecting other types of process. When done, click on the Save button bottom right and then go to the Feeds page to see the results.
If you then graph the results (or create a Dashboard or App) you can see usage over various time intervals (D, W, M, Y etc), and there are others way to see the info also.
Thank you Robert and Julian for your contributions but I still have a fairly basic issue or misunderstanding on my part.
I deleted all my inputs on opencms.org and then let the EmonTx repopulate the list as it had previously.
I look at one Pn reading - the one for the circuit with the MVHR system that runs continuously. The EmonTx reading is around 30 for this input- so what does that represent? I had understood it to be watts as Robert confirmed. I attached a CT on the same MVHR supply attached to an old Owl monitor and that reads around 100 (watts). Within the limits of the Owl’s approach 100 watts seems about right.
My Vrms reading varies around 250.
A relatively unusual aspect of our house electrics are on a 3-phase supply. The EmonTx AC-AC adapter, USB power supply and the 4 monitored circuits are each on various of the 3 phases. However, unless my understanding is way off, I don’t see how this would affect any of the above - although the apparent roughly 1:3 ratio of the EmonTx vs Owl readings makes me wonder!
I would be very grateful if anyone explain what is going on?
(Typing this beats paying attention to the “Leaders” debate on BBC1!)
That is undoubtedly your problem. All the OEM hardware is designed principally for the UK single phase domestic mains supply. I’m afraid your understanding is way off, it does affect (almost) everything. You can read up about 3-phase supplies in ‘Learn’, but basically, unless everything is on the same phase - a.c. adapter and all your loads, the answer will be wrong. How much wrong and in which direction depends on the characteristics of the load.
You need to change over to the 3-phase sketch and set that up correctly in order to read real power with better accuracy (still limited because you can only measure one voltage), or you could use one emonTx per phase, or you could alter your sketch so that it only sends apparent power - in which case unless the load you’re measuring has a power factor of unity or very nearly so, that answer will be wrong because of that.
I’m at the edge of my knowledge here, but don’t forget that the OWL system (I have one too) doesn’t have an accurate measure for Vrms, so the watts are always likely to be different. In the end I gave up comparing the numbers from the two systems as I could never actually be sure which one was “right”.
Electrical engineering lesson coming up:
What the Owl is doing is guessing the apparent power based on the nominal voltage (which I hope you can set as an option - if not, it’s an even poorer guess). So it multiplies the current it measures by a voltage. The snag is, I can find a load - either a capacitor or a large inductor - that draws current but dissipates very little power. The Owl will give a very wrong value in those circumstances. EmonTx will get a lot closer, because with an a.c. adapter, it does calculate real power.
Thanks Robert, I realise the Owl is an imperfect measurement device but on the other hand I wasn’t after high accuracy readings with the EmonTx, but more indicative information to understand energy use and help with optimisation of that use.
I need to think again, as I don’t want to go down the route of 3x EmonTx plus 6x 13A sockets across 3-phases (or maybe 4 sockets with a multi-way USB power supply). Nor do I want to get into Arduino firmware uploads and “sketches” - I had hoped to avoid CLI mysteries with Linux and Pi systems with the EmonTx.
So it looks like I might have a barely used EmonTx / WiFi with AC-AC power and 4 CTs to sell - what am I bid?
The Arduino IDE isn’t all that bad - there’s a fairly detailed guide to setting it up in ‘Learn’, but you do need to buy a programmer from the shop. And if you use Windows (I don’t), the guide covers that too.
No, I’ve never supplied the hex file. Many options (I exclude calibration from this) need a recompilation, as the code stands. I’d need to look at how many of those could be included in the on-line calibration - but my feeling is there are too many. The point about setting all the things that should be known and never need changing by including or excluding them with #define directives is only the parts you need get compiled, all the rest vanish without trace during compilation, so don’t contribute to memory use nor execution time.
And in the 3-phase sketch, speed of execution is vital.
One more point for @John_Downe - I’ve just remembered that you said you are using the ESP8266. Unfortunately that will also need a new sketch, because the 3-phase emonTx sketch just cannot keep running and talk to it at the default speed of 115200 baud - they need to talk at 9600 baud.
I keep meaning to order an ESP8266 so that I can find out about it. I’ve no idea what is actually involved with setting it up or changing the sketch - I can only repeat what others who’ve used it have written.
But from what John has written, I think he’d prefer that to the Pi Zero W.
