I’m looking to try and implement a really simple Excess Solar to Tesla divert. Without using openEvSE or anything else. The Tesla API has evolved over the years to enable adjustment of charge current directly from 0 amps to 32 amps.
I have basic emonPI running and Tesla charges either from the mains plug via Tesla dumb charger (max 10 amp) or generic dumb wall charger.
Looking for something simple that just says … if Solar > use by 250w for 30 sec then increase Tesla charge rate by 1 amp. If opposite then reduce. Repeating cycle with ramp up or down the charge rate
This way the Tesla charge rate just varies depending on excess Solar. Using the rate in this way will not interfere with charge % and if rate is zero amps then it doesn’t charge.
Has anybody implemented anything similar? Or willing to help a novice?
That looks a straightforward scheme to implement. Although my Mk2 PV Router code on the archived forum should still work as intended, I’m wary of modifying it after several years. Instead, I would use equivalent code from the Downloads page of my own website, mk2pvrouter.co.uk
My sketch Mk2_RFdatalog_6 reports the average power at the grid connection point every N seconds. By default, the reporting period is 10 seconds, but that could be easily changed to every 30 seconds. Then, if there is >250W of (average) export during the reporting period, the EV’s charging rate can be increased by 1 Amp. Or if there is >250W of import, the charging rate can be decreased by the same amount. Maybe the threshold criterion should be 125W, for 0.5 Amps?
That code will run on my own PCB (the Rev 1.1a version is available for the cost of the postage). That PCB layout had a tracking error which won’t affect what you would be using the board for. Or it can be run on any Arduino-type platform with just the port allocations being amended to suit the hardware that’s in use.
Sure. But if Solar > use by 3000W for 30 sec, would you not want to increase the charge rate by 12 Amps all in one go? That way, the system would only take ~30 seconds to regain its balance after a 3kW kettle has come to the boil, rather than 6 minutes. And similarly for when the kettle is turned on. Such a control scheme would be very straightforward to implement in the software.
The frequency of the charge-rate updates would presumably be determined by your EV charger. Whenever the system is put out of balance, surplus power will escape to the grid or chargeable power will be imported. The faster the update rate, the closer you will be to using all of your surplus power and only your surplus power.
You have an emonPi, so you have a computer platform you can use. I don’t so I’m not sure if you can, but I’d use some custom Python program to do what you want. Stick it on the emonPi.
You need to figure out how you can talk to your Tesla. OpenEVSE already knows, it seems. The app can do it, so using JSON you should be able to do that same.
I have OpenEVSE and I use MQTT. I do not need emonPi, I have my NAS doing MQTT broker and it gets data from the smart tmeter. I have a Python program that calculates what OpenEVSE needs for solar divert from data it gets from the smart meter. The program publishes to the broker on the NAS and the OpenEVSE subscribes to it. Works for over two months now.
One amp steps is what I am doing with my Open EVSE but, as you say, it’s slow to adjust to a large power step in solar or house consumption. I have thought about a PID loop that can make bigger steps but am warned there may be a Nyquist sample rate problem. I am no expert here but it goes something like this:
Robin, in your diverter, you are sampling the mains export many times a second so can alter the power into the immersion rapidly. Nyquist implies about 5 times less power change rate than the sample rate.
But in a car charging scenario you are forced to use 1 amp steps, rather than the much finer granularity of a diverter, and don’t want the car rapidly switching on and off every time a kettle or oven goes on say. So you average the export available over say a minute. I use 1 minute so effectively the sample rate is 1 minute (I don’t think that is quite true due to the averaging but my mathematics fails me here). Thus trying to change the car load in large steps faster than every 1 minute breaks the Nyquist rules and may cause large oscillations in current. I thus only alter it at one amp per minute. But, in addition, to stop it turning on and off every minute I use a 5-10 minute cycle for car currents below 6 amps.
Despite all that I am thinking of doing larger steps when the car current is >>6 amps and the export or import is >> 1A. I.e. If averaged export is 2000W divide by 2 and 250 to get 4 steps. Repeat one minute later. If the solar and house are unchanged that will lead to 2 steps this time and 1 the next time. This is the D bit of PID, I am told. Could make ramp down faster than up to limit import.
If you have a lithium battery storage system oscillation is less of a problem as any short overshoots in power consumed by the car are sucked out of the battery rather than the grid.
Anyone got any better knowledge here? E.g. how large /fast does the official Open ESVE/Emmons setup do?
With the Mk2 diverter, the load is either fully on or fully off, and a new decision as to the optimal state of the load is taken every mains cycle. This is 100% modulation which I would not describe as “fine granularity”.
The control algorithm allows the rate of consumption to accurately match the rate of generation within a timescale of just a few mains cycles. This behaviour lies well within the energy range that is tolerated by all types of meter in the UK, hence all surplus power can be safely consumed on site at no cost to the user.
With the EV charger where the charge rate can be altered in 1 Amp steps, I would expect there to be a minimum specified duration between consecutive instructions. Any delay beyond this minimum duration will degrade the match between consumption and generation.
If a 3kW kettle goes on for, say, 4 minutes, it would seem best for the EV charger to reduce its output as quickly as is possible during that period, and then to resume as quickly as possible thereafter.
You can’t use a solar diverter like @calypso_rae’s Mk2 to charge a car. Period.
An immersion element is dumb passive bit of wire.
The electronic charger in an EV is not. Don’t do it or you’ll damage your charger/car/both.
OpenEVSE firmware (in the charger) talks to the car to tell it how much currant it can pull, and the car pulls more/less power. This is why we have 2kW portable units and 7kW wall chargers, there’s not much difference in the kit, but the kit ‘knows’ how thick the wire connecting it to the grid is, and hence how much current can be passed through it.
Secondly you (almost certainly) can’t adjust the charge rate (even with OpenEVSE) second by second, every minute or two is OK, but if you change the charge rate every few seconds most cars will throw a tantrum and stop charging.
Charging by solar isn’t a 100% bulletproof process. It will draw grid power occasionally at lower charge rates as the clouds pass by, even on commercial it.
I understand that but even your diverter has granularity in that it can’t deal in grains smaller than half a cycle and the say 1 Joule bucket size means the power level is not perfectly matched to export. It’s just matched to within 1 joule say. That is a very fine granularity and perfectly adequate for an immersion diverter.
I am going to try an Excel spreadsheet to see how stable this is but suspect that in your scenario it is fine to rapidly absorb the extra 3kW into the car if the house load /solar is otherwise stable. But if the house load/solar changes in the next few seconds (and it’s very common for it to be all over the place) Nyquist is going to tell you that power oscillations will result. E.g. if the washing machine turns on 10 seconds later the car has to rapidly reduce its current again but the one minute measurement of the average power just has not caught up. A further slight source of instability is that one’s software has to make assumptions about how big the power steps are. In reality they are not the exact 250W discussed here and every car probably varies a bit in its actual consumption when sent a say 10 Amp command. Mains voltage affects it too.
Both our cars (a Peugeot 2008 and a Leaf) cope with one minute changes to the power level. Rumour is that the Leaf can do maybe 10 seconds, but it’s hard to get the data to prove it.
Chis needs to answer this but I assumed he was saying that the Tesla API talks direct to the car to alter the current. So a dumb charger works and the only purpose of the diverter is to gather the export value to talk to the API.
The API is unlikely to be very fast at altering the current. My cars’ APIs react in 15 secs or more to things like starting a charge. They can’t alter the current.
This sound like a job for a NodeRED flow, there is already a Tesla API module available, I’m not sure if this supports the charge rate API yet:
The Tesla API is quite challenging to work with since Tesla are constantly changing it and there are some security loopholes to jump through with 2FA and token authentication. I’m not sure how well solar PV divert will work using the API, the latency may make it difficult to accurately track solar. I think local control of the pilot single duty rate using an OpenEVSE or similar is a better solution for adjusting the current for solar PV divert.
