The Anker Solix integration pulls Home Assistant data from Anker's own cloud

One cloud API, and it is not optional

ha-anker-solix is a Home Assistant custom integration that uses the anker-solix Python library to talk to Anker Solix devices through the Anker power cloud, and optionally through the Anker MQTT server. It was specifically developed to monitor the Anker Solarbank E1600, and support for further devices has been added to the API library and is available through the integration, including solar micro-inverters such as the MI80, Solarbank 2 E1600, Solarbank 3 E2700 and Anker smart meters.

The Anker power cloud also supports portable power stations, home Power Panels and home energy systems, which are not or only partially supported by the power cloud. Those are, or can be, integrated through the optional Anker MQTT server connection.

The most important architectural statement in the README is the one marked IMPORTANT. This project will NOT integrate another third interface, since merging data from two interfaces is complex enough, and the project is and remains cloud dependent. The API cloud is not optional, it is mandatory also for MQTT cloud usage.

That is a hard constraint and it is the single fact to weigh first. Even if you take the MQTT route for the data the cloud does not carry, you still need the API cloud for the system level information. If you need more robust local device interfaces and do not need system related data which is only available in the API cloud, the README points you at the Solix BLE or Anker's Modbus projects instead, and lists them under additional resources.

So the choice is not between cloud and local. It is between this integration, which handles the whole product line in one place, and the local protocols, which require you to assemble the coverage yourself.

Standalone devices do not report to the cloud at all

The NOTE block explains a limitation that will decide whether the integration is useful for your hardware.

Anker power devices which are not configured into a power system in your Anker mobile app typically do not provide any consumption data to the Anker power cloud. Likewise it has turned out that portable power stations, power banks or power cooler do not send data to the Anker power cloud either since they are not configurable as a main power system device. Therefore the API library cannot get consumption data of standalone devices through the API cloud server, but only through the optional MQTT server connection.

That is a specific and confusing failure for a new user. The device is in your account, it appears in the app, it works, and the integration simply has no consumption sensors for it, because the cloud never received the data in the first place.

The MQTT side has its own cost. Most MQTT device data is published in a hex format and varies per device model, therefore it must be decoded and described first by device owners. The README links the discussion in the API library where that work is tracked. So the MQTT route is not a plug-in either. It is a path where the community fills in the per-model decoding, and until someone does it for your model, that data is not available to you either.

The supported sensors and devices section is the reference list, and the table of contents shows how much of it there is. There are separate sections for standalone inverters such as the MI80, for Solarbank 1 devices, for Solarbank 2 devices and smart meters, for Solarbank 2 AC devices, for combined Solarbank 2 systems containing cascaded Solarbank 1 devices, for Solarbank 3 devices, for a Solarbank multisystem with a Power Dock, for Solarbank station controls, for Solarbank PPS systems, for portable power stations, for EV charger devices, for electric vehicle devices, for Power Panels, for home energy systems, for home backup systems, for the 250W Prime Charger, and for other devices, plus a section on MQTT managed devices.

That list is a good indicator of the maturity. The project is not a single device integration, it is a growing catalogue of product families, each with its own quirks, and the section per device family is where the work lives.

The README spends more words on risk than on setup

Two sections before the table of contents are the disclaimer and the usage terms, and they are unusually direct.

The disclaimer states that this custom component is an independent project and is not affiliated with Anker, that it has been developed to provide Home Assistant users with tools to integrate the devices of Anker Solix power systems into their smart home, and that any trademarks or product names mentioned are the property of their respective owners.

The usage terms explain the mechanism. The 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 caused by improper usage, library failures, API changes or other reasons.

Then the warning: 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, and users must accept these conditions prior to 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.

The last clause is the one that gives the project room to act. A user who accepts the terms is accepting that a later update may expose new write operations on their device, and the warning about improper settings causing device damage is a real hazard in a domain where the integration can set charge limits, output power and battery behaviour on a device costing a few hundred euros.

So the integration is read-mostly by intention, but not by construction, and the sections on Solarbank station controls and device settings are where writes live.

The packaging is a HACS custom component with pinned tooling

The repository layout is the standard shape of a Home Assistant custom integration, and the badges tell you how it is distributed.

There is a HACS Default badge, which is the Home Assistant Community Store listing, and hacs.json at the top of the repository is the manifest HACS reads. The custom_components/ directory holds the integration itself, with doc/ for the documentation, scripts/ for the helper scripts, and a .devcontainer.json for a development environment.

The requirements.txt shows the runtime and tooling dependencies, and they are all pinned:

colorlog==6.12.0
homeassistant>=2025.12.0
pip>=26.2.1,<26.3
ruff==0.17.0
aiofiles>=25.1.0
paho-mqtt>=2.1.0

The two runtime pieces beyond Home Assistant itself are aiofiles for asynchronous file access and paho-mqtt for the MQTT path, which confirms the optional broker connection is a first class feature rather than an afterthought. The rest are development tools, with ruff for linting and colorlog for the logging format.

The Home Assistant floor of 2025.12.0 is worth noting, because it tells you the integration uses recent core APIs rather than maintaining compatibility with old releases.

The releases are frequent: 3.8.1 on 2026-08-27, 3.8.2 on 2026-09-14 and 3.9.0 on 2026-09-29, with the last push on 2026-10-13. So the project is on a 3.x line and moving about one version a month, which for an integration that depends on a vendor cloud is a reasonable pace, since a vendor API change forces a release.

The repository is MIT licensed with a LICENSE file at the top, and it has a CODE_OF_CONDUCT.md, a CONTRIBUTING.md and an INFO.md alongside the README.

Where this integration is the wrong choice

The first limit is the one the README states most forcefully, and it cannot be engineered away. The API can change or break at any time without notice, and when it does, the integration breaks with it. That is not a hypothetical maintenance burden, it is the expected failure mode of any integration built on an undocumented API, and the project is upfront about it rather than pretending otherwise.

The second is that there is no way to run this without the cloud. The API cloud is not optional, it is mandatory also for MQTT cloud usage, and the project explicitly refuses to add a third interface because merging data from two interfaces is complex enough. If your requirement is local control of a solar system, this is the wrong project and the README points you at the Solix BLE and Modbus alternatives instead.

The third is the write risk on real hardware. The integration exposes device settings, and the terms warn about device damage by improper settings and loss of manufacturer's warranty. Setting a charge threshold or an output power limit on a battery you own is not the same as toggling a light switch, and the consent clause means a future update can add new write paths without a fresh agreement.

The fourth is the per-device data availability. If your device is not configured into a power system in the Anker app, the cloud never sees its consumption, and the MQTT fallback needs the community to have written a decoder for that model. Both conditions are outside your control, and the practical consequence is that the integration may install cleanly and still show you nothing for the device you care about most.

The fifth is the scale of the device catalogue. There are well over a dozen device families in the table of contents, each with its own section, and the quality of the integration varies by family because the work is per family. A reviewer looking at this project should read the section for their own model rather than the feature list, and there is no way to know from the outside which of those sections are thorough and which are partial.

Editorial conclusion

ha-anker-solix suits a Home Assistant user with an Anker Solarbank or related system who wants consumption and battery data as entities and is comfortable depending on an unofficial API client that can break when Anker changes it. It is the wrong tool if you need local control without a cloud round trip, because the README states the API cloud is mandatory even for MQTT usage. Before installing, read the usage terms, since the project warns of warranty and damage risk from improper settings, and read the supported devices list, because standalone devices that are not configured as a main power system device in the Anker app do not report consumption to the cloud at all.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. thomluther/ha-anker-solix on GitHub