Surplus charge automation for Solarbank E1600 (1st generation) #81

thomluther · 2024-07-06T18:25:31Z

thomluther
Jul 6, 2024
Maintainer

Surplus charge automation for E1600

Introduction

I want to introduce my Home Assistant automations that I use to control the Anker Solix Solarbank E1600 Generation 1.
Based on the Anker Solix HA integration, it is now possible to modify the Solarbank time schedule parameters dynamically. This allows to automate the power export of the Solarbank to better fit your actual power consumption in the house. The goal and use case for my automations is following:

Allow the appliance to produce as much solar energy as possible, under consideration of existing limitations
Use solar energy directly in bypass as much as possible while avoiding energy export to the grid which is not payed back

With this goal in mind, a charge priority use case for the solarbank is out of scope, since it will waste 15-20% solar energy unnecessarily due to battery management and energy conversion losses. Additionally, when the battery is full early in the day, the whole solar energy is bypassed to the house but cannot be consumed. My automations are optimized to use the battery only as buffer for solar energy that cannot be consumed directly. So the priority is not to avoid grid import at all cost, but avoid import as much as possible, while reducing export as much as necessary and possible. If you have different use cases for your Solarbank, these automations might not be applicable to you. But you could still get some ideas on how you can automate the Solarbank with Home Assistant.

Appliance overview

I own only a 790 Wp solar system with 2 panels and a single Solarbank. The panels are SE and SW oriented, ideally for stretching the solar production over the full day instead of having a shorter peek production. I have no shadows to consider over the day, which simplifies my optimization routines.
Since I have no over panelling, the automations are optimized for a balanced small photovoltaic system, that fits well with my daily consumption in spring and autumn, but may have surplus production with >4 kWh in summer which cannot all be consumed and buffered, especially if nobody is home to consume.
I use a normal automation mode that is considering a bias regulation slightly below the house consumption to ovoid exporting energy to the grid completely. However, I realized quickly that a more aggressive mode makes sense too for periods with expected overproduction.
For surplus periods when there is more energy expected as the solarbank can buffer, the automation is using a more aggressive regulation with a bias slightly above the house consumption. This will further reduce your grid energy import without exporting too much to the grid unnecessarily.

Requirements

The Solarbank provides value updates to the cloud in 1 min intervals at least. This is insufficient for usage in regulations. You need device or template sensors that can provide values in about 5 sec intervals or less, to ovoid time lags between value calculations and comparisons are becoming too significant. To realize my automations, you need sensor entities for following:

Actual AC power value exported from your inverter into the house

I use a Hoymiles inverter with OpenDTU, which provides a whole set of sensors via MQTT that can be refreshed in 5 seconds. If you have no direct quick inverter sensors, a quick smart plug may be used as well.
Actual grid power value

There are various smart Readers available to intergrate this value into HA. I use a Hichi DIY device providing the grid power via Tasmota FW and MQTT. Other devices like Shelly 3EM might be used as well, but you need quick and local interfaces. Getting the value via cloud API will be too slow and unreliable.

With those 2 (template) entities you create another template sensor that calculates your actual house consumption. The actual house consumption, or better a statistically flattened version of it, will be used as base to calculate the new power set point for your regulation.
I strongly recommend to use template sensors for those core entities instead of direct device sensors. This gives you more flexibility for the value they are reflecting in your regulation, and you don't need to change your automations when device sensors need to be changed or replaced. You can also combine values of multiple devices to reflect your entity. For example, my inverter is plugged into an outdoor Fritz Dect 210 smart socket. This only provides power once minute, so too slow for regulation. But I use this value when the inverter AC power entity is no longer available while the inverter is switched off. At that time it represents 0 W and does not break automation due to unavailability.

Another requirement is that you are familiar with HA usage, integrations, automations, templating and dashboards in general since I do not describe HA basics. Also YAML and Jinja knowledge should be available to make your own adoptions of the automations as necessary.

Regulation capabilities

Essentially there are two different approaches how you can regulate the generated AC power export to your house:

Limit the inverter, which typically will limit its DC input power on each MPPT channel and therefore the converted AC output power.
Limit the Solarbank power export, which limits the DC power that the Solarbank is giving to the inverter DC inputs.

Both have pros and cons. Limiting the inverter must be supported by your inverter and you must integrate it into HA as well. It has the advantage that power regulation is typically very fast, and you can limit it well below 100W. However, it can negatively impact the MPPT trackers of your Solarbank and reduce the produced energy. Furthermore it typically limits all DC input channels equally, which is a disadvantage for asymmetrical setups where some solar panels are directly connected to the inverter. Therefore I do not recommend the inverter limit approach at daytime. However it is the best approach for discharging the solarbank. I realized this automation with a Hoymiles HM 600 inverter that I integrated into HA via an OpenDTU ESP DIY device. The project and the automation is described in the HA community.
For most efficient daytime regulation you need to adjust the solarbank power export to the house. The solarbank does not react as fast as the inverter and cannot be limited to less than the defined inverter limit of 150 W or 100 W. Furthermore power export increases are not allowed in less than 30 sec intervals by the integration and everything is processed via Api and depends on the cloud.
In this project I use both types of regulation and I optimized them for my use case. If you have no inverter limit regulation capabilities (Anker inverters do not provide that feature), this project may still help you to understand how you can automate you solarbank power export all day, even if I use it only for the daytime phase and the inverter regulation for the nighttime phase.

Automation overview

In general I split my regulation algorithms for daytime and nighttime. At daytime I use the solarbank regulation, at nighttime the inverter regulation. To clearly separate those two different concepts, I split the solarbank time schedule accordingly into a fixed format of 3 intervals:

Night interval from 00:00 until solar start
Day interval from solar start until solar end
Evening interval from solar end until 24:00

The interval borders are adjusted automatically based on sun or other conditions.
The inverter automations are used only when the day interval is not active, but the automations will ensure to reset the inverter limit to its max. value for day interval or whenever the solarbank state indicates anything but a discharge state to prevent the inverter limit is reducing solar production by any means.

Overall I use 2 generic automations that are applicable for both regulation concepts:

Automation to set a helper for the regulation mode

While optimizing my regulations, I found that it is valuable to use 2 different modes for both regulation concepts. I use a 'moderate' mode and an 'aggressive' mode, but a single mode might be good for you too. Based on this mode, I optimize the algorithm parameters for both regulation approaches. They have the goal that the 'moderate' mode keeps the grid consumption slightly above 0 W and avoids any export to the grid if possible (0 to 30 W range), while the 'aggressive' mode keeps the grid export as small as possible while avoiding grid import if possible (-40 to 5 W range).
Automation for daily schedule adjustment

This will adjust the borders between day and night intervals of the Solarbank schedule and control when either of the two regulation approaches will be used

Furthermore I use 2 automations for the solarbank day interval, but their parameters are very unique and depend on your personal preference how you want to use the solarbank:

Automation to adjust export switch

This is based on various individual criteria, but mainly to avoid risk of unwanted discharge due to solarbank firmware inefficiency or bad weather conditions. However, the export need to be allowed for regulation of output power above the minimum bypass of 100/150 W
Automation to adjust power export to home

This is the main regulation automation, but only used at daytime interval and when export is allowed.

Last but not least, I use 2 automations for the inverter regulation:

Automation to adjust inverter limit

This is the main regulation automation, but not used at daytime interval.
Automation to reset inverter and its limit

This is to ensure the inverter is not limiting possible solarbank production at any time when it is not discharging. It will also reset the inverter daily yields once a day in case the inverter did not went off over night.

All automations are explained and provided in following sections, so you can adopt and adjust them to your own needs and use case.
If you have a dual solarbank setup, you also may benefit from this project when you automate them equally shared by regulating the whole appliance. While with version 1.3 of the Anker Solix HA integration and firmware 1.5.6 you can set individual solarbank power exports, such an asymmetrical or staggered use case is not considered in this project. It would make a meaningful split of regulation intervals much more complex and more automations may be needed to regulate each solarbank individually.

Full cycle example of a sunny day

Following screenshot provides an overview how the automations work across a sunny day (done with HACS ApexChart card)

The most important graph is the dark blue grid power, which is regulated closely to the 0 W axis while there is sufficient solar or battery power as highlighted below:

You can see how the moderate regulation at night keeps the average slightly above 0 W, avoiding grid export as much as possible. During the sunny day the regulation mode went to aggressive and kept the grid power close below the 0 W axis, trying to avoid grid import without exporting too much power. You can also see the light green inverter limit used for the regulation at night, which is reset during the day to its maximum. The sandy solarbank system preset graph shows my fixed 300 W limit for the discharging intervals at night and you see the regulation during the day. The switches between day and night periods are marked with the vertical Sun and Moon marker lines. The greenish SOC and self consumption percentage is printed against the 2nd Y axis (% unit) on the right. The little bumps in the light blue house consumption median graph are from the fridge which is toggling on and off multiple times a day. The high peek in house consumptions are large consumers like the coffee machine, but there was no cooking on that day which appears more of a pulsing peek consumption which is difficult to regulate.

Note:

I do not regulate over aggressively to limit the amount of changes that needs to be applied to either the inverter or solarbank limits. The wider you will choose your regulation range, the less adjustments may be required.

Daytime example with changing conditions

Following chart shows how the automations work on changing conditions during the day. Not only for cloudy conditions early in the morning, but also for cooking at noon. This chart is also showing the toggle from aggressive to moderate mode in the morning due to changed conditions/estimations. You can see how the dark blue grid power average shifts again slightly from below 0 W to above 0 W (done with HACS History Explorer card)

This chart is a good example to demonstrate that short peeks or fluctuations are difficult to regulate. If they are too short for the sensors and automation latency, they should be better ignored by the algorithm, otherwise the regulation starts when the peek is over and lots of energy is exported to the grid unnecessarily. Therefore my algorithm is a bit lazy for preset increases (initial delay after decrease, median delay), but immediately reacts on grid exports to limit the export as much as possible. This graph may also give you an idea, why your main sensors for grid power and produced solar/battery power should be near real time values, otherwise such a regulation effectiveness cannot be realized. Of course, the latency to apply a changed preset also matters, which is the reason why you must monitor the effectiveness of your automations and adopt the algorithm parameters eventually.

Implementation of automations

Preparation

Before you start adopting the automations, you should prepare the following.

Dashboard to monitor automation effectiveness

Build a dashboard that allows you to view and control the following:

Relevant sensors used in your automations, especially the important ones for regulation trigger and set points
A Markdown card with Solarbank schedule (see example)
A Logbook card tracking events for the entity that will be used to record major changes done by automations. Some automations may trigger very often and you cannot debug relevant parameters with their traces since they wrap up quickly while doing nothing. I use log event services in such automations to validate why a certain change was done and log it against my solarbank export switch entity
A history graph card showing the relevant automation sensors over time to control the effectiveness of your automations. The HA history view might be good as well. You can label your relevant entities that you need to quickly select them all via the label. I also allows you to display short periods in great details. The only disadvantage is that you cannot directly shift the diagram back and forth to review the history. Alternatively I found the History Explorer card from HACS very useful, since that allows quick resolution changes and can be shifted for the displayed interval, but this repo is archived meanwhile. Another nice card for graphs only is the Apex Chart card, but this might need some tweaking until you have it presented in your preferred way. This is used for the day cycle above, but Apex chart cards must be edited if you want to display another interval in the past by using the chart offset setting.

Forecast Solar integration

Some automations are considering the Forecast Solar for decisions and optimizations. Therefore it will be useful to install a Forecast Solar integration and configure it for your solar panels as accurately as possible. You may need to monitor the Forecast Solar on various days and conditions to see whether this reflects your panel yields as good as possible. Possible integrations are:

Forecast Solar core integration. That is the one I use, but it is not always that accurate
Solcast Forecast Solar HACS integration. This might be more accurate, but free subscription Api calls are meanwhile limited to 10 API calls per day

Integration for your grid meter

Depending on your grid meter, various options are available to get the power consumption into HA. An important factor for the regulation is that this value is provided near real time. So you should not use a smartmeter reader that can be accessed only via cloud (dependency, latency, time lag issues). I use an ESP DYI device with Tasmota firmware that reads the grid meter via its optical interface and publishes the data to my WLAN and HA using MQTT. I can accomplish around 5 sec refresh and that is sufficient. Optionally you may use the known Shelly smart meters, since more and more vendors seem to corporate with shelly devices for power metering. They provide the grid meter data also locally via WLAN.

Integration for your inverter (optional)

In case you use the inverter regulation concept, depending on your inverter you will need devices and integrations to support near real time sensing of the AC output as well as capabilities to modify the inverter limit as needed. I use a Hoymiles HM600 inverter, which I integrated into HA with an OpenDTU device, providing the inverter connection via local Wifi and MQTT. So in my case, I had to install the MQTT Addon and configure my OpenDTU device to publish its data via the HA MQTT server.

Note:

One important generic requirement independent of the integration you use, you should create a template entity representing the inverter AC power into the house the ALL the time. Since your inverter is typically switched off at night, the integration entities may render unavailable. Your template should ensure that it always represents a value of 0 W if the inverter AC power inverter entity is no longer available. It will simplify all automations and templates based on the AC inverter power if represented by an entity that is typically not unavailable.

House consumption entity

You need to create a template entity for your actual (real time) house consumption. This will be used as the target set point in all regulation algorithms, so the value should be as accurate as possible.
Without solar panels this is typically your grid meter power value. However with solar panels or power batteries you have to consider the actual solar/battery AC power feeding into your home as well. The house consumption template sensor needs to consider that there may be time lags between both values and a negative house consumption is typically not possible. The larger the time lags are between the entities used for the calculation, the higher the fluctuation for this template can be. I found that it will be helpful to create a second statistic entity for the house consumption template entity. I use a median entity, which represents the 50th percentile. Other percentiles might be good for you as well and their purpose is to flatten out calculation peeks as well as very short peeks of your source entities that may occur and should be ignored for regulation. The disadvantage of the statistic entity is that it needs a couple of samples and therefore is lagging somewhat behind the actual value. I use the median value for solar/battery power increases into the house since this regulation can be a bit lazy and should not be over aggressive. For solar/battery power reductions I use the actual consumption sensor however, since I do not want to lag behind when external grid power dropped below my target range (for example when exporting to grid).

Note:

I created template sensors also for my important source device values instead of using the provided device entities directly. This has the benefit to make all your automations independent of the device or integration entities, because they could change in future (device or integration replacements etc). If you have a template sensor for them, you just need to update the template with the new device or integration entity after any change or replacement.

Following is an example how the median sensor flattens out peeks in the actual consumption calculation. The white calculated real time consumption line is overlayed by the light blue flattening median sensor line. You can see that all the white short peeks are flattened, and the long term changes are delayed by about half of the sampling interval.

When using the median value for increases in the automation, you consider a somewhat settled value for lazy increases.

House consumption template sensor

Following are the source entities you need to replace:

sensor.grid_power

In my case this is a template with positive Watt for grid import and negative Watt for grid export.
sensor.inverter_power

In my case this a template for the AC power in Watt coming from the inverter

template:
  - sensor:
      - name: "House consumption"
        unique_id: "house_consumption"
        unit_of_measurement: "W"
        device_class: "power"
        icon: mdi:home-lightning-bolt
        state: >
          {% set gridmeter = states('sensor.grid_power')|float %}
          {% set production = states('sensor.inverter_power')|float(0) %}
          {% set mystate = this.state %}
          {% if mystate in [None,'unavailable','unknown',''] %}
            {% set mystate = 0 %}
          {% endif %}
          {% if is_number(gridmeter) %}
            {# add solar power to grid power for house consumption while above 0 #}
            {{ (gridmeter + production) | round(1) if gridmeter + production > 0 else mystate}}
          {% else %}
            {{mystate}}
          {% endif %}
        availability: >
          {{ has_value('sensor.grid_power') and is_number(states('sensor.grid_power'))}}

House consumption median sensor

With about 5 sec samples for each of the source entities, the calculated house consumption entity gets 10-12 samples in 30 seconds. This has proven to be a good flattening sensor for actual house consumption which is only lagging about 15-20 seconds behind the real value. Following are the source entities you need to replace:

sensor.house_consumption

Your actual house consumption template sensor from above.

sensor:
  - platform: statistics
    name: "House consumption median"
    unique_id: house_consumption_median
    entity_id: sensor.house_consumption
    state_characteristic: median
    precision: 0
    max_age:
      seconds: 30

Solarbank battery energy change in last hour

Create an Integral sensor that will be tracking the energy in kWh that is going into and out of your battery all the time, so it will count up and down. The value itself is not that important, but it can be used as source for a statistic sensor that calculates the battery energy change during last hour. This sensor will be used in automations to predict the time when the battery is full or empty and switch the regulation mode based on it.

Integral sensor for solarbank energy

Create a helper for an Integral sensor from your Solarbank battery power (Watt) to sum up the energy (kWh). You can create it from the UI with following settings:

entity_id: sensor.solarbank_battery_energy
metric prefix: kilo
time unit: hours
source entity: sensor.system_bkw_sb_battery_power

Your solarbank battery power entity. For dual solarbank systems, you should select the system SB battery power entity to track the energy of both devices
method: left Riemann sum (most accurate)
precision: 3 (Wh resolution)

Since the battery power of the integration will show positive Watt for charging and negative Watt for discharging, the integral sensor will increase while charging and decrease while discharging.

Statistic sensor for Solarbank energy change in last hour

This sensor represents the actual charge or discharge rate of the last hour which we are interested in for the prediction.

- sensor
  - platform: statistics
    name: "Solarbank kWh last hour"
    unique_id: solarbank_battery_energy_last_hour
    entity_id: sensor.solarbank_battery_energy
    state_characteristic: change
    precision: 3
    max_age:
      minutes: 60

Helper to define daily solar start and solar end

The actual time when your solar panels start and end their production does vary throughout the year since it depends from the sun level (elevation) and its angle (azimuth). This variation must be considered in the automations to adjust the borders of the day interval in the solarbank schedule accordingly.
I use datetime input helpers to record the start and end time each day based on various conditions. The recorded times will then be used to adjust the daily solarbank schedule intervals once per day at night. The durations between now and those recorded times will also be used for battery buffer and discharge predictions to switch the regulation mode accordingly.

Datetime helper for daily solar start and solar end

Create two datetime helpers via the UI using following:

entity_ids:
- input_datetime.solarstart
- input_datetime.solarend
input type: Date and Time

Regulation mode helper

I created an Input Select helper to switch between two regulation modes I called 'moderate' and 'aggressive'. You can create it via the UI using following:

entity_id: input_select.power_regulation_mode
options:
- moderate
- aggressive

I decided for an input select sensor to have more than 2 options available, but discovered later that 2 are sufficient. So you can also create a simple switch helper for the regulation mode and adopt the automations code accordingly when using its state.

Helpers to delay first and subsequent solarbank preset increases

I implemented 2 different helpers to delay the first preset increase after a decrease or other 'reset' condition, and subsequent increases after a previous increase.

Timer helper to enforce wait time for subsequent increase

The solarbank preset can be increased only every 30 seconds. This is a restriction to limit the amount of Api requests since each change requires 2 requests. Furthermore the Solarbank needs some time to adjust to the new preset. 30 seconds allow the battery management system to adjust and settle for the new preset. The timer helper is required to block subsequent preset changes until the timer is finished. The timer helper can be created via the UI:

entity_id: timer.regulation_delay
default duration: 0:01:00

The duration of the timer will be set dynamically by the automations and vary depending on the regulation mode or other conditions. But it needs to be set to 30 sec as minimum to avoid subsequent preset errors with the solarbank system preset entity.

Switch helper to generally block or allow preset increases

Some situations may require an additional or first delay where quick increases do not make sense. With an additional switch helper, the normal increase capability can blocked or enabled with additional dynamic delays made in automations. It can be used to ignore short time consumption peeks as you can typically see in your house (modern cooking fields for example). So it acts an initial increase delay after an undefined period of time when the timer is not active anymore. The switch helper can be created via the UI:

entity_id: input_boolean.regulation_increase_ok

Binary sensor to indicate a workday

I see different consumption patterns in my house depending whether it is a workday or weekend/holiday. This sensor can be used to consider different consumption forecast calculations and make various decisions on it in your automations. You can install the core HA integration workday and configure it to your needs to get a reliable sensor for working days in your area.

entity_id: binary_sensor.workday

Selection helper to indicate home presence

Independent of the automations described here, I use a general Input Select helper that I set manually or via other automations to a meaningful automation mode. It can be used to disable your automations with a single entity when that is relevant for specific automations. Another way I use this is for different modes of shutter automations. For the solarbank automations I use it as well to better forecast the day and night consumptions in order to toggle the appropriate regulation mode. For example I have 2 modes indicating that nobody is at home (travelling or vacation) and then the daily consumption is typically much less, so aggressive mode could be used even with lower solar energy prediction. This is something you really need to adopt to your typical life and power consumption behaviour, or ignore it altogether in the automations. I describe it here, so you have an understanding how it is used in the automation code further below.

entity_id: input_select.automode
options: Whatever is meaningful to you and your generic house automations. I use for example:
- Off
- Travel Summer (This is used in my solarbank automations)
- Travel Winter (This is used in my solarbank automations)
- Vacation Home
- Home Office
- Work

Daily solar cycle tracking for battery energy

This part is a little bit off topic for the power regulation, but relevant for proper battery energy tracking and integration into your Energy Dashboard. Many people are struggling with this topic and wonder why they cannot properly use the daily energy entities as provided by the Anker Solix integration.
On top of that, for proper tracking and comparison of daily energy entities, I realized that the standard reset cycles of the utility meter helpers are not very useful if you use a battery for your solar power, which can extend the daily solar energy usage into the next day. For example to create template sensors that track the daily efficiency of your charge and discharge energy, you have to consider a flexible end of the overall solar cycle for the meter reset. Therefore I created utility meter helpers which can be reset via a service that can be triggered by an automation. The reset service only works for utility meters that have a tariff option defined. With a tariff option specified, HA will create the main select.* entity for the meter and another sensor.* entity for each tariff, where the tariff name is appended to the common sensor name. So you can create a utility meter referring to the energy that you want to track and the tariff can be called for example 'solarcycle' to indicate that this is not a normal daily utility meter entity. In order to reset the counter of all tariff entities, you have to issue the utility meter reset service against the main select entity, which typically switches between mutliple tarifs. Only then you will have a valid last_reset timestamp and last_period value recorded automatically in the tariff entity along with the reset of the state value itself.

Create separate template entities for battery charge and discharge energy

You cannot utilize the daily energy entities as provided by the Anker Solix integration as is in your HA Energy dashboard, and I would never recommend this either. Those entities are reset on a daily base and may confuse energy recording, which works best with total increasing entities. Furthermore any integration or device entity in general may have to be replaced over lifetime and then you would loose their history in the dashboard. History data switch to another entity is possible, but requires manual SQL scripting and is painful. That is nothing you want to do if not familiar with SQL and the HA database structures. The integration's daily energy entities will also be reset at a fixed time each day and the values are provided as is from the cloud. For those reasons, I strongly recommend to create template entities for the integration provided appliance battery power, which can be positive (charging) and negative (discharging) power. You can use the UI to create one template entity for the charging power presenting only the positive values or 0, and another entity for the discharging power presenting only the negative values or 0. Those negative values can be multiplied by (-1) to convert them to positive numbers if desired. For each of those template entities, create a Rieman Integral helper entity from the UI to sum the charge and discharge power (W) separately into charge and discharge energy per hour (kWh). Those energy helpers are always increasing totals and can be used directly in your HA energy dashboard to represent the required battery energy entities. If you have to replace your integration entities in future, you just need to update the power template entities for the new source entity to properly represent the separated charge and discharge power and the rest will continue to work as is, without risk of loosing energy history data in the dashboard.
Following Rieman Integral helper example entities will be used here in the automations to demonstrate the tariff utility meter and daily solar cycle based reset:

sensor.solarbank_discharge_kwh (Total increasing kWh)
sensor.solarbank_charge_kwh (Total increasing kWh)

Create utility meter with tariff for 'daily' charge and discharge energy

The required utility meters can be created from the UI with following settings:

name: solarbank_charge_kwh or solarbank_discharge_kwh
source entity: sensor.solarbank_charge_kwh or sensor.solarbank_discharge_kwh
reset cycle: None
supported tarifs: solarcycle
sensor always available: Can be switched ON

Keep the defaults for the other settings. This will create 2 entities for each utility meter. Following entities will be available once finished:

select.solarbank_charge_kwh
sensor.solarbank_charge_kwh_solarcycle
select.solarbank_discharge_kwh
sensor.solarbank_discharge_kwh_solarcycle

Template sensor to indicate solar cycle restart

In order to have a unique trigger entity for the solar cycle restart, I created a trigger based template sensor. Maybe that can all be done in an automation itself, but here I show you an example how to create a sensor that changes once a day depending on triggers and conditions. Basically the sensor triggers when the solarbank changes into a state that indicates solar power. The other trigger comes from the inverter integration once the inverter becomes reachable, as well as a time trigger after midnight. This will ensure that the sensor is also reset when the solarbank is not installed over winter, as well as updating an entity attribute.

Note:

Trigger based sensors will be unknown until triggered the first time after initial reload.

Entities used in the template sensor

Following are the entities that you need to replace in the template code:

sensor.sb_e1600_mode
binary_sensor.hoymiles_hm_600_reachable

Template sensor code

# Sensor for daily utility meter cycle restart, considering daily energy consumption may proceed until next day with battery
template:
  - trigger:
      # trigger when charging or bypass of Solarbank starts
      - platform: state
        id: charge
        entity_id: sensor.sb_e1600_mode
        to:
          - charge
          - charge_priority
          - charge_bypass
          - bypass
          - full_bypass
      # check if inverter went on
      - platform: state
        id: reachable
        entity_id: binary_sensor.hoymiles_hm_600_reachable
        to: "on"
      # trigger on new day to update boolean attribute today or reset if solarbank not discharging
      - platform: time
        id: newday
        at: "00:00:01"
    sensor:
      - name: "BKW Cycle start"
        unique_id: "bkw_cycle_start"
        icon: mdi:restore
        state: >
          {% set mystate = this.state %}
          {% if not has_value(this.entity_id) %}
            {# initial setting #}
            {% set mystate = now().isoformat() %}
          {% elif now().day != (mystate|as_datetime|as_local).day %}
            {# avoid state update when triggered by time platform but still discharging #}
            {% if trigger.id == 'charge' or (trigger.id == 'reachable' and not has_value('sensor.sb_e1600_mode')) or (trigger.id == 'newday' and not is_state('sensor.sb_e1600_mode','discharge')) %}
              {# reset when charging or bypass starts / inverter switches on the next day, or when next day and solarbank not discharging #}
              {% set mystate = now().isoformat() %}
            {% endif %}
          {% endif %}
          {{mystate}}
        attributes:
          today: >
            {# Boolean to indicate whether reset was or is done today #}
            {{not has_value(this.entity_id) or now().day == (this.state|as_datetime|as_local).day or
            ( trigger.id == 'newday' and not is_state('sensor.sb_e1600_mode','discharge')) or
            ( trigger.id == 'charge' and now().day != (this.state|as_datetime|as_local).day) or
            ( trigger.id == 'reachable' and not has_value('sensor.sb_e1600_mode'))}}

Entity overview

The last but not least preparation step is to create an entity overview for the automations, scripts and templates that you are going to create. I pulled this together for all entities I used in this project. You need to understand what they are used for and how to replace each of them with your own appropriate entity. You may not need all, you may need more. Each setup, device integration and regulation requirement is different, so you will need to understand the described automations and the sense of the entities that are used. Following table will explain each of them to provide you a central reference.

Entity	Description	Unit
Core entities
sensor.grid_power	(near realtime) AC grid power, positive = import, negative = export	W
sensor.inverter_power	(near realtime) AC power produced by inverter	W
sensor.house_consumption	Template combining grid and inverter power for actual AC house consumption	W
sensor.house_consumption_median	statistic median from actual house consumption	W
Forecast Solar integration entities
sensor.energy_next_hour	Solar energy expected for next hour	kWh
sensor.energy_production_today	Total solar energy expected today	kWh
sensor.energy_production_today_remaining	Expected solar energy remaining today	kWh
sensor.energy_production_tomorrow	Total solar energy expected tomorrow	kWh
Sun integration entities
sensor.sun_solar_elevation	Sun height	°
sensor.sun_solar_azimuth	Sun angle	°
Anker Solix integration entities
sensor.sb_e1600_mode	Solarbank operational mode
sensor.sb_e1600_battery_energy	Solarbank battery SOC energy	kWh
select.sb_e1600_soc_reserve	Solarbank SOC reserve	%
sensor.sb_e1600_home_preset	Solarbank output preset entity which has the schedule attribute	W and schedule attribute
switch.sb_e1600_allow_power_export	Entity to switch Solarbank power export	boolean
number.sb_e1600_system_home_preset	Entity to change Solarbank appliance preset	W
sensor.system_bkw_sb_solar_power	Solarbank appliance solar power	W
sensor.system_bkw_system_home_preset	Solarbank appliance output preset applied	W
sensor.system_bkw_sb_state_of_charge	Solarbank appliance state of charge	%
sensor.system_bkw_sb_battery_power	Solarbank applicane battery power	W
Hoymiles inverter OpenDTU entities via Tasmota and MQTT integration (if applicable)
binary_sensor.hoymiles_hm_600_producing	Inverter AC production state	boolean
binary_sensor.hoymiles_hm_600_reachable	Inverter availability state	boolean
number.hoymiles_hm_600_limit_nonpersistent_absolute	Inverter entity to set DC Limit	W
sensor.hoymiles_hm_600_ch1_power	Inverter DC input of MTTP 1	W
sensor.hoymiles_hm_600_ch2_power	Inverter DC input of MTTP 2	W
button.hoymiles_hm_600_restart_inverter	Inverter restart entity
sensor.hoymiles_hm_600_yieldday	Inverter daily yield (if applicable)	kWh
Helper entities
input_select.automode	Home presence mode	used: 'travel winter', 'travel summer'
binary_sensor.workday	Entity created by workday integration	boolean
input_datetime.solarstart	Estimated start of Solarbank production	datetime
input_datetime.solarend	Estimated end of Solarbank production	datetime
input_select.power_regulation_mode	Selected regulation mode	moderate, aggressive
input_boolean.regulation_increase_ok	Switch to allow power increases	boolean
timer.regulation_delay	Timer to delay regulation actions as needed	seconds
sensor.solarbank_battery_energy	Energy to/from solarbank appliance	kWh
sensor.solarbank_battery_energy_last_hour	Energy to/from solarbank appliance in last hour	kWh
sensor.bkw_cycle_start	Helper to change once a day when solar cycle restarts	timestamp
select.solarbank_charge_kwh, sensor.solarbank_charge_kwh_solarcycle	Utitlity meter with tariff for battery charge energy in solar cycle	kWh
select.solarbank_discharge_kwh, sensor.solarbank_discharge_kwh_solarcycle	Utitlity meter with tariff for battery discharge energy in solar cycle	kWh

Automation to set helper for the regulation mode

Explanation

The first automation will switch your helper entity to indicate which mode to be used for the power regulation. In this project I used two modes called 'moderate' and 'aggressive'. Based on my home presence pattern, the solar forecast and the expected house consumption, this entity is set to the appropriate mode. It is the base setting for other automations to distinguish between various parameter sets which they should apply. This is the automation you have to adopt the most to your particular setup and your power consumption behaviour. You may need to tweak this more often when you discover situations where the mode setting is not appropriate, either for daytime or nightime periods.

The automation separates both periods with their own rules, since the sun forecast is relevant for charging capability during the day, and the SOC and energy draw at evening is most important for the nighttime period. Therefore you clearly need to separate the conditional checks and actions between those two periods. Most of the parameter changes can be applied in the variables section. Those variables will be used by the actions and conditional steps to simplify necessary adoptions. I divided the automation into two choice options based on the mode setting. In each option I separate the conditional checks for the two periods. Since the variables are used in most places, except the entity replacements the required changes should be minimal in the rest of the actions and conditions.

Initially I struggled to find a good trigger when the mode setting should be re-evaluated. A time pattern may be used, but is not ideal. At the end it turned out that the solarbank battery SOC state change is the perfect trigger for automations that need to re-evaluate their setting conditions. It is not triggered too often during a daycycle, but triggered often enough and only when it makes sense to re-evaluate the conditions. Because when the SOC is not changing, your regulation parameters don't have to be changed either. Special cases can be covered by additional triggers as you see in the automation, for example when the solarbank operational mode is changing.

In order to simplify monitoring and debugging of the automation, I log any automation change to a single entity for later review via a logbook card. Typically the automation traces are wrapped too fast, so you cannot follow up why a change was made otherwise. I use the same in other automations, so I will not explain it for each automation.

Entities to be replaced

Following entities are used and need to be replaced:

sensor.energy_production_today
sensor.energy_production_today_remaining
sensor.energy_production_tomorrow
sensor.sun_solar_elevation
sensor.sb_e1600_mode
sensor.system_bkw_sb_state_of_charge
input_select.automode
binary_sensor.workday
input_datetime.solarstart
input_datetime.solarend
sensor.sb_e1600_battery_energy
select.sb_e1600_soc_reserve
sensor.sb_e1600_home_preset
sensor.solarbank_battery_energy_last_hour
input_select.power_regulation_mode
switch.sb_e1600_allow_power_export

Expand to see Automation Code

You need to review all variables and parameter settings to adjust them to your setup and consumption behaviour for various conditions to set your desired regulation mode. Especially for dual solarbank systems you need to adjust various calculations, but also conditions and actions if both devices must be considered separately instead of a corresponding appliance entity. Copy and paste the automation code into a new UI Automation using the YAML mode.

alias: "Adjust home power regulation mode entity"
description: ""
trigger:
  - platform: state
    id: FCRemaining
    entity_id:
      - sensor.energy_production_today_remaining
    to: null
  - platform: numeric_state
    id: Sunrise
    entity_id:
      - sensor.sun_solar_elevation
    above: 4
  - platform: state
    entity_id:
      - sensor.sb_e1600_mode
    to: discharge
  - platform: state
    id: SOC
    entity_id:
      - sensor.system_bkw_sb_state_of_charge
    to: null
condition: []
action:
  - variables:
      away: >
        {# Boolean to flag empty house with little consumption like vacation #}
        {{'travel' in states('input_select.automode')|lower()}}
      holiday: >
        {# Boolean to flag today is expected little house consumption like vacation or sunday and holiday #}
        {{away or (is_state('binary_sensor.workday','off') and now().weekday() != 5)}}
      solar_today: |
        {# kWh expected today #}
        {{states('sensor.energy_production_today')|float(0)}}
      solar_left: |
        {# kWh remaining today #}
        {{states('sensor.energy_production_today_remaining')|float(0)}}
      solar_h_left: >
        {# remaining hours with solar production #}
        {{max(0,(today_at((states('input_datetime.solarend')|as_datetime).time()) - max(now(),today_at((states('input_datetime.solarstart')|as_datetime).time()))).total_seconds()/3600)|round(2)}}
      discharge_h_left: >
        {# remaining hours for battery discharge before solarproduction starts again, consider next interval on solar start time #}
        {% set now_dt = now() %}
        {% set start = states('input_datetime.solarstart')|as_datetime|as_local %}
        {% set end = states('input_datetime.solarend')|as_datetime|as_local %}
        {{max(0,(start+timedelta(days=1) - max(now_dt,end+timedelta(days=(1 if start > end else 0)))).total_seconds() / 3600)|round(2)}}
      today_limit: >
        {# fix kWh forecast limit to switch between modes depending on expected house consumption #}
        {{1.5 if away else 2.0 if holiday else 2.5}}
      consumption_left: >
        {# remaining average kWh of house consumption to consume solar energy #}
        {{max(0,solar_h_left-2)*(0.075 if away else 0.1 if holiday else 0.25)}}
      surplus: >
        {# expected solar energy kWh that cannot be consumed or buffered in battery, consider 10% overhead for remaining battery cap #}
        {{solar_left - consumption_left - (1600-states('sensor.sb_e1600_battery_energy')|int(0))/1000}}
      battery_hourly_left: >
        {# average Wh available in battery for remaining discharge duration #}
        {{max(0,states('sensor.system_bkw_sb_state_of_charge')|int(5) - states('select.sb_e1600_soc_reserve')|int(5))*16 / max(1,discharge_h_left)}}
      battery_last_hour: |
        {# kWh change for battery in last hour, positive / negative #}
        {{states('sensor.solarbank_battery_energy_last_hour')|float(0) * 1000 }}
      dayinterval: >
        {# Flag daytime interval based on actual time and schedule #}
        {% set slots = (state_attr('sensor.sb_e1600_home_preset','schedule')).ranges|default([])|list %}
        {{ slots|length > 2 and strptime(slots[1].start_time,"%H:%M").time() <= now().time().replace(second=0,microsecond=0) < (strptime(slots[1].end_time.replace('24:00','23:59'),"%H:%M")-timedelta(seconds=10)).time()}}
      day_high: >
        {# Flag to indicate more energy production or capacity than consumable during day or night depending on SOC and FC tomorrow #}
        {{surplus > 0 or solar_today > today_limit or (states('sensor.energy_production_tomorrow')|float(0) > 1 and battery_hourly_left > (75 if away else 150))}}
  - choose:
      - alias: Check if mode can be set aggressive
        conditions:
          - alias: Check that setting is not aggressive
            condition: not
            conditions:
              - condition: state
                entity_id: input_select.power_regulation_mode
                state: aggressive
          - condition: or
            conditions:
              - alias: Check if discharge but battery will not get empty
                condition: and
                conditions:
                  - condition: state
                    entity_id: sensor.sb_e1600_mode
                    state: discharge
                  - alias: Check no daytime interval
                    condition: template
                    value_template: |
                      {{not dayinterval}}
                  - alias: Check that battery does not get empty based on last hour discharge, ignore first hour after start
                    condition: template
                    value_template: >
                      {{now() >= states.sensor.sb_e1600_mode.last_changed + timedelta(hours=1) and battery_last_hour < -60 and battery_last_hour|abs < battery_hourly_left}}
              - alias: Check if high forecast today or surplus expected
                condition: and
                conditions:
                  - alias: Check that not discharging
                    condition: not
                    conditions:
                      - condition: state
                        entity_id: sensor.sb_e1600_mode
                        state: discharge
                  - alias: Check that sun is up
                    condition: numeric_state
                    entity_id: sensor.sun_solar_elevation
                    above: 3
                  - alias: Check that high forecast or surplus
                    condition: template
                    value_template: "{{day_high}}"
        sequence:
          - if:
              - alias: Distinguish period for proper logbook entry
                condition: state
                entity_id: sensor.sb_e1600_mode
                state: discharge
            then:
              - alias: Logbook entry to track considered values for change
                service: logbook.log
                data:
                  message: >
                    Aggressive with {{states('sensor.system_bkw_sb_state_of_charge')}} % SOC for {{discharge_h_left}} h ({{battery_hourly_left|round}} Wh/h left while {{battery_last_hour|round}} Wh/h used last hour)
                  name: "Changed regulation mode:"
                  entity_id: switch.sb_e1600_allow_power_export
            else:
              - alias: Logbook entry to track considered values for change
                service: logbook.log
                data:
                  message: >
                    Aggressive with {{surplus|round(3)}} kWh surplus ({{solar_left|round(3)}} kWh remaining with {{states('sensor.system_bkw_sb_state_of_charge')}} % SOC{{', Daily surplus' if day_high else ''}})
                  name: "Changed regulation mode:"
                  entity_id: switch.sb_e1600_allow_power_export
          - alias: Set regulation mode to aggressive
            service: input_select.select_option
            target:
              entity_id: input_select.power_regulation_mode
            data:
              option: aggressive
      - alias: Check if mode can be set moderate
        conditions:
          - alias: Check that setting is not moderate
            condition: not
            conditions:
              - condition: state
                entity_id: input_select.power_regulation_mode
                state: moderate
          - condition: or
            conditions:
              - alias: Check if battery gets empty when discharging
                condition: and
                conditions:
                  - condition: state
                    entity_id: sensor.sb_e1600_mode
                    state: discharge
                  - alias: Check that discharge not in daytime interval
                    condition: template
                    value_template: |
                      {{not dayinterval}}
                  - alias: Check battery can get empty based on discharge  energy in last hour and consumption estimate
                    condition: template
                    value_template: >
                      {{battery_last_hour < 0 and battery_last_hour|abs >
                      battery_hourly_left}}
              - alias: Check low daily forecast without surplus
                condition: and
                conditions:
                  - alias: Check that not discharging
                    condition: not
                    conditions:
                      - condition: state
                        entity_id: sensor.sb_e1600_mode
                        state: discharge
                  - alias: Check that sun is up
                    condition: numeric_state
                    entity_id: sensor.sun_solar_elevation
                    above: 3
                  - alias: Check low daily forecast without surplus
                    condition: template
                    value_template: "{{not day_high}}"
        sequence:
            if:
              - alias: Distinguish period for proper logbook entry
                condition: state
                entity_id: sensor.sb_e1600_mode
                state: discharge
            then:
              - alias: Logbook entry to track considered values for change
                service: logbook.log
                data:
                  message: >
                    Moderate with {{states('sensor.system_bkw_sb_state_of_charge')}} % SOC for {{discharge_h_left}} h ({{battery_hourly_left|round}} Wh/h left while {{battery_last_hour|round}} Wh/h used last hour)
                  name: "Changed regulation mode:"
                  entity_id: switch.sb_e1600_allow_power_export
            else:
              - alias: Logbook entry to track considered values for change
                service: logbook.log
                data:
                  message: >
                    Moderate with {{surplus|round(3)}} kWh surplus ({{solar_left|round(3)}} kWh remaining at {{states('sensor.system_bkw_sb_state_of_charge')}} % SOC{{',no daily surplus' if not day_high else ''}})
                  name: "Changed regulation mode:"
                  entity_id: switch.sb_e1600_allow_power_export
          - alias: Set regulation mode to moderate
            service: input_select.select_option
            target:
              entity_id: input_select.power_regulation_mode
            data:
              option: moderate
mode: queued
max: 3

Automation to adjust daily solarbank schedule

Explanation

This automation adjusts your solarbank schedule, which I divided into a daytime period from solar production start until solar production end, and a nighttime period from solar production end until solar production start in the morning. Solarbank schedules must be defined for a full day from 00:00 until 24:00, therefore the two periods will require creation of 3 intervals in the schedule. The times for the period switch in the morning and evening will be adjusted once a day to the actual sun position. Basically you have to define proper sun elevation and eventually sun azimuth values that will trigger the automation when solar production typically starts for your setup and when it ends again. This will be different for everyone, and you may have to consider obstacles that may throw shadows to your panels in the morning or evening. Since I have no shadows on my panels, I can use only the sun elevation to define meaningful start and end triggers for this automation. You will have to adopt and test this with your trigger settings to work reliably.

I have chosen sun parameters to catch most of the solar power in the evening, while having the option to bring forward the nighttime period under certain conditions (low or no solar but charged battery earlier in the evening). This will maximise your possible solar energy production, but provides the option to start discharge earlier if it makes sense.

The same approach I found useful for the start of the daytime interval, which I defined late per default to allow a charged battery to discharge completely while solar production may start late on cloudy days for example. In case of early sun on nice days, the solarbank will switch automatically to solar production mode and does not waste possible solar energy. This approach ensures that charged batteries can discharge as long as possible, while the daytime interval can be brought forward upon solar production start to allow early adjustment of solarbank home load presets if necessary.

The times for the solarbank schedule will be rounded by 5 minutes. While the mobile app allows only 30 minute granularity for the schedule intervals, the HA integration supports 1 minute interval granularity. I use 5 minute granularity since that is typically sufficient and I haven't tested either full functionality with 1 minute schedule granularity.

Notes:

When updating a solarbank schedule interval, update the interval that will increase because otherwise you will split the existing interval upon shrinking.
It was also noticed that the solarbank does not start with discharging when a schedule service will end up sending a daily schedule that will contain just a single interval. Even if the solarbank applies this interval correctly as also reported back by the integration, the solarbank may have applied a 0 W preset setting for this single interval which you can see only when the schedule is verified in the Anker mobile app. This condition can be fixed only directly in the mobile app. The problem can be avoided when schedule service calls will result in more than a single interval for the day, which will be the case if a schedule exists and the update service will change just a sub range of the day interval.
When bringing a future interval forward, allow the solarbank a few minutes to fully apply the schedule change. When a new interval should start within a minute or two after the change, the interval change may not be applied for today.

Entities to be replaced

Following entities need to be replaced:

sensor.sun_solar_elevation
sensor.sun_solar_azimuth (may be needed)
binary_sensor.hoymiles_hm_600_reachable
sensor.system_bkw_sb_solar_power
input_datetime.solarstart
input_datetime.solarend
number.sb_e1600_system_home_preset
sensor.sb_e1600_home_preset
sensor.system_bkw_sb_state_of_charge

Expand to see Automation Code

Copy and paste the automation code into a new UI Automation using the YAML mode. You will need to adjust the triggers for SunStart and SunEnd according to your solar panel environment. Please review also all other templates and variables for required parameter adjustments.

alias: "Adjust daily solarbank schedule"
description: >-
  Record daily datetime for solar production start and end to adjust the
  solarbank schedule once a day. Adjust schedule once for next interval
  when it makes sense
trigger:
  - platform: numeric_state
    id: SunStart
    entity_id:
      - sensor.sun_solar_elevation
    above: 12
  - platform: numeric_state
    id: SunEnd
    entity_id:
      - sensor.sun_solar_elevation
    below: 8
  - platform: time
    id: SetSchedule
    at: "01:00:00"
  - platform: state
    id: InverterOff
    entity_id:
      - binary_sensor.hoymiles_hm_600_reachable
    to: "off"
  - platform: numeric_state
    id: EarlySolar
    entity_id:
      - sensor.system_bkw_sb_solar_power
    above: 20
    for:
      hours: 0
      minutes: 8
      seconds: 0
condition: []
action:
  - variables:
      now_rounded: >
        {# round now to 5 minutes #}
        {% set tm = now() + timedelta(minutes=2.5) %}
        {{ (tm - timedelta(minutes=tm.minute % 5,seconds=tm.second,microseconds=tm.microsecond)).isoformat() }}
      solarstart: >
        {{((states('input_datetime.solarstart'))|as_datetime).strftime("%H:%M:%S")}}
      solarend: >
        {{((states('input_datetime.solarend'))|as_datetime).strftime("%H:%M:%S")}}
      dayload: 100
      nightload: 300
  - choose:
      - alias: Save rounded datetime when sun starts
        conditions:
          - condition: trigger
            id:
              - SunStart
        sequence:
          - service: input_datetime.set_datetime
            target:
              entity_id: input_datetime.solarstart
            data:
              datetime: |
                {{now_rounded}}
      - alias: Save rounded datetime when sun ends
        conditions:
          - condition: trigger
            id:
              - SunEnd
        sequence:
          - service: input_datetime.set_datetime
            target:
              entity_id: input_datetime.solarend
            data:
              datetime: |
                {{now_rounded}}
      - alias: Update schedule daily with saved solar production times
        conditions:
          - condition: trigger
            id:
              - SetSchedule
          - alias: Check that schedule entity is available
            condition: not
            conditions:
              - condition: state
                entity_id: number.sb_e1600_system_home_preset
                state: unknown
        sequence:
          - service: anker_solix.update_solarbank_schedule
            target:
              entity_id: sensor.sb_e1600_home_preset
            data:
              start_time: "00:00:00"
              end_time: |
                {{solarstart}}
              appliance_load: |
                {{nightload}}
              charge_priority_limit: 5
              allow_export: true
            enabled: true
          - delay:
              hours: 0
              minutes: 0
              seconds: 5
              milliseconds: 0
            enabled: true
          - service: anker_solix.update_solarbank_schedule
            target:
              entity_id: sensor.sb_e1600_home_preset
            data:
              start_time: |
                {{solarstart}}
              end_time: |
                {{solarend}}
              appliance_load: |
                {{dayload}}
              charge_priority_limit: 5
              allow_export: false
          - delay:
              hours: 0
              minutes: 0
              seconds: 5
              milliseconds: 0
            enabled: true
          - service: anker_solix.update_solarbank_schedule
            target:
              entity_id: sensor.sb_e1600_home_preset
            data:
              start_time: |
                {{solarend}}
              end_time: "23:59:00"
              appliance_load: |
                {{nightload}}
              charge_priority_limit: 5
              allow_export: true
      - conditions:
          - condition: trigger
            id:
              - InverterOff
          - alias: Check that SOC is high
            condition: numeric_state
            entity_id: sensor.system_bkw_sb_state_of_charge
            above: 80
          - alias: >-
              Check schedule exists and middle interval active for at least 6 min. after 18:00
            condition: template
            value_template: >
              {% set slots = (state_attr('sensor.sb_e1600_home_preset','schedule')).ranges|default([])|list %}
              {{ slots|length > 2 and today_at("18:00:00").time() <= now().time().replace(second=0,microsecond=0) < (strptime(slots[1].end_time.replace('24:00','23:59'),"%H:%M")-timedelta(minutes=6)).time()}}
        sequence:
          - alias: Shorten daytime interval if inverter went off before solar end but solarbank has high SOC to allow complete discharge at night
            service: anker_solix.update_solarbank_schedule
            target:
              entity_id: sensor.sb_e1600_home_preset
            data:
              start_time: >
                {# round next minute to 5 minutes #}
                {% set tm = now() + timedelta(minutes=1) %}
                {{ (tm + timedelta(minutes=4-tm.minute % 5,seconds=60-tm.second,microseconds=-tm.microsecond)).strftime("%H:%M:%S") }}
              end_time: "23:59:00"
              appliance_load: |
                {{nightload}}
              charge_priority_limit: 5
              allow_export: true
      - alias: Start daytime inteval earlier if sufficient early solar power
        conditions:
          - condition: trigger
            id:
              - EarlySolar
          - condition: time
            before: "10:00:00"
          - alias: >-
              Check schedule available and first interval active for >6 minutes
            condition: template
            value_template: >
              {% set slots = (state_attr('sensor.sb_e1600_home_preset','schedule')).ranges|default([])|list %}
              {{ slots|length > 2 and now().time().replace(second=0,microsecond=0) < (strptime(slots[0].end_time.replace('24:00','23:59'),"%H:%M")-timedelta(minutes=6)).time()}}
        sequence:
          - alias: Start daytime interval earlier
            service: anker_solix.update_solarbank_schedule
            target:
              entity_id: sensor.sb_e1600_home_preset
            data:
              start_time: >
                {# round next minute to 5 minutes #}
                {% set tm = now() + timedelta(minutes=1) %}
                {{ (tm + timedelta(minutes=4-tm.minute % 5,seconds=60-tm.second,microseconds=-tm.microsecond)).strftime("%H:%M:%S") }}
              end_time: "{{solarend}}"
              appliance_load: |
                {{dayload}}
              charge_priority_limit: 5
              allow_export: false
mode: queued
max: 3

Automation to adjust home load export switch of solarbank system

Explanation

This automation will change the Solarbank appliance power export switch setting as required. Initially you may think this is not required since it could be set ON by the daytime schedule interval for allowing output preset changes all the time as needed. And you are right, this is the way it should be. However, you have to change it to limit some firmware flaws because the solarbank may change suddenly into a discharge mode during daytime with varying conditions. Each undesired switch to discharge will cost you about 30 minutes solar energy that is not produced because Solarbank 1 cannot discharge and produce at the same time, so it will discharge with the output preset for 10-30 minutes. Additionally, when switching back to solar production, the solar power may remain limited to 35 W for at least 10 minutes to allow various inverters to ramp up once the solar production starts. So this may end up in really bad efficiency for solar production, especially on partially cloudy days.

Initially I built this automation just to disable the export switch once discharge state is discovered at daytime interval to limit the solar energy loss as much as possible. Correspondingly I added triggers and rules to re-enable the export switch again when solar conditions justify the risk of re-enabling the switch. You need to consider that the power bypass is also working when the export switch is off, but it is limited to the defined inverter minimum power setting, which is 100 W for Anker inverters or 150 W for 3rd party inverters. This bypass limit is OK while there is not much more solar to expect. However, if you want to adjust the preset to higher values, it will be applied only when the export switch is enabled.

Note:

The minimum bypass usage with disabled Export switch does not work when Charge Priority with MI80 is applicable, or the 0 W switch is installed for 3rd party inverters. In both cases, deactivation of the home load export switch will cause 0 W bypassed to the house, which is NEVER the goal of these automations. Without active charge priority or 0 W Switch, a deactivation of the export switch has following major function:

Disable a potential discharge of the battery, but maintain the minimum bypass of up to 100/150 W to the house. The minimum depends on your defined inverter in the Anker app.

In my journey to improve the automatic discharge behaviour of the Solarbank with Anker support, I got provided following rules that are supposed to be applied for automatic discharge as of firmware 1.6.2:

Solar power less than 20 W for more than 10 minutes
Solar power below 100 W and more than 100 W below preset for more than 10 minutes

I factored in some automation rules to prevent these rules can kick in at all, but discovered that the 10 minute condition time is not always applied and discharge condition can happen sooner. Even when the export switch is off and discharge is not allowed, the firmware may still apply the rule, but then discover that discharge is not possible. However it still applies the 10 minute ramp up period for a solar start with solar limitation to 35 W even if much more solar power could be generated. My final automations have built in some improved rules to avoid the switch to discharge completely by lowering the presets if needed in the other automations, but also to disable the export switch when no regulation above the configured bypass minimum power is required.

Entities to be replaced

Following entities need to be replaced:

sensor.system_bkw_sb_state_of_charge
input_select.power_regulation_mode
sensor.energy_next_hour
sensor.sun_solar_elevation
sensor.sb_e1600_mode
sensor.system_bkw_sb_solar_power
switch.sb_e1600_allow_power_export
sensor.sb_e1600_home_preset
number.sb_e1600_system_home_preset
input_boolean.regulation_increase_ok
sensor.system_bkw_sb_solar_power

Expand to see Automation Code

Copy and paste the automation code into a new UI Automation using the YAML mode. You will need to adjust the triggers for SunStart and SunEnd according to your solar panel environment. Please review also all other templates and variables for required parameter adjustments.

alias: "Adjust Solarbank Export Switch"
description: >-
  Adjust solarbank export switch depending on daily solar forecast
trigger:
  - platform: state
    id: SOC
    entity_id:
      - sensor.system_bkw_sb_state_of_charge
    to: null
  - alias: High solar power next hour depending on mode
    platform: template
    id: HighForecast
    value_template: |
      {% set mode = states('input_select.power_regulation_mode') %}
      {% set nexthour = states('sensor.energy_next_hour')|float(0) %}
      {{nexthour > 0.1 if mode == 'aggressive' else nexthour > 0.15 }}
  - platform: numeric_state
    id: Dark
    entity_id:
      - sensor.sun_solar_elevation
    below: 0
  - platform: numeric_state
    id: FullSOC
    entity_id:
      - sensor.system_bkw_sb_state_of_charge
    above: 99
  - platform: state
    id: Discharge
    entity_id:
      - sensor.sb_e1600_mode
    to: discharge
  - platform: numeric_state
    id: LowSolar
    entity_id:
      - sensor.system_bkw_sb_solar_power
    for:
      hours: 0
      minutes: 5
      seconds: 0
    below: 80
  - platform: state
    id: Disabled
    entity_id:
      - switch.sb_e1600_allow_power_export
    from: "on"
    to: "off"
condition:
  - alias: Check schedule available and middle interval is active or its dark
    condition: template
    value_template: >
      {% set slots =
      (state_attr('sensor.sb_e1600_home_preset','schedule')).ranges|default([])|list
      %} {% if slots|length > 2 %}
        {# expected schedule format, ensure 2nd slot (day interval) #}
        {{ strptime(slots[1].start_time,"%H:%M").time() <= now().time().replace(second=0,microsecond=0) < strptime(slots[1].end_time.replace('24:00','23:59'),"%H:%M").time()}}
      {% else %}
        {# unexpected schedule format, allow discharge and export if disabled at night #}
        {{states('sensor.sun_solar_elevation')|int(0) < 0 and is_state('switch.sb_e1600_allow_power_export','off') and states('sensor.system_bkw_sb_state_of_charge')|int(0) > 10 }}
      {% endif %}
action:
  - choose:
      - alias: When export was disabled, reset necessary regulation entities for daytime interval
        conditions:
          - condition: trigger
            id:
              - Disabled
        sequence:
          - alias: Reset output preset to minimum when switched off
            if:
              - condition: numeric_state
                entity_id: number.sb_e1600_system_home_preset
                above: 100
            then:
              - service: number.set_value
                target:
                  entity_id: number.sb_e1600_system_home_preset
                data:
                  value: "100"
          - alias: Disable power increase helper
            if:
              - condition: state
                entity_id: input_boolean.regulation_increase_ok
                state: "on"
            then:
              - service: input_boolean.turn_off
                target:
                  entity_id:
                    - input_boolean.regulation_increase_ok
                data: {}
      - alias: Check when export should be disabled to prevent daytime discharge
        conditions:
          - condition: trigger
            id:
              - FullSOC
              - Discharge
              - LowSolar
          - condition: state
            entity_id: switch.sb_e1600_allow_power_export
            state: "on"
        sequence:
          - service: switch.turn_off
            target:
              entity_id:
                - switch.sb_e1600_allow_power_export
            data: {}
          - alias: Logbook entry to track considered values for change
            service: logbook.log
            data:
              message: >
                {% set entity = 'sensor.energy_next_hour' if trigger.platform == 'template' else trigger.to_state.entity_id %} {{'Triggered by '~trigger.id|default('')~' (State '~''.join([states(entity,rounded=False,with_unit=True),state_attr(entity,'friendly_name')])~')'}}
              name: "Disable Solarbank Export:"
              entity_id: switch.sb_e1600_allow_power_export
      - alias: Check if export switch can be enabled
        conditions:
          - condition: state
            entity_id: switch.sb_e1600_allow_power_export
            state: "off"
          - alias: Check if activation makes sense
            condition: or
            conditions:
              - alias: Check battery is not full
                condition: numeric_state
                entity_id: sensor.system_bkw_sb_state_of_charge
                below: 100
              - alias: Check its dark and battery not empty
                condition: and
                conditions:
                  - condition: numeric_state
                    entity_id: sensor.system_bkw_sb_state_of_charge
                    above: 10
                  - condition: numeric_state
                    entity_id: sensor.sun_solar_elevation
                    below: 0
                    alias: Dark
        sequence:
          - alias: Wait until regulation mode was changed for same trigger
            delay:
              hours: 0
              minutes: 0
              seconds: 1
              milliseconds: 0
          - alias: Check if export should be activated
            if:
              - condition: or
                conditions:
                  - condition: trigger
                    id:
                      - HighForecast
                  - alias: >-
                      Check high production above xx% SOC or high forecast depending on mode
                    condition: and
                    conditions:
                      - condition: trigger
                        id:
                          - SOC
                      - alias: Check SOC is rising and battery not full
                        condition: template
                        value_template: >
                          {{trigger.from_state.state|int(0) < trigger.to_state.state|int(0) < 100}}
                      - alias: >-
                          Check if high production next hour or certain  SOC depending on mode
                        condition: template
                        value_template: >
                          {% set mode = states('input_select.power_regulation_mode') %}
                          {% set soc = states('sensor.system_bkw_sb_state_of_charge')|int(0) %}
                          {% set solar = states('sensor.system_bkw_sb_solar_power')|int(0) %}
                          {% set nexthour = states('sensor.energy_next_hour')|float(0) %}
                          {{(nexthour > 0.1 or solar > 150) if mode == 'aggressive' else (nexthour > 0.2 or solar > 250 and soc > 20)}}
            then:
              - service: switch.turn_on
                target:
                  entity_id: switch.sb_e1600_allow_power_export
                data: {}
              - alias: Logbook entry to track considered values for change
                service: logbook.log
                data:
                  message: >
                    {% set entity = 'sensor.energy_next_hour' if trigger.platform == 'template' else trigger.to_state.entity_id %}
                    {{'Triggered by '~trigger.id|default('')~' (State '~''.join([states(entity,rounded=False,with_unit=True),state_attr(entity,'friendly_name')])~')'}}
                  name: "Enable Solarbank Export:"
                  entity_id: switch.sb_e1600_allow_power_export
mode: queued
max: 10

Automation to adjust solarbank preset

Explanation

This is the main automation that makes the solarbank home preset adjustments under certain conditions and based on various parameters for the active regulation mode.

The algorithm used is an improvement from my former invert limit adjustment project described in the HA community. The parameters for the algorithm are typically defined in the variables section. For decreases I still used the calculation for the actual home consumption, since I want to react quickly on grid exports that exceed the defined lower range. For increases however, I found it beneficial to use the house consumption median value since that can flatten out short spikes in the home grid or the calculation. I also introduced a binary switch and a timer to delay the first increase and delay subsequent increases to follow a lazy increase approach. The reason for that is that it is not beneficial to regulate a short pulsing high peek consumption like some home consumers may use, for example modern cooking fields, washing machines etc.

Following closeup screenshot demonstrates the effectiveness of the algorithm for moderate changes using a fridge consumer.

The orange house consumption median is mainly fluctuating by the fridge power toggling off/on/off. The purple line shows the solarbank home load preset which reacts immediately when preset must be decreased, but reacts lazy when it can be increased again after the fridge toggled on. The result is that you see a short grid import bump when a consumer is switched on, which is no problem at all. But you see only a very short export glitch when a consumer is turned off again. For the rest of the time the grid power is close to 0 W, showing only micro fluctuations which you always have in your home grid. Therefore it is important that you regulate in a range of approximately 30 W only to avoid too many unnecessary toggling of your solarbank home load preset.

If you make the ac_efficiency progressive factor too low, this may overshoot the target and resulting in an quick adjustment into opposite direction which you should avoid. The limit curve will show that the new limit was overestimated. This factor is less significant for low power limits, but for higher limits it should adopt closely to your inverter DC/AC loss to ensure the AC output will be close to the house consumption value. The offset_factor is used to shift the target output towards conservative (positive) or aggressive (negative) values, resulting in no or minimal grid export. This factor is used in combination with the defined base that is used for rounding the new preset value. For the solarbank I use 10 W as base, which is identical to the mobile app granularity. Do not choose too small bases, since that may result in much more preset changes which are not beneficial at all and cause much more api requests.

The grid power ranges for the moderate and the aggresive modes should also be 30 W at least, otherwise your automation may also perform too many non-beneficial adjustments. At the end, you will need to spend time to monitor the algorithm efficiency closely in the beginning to ensure it works as desired. When you apply changes, make them small and verify the result. Changes can make the efficiency also worse in various situations.

Entities to be replaced

Following entities need to be replaced:

sensor.grid_power
sensor.system_bkw_sb_solar_power
sensor.system_bkw_system_home_preset
sensor.sun_solar_elevation
switch.sb_e1600_allow_power_export
timer.regulation_delay
sensor.sb_e1600_mode
sensor.system_bkw_sb_state_of_charge
sensor.sb_e1600_home_preset
input_select.power_regulation_mode
sensor.house_consumption & sensor.house_consumption_median
number.sb_e1600_system_home_preset
input_boolean.regulation_increase_ok
sensor.inverter_power

Expand to see Automation Code

Copy and paste the automation code into a new UI Automation using the YAML mode. You may need to adjust the parameters in the variables section according to your inverter or desired grid power ranges. Please review also all other templates and variables for required parameter adjustments.

alias: "Adjust Solarbank home load preset"
description: >-
  Dynamically change the solarbank home load preset at daytime interval to stretch the battery charge over the whole day (Surplus charging)
trigger:
  - alias: New grid power value
    platform: state
    entity_id:
      - sensor.grid_power
    to: null
  - alias: Solar power below 100 W for 5 minutes
    id: LowSolar
    platform: numeric_state
    entity_id:
      - sensor.system_bkw_sb_solar_power
    for:
      hours: 0
      minutes: 5
      seconds: 0
    below: 100
  - alias: Solar power more than 80 W below home load preset
    id: SolarBelowPreset
    platform: template
    value_template: >-
      {% set preset = states('sensor.system_bkw_system_home_preset')|int(0) %}
      {{preset > 100 and preset - states('sensor.system_bkw_sb_solar_power')|int(0) > 80}}
condition:
  - alias: Check sun is high enough for meaningful regulation
    condition: numeric_state
    entity_id: sensor.sun_solar_elevation
    above: 4
  - alias: Check solarbank power export is enabled
    condition: state
    entity_id: switch.sb_e1600_allow_power_export
    state: "on"
  - condition: or
    conditions:
      - condition: trigger
        id:
          - LowSolar
          - SolarBelowPreset
      - alias: Check regulation timer is idle
        condition: state
        entity_id: timer.regulation_delay
        state: idle
      - alias: Check if grid export occurs
        condition: numeric_state
        entity_id: sensor.grid_power
        below: 0
  - alias: Check solarbank is installed and not discharging
    condition: not
    conditions:
      - condition: state
        entity_id: sensor.sb_e1600_mode
        state:
          - unavailable
          - discharge
  - alias: Check battery is not full
    condition: numeric_state
    entity_id: sensor.system_bkw_sb_state_of_charge
    below: 100
  - alias: Check schedule is available and daytime interval active
    condition: template
    value_template: >
      {% set slots = (state_attr('sensor.sb_e1600_home_preset','schedule')).ranges|default([])|list %}
      {{ slots|length > 2 and strptime(slots[1].start_time,"%H:%M").time() <= now().time().replace(second=0,microsecond=0) < (strptime(slots[1].end_time.replace('24:00','23:59'),"%H:%M")-timedelta(seconds=10)).time()}}
action:
  - variables:
      mode: |
        {{states('input_select.power_regulation_mode')}}
      consumption: |
        {{states('sensor.house_consumption')|int(0)}}
      consumption_median: |
        {% set entity = 'sensor.house_consumption_median' %}
        {{states(entity)|int(0) if has_value(entity) else consumption}}
      solar: |
        {{states('sensor.system_bkw_sb_solar_power')|int(0)}}
      grid: |
        {{states('sensor.grid_power')|int(0)}}
      low_grid: |
        {# low grid power range for regulation depending on mode #}
        {{(-40) if mode == 'aggressive' else 0}}
      high_grid: |
        {# high grid power range for regulation depending on mode #}
        {{5 if mode == 'aggressive' else 40}}
      ac_efficency: |
        {# Progressive factor for preset calculation, higher solarbank preset may need more correction to get desired AC output #}
        {# Typically the inverter DC/AC efficiency #}
        {{0.95}}
      min_preset: 100
      max_preset: 600
      actual_preset: |
        {{states('number.sb_e1600_system_home_preset')|int(0)}}
      delay_minutes: |
        {# Timer delay in minutes for next increase depending on mode #}
        {{0.55 if mode == 'aggressive' else 1}}
      base: |
        {# Base for rounding of solarbank output preset calculation #}
        {{10}}
      offset_factor: |
        {# offset factor in relation to base for preset calculation #}
        {# This is a linear offset for preset calculation, negative means more aggressive #}
        {{(-1) if mode == 'aggressive' else 1}}
  - choose:
      - alias: Check Grid export and decrease home load preset under given conditions
        conditions:
          - alias: Check if grid export exceeds low range limit
            condition: template
            value_template: |
              {{grid < low_grid}}
          - alias: Check if home load preset can be further decreased
            condition: template
            value_template: "{{actual_preset > min_preset}}"
        sequence:
          - alias: >-
              Short delay for updated house consumption value based on same trigger as required for new decrease preset
            delay:
              hours: 0
              minutes: 0
              seconds: 1
              milliseconds: 0
          - variables:
              consumption: |
                {{states('sensor.house_consumption')|int(0)}}
              new_preset: >
                {# Decrease solarbank preset rounded down by base below consumption value, consider inverter efficency #}
                {% set max_preset = min(max_preset,actual_preset) %}
                {% set new_preset = max(min(max_preset,consumption/ac_efficency-base*offset_factor),min_preset)|int %}
                {# Round preset down to base #}
                {{new_preset - (base + new_preset) % base}}
          - if:
              - alias: Check new preset is really below actual preset
                condition: template
                value_template: "{{new_preset < actual_preset}}"
              - alias: Check again solarbank export is enabled
                condition: state
                entity_id: switch.sb_e1600_allow_power_export
                state: "on"
            then:
              - alias: Decrease home load preset
                service: number.set_value
                data:
                  value: |
                    {{new_preset}}
                target:
                  entity_id: number.sb_e1600_system_home_preset
              - alias: Start regulation timer to delay next increase check
                service: timer.start
                target:
                  entity_id: timer.regulation_delay
                data:
                  duration: "{{int(delay_minutes*60)}}"
              - alias: Logbook entry to track considered values for change
                service: logbook.log
                data:
                  message: >
                    {{actual_preset}} => {{new_preset}} W with {{consumption}} W house consumption and {{grid}} W grid
                  name: "Decrease Solarbank Preset ({{mode}}):"
                  entity_id: switch.sb_e1600_allow_power_export
              - alias: Delay next trigger 15 sec for solarbank preset apply
                delay:
                  hours: 0
                  minutes: 0
                  seconds: 15
                  milliseconds: 0
              - alias: Disable regulation increase switch for lazy increase
                if:
                  - condition: state
                    entity_id: input_boolean.regulation_increase_ok
                    state: "on"
                then:
                  - service: input_boolean.turn_off
                    target:
                      entity_id:
                        - input_boolean.regulation_increase_ok
                    data: {}
      - alias: >-
          High consumption, increase solarbank home load preset under certain conditions
        conditions:
          - alias: Check regulation delay timer is idle
            condition: state
            entity_id: timer.regulation_delay
            state: idle
            enabled: true
          - alias: >-
              Check grid import is exceeding upper limit of range
            condition: template
            value_template: "{{grid > high_grid}}"
          - alias: Check actual preset is below max preset
            condition: template
            value_template: "{{actual_preset < max_preset}}"
          - alias: >-
              Check actual output power is not limited compared to actual preset or solar because further increase will not help
            condition: template
            value_template: >-
              {{actual_preset*ac_efficency-states('sensor.inverter_power')|int(0) < 30 and actual_preset < solar}}
        sequence:
          - variables:
              new_preset: >
                {# Increase solarbank preset rounded down by base to median consumption with offset, consider inverter efficeny and actual solar power #}
                {% set new_preset = max(min(max_preset,consumption_median/ac_efficency-base*offset_factor,solar+(50-solar)%50),min_preset)|int %}
                {# Round down to base #} {{new_preset - (base + new_preset) % base}}
          - if:
              - alias: Check new preset larger than actual preset
                condition: template
                value_template: "{{new_preset > actual_preset}}"
            then:
              - alias: Increase if allowed, otherwise enable increase switch
                if:
                  - condition: state
                    entity_id: input_boolean.regulation_increase_ok
                    state: "on"
                then:
                  - alias: Increase solarbank home load preset
                    service: number.set_value
                    data:
                      value: |
                        {{new_preset}}
                    target:
                      entity_id: number.sb_e1600_system_home_preset
                    enabled: true
                  - alias: Logbook entry to track considered values for change
                    service: logbook.log
                    data:
                      message: >
                        {{actual_preset}} => {{new_preset}} W with
                        {{consumption_median}} W house consumption, {{solar}} W solar and {{grid}} W grid
                      name: "Increase Solarbank Preset ({{mode}}):"
                      entity_id: switch.sb_e1600_allow_power_export
                else:
                  - service: input_boolean.turn_on
                    target:
                      entity_id: input_boolean.regulation_increase_ok
                    data: {}
              - alias: Start regulation timer to delay next increase
                service: timer.start
                target:
                  entity_id: timer.regulation_delay
                data:
                  duration: "{{int(delay_minutes*60)}}"
      - alias: >-
          Decrease home load preset to prevent sudden solarbank discharge during daytime interval when low solar and preset above minimum
        conditions:
          - condition: trigger
            id:
              - LowSolar
              - SolarBelowPreset
          - alias: Actual preset above minimum
            condition: numeric_state
            entity_id: sensor.system_bkw_system_home_preset
            above: 100
        sequence:
          - variables:
              new_preset: >
                {# Round solarbank preset by base to either solar power roundup by 50 or preset minimum #}
                {# Use same solar power roundup as increase step to avoid flip flop preset changes #}
                {% set target = max(min(max_preset,solar+(50-solar)%50),min_preset)|int %}
                {{100 if trigger.id == "LowSolar" else target + (base - target) % base}}
          - alias: Decrease home load preset
            service: number.set_value
            data:
              value: "{{new_preset}}"
            target:
              entity_id: number.sb_e1600_system_home_preset
          - alias: Start regulation timer to delay next increase check
            service: timer.start
            target:
              entity_id: timer.regulation_delay
            data:
              duration: "{{int(delay_minutes*60)}}"
          - alias: Logbook entry to track considered values for change
            service: logbook.log
            data:
              message: >
                {{actual_preset}} => {{new_preset}} W with {{solar}} W solar for several minutes far below preset
              name: "Decrease Solarbank Preset ({{mode}}):"
              entity_id: switch.sb_e1600_allow_power_export
          - alias: Disable regulation increase switch for lazy increase
            if:
              - condition: state
                entity_id: input_boolean.regulation_increase_ok
                state: "on"
            then:
              - service: input_boolean.turn_off
                target:
                  entity_id:
                    - input_boolean.regulation_increase_ok
                data: {}
mode: queued
max: 10

Automation to adjust inverter limit

Explanation

This is the main regulation automation for the inverter limit, but not to be used at daytime interval. Unlike the automation to adjust the solarbank home load preset, the inverter regulation is a combination of an automation and a script which is only executed by the automation if a change may be required. It can also be combined into a single automation, but I split this in a past project when I implemented the inverter adjustment automation as described in the HA community.

A script works essentially the same as an automation, but without triggers. I used it for the action part of the regulation. The advantage of the split is that it simplifies the debugging. While the automation is triggered every 3-5 seconds, the script will just be called when a change may be necessary. Therefore the traces for a potential change wrap slower than for an automation, which makes it easier for real time debugging when and why changes have been applied.

This is an improved version of the algorithm along the changes and improvements I implemented for the solarbank home load preset algorithm explained earlier. Similar variable and parameter settings apply here. It is not using the same laziness as the solarbank algorithm because the hoymiles limit settings are applied quicker then solarbank power settings. However increases will now also use the home consumption median value to ignore any power or calculation spikes upon limit increases. It also supports the two regulation modes, where aggressive mode is to be used typically only for short nights in summer when battery is full and house consumption does not indicate full discharge capability. So in case of surplus charge as indicated by aggressive mode setting, minimal grid export is tolerated to keep the import down to 0 W most of the time.

Entities to be replaced

Following entities needs to be replaced in the automation and the script:

sensor.sb_e1600_mode
sensor.grid_power
binary_sensor.hoymiles_hm_600_producing
number.hoymiles_hm_600_limit_nonpersistent_absolute
sensor.sun_solar_elevation
sensor.sb_e1600_home_preset
input_select.power_regulation_mode
timer.regulation_delay
sensor.house_consumption & sensor.house_consumption_median
sensor.hoymiles_hm_600_ch1_power & sensor.hoymiles_hm_600_ch2_power
sensor.inverter_power
script.inverter_regulation

Expand to see Automation Code

Copy and paste the automation code into a new UI Automation using the YAML mode. You may need to adjust the parameters in the variables section according to your inverter or desired grid power ranges. Please review also all other templates and variables for required parameter adjustments.

alias: Adjust Inverter limit
description: >-
  Dynamically adjust the temporary inverter output limit to prevent grid export while the solarbank is discharging at night intervals
trigger:
  - platform: state
    id: Discharge
    entity_id:
      - sensor.sb_e1600_mode
    to: discharge
  - alias: New grid value
    platform: state
    entity_id:
      - sensor.grid_power
    to: null
condition:
  - alias: Check inverter is producing AC power
    condition: state
    state: "on"
    entity_id: binary_sensor.hoymiles_hm_600_producing
  - condition: state
    alias: Check solarbank is discharging
    entity_id: sensor.sb_e1600_mode
    state: discharge
  - condition: or
    conditions:
      - alias: Check sun is low enough for inverter regulation
        condition: numeric_state
        entity_id: sensor.sun_solar_elevation
        below: 4
      - alias: >-
          Check solarbank schedule is available and daytime interval not active
        condition: template
        value_template: >
          {% set slots = (state_attr('sensor.sb_e1600_home_preset','schedule')).ranges|default([])|list %}
          {{ slots and (slots|length > 2 and not strptime(slots[1].start_time,"%H:%M").time() <= now().time().replace(second=0,microsecond=0) < (strptime(slots[1].end_time.replace('24:00','23:59'),"%H:%M")-timedelta(seconds=10)).time()) }}
action:
  - variables:
      min_limit: 30
      max_limit: 600
      actual_limit: >
        {{states('number.hoymiles_hm_600_limit_nonpersistent_absolute')|float(0)|round(-1)}}
      mode: |
        {{states('input_select.power_regulation_mode')}}
      grid: |
        {{states('sensor.grid_power')|int(0)}}
      low_grid: |
        {# low grid power range for regulation #}
        {{(-15) if mode == 'aggressive' else 0}}
      high_grid: |
        {# high grid power range for regulation #}
        {{5 if mode == 'aggressive' else 30}}
  - choose:
      - alias: >-
          Decrease inverter limit upon grid export or solarbank discharge under certain conditions
        conditions:
          - condition: or
            conditions:
              - alias: Check Solarbank is discharging
                condition: trigger
                id:
                  - Discharge
              - alias: Check grid export exceeds lower limit
                condition: template
                value_template: |
                  {{grid < low_grid}}
          - alias: Check if inverter limit can be increased further
            condition: template
            value_template: "{{actual_limit > min_limit}}"
        sequence:
          - alias: Call script to reduce inverter limit
            service: script.inverter_regulation
            data:
              action: decrease
              min_limit: "{{min_limit}}"
              max_limit: "{{max_limit}}"
              actual_limit: "{{actual_limit}}"
      - alias: >-
          Increase inverter limit upon high consumption under certain conditions
        conditions:
          - alias: Check grid import exceeds high range limit
            condition: template
            value_template: "{{grid > high_grid}}"
          - alias: Check inverter limit is below defined max limit
            condition: template
            value_template: "{{actual_limit < max_limit}}"
          - alias: Check regulation timer is idle for lazy increase
            condition: state
            entity_id: timer.regulation_delay
            state: idle
        sequence:
          - alias: Call script to increase inverter limit
            service: script.inverter_regulation
            data:
              action: increase
              min_limit: "{{min_limit}}"
              max_limit: "{{max_limit}}"
              actual_limit: "{{actual_limit}}"
mode: queued
max: 10

Expand to see Script Code

The following script script.inverter_regulation is called by the inverter limit adjustment automation. Make sure that the script name will match the service name in the automation. Please also adjust the variable parameters as required.

alias: Inverter regulation
description: >-
  Adjust the temporary inverter limit with given parameters to avoid grid export during discharge of solarbank
sequence:
  - variables:
      ac_efficency: |
        {# Progressive factor for preset calculation, higher inverter DC limit may need more correction to get desired AC output #}
        {# Typically the inverter DC/AC efficiency #}
        {{0.95}}
      mode: |
        {{states('input_select.power_regulation_mode')}}
      min_limit: |
        {# set default if not provided by service call #}
        {{min_limit if min_limit is defined and min_limit != none else 30}}
      max_limit: |
        {# set default if not provided by service call #}
        {{max_limit if max_limit is defined and max_limit != none else 600}}
      actual_limit: >
        {# set default if not provided by service call #}
        {{actual_limit if actual_limit is defined and actual_limit != none else states('number.hoymiles_hm_600_limit_nonpersistent_absolute')|float(0)|round(0)}}
      consumption: |
        {{states('sensor.house_consumption')|int(0)}}
      consumption_median: |
        {% set entity = 'sensor.house_consumption_median' %}
        {{states(entity)|int(0) if has_value(entity) else consumption}}
      base: |
        {# Base for rounding of inverter limit calculation #}
        {{5 if mode == 'aggressive' else 10}}
      offset_factor: |
        {# offset factor in relation to base for preset calculation #}
        {# This is a linear offset for limit calculation, negative means more aggressive #}
        {{(-1) if mode == 'aggressive' else 1}}
      ch_factor: >
        {# check how many of total inverter input channels are used for discharging #}
        {# Define all inputs, use 2 W as min. to avoid zero division and ignore smaller values #}
        {% set ch1 = max(2,states('sensor.hoymiles_hm_600_ch1_power')|float(0)) %}
        {% set ch2 = max(2,states('sensor.hoymiles_hm_600_ch2_power')|float(0)) %}
        {# define channel 3 & 4 if available, otherwise set them to 1 & 2 #}
        {% set ch3 = ch1 %}
        {% set ch4 = ch2 %}
        {% set channels = [ch1,ch2,ch3,ch4] %}
        {# Percentage of used channels compared to channel with max load #}
        {% set percent = (average(channels) / max(channels) * 100)|round %}
        {# round to nearest possible channel factor #}
        {% set ch_base = 100 / channels|count %}
        {{(percent/ch_base)|round * ch_base / 100}}
  - choose:
      - alias: Check if limit should be decreased
        conditions:
          - condition: template
            value_template: "{{action|lower == 'decrease'}}"
        sequence:
          - alias: >-
              Short delay for updated house consumption value based on same trigger as required for new decrease preset
            delay:
              hours: 0
              minutes: 0
              seconds: 1
              milliseconds: 0
          - variables:
              consumption: |
                {{states('sensor.house_consumption')|int(0)}}
              new_limit: >
                {# Decrease inverter limit rounded down below actual consumption value, consider mode and inverter efficency #}
                {% set max_limit = min(max_limit,actual_limit/ch_factor) %}
                {% set new_limit = max(min(max_limit,consumption/ac_efficency/ch_factor - base*offset_factor),min_limit)|int %}
                {# Round down to base #}
                {{new_limit - (base + new_limit) % base}}
          - alias: Decrease inverter limit when conditions apply
            if:
              - alias: Check new limit is really below actual limit
                condition: template
                value_template: "{{new_limit < actual_limit}}"
            then:
              - alias: Decrease inverter limit
                service: number.set_value
                data:
                  value: |
                    {{new_limit}}
                target:
                  entity_id: number.hoymiles_hm_600_limit_nonpersistent_absolute
              - alias: Start regulation timer to avoid increase prior median value delay
                service: timer.start
                target:
                  entity_id: timer.regulation_delay
                data:
                  duration: 30
      - alias: Check if limit should be increased
        conditions:
          - condition: template
            value_template: "{{action|lower == 'increase'}}"
          - alias: >-
              Check actual output power is not limited compared to actual setting because further increase will not help
            condition: template
            value_template: >-
              {{actual_limit*ac_efficency*ch_factor-states('sensor.inverter_power')|int(0) < 30}}
        sequence:
          - variables:
              new_limit: >
                {# Increase inverter limit rounded up to median consumption, consider mode and inverter efficency #}
                {% set new_limit = max(min(max_limit,consumption_median/ac_efficency/ch_factor - base*offset_factor),min_limit)|int %}
                {# Round down to base #}
                {{new_limit - (base + new_limit) % base}}
          - alias: Increase inverter limit when conditions apply
            if:
              - alias: Check new limit is larger actual limit
                condition: template
                value_template: "{{new_limit > actual_limit}}"
            then:
              - alias: Increase inverter limit
                service: number.set_value
                data:
                  value: |
                    {{new_limit}}
                target:
                  entity_id: number.hoymiles_hm_600_limit_nonpersistent_absolute
              - alias: Start regulation timer to avoid increase prior median value delay
                service: timer.start
                target:
                  entity_id: timer.regulation_delay
                data:
                  duration: 30
icon: mdi:home-battery
mode: queued
max: 3

Automation to reset inverter and its limit

Explanation

This automation is mainly to reset the inverter limit to max. (600/800 W) in order to avoid potential reductions of solar production during the day. It will also be used to reset the inverter daily yields if needed.

Note:

I figured out that the daily inverter yields reported by your inverter integration (e.g. OpenDTU) may no longer be usable by HA for your daily solar yield tracking. One reason is that the inverter typically can switch off multiple times during cloudy/dark days when the solar panels do not produce sufficient power for the solarbank. Upon each inverter power cycle, the daily yields are reset. Another reason is that solar yield is no longer limited to a single day when you use batteries. The solar cycle can stretch over a day and you may want to consider that as well.
I strongly recommend to build your own Rieman Integral sensors from power entities. These power entities ideally are also template sensors from sensors provided by your devices/integration, so they can be used as an 'alias' to a physical device or integration bound sensor. The Rieman integral helper will create an always increasing energy template entity. From that energy entity, you can create your utility meter helpers with reset intervals as needed. They will only be reset at your controlled or manual reset interval and the power entity template provides the capability to switch to a new power entity whenever the used end device or integration entity must be replaced. So you never have to change your automations anymore when they all are based on the template entities instead of end device or integration entites.
Especially for the long term history tracking in the energy dashboard I would never recommend to use any end device or integration entities, since their replacement in the energy dashboard will cause a loss of history data typically.

Entities to be replaced

Following entities needs to be replaced in the automation and the script:

sensor.sb_e1600_mode
sensor.bkw_cycle_start
binary_sensor.hoymiles_hm_600_producing
binary_sensor.hoymiles_hm_600_reachable
sensor.hoymiles_hm_600_yieldday
device_id of HA integration configuration entry for inverter
button.hoymiles_hm_600_restart_inverter
number.hoymiles_hm_600_limit_nonpersistent_absolute
select.solarbank_discharge_kwh & sensor.solarbank_discharge_kwh_solarcycle

Expand to see Automation Code

Copy and paste the automation code into a new UI Automation using the YAML mode. Please review all templates and variables for required parameter adjustments. Especially the inverter reset depends on the used integration. I also included a sequence to reload the configuration entry for the inverter device id, since I had few occasions where entities remained unknown upon inverter start. You may disable or remove this section if not applicable to your inverter, but at least replace the device id with the one you have in your HA setup.

alias: Inverter and Utility meter reset
description: Reset inverter limit at start of solar cycle if it was not off and reset solar cycle utility meters
trigger:
  - platform: state
    alias: Solarbank state indicates solar power
    id: SolarPower
    entity_id:
      - sensor.sb_e1600_mode
    to:
      - charge
      - charge_priority
      - charge_bypass
      - bypass
  - platform: state
    alias: Solar cycle start changed
    id: reset
    entity_id:
      - sensor.bkw_cycle_start
    not_to:
      - unavailable
      - unknown
  - platform: state
    alias: Inverter started AC production
    id: AC Start
    entity_id:
      - binary_sensor.hoymiles_hm_600_producing
    to: "on"
condition: []
action:
  - alias: Check inverter state and restart or reset limit to max
    if:
      - alias: Check inverter is on
        condition: state
        entity_id: binary_sensor.hoymiles_hm_600_reachable
        state: "on"
    then:
      - alias: Wait for few seconds for availability of daily yield value
        wait_for_trigger:
          - platform: state
            entity_id:
              - sensor.hoymiles_hm_600_yieldday
            from: unavailable
        timeout:
          hours: 0
          minutes: 0
          seconds: 10
          milliseconds: 0
      - alias: Reload inverter integration config entry if daily yield does not become available
        if:
          - condition: state
            entity_id: sensor.hoymiles_hm_600_yieldday
            state: unavailable
        then:
          - service: homeassistant.reload_config_entry
            data: {}
            target:
              device_id: 24219185c693b268d6640b68398cb5da
          - delay:
              hours: 0
              minutes: 0
              seconds: 5
              milliseconds: 0
      - alias: >-
          Restart inverter if it was not off prior solar cycle restart
        if:
          - condition: trigger
            id:
              - reset
          - alias: Check if solar cycle was just started
            condition: template
            value_template: >-
              {% set lastreset = states('sensor.bkw_cycle_start') %}
              {{ lastreset not in ['unknown','unavailable'] and now()|as_local-lastreset|as_datetime|as_local < timedelta(minutes=1) }}
          - alias: Check inverter was not off last 5 hours
            condition: template
            value_template: >
              {{expand('binary_sensor.hoymiles_hm_600_reachable')|selectattr('last_changed','lt',now()-timedelta(hours=5))|map(attribute='entity_id')|list|count > 0 }}
        then:
          - alias: Restart inverter to reset limit and daily yield
            service: button.press
            data: {}
            target:
              entity_id: button.hoymiles_hm_600_restart_inverter
          - alias: Wait for inverter limit entity availability
            wait_for_trigger:
              - platform: state
                entity_id:
                  - number.hoymiles_hm_600_limit_nonpersistent_absolute
                from: unavailable
            timeout:
              hours: 0
              minutes: 0
              seconds: 30
              milliseconds: 0
      - alias: Reset inverter limit any time when solarbank not discharging
        if:
          - alias: Check inverter limit below max
            condition: numeric_state
            entity_id: number.hoymiles_hm_600_limit_nonpersistent_absolute
            below: 599
          - alias: Testen dass Solarbank nicht am Entladen
            condition: not
            conditions:
              - condition: state
                entity_id: sensor.sb_e1600_mode
                state: discharge
        then:
          - alias: Reset inverter limit to ensure max solarbank power generation
            service: number.set_value
            data:
              value: 600
            target:
              entity_id: number.hoymiles_hm_600_limit_nonpersistent_absolute
  - alias: Reset utility meters for daily solar cycle
    if:
      - condition: trigger
        id:
          - reset
    then:
      - alias: >-
          Ensure some delay in case reset was triggered by HA restart circumstances
        delay:
          hours: 0
          minutes: 0
          seconds: 10
          milliseconds: 0
      - alias: Reset Solarbank daily discharge utility meter
        if:
          - alias: Check utility meter was not already reset today
            condition: template
            value_template: >-
              {% set lastreset = state_attr('sensor.solarbank_discharge_kwh_solarcycle','last_reset') %}
              {% set reset = states('sensor.bkw_cycle_start') %}
              {{ reset not in ['unknown','unavailable'] and lastreset != None and (lastreset == '' or (lastreset|as_datetime|as_local).day != (reset|as_datetime|as_local).day) }}
        then:
          - alias: Reset select entity of utility meter
            service: utility_meter.reset
            data: {}
            target:
              entity_id:
                - select.solarbank_discharge_kwh
      - alias: Reset Solarbank daily charge utility meter
        if:
          - alias: Check utility meter was not already reset today
            condition: template
            value_template: >-
              {% set lastreset = state_attr('sensor.solarbank_charge_kwh_solarcycle','last_reset') %}
              {% set reset = states('sensor.bkw_cycle_start') %}
              {{ reset not in ['unknown','unavailable'] and lastreset != None and (lastreset == '' or (lastreset|as_datetime|as_local).day != (reset|as_datetime|as_local).day) }}
        then:
          - alias: Reset select entity of utility meter
            service: utility_meter.reset
            data: {}
            target:
              entity_id:
                - select.solarbank_charge_kwh
mode: queued
max: 5

chrisuki · 2024-07-25T08:41:01Z

chrisuki
Jul 25, 2024

Hi,
As I mentioned it on the HA community, again thank you a lot for this valuable contribution!
I found an issue in the first automation "Automation to set helper for the regulation mode":

- alias: Set regulation mode to moderate
  target:
    entity_id: input_select.power_regulation_mode
    data:
      option: moderate
  alias: Solarbank Optimierung auf moderate stellen

I needed to remove the last line "alias" to make it work.

1 reply

thomluther Jul 25, 2024
Maintainer Author

Thx, will correct it

desvelado · 2024-07-25T21:20:35Z

desvelado
Jul 25, 2024

I added the first automation via yaml editor to automation ui and get the following error:
"Message malformed: extra keys not allowed @ data['0']"

I googled it but it seems not to be clear what it is. delete "" works not variables should be correct.
i added no extra logbook - should i?

what could be wrong with data ? the error is quite senseless, because no line is addressed. is there any other debugging option available?

alias: "Adjust home power regulation mode entity"
description: ""
trigger:
'i deleted the code with some errors to keep the overview'
mode: queued
max: 3

thanks for any hints - replaced only entity names

0 replies

thomluther · 2024-07-25T22:12:57Z

thomluther
Jul 25, 2024
Maintainer Author

I assume your variable do not resolve correctly. You should check all your templates in the developper tools to ensure they are ok for the automations.
Otherwise it is very difficult to debug when they do not resolve properly but are used later in some automation steps like the logbook message data or any calculations...

4 replies

desvelado Aug 5, 2024

Thnak you - I found many errors, i hope it will work tommorrow - now i'am learning /understanding more and more " by testing single things of the automation.

in the first automation for regulation mode is still one line in the "moderate" option missing after alias "" and before target:
service: input_select.select_option

A question regarding the power limits of the inverter:
For me i couldn't access the inverter entities because the apsystems ez1-m inverter is working "under" the anker solix, because of a third party firmware-mode it is not possible to access the power and energy of the 2 channels etc.

What do you recommend for the nigth mode?
i would like to change the automation this way that the needed power (up to an given maximum may be) is also adressed by the anker by the schedule.
What ist the easiest way to do this?

thomluther Aug 5, 2024
Maintainer Author

Thanks, fixed the missing line in the automation above.
If you cannot regulate the inverter for discharge, you don't need the last 2 automations. Or easier is probably to keep the day and night mode automations separately since they have different decision criteria anyway and based on the active schedule interval just one or the other will run...
So instead of setting the inverter output at nighttime, you have to set again the solarbank output, but you have the higher limit of 100 W discharge at least and you should use similar delays, base and regulation parameters as for the daytime regulation algorithms.
You also may change the schedule automation to define a min discharge of 100 W for the night interval (instead of 300 W as in my automation) and let the automation increase it as needed.
When you use an inverter limit for night discharge, the SB interval limit should be constant at max range in which the inverter should regulate, so it must be larger than the inverter limit. But without inverter limitation, I think it is safer to have the default at minimum of 100 W to avoid discharge is too much when your SB automation has issues...

desvelado Aug 7, 2024

Thanks again. I'm thinking about first concept for night time and there are some questions about the daytime:
in the automation adjusting home load preset:

why do you only allow this automation/ adjustment of home load preset when "Check battery is not full" and " Check solarbank is installed and not discharging" ?

Should SOC need to be more then minimum and solarbank installed is enough?

This would mean, that if solarbank is discharging already, the homeloadpreset could not be adapted - or am i wrong?

May be in daytime there is the chance to use the collected solarpower much more then nighttime: is there another option to avoid the 30minutes losses of solarpower during statechanges? (may be there is none)

thomluther Aug 7, 2024
Maintainer Author

why do you only allow this automation/ adjustment of home load preset when "Check battery is not full" and " Check solarbank is installed and not discharging" ?

Because it does not make sense to regulate when the battery is full. Since I have no 0W Switch installed and no MI80, I disable even the export switch to prevent risk that discharge is starting in daytime interval when solar goes down. I want to start discharge only at night interval. Typically all PV is bypassed to the house when battery is full, so any regulation does not longer make any sense...
I also check that the entity for regulations is available, since I uninstall my solarbank over winter, when the automation should not run of course. When solarbank is discharing, I want to regulate with my inverter, not with the solarbank, so typically the other automation kicks in when state is discharging...

shortibln · 2024-07-30T20:15:40Z

shortibln
Jul 30, 2024

Hi,thanks for your great work and the detailed instructions! Due to your work I was able to set my automations up within a day. Can't emphasize enough how valuable your input was for me! :)

For my setup I did set keep_last_sample to true for the statistics sensors (see https://www.home-assistant.io/integrations/statistics). This avoids, that the state of those sensors gets unavailable/unknown if max_age is exceeded. Probably this is also useful for you.

Thanks again!
Michael

1 reply

thomluther Jul 30, 2024
Maintainer Author

Yeah, it might help, but might also give completely offset demand when there is an issue with the sensor...
Since my template sensor for house consumption updates every 1-2 seconds or so due to frequent updates of any of the source entities, it really has a problem when max age is exceeded, which is better reflected with unavailable instead of an obsolete and aging value, that may be a complete offset demand.
Actually I have not tested what happens if the core demand sensor for the smart meter goes unavailable. But it might make sense to consider that in the automation. I believe I falls back to the source entity if the statistic sensor has no value, but that could also be unavailable.
So my point is that the automation should be made clever enough to fall back to your minimum AC export in case the regulation has unavailable core entities and correct regulation is no longer possible...

desvelado · 2024-08-16T20:43:00Z

desvelado
Aug 16, 2024

Hi,
So the Main automation including the adapted night adjustment automation seems to work, I need to have a Look and adapt, thanks for your great work. As a newbee I get a little bit cofused with the Lots of entities...

Now I have the problem, that I don't rallye Know how to get the solarcycle resettet.

All sensor and select entities I created about gui. It seems that I need no make an automation for the reset of the solarcycle - or is there a simple solution?

What should an automation trigger looks like and what Action is needed? Could you please help me may be with an example?

I also need to Look tomorrow if the sensor solarcycle deliveres something..

Thanks in regard!

3 replies

thomluther Aug 18, 2024
Maintainer Author

Have a look to the second Part for daily efficency of the battery.
That shows the trigger based template sensor I use and the automation.

desvelado Aug 24, 2024

Thanks again,
I found an issue in the home load preset automation. The condition to enter asks that battery state should not discharge and not unavailable but unavailable should be replaced against unknown. In my enviroment unavailable does allways Block the automation. Do you also think so?

thomluther Aug 25, 2024
Maintainer Author

Hi @desvelado
Maybe....Actually I don't use the solarbank mode entity of the integration directly, but have a template sensor for this, where I factored in the conditions of my inverter integration to estimate the solarbank state in case the Solix integration does not work or it is disconnected from the cloud. So my template entity for the mode is never 'unknown'.
But if your's can become unknown, then simlpy add this state into the NOTcondition which is checking the state

  - alias: Check solarbank is installed and not discharging
    condition: not
    conditions:
      - condition: state
        entity_id: sensor.sb_e1600_mode
        state:
          - unavailable
          - discharge
          - unkonwn

The reason for this conditional check is that the preset should NOT be done, when the integration is not working, or the solarbank is not installed (e.g. like mine is uninstalled over winter)

desvelado · 2024-09-02T12:03:49Z

desvelado
Sep 2, 2024

Hi tholu,
now all should work fine including health watching.
In the meantime, I have expanded my overall system to be able to make better use of the 800W limit. (especially in spring/autumn/winter.
Now I have following subset:

south modules directly on the SB Gen 1
east modules and
west modules each in parallel on the 2nd output of the inverter

Now I have the following questions:

Is a 2nd storage unit worthwhile (I think so)?
Should it be a Gen 1 storage system or a Gen2 with inverter and smart meter?

It would therefore be important to know: How do the 2 storage units work together? Would you have to manually control 2 schedules or do they have a common schedule?

What strategy would make sense for discharging the 2nd storage system?
The 1st storage tank focuses on day charging and the night charging currently lasts until 4 / 5 o'clock.
The 2nd storage tank could not be fully or only partially discharged at night, especially in summer, and would have to be discharged during the day, especially in the morning/evening.
How could this be easily implemented? You had already thought about several storage tanks, but unfortunately I can no longer find the passage.

What seems to make sense from your experience? 500€ for the old one or 1000€ for the newer one, where the inverter would have to be sold.

3 replies

thomluther Sep 2, 2024
Maintainer Author

@desvelado I cannot answer your questions, that's something you have to answer to yourself based on your data, PV production and consumption.
I cannot tell you either how both would work together. Gen 2 does not officially support Gen 1 and I have no experience of such a combination either.
You have to turn to established PV forums to get answer to such questions.

The schedule is typically managed by the system that you create in the App. I don't know, how the SB1 will be added to an SB2 system and whether then both will share the same schedule, or each will have a separate one, or if users have to create 2 separate system for both generations since the SB1 schedules have different format with more parameters and no weekday support. So all this is completely open and it will also take time to implement such changes into the integration. It is also questionable if they can be easily incorporated and it depends on the community to provide sample data and perform testing of this combination since Anker does not provide and Api information....

desvelado Sep 10, 2024

Hello @thomluther,
yeah you couldn't know at all. Fortunattely I found some Discussions. For me it means im waiting until winter/spring an have Look for new products or prices of batteries.

Another question:
Im not Sure If I understood the target behavior of the anker right:

Is it possible to Force full daytime charging instead of charge_bypass?
Or is the minimal bypass-power still 100W?

I adjusted the charge priority to 99 to Formel this behavior.
Which is the desired value for charge priority?

thomluther Sep 12, 2024
Maintainer Author

It depends on your needs. My automations are not made for any charge priority behavior.
You always have min bypass if no charge priority is used, which is what I want.
Having 0W bypass is less efficient, therefore I do not consider it.

Surplus charge automation for Solarbank E1600 (1st generation) #81

thomluther Jul 6, 2024 Maintainer

Surplus charge automation for E1600

Introduction

Appliance overview

Requirements

Regulation capabilities

Automation overview

Full cycle example of a sunny day

Daytime example with changing conditions

Implementation of automations

Preparation

Dashboard to monitor automation effectiveness

Forecast Solar integration

Integration for your grid meter

Integration for your inverter (optional)

House consumption entity

House consumption template sensor

House consumption median sensor

Solarbank battery energy change in last hour

Integral sensor for solarbank energy

Statistic sensor for Solarbank energy change in last hour

Helper to define daily solar start and solar end

Datetime helper for daily solar start and solar end

Regulation mode helper

Helpers to delay first and subsequent solarbank preset increases

Timer helper to enforce wait time for subsequent increase

Switch helper to generally block or allow preset increases

Binary sensor to indicate a workday

Selection helper to indicate home presence

Daily solar cycle tracking for battery energy

Create separate template entities for battery charge and discharge energy

Create utility meter with tariff for 'daily' charge and discharge energy

Template sensor to indicate solar cycle restart

Entities used in the template sensor

Template sensor code

Entity overview

Automation to set helper for the regulation mode

Explanation

Entities to be replaced

Expand to see Automation Code

Automation to adjust daily solarbank schedule

Explanation

Entities to be replaced

Expand to see Automation Code

Automation to adjust home load export switch of solarbank system

Explanation

Entities to be replaced

Expand to see Automation Code

Automation to adjust solarbank preset

Explanation

Entities to be replaced

Expand to see Automation Code

Automation to adjust inverter limit

Explanation

Entities to be replaced

Expand to see Automation Code

Expand to see Script Code

Automation to reset inverter and its limit

Explanation

Entities to be replaced

Expand to see Automation Code

Replies: 6 comments · 12 replies

thomluther Jul 25, 2024 Maintainer Author

thomluther Jul 25, 2024 Maintainer Author

thomluther Aug 5, 2024 Maintainer Author

thomluther Aug 7, 2024 Maintainer Author

thomluther Jul 30, 2024 Maintainer Author

thomluther Aug 18, 2024 Maintainer Author

thomluther Aug 25, 2024 Maintainer Author

thomluther Sep 2, 2024 Maintainer Author

thomluther Sep 12, 2024 Maintainer Author

thomluther
Jul 6, 2024
Maintainer

Replies: 6 comments 12 replies

thomluther Jul 25, 2024
Maintainer Author

thomluther
Jul 25, 2024
Maintainer Author

thomluther Aug 5, 2024
Maintainer Author

thomluther Aug 7, 2024
Maintainer Author

thomluther Jul 30, 2024
Maintainer Author

thomluther Aug 18, 2024
Maintainer Author

thomluther Aug 25, 2024
Maintainer Author

thomluther Sep 2, 2024
Maintainer Author

thomluther Sep 12, 2024
Maintainer Author