This Home Assistant custom integration utilizes the anker-solix Python library, allowing seamless integration with Anker Solix devices via the Anker power cloud. It was specifically developed to monitor the Anker Solarbank E1600. Support for further Anker devices like solar micro-inverters (MI80), Solarbank 2 E1600, Solarbank 3 E2700 and Anker smart meters has been added to the Api library and is available through the integration. The Anker power cloud also supports portable power stations (PPS), home Power Panels or home energy systems (HES) which are not or only partially supported by the api library. They may be added in the future once Api data structures for those devices are known and regular consumption data will be sent to the Anker Power cloud.

Please refer to supported sensors and devices for a list of supported Anker Solix devices.

🚨 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 devices of Anker Solix power systems into their smart home. 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, which is used by the official Anker mobile app. The cloud server 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. 🚨

1. Disclaimer
2. Usage terms and conditions
3. Anker Account Information
4. Limitations
5. Supported sensors and devices
6. Special device notes
   • Standalone inverters (MI80)
   • Solarbank 1 devices
   • Solarbank 2 devices and Smart Meters
   • Solarbank 2 AC devices
   • Combined Solarbank 2 systems containing cascaded Solarbank 1 devices
   • Solarbank 3 devices
   • Solarbank Multisystem with Power Dock
   • Electric Vehicle devices
   • Power Panels
   • Home Energy Systems (HES)
   • Other devices
7. MQTT data from devices
8. Installation via HACS (recommended)
   • Installation Notes
9. Manual installation
10. Optional entity pictures
11. Integration configuration and usage
12. Issues, Q&A and other discussions
13. Contributions are welcome!
14. Attribution
15. Showing Your Appreciation
16. Additional Resources
    • Blog-Posts
    • Videos

Because of the way the Anker Solix Cloud Api was working, one account with email/password could not be used for the Anker mobile app and this Api in parallel. The Anker Solix Cloud allowed only one login token per account at any time. Each new login request by a client will create a new token and the previous token on the server was dropped. For that reason, it was not possible to use this Api client and your mobile app with the same account in parallel. Starting with Anker mobile app release 2.0, you could share your owned system(s) with 'family members'. Since then it was possible to create a second Anker account with a different email address and share your owned system(s) with one or more secondary accounts as member.

For detailed usage instructions, please refer to the INFO

• The used Api library is by no means an official Api and is very limited as there is no documentation at all
• The Api library or the login can break at any time, or Api requests can be removed/added/changed and break some of the endpoint methods used in the underlying Api library
• The Api library was validated against both Anker cloud servers (EU and COM). Assignment of countries to either of the two servers however is unknown and depending on the selected country for your account. Upon wrong server assignment for your registered country, the Api may login but show no valid systems, devices or sensors in the integration
• The integration sensors and entities being provided depend on whether an Anker owner account or member account is used with the integration
• It was observed that solarbank or inverter devices may loose Wifi connection from time to time and will not be able to send data to the cloud. While device Wifi is disconnected, the reported data in the cloud may be stale. You can use the cloud state sensor of the end device to verify the device cloud connection state and recognize potentially stale data.
• The integration can support only Solix power devices which are defined in a power system via the Anker mobile app. While it may present also standalone devices that are not defined in a system, those standalone devices do not provide any usage or consumption data via the cloud Api and therefore will not present any power entities.
• Further devices which can be added to a power system and managed by the Anker Power cloud may be added in future once examples of Api response data can be provided to the developer.

This integration will set up the following HA platforms and provides support for following Anker Solix devices:

For more details on the Anker Solix device hierarchy and how the integration will represent them in Home Assistant, please refer to the discussion article Integration device hierarchy and device attribute information.

Anker does not support the creation of a power system with their MI80 inverter as main and only device. However, the solar power and energy yields are still reported and tracked in the cloud and can be monitored in the mobile app. Version 2.7.0 added support for such standalone inverters. Even the persistent inverter limit can be changed via the cloud api. In order to merge entities for standalone inverters with the common integration device hierarchy, a virtual system (site) will be created by the api library as home for the data polling and all entities that are typically related to a system device. The cloud update interval is approximately every 60 seconds if the inverter is online. The api however does a false reporting of the inverter Wifi state, which is always reported offline independent of its real Wifi state. The cloud connection state is a better indicator whether the inverter is On or Off. Since standalone inverters cannot be added to a real Anker power system, their monitoring cannot be shared with other accounts and their usage is limited to the Anker account that owns the device.

Solarbank 1 systems transfer their power values every 60 seconds to the cloud while there is PV generation or battery discharge. Once the Solarbank 1 goes into standby mode, there is only a cloud state check/update once per hour to save standby energy consumption.

Anker changed the data transfer mechanism to the Api cloud with Solarbank 2 power systems. While Solarbank 1 systems transfer their power values every 60 seconds to the cloud, Solarbank 2 systems seem to use different intervals for their data updates to the cloud which is either 5 minutes or few seconds. Originally this resulted in invalid data responses and unavailable entities for shared accounts or api connections. This problem was resolved by Anker, but the regular cloud update interval remains at 5 minutes. Please see the configuration option considerations for Solarbank 2 systems in the INFO for more details and how you can avoid unavailable entities if this problem should occur again.

The Solarbank 2 AC model comes with new and unique features and initial support has been implemented with version 2.5.0. Version 2.6.0 added support for missing capabilities like modifications of the Time of Use plan via control entities or actions.

This coupling feature for 1st generation Solarbank devices was announced in May 2024 and delivered in Dec 2024. It turns out that Anker implemented just the bare minimum to support such combined systems. As users noticed, the power totals and energy statistics for such systems reflect ONLY the SB2 data, but not any SB1 data. That means you don't see anymore the SB1 solar power / energy during the day, but the SB1 discharge at night counts as solar power/energy of the SB2 during the night. All reported charge or discharge data does not reflect anything of the SB1 devices in the system. So the SB1 is pretty much a black box for the Anker home page and the energy statistics, which can also be accessed by system members. Furthermore, the SB1 device(s) may have different schedules in combined systems. While the SB2 is running in an automatic mode, the SB1 has its own schedule with all known controls for any number of time intervals. When the SB2 is switched to manual mode however, it enforces another, minimalistic all day interval schedule to the SB1 devices which is not accessible via the mobile App. This schedule has no interval control elements. The output preset is the only value for the whole day interval and it is determined by the SB2, depending on its manual plan settings and SOC. When adding a SB1 device into a SB2 system, the 'Solarbank 2' will get configured as inverter type for the cascaded SB1 device. Therefore the output preset in this minimalistic schedule can also be 0 W for the SB1, however the 0 W output will only be applied if the 0 W output switch accessory is installed between SB1 output and SB2 input. Otherwise the SB1 will still bypass a minimum of 100 W typically. To prevent any SB1 schedule modifications while the enforced schedule is active, the integration will make all affected control entities unavailable to prevent user changes. Therefore you may see unavailable controls in cascaded SB1 devices that cannot be modified any longer, otherwise this may screw up the presented values and schedule settings, which would always be applied to the real SB1 schedule, even if inactive. To present correct total values for the combined system, the Api library corrects also the solarbank totals in the Api system info response based on proper accumulation of individual solarbank device values:

• Total solar power: SB1 device(s) solar power + SB2 device solar power - SB1 device(s) output power
• Total output power: Remains SB2 device output power
• Total SOC: Weighted average SOC across all devices, considering also number of SB2 battery packs
• Total battery power:
  • The device battery power has always been calculated by the library, since the Api never reflected reliable charge or discharge power fields
  • It is calculated as Solar power - Output power, resulting in the overall battery power for the device (positive charge power and negative discharge)
  • Since a single device cannot charge and discharge at the same point in time, the device battery power typically reflects the complete charge OR discharge power
  • The total battery power simply accumulates each device's battery power, and thus reflecting the total NET battery power
  • However, this total NET battery power of multiple devices cannot reflect the total charge or discharge power at any given time, since a SB1 discharge of 100 W and a charge of those 100 W by the SB2 will result in 0 W NET battery power. So neither the 100 W charge power nor the 100 W discharge power are reflected in the total (NET) battery power value.

To achieve a correct charge and discharge energy calculation for your energy dashboard, you need to separate the charge and discharge power individually from each device battery power value. Then you can accumulate correct energies in following 2 ways:

• Accumulate charge and discharge energy individually for each device and add them all to the energy dashboard. This allows granular energy tracking per Solarbank, since the dashboard will automatically accumulate energies of same type, but display each in a different color. This is the recommended option.
• Create total charge and discharge power helper entities, that summarize the device power values separately. Then you can accumulate the total charge and discharge energies from those new summary helper entities.

Solarbank 3 devices behave similar to Solarbank 2 AC devices, but they will provide additional entities and usage mode options that are unique to this generation:

• Anker Intelligence (AI) usage with 'Smart' mode
• Dynamic Price support (Provider options depend on country and model)
• New 'Time Slot' usage mode (based on dynamic prices) to automate AC charging and discharging
• 24h solar forecast data while 'Smart' mode is active, which can be seen in the App intraday solar chart

However, it was noticed that the Solarbank charging status code is not longer being used by models that contain a hybrid inverter (since Solarbank 2 AC). The code remains always '0' which is translated into a Detection status as used by earlier solarbank models. Since that is no longer meaningful for Solarbank 2+ models, starting with version 3.2.0 an appropriate charging status description is assumed for code '0' of Solarbank 2+ devices, which is based on the actual power and SOC value constellation. A new description for AC charging was also implemented to better distinguish the various charging modes for hybrid inverter models.

Dynamic utility rate plan support was introduced with integration version 3.0.0. Version 3.1.0 added support for solar forecast data.

Anker announced the Solarbank Multisystem solution for early testing in Germany (DE) with common delivery planned in September 2025. A Solarbank Multisystem with the Power Dock will support up to 4 Solarbank devices. Initially this is only supported for Solarbank 3, but the various Solarbank 2 models are announced to follow end of 2025.

The Api library implemented enhancements to mask some value errors, but this can be done only on a limited base. It also does not help for proper total value breakdown to individual devices, if the breakdown is missing in the cloud data. Therefore some of the Solarbank device power values may reflect the appliance totals instead of individual breakdown. Many settings for Multisystems are shared across all Solarbanks in the system, like usage mode, SOC reserve and export to grid setting. In the mobile App they are managed through the station settings, and the individual device settings are greyed out. Custom plans for output presets is shared for all devices, and the individual device output is managed automatically across all solarbanks, depending on their SOC, capacity etc. That means they cannot be modified individually anymore. The integration will still show the individual device settings if applicable, but changing them will change the settings for all devices in the system. The new combiner box device type will be used for the passive power dock, which is not reported as normal device by the cloud since it is passive and has no cloud connection. The integration will use it to reflect combined sensors and control entities for such Multisystems, although those values and settings are not managed by the combiner box itself.

Anker announced its Solix V1 EV Charger (DE) which can be used as stand alone system or being integrated into the X1 HES system as well as into the Solarbank Multisystem (by 4Q 2025). The EV Charger device can be shared amongst Anker cloud users, while each user can define/create its own virtual electric vehicle, or even multiple of them (up to 5 vehicles per account). The vehicles are used to manage EV charging by individual users, even if they are not the owner of the system to which the EV Charger device belongs to. Each user will need to create its own vehicle(s) to create and manage charge orders for the V1. The integration currently does NOT yet support the vehicle creation itself, but it creates a virtual device for each existing EV under the user account and it can modify various vehicle attributes and show all entities that belong to the vehicle. The user vehicle can also be deleted by removing the vehicle device from the integration hub.

Power Panels are not supported in the EU market, therefore the EU cloud api server currently does not support either the required endpoints. Furthermore it was discovered that the F3800 power stations attached to the Power Panel are not tracked as system devices. Actual power consumption data in the cloud api was not discovered yet and it is assumed that the power panel home page consumption values are merged by the App from the MQTT cloud server only if the App home page is viewed. A work around for monitoring some power values and overall SOC has been implemented by extracting the last valid 5 minute average data that is collected with the system energy statistics (Basically the last data point that is visible in the various daily diagrams of your mobile app). However this comes with a cost of ~80 MB data traffic per system per day just for the average power values. You can exclude the average power category from your integration configuration options to reduce they daily data traffic.

Integration version 3.1.0 added a customizable battery capacity to the Powerpanel device. Since the assigned F3800 PPS cannot be determined via Api queries, the capacity is assumed with a single F3800 device without expansion batteries. You can adjust the capacity to your installation to let the integration calculate the estimated remaining battery energy based on the actual SOC. See customizable entities for a better understanding how such virtual entities are being used.

Power Panel owners need to explore and document cloud Api capabilities to further expand any Power Panel system or device support. Please refer to issue Add F3800/BP3800 Equipment when connected to Home Power Panel for contribution.

Anker released also large battery devices to complement existing PV systems. They are classified as Home Energy Systems (HES) and they come along with their own Api structures and endpoints. The X1 system belongs to this device category. The common HES Api structures and information is still unknown to a large extend, since most queries require owner access to such a device. Furthermore no endpoint to query actual power values has been identified yet, and it is assumed that the power values presented on the App home screen are merged from the MQTT server Api, but only when the App is actively used. In order to provide initial monitoring capabilities similar to Power Panel systems, the same work around for average power values and overall SOC has been implemented by extracting the last valid 5 minute average data that is collected with the system energy statistics (Basically the last data point that is visible in the various daily diagrams of your Anker App). However this comes with a cost of ~80 MB data traffic per system per day just for the average power values. You can exclude the average power category from your integration configuration options to reduce they daily data traffic.

Since integration version 3.0.0, a customizable battery capacity entity was implemented for each X1 battery module. As described above, SOC and average power values are extracted from intraday energy stats of the whole system. The values are reported against the main controller device in your system. Likewise this controller device has now also a virtual and customizable capacity entity for the whole system. If you adjust the capacity of individual battery modules, this is considered automatically for the overall system capacity calculation. However, if you modify the overall system capacity in the main controller device, individual capacity modifications of battery modules are ignored.

Integration version 3.1.0 added Dynamic utility rate plan support to monitor dynamic price forecasts for your system. However, none of those entities can actually control your X1 system settings, they are only used as customizable entities to calculate the total energy price.

X1 system owners need to explore and document cloud Api capabilities to further expand any X1 system or (sub-)device support. Please refer to issue Extending the solution to support Anker Solix X1 systems for contribution or create a new and more specific issue as feature request.

Other devices not listed in the support table are neither supported nor tested with the Api library or the HA integration. Be aware that devices are only supported by the Anker cloud Api if they can be added into a Power System. Stand alone devices such as portable power stations (PPS), power charger or power cooler, cannot be added to a system and therefore do not provide any data into the power cloud.

To get additional Anker power devices/systems added, please review the anker-solix Python library and contribute to open issues or Api exploration. Most devices can neither be tested by the developer, nor can they be added to the HA integration before their Api usage, parameters, structures and fields are fully understood, interpreted and implemented into the Api library. You can also explore the Anker Solix cloud Api directly within your HA instance via the integration's Api request action.

The Api library version 3.3.0 added support for an optional MQTT client session with the Anker MQTT server. Based on the MQTT server access information available from your Api connection, an MQTT client session can be connected to the MQTT server and subscribe to root topics for your owned devices and receive their MQTT published messages. All devices that you configured via your mobile App send data to the MQTT server at different intervals, depending on device type and state (3 sec - hourly). The Api cloud servers are also subscribed to the MQTT server in order to receive your individual device data, and record energy statistics or calculate other values that are relevant to your power system. The regular data publish interval may be in the range of 1-5 minutes, but real time data publish (3-5 seconds) can be triggered via the MQTT server for a certain timeout duration. This mechanism is used by the mobile App, which typically triggers real time data publish for a timeout duration of 5 minutes once you access the home screen or device details pages. After the timeout, the devices fallback to their standard publish interval. This trigger is only possible for owned devices, therefore member accounts typically do not see frequent data updates on the App home screen, but only at default publish intervals. Likewise the HA integration cannot get or trigger more frequent data updates via the Api connection. The optional MQTT session however can also trigger the real time date publish for owned devices. However, this mechanism is not designed to run 24x7, especially not if devices are supposed to go into standby mode. Beside additional power consumption, it may also cause lots of additional data traffic! Not only for your local MQTT client, but also in the backend between MQTT and Cloud servers. While the cloud Api payload is typically encrypted, the published MQTT message payload from the devices is not encrypted. But the bad news is, the payload is proprietary binary data, which is different for each device type and device constellation. The good news is, that the general MQTT data structure has been identified. The MQTT and Bluetooth data structures seem to be pretty identical. This enables byte decoding capabilities for the reported MQTT data fields.

This is were YOUR contribution is required. Decoding of Anker MQTT binary data has been made as simple as possible and an mqtt_monitor tool is available with the Api library. To get started, follow the MQTT data decoding guidelines.

🎉 The repository has been added to HACS community store 🎉

You should find the Anker Solix integration when you search for Anker Solix in HACS and you can install it directly from your HACS store.

Unfortunately, HACS does not automatically install the optional entity images that must be located within the web accessible www folder, which must be located in your HA installation configuration folder. Please see Optional entity pictures for instructions to copy the image files manually.

If you don't find the integration in your HACS store, use this button to add the repository to your HACS custom repositories:

Or use following procedure for HACS 2.0 or later to add the custom repository:

1. Open the HACS panel in your Home Assistant frontend.
2. Click the three dots in the top-right corner and select "Custom Repositories."
3. Add a new custom repository via the Popup dialog:
   • Repository URL: https://github.com/thomluther/ha-anker-solix
   • Type: Integration
4. Click "Add" and verify that the Anker Solix repository was added to the list.
5. Close the Popup dialog and verify that Anker Solix integration is now listed in the Home Assistant Community Store.
6. Install the integration

• It was observed that adding the repository to HACS via the button, an error may occur although it was added. You may check if you can find Anker Solix listed as possible HACS integration to be installed. If not, try to add the repository again.
• After adding the custom repository and installing the integration under HACS, you must restart Home Assistant to pick up the changes in your custom integration folder
  • HA 2024.02 will report the required restart automatically under problems
• After HA restart, you can install and configure the integration like a normal core integration via the HA frontend:
  • Go to "Configuration" -> "Integrations" click "+" and search for "Anker Solix". It should now be listed as community integration

1. Using the tool of choice to open the directory (folder) for your HA configuration (where your configuration.yaml is located, e.g. /homeassistant)
2. If you do not have a custom_components directory (folder) there, you need to create it
3. In the custom_components directory (folder) create a new folder called anker_solix
4. Download all the files from the custom_components/anker_solix/ directory (folder) in this repository
5. Place the files you downloaded in the new directory (folder) you created
6. Restart Home Assistant
7. In the HA UI go to "Configuration" -> "Integrations" click "+" and search for "Anker Solix"

If you want to use the optional entity pictures that are shown in the example screenshots in the INFO, you need to copy the images folder from the integration installation path to the www folder of your Home Assistant installation configuration folder. If you operate a Home Assistant OS device, you can preferably use file management Add Ons such as Studio Code Server or File Explorer to copy this folder after the installation:

1. Navigate to the configuration folder of your HA installation (where your configuration.yaml is located, e.g. /homeassistant)
2. Navigate to custom_components/anker_solix/ folder and copy the images subfolder containing the entity pictures
3. Go back to your configuration folder and navigate to or create the www/community/anker_solix folder structure if not existing
4. Paste the images folder into the created anker_solix community subfolder

Once the images are available in www/community/anker_solix/images/, they will be picked up when the integration is (re-)creating the entities, like on first creation or re-load of the configuration entry. Make sure to reload your HA UI browser window without cache to get the entity pictures displayed correctly.

For detailed instructions on how to configure and use the integration, please refer to INFO.

Note: When you make changes to the integration folder content, you need to restart Home Assistant to pick up those changes for the container or virtual environment where Home Assistant is being started. This is applicable as well when the integration is updated manually or via HACS.

If you have a problem, review existing issues or open a new issue with detailed instructions describing the problem. You may need to enable Debug Output for your Integration configuration. Review your debug output before you post it. While sensitive login information is masked, your unique device information as returned from the Api is not masked (serial numbers, IDs etc). You may want to change that globally before providing a debug output.

If you have questions, observations, advises or want to share your experience, feel free to open a new discussion topic.

If you want to contribute to this project, please read the Contribution guidelines. As a starter, you may want to add more translations for your native language. If you have no Python knowledge, you can contribute by exploring the Anker Solix Api via the Api request action and document your discovery of new, unknown Api request capabilities and information about your owned Anker Solix devices that you still miss in the integration.

• anker-solix-api library
• solix2mqtt project
• Solaredge HA core integration
• ha-hoymiles-wifi custom integration

If you like this project, please give it a star on GitHub

• Usage instructions and configuration of the integration
• Possibilities to integrate the Solarbank into your Energy Dashboard
• Surplus charge automation for Solarbank E1600 (1st generation)
• How to monitor Solarbank battery efficiency and health

If you need more assistance on the topic, please have a look at the following external resources:

• simon42 - Anker Solix – Home Assistant Energiedashboard & Steuerung (🇩🇪)
• Alkly - Anker SOLIX Balkonkraftwerk & Home Assistant integrieren (🇩🇪)
• Alkly - Anker Integration in Home Assistant einrichten – Eine Schritt-für-Schritt-Anleitung (🇩🇪)

Spoiler: Zero grid export with E1600 not possible? It works better as originally expected with certain requirements while considering given limitations.

Spoiler: This shows integration capabilities before Solarbank 2 was supported with version 2.0.1

Spoiler: Alkly explains his experience with Solarbank 1 and 2, the HA integration 2.4.1 and 0 grid export. Furthermore he shows how to integrate the solarbank into the energy dashboard, based on this discussion