How to configure hysteresis for solar?

[bikeymouse]

When tracking green energy, I noticed that - even with "greenEnergyLatch" at 5 minutes, charging is started and stopped quite a lot on an intermittent cloudy day.

I therefore would like to start charging when I have 4 Amps solar surplus, and stop if it drops below 2 Amps for more then 5 minutes. The minimum amps for the TWC is 6, but I'm fine it draws the difference (being 2 to 4 amps) from the net.

I have now used these settings: "minAmpsPerTWC": 6 "greenEnergyFlexAmps": 4 and
"useFlexAmpsToStartCharge": true

But with this setting it starts and stops at 2 Amps surplus, making it quite nervous, even with the 5 minutes latching.

If I use "useFlexAmpsToStartCharge": false, then it will stop a 2 Amps, but only start at 6 Amps.

I have a feeling this might be solved with a policy, but can't see how.

[MikeBishop]

There isn't currently a way to have a policy trigger on a surplus, unfortunately, and the ability to trigger on generation itself depends on the specific EMS module -- you can't trigger on the number within TWCManager because it only queries for generation/consumption data when certain policies are active. If the EMS module exposes that information as a property, like the Powerwall module does, you can act on it directly; no module exposes the amount of surplus, and if one did it would miss any manual adjustments specified in the config.

So one solution for this scenario would be in the vein of some other issues @ngardiner has been looking at, polling for consumption/generation all the time and exposing a way to query those values in policy rules.

Alternatively, it sounds like you really want to specify a different flex value for starting vs. continuing to charge. That would be a smaller change -- perhaps adding the ability to specify the value as [2, 4]?

[bikeymouse]

There isn't currently a way to have a policy trigger on a surplus, unfortunately, and the ability to trigger on generation itself depends on the specific EMS module -- you can't trigger on the number within TWCManager because it only queries for generation/consumption data when certain policies are active.

I'm afraid I don't quite follow: the "Track Green Energy" policy already does that: it calculates the Solar Surplus as being "Generation - Consumption". And by polling the Generation and Consumption data from an EMS (I use Home-Assistant), it does trigger. It's just that I'd like it to have it done at different levels for starting and stopping.

So yes, the ability to specify the value for use greenEnergyFlexAmps [2,4) would work for me.

Having said that, I do realize that with the combination of the "minAmpsPerTWC" it may look a bit complicated, but it would work as follows:

Say I have minAmpsPerTWC = 6 and FlexAmpsToStartCharge [2,4) this would mean:

• wait until the (calculated) solar surplus is > 4 Amps, so that charging can start with the minimum 6 Amps, using the configured max [2] A "greenEnergyFlexAmps" from the net.
• then track the sun until the surplus drops down to < 2 Amps thereby exceeding the configured max [4] A "greenEnergyFlexAmps" that is needed from the net to achieve the minimum 6 Amps.
• Take the configured "greenEnergyLatch" time into account, and if that is expired too, then stop charging.

So this is a bit more subtle then (see my first post), the current situation where:

If I use "useFlexAmpsToStartCharge": false, then it will stop a 2 Amps, but only start at 6 Amps.

[MikeBishop]

I'm afraid I don't quite follow: the "Track Green Energy" policy already does that: it calculates the Solar Surplus as being "Generation - Consumption". And by polling the Generation and Consumption data from an EMS (I use Home-Assistant), it does trigger. It's just that I'd like it to have it done at different levels for starting and stopping.

Sorry -- getting a bit too much into the internals, perhaps. The policy rules decide when a particular policy is applicable. Track Green Energy is typically applicable based purely on time, from something like 6 AM to 9 PM. Once TGE is selected, it polls generation/consumption to decide how much to offer, and it might then decide to offer 0A even though the policy remains active.

Latching makes the policy continue to match even if the criteria are inconsistent. However, it does not force the policy to actually offer power if it's dynamically choosing how much to offer.

We currently don't start polling generation/consumption data until a policy is selected that relies on those values. However, if an EMS exposes custom values, those can be added as restrictions to keep a policy from even being selected until they match. That's a separate layer.

But yes, if we separated the flex into separate start/end values, it should behave as you've described. It's more useful to think of the "flex" as the maximum amount of current that can come from somewhere other than solar.

[JinbaIttai]

I had the same problem when I first started tracking solar, and wrote some code to deal with it I don't start charging until there's at least 7 amps available, and I have minAmpsPerTWC = "4", greenEnergyFlexAmps = "1" and "greenEnergyLatch" = 120 so it only stops charging if the rate drops below 3A for more than 2 minutes.

I've got the 7 Amps hardcoded in TWCSlave.py but I should make it a new configurable variable, and send a pull request here.

Any suggestions on what it should be called? or am I taking the wrong approach?

`

        if self.lastAmpsOffered == 0 and desiredAmpsOffered < 7: 
            # Don't start charging with less than 7 amps
            # will need to make a new variable to change this
            self.master.debugLog(
                1, # MK 
                "TWCSlave  ",
                "Don't start charging TWC: "
                + self.master.hex_str(self.TWCID)
                + " yet because: "
                + "Amps "
                + str(desiredAmpsOffered)
                + " < 7",
             )
            desiredAmpsOffered = 0

`

[ngardiner]

@JinbaIttai what's the purpose of setting minAmpsPerTWC to 4A? It does effectively exactly what your code does (unless I'm missing anything - I see you won't start charging with less than 7A but I assume you'll go as low as 5A during charging - 5A being the minimum that any TWC can support, hence why I'm wondering why you have minAmpsPerTWC set to 4 as the hardware isn't capable of it.

In your case, I'd just set minAmpsPerTWC to 7 and then flex amps to either 1 (to charge as low as 6A but only start at 7A) or 2 (for 5A charge and 7A start) depending on your hardware, EU TWC can only go as low as 6A.

[ngardiner]

Just as an aside, I am planning today to put together a page of config examples for how to do things such as charging only over a specific region of generated power (for those who are export limited), as well as a few flex examples as well. So knowing the background behind configs will allow us to use these as examples for others with similar requirements, since there are a lot of tunables and it's hard for users to know what to set and when.

[JinbaIttai]

My TWC will go much lower than 5A, as I discovered when I reported & fixed this bug: https://github.com/ngardiner/TWCManager/issues/143

I tried setting MinAmpsPerTWC to 7 and Flex to 3, but then it would be importing from the grid at up to 3A, which at 58c/kWh (peak tariff) gets very expensive fast.

Much better to reduce charging to 3A or 4A temporarily, while waiting for the sun to reappear from behind the cloud.

[ngardiner]

Just to confirm:

• Your logic says that the minimum amps that you'll charge with is 4A (which works for you because of your specific model of TWC) but you'll only start charging after 7A offered?
• You had different behaviour when setting flex to 3A and minAmpsPerTWC to 7... why is that? it should result in the same outcome.

Much better to reduce charging to 3A or 4A temporarily, while waiting for the sun to reappear from behind the cloud.

That's exactly what flexAmps allows you to do, it's just that most TWC owners (both single and 3 phase) cannot charge at less than 5A or 6A so they use flex to maintain 5A/6A of charge rate for short periods. You can charge at as low of a rate as you like, there's no drawing from the grid in your case (if I am understanding you correctly), you get to choose at what rate you start and maintain charge, the rest of us don't - we can't charge off of 4A. You can without drawing anything from the grid

[JinbaIttai]

Your logic says that the minimum amps that you'll charge with is 4A (which works for you because of your specific model of TWC) but you'll only start charging after 7A offered?

That is correct

You had different behaviour when setting flex to 3A and minAmpsPerTWC to 7

Yes, I then got the message "Flex Setting desiredAmps to minAmps 7" and was drawing from the grid. I haven't tested this in over 9 months so I don't know if this has been fixed since.

You can charge at as low of a rate as you like, there's no drawing from the grid in your case (if I am understanding you correctly),

That's it exactly, on cloudy days it starts at 7A and stops at 4A, with nothing drawn from the grid. If I had the same 5A limitation I'd probably want to start at 8A or 9A to get some hysteresis.

[ngardiner]

Okay, I'm following now, the idea of raising the threshold to charge to avoid hysteresis just wasn't that clear to me - in my experience I just fail to meet the minimum threshold on those days, but I can understand we all have different conditions and that might be the case in some environments.

Have you considered using the debounce feature in v1.2.2 to configure a threshold to tune out hysteresis automatically? The benefit I can see from this is that you wouldn't need to wait for the charge curve to cross a higher threshold to charge on a day with good weather:

        # If the system rapidly changes its mind about whether to start or stop charging,
        # this parameter keeps charging / not charging until the decision remains stable
        # for this many seconds.
        #"startStopDelay": 60,

Ultimately if we were to add a higher threshold to charge to avoid hysteresis in cloudy conditions, I'd like to see it tied in with a weather service such as OpenWeatherMap API (we already have an EMS integration for it, but for a slightly different use case) simply because for smaller systems, having to hit 9A to charge at 5A or 10A to charge at 6A seems like an excessive threshold to hit on non-cloudy days to begin charging - and then we'd get the benefit of knowing what the weather was (and reacting in other ways).

[JinbaIttai]

I find the charging efficiency on my Model S at lower amps isn't great, so am happy to start at 7A anyway - allowing it to drop as low as 4A is more about saving the contactors than trying to squeeze out every last milliwatt :)

And even on a winter's day like today, starting at 4A would have meant it started charging at 9:25am instead of 9:55am so I would have gained maybe an extra 500Wh at best.

I like your idea of tying into an API.
I use the free API from solcast.com to predict cloud cover and manually adjust my overnight (off-peak tariff) charging based on the amount of driving and daytime charging opportunities over the next few days. I'm still pondering how to automate that, perhaps by tying into my calendar as well.

[alexeiw123]

Alternatively, it sounds like you really want to specify a different flex value for starting vs. continuing to charge. That would be a smaller change -- perhaps adding the ability to specify the value as [2, 4]?

@MikeBishop I think this would be a great solution for now. I am using the recent consumption offsets feature to set a value in W for when charging will start (with a negative buffer set for the minimum charge power). I can successfully use a flex amps value of 1A to avoid hysteresis around the trigger point. Unfortunately this does mean I'm unnecessarily dipping in to exportable solar as my generation continues to increase.

I can get better optimised charging above the trigger point by removing the negative buffer and setting "useFlexAmpsToStartCharge": true however I can no longer avoid the hysteresis. Being able to set different values for starting vs. continuing charge would allow me to get the best of both configurations.