Enhance SolarMode and C2 AUTO to automatically switch up to 3 phases if charging with 1 phase

[cvanlith]

The current situation, when in SolarMode and CONTACTOR2 is AUTO, is that charging will automatically switch down to 1 phase if there is not enough current for 3 phases. After switching down there is no way to switch up to 3 phases again. Except manually switching the CONTACTOR2. It is beter to also automatically switch up to 3 phases when sun is available.

Currently the actual switch is implemented in a lot of different places. I would suggest streamlining and do the switching when the SolarStopTimer runs out. To beable to switch up to 3 phases we need another timer. Also there do the switch when this timer runs out. The timers are started based on the lack or abundance of current in CalcBalancedCurrent().

The new switch will be implemented by a new variable SinglePhaseOverride with possible values: REFRESH, YES and NO. The method SetSinglePhaseOverride(new) is sets the variable and restarts the charger if charging. The actual switching is done later during restart in State_C of SetState(). Contactor2 is switched based on the slightly adapted method Force_Single_Phase_Charging(). The variable SinglePhaseOverride is included in the logic of Force_Single_Phase_Charging().

By combining the timers with the new switching logic switching up and done is done in a smooth way with a proper waiting time (SolarStopTime).

This pull request contains also some other minor changes.

This code has been tested in a single SmartEVSE setup. Switching down works. Switching up could not be tested due to lack of sun.

[dingo35]

First of all: thanks for your work! Switching up to 3 phases is still up there on my todo list, so I appreciate any help!

I haven't looked at your code yet, to be honest I am not ready to accept PR's yet, especially not in the parts of the code that deal with Solar Mode: there is a difficult bug in there that manifests in Master/Slave configurations only, and it hinders the release of v3.5.0 . If thats solved I can look at functional expansions like your PR.

If you want to test Solar mode code with a lack of sun, a grep FAKE_SUNNY_DAY include/evse.h will show you how to test on cloudy days...

[cvanlith]

I understand. My code still needs more testing and I certainly will try with FAKE_SUNNY_DAY. This PR is work in progress and was meant to inform you and maybe get some feedback if you think it is the wrong direction.

[dingo35]

As you go further on this track, you will realise that there is a conceptual problem in up/down switching C2 on available current: Solar Mode works with the sum of all phases, which makes sense because all electricity providers will charge you for the sum of all phases. But the SmartEVSE can never know for sure on how many phases the EV is actually drawing current (unless an EV_Meter is installed); the CP signal tells the EV how much current (per phase) is available, but the EV can decide to only use certain phases. E.g. some Tesla's start charging on a low current on a single phase, and 40s later decide to add other phases to that. The industry protocols allow the EV to dynamically change that.

Both Stegen and I tried to overcome this with phase-detection routines, and those work most of the time, but not always. And we like our software to work always.... :-) so I removed those routines in 3.5.0-RC0.

So I hope you have an EV-meter installed, or you will run into problems that are conceptually impossible to overcome...

[cvanlith]

Ok, I was thinking along the following line. The EVSE can charge on 1 or 3 phases. The fact that the EVSE is fed with 1 or 3 phases is not relevant here. Also if the car uses 1, 2 or 3 phases is not relevant. BUT if charged it is always on L1 plus 0 or more extra phases. Is this correct?

If so then ....

Switching phases up and down should be done only based on the available sun power. All switching is done slowly with timers to make sure that EVSE and car have adapted to the situation.

Simply put you charge on 3 phases as a default. If you get the flag NO_SUN, you switch down to 1 phase i.e. set my new SINGLEPHASEOVERRIDE (SPO) flag (and wait awhile). If after that while you still get NO_SUN you switch off. Switching works based the NO_SUN flag and my SPO flag. It is not important if my new SPO flag actually switches anything or even if 3 phases are available or used. The worst thing that can happen is that it takes longer to switch off.

Switching up works the other way around. If charging is off and sun is available (>minCurrent) the SPO flag is set and charging is restarted. Again we wait a while. If charging is on and sun is available (>3*minCurrent) we set SPO flag to false and restart charge.

Both switching up and down are active simultaneously. To prevent problems there have to be waiting times.

Using this strategy you do not need to know what phase is charging. As long as the car is either charging on L1 or (L1 and L2) or (L1 and L3) or (L1 and L2 and L3) it wil work. So any charging without L1 wouldn't work. Note: when using 2 phases you will only switch up if there is enough sun for 3 phases.

Am I missing something? Let me know.

Thanks in advance.

[dingo35]

Its a little more complicated than that.

You can not predict which phase an EV is using to charge; an EV can dynsmically change this.

Also, you just cannot simply switch C2 on or off; my Enyaq handled that fine, but many EV's don't: you have to end the charging session and build up a new session. And the EV can then make different decisions on its charging strategie then the first time.

And now we are only talking Multi=Disabled, but in a Master/Slave config things get more complicated.

If you look in the code you can see how the switching down is currently handled, only in certain situations; switching up would need the same precautions.

[cvanlith]

Its a little more complicated than that. It always is :-)

You can not predict which phase an EV is using to charge; an EV can dynsmically change this. I understand, but when an EV is forced to charge on 1 phase it is always L1, isn't it? So when C2 disconnects L2 en L3 and we restart, then the EV has no choice but to continue charging at L1. When C2 is connected (so 3 phases connected) and we next restart, we should not care which or how many phases are actually used. The EVSE already has the logic to make that work.

Also, you just cannot simply switch C2 on or off; my Enyaq handled that fine, but many EV's don't: you have to end the charging session and build up a new session. And the EV can then make different decisions on its charging strategie then the first time. Yes for that I developed the SetSinglePhaseOverride method. It gently changes the number of phases bij switching to state C1. Similar to your solution.

And now we are only talking Multi=Disabled, but in a Master/Slave config things get more complicated. I do appreciate that. For now I am only working on Multi=Disabled. As a matter of fact I do not understand how this could work in Multi = Enabled.

If you look in the code you can see how the switching down is currently handled, only in certain situations; switching up would need the same precautions. I am now working with the FAKE_SUNNY_DAY and did find quite a few problems in my code. So stil work for me to do. As soon as I have some decent working code voor Multi=Disabled I will let you know.

[cvanlith]

I enhanced the FAKE_SUNNY_DAY by rotating the injected current from 0 to 7 to 39 and back again. The results is the C2 to open and close to find the optimal number of phases to charge with (only 1 or 3). There was not enough sun to check in real life. Hopefully I found a way around the problems you have described without using an EV meter. Let me know.

[cvanlith]

I added enhancements to determine the actual surplus current from the solar panels. My car (ZOE) sometimes drops the charge current briefly to 0 when changing the charge current. Also when using FAKE_SUNNY_DAY the available current dramatically drops and increases. This further made the calculation of the available current unstable. For this I needed an average value of the available current. Now switching from 0 to 1 to 3 phases and back is smooth.

[cvanlith]

Reverting previous commit, buffering IsumImport to overcome dropping charge currents is not necessary. My ZOE needs at least 8A, below that value it does start charging but the current regularly drops to zero. This causes the calculation of IsumImport to report unusable numbers. This in turn causes the timers to switch up and down the phases to be unreliable. This version now runs in production (only one EVSE no multi).

[dingo35]

Please don't think we don't appreciate your PR, but we have to concentrate on bringing out a stable v3.5.0 before adding new functionality. Hope you understand! You'll be first in line for v3.5.1 ...

[cvanlith]

Ok, I will redo the work, using smaller steps. Probably it is best to discard this Pull Request. I will come back later with a new one.

[dingo35]

Ok great; I like your coding style, but please avoid small beautifications (like e.g. making Force_Single_Phase_Charging returning bool instead of int).

That way we can concentrate on the essence of your PR, and see if there are unintended side effects; experience has learned it is very hard to keep all use cases in mind :-)