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

Hi I have a question.
I added one device now for testing.
Its comsuming ~450W.
Solar Charger was around 5,5kW.
Consumption was around ~6,5kW. (5,5kW) was the manually started Heatpump.
Akku was decharing with the difference and at 80%.
Forecast was high enough to get it full until evening, but only if I would turn of the manually turned on heat pump in time.
For some Reason it just started my added device even when the battery was already decharing.
Should it not keep the device off until the battery is at least not getting decharged?

Hi @tomcat ,

yes, normally nothing should be started when there is not enough PV excess.
I suspect that you did not pass the correct measurement for the Load Power or some of the other crucial sensors.
Do not use the combined import/export sensor when you have a hybrid inverter with battery. Otherwise the script cannot detect when your battery is discharging to compensate for a load.

If that was not the problem: You can also show an excerpt of the debug log so that I can help you finding the problem. If you set the log level to debug (according to instructions in the first post), you should see a lot of debug messages in your Home Assistant Logfile.

1 Like

Thanks for the suggestions @RoyBlatch1 !

  • 1+2: Thanks for the info, I will consider implementing this at some point to make the calculations more precise.
  • 3: Within the code, I already have a little fixed correction which could be made configurable through the blueprint. However at the moment, I am waiting for user reports if this is really something which needs to be made configurable (since the blueprint is growing and growing, I try to keep it still not overloaded with configuration options)
  • 5: The forecast is updated everytime the solcast sensor is updated; if you use the standard settings when installing the solcast integration, you should be out-of-request around noon. While this does not seem to be a big problem (the forecast from noon is then used for the rest of the day), I could include a small hint in the blueprint regarding this pitfall.
  • 6: Yes, such an implementation is definitely coming. I will make it universally usable, so that you can pass a sensor, and define a number “target” for this. So for pool pumps you could pass the runtime of the current day, and as target you could set 4 for 4 hours. Another example: For EVs, you can pass the battery level, and set a target of e.g. 50, which then means “charge to EV always to at least 50% regardless of solar power.”
  • 7: I guess such an approximation of the excess power could simply be made based on the solar forecast. Seems like a few users have this situation, that they cannot export to grid (or only export a fixed amount). I will think about implementing an approximation based on solar forecast for this situation.
1 Like

Simple question. How do you calculate * Solcast today remaining forecast?
It seems very tricky since you only have 12hr / 24hr , curent and next hr forecasts.

@GregEdge The Solcast integration provides this out of the box.

2 Likes

Hi everyone.
installation and so on went ok so far, but…
what i have to enter here:

Automation name

**[IMPORTANT]
This field must contain the same name/entity_id you defined for this automation.
The name must be unique!
You can check your automation entity ID by clicking on the three dots in the top right corner of your automation editor and selecting info → settings. **

When i click on the “dots” there is no “info…”
Do i have to create an automation first? I thought this script creates automations.?

@DevilDago

Thanks. I was using forecast.solar which didnt provide that detail. I’ve added Solcast integration.

Does your python script action the api to get the remaining production figure? I ask as there are only 10 calls allowed each day.

thanks

@GregEdge No, the python script only uses the sensor. It does not poll the Solcast API, that is done within the Solcast integration itself (or manually, if you disabled auto polling when setting up the Solcast integration)

thanks, I’ll investigate the Solcast Integration and see what I can do.

Thanks for your input_number update bro.
I now created an automatisation with your blueprint using a Helper Switch (that runs the service keba.enable / disable) and an input_number to set the current.
For my input_helper I created an automatisation:
Edit: Check my next post for possible solition

alias: PVKeba CurrentÄnderung
description: startet den Dienst Keba.SetCurrent nach Wertänderung der Helper Variable
trigger:
  - platform: state
    entity_id:
      - input_number.kebacurrent
condition: []
action:
  - service: keba.set_current
    data:
      current:
        "[object Object]": null
mode: single

But, the action part should llok like this:

service: keba.set_current
data:
  current: {{ states('input_number.kebacurrent') }}

Everytime I change in yaml, it gets back to object object null.
What is wrong here?
The original keba.setcurrent (without my varaible) looks like this:

service: keba.set_current
data:
  current: 6.5
1 Like

Ah. I think I got it.

  - service: keba.set_current
    data:
      current: 'input_number.kebacurrent' 

Atleast it stays saved in the automatisation (no object object stuff). And I can perform this service without any error.
So hopefully everything works if I plug my car tomorrow.

Is there any need to create an automatisation to check if a car is connectedfor activating / deactivating the car loading automatisation?
Im not sure if its a problem if I run keba.enable / keba.disable without any reason (e.g. when no car is connected to the box)

@TheSmurf your first approach was nearly correct, you just forgot the quotes. The second approach will definitely not work.

It should be

"{{ states('input_number.kebacurrent')|float(0) }}"

Regarding your second question: No that’s not necessary. Enabling your wallbox while no car is connected has no effect.

Thanks.
But float (0) rounds to 0 decimal places, doesnt it?
I think your Script Returns atleast 1 decimal char for setting the load Power in A.
So I should use float(1), or Just float(If possible)?

Hi @TheSmurf,

No. float(0) means, convert to float if possible. If the conversion fails, e.g. because the entity is unavailable, the default value will be set (0).

round(0) would round to 0 decimal places.

Have i misconfigured something to cause these errors?
’ Logger: custom_components.pyscript.file.pv_excess_control.on_time
Source: custom_components/pyscript/trigger.py:1268
Integration: Pyscript Python scripting (documentation, issues)
First occurred: April 16, 2023 at 4:56:00 PM (483 occurrences)
Last logged: 7:03:00 AM

  • Exception in <file.pv_excess_control.on_time> line 195: if home_battery_level >= PvExcessControl.min_home_battery_level or not self._force_charge_battery(): ^ TypeError: ‘>=’ not supported between instances of ‘NoneType’ and ‘float’
  • Exception in <file.pv_excess_control.on_time> line 428: for a_id, e in dict(sorted(PvExcessControl.instances.items(), key=lambda item: item[1][‘priority’])): ^ ValueError: too many values to unpack (expected 2) ’

Could this be caused because the integration I use to get the data is via modbus and occassionally tcpip times out so the entities are not populated or get null or not available?

Yes, the first error is caused by None values for battery_level. If that happens only sporadically with your modbus connection, then it is nothing to worry about, since the script will run in the background every minute.

The second error is a bug which occurs when your remaining solar excess is just enough to charge the home battery to the specified level. I just pushed a little bugfix to the repo to solve this.

1 Like

Hey hey
Im afraid I got a big issue.
Yesterday I did setup the Blueprint for my wallbox, as discussed here.
Today after pluging my car I found out it isnt working.
It looks like it turns on the charger, but doesnt set a charging.current. (On off is hard to determine, because there is lot of sunpower today)
But also none of my other automatisations work (which worked perfectly fine so far).
Im kinda sure they also worked after I manually updated the blueprint and the python file.
So im quite sure, last change before my automatisation didnt work anymore was setting up the Wallbox blueprint.
I tried following:

  1. Execute all automatisations
  2. Delete Wallbox Blueprint and execute all other automatisations
  3. Restart the complete HomeAssistant

But still nothing is working here.
Is there anything I possibly made wrong?
Or what do you need to find a bug possibly?

Here is what I have:
I got 10 automatisations from your blueprint:
my LaptopCharger (prio2)
8x aquarium heaters (all prio3)
and an infrared heater (prio4)
all of them use shelly plugs, so basically all created automatisations are the same.
e.g. for a heater:

alias: PVSteckdoseHeizer21
description: ""
use_blueprint:
  path: pv_excess_control.yaml
  input:
    automation_id: PVSteckdoseHeizer21
    appliance_priority: 3
    pv_power: sensor.solaredge_ac_power
    import_export_power: sensor.solaredge_negated_sensor
    appliance_switch: switch.shellyplugheizer21
    defined_current: 0.3
    actual_power: sensor.shellyplugheizer21_power
    appliance_switch_interval: 1

in addition to this I created an helper (input_boolean) for every automatisation to turn it on and off, in case I need the device run no matter how much PV power is produced.
Again this is basically same for all devices:

alias: PVSteckdoseHeizer21Schalter
description: Schaltet PV Steuerung für Heizer 2.1 ein und aus
trigger:
  - platform: state
    entity_id:
      - input_boolean.schalterpvsteckdoseheizer21
    to: "on"
    id: SchalterAn
  - platform: state
    entity_id:
      - input_boolean.schalterpvsteckdoseheizer21
    to: "off"
    id: SchalterAus
condition: []
action:
  - if:
      - condition: trigger
        id: SchalterAn
    then:
      - service: automation.turn_on
        data: {}
        target:
          entity_id: automation.pvsteckdoseheizer21
    else:
      - service: automation.turn_off
        data:
          stop_actions: true
        target:
          entity_id: automation.pvsteckdoseheizer21
      - type: turn_on
        device_id: 2dd6712df8d10d0ea7ed2893c3bf8048
        entity_id: switch.shellyplugheizer21
        domain: switch
mode: single

Ofcourse all these booleans are true, and all the blueprint automatisations are active.

Please get the debug logs and paste them here.

By the way, why are you creating a helper boolean to turn the automation on on off, when this is already possible out of the box?

I am sorry, but can you tell me where I find the debug logs?

I didnt know this is possible out of the box. And I cant even find a setting in your blueprint Oo
I use the helper to visualise on my dashboard.


But if its possible without a helper, ofcourse im interested.

Edit:
Ignore the wallbox section on my screenshot. I deleted the automatisation, but left the dashboard entries.