This question is for someone familiar with the GX algorithm that decides when to start adding PV Charger power to AC loads.
With this I mean in the mornings my PV Charger starts to charge my battery at full tilt and once it reaches ±10% above my SOC it diverts power to my AC loads with the remainder to continue charging the battery.
Here is the thing: In summer my PV Charger starts to charge with a huge bang very quickly and at around 10:30 my battery is full leaving me with wasted PV power while not feeding in.
Now what IF there is a way to modify the GX algorithm to say charge my battery from PV when it reaches only 1% above the SOC or even 0%? This way I will benefit from PV power assisting my AC loads and an hour later when it’s at full tilt then it diverts the extra power to charge the batteries?
So, where is that 10% exactly and can it be modified?
The algorithm uses a hysteresis of 3%. If the SOC goes 3% above the minimum, it switches to self-consumption.
But if you use BatteryLife, then this may sometimes turn into 8%. If the battery didn’t reach 95% or more yesterday, it increases the active soc limit by 5%, which means that tomorrow it might take a lift of 8% before it switches to self-consumption.
There isn’t really any way to change this other than manually switching to Optimised (without batterylife) and moving the MinSoc down (pushing it into self-consumption), or by messing with the above source code. And be careful, just modifying the constants can end the state machine in an unstable loop, they are chosen in a way that stops that from happening.
Edit: Specifically, look at the switch_on_soc property.
Interesting. My battery cycles from 100% to 30% (and drops to 29% due to a small DC load) each day and every morning at 39% (from 29%) it starts to assist with the AC loads. This happens every day except cloudy days if I don’t get to above 95%. I’ve never seen a change at 3% above SOC.
But thanks for the warning. I’ll have a look but won’t toy around too much for now.
Edit: Ok, looking at the code I can see the 10% This is really just a coincidence. From what I see it’s 29% SOC with Active SOC at 35% + 3% hysteresis and the operator is a > function meaning at 39% it changes to self consumption. Wow, exactly 10% above my 29% initial SOC value - go figure.
That’s also impacted somewhat by the CAN-bus protocol, which for whatever reason doesn’t make provision for a decimal value on the SOC, even though it has ample space to do so (but it does make provision for a decimal in the charge- and discharge current limits, in many ways this protocol is a little weird). In any case, with other hardware, such as the BMV, it allows for one decimal, so it switches to self-consumption at 38.1% in this example. Since my own system uses a BMV, I tend to forget about that…
I’ve had a similar situation with BL should I hit min SoC. Basically what I noticed was, regardless whether my batteries hit 100% the previous day, should I hit min SoC during the evening/morning, BL would increase the active SoC by 5%.
So say I had 40% min SoC, if I hit 40%, then the active SoC becomes 45% and I need to charge to 48% before PV gets used in the house. This is why I disabled BL, because on Optimised without BL it just needs the 3% above the static min SoC. I just found it weird that BL should care whether I hit my min SoC or not and ended up wasting 8% of my PV instead of just 3% (I would still fill my batteries the day, but I’ll never get the power I purchased back.
What I did … NodeRED with @Paul 's help … is to let the inverter run just just below the panel’s wattages, and then with HA, I increase the SOC in either 5% jumps, or 10% jumps, dependant on the time and loads per day.
Sometimes I have to wait that 3% out, on cloudy days, other days, the house is powered, batts are charged, SOC is ready for evening use.
We “spread” the load over the day, and to not hammer the batts either, Eskom is cheaper.
BUT, it may not work for everyone … works for me and Paul though.
All good comments. The SOC change to 20% is the one I tested this morning after I fixed the ‘slightly unstable’ state machine
Yip, that extra 5% comes in handy so I might just go without BL as weather on the reef is such that you will most likely not get 7 cloudy days unless there is another hurricane off the Moz coast.
That Node Red option is also on the radar but as a last resort.
There is a unit test (it uses nosetests) that sweeps through the entire range and makes sure the state machine cannot be in an ambiguous state, or rather, it does a sanity check so we know there’s at least no obvious dumb mistakes
I wouldn’t necessary say it is unstable, but it is sensitive to those constants. Some of them cannot be smaller than others, otherwise the state machine starts to flip-flop between two states.
I think the safest way is to remove BL and live with the 3% safety margin. What I saw by, in effect, ‘removing’ the 3% was a flip-flop between charging and assisting AC which I didn’t like.
One day, should I find the time again, I’ll implement a “managed” min SoC that will be higher than the min SoC in the GX. So for example, 35% vs. 30%. I already have the automation set up to run the battery down at a specified rate. I’ll then just adjust that automation to run the battery down to a minimum of the 35% (as per my example). Then I’ll never hit the 30% and be forced to “loose” the 3%.
The run-down of the battery will be managed through an inverter limit automation. Where I’ll have my maximum set to be the minimum of (some predefined maximum discharge I want to have - C/4 or something like that because I’m more anal than Pylontech) and (kWh capacity left before hitting 35% / hours left before sunrise).
Then I’ll cut out the 3% and also smooth my battery usage over the course of the entire evening and early morning.
