OpenEVSE charge regulation – A possible improvement?

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.