OpenEVSE charge regulation – A possible improvement?

Today is sunny and the ~ 4kW excess solar is charging the car nicely taking priority over my energy diverter as intended using SolarPV-gen topic: emon/emonpi/power2

All good until my wife turns on the oven!

The problem seems to be that SolarPV-gen topic: emon/emonpi/power2 simply allows the car to use all the PV power. Now this could be handled better in software but in the short term suppose I connect another CT on the house feed but position it to be out of phase with the existing CT and wire it in series with the PV CT. Now the uncontrolled house load will ‘regulate’ the available PV power and emonpi should control the OpenEVSE to match the surplus PV.

Is this feasible?

That will never work - unless the c.t’s have internal burdens. Did you not read this: Arduino based Mk2 PV Diverter being resurrected - #4 by Robert.Wall ?

I fact, you should probably read all of that thread anyway. The principle, if nothing else, seems to apply to your situation.

The easiest/quickest way to resolve this is as I described in your other thread and is also mentioned in the guide i linked. You simply need to subtract your normal consumption from the PV and use that “available PV” value to drive your EV charger via a “publish_to_mqtt” process and just change the openEVSE “solar topic” to use that new “available PV” topic.

I guess my problem is trying to sort out too many issues in one go. Yes thank you Paul I did read your instructions but I am a long way behind you in understanding how this stuff hangs together and did not wish to burden you with more dumb questions. You appear to have great patience so I shall try to explain my difficulty.

I looked up MQTT and it’s a protocol which I guess is used between the emonPi and the OpenEVSE. It may also be used to communicate with the car but I have not looked into that.

There are two MQTT topics I can control using the OpenEVSE web interface under the Solar PV divert heading. These are SolarPV-gen topic and Grid (+I/E) topic.

I currently have emon/emonpi/power2 in the SolarPV-gen topic and the Grid (+I/E) topic is blank.

You are suggesting that I:

“simply need to subtract your normal consumption from the PV and use that “available PV” value to drive your EV charger via a “publish_to_mqtt” process and just change the openEVSE “solar topic” to use that new “available PV” topic.”

Looking again at the instructions I see:

This may be required for a Type 1 solar PV system: Grid (import/export) = site-consumption – Generation.

Are you suggesting I put Grid (import/export) = site-consumption – Generation in the Grid (+I/E) topic box?

Not quite true,

There are 2 MQTT selection fields where you can enter MQTT topics, but the MQTT topic is what controls the EV charger not the other way round.

There is a choice of 2 ways to subscribe to any single MQTT topic. The pool from which you could choose that one topic is only restricted by your own implementation, you can choose from existing MQTT topics or create custom MQTT topic(s).

It seems the difference between the 2 MQTT selection boxes is simply that one works on a positive “available for EV” and the other on a negative “available for EV” value, the latter obviously ignores also any positive “import” value and without testing or diving into the code, I do not know if the former will also ignore negative values.

So all you need is to (create and) select a feed that better tracks what you want as “available for EV”, selecting that feed in which ever of the 2 boxes suits it’s sign.

Put it in “SolarPV-gen topic:” if it is a value that increases positively when the EV should be charging or in “Grid (+I/-E) topic:” if it is a value that increases with a negative sign when the EV should be charging.

Think of the MQTT topic as a “EV charge limiter” rather than specifically PV or export etc. You could if you chose, fabricate these values and drive it manually or automate it with a complex algorithm. How you get the numbers is up to you, which box the topic goes in depends on the sign/direction of the values, the EV charger will just try and operate under that limit you give it.

As for the topic path/name, if you are using an existing topic eg emon/emonpi/power1 or emon/emonpi/power2 etc then you need to use the topic path/name in question, but if you are creating your own feed in emoncms and publishing that then you can designate your own MQTT topic specifically for the job eg emon/openevse/available and that is what you enter both in the “publish to mqtt” process in emoncms and also in the EV web interface. ie emoncms is publishing values to emon/openevse/available and the EV is subscribing (listening) to emon/openevse/available to get a value to control the charging level.

So working backwards here :slight_smile: We’ve covered how to get the feed value to the EV and what it does with it. That just leaves the source of the data to be established.

This bit is very specific to your setup and we would need to know what inputs and feeds you already have to be more specific, but I would have expected you to be logging your “normal” consumption. By “normal” consumption I mean the stuff that is not “diverted”. However now looking back at your other thread (emonPi Solar PV OpenEVSE Setup Tesla Model 3 - #32 by BrianD) I believe you only have 2 measured metrics “PV” and “Grid” (duplicated by 2 devices) so this limits what you can do. Had you already been tracking “normal use” it would have been as easy as subtracting that from “PV” (hence my previous “easy as” comment) .

Does the MartinR diverter send data to emoncms? If so what values? We might be able to make use of “diverted” if that’s present (as suggested by Robert in the other thread) but I’m not 100% sure (the energy store will have a higher priority than the EV or diverter)

Are you open to moving some CT’s? eg leave the MartinR diverter as it is and use the emonPi to get some other data eg on the feed to the House CU and perhaps the cable to the energy stores?

How would you like/expect the energy stores to fit in with the EV and diverters?

how many loads does the MartinR diverter divert to? ie is the remote diverter an additional diverter? What are those diverter loads?

Where on that linked diagram do the diverter loads take their power from?

Does the energy store have any monitoring or data api’s?

Sorry for all the questions, but hopefully you can see from the above, that getting the EV to react to data from emoncms is the easy part. The part with all the work is establishing a stream of values that best reflects how you want the EV to work. From only 2 measurements “PV” and “grid” you can only really calculate total use of all consumers incl diverted and EV and energy store, you cannot distinguish between them, the more detail you have, the more control you can have.

That is a very detailed response Paul thank you.

I decided for several reasons to re-arrange my grid connection tails to form a ‘Type 1’ arrangement. This was done a couple of days ago, previously it was ‘Type 2’. A diagram of the new configuration is attached fyi.

The diverters are both connected to the House CU and neither communicates with the emonpi or emoncms so can simply be considered to be a variable load. There is another RPI but this merely talks to the inverters and uploads to PVOutput. It does not use CT’s.

How would you like/expect the energy stores to fit in with the EV and diverters?!
how many loads does the MartinR diverter divert to? ie is the remote diverter an additional diverter? What are those diverter loads?

I think the diverters can be considered like any other variable load. They are the immersion heaters in two DHW tanks. Tank A being controlled directly by MartinR and tank B as a slave from MartinR via an RF link to a diverter I designed.

The new diagram should explain where the loads are.

Moving CT’s around is not a problem

I have the emoncms app running on IOS and this is excellent. Setting up was incredibly easy and I am very happy with that. I also use my Win 10 desktop PC to inspect the local and web based data but I am puzzled because I can change inputs and feeds in both the local and the web connections. Is this OK or should I only do this in one or the other? My preference is to make changes using the desktop machine as it’s more convenient.

Some more detail for clarity:

No, that’s the issue, if you do that the diverters take priority over the EV and your EV will only charge once both DHW tanks reach temp.

Unless you distinguish between high priority “normal” consumption and low priority “diverted” consumption you cannot get the EV’s priority to sit in between them. That’s why Glyn’s “next best thing” suggestion was to just track PV that’s the only other metric you have available, but that doesn’t take any use into consideration as you’ve discovered.

If you cannot separate “use” then the whole use is either considered as a whole and your EV has to wait til the tanks are hot or the EV charges regardless of any use, you cannot use “some use” if all use is seen to be the same.

What info goes to the emonGLCD’s? Is that info from the MartinR diverter? Are they 433 or 868MHz?

@pb66What info goes to the emonGLCD’s? Is that info from the MartinR diverter? Are they 433 or 868MHz?

Just modified info’ from MartinR. They operate on 433MHz

The current setup I am using is correctly diverting and modulating all the PV power. This means no power is fed into the grid therefore MartinR does not consume anything because it has not ‘seen’ any power filling the ‘energy bucket’.

The problem is not MartinR but the uncontrolled load such as oven, dishwasher etc. The emonPi is measuring the house load therefore if it were to subtract the PV power from the Henley 2 power it can calculate the house power. The emonPi could then reduce the EVSE power by an amount equal to the calculated house power.

Do you recall what group and node id’s were used?

Is the emonPi in range of the MartinR diverter? (or could it be?)

All you have done is change the CT arrangement “install type”.

“GRID”, “PV” and “USE” are 3 metrics that can be determined from measuring any 2 of the 3. Previously you had both devices configured as “type 2”, now you have the diverter as “type 2” and the emonpi as “type1” but they both monitor 2 of the 3 core metrics so both can (only) provide all 3 metrics the same. Neither can separate out the “use” it’s all “use”, the emonpi measures all “use” directly via a ct and the diverter can derive “use” from “grid” and “pv”, but in both cases it is just “use” all use, house, ev and diverters together, just “use”.

Sorry that doesn’t make much sense to me, if it’s measuring the house load why/how would it calculate the “house load” by subtracting the PV from the house load? That would just be USE minus PV = GRID.

Missing from your diagram is where MartinR’s diverter’s dump load is fed from. That information is crucial.

Previously Brian had said it they were both from the house CU.

1 Like

Maybe this might help clarify the type 1 vs type 2 (and an un-mentioned possible 3rd type)

Grid CT Solar CT Use CT and
"Type 1" no yes yes Grid = Use - Solar
"Type 2" yes yes no Use = Grid + Solar
3rd Type yes no yes Solar = Use - Grid

(I hope that’s all accurate I just knocked it up quickly to demonstrate the “2 of 3” rule)

Until the consumption of the dump load is known by some means so that it can be subtracted from the power available to the EV, then it’s going to be difficult if not impossible to have a stable system where the priorities can be controlled.

“by some means” can be by a direct measurement or, if Martin’s diverter is working as per his original design (not the published sketch) and the diversion is being overridden by temperature measurement so that the diverted power can be calculated (not possible if the immersion heater thermostat is the temperature control mechanism), then Martin’s diverter can send that data by radio to the Pi.

I have read all the above several times and it seems to me that a simple fact is being overlooked.

The MartinR diverter only applies its dump load when 2250 Joules of energy has fed to the grid.

If PV power is available but is all used by anything connected to Henley block 2 then no power is fed to the grid and MartinR remains OFF. This is what is intended by design and is what I observe during normal operation.

The discussion above appears to focus upon the interaction of the MartinR diverter and the load controlled by the emonPi. I would like to simplify the problem by starting with MartinR removed. During any testing I shall simply switch him OFF.

I hope to achieve the goal of regulating the power flow to the EV based on the simple rule of:

EV = PV – H2

Where EV is power diverted to the car via OpenEVSE

PV is power from solar

H2 is power to Henley block 2 as measured by CT4

The emonPi has access to both PV & H2 is capable of this simple arithmetic my problem is that I don’t know how to do it.

This part would have worked fine with the original Henley block arrangement as it was so that H2 doesn’t include EV because to expand your equation above it would become

EV = PV – (House CU + EV)

when in actual fact it should be

EV = PV – House CU

As the HB’s were (EV on HB1), then yes CT4 can be used directly to ascertain the available power for EV charging which is what I’ve been saying,

Originally 8 days ago on the other thread

. . . and in this thread 3 days ago

Alternatively you could move CT4 to between HB2 and the house CU or maybe some form of feedback value could be used, for example available for EV = PV – (HB2 - used by EV). Whether the EV is removed from the “normal use” by changing the wiring, moving the CT or in the maths, EV must be removed from the basic PV - USE equation.

Otherwise when there is 2KW of spare PV the EV will be told to use 2kW at which point there is no spare PV so the EV will be switched off and then the 2kW spare reappears so the EV is told to use the 2kW etc etc etc

Do you agree with this part before we reintroduce the diverter?

[edit] Looking closer at the diagrams, moving the CT not the wiring seems the easy choice, the change of diagram style confuses comparison between what you had originally and what you have now.

Yes indeed I have always agreed with what you are saying. My first post in this thread was seeking to achieve the same thing but by a different method.

If I move CT4 between Henley 2 and the house CU the emonPi will have the information required to calculate surplus PV (EV = PV – CT2) However, the power consumed as displayed and recorded on emoncms will not include the EV.

If we leave things as shown on version 6 of my drawing let’s consider what will happen if as the system operates.

Where EVm = EV measured

EVc = EV control level

House = House CU load

Assuming that the command sent to EV will be EVc = PV – (House + EVm)

Initially EVm = 0 therefore the calculation will result in EVc = (PV – House)

Some short while later as the OpenEVSE ramps up the value of EVm will increase and consequently will effectively apply negative feedback by reducing EVc which should prevent overshoot. The inherent delays in this should result in a damped control system which will not oscillate up and down.

I am very happy to try this but I don’t yet know how to do it. If you could please give me an example I would be delighted to try and report back the result.

I thought you may like to see the following graph. It shows the system for today 26/08/2019 with the wiring as detailed in the Version 6 drawing.

Just before 10:00 you can see MartinR diverting power as expected until I enabled the car to charge which happened to coincide with my wife switching on a 3kW load. After that the consumption curve is correctly showing the power diverted to the car plus the house base load. You can see the car taking more power as the sun comes up and in the late afternoon reduces to 2kW as it is designed to do. The spikes are the inevitable cups of tea.

The drop to zero at around 11:00 was me interfering.

The reason to post this is simply to show how well the OpenEVSE is working. Sorry if this is all old news to you.

1 Like

It may help if I backtrack a little and explain why I am having such difficulty making progress.

I am using a Win 10 desktop machine to access my emoncms configuration via This allows me to view graphs and configure the system using Inputs and Feeds.

In addition, I can access the emonPi directly from the desktop machine using the local IPA of where I can also configure Inputs and Feeds as required.

Thirdly, I can access emoncms via an app on IOS where once again I can configure Inputs and Feeds.

I don’t understand which of these has priority, if I try to add some simple arithmetic function in the control loop which should I be tinkering with?