Leveraging solar panel surplus

[Bello2023]

Question

I have an Easee Home Charging Station with Equalizer. These are connected to HA. My desire is to utilize the surplus solar energy for charging the car, but not exceeding what is generated. So, the amount typically fed back into the grid should now be directed towards charging the vehicle. For example, if I'm feeding back 6 kW, then the charging station should provide 6 kW to the car. Is there a setting in HA that allows me to control the charging station's capacity?

What version of the integration are you using?

Easee Home

Anything in the logs that might be useful for us?

No response

Additional information

No response

[olalid]

First option is to use the surplus energy setting in the easee app (this setting can not be controlled from the HA integration unfortunately since there is no publicly known api for it). The other option is to use the easee.set_circuit_dynamic_limit service in some automation and set it such that the export/import of power is close to zero. There are some other discussions about this if you look through the issues the support issues.

[celodnb]

I have been doing this very thing at home for just over a year now (an Easee home chargebox with Huawei solar panel and 5kWh battery). I'll post the way I have done it, and how it works for me, but I have likely done it in a very complicated way, so I'd love to hear if anyone else has an alternative way of doing it.

When I first started, I made a basic template to calculate the surplus number of amps I had available to charge with, which could be fed into the car. I also wanted to ensure that HA would automatically change the Easee charger from single to three phase, and of course, I only ever want to use surplus solar, and minimize charging from the electricity grid, unless I specifically chose to (usually at night during the winter months, or if there is not enough sun, then find the cheapest time during the day).

Basic surplus amps calc is as follows:

#Charging current
  - platform: template
    sensors:
      charging_current:
        friendly_name: Charging current
        value_template: "{{ (((states('sensor.power_meter_active_power') | float(0) ) + (states('sensor.car_charger_power') | float(0) ) + (states('sensor.battery_charge_discharge_power') | float(0) )) / (0.23) + (0.5) | float(0) ) | round(0) }}"
        icon_template: mdi:current-ac
        unit_of_measurement: A

This sensor can then be used in automations, to control the easee.set_circuit_dynamic_limit service. However, I found that if I use this value directly, it can cause some minor issues with the charger. On sunny days, there is no problem, however, if you have a day where you have some cloud cover, and the charging current value keeps changing between values that are over 6A, and below 6A, this of course stops and starts the charger all the time, and after a few times, I find the charger just decides to stop charging anymore. So what I did, was I used the HACS average sensor integration to create an average value for the charging current. This effectively removes the sudden changes in the charging current value, helping to prevent the sudden changes from over 6A and below 6A, keeping the charger charging. It can be found here:

https://github.com/Limych/ha-average/tree/2.3.4

And here's my average sensor:

#Average charging current
  - platform: average
    name: 'Charging current average 5 mins'
    duration:
      minutes: 5
    entities:
      - sensor.charging_current

This is the value I then used in my automations to control the easee.set_circuit_dynamic_limit service.

[stefan240987]

I have been doing this very thing at home for just over a year now (an Easee home chargebox with Huawei solar panel and 5kWh battery). I'll post the way I have done it, and how it works for me, but I have likely done it in a very complicated way, so I'd love to hear if anyone else has an alternative way of doing it.

When I first started, I made a basic template to calculate the surplus number of amps I had available to charge with, which could be fed into the car. I also wanted to ensure that HA would automatically change the Easee charger from single to three phase, and of course, I only ever want to use surplus solar, and minimize charging from the electricity grid, unless I specifically chose to (usually at night during the winter months, or if there is not enough sun, then find the cheapest time during the day).

Basic surplus amps calc is as follows:

#Charging current
  - platform: template
    sensors:
      charging_current:
        friendly_name: Charging current
        value_template: "{{ (((states('sensor.power_meter_active_power') | float(0) ) + (states('sensor.car_charger_power') | float(0) ) + (states('sensor.battery_charge_discharge_power') | float(0) )) / (0.23) + (0.5) | float(0) ) | round(0) }}"
        icon_template: mdi:current-ac
        unit_of_measurement: A

This sensor can then be used in automations, to control the easee.set_circuit_dynamic_limit service. However, I found that if I use this value directly, it can cause some minor issues with the charger. On sunny days, there is no problem, however, if you have a day where you have some cloud cover, and the charging current value keeps changing between values that are over 6A, and below 6A, this of course stops and starts the charger all the time, and after a few times, I find the charger just decides to stop charging anymore. So what I did, was I used the HACS average sensor integration to create an average value for the charging current. This effectively removes the sudden changes in the charging current value, helping to prevent the sudden changes from over 6A and below 6A, keeping the charger charging. It can be found here:

https://github.com/Limych/ha-average/tree/2.3.4

And here's my average sensor:

#Average charging current
  - platform: average
    name: 'Charging current average 5 mins'
    duration:
      minutes: 5
    entities:
      - sensor.charging_current

This is the value I then used in my automations to control the easee.set_circuit_dynamic_limit service.

Why do you divide with 0.23 + 0.5 for the surplus amps?

[celodnb]

I have been doing this very thing at home for just over a year now (an Easee home chargebox with Huawei solar panel and 5kWh battery). I'll post the way I have done it, and how it works for me, but I have likely done it in a very complicated way, so I'd love to hear if anyone else has an alternative way of doing it. When I first started, I made a basic template to calculate the surplus number of amps I had available to charge with, which could be fed into the car. I also wanted to ensure that HA would automatically change the Easee charger from single to three phase, and of course, I only ever want to use surplus solar, and minimize charging from the electricity grid, unless I specifically chose to (usually at night during the winter months, or if there is not enough sun, then find the cheapest time during the day). Basic surplus amps calc is as follows:

#Charging current
  - platform: template
    sensors:
      charging_current:
        friendly_name: Charging current
        value_template: "{{ (((states('sensor.power_meter_active_power') | float(0) ) + (states('sensor.car_charger_power') | float(0) ) + (states('sensor.battery_charge_discharge_power') | float(0) )) / (0.23) + (0.5) | float(0) ) | round(0) }}"
        icon_template: mdi:current-ac
        unit_of_measurement: A

This sensor can then be used in automations, to control the easee.set_circuit_dynamic_limit service. However, I found that if I use this value directly, it can cause some minor issues with the charger. On sunny days, there is no problem, however, if you have a day where you have some cloud cover, and the charging current value keeps changing between values that are over 6A, and below 6A, this of course stops and starts the charger all the time, and after a few times, I find the charger just decides to stop charging anymore. So what I did, was I used the HACS average sensor integration to create an average value for the charging current. This effectively removes the sudden changes in the charging current value, helping to prevent the sudden changes from over 6A and below 6A, keeping the charger charging. It can be found here: https://github.com/Limych/ha-average/tree/2.3.4 And here's my average sensor:

#Average charging current
  - platform: average
    name: 'Charging current average 5 mins'
    duration:
      minutes: 5
    entities:
      - sensor.charging_current

This is the value I then used in my automations to control the easee.set_circuit_dynamic_limit service.

Why do you divide with 0.23 + 0.5 for the surplus amps?

Hi Stefan, the various sensors in the calculations give me the amount of surplus watts there are available for charging. This is then multiplied by 0.23 to give the number of amps (amps is A = W x V, where the 0.23 is 230 volts).

The extra 0.5 was just a bias to boost the about up to the nearest amp. Is not necessary though :-)

[wilderbridge]

For anyone interested I've reverse engineered the surplus API:

The URL is https://api.easee.com/cloud-loadbalancing/equalizer/<equalizer ID>/config/surplus-energy

where response is {"mode":"chargingWithImport","chargingWithImport":{"eligible":true,"maximumImportAddedCurrent":3}}

POSTing '{"mode":"chargingWithImport","chargingWithImport":{"eligible":true,"maximumImportAddedCurrent":6}}' to the same URL will result a response 202 and surplus parameters are updated.

Setting maximumImportAddedCurrent to 0 will result charging only from surplus. The mode would still be chargingWithImport.

Disabling the surplus charging: {"mode":"none","chargingWithImport":{"eligible":true,"maximumImportAddedCurrent":0}}

I've no idea about the rate limits but would assume some exists.

[wilderbridge]

Hacked pyeasee and easee_hass to add a service command to this and it works perfectly.

Is this project up for non-public APIs? If so, I can submit PRs probably next week.

[olalid]

Good question, this would be the first occasion where we needed to resort to using undocumented features to implement something, although there is always a certain amount of trial and error with the Easee API. I have asked Easee if they can provide info on an API for it, but have not gotten any response. So in absence of a reply I guess we could do it.

If you want to provide PRs please do and we will take it from there.