🚨 This custom component is an independent project and is not affiliated with Anker. It has been developed to provide Home Assistant users with tools to integrate the Solarbank E1600 into their smart home. Initially the Api library as well as the integration has been developed for monitoring of the Anker Solarbank only. Meanwhile also Anker inverters can be monitored and additional enhancements also allow modifications to their device settings. Any trademarks or product names mentioned are the property of their respective owners. 🚨
This integration utilizes an unofficial Python library to communicate with the Anker Power cloud server Api that is also used by the official Anker mobile app. The Api access or communication may change or break any time without notice and therefore also change or break the integration functionality. Furthermore, the usage for the unofficial Api library may impose risks, such as device damage by improper settings or loss of manufacturer's warranty, whether is caused by improper usage, library failures, Api changes or other reasons.
🚨 The user bears the sole risk for a possible loss of the manufacturer's warranty or any damage that may have been caused by use of this integration or the underlying Api python library. Users must accept these conditions prior integration usage. A consent automatically includes future integration or Api library updates, which can extend the integration functionality for additional device settings or monitoring capabilities. 🚨
This Home Assistant custom component integration allows seamless integration with Anker Solix devices via the Anker Api cloud. It follows the Anker Api cloud structures, which allows registered users to define one or more Power Systems, called site in the Api, with a unique site_id. The configured user must have defined at least one owning system, or have access to a shared system, to see devices for a configured integration account. For each accessible system by the configured account, the integration will create one System Device with the appropriate system sensors. These sensors typically reflect the values that are presented in the Anker mobile app main view of a system. Following example shows how configured integration accounts may look like:
For each end device the system owner has configured into a system, the integration will create an End Device entry, which is controlled by the System Device. So far, available accessory devices such as the 0 W Output switch are not manageable on its own. Therefore they are currently presented as entity of the End Device entry that is managing the accessory.
Following are anonymized examples how the Anker power devices will be presented (Screenshots are from initial release without changeable entities):
1. System Device with Solarbank E1600 and MI80 inverter
2. Solarbank E1600 Device
3. MI80 Inverter Device
Following are screenshots from basic dashboard cards including the latest sensors and all changeable entities that are available when using the system main account:
4. Dark Theme examples of Solarbank 2 E1600 Pro with Smart Meter
5. Light Theme examples of Solarbank E1600
6. Additional device preset entities only available in supported dual Solarbank E1600 systems
7. Solarbank 2 E1600 Pro device
8. Smart Meter device
Note: When using a shared system account for the integration, device detail information is limited and changes are not permitted. Therefore shared system account users may get presented only a subset and no changeable entities by the integration.
The integration will setup the entities with unique IDs based on device serials or a combination of serial numbers. This makes them truly unique and provides the advantage that the same entities can be re-used after switching the integration configuration to another shared account. While the entity history is not lost, it implies that you cannot configure different accounts at the same time when they share a system. Otherwise, it would cause HA setup errors because of non unique entities. Therefore, new integration configurations are validated and not allowed when they share systems or devices with an active configuration. If you want to switch from your main account to the shared account, delete first the active configuration and then create a new configuration with the other account. When the devices and entities for the configured account will be created, deleted entities will be re-activated if their data is accessible via Api for the configured account. That means if you switch from your main account to the shared account, only a subset of entities will be re-activated. The other deleted entities and their history data may remain available until your configured recorder interval is over. The default HA recorder history interval is 10 days.
Usage of the same Anker account in the integration and the Anker mobile app at the same time is not possible due to security reasons enforced by Anker. For more details refer to the Anker Account information in the README. Therefore, it is recommended to use a second account in the integration that has the power system shared as a member. For instructions to create a second account and share the system, see How to create a second Anker Power account. Following is the integration configuration dialog:
Attention:
System members cannot manage any devices of the shared system or view any of their details. You can only see the system overview in the app. Likewise it is the same behavior when using the Api: You cannot query device details with the shared account because you don't have the required permissions for this data. However, a shared account is sufficient to monitor the overview values through the integration without being restricted for using the main account in the Anker app to manage your device settings if needed.
A work around to overcome this account limitation has been implemented via an Api switch in the System Device. When disabled, the integration stops any Api communication for all systems of the disabled account. During that time, you can use the owning account again for login through the Anker app and modify device settings as needed. Afterwards you can re-activate Api communication in the integration again, which will automatically re-login and continue reporting data. While the Api switch is off, all sensors will be unavailable to avoid reporting of stale data.
To simplify usage of this workaround, please see Automation to send and clear sticky, actionable notifications to your smart phone based on Api switch setting for an example automation, which sends a sticky mobile notification when the Api switch was disabled, using actionable buttons to launch the Anker App directly from the notification. It provides also actionable buttons to re-enable the switch again and clear the sticky notification. This avoids forgetting to re-enable your data collection when you are finished with your tasks in the Anker App.
The data on the cloud which can be retrieved via the Api is typically refreshed only once per minute. Therefore, it is recommended to leave the integration refresh interval set to the default minimum of 60 seconds, or increase it even further when no frequent updates are required. Refresh intervals are configurable from 30-600 seconds, but less than 60 seconds will not provide more actual data and just cause unnecessary Api traffic. Version 1.1.0 of the integration introduced a new system sensor showing the timestamp of the delivered Solarbank data to the cloud, which can help you to understand the age of the data.
Note: The solarbank data timestamp is the only device category timestamp that seems to provide valid data (inverter data timestamp is not updated by the cloud).
During each refresh interval, the power sensor values will be refreshed, along with the actual system configuration and available end devices. There are more end device details available showing their actual settings, like power cut off, auto-upgrade, schedule etc. However, those details require much more Api queries and therefore are refreshed less frequently. The device details refresh interval can be configured as a multiplier of the normal data refresh interval. With the default options of the configured account, the device details refresh will run every 10 minutes, which is typically by far sufficient. If a device details update is required on demand, each end device has a button that can be used for such a one-time refresh. However, the button will re-trigger the device details refresh only when the last refresh was more than 30 seconds ago to avoid unnecessary Api traffic.
The cloud Api also enforces a request limit but actual metrics for this limit are unknown. You may see the configuration entry flagged with an error, that may indicate 429: Too many requests. In that case, all entities may be unknown or show stale data until further Api requests are permitted. To avoid hitting the request limit, a configurable request delay was introduced with version 1.1.1. This may be adjusted to avoid too many requests per second. Furthermore all energy statistic entities which started to get introduced with version 1.1.0 will be excluded from new configuration entries per default. They may increase the required Api requests significantly as shown in the discussion post Api request overview. The energy statistics can be re-enabled by removing them from the exclusion list. The configuration workflow was completely reworked since version 1.2.0. Configuration options can now already be modified right after successful account authorization and before the first data collection is done. Excluded device or details categories can be reviewed and changed as needed. Device types of no interest can be excluded completely. Exclusion of specific system or solarbank categories may help to further reduce the number of required Api requests and customize the presented entities of the integration.
Anker changed the data transfer mechanism to the Api cloud with Solarbank 2 power systems. While Solarbank 1 power systems transferred their power values every 60 seconds to the cloud, Solarbank 2 systems seem to use different intervals for Api cloud updates:
- Default interval is ~5 minutes: After ~60 seconds, the cloud considers the last values obsolete and no longer returns valid values upon refresh requests (only 0 values), until new values are received again from the devices. There was a change implemented in the cloud around 25. July 2024 to provide always the last known data upon refresh requests. This eliminated the missing value problem for shared accounts or 0 values in api client responses.
- Triggered interval is ~3 seconds: When the mobile app is used with the main account, it triggers permanent Api cloud updates, most likely via the MQTT cloud server connection to the devices which is also triggering live data updates of individual devices when watching device real time data. That means while watching the Solarbank 2 power system overview, you receive very frequent data updates from the cloud Api. Of course, this is only applied while the home screen is watched to limit cloud Api requests and data traffic for the remaining times.
In consequence, before the cloud change in July 2024 the HA integration typically received 1 response with valid data and another 4 responses with invalid data when using the default refresh interval of 60 seconds. There is nothing the integration or the underlying Api library can do to trigger more frequent cloud data updates for Solarbank 2 systems at this point in time. Per default, the HA integration will switch all relevant entities to unavailable while invalid data is returned. Optionally, you can change your integration configuration entry options to Skip invalid data responses and skip updates to maintain the previous entity value until valid data is received again. While this means your entities will not show unavailable most of the time, they may present obsolete/stale data without your awareness. It is your choice how entities should reflect obsolete data, but neither of the options makes the data more current or reliable. The SB data time entity in the system device will reflect when the last data was provided by the Solarbank 2, or when the last valid data was read through the Api, since also that timestamp in the response is not always valid even if the data itself is valid. A new service was implemented to allow you a manual and easy to use verification capability of the available system data and power values in the cloud.
Note:
The cloud change in July did not change the cloud data update frequency for Solarbank 2 systems. It only avoids that the cloud considers older device data as obsolete, but always responds with last known data instead. It has the same effect as the new 'Skip invalid data responses' option that was implemented to the integration.
Note: Prior version 1.2.0, when you added categories to the exclusion list, the affected entities were removed from the HA registry during integration reload but they still showed up in the UI as entities no longer provided by the integration. You needed to remove those UI entities manually from the entity details dialog. Starting with version 1.2.0, a change in the exclusion list will completely remove the affected devices and re-register them with remaining entities as necessary. This avoids manual cleanup of excluded entities.
If you have the Anker app installed on 2 different devices, the account creation and system sharing will be a little bit easier. Following is a high-level guideline how to create a second account and share the system on a single device:
- Go to your profile in the Anker app, click on your name at the top and then Log out.
- Then create a new Anker power account via the app. You will need a second e-mail address. (This could also be an alias address that you set up with your e-mail provider)
- Complete the registration process. This may have to be confirmed via a temporary code that is sent to the used e-mail address.
- Once you are logged in with the secondary account, log out again in the app as in step 1.
- Log in again with your main account and go to your profile.
- The first item there is Manage System. Go into Manage System and then click on the arrow to the right of the system you want to share.
- Then you will see Invite Members at the bottom, where you must enter the e-mail of your second account.
- Then log out again as in step 1.
- Log in with the second account and go to your systems via the profile.
- There you should now see the invitation from your main account. You must confirm the invitation to activate shared system access.
- Just now you can access the system as a member. The owner will also get a confirmation that you accepted the invitation.
Automation to send and clear sticky, actionable notifications to your smart phone based on Api switch setting
Following automation can be used to send a sticky actionable notification to your Android mobile when the companion app is installed. It allows you to launch the Anker app or to re-activate the Api again for your system.
Make sure to replace the entities used in the example below with your own entities. The system variable is automatically generated based on the device name of the entity that triggered the state change.
Note: If you want to modify the notification to work with your iPhone, please refer to the HA companion App documentation for IOS capabilities.
Expand to see automation code
alias: Notify - Anker Solix Api Switch
description: >
Send or clear sticky mobile notification depending on Anker Solix Api Switch setting
trigger:
- platform: event
event_type: mobile_app_notification_action
id: ActivateApi
event_data:
action: ACTIVATE
- platform: state
id: ApiDisabled
entity_id:
- switch.system_bkw_api_usage
from: "on"
to: "off"
- platform: state
id: ApiEnabled
entity_id:
- switch.system_bkw_api_usage
to: "on"
condition: []
action:
- variables:
system: >
{{device_attr(trigger.entity_id, "name") if trigger.platform == 'state' else ""}}
- choose:
- conditions:
- condition: trigger
id:
- ApiDisabled
sequence:
- service: notify.my_smartphone
alias: Send notification to smartphone
data:
title: Anker Api deactivated
message: >
{{'The Anker Solix Api for '~system~' was disabled. Launch the
Anker App for Login and modifications, or reactivate the Api
again.'}}
data:
tag: ANKERSOLIXAPI
channel: Alarm
ttl: 0
priority: high
sticky: true
persistent: true
color: "#FFD700"
notification_icon: mdi:sync-alert
actions:
- action: URI
title: App
uri: app://com.anker.charging
- action: ACTIVATE
title: Reactivate
- conditions:
- condition: trigger
id:
- ActivateApi
sequence:
- if:
- condition: state
entity_id: switch.system_bkw_api_usage
state: "off"
then:
- alias: Reactivate the Api
service: switch.turn_on
target:
entity_id: switch.system_bkw_api_usage
data: {}
- if:
- condition: trigger
id:
- ActivateApi
- ApiEnabled
then:
- alias: Delete message on mobile
service: notify.notify
data:
message: clear_notification
data:
tag: ANKERSOLIXAPI
channel: Alarm
ttl: 0
priority: high
mode: queued
max: 3
Version 2.0.0 of the integration only supports switching between Smart Meter (AI) or Manual (custom) home load usage modes when a smart meter is configured in the system. Otherwise only Manual usage mode is supported, but schedule based modifications via direct output entities or schedule change services are not yet supported for Solarbank 2. This will be supported in a future release.
Attention:
Setting the Solarbank 1 output power for the house is not as straight forward as you might think and applying changed settings may give you a different result as expected or as represented by the output preset sensor.
Following is some more background on this to explain the complexity. The home load power cannot be set directly for the Solarbank. It can only be set indirectly by a time schedule, which typically covers a full day from 00:00 to 24:00h. There cannot be different schedules on various days, it's only a single schedule that is shared by all solarbanks configured into the system. Typically for single solarbank systems, the solarbank covers the full home load that is defined for the time interval. For dual solarbank setups, both share 50% of the home load power preset per default. This share was fixed and could not be changed so far. Starting with the Anker App 2.2.1 and new solarbank firmware 1.5.6, the share between both solarbanks can also be modified. Starting with integration version 1.3.0, this capability is also supported with additional entities that will be created for dual solarbank systems supporting individual device presets. It is a new preset mode that was implemented in the schedule structure.
Following are the customizable parameters of a time interval that are supported by the integration and the Python Api library:
- Start and End time of a schedule interval
- Appliance home load preset (100 - 800/1600 W). If changed in dual solarbanks systems, it will always use normal preset mode with the default 50% device share
- Device load preset (50-800 W) for dual solarbank systems supporting individual device presets. A change will always enable advanced preset mode and also affect the appliance load preset accordingly
- Export switch
- Charge Priority Limit (0-100 %), typically only seen in the App when Anker MI80 inverter is configured
Those given ranges depend on the number of solarbanks in the system and are being enforced by the integration and the Api library. However, while those ranges are also accepted by the appliance when provided via a schedule, the appliance may ignore them when they are outside of its internally used/defined boundaries. For example, you can set an Appliance home load of 100 W which is also represented in the schedule interval. The appliance however will still apply the internal minimum limit of 150 W depending on the configured inverter type for your solarbank. It is typically the combination of those settings, as well as the actual situation of the battery SOC, the temperature and the defined/used inverter in combination with either the charge priority setting or activation of the 0 W switch that all determine which home load preset will be applied by the appliance. The applied home load is typically represented in the App for the active time interval, and this is what you can also see in the Solarbank System sensor for the preset output power. But rest assured, even if it shows 0 W home load preset is applied, it does not warrant you there won't be any output power to the house!
To conclude: The appliance home load preset for Solarbank 1 is just the desired output, but the truth can be completely different
Before you now start using the home load preset modification capability in some fancy real time automation for zero grid power export, here is my advise:
- Be careful !!!
I will also tell you why:
- The first generation of Solarbank E1600 is Anker's first all in one battery device for 'balcony solar systems' and was not designed for frequent home load changes. Unlike the new Solarbank 2 systems, Solarbank 1 is only manageable via a 'fixed' time schedule and therefore was never designed to react quickly on frequent home load changes (and neither is the Api designed for it)
- The Solarbank reaction on changed home load settings got better and during tests a typical adoptions of 10-20 seconds for smaller home load changes with firmware 1.5.6 have been observed. However, using only the integration sensors is still far too slow for real/near time power automation, since all data communication occurs only via the cloud and has significant value time lags to be considered.
- In reality (as an average) you need to allow the solarbank up to 1-2 minutes until you get back reliable sensor values from the cloud that represent the result of a previous change. The solarbank also sends the data only once per minute to the cloud, which is another delay to factor into your automation.
- If you have additional and local (real time) sensors from smart meters or inverters, they might help to see the modification results faster. But still, the solarbank needs time until it settled reliably for a changed home load. Furthermore it all depends on the cloud and internet availability for any automation. Alternatively I recommend to automate the solarbank discharge only locally via limiting the inverter when you have real time automation capabilities for your inverter limits. I realized this project as described in the forum with Hoymiles inverter, OpenDTU and a Tasmota reader device for the grid meter and that works extremely well.
- Attention: Don't use the inverter limit during solar production since this will negatively impact your possible solar yield and the solarbank may end up in crazy power regulations all the time.
- Additionally, each schedule parameter or complete schedule change requires 2 Api requests, one to submit the whole changed schedule and another two to query the applied and resulting schedule and site values again for sensor updates. To enforce some protection for the Api and accommodate the slow solarbank reaction, an increase of the home load is just allowed every 30 seconds at least (decreases or other interval parameter changes are not limited)
- Attention: Cloud Api requests are limited, but actually the enforced limits in regards to quantity and time frames are unknown. Each change may bring you towards the enforced limit and not only block further changes, but also render all integration entities unavailable or stale
- If you have some experience with the solarbank behavior, you may also know how weird it sometimes reacts on changed conditions during the day (or even unchanged conditions). This makes it difficult to adjust the home load setting automatically to a meaningful value that will accomplish the desired home load result.
- If you plan to automate moderate changes in the home load, use a timer helper that is restarted upon each change of the settings and used as condition for validation whether another change (increase) should be applied. I would not recommend to apply changes, especially increases in the home load, in less than 2 minute intervals, a trusted re-evaluation of the change results and further reaction can just be done after such a delay. Remember that each provided Solarbank data point is just a single sample within 60 seconds or more. The value average in that interval can be completely different, especially if you compare Solarbank data with real time data of other power devices in your home!
Meaningful automation ideas that might work for the Solarbank 1:
- Use schedule services to apply different set of schedules for different weekdays (workday, home office, weekend etc). The Anker App does not provide this capability, but with HA automation you could create new schedules for given days in advance. Use first the Set schedule service which will create a new all day interval and then Update schedule service to insert additional intervals as needed. Try the service sequence manually to validate if they accomplish the desired end result for your schedule.
- Use solar forecast data to define a proper home load preset value for the day in order to allow the battery charging is spanning over the whole day while using as much direct solar power as possible in the house. This will prevent that the battery is full before noon in summer and then maximum solar power is bypassed to the house but cannot be consumed. This is something that I plan implementing for this summer since I have already built an automation for recommended home load setting...
- Use time to time changes in the home load when you have expected higher consumption level for certain periods, e.g. cooking, vacuum cleaning, fridge cooling, etc. Basically anything that adds a steady power consumption for a longer period. Don't use it to cover short term consumers like toaster, electric kettles, mixer or coffee machines. Also the home load adoption for washing machines or laundry dryer might not be very effective and too slow since they are pretty dynamic in power consumption.
- You have probably more automation ideas for your needs and feel free to share them with the community. But please keep the listed caveats in mind to judge whether an automation project makes sense or not. All efforts may be wasted at the end if the appliance does not behave as you might expect.
If you are interested building your own automation for using the Solarbank 1 as surplus battery buffer without wasting generated solar energy to the grid unnecessarily, you may have a look to my automation project that I documented in the discussions.
For Solarbank 2 systems with a smart meter, you can automate the switch of the home load usage mode between Smart Meter and Manual if you may have the need to change this in your setup. The Anker mobile app actually does not support scheduled switches of the home load usage mode.
At this point be warned again:
The user bears the sole risk for a possible loss of the manufacturer's warranty or any damage that may have been caused by use of this integration or the underlying Api python library.
Following 3 methods are implemented:
1. Direct parameter changes via entity modifications for Appliance and/or Device Home Load preset, allowance of export, charge priority limit or usage mode
Any change in those entities is immediately applied to either the current time slot in the existing schedule, or to the general schedule structure. Please see the Solarbank dashboard screenshots above for examples of the entity representation. While the schedule is shared for the appliance, each Solarbank 1 in a dual Solarbank setup will be presented with those entities. A change in the device load preset will however enable advanced preset mode and only change the corresponding solarbank output. However, it will also result in a change of the appliance home load preset accordingly.
Solarbank 2 schedule intervals have less time interval settings and can only define the appliance output power. However, different Solarbank 2 schedules can be defined for various weekdays. One common setting for all schedules is the usage mode. If a smart meter is configured in your power system, you can set the usage mode to Smart Meter and the Solarbank 2 will automatically adjust the appliance output to your house demand measured by the smart meter. So while you can still define schedules via the Anker mobile app, they will be applied ONLY if the solarbank lost connection to the device that is used to provide automated power demand such as the smart meter. For any gap in the defined schedule, the default output of 200 W will be applied.
Attention: Home load changes or schedule changes are NOT yet supported for Solarbank 2
A word of caution:
When you represent the home load number entities as input field in your dashboard cards, do NOT use the step up/down arrows but enter the home load value directly in the field. Each step via the field arrows triggers a settings change immediately, and increases are restricted for min. 30 second intervals. Preferably use a slider for manual number modifications, since the value is just applied to the entity once you release the slider movement (do not release the slider until you moved it to the desired value).
They are useful to apply manual or automated changes for times that are beyond the current time interval. Following services are available:
-
Set new Solarbank schedule:
Allows wiping out the defined schedule and defines a new interval with the customizable schedule parameters above
Attention: This service is NOT yet supported for Solarbank 2
-
Update Solarbank schedule:
Allows inserting/updating/overwriting a time interval in the existing schedule with the customizable schedule parameters above. Adjacent intervals will be adjusted automatically
Attention: This service is NOT yet supported for Solarbank 2
-
Request Solarbank schedule:
Queries the actual schedule and returns the whole schedule JSON object, which is also provided in the schedule attribute of the Solarbank device output preset sensor.
-
Clear Solarbank schedule:
Clear all defined solarbank schedule intervals. The solarbank will have no longer a schedule definition and use the default output preset all day (200 W).
You can specify the solarbank device id or the entity ID of the solarbank output preset sensor as target for those services. The service UI in HA developer tools will filter the devices and entities that support the solarbank schedule services. I recommend using the entity ID as target when using the service in automation since the device ID is an internal registry value which is difficult to map to a context. In general, most of the solarbank schedule changes should be done by the update service since the Api library has built in simplifications for time interval changes. The update service follows the insert methodology for the specified interval using following rules:
- Adjacent slots are automatically adjusted with their start/end times
- Completely overlay slots are automatically removed
- Smaller interval inserts result in 1-3 intervals for the previous time range, depending on the update interval and existing interval time boundaries
- For example if the update interval will be within an existing larger interval, it will split the existing interval at one or both ends. So the insert of one interval may result in 2 or 3 different intervals for the previous time range.
- Gaps will not be introduced by schedule updates
- If only the boundary between intervals needs to be changed, update only the interval that will increase because updating the interval that shrinks will split the existing interval
- When one of the update interval boundaries remains the same as the existing interval, the existing interval values will be re-used for the updated interval in case they were not specified.
- This allows quick interval updates for one boundary or specific parameters only without the need to specify all parameters again
- All 3 parameters are mandatory per interval for a schedule update via the Api. If they are not specified with the service, existing ones will be re-used when it makes sense or following defaults will be applied:
- 100 W Home load preset in normal preset mode if neither appliance nor device load presets are provided
- Allow Export is ON
- 80 % Charge Priority limit
- The Set schedule service also requires to specify the time interval for the first slot. However, testing has shown that the provided times are ignored and a full day interval is always created when only a single interval is provided with a schedule update via the Api.
For dual Solarbank 1 systems, following load preset rules will be applied:
- If only appliance load preset provided, the normal preset mode will be used which applies a 50% share to both solarbanks
- If only device load preset provided, the advanced power mode will be used if supported by existing schedule structure. The appliance load preset will be adjusted accordingly, but the other solarbank device preset will not be changed. It will fall back to normal appliance load usage if advanced power mode not supported by existing schedule structure.
- If appliance and device load preset are provided, the advanced power mode will be used if supported by existing schedule structure. The appliance load preset will be used accordingly within the capable limits, resulting from the provided device preset and the preset difference that will be applied to the other solarbank device. It will fall back to normal appliance load usage if advanced power mode not supported by existing schedule structure.
- If neither appliance nor device presets are provided, the existing power presets and mode will remain unchanged and reused if at least start or end time remain unchanged. Otherwise the default preset will be applied for the interval
- If only device preset is provided for single solarbank systems, it will be applied as appliance load preset instead, which in fact is the same result for such systems
Note:
Usage of advanced preset mode is determined by existing schedule structure. When no schedule is defined and the set schedule service is used with a device preset requiring the advanced power preset mode, but the solarbanks are not on required firmware level to accept the new schedule structure, the service call may fail with an Api request error.
3. Interactive solarbank schedule modification via a parameterized script that executes a schedule service with provided parameters
Home Assistant 2024.3 provides a new capability to define fields for script parameters that can be filled via the more info dialog of the script entity prior execution. This allows easy integration of schedule modifications to your dashboard (see Script to manually modify appliance schedule for your solarbank).
Following are screenshots showing the schedule service UI panel (identical for Set schedule and Update schedule service), and the Get schedule service with an example:
1. Set or Update schedule service UI panel example, using the entity as target
2. Get schedule service example, using the device as target
While not the full entity ranges supported by the integration can be applied to the device, some may provide enhanced capabilities compared to the Anker App. Following are important notes and limitations for schedule modifications via the cloud Api:
Attention: Schedule modification is NOT yet supported for Solarbank 2
- Time slots can be defined in minute granularity and what I have seen, they are also applied (don't take my word for given)
- The end time of 24:00 must be provided as 23:59 since the datetime range does not know hour 24. Any seconds that are specified are ignored
- Home Assistant and the Solarbank should have similar time, but especially same timezone to adopt the time slots correctly. Even more important it is for finding the current/active schedule time interval where individual parameter changes must be applied
- Depending on the front end (and timezone used with the front end), the time fields may eventually be converted. All backend datetime calculations by the integration use the local time zone of the HA host. The HA host must be in the same time zone the Solarbank is using, which is typically the case when they are on the same local network.
- Situations have been observed during testing where an active home load export was applied in the schedule, but the solarbank did not react on the applied schedule. While the cloud schedule was showing the export enabled with a certain load set, verification in the Anker App presented a different picture: There the schedule load was set to 0 W in the slider which is typically not possible in the App...The only way to get out of such weird schedules on the appliance is to make the interval change via the Anker App since it may use other interfaces than just the cloud Api (Bluetooth and another Cloud MQTT server). This problem was only noticed when just a single resulting interval remains in the schedule that is sent via the Api, for example setting a new schedule or making an update with a full day interval. To avoid this problem, make sure your schedule has more than one time interval and you do NOT use the Set new Solarbank schedule service. Instead you can apply schedule changes via the Update Solarbank schedule service which is NOT covering the full day.
Following markdown card code can be used to display the solarbank 1 schedule in the UI frontend. Just replace the entity with your sensor entity representing solarbank effective output preset. It is the sensor that has the schedule attribute.
Expand to see card code
type: markdown
content: |
## Solarbank Schedule
{% set entity = 'sensor.solarbank_e1600_home_preset' %}
{% set slots = (state_attr(entity,'schedule')).ranges|default([])|list %}
{% set isnow = now().time().replace(second=0,microsecond=0) %}
{% if slots %}
{{ "%s | %s | %s | %s | %s | %s | %s | %s | %s"|format('Start', 'End', 'Preset', 'Export', 'Prio', 'Mode', 'SB1', 'SB2', 'Name') }}
{{ ":---:|:---:|---:|:---:|:---:|:---:|---:|---:|:---" }}
{% else %}
{{ "No schedule available"}}
{%- endif -%}
{%- for slot in slots -%}
{%- set bs = '_**' if strptime(slot.start_time,"%H:%M").time() <= isnow < strptime(slot.end_time.replace('24:00','23:59'),"%H:%M").time() else '' -%}
{%- set be = '**_' if bs else '' -%}
{%- set sb2 = '-/-' if slot.device_power_loads|default([])|length < 2 else slot.device_power_loads[1].power~" W" -%}
{{ "%s | %s | %s | %s | %s | %s | %s | %s | %s"|format(bs~slot.start_time~be, bs~slot.end_time~be, bs~slot.appliance_loads[0].power~" W"~be, bs~'On'~be if slot.turn_on else bs~'Off'~be, bs~slot.charge_priority~' %'~be, bs~(slot.power_setting_mode or '-')~be, bs~slot.device_power_loads[0].power~" W"~be, bs~sb2~be, bs~slot.appliance_loads[0].name)~be }}
{% endfor -%}
Notes:
- Shared accounts have no access to the schedule
- The schedule values show the individual customizable settings per interval. The reported home load preset that is 'applied' and shown in the system preset sensor state as well as in the Anker App is a combined result from the appliance for the current interval settings.
- The applied appliance home load preset can show 0 W even if appliance home load preset is different, but Allow Export switch is off. It also depends on the state of charge and the charge priority limit and the defined/installed inverter. Even if the preset sensor state shows 0 W, it does not mean that there won't be output to the house. It simply reflects the same value as presented in the App for the current interval.
- Starting with Anker App 2.2.1, you can modify the default 50 % preset share between a dual Solarbank setup. The SB1 and SB2 values of the schedule will show the applied preset per Solarbank in that case, which is also reflected in the individual device preset sensor. For single Solarbank setups, the individual device presets of the schedule are ignored by the appliance and the appliance preset is used.
- Even if each Solarbank device has its own Home Preset sensor (reflecting their contribution to the applied home load preset for the device) and schedule attribute, all Solarbanks in a system share the same schedule. Therefore a parameter change of one solarbank also affects the second solarbank. The applied home load settings are ALWAYS for the schedule, which is still shared by all solarbanks in the system.
- The schedule structure for the normal preset mode is always reflecting 50% of the appliance load preset to the device load preset. This is also the case for single solarbank systems. A simple schedule structure rule is that with no or normal preset mode, the appliance load preset will be applied. For advanced preset mode which is only accepted in dual solarbank systems, the individual device load presets will be applied and the appliance load setting will be ignored.
Following markdown card code can be used to display the solarbank 2 schedule in the UI frontend. Just replace the entities at the top with your sensor entities representing the solarbank output preset and usage mode.
Expand to see card code
type: markdown
content: |
{% set entity = 'sensor.solarbank_2_e1600_pro_home_preset' %}
{% set mode = states('select.solarbank_2_e1600_pro_usage_mode') %}
{% set plan = ((state_attr(entity,'schedule')).custom_rate_plan|default([]))|list %}
{% set isnow = now().replace(second=0,microsecond=0) %}
### Solarbank 2 Schedule (Usage Mode: {{mode|capitalize}})
{% if plan %}
{%- set week = ["Sun","Mon","Tue","Wed","Thu","Fri","Sat"] -%}
{{ "%s | %s | %s | %s | %s"|format('ID', 'Start', 'End', 'Output', 'Weekdays') }}
{{ ":---:|:---:|:---:|---:|:---" }}
{% else %}
{{ "No schedule available"}}
{%- endif -%}
{%- for idx in plan -%}
{%- set index = idx.index|default('--') -%}
{%- for slot in idx.ranges|default([]) -%}
{%- set ns = namespace(days=[]) -%}
{%- for day in idx.week|default([]) -%}
{%- set ns.days = ns.days + [week[day]] -%}
{%- endfor %}
{%- set bs = '_**' if strptime(slot.start_time,"%H:%M").time() <= isnow.time() < strptime(slot.end_time.replace('24:00','23:59'),"%H:%M").time() and int(isnow.strftime("%w")) in idx.week|default([]) else '' -%}
{%- set be = '**_' if bs else '' -%}
{{ "%s | %s | %s | %s | %s"|format(bs~index~be, bs~slot.start_time~be, bs~slot.end_time~be, bs~slot.power~" W"~be, bs~','.join(ns.days)~be) }}
{% endfor -%}
{% endfor -%}
Notes:
- Shared accounts have no access to the schedule
- Solarbank 2 has less settings per time slot than Solarbank 1, making it easier to adjust
- Solarbank 2 schedules can be created for individual weekdays. Each group of weekdays has its own plan ID. A weekday can only be configured into one plan ID
- The defined schedule is only used when the usage mode is set to Manual (custom usage)
Attention: This is NOT yet supported for Solarbank 2
With Home Assistant 2024.3 you have the option to manually enter parameters for a script prior execution. This is a nice capability that let's you add an UI capability for a service right into your dashboard. You just need to create a script with input fields that will run the selected solarbank service using the entered parameters. Following is a screenshot of the more info dialog for the script entity:
Below is an example script which you can use, you just need to replace the entity name in the service data entity_id field with your device sensor that represents the output preset and has the schedule attribute. If you have multiple systems, you can make the entity also a selectable field in the script similar to the service. For dual solarbank systems, you just need one of the 2 solarbank preset entities to apply the change, since the schedule is shared.
Expand to see script code
alias: Change Solarbank Schedule
fields:
service:
name: Service
description: Choose which service to use
required: true
default: anker_solix.update_solarbank_schedule
selector:
select:
mode: dropdown
options:
- label: Update schedule
value: anker_solix.update_solarbank_schedule
- label: Set schedule
value: anker_solix.set_solarbank_schedule
start_time:
name: Start time
description: Start time of the interval (seconds are ignored)
required: true
default: "00:00:00"
selector:
time: null
end_time:
name: End time
description: >-
End time of the interval (seconds are ignored). For 24:00 you must enter 23:59
required: true
default: "23:59:00"
selector:
time: null
appliance_load:
name: Appliance load preset
description: Watt to be delivered to the house
required: false
default: 100
selector:
number:
min: 100
max: 1600
step: 10
unit_of_measurement: W
device_load:
name: Device load preset
description: Watt to be delivered by the solarbank device
required: false
default: 50
selector:
number:
min: 50
max: 800
step: 5
unit_of_measurement: W
allow_export:
name: Allow export
description: >-
If deactivated, the battery is not discharged or, if an MI80 inverter or 0 W switch is installed, the charging priority is used without exporting to the house
required: false
selector:
boolean: null
default: false
charge_priority_limit:
name: Limit for charge priority
description: >-
The charging priority is used up to the set charge level when the MI80 inverter is set. Setting is ignored if no 0 W switch is installed or no MI80 inverter is set.
required: false
default: 80
selector:
number:
min: 0
max: 100
step: 5
unit_of_measurement: "%"
sequence:
- service: |
{{service}}
target:
entity_id: sensor.solarbank_e1600_home_preset
data:
start_time: |
{{start_time}}
end_time: |
{{end_time}}
appliance_load: |
{{appliance_load|default(None)}}
device_load: |
{{device_load|default(None)}}
allow_export: |
{{allow_export|default(None)}}
charge_priority_limit: |
{{charge_priority_limit|default(None)}}
mode: single
icon: mdi:sun-clock
In order to run the script interactively from the dashboard, you just need to add an actionable card and select the script as entity with the action to show the more-info dialog of the script. If you place the schedule markdown card on the left or right column of the dashboard, you can review the active schedule while entering the parameters for the changes you want to apply. That gives you similar schedule management capabilities as in the Anker App...Nice.
Notes:
- You may have to reload your browser window when the changed or inserted schedule intervals are not directly represented in the markdown card
- See further notes above for adjusting the appliance home load parameters or schedule when things are behaving differently than expected
Starting with version 2.0.0, a new service was added for the system total yield entity in order to query the overall system information from the cloud Api, which contains the data that is presented on the Anker App home page screen. This data is used by the integration to represent most but not all of the entities. It may be helpful to debug what values are actually available on the Api cloud at the time requesting them. Following is an example screenshot showing only the top of the response:
If you like this project, please give it a star on GitHub