Hi all,
I hope someone can help me with pointers to resources that explain how to achieve…
I have an emonPi running well for quite a while and also one of Robin Emley’s mk2pvrouters for diverting surplus solar.
I’ve recently installed a battery which is working fine, but there can sometimes be a bit of conflict between the battery and the Router in respect of priority for energy because both systems use CTs at the same grid import position and both attempt to keep current at that location close to zero.
What can happen is that - possibly because of small calibration errors - the battery overshoots and exports a bit of stored energy towards the grid which the Router then rightly intercepts and absorbs into diversion loads. Occasionally this develops into a feedback loop until my diversion loads are pulling power from the battery at their full load - which is not desirable.
It occurs to me that it may be possible to program a spare output pin on the emonPi so that it changed state when the battery’s own input/output CT went negative - ie when the battery was discharging. (this is not the battery’s own grid sensing CT, but is my monitoring CT sent to emonPi from emonTX).
This pin could potentially be patched into the Router. I’m hoping I could modify the router script and use this signal to make diversion conditional on the battery not currently discharging.
Sadly, I don’t know whether this is possible or where to begin researching. If someone else here has done something similar, I’d appreciate some tips.
I presume your battery system is proprietary, and you have no control over it? And I’m assuming it has an inverter/charger that supplies your house loads from the battery at “night” and recharges the battery from your PV when there is surplus power.
Where is the PV infeed and the battery connection in relation to everything else?
My thinking is that the battery system is the one that shouldn’t supply power back into the grid, the fact that it sees the diverter load as house use and tries to supply it is where the system is going wrong. So is it possible to rearrange the connections and measurement points so that this doesn’t happen?
If that’s not possible, there’s the second, small c.t. usually inside the Mk2PVRouter’s case that is only used to display the “routed” power, and could fairly easily be moved out of the case onto the battery’s inverter to monitor that instead, bypassing your emonTx/emonPi. And then a small change to the software to inhibit diversion when the battery is exporting.
But I can see that resulting in you exporting energy when it could be diverted and put to good use to heating water.
Thanks for the reply Robert.
First paragraph - all agreed.
All connections are 240v AC. The PV, Robin’s diverter, an emonEVSE and the battery are on adjacent breakers in a 2nd Consumer unit that is on a separate “Y” branch of my main incomer from any household loads.
Yes, the Router’s internal CT is being radio’d into the emonPi for use on the divert graphs, but I don’t mind changing this arrangement. I haven’t been in touch with Robin about this, but if he is around at the moment he may pick up on this thread.
I agree with you that the issue stems from both systems (router & battery) being controlled at the same measurement point, and both want to make my grid connection Null current. I haven’t thought of a measurement point to put the battery’s sensing CT that can avoid this effect.
My thinking is that the battery system is the one that shouldn’t supply power back into the grid.
Yes and no. At the moment I’m not considering signing up to any grid services. But in the longer term view, there’s the chance that I may enter a contract to export energy back into the grid. During those times I probably wouldn’t want to defeat the export by routing into a diversion load.
Thanks for the suggestion about re-assigning the Router’s internal CT. I hadn’t thought of that.
But I can see that resulting in you exporting energy when it could be diverted and put to good use to heating water.
I’m not with you here. In which cases are you thinking I would want to divert when the battery is discharging?
No, You want the opposite to that, but when both are monitoring the same point and competing to achieve the same end, I see an unstable feedback system as being inevitable.
I think adjusting the Mk2 to prevent it from mopping up all of the surplus power could work, but it is the least desirable solution. It’s that which would lead to you exporting at least some energy that could usefully be used locally instead.
Your real problem is that the battery system sees the dump load as part of the house load, and tries to supply it. That’s what you need to prevent. And the easiest way - in concept, maybe not in practice - is to rearrange your connections and monitoring so that it doesn’t see it. If you can achieve that, I think both systems will work independently and correctly.
I think you need to move things round so that you can put your Mk2 feedback c.t. on the grid connection so that it sees the total load, downstream of that you need the dump load branch connection, and downstream of that the battery’s feedback c.t. and finally the P.V infeed, the battery inverter and the house load. So that way, the battery system doesn’t see the dump load but does see the house load, and the Mk2 system sees everything.
If you can’t rearrange the connection points like that, can you run the PV dump load cable backwards through the battery c.t., so that it cancels? I don’t know how far apart the two Consumer Units are, so I don’t know what might be practical and what might not.
Thanks again Robert, that’s really clear and helpful.
I can see that your topology changes would reduce uncertainty by creating a strict heirarchy with the battery taking complete charge priority over the Mk2 dump loads. My 4 dump loads would only be served when the battery is not absorbing all of the available surplus. I need to decide whether that suits our needs or if we would like to have some of the dump loads on a higher priority than the battery. Food for thought.
.
I’ve had a look at my cabling and I do have a spare way on a Henley block to add a spur for the Mk2 router as per your first suggestion, alternatively it would also be only a short cable loop to run the existing Mk2 supply cable through the battery CT as per your second suggestion. So that’s good. The difficulty is that the battery’s CT isn’t big enough to accommodate more than one tail which would be the simple way of achieving either solution. The next step would be to install another insertion point - like another Henley block - before my tails are split to the two CUs.
Coming back to my original question, do you think there is any scope to make a logic switch from the emonPi? I can now see that this doesn’t fully address the primary issue above, but it may help to integrate future enhancements by introducing the possibility of the emonPi giving conditional switches.
But what is the rating of your immersion heater? If it’s 3 kW like most, that’s 12.5 A and a single core of 1.5 mm² should be adequate provided you only use a short length through the c.t. itself. Does that make it practical?
I’m not an emonCMS expert, so I can’t answer that. The RPi does have I/O ports that can provide a signal, but how you’d get the instruction to drive one out of emonCMS - I have no idea. But there are other messaging systems (that I also don’t understand) that might be capable of doing it in a roundabout way.
Agreed that passing the Mk2’s supply cable through the battery’s CT is my easiest wiring solution. My Mk2 has up to 9kW of loads across 4 outputs in a priority sequence and my solar is 9kWp. The Mk2 is cabled with 6 mm².
The CT’s data sheet shows its aperture is 13mm and my tail has OD 11mm. I reckon I could get a core of 6 mm² in if I filed out a white plastic corner of the hinged lid of the CT - avoiding damaging the magnet, of course. Would that be acceptable?
I now have the Mk2pvRouter supply wired via a loop that passes through the battery’s CT and, as you indicated this has calmed the whole system down.
With this new topology the battery’s web interface now shows an “export” amount when the battery is not absorbing all surpus power, but this “export” is then offered th the Mk2 - which seems to be much finer-grained and responsive in its diversion which is improving my total self-consumption.
So thanks very much for the suggestions, much appreciated, David.
