What to buy?

Hi,

I’m considering an OEM setup (emonPi) but before I take the plunge I’d like to understand if it will do what I need it to do for my (possibly unique) setup.

They say a picture is equivalent to a 1,000 words so I’ve attached a rough diagram showing my system.

I’ve numbered all the proposed CT clamps in green and would appreciate any pointers on whether the following readings will be possible:

House Usage = House (3) - Solar PV (2) - Summer House (1)

Garage Usage = (4)

Summer House Usage = (1)

Total Usage = House (3) + Garage (4) - Solar PV (2)

Solar PV = (2)

EV Charging = (7)

Battery Charging = (6) when current flowing to Inverter

Battery Discharging = (6) when current flowing from Inverter

Grid Import = (5) when importing

Grid Export = (5) when exporting

Hopefully all of those are doable?

In particular it’s the battery charging / discharging one that I am not sure about.

I understand that a CT at (5) with the AC - AC adapter can help detect the current flow and therefore give Import / Export (I assume these can be tracked individually too as opposed to a nett value).

But on the battery storage side this will switch direction depending on whether it is charging the batteries (from excess PV to minimise grid export or from overnight cheaper rate electricity) or whether it is discharging the batteries to minimise grid import. So can the same thing work here too some how?

Assuming that everything is possible, what would I need to buy to be most cost effective?

Thanks for your help,

Martyn

1 Like

I think what I’d do is have an emonBase (not an emonPi) with an emonTx in the under-stairs cupboard, with an a.c. adapter. You will need to relocate c.t. 3 to the incoming side of the consumer unit. That will use 3 of the 4 inputs of the emonTx for c.t’s 1, 2 & 3, giving you direction of power flow on all three.

(This is why I recommend the emonBase, there are only two current inputs on the emonPi, so there’s no point in having an emonPi plus an emonTx for 1 extra input)

I’d add a second emonTx in the garage (you don’t mention the distance - presumably it’s a few tens of metres or less) again with an a.c. adapter, taking c.t’s 4, 5, 6 & 7. Depending on the ratings of the circuits, you might need to desensitise input 4 of this emonTx by adding a parallel burden resistor. Again, you’ll get the direction of power flow on all the inputs.

Once you get the raw data into emonCMS (running on the Raspberry Pi that’s the major part of your emonBase), you can manipulate the numbers. Yes, you can separately accumulate import and export, charging and discharging; and you can add and subtract inputs (for house usage and total usage).

If it’s not possible to relocate the c.t., then it looks as if you do need the emonPi, still with two emonTx’s.

Thanks Robert, that’s very helpful!

I can put CT 3 on the other side of the wall, that’s not a problem and the distance is pretty much what you see on the drawing, literally the other side of the wall to each other really.

Just for a bit of background I currently have some of this data being logged using various OWL CT meters but they don’t do current direction so it means a lot more maths to try and work out what’s going where!

Plus the transmission on them is once a minute so when you’re trying to calculate stuff in real-time you’re hardly never working with data that’s from the same time interval (so you could be subtracting a Solar PV generation figure from 55 seconds ago from a “total usage” that’s just arrived this second).

So am I right in thinking that all the number manipulation would occur in real-time with all the samples across all CT’s synchronised? So I’d be able to look at a screen and see the previously mentioned values accurate as of now?

Oh and finally, with the node-red / mqtt integration I can push any of that data (raw and / or calculated) elsewhere too?

Thanks again,

Martyn

No - not quite. You cannot synchronise the two emonTx’s, and the 4 inputs of each emonTx are sampled sequentially, but the sample duration is 200 ms and the interval between sample sets is about 10 s by default (but you can change it - however it costs you SD card / hard disk space to store the samples). So you’re 6 × better off.

I understand so, but I know nothing about that side.

Hi Robert,

I took the plunge and ordered an emontx with 4 CT clamps and a pulse sensor and got myself up and running with an emonESP posting directly to emoncms.org.

Would you mind checking my logic on an input process please?

This is for the main incoming grid CT clamp so will show positive when importing and negative when exporting (I have the AC adapter for sensing direction and DC power to power the emontx / emonESP).

I want to log the raw data (with kwh and kwhd) and also to create separate feeds for export and import (also with kwh and kwhd).

I think I have the logic correct but it seemed a bit of a long winded way to get there as there doesn’t seem to be a short way to get back to the original input value once you’ve added a rule to say only pass negative or positive.

Thanks again,

Martyn

I’m not an expert on emoncms processes, so someone else needs to check that for you.

Your processing looks fine, lines 4 and 5 are not actually needed as the “Node 72:test1” value is passed on from the power to kwh/d, but it will work fine either way. Personally I would also add a scale process in-between 12 and 13 to multiply by minus one so that the export is recorded as a positive, exporting -2000w sounds more like an import.

Thanks Paul, glad I was on the right track!

I realised the negative export thing after I posted, but I added a “signed to unsigned” process, is that the same thing as multiplying by minus one?

No, The signed to unsigned process is for reading an “unsigned” datatype therefore -100 = 65436 when passed through that process, not 100 as is desired.

OK, got it, thanks again!

Hey Paul,

Hope you can give me another couple of pointers surrounding processing?

I’m getting a bit confused with the concept mentioned at the top of the Inputs page (from emoncms.org):

“Input processes are executed sequentially with the result being passed back for further processing by the next processor in the input processing list.”

This implies that each process “does something” and then passes back the result of whatever it did for the next process in the chain, but this doesn’t always seem to be the case.

For example I have a power reading coming from emontx CT clamp so I:

log to feed
power to kWh
power to kWh/d
x 0.125
log to feed

My expectation with the last two is that I should get an increasing cost that resets each day i.e. the kWh/d amount times 0.125

This doesn’t appear to be the case and I think that you alluded to this in one of your previous comments “the ‘Node 72:test1’ value is passed on from the power to kwh/d”.

So that’s not really passing back the result, in this case it’s passing back the original input value.

Is there any documentation that details the processing anywhere that explains all this?

If not, would you know how I can get the end result that I’m after above (it’s for a dashboard display).

Thanks!

Sorry for the late reply, I’ve not been about much this past week.

Yes that statement is misleading, some do, some don’t, the only way to tell the difference is trial and error or stumbling across some info on the forum, there is no real documentation on what gets passed back to the next process, I did update the documentation for all the processes a couple of years ago to include that info but all that got deleted “to make room for the new documentation” a couple of years back and has never been replaced.

The log to feed, power to kwh and power to kwhd processes all do their thing and pass the unchanged value on to the next process, try to think of the processes as falling into 2 groups, those that do something with the value and those that do something to the value, the previously mentioned processes are examples of “with” processes because they take the value and store it or calculate and record energy from the value but they do not alter the value that’s passed on to the next process. Where as the processes in the “to” camp will reset the value to zero or multiply it by another value or filter positive values passing just the negative values etc etc. The fun is learning which is which and then remembering that info, especially as there are always exceptions to any rule, for example the Wh Accumulator that does both, it uses the value to determine energy, saves that calculated value but also passes the new value not the original value onto the next process.

In the example you give, the “power to kwhd” is passing on the unchanged “power” in watts whilst calculating the energy used, adding it to the running total and saving that to a feed. The “power” value is therefore multiplied by 0.125 and “log to feed” so the resulting feed will follow the original feed but the value will be one eighth of that original feed (x0.125).

What you could use is

log to feed
power to kWh
power to kWh/d
x 0.125
power to kWh/d

I’m assuming here you are trying to log cost per day and 0.125 is your kWh unit price. Although the "power to kWh/d is very specifically named, it can be used for a multitude of calcs including monetary costs, it basically converts flow rate to a running total, but as it is intended for electric it also has a inbuilt scaling from Watts to kW. So to display a “current cost per hour” you could also use

log to feed
power to kWh
power to kWh/d
x 0.001
x 0.125
log to feed -------> Current running cost per hour
x 1000
power to kWh/d ---------> Today’s total spend

The x0.001 and x1000 (in italics) are purely to scale Watts to kW’s for the cost per hour then back down again, so the “power to kWh/d” process being used for “running costs per hour to daily spend” outputs correctly when automatically scaled by 0.001 internally. (The multiple multiplications can also be combined eg x0.001 x0.125 = one step of x0.000125, but I thought that would be less clear in the example)

I hope this help and doesn’t confuse thing further, IMO some generic processes would often be more useful than the “apparently” very specialized processes.

Hi Paul,

Thanks for the very detailed reply, it’s most helpful, I think I’m pretty much up and running where I need to be now!

It’s a shame your documentation efforts were deleted, I participate in a number of open source projects myself so I understand how much of a PITA it is to keep manuals and howtos up-to-date.

That said, given the commercial aspects of the project you’d hope that the powers that be would see the value of keeping documentation current, complete and easy to find.

As a newbie that’s just spent a fair chunk of cash on OEM products (and just ordered some more today) it’s quite frustrating to have to bumble around on forums and rely on the good nature of people such as yourself to help with what are probably quite trivial things!

Thanks again,

Martyn