oscillating bahavior - Githubissues

Maik7 commented 4 months ago

Hi,

right now I am testing the script mainly with some simulations. I simulate a fish tank heater (very low appliance_switch_interval), a fridge (high appliance_switch_interval), one or more e-bike battery charger (medium appliance_switch_interval) and real e-bike charger. In one simulation I ended up with an oscillating behavior. This means two appliances were permanently switched on and off. I think this was caused by two different issues:

If an appliance is switched off, its last known power consumption is subtracted from some history power values (appliance_switch_interval times). But both, my real e-bike charger and my e-bike charger simulator increases the power consumption slowly. And as the power consumption was to high for the solar power, it was switched off. But at the history not the real power consumption is "corrected", but the last power consumption is added for a longer period of time. Therefore, the later calculated avg_excess_power is too high and another appliance is switched on.
if an appliance A is switched on, the history power values are reduced by the power needed by this appliance A, but only for A.appliance_switch_interval. But the next appliance B with much higher appliance_switch_interval will calculate the average over a much higher time span, where the rather short A.appliance_switch_interval reduced history values will cause only a small reduction due to the recently switched appliance A. This causes B to be switched on, even if in reality the excess power (due to switched on A) is not sufficient.

Therefore I suggest:

either calculate avg_excess_power always for the same time span, independent from the individual instances and correct the history for this time span if an appliance is switched on. I understand the concept to only switch on an appliance, if the conditions are met for appliance_switch_interval as this is maybe the best prediction, if the conditions will be met for the next appliance_switch_interval , but on the other hand excess power for appliance_switch_interval is the consequence. in most scenarios.
or correct the history for the complete history if an appliance is switched on.

if an appliance is switched off

correct the history by the real history power consumption of this appliance. This means, a history for this power consumption need to be added. Initially it should be filled with the power the history was corrected, as the appliance was switched on.
don't correct the history at all. But his will cause to not switch on the next appliance with a high appliance_switch_interval. In combination with a short time span for avg_excess_power this can work. If avg_excess_power is calculated for individual time spans, I would prefer to store the history for each appliance.

Maik7 commented 3 months ago

@InventoCasa I tested this

don't correct the history at all. But his will cause to not switch on the next appliance with a high appliance_switch_interval. In combination with a short time span for avg_excess_power this can work.

in combination with a limiting of the history evaluation to a maximum of 6 entries.

It seem to work well. What do you think? Shall I create a PR? But it is a change in the concept of having longer history data to decide, if an appliance should be switched on. The approach of having a history for each appliance and (in case of switching off one appliance) to correct the overall history by just this appliance history fits better to the actual concept.

Maik7 commented 3 months ago

One further thought: The function _adjust_pwr_historyis updating the history in the case we switch an appliance on or off. This is absolutely necessary to not switch more appliances, than the excess power will cover. But we update the history only for a limited period of time, and this time is different for the different appliances (inst.appliance_switch_interval). This means, if we switch on a appliance with low inst.appliance_switch_interval, it is possible, that another appliance with a high inst.appliance_switch_interval will be switched on, too, even if the excess power is not sufficient any longer.

ppuschmann commented 3 months ago

I experience also the issue of the oscillation.

On a perfect sunny day my car will charge for 5 minutes (my standard switch interval set in the automation) and then switch off for 5 minutes, then on again.

Observation: the dynamic current is configured to the max, when the device is in status "off" (e.g. in the night), this is odd.

When there's enough excess power, the wallbox is switched on and the current will increase a bit, until it reaches some plateau. After some time the wallbox will get switched off, then everything starts again.

In my implementation I use a helper-value to store the dynamic current. With the help of a second automation I write the dynamic current to my wallbox upon every change of the helper-value. My wallbox only understands integer-values, so I use this snippet: "{{states('input_number.wallbox_strom_dynamisch') | int }}" to write only integer values. In this case |int will do some rounding down, so my wallbox shouldn't draw to much energy.

So why does the automation switch off the wallbox?

Maik7 commented 3 months ago

Hi Paul, can you change the logging to debug and check the log file around the switch off event? And can you add a plot of the excess power? (Is the excess power reaching zero at the moment of switching off?)

ppuschmann commented 3 months ago

... found out now, that I got also heavily confused with Current and Power in this automation. --> setting the "Appliance typical current draw" and "Minimum dynamic current" to something like 6 A. --> Should've been ~8.7A, which is 6kW (on 3 phases)?

And the car only starts with 6kW.

ppuschmann commented 3 months ago

@Maik7 Here's some gist https://gist.github.com/ppuschmann/68f504476936543d24f2f805857f907b for the time from 9:10h to 10:40h in TXT and JSON format.

Did I say I love Grafana Cloud? :-)

Maik7 commented 3 months ago

Hi, btw, the issue seem to be similar to #42 the logfile shows, how the current is increased step by step. This is last step, before switching off: 2024-06-24 10:13:36.136 2024-06-24 10:13:36.127 INFO (MainThread) [custom_components.pyscript.file.pv_excess_control.on_time] [switch.eh37hcr4_charger_enabled automation.wallbox_pv_charging1 (Prio 500)] Setting dynamic current appliance from 11.8 to 12.100000000000001 A per phase. The automation reports, that the excess power should be reduced by 207W to approx 232W. But at the next reading one minute later, the excess power is negative, -719W. You wrote, that the charger only can be controled in 1A steps, resulting in 1A change instead of expected 0.3A. Now the automation should try to reduce the power consumption, but it is reporting a wrong current consumption:

2024-06-24 10:14:37.118 2024-06-24 10:14:37.114 DEBUG (MainThread) [custom_components.pyscript.file.pv_excess_control.on_time] Adjusting power history by 8.24400043487549.
2024-06-24 10:14:36.115 2024-06-24 10:14:36.112 INFO (MainThread) [custom_components.pyscript.file.pv_excess_control.on_time] [switch.eh37hcr4_charger_enabled automation.wallbox_pv_charging1 (Prio 500)] Application has run for 7326.0 minutes
2024-06-24 10:14:36.115 2024-06-24 10:14:36.112 INFO (MainThread) [custom_components.pyscript.file.pv_excess_control.on_time] [switch.eh37hcr4_charger_enabled automation.wallbox_pv_charging1 (Prio 500)] Switched off appliance.
2024-06-24 10:14:36.115 2024-06-24 10:14:36.112 DEBUG (MainThread) [custom_components.pyscript.file.pv_excess_control.on_time] [switch.eh37hcr4_charger_enabled automation.wallbox_pv_charging1 (Prio 500)] Current power consumption: 8.24400043487549 W
2024-06-24 10:14:36.114 2024-06-24 10:14:36.111 DEBUG (MainThread) [custom_components.pyscript.file.pv_excess_control.on_time] [switch.eh37hcr4_charger_enabled (Prio 500)] actual_current=0.0A | diff_current=-1.0A | target_current=6.0A
2024-06-24 10:14:36.114 2024-06-24 10:14:36.111 DEBUG (MainThread) [custom_components.pyscript.file.pv_excess_control.on_time] [switch.eh37hcr4_charger_enabled (Prio 500)] Average Excess Power (-719 W) is less than minimum excess power (-10 W).

The automation is reporting a power consumption of 8W. How did you define the actual power? Maybe it is in kW or A and not in W?

@InventoCasa Even if this fixes this unwanted switching off, it will still cause oscillations and will cause to switch off all lower prioritized appliances before reducing the power. I think we should add a current_step_size parameter and replace the fixed 0.09 in if amps > (prev_amps+0.09): with it and always round down the set_current.

ppuschmann commented 3 months ago

The automation is reporting a power consumption of 8W. How did you define the actual power? Maybe it is in kW or A and not in W?

You are totally right! The entity for "Appliance actual power sensor" is actually showing kW values! Since this is technically still Watts I didn't question this. Thank you.

I'll try to change this and wait for the the next sunny day (and a non-charged car).

ppuschmann commented 3 months ago

Okay, the first tests are showing: everything is working as planned.

I'd like to conclude this with the german phrase "Kaum macht man es richtig, funktioniert es auch schon." :-)

ppuschmann commented 3 months ago

... found out now, that I got also heavily confused with Current and Power in this automation. --> setting the "Appliance typical current draw" and "Minimum dynamic current" to something like 6 A. --> Should've been ~8.7A, which is 6kW (on 3 phases)?

And the car only starts with 6kW.

This was total crap, again.

The car has a minimum current of 6A (three phases), which is then 4,2kW.

Again: entering the correct values helps.

Maik7 commented 3 months ago

Hi, did you had a situation, where the solar power was to low to charge the car with full power? If yes, I would be interested in a plot of the power over time. Is the power oscillating? Best, Maik

sirfalo commented 2 months ago

Not sure if this is what you are looking for, but in my case I have something like this: Bezik is car name (just FYI)

As you see, no clouds, so generation of PV is slowly increasing, but still there are big oscillations. I guess that problem is that it set's incorrectly dynamic current bit too high so this leads to negative value. I've changed now voltage from 235 to 240V, maybe this will help with calculations at the end (but this is blind guess which I can check next time car will need to be charged. In previous version of this BP I didn't see such problem...

I have to say that this is very annoying, as I'm not sure how such changes will affect battery life...

Maik7 commented 2 months ago

@sirfalo Thank you for the plot. It seems, that if the automation tries to reduce the power, it always reduces to 5A. Is 5A the minimum Current, you can choose? To understand the problem the log (debug) could be helpful. In principle it could be the same cause as at ppuschmann. The way the automation calculated the step to decrease the power is totally different from the way it increases power. "Appliance actual power sensor" is only used for decreasing the power, therefore a wrong setup / wrong value can cause high jumps, if the power should be reduced by a small step.

sirfalo commented 2 months ago

Hi

I have minimum current set for 5A as this is recommended minimum current for Tesla charging. I played even with 1A, but this didn't change anything. Today I've checked with setup "only ON appliance" and it works better (i've changed this around 14? I think, but I can't remember). On graph I added red lines so you can eaisly see and I marked:

Nice increase of charging power.
Unknown lack of current reduction. PV is very low, but charging current is around 12A while minimum should be 5A.
Turning off charging when PV is too low instead of dropping to 5A (I understand that this is intentional behaviour.

Compared to previous graph which I attached, I've reloaded completely HA, changed to 240V and time between change to 10 min from 1 min.

I've also attached log with debug.

home-assistant.log

ppuschmann commented 2 months ago

Hi, did you had a situation, where the solar power was to low to charge the car with full power? If yes, I would be interested in a plot of the power over time. Is the power oscillating?

@Maik7 I could try to dig into some plots. For me personally the situation improved after I finally entered the correct values.

Hint for @sirfalo : Did you check if all of your units are 100% matching? I for example needed to create some extra value for "Appliance actual power sensor", because the sensor of my wallbox reported in kW (like values of 4,2 and similar) where I actually needed a sensor with real W (like values of 4200).

sirfalo commented 2 months ago

Hint for @sirfalo : Did you check if all of your units are 100% matching? I for example needed to create some extra value for "Appliance actual power sensor", because the sensor of my wallbox reported in kW (like values of 4,2 and similar) where I actually needed a sensor with real W (like values of 4200).

Hi

No, I have correct setup of values, in W.

sirfalo commented 2 months ago

Hi Small update - today is perfect sun, but now I see different behavior:

Program is calculating in some weird way solar excess. I have -1600 up to -1900 (between 9:00 and 9:10as I have 5 min as update time) and it is calculating value (based on logs) as 4-07-26 09:09:13.518 DEBUG (MainThread) [custom_components.pyscript.file.pv_excess_control.on_time] [switch.bezik_charger (Prio 1)] Average Excess Power (616 W) is still greater than minimum excess power (-10 W) - Doing nothing.

And here are the logs again:

log.txt

I noticed that whenever something is working incorrectly then I need to restart system (not just HA) and then it starts to work OK. Today disconnection of car for 3h made it working again weird.

ppuschmann commented 2 months ago

@sirfalo so you use the "Combined Import/Export Power" sensor, I guess?

Maybe create some extra (template) sensors and configure the automation with the separate "Export Power" and "Load Power" sensors?

sirfalo commented 2 months ago

Hi

Honestly my knowledge how to create such template is too small...

Maik7 commented 1 month ago

And here are the logs again:

log.txt

Hi, the log shows, that the script permanently tries to increase the dynamic current in .1A Steps, e. g. from 6A to 6.8A. The power history gets "corrected" accordingly, but the script fails to increase the current, as the current can only be change in steps of 1A, not 0.1A. But the step of 0.1A is hardcoded in the script. @InventoCasa what do you think, should this step size better be configured?

InventoCasa / ha-advanced-blueprints

oscillating bahavior #66