PV / Solar Excess Optimizer: Auto-control appliances (wallbox, dish washer, heatpump, ...) based on excess solar power

nukleuz80 · May 28, 2024, 6:42am

Hi, isn´t it possible to remove the logger in configuration.yaml?

cypresss · May 28, 2024, 7:08am

The entries in the logbook are generated by the pyscript integration:

github.com/custom-components/pyscript

Logbook Functionality

custom-components:master ← dlashua:logbook

opened 10:57AM - 29 Oct 20 UTC

dlashua

+102 -8

There might be a better way to do this instead of using `Function` like I have. …However, it works. A few things to note. * The event fired before the function runs can be named anything we want. I chose "pyscript_running" and then realized Home Assistant uses "automation_triggered". This can be renamed by changing it in both `trigger.py` and `logbook.py`. * While I have confirmed that `state.set()` is sending the correct context to the best of my knowledge, it seems that states set in this manner don't show up in the log book at all. The state still "sets" as expected, but there is no logbook entry. Therefore, all of the "context" code can be removed from `state.set()` if desired. * I've left the original context as part of the trigger function kwargs. This way, pyscript users can still look at `user_id` to determine who did something. Unfortunately, determining if **pyscript** did something would mean climbing the context tree, which is tedious. * I've also left context as an optional kwarg to `service.call` and `event.fire`. If a users passes a context, it'll use that. If they don't and we have one from the `pyscript_running` event we fired, it'll use that. If they want to disable the logbook functionality for some reason, they can pass `context=Context()`. * The logbook attributes actions to entity_ids. And entity ids can only have one "." between the domain and name. So I'm sending, essentially, `__name__`, with "." converted to "_". This means the entity_ids are a bit ugly (ex. `pyscript.file_myfile_myfunction`). This is set in `trigger.py` and can be changed to anything we want as long as it fits the rules for entity ids. I've tested events, service_calls, time triggers, and state.set with this code: ```python @state_trigger(["input_boolean.test_1"]) def test_state_trigger(**data): log.info("test_state_trigger") input_boolean.toggle(entity_id="input_boolean.test_2") state.set("binary_sensor.test", "on") @event_trigger("PYSCRIPT_TEST") def test_event_trigger(**data): log.info("test_event_trigger") input_boolean.toggle(entity_id="input_boolean.test_3") @state_trigger(["binary_sensor.test"]) def report_binary_sensor(**data): log.info(f"binary_sensor trigger with {data}") @time_trigger("startup") def test_time_trigger(**data): task.sleep(3) log.info(f"test_time_trigger {data}") input_boolean.toggle(entity_id="input_boolean.test_4") ``` It results in this logbook: ![logbook](https://user-images.githubusercontent.com/4126703/97559509-86680c80-19ab-11eb-88cf-f3852a51d2ab.png)

But I can’t find a way to disable them for the PV Excess script only.

Logbook or recorder exclusions in the configuration.yaml only work with entity IDs.

RienduPre · May 28, 2024, 10:33am

Help with my setup

I only get many of the same log items in my logboek

2024-05-28 12:22:16.250 DEBUG (MainThread) [custom_components.pyscript.trigger] trigger file.pv_excess_control.on_time got time trigger, running action (kwargs = {'trigger_type': 'time', 'trigger_time': datetime.datetime(2024, 5, 28, 12, 22, 16, 245653)})
2024-05-28 12:22:16.250 DEBUG (MainThread) [custom_components.pyscript.trigger] trigger file.pv_excess_control.on_time time_next = 2024-05-28 12:22:26.245653, now = 2024-05-28 12:22:16.250553
2024-05-28 12:22:16.251 DEBUG (MainThread) [custom_components.pyscript.trigger] trigger file.pv_excess_control.on_time waiting for 9.9951 secs
2024-05-28 12:22:16.266 DEBUG (MainThread) [custom_components.pyscript.eval] file.pv_excess_control.on_time: calling on_time(, {'trigger_type': 'time', 'trigger_time': datetime.datetime(2024, 5, 28, 12, 22, 16, 245653)})
2024-05-28 12:22:16.425 DEBUG (MainThread) [custom_components.pyscript.trigger] trigger file.pv_excess_control.on_time got time trigger, running action (kwargs = {'trigger_type': 'time', 'trigger_time': datetime.datetime(2024, 5, 28, 12, 22, 16, 423652)})
2024-05-28 12:22:16.426 DEBUG (MainThread) [custom_components.pyscript.trigger] trigger file.pv_excess_control.on_time time_next = 2024-05-28 12:22:26.423652, now = 2024-05-28 12:22:16.426245
2024-05-28 12:22:16.426 DEBUG (MainThread) [custom_components.pyscript.trigger] trigger file.pv_excess_control.on_time waiting for 9.99741 secs
2024-05-28 12:22:16.430 DEBUG (MainThread) [custom_components.pyscript.eval] file.pv_excess_control.on_time: calling on_time(, {'trigger_type': 'time', 'trigger_time': datetime.datetime(2024, 5, 28, 12, 22, 16, 423652)})
2024-05-28 12:22:17.104 DEBUG (MainThread) [custom_components.pyscript.trigger] trigger file.pv_excess_control.on_time got time trigger, running action (kwargs = {'trigger_type': 'time', 'trigger_time': datetime.datetime(2024, 5, 28, 12, 22, 17, 103568)})
2024-05-28 12:22:17.105 DEBUG (MainThread) [custom_components.pyscript.trigger] trigger file.pv_excess_control.on_time time_next = 2024-05-28 12:22:27.103568, now = 2024-05-28 12:22:17.104925
2024-05-28 12:22:17.105 DEBUG (MainThread) [custom_components.pyscript.trigger] trigger file.pv_excess_control.on_time waiting for 9.99864 secs

But nothing happens with my applicance?

Any help is more than welcome (I use the latest versions of all)

My automation yaml files is like this:

alias: Zwembad Warmtepomp PV excess optimizer
description: ""
use_blueprint:
  path: InventoCasa/pv_excess_control.yaml
  input:
    automation_id: "74075083"
    pv_power: sensor.actueel_zonnepanelen_opbrengst
    export_power: sensor.electricity_meter_energieproductie
    load_power: sensor.actueel_huis_gebruik
    home_battery_level: sensor.sessy_de7j_state_of_charge
    solar_production_forecast: sensor.solcast_pv_forecast_forecast_remaining_today
    actual_power: sensor.zwembad_total_power
    appliance_switch: input_boolean.zwembad_verwarming
    home_battery_capacity: 5

nukleuz80 · May 28, 2024, 12:46pm

I think your automation_id has to be the same with alias

EDIT: Check → PV / Solar Excess Optimizer: Auto-control appliances (wallbox, dish washer, heatpump, ...) based on excess solar power - #70 by InventoCasa

RienduPre · May 30, 2024, 2:22pm

Check !!!

That did the trick

Monster_D · May 31, 2024, 10:27am

wow … as the solcast integration is dead/deleted … what forecast method do you use for

solar_production_forecast: sensor.solcast_pv_forecast_forecast_remaining_today

and how happy are you with it?

Monster_D · May 31, 2024, 4:29pm

For now other users saved the work and keeping on with the solcast integration. Fingers crossed the api will not change to soon…

Reunion974 · June 2, 2024, 12:02pm

I use forecast.solar, it work fine.
I never used solcast as I’m out of its coverage area.

Mylua31 · June 2, 2024, 3:50pm

Hello,

I am testing this Blueprint, I made my frist automation but something is not working.

Calculated average excess power based on >> solar power - load power <<: 0 W

I use two sensors :

PW Power : sensor.envoy_consommation_electrique_actuelle, current state: 1.551 kW
Combined Import/Export Power : sensor.envoy_production_d_electricite_actuelle, current state : 0.512 kW

So the calculated excess power should not be null.

Can someone help me, please ?

techydude · June 3, 2024, 11:38am

Hi Juergen, me again
Could you please post the full entry for your sensor.new_charge_current_int is a template sensor?

Is this in templates.yaml? so:

sensor:
?

juergenjw · June 3, 2024, 11:46am

I created the sensor as template helper.

using the template from above.

cypresss · June 4, 2024, 10:49am

I have the exact same problem.

Was this ever solved for you over the last year?

Neroson · June 4, 2024, 2:53pm

Hi, first I would like to thank for this great Automation

any chance to implement 3-Phase to 1-Phase switching and vice versa?
Would be a great feature for a Wallbox.

Maik7 · June 7, 2024, 9:32pm

The issue is solved. Just update the script.

Reunion974 · June 8, 2024, 2:04pm

Hello @Maik7
I’m so happy, I can see that your 2 pull requests have been merged!

So there is no more issue with the dynamic priority?
We can use a template to define the priority in the automation and dynamicaly modify this priority, and then execute in the same script the PV automation to refresh with “service: automation.trigger” , right?
About the priority >1000:

You documented the priority adding:

If the priority is greater than 1000 this appliance will be switched on, even if the excess power is not sufficient for 100% of the needed power

Can you please precise the behaviour when prio > 1000 ?
Is the appliance ON while the solar panel produce 50% of the needed power? and then it is turned off? or is it different?
Also is it possible to modify the percentage??

Thank you so much

Maik7 · June 9, 2024, 2:15pm

Hi,
right now it is turned on, if there is any excess power. Using a threshold, e.g. 50% of the needed power, can cause unwanted behavior, if you have more than one appliance with priority>1000. And with three appliances it can cause oscillations. Think of two appliances with 100W/Prio 1100 and 10W/Prio 1200, and 65 75 W excess Power and 50% threshold for both.
The 10 W will be switched on and then the 100W, causing -35W excess power. As a consequence the higher prioritized 10W appliance will be switched off, which is most likely unwanted. And with three appliances you can have oscillations.

Therefore we need a more complex logic, if you want allow percentages of grid power. Any suggestions?

Maybe it is sufficient to limit the absolute grid power (same threshold for all appliances)?

Best,
Maik

Reunion974 · June 9, 2024, 2:46pm

humm, interesting point. I understand.

And what about this:

Lets say that when we turn on a 1000W appliance with prio>1000
the threshold is 50% → the system will consider that this appliance use 500W
but we also add a tolerance for 500W additional power (from the grid) while that appliance is on.

So in your example:
I have 75W (you meant 75 not 65) excess.
The system will turn on both appliances 10W and 100W
→ We have -35W excess
→ the “tolerance” is increased by 5+50 (prio appliance’s power * threshold )
So the “virtual excess” = excess + tolerance → -35+55 = 20W
All calculations have to be done with this “virtual” excess.

Problem: if at some point the real exces is 0 but the virtual excess is 500, the system may turn on some low prio appliances that I’d prefer to see off.

Solution? : the “virtual excess” prio could be used in the calculation of the appliances with high prio only. The decisions for other appliances would still be based on normal excess value.

What do you think?

Maik7 · June 9, 2024, 7:33pm

Hi,

I think it is still the same conflict. How to count a higher prio appliance, which can be covered 90% by the solar power and 10% grid power? Allow further appliances to be switched on, even if they use 100% grid power? And what is, if the solar power increases slightly, that the higher prio appliance can be covered 100% by solar power? Is it the same, if the lower prio appliance has a prio < 1000?
The topic is much more complex, than it looks in the first moment.

E.g. think of 1000W solar power and the highest prioritized appliance is using 800W. How much grid power is allowed? Is it the same, if we deactivate this 800W appliance and solar power is reduced to 200W by a cloud?

Maybe we have to collect the different aims, why users are using this script.

try to avoid using grid power.
try to use all available solar power

The 1st is for solar installations, which can cover all or most of the needed energy. The former version of the script is exactly for that use-case (and the current still is by using priorities <= 1000).

The 2nd is for small solar installations (in Germany “balcony power plants” are very popular, with up to 800W power). An installation which can only cover a fraction of the needed energy. For this I added the new method for priority > 1000.

What is exactly the use case to allow grid power as a fraction of the currently used solar power? If we can define a use case for this, it might be easier to find a good algorithm for this.

Maybe adding other features will add more benefit?

I have a pull request to switch off lower prioritized appliances to enable switching on higher prioritized. I think this is improving the script significantly.

For appliances like washing machines the usage of the expected solar power of the next hour(s) could be beneficial.

What also can be done with the actual implementation: I am calculating the priority of an appliance dependent on further parameters:

My fish tank heater priority depends on the time it is switched off (in detail: when the switch was on, but the heater did only consume negligible power).
same for my fridge (right now I am using a fridge simulator, but soon I will activate it). It has button to force “switch on” for 1 hour (and it will be only be switched off, if the power consumption indicates, that the fridge is not cooling any longer).
If I connect my e-bike charger, the priority will be rather low. But I can define a due date, when the e-bike shall be fully charged. (by pressing a button, single press: today, double: tomorrow, triple …) The priority increases if the due date gets nearer. If the due date is today or tomorrow I am using the expected solar power till due date (minus the typical power consumption) to calculate, if the solar power should be sufficient to charge the e-bike without using grid power. If not, I increase the priority > 1000

And they will be switched on if necessary even if the script says “no”.

This means: even with the actual implementation it is possible, to realize complex automatons.

Reunion974 · June 10, 2024, 4:33am

A completely agree with your analysis.

Your 2nd use case can apply to many different solar installation regardless of the size. Actualy any installation that do not produce enough to cover their needs or without a satisfying electricity selling price. I’l lgive you an example with my setup:

For the moment I can not sell my production, so everything that is not used is lost. Later I will be allowed to sell my exceed to the solar provider but the price will be quite low.
→ So it’s more interesting to use all my production than to sell it.

In my case, I have a 6kWc production but my swiming pool filter use 1600W. If I use the heat pump it’s +2000W. When I charge my car it’s 1.8 to 3.5kW.
→ So my production can not cover all my consumption and I should use almost every Watt produced

So your description of use case #2 is just fine. “try to use all available solar power”.

The possibility to dynamicaly modify the priority is certainly a part of the solution.
Like you, I tend to automaticaly swith the priority:

if the swiming pool is covered, the water is protected from sun → chlorine is not destructed by UV → the water need less filtration.
So if cover ON → priority=200, if cover OFF → priority=400
Later I’ll also implement something to make sure the pool is filtered enough each day, so the prio will increase if an objective is not reached. Similar to your due date but inside each 24h cycle.
if the car is empty I need to urgently charge it. The more the battery is filled, the lower the priority become.
So I defined differents levels of priority that can be automaticaly set depending on the battery charge level. The highest level → grid charge, the level before → priority > 1000

That’s really funny because as you can see, we are in a very very similar situation even if our setups are completely different → it means that many other persons will enjoy your solutions

As you can see, in my case, your 2 pull request changed the game and now I really start enjoying this integration.
An improvement would be to have 2 settings for the priority > 1000 (why not 1000 and 2000 ?).

Teemops2806 · June 11, 2024, 8:00am

Hi there, this is exactly what I was looking for…but - old problem…I am still new to this…
I cannot get it work…
Installed everything - blueprint an pythonscript…get no errors - so far, fine.
I created two automations, for washing machine and dryer, connected via two shelly plugs.
They simply dont get activated, but enough power is there (battery level is ok, load is ok…everything fine).
I dont know where to start with debugging.
Perhaps theres anybody who could help?
I set debug level in config.yaml, but I dont see special debug messages, just the normal “file_pv_excess_control_on_time has been triggered by time”

Hier mal aktuelle Auszüge aus dem Log:

2024-06-11 15:00:11.553 ERROR (MainThread) [custom_components.pyscript.file.pv_excess_control.on_time] Could not update Export/PV history!: Could not update Export/PV history PvExcessControl.export_power=sensor.sonnenbatterie_235801_production_output | PvExcessControl.pv_power=sensor.sonnenbatterie_235801_production_input | PvExcessControl.load_power=sensor.sonnenbatterie_235801_consumption_w = export_pwr_state=None | pv_power_state=None | load_power_state=514.0
2024-06-11 15:00:11.564 DEBUG (MainThread) [custom_components.pyscript.file.pv_excess_control.on_time] [switch.waschmaschine_switch_0 automation.waschmaschine_pv (Prio 10)] Home battery charge is sufficient (5115.0/20.0 %) OR remaining solar forecast is higher than remaining capacity of home battery. Calculated average excess power based on >> solar power - load power <<: 0 W
2024-06-11 15:00:11.566 DEBUG (MainThread) [custom_components.pyscript.file.pv_excess_control.on_time] [switch.waschmaschine_switch_0 automation.waschmaschine_pv (Prio 10)] Appliance is already switched on.
2024-06-11 15:00:11.568 INFO (MainThread) [custom_components.pyscript.file.pv_excess_control.on_time] [switch.waschmaschine_switch_0 automation.waschmaschine_pv (Prio 10)] Application has run for 3.8 minutes
2024-06-11 15:00:11.578 DEBUG (MainThread) [custom_components.pyscript.file.pv_excess_control.on_time] [switch.trockner_switch_0 automation.trockner_pv (Prio 10)] Home battery charge is sufficient (5115.0/20.0 %) OR remaining solar forecast is higher than remaining capacity of home battery. Calculated average excess power based on >> solar power - load power <<: 0 W
2024-06-11 15:00:11.581 DEBUG (MainThread) [custom_components.pyscript.file.pv_excess_control.on_time] [switch.trockner_switch_0 automation.trockner_pv (Prio 10)] Appliance is already switched on.
2024-06-11 15:00:11.583 INFO (MainThread) [custom_components.pyscript.file.pv_excess_control.on_time] [switch.trockner_switch_0 automation.trockner_pv (Prio 10)] Application has run for 3.7 minutes
2024-06-11 15:00:11.586 DEBUG (MainThread) [custom_components.pyscript.file.pv_excess_control.on_time] [switch.trockner_switch_0 (Prio 10)] Average Excess Power (0 W) is still greater than minimum excess power (-10 W) - Doing nothing.
2024-06-11 15:00:11.590 DEBUG (MainThread) [custom_components.pyscript.file.pv_excess_control.on_time] [switch.waschmaschine_switch_0 (Prio 10)] Average Excess Power (0 W) is still greater than minimum excess power (-10 W) - Doing nothing.
2024-06-11 15:00:21.552 ERROR (MainThread) [custom_components.pyscript.file.pv_excess_control.on_time] Could not update Export/PV history!: Could not update Export/PV history PvExcessControl.export_power=sensor.sonnenbatterie_235801_production_output | PvExcessControl.pv_power=sensor.sonnenbatterie_235801_production_input | PvExcessControl.load_power=sensor.sonnenbatterie_235801_consumption_w = export_pwr_state=None | pv_power_state=None | load_power_state=514.0
2024-06-11 15:00:31.552 ERROR (MainThread) [custom_components.pyscript.file.pv_excess_control.on_time] Could not update Export/PV history!: Could not update Export/PV history PvExcessControl.export_power=sensor.sonnenbatterie_235801_production_output | PvExcessControl.pv_power=sensor.sonnenbatterie_235801_production_input | PvExcessControl.load_power=sensor.sonnenbatterie_235801_consumption_w = export_pwr_state=None | pv_power_state=None | load_power_state=514.0
2024-06-11 15:00:41.546 ERROR (MainThread) [custom_components.pyscript.file.pv_excess_control.on_time] Could not update Export/PV history!: Could not update Export/PV history PvExcessControl.export_power=sensor.sonnenbatterie_235801_production_output | PvExcessControl.pv_power=sensor.sonnenbatterie_235801_production_input | PvExcessControl.load_power=sensor.sonnenbatterie_235801_consumption_w = export_pwr_state=None | pv_power_state=None | load_power_state=437.0
2024-06-11 15:00:51.550 ERROR (MainThread) [custom_components.pyscript.file.pv_excess_control.on_time] Could not update Export/PV history!: Could not update Export/PV history PvExcessControl.export_power=sensor.sonnenbatterie_235801_production_output | PvExcessControl.pv_power=sensor.sonnenbatterie_235801_production_input | PvExcessControl.load_power=sensor.sonnenbatterie_235801_consumption_w = export_pwr_state=None | pv_power_state=None | load_power_state=437.0
2024-06-11 15:01:01.550 ERROR (MainThread) [custom_components.pyscript.file.pv_excess_control.on_time] Could not update Export/PV history!: Could not update Export/PV history PvExcessControl.export_power=sensor.sonnenbatterie_235801_production_output | PvExcessControl.pv_power=sensor.sonnenbatterie_235801_production_input | PvExcessControl.load_power=sensor.sonnenbatterie_235801_consumption_w = export_pwr_state=None | pv_power_state=None | load_power_state=437.0
2024-06-11 15:01:11.548 ERROR (MainThread) [custom_components.pyscript.file.pv_excess_control.on_time] Could not update Export/PV history!: Could not update Export/PV history PvExcessControl.export_power=sensor.sonnenbatterie_235801_production_output | PvExcessControl.pv_power=sensor.sonnenbatterie_235801_production_input | PvExcessControl.load_power=sensor.sonnenbatterie_235801_consumption_w = export_pwr_state=None | pv_power_state=None | load_power_state=391.0
2024-06-11 15:01:11.559 DEBUG (MainThread) [custom_components.pyscript.file.pv_excess_control.on_time] [switch.waschmaschine_switch_0 automation.waschmaschine_pv (Prio 10)] Home battery charge is sufficient (5115.0/20.0 %) OR remaining solar forecast is higher than remaining capacity of home battery. Calculated average excess power based on >> solar power - load power <<: 0 W
2024-06-11 15:01:11.561 DEBUG (MainThread) [custom_components.pyscript.file.pv_excess_control.on_time] [switch.waschmaschine_switch_0 automation.waschmaschine_pv (Prio 10)] Appliance is already switched on.
2024-06-11 15:01:11.564 INFO (MainThread) [custom_components.pyscript.file.pv_excess_control.on_time] [switch.waschmaschine_switch_0 automation.waschmaschine_pv (Prio 10)] Application has run for 4.8 minutes
2024-06-11 15:01:11.571 DEBUG (MainThread) [custom_components.pyscript.file.pv_excess_control.on_time] [switch.trockner_switch_0 automation.trockner_pv (Prio 10)] Home battery charge is sufficient (5115.0/20.0 %) OR remaining solar forecast is higher than remaining capacity of home battery. Calculated average excess power based on >> solar power - load power <<: 0 W
2024-06-11 15:01:11.573 DEBUG (MainThread) [custom_components.pyscript.file.pv_excess_control.on_time] [switch.trockner_switch_0 automation.trockner_pv (Prio 10)] Appliance is already switched on.
2024-06-11 15:01:11.575 INFO (MainThread) [custom_components.pyscript.file.pv_excess_control.on_time] [switch.trockner_switch_0 automation.trockner_pv (Prio 10)] Application has run for 4.7 minutes
2024-06-11 15:01:11.579 DEBUG (MainThread) [custom_components.pyscript.file.pv_excess_control.on_time] [switch.trockner_switch_0 (Prio 10)] Average Excess Power (0 W) is still greater than minimum excess power (-10 W) - Doing nothing.
2024-06-11 15:01:11.582 DEBUG (MainThread) [custom_components.pyscript.file.pv_excess_control.on_time] [switch.waschmaschine_switch_0 (Prio 10)] Average Excess Power (0 W) is still greater than minimum excess power (-10 W) - Doing nothing.
2024-06-11 15:01:21.550 ERROR (MainThread) [custom_components.pyscript.file.pv_excess_control.on_time] Could not update Export/PV history!: Could not update Export/PV history PvExcessControl.export_power=sensor.sonnenbatterie_235801_production_output | PvExcessControl.pv_power=sensor.sonnenbatterie_235801_production_input | PvExcessControl.load_power=sensor.sonnenbatterie_235801_consumption_w = export_pwr_state=None | pv_power_state=None | load_power_state=391.0
2024-06-11 15:01:31.552 ERROR (MainThread) [custom_components.pyscript.file.pv_excess_control.on_time] Could not update Export/PV history!: Could not update Export/PV history PvExcessControl.export_power=sensor.sonnenbatterie_235801_production_output | PvExcessControl.pv_power=sensor.sonnenbatterie_235801_production_input | PvExcessControl.load_power=sensor.sonnenbatterie_235801_consumption_w = export_pwr_state=None | pv_power_state=None | load_power_state=391.0
2024-06-11 15:01:41.552 ERROR (MainThread) [custom_components.pyscript.file.pv_excess_control.on_time] Could not update Export/PV history!: Could not update Export/PV history PvExcessControl.export_power=sensor.sonnenbatterie_235801_production_output | PvExcessControl.pv_power=sensor.sonnenbatterie_235801_production_input | PvExcessControl.load_power=sensor.sonnenbatterie_235801_consumption_w = export_pwr_state=None | pv_power_state=None | load_power_state=400.0
2024-06-11 15:01:51.550 ERROR (MainThread) [custom_components.pyscript.file.pv_excess_control.on_time] Could not update Export/PV history!: Could not update Export/PV history PvExcessControl.export_power=sensor.sonnenbatterie_235801_production_output | PvExcessControl.pv_power=sensor.sonnenbatterie_235801_production_input | PvExcessControl.load_power=sensor.sonnenbatterie_235801_consumption_w = export_pwr_state=None | pv_power_state=None | load_power_state=400.0

Ok, now I saw, that the automation id was still not correct…made some changes and I got a little further, as shown above, in the log.
I changed the entity id and triggered the automations again, but I still get errors. And I dont know, how to fix the error messages. Thanks for some help.

Best regards,