Recent Releases of Anker Solix Integration for Home Assistant
Anker Solix Integration for Home Assistant - 3.5.3
Release 3.5.3
π Fixes and small X1 and Power Panel enhancements π«
[!IMPORTANT]
π¨ Read the breaking changes before upgrading π¨
This release implements experimental support for X1 and Power Panel device MQTT messages that may use different data field structures in MQTT messages. However, the json fields they provide use abbreviations which cause lots of ambiguity of their meaning. System owners are required to describe the X1 and Power Panel MQTT json field values with a descriptive and correct name and correct value factors if required, so the values can be extracted and properly merged with Api values and used in the HA integration. That's your time to contribute.
If controls for your Solix device are missing, they are not discovered or described yet in the MQTT mappings. For MQTT discovery π and MQTT command descriptions π§°, follow this guideline using the mqtt_monitor π with the Api library. Missing descriptions of requested device support are:
- Adding Support for Solix C2000 Gen 2 #460, A1783 Mqtt decoding - SOLIX C2000 Gen2 anker-solix-api issue #269
- Missing controls for A2345, Anker Prime Charger (250W, 6 Ports, GaNPrime) anker-solix-api issue #252
- MQTT data for A1782, SOLIX F3000 anker-solix-api issue #268
- This is a unique Solarbank PPS system type available in US and uses different Api queries and structures, which also must be discovered and explored by system owners
- Solix Cooler devices #364
- Solix X1 Home Energy System anker-solix-api issue #192
- Power Panel Data #447
- Extending solution to the E10 system Discussion #459, anker-solix-api issue #274
If nobody will analyze and describe their MQTT messages and provide MQTT command examples, those devices cannot be supported. π€·
[!TIP]
The monitor tools in the Api library allow MQTT device control for described commands per model. Try it out, and fix or update the command descriptions for your device model if missing or not working properly. The next release of the integration can then implement selected and verified MQTT device control entities for your model as well.
π Enjoy the new Anker Solix device control capabilities of this integrationπ
Enhancements: π’
- Enhanced MQTT data decoding and mapping descriptions to support Power Panel MQTT message format
- The Power Panel system provides MQTT messages with binary fields that contain json strings
- All json field names are abbreviations and context is ambiguous (similar to X1 json fields)
- A few data fields have been described but cannot be validated, therefore this is all experimental
- Bumped Api library to 3.5.3 to enable enhanced MQTT framework for coming support of Solx V1 EV charger (April release - hopefully π€·)
Breaking changes: π₯
- For upgrades from version < 3.4.0, see breaking changes in 3.4.2 release notes
- For upgrades from version < 3.5.0, see breaking changes in 3.5.1 release notes
Fixes π¨ and other changes: π§
-
Fix for Solarbank SOC reserve setting, that was not applied by Solarbank 2 devices (#463)
- The SOC reserve setting will now be applied to all Solarbank types as hybrid control:
- Via Api to apply the change to the cloud and allow the App to display the correct setting in non-device panels, for example the station settings
- Via MQTT control, to apply the change to the device itself, which is represented on the device details panel
- Solarbank 1 devices are an exception from this MQTT control requirement, since they are managed differently and the cloud typically sends regular MQTT controls (once per minute) that include the device settings known by the cloud, such as the SOC reserve setting. Therefore an Api change was indirectly applied to Solarbank 1 devices as well, but will now also be applied directly by the HA integration
- This control requires the MQTT connection to be applied properly to the device
- The SOC reserve setting will now be applied to all Solarbank types as hybrid control:
-
Fixed factor for Solarbank 2 consumed energy MQTT value (#216)
-
Fixed some MQTT descriptions for C300(X) DC charger models A1726/A1728
- Fixed missing DC 12V port power and status data extraction
-
Code refactoring to match new Ruff rules
Full Change log https://github.com/thomluther/ha-anker-solix/compare/3.5.2...3.5.3 and link to previous release notes 3.5.2
General notes: π
- MQTT data may get stale if required status messages are not longer published by the device. Some devices publish specific status messages only while their real-time trigger is active. If you overlay MQTT data, the stale MQTT values cannot be refreshed anymore by new Api data, see example in issue #401. This is working as designed, therefore you have the choice whether MQTT data should overlay Api data.
- The device sensor for battery energy is just a theoretical value and calculated by the Api library from calculated (or customized) battery capacity and SOC. Changes of this entity should NOT be considered for the energy dashboard or helper sensors, since this battery energy sensor can never reflect the battery efficiency or capacity loss over time. Furthermore the SOC value may be inaccurate as well since that is difficult to determine for LiFePo batteries.
- I do NOT recommend to use the Anker Solix integration daily energy statistic sensors directly in your energy dashboard, even if that is possible since they are classified as total_increasing sensors. The reasons for that are described in the discussion how to integrate the Solarbank into you energy dashboard. There you can also find the recommended approach for creating the required entities for easiest and most flexible energy dashboard integration. If your device supports aggregated energy values from decoded MQTT data, they may provide a more accurate source for your helper sensors that you utilize in your energy dashboard.
[!TIP]
Anker relaxed the restriction of a single active login token per account. You can now use you owner account in the App and the integration in parallel without disabling the Api switch. See Switching between different Anker Power Accounts to modify your hub configuration entry.
Contribution: π
- YOUR HELP is required if you have new Anker Solix devices or if new features are introduced by Anker and you want them being integrated into HA
- I have no chance to test any Anker devices or explore the cloud Api requests and responses for new devices or features. Since the Api is not official, no documentation exists and the Api library can only be enhanced with your support and willingness to explore and test the Api queries:
- Enhancements may only be possible when exclusive owner access to the system is available.
- But since the system belongs to you and the Api usage is not officially supported, it is up to you to test and verify Api capabilities
- MQTT device data requires decoding of binary data for your owned device type and constellation before they can be consumed
- You need to compare live message decoded values with your mobile App data to properly describe the message data fields
- This must be done under various usage conditions of the device to allow description of most data fields and bytes
- To get started, follow the MQTT data decoding guidelines and MQTT command and state analysis guideline in the Api library
Appreciation: β¨
If you like this integration and you want to show your appreciation for the countless hours spent to enhance and maintain it, I would be happy for a π΅coffee β

Renewable Energy - Photovoltaics and Solar Energy
- Python
Published by thomluther 8 days ago
Anker Solix Integration for Home Assistant - 3.5.2
Release 3.5.2
π Fixes and X1 enhancements π«
[!IMPORTANT]
π¨ Read the breaking changes before upgrading π¨
This release will bring back the new Solarbank control entities that went missing after upgrade from 3.5.0. It also implements experimental support for X1 MQTT messages and modifies/fixes the entity structure for larger X1 systems.
If controls for your Solix device are missing, they are not discovered or described yet in the MQTT mappings. For MQTT discovery π and MQTT command descriptions π§°, follow this guideline using the mqtt_monitor π with the Api library. Completely missing descriptions of requested device support are:
- Solix Cooler devices #364
- Solix V1 EV Charger #322
- Solix X1 Home Energy System in the Api library #192
If nobody will analyze and describe their MQTT messages and provide MQTT command examples, those devices cannot be supported. π€·
[!TIP]
The monitor tools in the Api library allow MQTT device control for described commands per model. Try it out, and fix or update the command descriptions for your device model if missing or not working properly. The next release of the integration can then implement selected and verified MQTT device control entities for your model as well.
π Enjoy the new Anker Solix device control capabilities of this integrationπ
Enhancements: π’
- Enhanced MQTT data decoding and mapping descriptions to support X1 MQTT message format
- The X1 HES system provides MQTT messages as json strings
- All json field names are abbreviations and context is ambiguous
- A few data fields have been described but cannot be validated, therefore this is all experimental
[!IMPORTANT]
To all X1 system owners: Please contribute in MQTT decoding, validation and data description for X1 MQTT messages. There are also couple of open questions to understand how those messages can be triggered and how command messages are structured.
[!NOTE]
The existing average power entity translation was slightly modified to show an average character in the name. Those entities cannot be merged with the MQTT data, since they have different units and may have slightly different reporting character. Therefore some power entities may appear to be duplicate. If you want to remove the average entities, you can exclude the HES average power category from your hub options.
[!TIP]
If you want local X1 system integration via the HA Modbus integration, you may refer to discussion #438
-
Updated/Fixed/enhanced the X1 entity structure
- The X1 can have multiple controller devices, however only one device is the primary controller and all others are in a subordinate role
- The primary controller seems to be the only device providing MQTT messages for the system
- All MQTT based entities will therefore being created on the primary controller only
-
Updated/Fixed/enhanced the X1 battery reporting and capacity/energy calculation
- The system did already report the overall battery module count
- Each controller will now also report the battery module count for batteries it is actually controlling
- Each controller battery capacity is therefore the sum of all controlled battery module (customized) capacities
- For example a system with 2 controllers and 6 battery modules may have 3 modules per controller:
- Each controller therefore reports 15 kWh capacity (30 kWh in total for the system)
- If any controller or controlled battery capacity is customized, it will be accounted in its controller capacity
- The primary controller is the only one reporting the overall SOC of the system and therefore also calculates the remaining battery energy of the system.
- The overall capacity accounts only the (customized) battery capacity of all controllers in the system
- This may be higher than the own reported controller battery capacity, since the battery energy accounts for the overall SOC and overall capacity of the system
- Using the example above with 100 % SOC, the primary controller will report 30 kWh remaining energy although its battery capacity is only showing 15 kWh capacity
- This may be confusing, but there is no other way to structure the data, since all is reported against the primary controller device and MQTT entities are not supported in system device types, which only reflect Api data from systems as known in the Anker cloud.
Breaking changes: π₯
- For upgrades from version < 3.4.0, see breaking changes in 3.4.2 release notes
- For upgrades from version < 3.5.0, see breaking changes in 3.5.1 release notes
Fixes π¨ and other changes: π§
-
Fix for 3.5.1 error causing some new control entities no longer being created (#258, #446)
- Control entities for Solarbank AC socket switch, LED Light Switch and Mode and Temperature unit were missing after update from 3.5.0
-
Fix for missing dynamic price provider display
- The provider selection has shown only provider options that contain also an area code
- However, with the new dynamic price provider registration, the user can select any supported provider through the app, which is no actual provider option for the device type itself.
- User registered provider selections are now shown in the select entity as well
- However, the integration cannot be used to toggle to such registered providers. This must be controlled and registered through the mobile App
-
Dynamic prices for non Nordpool provider will now consider end prices being provided
- Spot prices may be provided only by the Nordpool provider, and therefore requires to calculate the end price including taxes and fees
- End price assumption for other providers may actually be wrong, but there is no way to determine the provided price structures from the Anker cloud
- Incorrect dynamic prices cannot be fixed by the integration!
[!TIP]
It seems Anker finally fixed the broken cloud endpoints to query unread account messages and obtaining the product list, which frequently caused query timeout errors. You can now safely include the account category again, if you want to get back the unread messages sensor for system and device messages. π
Full Change log https://github.com/thomluther/ha-anker-solix/compare/3.5.1...3.5.2 and link to previous release notes 3.5.1
Notes: π
- MQTT data may get stale if required status messages are not longer published by the device. Some devices publish specific status messages only while their real-time trigger is active. If you overlay MQTT data, the stale MQTT values cannot be refreshed anymore by new Api data, see example in issue #401. This is working as designed, therefore you have the choice whether MQTT data should overlay Api data.
- The device sensor for battery energy is just a theoretical value and calculated by the Api library from calculated (or customized) battery capacity and SOC. Changes of this entity should NOT be considered for the energy dashboard or helper sensors, since this battery energy sensor can never reflect the battery efficiency or capacity loss over time. Furthermore the SOC value may be inaccurate as well since that is difficult to determine for LiFePo batteries.
- I do NOT recommend to use the Anker Solix integration daily energy statistic sensors directly in your energy dashboard, even if that is possible since they are classified as total_increasing sensors. The reasons for that are described in the discussion how to integrate the Solarbank into you energy dashboard. There you can also find the recommended approach for creating the required entities for easiest and most flexible energy dashboard integration. If your device supports aggregated energy values from decoded MQTT data, they may provide a more accurate source for your helper sensors that you utilize in your energy dashboard.
[!TIP]
Anker relaxed the restriction of a single active login token per account. You can now use you owner account in the App and the integration in parallel without disabling the Api switch. See Switching between different Anker Power Accounts to modify your hub configuration entry.
Contribution: π
- YOUR HELP is required if you have new Anker Solix devices or if new features are introduced by Anker and you want them being integrated into HA
- I have no chance to test any Anker devices or explore the cloud Api requests and responses for new devices or features. Since the Api is not official, no documentation exists and the Api library can only be enhanced with your support and willingness to explore and test the Api queries:
- Enhancements may only be possible when exclusive owner access to the system is available.
- But since the system belongs to you and the Api usage is not officially supported, it is up to you to test and verify Api capabilities
- MQTT device data requires decoding of binary data for your owned device type and constellation before they can be consumed
- You need to compare live message decoded values with your mobile App data to properly describe the message data fields
- This must be done under various usage conditions of the device to allow description of most data fields and bytes
- To get started, follow the MQTT data decoding guidelines and MQTT command and state analysis guideline in the Api library
Appreciation: β¨
If you like this integration and you want to show your appreciation for the countless hours spent to enhance and maintain it, I would be happy for a π΅coffee β

Renewable Energy - Photovoltaics and Solar Energy
- Python
Published by thomluther about 2 months ago
Anker Solix Integration for Home Assistant - 3.5.1
Release 3.5.1
βπ Control is everything π§ May the Force be with you π«
[!IMPORTANT]
π¨ Read the breaking changes before upgrading π¨
This major release finally adds support for missing device control via the Anker MQTT server and enhances and updates some MQTT data of various devices. After countless hours of Api library and HA integration enhancements, testing, debugging and error fixing, the integration now enables you to gain App like control of supported Anker Solix devices via Home Assistant, for proper Solix device integration into your home automation and energy management. Ensure to read the detailed release notes for more information!
If controls for your Solix device are missing, they are not discovered or described yet in the MQTT mappings. For MQTT discovery π and MQTT command descriptions π§°, follow this guideline using the mqtt_monitor π with the Api library. Completely missing descriptions of requested device support are:
If nobody will analyze and describe their MQTT messages and provide MQTT command examples, those devices cannot be supported. π€·
[!TIP]
The monitor tools in the Api library allow MQTT device control for described commands per model. Try it out, and fix or update the command descriptions for your device model if missing or not working properly. The next release of the integration can then implement selected and verified MQTT device control entities for your model as well.
π Enjoy the new Anker Solix device control capabilities of this integrationπ
Enhancements: π’
- Added control entities for various devices as MQTT commands are known and described (#394):
[!NOTE]
Some station based Solarbank commands are hybrid commands and may require Api and MQTT commands. Previous entities may have changed the App display, but were never applied to the device (e.g. SOC Reserve out Grid export setting). Those will now only be available/changeable, if the MQTT connection is enabled in the hub options.
[!IMPORTANT]
The AC output limit setting may not be applied or display properly due to unknown Api query/parameter that may be required. See Solarbank station controls.
-
PPS and power charger device controls as documented in supported devices (#264, #115):
- LED switch and mode, Display switch, mode and timeout
- AC/DC switches and limits, SOC limit settings
- Device timeouts, AC/DC Output timeouts
- Temperature unit selection
-
Anker Smart Plug control and real time sensor for power and energy (#150):
- Plug switch added to control the plug in HA
- Voltage and Current attributes have been added to power sensor
- Use MQTT Overlay and automate MQTT status requests for the plug if you want to refresh power data in customized intervals
- Plug related timer and schedule messages are not fully understood yet. As device owner you can contribute in their description to provide sensors for active timer as well
[!IMPORTANT]
Other MQTT controls than the plug switch will not be implemented. The MQTT command structures for plug timers and schedules are too complex and not understood. All timer and schedule based controls of the plug can be realized with HA automations and there is no need for additional plug control by the integration.
-
Changed and enhanced controls for Multisystems (#423, #392, #310):
- All usage mode and output related controls are moved from multiple Solarbanks to single Power Dock device (see breaking changes)π₯
- Added MQTT control support for station settings that must be applied to Power Docks as well
- Added MQTT power sensors for attached Solarbanks, showing also SN and SOC in attributes
- See more details under Solarbank station controlsπ
-
Updated MQTT data mapping with additional information provided by device owners. This may provide additional entities or attributes for following devices
- Solarbank 2 models, Solarbank 3 models
- Power Dock
- Prime Charger
- Anker Smart plugs
- PPS C1000 Gen 2
- PPS C300(X) AC/DC models
-
The Api library added device and battery efficiency calculations for Solarbank 2 and 3 models if required MQTT data is provided
- Device efficiency = (all output energy / all input energy) * 100%
- Battery efficiency = (all discharged energy / all charged energy) * 100%
- The provided MQTT energies are totals aggregated by the device since installation and more accurate than cloud tracked energies
- Anker may reduce consumed energy from aggregated PV and charged energies. Identified consumed energy will be added to input and charged energy for more realistic efficiency calculations.
- Details for SB2 calculations have been discussed in this issue.
- Example calculations:
[!NOTE]
The device energy related entities require that you remove the appropriate energy category from excluded category selection in your hub option settings. All device energies are excluded per default.
- Updated README and INFO documentation
- Limitations
- Supported sensors and 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
- Solarbank station controlsπ
- MQTT managed devices
- Dynamic Price Provider selection
- MQTT connection and integration
Breaking changes: π₯
- Solarbank Multisystems with Power Dock:
- Solarbank controls that may affect multiple devices in a system are now consolidated under the Power Dock device for multi systems (#423, #392):
- All schedule object related settings, like output preset, usage mode, backup load controls, Time of Use plan controls etc
- SOC reserve setting, which cannot be controlled individually in multi systems
- (New) grid export settings, which cannot be controlled individually in multi systems
- This eliminates duplicated entities that control the same settings on various devices in a system
- That also means that some of your control entities will change after the update:
- Individual Solarbank controls will remain unavailable
- Corresponding controls will be created under the Power Dock device
- Solarbank controls that may affect multiple devices in a system are now consolidated under the Power Dock device for multi systems (#423, #392):
[!IMPORTANT]
You must update your Solarbank dashboards, automations and scripts to the new entity IDs used with the Power Dock
[!TIP]
The easiest way to clear/remove orphaned entities after the update is to reconfigure your hub entry and confirm the account credentials in the reconfigure dialog. This will unregister all entities in HA and register only the remaining entities again. They will pickup the previous history data if the entity existed already.
- Dynamic price support remains limited to Nordpool provider
- Anker implemented support for lot of new dynamic price providers, which must typically be registered through the Anker app
- Provided price structures for other providers than Nordpool is unknown and may be different
- Anker servers may provide massive data overhead for other provider price queries and the time slots do not include dates π
- The price forecast calculations have therefore been limited to first 24 data points of today and tomorrow fields to avoid massive attribute sizes in the forecast entities of the integration π₯
[!IMPORTANT]
If you select another provider than Nordpool, the calculated prices in the integration are most likely wrong. The various price structures are not maintainable by this integration, therefore dynamic price support remains limited to Nordpool provider only and will NOT be enhanced.
- For upgrades from version < 3.4.0, see breaking changes in previous release notes
Fixes π¨ and other changes: π§
-
Fix for 3.5.0 error in mqtttypes.py module if message description defines more bytes in binary fields than contained in message (#439)
- Changed also the system export module to restart a new MQTT client during export if the existing client of Api session is not connected or broken
- This should ensure that MQTT messages are contained in the export to allow debugging of the message decoder
-
Fix for 3.5.0 error in schedule.py module (#440)
- Error introduced by code refactoring
-
Fix for Api change that no longer allows to query wifi info for shared X1 system devices π (#429)
- This may cause wifi related entities to become unavailable for member accounts
-
Fix for cloud Api changes since Anker added support for additional dynamic price providers (#427)
- Anker may now list provides that have no area code while not registered through the App
- Provider without area code will fail price forecast queries
- This may have caused request errors for price details and the integration could not longer be loaded if dynamic price tariff was selected for the system π
-
Dynamic price support will remain limited to Nordpool provider only
- For reason and details see Dynamic price provider selection
-
Bumped Api library to latest release for MQTT device control support
- Full HA integration support to create various control entities for MQTT devices
- Added command descriptions for various devices as provided by device owners
- Added support of new Solarbank 3 feature to display and control grid export limit
- Enhancements to support station wide Solarbank controls via the Power Dock device
- Enhanced export module with new site_device_parm types (their usage is still unknown)
- Added combiner_box controls to enable MQTT controls for Multisystems with Power Dock
- Provide efficiency calculations for SB 2/3 devices based on available aggregated energy fields
[!TIP]
It seems Anker finally fixed the broken cloud endpoints to query unread account messages and obtaining the product list, which frequently caused query timeout errors. You can now safely include the account category again, if you want to get back the unread messages sensor for system and device messages. π
Full Change log https://github.com/thomluther/ha-anker-solix/compare/3.4.2...3.5.1 and link to previous release notes 3.4.2
Notes: π
- MQTT data may get stale if required status messages are not longer published by the device. Some devices publish specific status messages only while their real-time trigger is active. If you overlay MQTT data, the stale MQTT values cannot be refreshed anymore by new Api data, see example in issue #401. This is working as designed, therefore you have the choice whether MQTT data should overlay Api data.
- The device sensor for battery energy is just a theoretical value and calculated by the Api library from calculated (or customized) battery capacity and SOC. Changes of this entity should NOT be considered for the energy dashboard or helper sensors, since this battery energy sensor can never reflect the battery efficiency or capacity loss over time. Furthermore the SOC value may be inaccurate as well since that is difficult to determine for LiFePo batteries.
- I do NOT recommend to use the Anker Solix integration daily energy statistic sensors directly in your energy dashboard, even if that is possible since they are classified as total_increasing sensors. The reasons for that are described in the discussion how to integrate the Solarbank into you energy dashboard. There you can also find the recommended approach for creating the required entities for easiest and most flexible energy dashboard integration. If your device supports aggregated energy values from decoded MQTT data, they may provide a more accurate source for your helper sensors that you utilize in your energy dashboard.
[!TIP]
Anker relaxed the restriction of a single active login token per account. You can now use you owner account in the App and the integration in parallel without disabling the Api switch. See Switching between different Anker Power Accounts to modify your hub configuration entry.
Contribution: π
- YOUR HELP is required if you have new Anker Solix devices or if new features are introduced by Anker and you want them being integrated into HA
- I have no chance to test any Anker devices or explore the cloud Api requests and responses for new devices or features. Since the Api is not official, no documentation exists and the Api library can only be enhanced with your support and willingness to explore and test the Api queries:
- Enhancements may only be possible when exclusive owner access to the system is available.
- But since the system belongs to you and the Api usage is not officially supported, it is up to you to test and verify Api capabilities
- MQTT device data requires decoding of binary data for your owned device type and constellation before they can be consumed
- You need to compare live message decoded values with your mobile App data to properly describe the message data fields
- This must be done under various usage conditions of the device to allow description of most data fields and bytes
- To get started, follow the MQTT data decoding guidelines and MQTT command and state analysis guideline in the Api library
Appreciation: β¨
If you like this integration and you want to show your appreciation for the countless hours spent to enhance and maintain it, I would be happy for a π΅coffee β

Renewable Energy - Photovoltaics and Solar Energy
- Python
Published by thomluther about 2 months ago
Anker Solix Integration for Home Assistant - 3.4.2
Release 3.4.2
β Some enhancements and fixes for MQTT data π§
[!IMPORTANT]
π¨ Read the breaking changes before upgrading from a version < 3.4.0 π¨
This release will add and update some MQTT data and it provides fixes for value decoding of particular data fields that do not follow their default field type signing. As such, the temperature fields typically use an unsigned integer byte field, but the value obviously uses a signed encoding to show negative temperatures as well. The MQTT mapping descriptions have been enhanced to support enforcement of different signed decoding if necessary.
The detection of installed expansion pack batteries for portable power stations has been corrected as well. If this information is wrong, the calculated values for installed capacity as well as remaining battery energy will be wrong as well. Values of uninstalled expansion batteries are no longer extracted since they provide no useful information. This may cause some of your unused expansion entities are no longer available after the update.
If you want to discover π and describe MQTT commands π§° for future control of your device through the integration, follow this guideline using the mqtt_monitor π with the Api library. This request for contribution goes especially to device owners that also opened the feature requests for support of:
If nobody will analyze and describe their MQTT messages and provide MQTT command examples, those devices can never be supported.
[!TIP]
The monitor tools in the Api library allow already MQTT device control for described commands per model. Try it out, and fix or update the command descriptions for your device model if missing or not working properly. The next release of the integration can then implement selected and verified MQTT device control entities as well.
Enjoy π and have a good start into 2026 π
Enhancements: π’
-
Updated MQTT data mapping with additional information provided by device owners
-
Updated guidelines and how to instructions in the Api library for MQTT command and state analysis description
-
Bumped Api library to latest updates
- Support description of enforced signing for value decoding
- Harmonized MQTT mapping keywords for command and message descriptions
- Centralized validation of MQTT controls for mandatory and optional command parameter values
- Centralized MQTT command composition, based on supported and described MQTT command messages per device model
- Added command descriptions for various devices as provided by device owners
Breaking changes: π₯
-
An update to version 3.4.0 or later will migrate previous hub configurations to the new options structure
- If you need to downgrade to a version < 3.4.0, you cannot re-use existing hub configurations
- It may work, but defaults for the restructured options will be used.
- For downgrades I recommend to remove the hub and re-create it with the required options.
- All previous entities will be recreated since they re-use the same unique_id
-
After upgrade from version < 3.4.0, you may see entities that are unavailable
- The merge of Api and MQTT data required to rename a few entity keys, which are used together with the serial number to build the unique_id of the entity
- The old unique ID is therefore no longer provided by the integration and the entity remains unavailable
- At the same time, you may see the same translated entity name with a value, but that is a new entity without history (new unique ID)
- Since the entity translations did not change, the entity_id is typically composed with same translated name and to avoid duplicates, HA adds a suffix of '*_2' in the default entity_id name
- Before you enable the new MQTT option, follow this procedure to merge the history of old unavailable entities to the new entities:
- Update the integration and restart HA
- Wait until the hub has finished the startup process. This lasts at least 1 minute until the 2nd Api poll cycle is finished, which includes the daily energy entity data (they should become available)
- Review all your Anker Solix device entities. If there are some still unavailable (old ones), you may find the same entity name with a value (new one)
- Check the entity_id of the new one, it should be suffixed with '_2' if you did not customize the original entity_id
- Now check the entity_id of the old one, which should be the same. Copy the entity_id and delete the old entity
- Go to the new entity details again and change the entity_id to the old one and update the entity.
- If you re-enter the entity details, you should also find the history of the old entity.
Fixes π¨ and other changes: π§
-
Fixed code to correctly determine number of installed expansion batteries if this information is not described or available in MQTT messages #376
- The number of installed expansion batteries will now be determined correctly by found SOC fields > 0 or SOH fields > 0 (since some PPS may report real 0 % SOC for empty batteries.
- Based on the correctly determined expansion battery count, uninstalled expansion data fields will not longer be extracted (unused 0 value fields)
- The correct battery expansion count will also fix the incorrect calculations of battery capacity and remaining energy, since those calculations are based on correct expansions count (multiplier for installed capacity)
-
Fixed temperature value decoding to show negative temperatures #418 and avoid negative times in remaining PPS battery duration #410
- Enhanced MQTT mapping descriptions to enforce signed or unsigned decoding of particular fields that deviate from their default field type encoding
-
Fixed calculated efficiency sensors to limit them to 100% and avoid 0 devisions in case of weird values provided/described in MQTT messages
-
Fixed blocking condition while closing the MQTT connection
- This could become visible at the end of the Export System action which then never completed, nor created the zip file.
Full Change log https://github.com/thomluther/ha-anker-solix/compare/3.4.1...3.4.2 and link to previous release notes 3.4.1
Notes: π
- MQTT data may get stale if required status messages are not longer published by the device. Some devices publish specific status messages only while their real-time trigger is active. If you overlay MQTT data, the stale MQTT values cannot be refreshed anymore by new Api data, see example in issue #401. This is working as designed, therefore you have the choice whether MQTT data should overlay Api data.
- The device sensor for battery energy is just a theoretical value and calculated by the Api library from calculated (or customized) battery capacity and SOC. Changes of this entity should NOT be considered for the energy dashboard or helper sensors, since this battery energy sensor can never reflect the battery efficiency or capacity loss over time. Furthermore the SOC value may be inaccurate as well since that is difficult to determine for LiFePo batteries.
- I do NOT recommend to use the Anker Solix integration daily energy statistic sensors directly in your energy dashboard, even if that is possible since they are classified as total_increasing sensors. The reasons for that are described in the discussion how to integrate the Solarbank into you energy dashboard. There you can also find the recommended approach for creating the required entities for easiest and most flexible energy dashboard integration. If your device supports aggregated energy values from decoded MQTT data, they may provide a more accurate source for your helper sensors that you utilize in your energy dashboard.
[!TIP]
Anker relaxed the restriction of a single active login token per account. You can now use you owner account in the App and the integration in parallel without disabling the Api switch. See Switching between different Anker Power Accounts to modify your hub configuration entry.
Contribution: π
- YOUR HELP is required if you have new Anker Solix devices or if new features are introduced by Anker and you want them being integrated into HA
- I have no chance to test any Anker devices or explore the cloud Api requests and responses for new devices or features. Since the Api is not official, no documentation exists and the Api library can only be enhanced with your support and willingness to explore and test the Api queries:
- Enhancements may only be possible when exclusive owner access to the system is available.
- But since the system belongs to you and the Api usage is not officially supported, it is up to you to test and verify Api capabilities
- MQTT device data requires decoding of binary data for your owned device type and constellation before they can be consumed
- You need to compare live message decoded values with your mobile App data to properly describe the message data fields
- This must be done under various usage conditions of the device to allow description of most data fields and bytes
- To get started, follow the MQTT data decoding guidelines and MQTT command and state analysis guideline in the Api library
Appreciation: β¨
If you like this integration and you want to show your appreciation for the countless hours spent to enhance and maintain it, I would be happy for a π΅coffee β

Renewable Energy - Photovoltaics and Solar Energy
- Python
Published by thomluther 3 months ago
Anker Solix Integration for Home Assistant - 3.4.1
Release 3.4.1
β More MQTT enhancements π and some fixes π§
[!IMPORTANT]
π¨ Read the breaking changes before upgrading from a version < 3.4.0 π¨
This release introduces an additional MQTT button to send a status request to the device. The device should immediately return a set of status messages if fully supported. You need to try.. If you get all MQTT data, this button should preferably be the one you automate, since it gives full control about the MQTT message traffic at your desired interval.
If you want more insight what data is extracted by the MQTT client and the device Api, you can use the new Get device information action.
And if you want to discover π and describe MQTT commands π§° for future control of your device through the integration, follow this guideline using the mqtt_monitor π with the Api library.
Enjoy and have a peaceful π Christmas Time π
Enhancements: π’
-
Added diagnostic MQTT status request button
-
New action to get device info in cache, extracted from the Api and optional MQTT client
-
Updated Export Systems method to use regular status requests instead of real-time trigger during MQTT messages export for device types that are confirmed for providing all status message types upon status requests
-
Added definitions for another PPS device type A1723
-
Updated MQTT data mapping with additional information provided by device owners
-
Added two example system exports from portable power station models including MQTT messages
-
Updated and added optional device pictures. Follow this installation guidelines if you want to use them as Entity pictures.
-
Created guidelines and how to instructions in the Api library for MQTT command and state analysis description
Breaking changes: π₯
-
An update to version 3.4.0 or later will migrate previous hub configurations to the new options structure
- If you need to downgrade to a version < 3.4.0, you cannot re-use existing hub configurations
- It may work, but defaults for the restructured options will be used.
- For downgrades I recommend to remove the hub and re-create it with the required options.
- All previous entities will be recreated since they re-use the same unique_id
-
After upgrade from version < 3.4.0, you may see entities that are unavailable
- The merge of Api and MQTT data required to rename a few entity keys, which are used together with the serial number to build the unique_id of the entity
- The old unique ID is therefore no longer provided by the integration and the entity remains unavailable
- At the same time, you may see the same translated entity name with a value, but that is a new entity without history (new unique ID)
- Since the entity translations did not change, the entity_id is typically composed with same translated name and to avoid duplicates, HA adds a suffix of '*_2' in the default entity_id name
- Before you enable the new MQTT option, follow this procedure to merge the history of old unavailable entities to the new entities:
- Update the integration and restart HA
- Wait until the hub has finished the startup process. This lasts at least 1 minute until the 2nd Api poll cycle is finished, which includes the daily energy entity data (they should become available)
- Review all your Anker Solix device entities. If there are some still unavailable (old ones), you may find the same entity name with a value (new one)
- Check the entity_id of the new one, it should be suffixed with '_2' if you did not customize the original entity_id
- Now check the entity_id of the old one, which should be the same. Copy the entity_id and delete the old entity
- Go to the new entity details again and change the entity_id to the old one and update the entity.
- If you re-enter the entity details, you should also find the history of the old entity.
Fixes π¨ and other changes: π§
- Changed assignment of Api server for country 'RO' #410
- Fixed battery capacity definitions for A1723 and other device types #410
- Fixed wrong numbering in German translations for expansion battery entities #398
- The translation fix will be used only if entity_id is created for new entities. Existing German expansion entity_ids and names must be updated/customized manually (you need to increase the number + 1)
- Fixed Api and MQTT data merge for ambiguous battery SOC descriptions #396
- Api data for battery SOC seems always to refer to the overall device SOC
- If devices support expansion batteries, they may report different SOC data:
- The overall SOC
- An optional and dedicated main battery SOC
- Those values cannot be distinguished in MQTT data if there is no expansion battery installed, since they will always be the same
- The existing MQTT mapping descriptions have been updated to differentiate those SOC values in a way they can be merged with Api SOC values:
- The name 'battery_soc' should always refer to overall device SOC and will be merged with the Api SOC value
- If devices provide a dedicated SOC for the main battery, this must be named 'main_battery_soc'
- The integration will create a new sensor for 'main_battery_soc' data and this entity will also have the associated attributes for the main battery (health, SN etc), while the overall SOC entity will track those attributes only if no dedicated main battery SOC is available
- Changed MQTT message export file format from *.json to *.ndjson
Full Change log https://github.com/thomluther/ha-anker-solix/compare/3.4.0...3.4.1 and link to previous release notes 3.4.0
Notes: π
- MQTT data may get stale if required status messages are not longer published by the device. Some devices publish specific status messages only while their real-time trigger is active. If you overlay MQTT data, the stale MQTT values cannot be refreshed anymore by new Api data, see example in issue #401. This is working as designed, therefore you have the choice whether MQTT data should overlay Api data.
- The device sensor for battery energy is just a theoretical value and calculated by the Api library from calculated (or customized) battery capacity and SOC. Changes of this entity should NOT be considered for the energy dashboard or helper sensors, since this battery energy sensor can never reflect the battery efficiency or capacity loss over time. Furthermore the SOC value may be inaccurate as well since that is difficult to determine for LiFePo batteries.
- I do NOT recommend to use the Anker Solix integration daily energy statistic sensors directly in your energy dashboard, even if that is possible since they are classified as total_increasing sensors. The reasons for that are described in the discussion how to integrate the Solarbank into you energy dashboard. There you can also find the recommended approach for creating the required entities for easiest and most flexible energy dashboard integration. If your device supports aggregated energy values from decoded MQTT data, they may provide a more accurate source for your helper sensors that you utilize in your energy dashboard.
[!TIP]
Anker relaxed the restriction of a single active login token per account. You can now use you owner account in the App and the integration in parallel without disabling the Api switch. See Switching between different Anker Power Accounts to modify your hub configuration entry.
Contribution: π
- YOUR HELP is required if you have new Anker Solix systems or if new features are introduced by Anker and you want them being integrated into HA
- I have no chance to test any Anker devices or explore the cloud Api requests and responses for new devices or features. Since the Api is not official, no documentation exists and the Api library can only be enhanced with your support and willingness to explore and test the Api queries:
- Enhancements may only be possible when exclusive owner access to the system is available.
- But since the system belongs to you and the Api usage is not officially supported, it is up to you to test and verify Api capabilities
- MQTT device data requires decoding of binary data for your owned device type and constellation before they can be consumed
- To get started, follow the MQTT data decoding guidelines and MQTT command and state analysis guideline in the Api library
Appreciation: β¨
If you like this integration and you want to show your appreciation for the countless hours spent to enhance and maintain it, I would be happy for a π΅coffee β

Renewable Energy - Photovoltaics and Solar Energy
- Python
Published by thomluther 3 months ago
Anker Solix Integration for Home Assistant - 3.4.0
Release 3.4.0
β The temperature has finally arrived π‘
[!IMPORTANT]
π¨ And with this enhancement, there came also breaking changes. So please make sure to read them before upgrading from a version < 3.4.0 π¨
I'm happy to announce release 3.4.0 with a whole basket full of surprises and enhancements (Santa Clause π is coming β). This is all based on leveraging an optional interface to the Anker MQTT server, which was enabled recently by massive enhancements and countless hours of work on the Api library. With great assistance from some community members like @ohadlevy, @rschoebel, @stockmopar, @gitTinker, @adriangalilea, @Kasper027, @eriktews who helped me to decode and describe first values for their owned device types, these enhancements can now also be picked up by the HA integration.
And surprise, surprise π... not only temperature data is available in the encoded device MQTT data, but also other values that you will never find in the mobile App, such as battery health π©Ί, MPTT Voltage β‘or aggregated energies π just to name a few. And depending on available device energy aggregates, the device or battery efficiency will be calculated and provided as well. Here is an example with some of the MQTT data I found for my Solarbank 1 device:
Additionally, the integration can now πͺ trigger real time data delivery πͺ from devices in same way as the mobile App usage triggers them in the background.
And not to finish here, the optional MQTT interface also enables support for all the other standalone Anker Solix devices that are not supported pretty much by the cloud Api server, since they are not integrated into a power system. This release provides initial (experimental) support for decoded and described MQTT data π§° of a few Portable Power Stations (PPS) as requested since quite some time.
To get the full picture about the MQTT server options and how the integration will provide hybrid usage for your devices, please πREAD the MQTT server connection documentation π before you open any problems with this new release.
And if you don't find any useful new data for your owned devices although you enabled the MQTT connection, your device model still has to be decoded and described. You can contribute by starting with the mqtt_monitor tool from the Api library and follow the MQTT data decoding guidelines.
Outlook π:
For next major release I plan to integrate control entities for MQTT device commands. This capability heavily depends on development of a common framework in the Api library that can validate supported and described commands per device model with their allowed values or options and states. All this must be provided by device owners from the community and being described in the device MQTT mapping. Don't hesitate to contribute to MQTT decoding and description if you want to gain more control and integration for your Anker Solix device.
Enhancements: π’
-
Partially merge or add MQTT data monitoring support of (real time) data for following existing and new devices:
- Enhanced: Solarbank 1 & 2 E1600 models (new and merged sensors and attributes)
- Enhanced: Solarbank 3 E2700 model (new and merged sensors and attributes)
- Enhanced: Anker and Shelly Pro Smart Meter (new and merged sensors and attributes)
- NEW: PPS C300(X) DC/AC support
- NEW: PPS C1000(X) support #115
- NEW: PPS F2000(P) #376
- NEW: PPS F3800(P) #96
-
The MQTT enhancements may include the long requested temperature #26, but also battery health, expansion pack serials, their temperature, their SOC & health, aggregated energies and various power values that could be decoded and described so far.
- Review the attributes of your known entities for additional information that may be added by the MQTT connection
- Entities which are classified to provide or merge MQTT data are flagged for MQTT in their attribution
- Following new calculated entities were added if the required aggregated energies are available (e.g. for SB1):
- Device Efficiency = Output energy / Generated energy (solar) * 100
- Battery Efficiency = Discharged energy / charged energy * 100
-
Added MQTT data overlay toggle for each device that received described MQTT data
- Typically the MQTT data is most current, since the cloud servers receive the same device messages for their recording backend and Api data may have a delayed poll interval compared to the MQTT data push characteristics that can immediately refresh entities as messages are received
- Some data may be unique to either of the 2 interfaces. but other data is available in the Api as well as individual MQTT messages and you need to make a choice how they should be merged.
- The default setting is Off, to prioritize display of Api values if same value may be provided in MQTT data (classical behavior)
- If MQTT overlay is enabled, MQTT data may update corresponding device entities and attributes once new MQTT messages are received from the device
- This may enable real time updates also for merged sensors if MQTT real time data trigger is active
- However, if there are wrong decoding descriptions or other cloud correlated data depending on individual MQTT values, the values may flipping incorrectly between Api and MQTT data as you toggle the overlay
- Furthermore, since only a subset of data may be refreshed by the MQTT overlay and the received message, you may loose the holistic view of all your device data which is maintained if you look only at the values as they are all refreshed after the Api server poll.
- And last but not least, certain MQTT data may get stale, if it is just contained in the real time messages but the real time publish is stopped by the device
- You have to test that per device whether MQTT overlay (data merge) is beneficial for your device or not
- The toggle has NO effect on entities which do not get same data via Api & MQTT data fields.
- The toggle only selects whether entities with hybrid data should use the last value of the Api cache or the MQTT cache for their state and attribute updates
- The toggle is a customized device setting stored in the Api cache, it should be restored by HA upon reloads and restarts
[!IMPORTANT]
If you overlay MQTT data and merged data in the MQTT cache gets stale, your merged entities will no longer receive new data! See comment. This is working as designed and NO BUG #401. You ether need to disable the overlay, continuously trigger for real time messages with the data, or contribute to the message decoding for your device, to see if the stale values can be found in any standard messages which are independent of the realtime status messages.
- Added real time data trigger buttons for each device that may support MQTT server subscriptions
- This is only possible for owned devices in the used Anker account
- While real time data may not directly bring new entities and data to your device, it will also push more frequent data updates to the cloud servers (which are also subscribed to the MQTT servers), and therefore standard Api refresh cycles may provide more frequent data updates (on every cycle instead of every 5 minutes).
- Shared accounts used in the integration may not see any benefit from enabling the MQTT connection since they cannot trigger real time device data for their visible devices (neither through the mobile App due to restricted device permissions)
[!IMPORTANT]
Be aware that real time data may come with a cost if triggered permanently:
- There will be larger amounts of traffic to your HA server but also between the Anker MQTT and Cloud servers
- The Anker cloud infrastructure may not be scalable enough to maintain such 24x7 real time traffic, which is never the case with normal App usage
- The devices may be kept awake and never go to sleep mode, therefore using more power than necessary
For those reasons, the trigger is only a button that satisfies the MQTT trigger command which has a configurable timeout for real time data transmission and is not provided as permanent switch option. I would not recommend it either for permanent usage. But if you want to do so, you will have to create an automation for regular button triggering.
[!NOTE]
Just prior this release, I found that the real time trigger for Solarbank 1 devices does not always seem to work. Even if the App sends them to the SB1, it also sends permanently a command without parameters, lets call it 'status_request' command. After this command, the SB1 sends reliably the status message 0405 that is typically sent permanently while the trigger is active. But for SB1 this may have been implemented as permanent state request through the App. I don't know if there are other devices not using the real time trigger with timeout approach. If you notice the real time trigger not working for your device, please use the mqtt_monitor to verify the commands sent by the mobile App and open an issue in the Api library to adjust the MQTT real time data mechanism for affected model types.
-
The hub configuration options have been restructured to support more options #375
- Added MQTT options to the configuration options
- Toggle for the MQTT connection (default is Off)
- Timeout used for the Real Time trigger command
- MQTT remains disabled per default for the time being as this is still an experimental feature
- The dialog is now structured in collapsed sections for Api and MQTT options
- This restructuring requires a migration of your existing configuration entries to the new structure
- This is a breaking change and migrated configurations are not backward compatible (see breaking changes)
- Added MQTT options to the configuration options
-
Added support for up to 5 decimals with the system price entity as supported through the mobile app and the cloud server #368
-
Added option to export MQTT messages during Export System action
- This option is enabled per default and will include export of all received messages from eligible account devices into JSON files
- In order to collect standard and real time message types, the export duration elongates to over 5 minutes
- Within those 5 minutes, the account devices will be triggered for 60 seconds real time data. This trigger may overwrite any active device triggers that may have been started with longer timeouts
- MQTT data of the devices must be included if the export is required for problem analysis
Breaking changes: π₯
-
An update to version 3.4.0 or later will migrate existing hub configuration to the new options structure
- If you need to downgrade to a version < 3.4.0, you cannot re-use existing hub configurations
- It may work, but defaults for the options will be used.
- In this case I recommend to remove the hub and re-create it with the required options.
- All previous entities will be recreated
-
The merge of MQTT data required to rename a few entity keys, which are used together with the serial number to build their unique ID
- This will have the effect, that after upgrade from version < 3.4.0, you may see entities that are unavailable, because their unique ID is no longer provided by the integration. At the same time, you may see the same translated entity name with a value, but that is a new entity without history (new unique ID)
- Since the entity translations did not change, the entity_id is typically composed with same translated name and to avoid duplicates, HA adds a suffix of '*_2' in the entity_id name
- Before you enable the new MQTT option, follow this procedure to merge the history of old unavailable entities to the new entities:
- Update the integration and restart HA
- Wait until the hub has finished the startup process. This lasts at least 1 minute until the 2nd Api poll cycle is finished, which includes the daily energy entity data (they should become available)
- Review all your Anker Solix device entities. If there are some still unavailable (old ones), you may find the same entity name with a value (new one)
- Check the entity_id of the new one, it should be suffixed with '_2' if you did not customize the original entity_id
- Now check the entity_id of the old one, which should be the same. Copy the entity_id and delete the old entity
- Go to the new entity details again and change the entity_id to the old one and update the entity.
- If you re-enter the entity details, you should also find the history of the old entity.
Fixes π¨ and other changes: π§
- Configuration Error: Found shared Devices #370
- This occurred to some users with special or upper case characters in the account email address
- Work around was to delete the hub configuration and re-create it, which will also recreate previous entities
- This false account name comparison is now fixed and such false errors should no longer occur
- Added creation of HA repair issue for real shared device errors
- This may still happen if you have two or more hub configurations, and you start sharing systems or devices between those accounts through the mobile app, see Anker account limitations
- Same system IDs or device SNs will cause HA core errors during entity creation because that would create duplicate unique IDs
- The issue will now directly alert users in the frontend if the integration discovered shared devices across the existing hub accounts, since one of them will fail to load
- The issue will be automatically cleared once the conflict is resolved and all hub entries could be loaded successfully
Full Changelog https://github.com/thomluther/ha-anker-solix/compare/3.3.2...3.4.0 and link to previous release notes 3.3.2
Notes: π
- The device sensor for battery energy is just a theoretical value and calculated by the Api library from calculated (or customized) battery capacity and SOC. Changes of this entity should NOT be considered for the energy dashboard or helper sensors, since this battery energy sensor can never reflect the battery efficiency or capacity loss over time. Furthermore the SOC value may be inaccurate as well since that is difficult to determine for LiFePo batteries.
- I do NOT recommend to use the Anker Solix integration daily energy statistic sensors directly in your energy dashboard, even if that is possible since they are classified as total_increasing sensors. The reasons for that are described in the discussion how to integrate the Solarbank into you energy dashboard. There you can also find the recommended approach for creating the required entities for easiest and most flexible energy dashboard integration. If your device supports aggregated energy values which are decoded, described and provided through the MQTT device data, they may provide a more accurate source for your helper sensors that you utilize in your energy dashboard.
[!TIP]
Anker relaxed the restriction of a single active login token per account. You can now use you owner account in the App and the integration in parallel without disabling the Api switch. See Switching between different Anker Power Accounts to modify your hub configuration entry.
Contribution: π
- YOUR HELP is required if you have new Anker Solix systems or if new features are introduced by Anker and you want them being integrated into HA
- I have no chance to test any Anker devices or explore the cloud Api requests and responses for new devices or features. Since the Api is not official, no documentation exists and the Api library can only be enhanced with your support and willingness to explore and test the Api queries:
- Enhancements may only be possible when exclusive owner access to the system is available.
- But since the system belongs to you and the Api usage is not officially supported, it is up to you to test and verify Api capabilities
- MQTT device data requires decoding of binary data for your owned device type and constellation before they can be consumed
- To get started, follow the MQTT data decoding guidelines in the Api library
Appreciation: β¨
If you like this integration and you want to show your appreciation for the countless hours spent to enhance and maintain it, I would be happy for a coffee.

Renewable Energy - Photovoltaics and Solar Energy
- Python
Published by thomluther 4 months ago
Anker Solix Integration for Home Assistant - 3.3.2
Release 3.3.2
π§ Fix missing schedule control elements of combined SB1/SB2 systems π¨
Enhancements: π’
- None
Breaking changes: π₯
- None
Fixes π¨ and other changes: π§
- Fix missing schedule control elements of combined SB1/SB2 systems #359, #360
- Bug was introduced with 3.3.0 and schedule related Api query reductions for multisystem support
- Different SB1 / SB2 schedules will both be queried again for combined/cascaded Solarbank systems to make control entities available in integration
- Did further simplifications for schedule update methods across various system constellations
- Adjusted device and appliance preset limits for dual SB1 systems to use limits provided in schedule
- Your system output preset number entities can now have a reduced limit for systems with dual SB1
- The output preset limits in the schedule related Actions are not affected by this change. It remains at 3600 W, which is the maximum limit for a multisystem
- The SB1 system preset limit that can be applied to the schedule is still 800 W * SB1 count in system
- If a preset beyond any device limits is applied via schedule Actions, they will be presented in the Integration number entities, but they will be CAPPED by the device itself.
- Changed device output preset number from slider to box type to be consistent with recent system output number entity change
- This entity is only available in systems with 2 SB1 devices, which allow individual output control
Full Changelog https://github.com/thomluther/ha-anker-solix/compare/3.3.0...3.3.2 and link to previous release notes 3.3.1
Notes: π
- The device sensor for battery energy is just a theoretical value and calculated by the Api library from calculated (or customized) battery capacity and SOC. Changes of this entity should NOT be considered for the energy dashboard or helper sensors, since this battery energy sensor can never reflect the battery efficiency or capacity loss over time. Furthermore the SOC value may be inaccurate as well since that is difficult to determine for LiFePo batteries.
- I do NOT recommend to use the Anker Solix integration daily energy statistic sensors directly in your energy dashboard, even if that is possible since they are classified as total_increasing sensors. The reasons for that are described in the discussion how to integrate the Solarbank into you energy dashboard. There you can also find the recommended approach for creating the required entities for easiest and most flexible energy dashboard integration.
[!TIP]
Anker relaxed the restriction of a single active login token per account. You can now use you owner account in the App and the integration in parallel without disabling the Api switch. See Switching between different Anker Power Accounts to modify your hub configuration entry.
Contribution: π
- YOUR HELP is required if you have new Anker Solix systems or if new features are introduced by Anker and you want them being integrated into HA
- I have no chance to test any Anker devices or explore the cloud Api requests and responses for new devices or features. Since the Api is not official, no documentation exists and the Api library can only be enhanced with your support and willingness to explore and test the Api queries:
- Enhancements may only be possible when exclusive owner access to the system is available.
- But since the system belongs to you and the Api usage is not officially supported, it is up to you to test and verify Api capabilities
- MQTT device data requires decoding of binary data for your owned device type and constellation before they can be consumed
- To get started, follow the MQTT data decoding guidelines in the Api library
Appreciation: β¨
If you like this integration and you want to show your appreciation for the countless hours spent to enhance and maintain it, I would be happy for a coffee.

Renewable Energy - Photovoltaics and Solar Energy
- Python
Published by thomluther 6 months ago
Anker Solix Integration for Home Assistant - 3.3.1
Release 3.3.1
π§ Further changes and enhancements for ongoing Anker cloud Timeout Errors π¨
This release aims to reduce the logged warnings and errors of the integration while the cloud issues persist.
During my tests with the 3.3.1 enhancements, I could only see a single grouped log event for the repetitive errors with the same endpoint:
If you want to avoid that as well, you can now exclude the queries for the current problematic endpoints completely, by excluding the new category 'Account info' in your hub configuration options:
I also added a new hub configuration option to adjust the request timeout, in case that may help to prevent DNS Timeout errors for your specific network routing.
This new option is documented in the data refresh configuration options.
Enhancements: π’
-
New exclusion category was added to the hub configuration options: Account Information
- Once excluded, this will prevent the problematic get_message_unread and get_product endpoint requests completely
- It can be used to avoid the expected timeout errors while the cloud issues exist
- Exclusion will remove the Unread Messages sensor
- It may also cause no standard device names for device models in member systems, since those report only the alias (custom name), which will be used as device name by default
-
Request Timeout has been made configurable in your hub configuration option
- The default timeout remains 10 seconds, but can now be modified between 5-60 seconds
- It will be used for each request, also for a retry that may occur on timeouts or http errors indicating a temporary problem
-
Updated INFO.md for new data refresh configuration options.
Breaking changes: π₯
- None
Fixes π¨ and other changes: π§
- Reduced the severity of Request Retry log messages from Warning to Info
- This prevents they will be filtered for your HA core log events
- It can be seen only when looking at core live logs and if logger level is Info
- All final request errors now make only a single error log entry if something went wrong
- They still raise the error and methods catching that exception may additionally log an error if the exception is not ignored
Following is what you can see now in the HA core live logs for an endpoint failure during poll:
2025-09-24 15:43:50.467 INFO (MainThread) [custom_components.anker_solix] Http error 'Timeout Error', retrying request of api tho*** after delay of 2 seconds for endpoint: power_service/v1/get_message_unread
2025-09-24 15:44:01.469 ERROR (MainThread) [custom_components.anker_solix] Api tho*** Error for request: GET https://ankerpower-api-eu.anker.com/power_service/v1/get_message_unread
Response Text: Timeout Error
Full Changelog https://github.com/thomluther/ha-anker-solix/compare/3.3.0...3.3.1 and link to previous release notes 3.3.0
Notes: π
- The device sensor for battery energy is just a theoretical value and calculated by the Api library from calculated (or customized) battery capacity and SOC. Changes of this entity should NOT be considered for the energy dashboard or helper sensors, since this battery energy sensor can never reflect the battery efficiency or capacity loss over time. Furthermore the SOC value may be inaccurate as well since that is difficult to determine for LiFePo batteries.
- I do NOT recommend to use the Anker Solix integration daily energy statistic sensors directly in your energy dashboard, even if that is possible since they are classified as total_increasing sensors. The reasons for that are described in the discussion how to integrate the Solarbank into you energy dashboard. There you can also find the recommended approach for creating the required entities for easiest and most flexible energy dashboard integration.
[!TIP]
Anker relaxed the restriction of a single active login token per account. You can now use you owner account in the App and the integration in parallel without disabling the Api switch. See Switching between different Anker Power Accounts to modify your hub configuration entry.
Contribution: π
- YOUR HELP is required if you have new Anker Solix systems or if new features are introduced by Anker and you want them being integrated into HA
- I have no chance to test any Anker devices or explore the cloud Api requests and responses for new devices or features. Since the Api is not official, no documentation exists and the Api library can only be enhanced with your support and willingness to explore and test the Api queries:
- Enhancements may only be possible when exclusive owner access to the system is available.
- But since the system belongs to you and the Api usage is not officially supported, it is up to you to test and verify Api capabilities
- MQTT device data requires decoding of binary data for your owned device type and constellation before they can be consumed
- To get started, follow the MQTT data decoding guidelines in the Api library
Appreciation: β¨
If you like this integration and you want to show your appreciation for the countless hours spent to enhance and maintain it, I would be happy for a coffee.

Renewable Energy - Photovoltaics and Solar Energy
- Python
Published by thomluther 6 months ago
Anker Solix Integration for Home Assistant - 3.3.0
Release 3.3.0 for Solarbank 3 multisystem support and more
This release brings a couple of enhancements for Solarbank 3 and Multisystems. The new Power Dock has also been integrated as (passive) 'combiner_box' device in your power system.
While the power dock is not tracked as normal device in the cloud Api, it is used by the integration as home to report device related information such as SN and model, but also multisystem related sensors and controls, which you can find in the station settings of your mobile App. With new endpoints and parameters to support station managed settings, following capabilities could be implemented for all Solarbank 3 systems (with and without power dock installations):
- SOC reserve setting
- Grid export switch setting
Solarbank 3 systems also differentiate finally 3rd party PV surplus from their own PV production, not only for power and energy statistics, but also for your system earning calculations. A new 3rd party PV power sensor, as well as daily energy statistics for 3rd party PV charged and exported to grid have been implemented. This may be also supported in future for Solarbank 2 systems, but for now values are only tracked in single Solarbank 3 systems. Multisystems do NOT track 3rd party PV energy correctly yet and the energy values remain 0 kWh, which you can also see in the mobile App statistics. This will hopefully fixed soon by Anker along the other open issues with Multisystem data reporting (no data updates for member accounts).
π I'm also exited to announce further data capabilities with the Anker MQTT server π
The Api library provides a new MQTT client session, which can connect and subscribe to MQTT root topics of your owned devices to receive their published messages. It can even trigger real time data publish of your owned devices as used by the mobile App.
Sounds interesting? Then read MQTT data from devices to follow up and contribute.
π§ Ongoing Anker cloud Timeout Errors π¨
Due to ongoing Anker cloud Timeout Errors for certain endpoints (#353), further enhancements have been implemented to allow one retry for requests which indicate temporary errors. The general request timeout was also reduced from 30 to 10 seconds to avoid unnecessary delays, and the two endpoint queries which are currently identified for most timeout issues, are now ignoring but log such request errors during data collections. This may help in such situations, but the actual cloud server issues cannot be avoided completely. Hopefully Anker will fix these cloud service issues soon, since they may have been introduced with recent cloud changes to prepare support of new devicesπ€·.
Enhancements: π’
-
Common Solarbank 3 enhancements
- New select entities for AC charging power limit setting #354 and PV input power limit setting
- Those limits cannot be changed yet via cloud Api, but may be in future? π€·
- Therefore the entity just displays the actual setting as only option, but actually cannot be modified to another value
- SOC reserve setting is displayed correctly and can now also be modified via station settings as used for SB3 systems #346
- Grid export setting can be modified via a switch entity
- While SB2 models have the same capability, this setting is currently only supported for SB3 systems which modify this setting via station settings
- SB2 systems still modify this setting via direct device settings through the MQTT server
- Add 3rd Party PV power and energy to Solarbank system entities #343
- This may be supported for SB2 systems in future once supported by the power cloud and SB2 firmware.
- New select entities for AC charging power limit setting #354 and PV input power limit setting
-
Solarbank 3 multisystem enhancements
- Added basic support for multisystem configurations #310
- Fix some Solarbank values and breakdowns for cloud reported data
- Cloud does not provide (yet) breakdown for all Solarbank system data (e.g. no AC socket power breakdown)
- Wrong cloud values are adopted/corrected by the Api library as far as this is plausible and possible
- Implemented new 'combiner_box' device type to be used for (passive) devices such as the Power Dock
- The Power Dock will always be reported with offline status, since it is not connected to the cloud
- It provides the home for entities that are managed via the station, or sensors that provide totals for all Solarbank devices
- Support schedule related changes across multiple devices in same system
- All Solarbanks share the same schedule, so changes applied to an individual device must be reflected properly on other solarbanks in the system
- The appliance output preset is spread automatically across all devices in the system, depending on the SOC and capacity
- Therefore the device output power may show only the individual device share of the active output preset in custom or smart plug mode
- Support station related changes across multiple devices in same system
- This applies to all device settings that can be modified via the station settings
- Changes in either the individual device or the power dock device will be applied and updated for all Solarbank devices in the system
- Support for 3600 W output limit of Multisystems #345
- This is the new max limit allowed in Anker Solix Actions that may modify the output power in the schedule plan
- This new limit is automatically picked up correctly by the output preset entity
- Added basic support for multisystem configurations #310
-
Improved data polling stability for intermittent cloud issues #353
- The default request timeout was reduced from 30 to 10 seconds to avoid unnecessary delays
- The Anker cloud Api is typically quite fast and if there is no response within a few seconds, there won't be any
- All requests will be retried upon aiohttp ClientError that may indicate a temporary server or connection problem, or a general Timeout Error
- Each retry will be logged with a Warning message for the request error and indicate the affected endpoint
- If the retry fails too, the request will log the error with affected endpoint and raise an aiohttp ClientError
- The data poller typically stops upon any exceptions. However, recent sporadic but quite frequent cloud timeout issues mainly affected two endpoints, that have little to no dependencies in the data polling cycle
- Those queries for unread messages and product info for the account #353 now ignore request exceptions to allow the polling cycle to complete
- The impact is that you may no longer see regular updates of the unread messages entity
- The default request timeout was reduced from 30 to 10 seconds to avoid unnecessary delays
-
System export module enhancements
- Updated actual site device param types
- Added more device attributes that provide information
-
Updated README for supported devices and MQTT data from devices
Breaking changes: π₯
- To avoid data polling may fail with an error for frequent request timeouts on get_messages_unread endpoint, the corresponding entity may appear deleted by the integration or has stale data since it is no longer refreshed during device details polling cycle
- Check your HA core logs for warnings and errors from the integration and the affected endpoints
- Added new device pictures to the image folder
[!NOTE]
If you want to utilize device pictures, please update them accordingly after integration update as described in the README
Fixes π¨ and other changes: π§
- Changed the output preset number entity from slider to box format, since slider becomes unusable for larger range of 0-3600 W in 10 W steps
- This affects all Solarbank devices
- Numbers can be directly entered now via the more info dialog of the entity
- Do not use the box spinners for large changes, since each step will trigger 2 Api calls and consecutive increases are blocked for 30 seconds
Full Changelog https://github.com/thomluther/ha-anker-solix/compare/3.2.3...3.3.0 and link to previous release notes 3.2.4
Notes: π
- The device sensor for battery energy is just a theoretical value and calculated by the Api library from calculated (or customized) battery capacity and SOC. Changes of this entity should NOT be considered for the energy dashboard or helper sensors, since this battery energy sensor can never reflect the battery efficiency or capacity loss over time. Furthermore the SOC value may be inaccurate as well since that is difficult to determine for LiFePo batteries.
- I do NOT recommend to use the Anker Solix integration daily energy statistic sensors directly in your energy dashboard, even if that is possible since they are classified as total_increasing sensors. The reasons for that are described in the discussion how to integrate the Solarbank into you energy dashboard. There you can also find the recommended approach for creating the required entities for easiest and most flexible energy dashboard integration.
[!TIP]
Anker relaxed the restriction of a single active login token per account. You can now use you owner account in the App and the integration in parallel without disabling the Api switch. See Switching between different Anker Power Accounts to modify your hub configuration entry.
Contribution: π
- YOUR HELP is required if you have new Anker Solix systems or if new features are introduced by Anker and you want them being integrated into HA
- I have no chance to test any Anker devices or explore the cloud Api requests and responses for new devices or features. Since the Api is not official, no documentation exists and the Api library can only be enhanced with your support and willingness to explore and test the Api queries:
- Enhancements may only be possible when exclusive owner access to the system is available.
- But since the system belongs to you and the Api usage is not officially supported, it is up to you to test and verify Api capabilities
- MQTT device data requires decoding of binary data for your owned device type and constellation before they can be consumed
- To get started, follow the MQTT data decoding guidelines in the Api library
Appreciation: β¨
If you like this integration and you want to show your appreciation for the countless hours spent to enhance and maintain it, I would be happy for a coffee.

Renewable Energy - Photovoltaics and Solar Energy
- Python
Published by thomluther 6 months ago
Anker Solix Integration for Home Assistant - 3.2.4
Fix Release 3.2.4
A lot of you have been bothered with cloud issues last couple of days where entities became unavailable for some time (#353)
In most cases, the next refresh cycle will work again and update the entities. Sometimes you may need to reload the integration.
As it turns out, actually there are many timeouts for a specific endpoint to query unread messages of your Anker account, which is run every 10th update cycle per default (10 minutes). Testing has shown that retries on this endpoint may work, but several retries may be necessary. And very often the requests time out for this endpoint without any kind of response or error from the cloud.
Ignoring the timeouts or http gateway error responses for this endpoint seems to restore stability for the integration in many cases.
This release provides the code change as described in my comment.
General improvements on the underlying request code will be made to better handle generic timeout errors and implement a single retry for timeouts or 502 & 522 status responses, which indicate that the server may be temporarily be busy and does not respond.
While such a change cannot eliminate cloud issues, sporadic busy conditions may get masked.
Hopefully Anker will fix this cloud service issue soon, since that may have been introduced with recent cloud changes for support of latest devicesπ€·.
Enhancements: π’
- None
Breaking changes: π₯
- None
Fixes π¨ and other changes: π§
- Ignore ClientError and TimeoutError exceptions when querying unread messages for account (#353)
- Fixed Markdown card for Solarbank 2+ schedules
Full Changelog https://github.com/thomluther/ha-anker-solix/compare/3.2.3...3.2.4 and link to previous release notes 3.2.3
Notes: π
- The device sensor for battery energy is just a theoretical value and calculated by the Api library from calculated (or customized) battery capacity and SOC. Changes of this entity should NOT be considered for the energy dashboard or helper sensors, since this battery energy sensor can never reflect the battery efficiency or capacity loss over time. Furthermore the SOC value may be inaccurate as well since that is difficult to determine for LiFePo batteries.
- I do NOT recommend to use the Anker Solix integration daily energy statistic sensors directly in your energy dashboard, even if that is possible since they are classified as total_increasing sensors. The reasons for that are described in the discussion how to integrate the Solarbank into you energy dashboard. There you can also find the recommended approach for creating the required entities for easiest and most flexible energy dashboard integration.
[!TIP]
Anker relaxed the restriction of a single active login token per account. You can now use you owner account in the App and the integration in parallel without disabling the Api switch. See Switching between different Anker Power Accounts to modify your hub configuration entry.
Contribution: π
- YOUR HELP is required if you have new Anker Solix systems or if new features are introduced by Anker and you want them being integrated into HA
- I have no chance to test any Anker devices or explore the cloud Api requests and responses for new devices or features. Since the Api is not official, no documentation exists and the Api library can only be enhanced with your support and willingness to explore and test the Api queries:
- Enhancements may only be possible when exclusive owner access to the system is available.
- But since the system belongs to you and the Api usage is not officially supported, it is up to you to test and verify Api capabilities
Appreciation: β¨
If you like this integration and you want to show your appreciation for the countless hours spent to enhance and maintain it, I would be happy for a coffee.

Renewable Energy - Photovoltaics and Solar Energy
- Python
Published by thomluther 6 months ago
Anker Solix Integration for Home Assistant - 3.2.3
Fix Release 3.2.3
Yet another fix for the Solarbank battery power value in the course of utilizing new battery fields from the cloud responses.
With this last battery power calculation change, the Api library will now also consider AC charge conditions correctly (if your system AC charging values are provided correctly by the cloud, which is not always the case for SB2 AC models).
I knew that I should not have started to fix inconsistently reported consumption fields from the cloud, since this is a mess across the various Solarbank system constellations and the various fields introduced over the last years since the first Solarbank model. Once I try to fix this for a new system constellation with weird values, I may break an existing work around for another weird constellation. But at the end, there is no way to avoid those necessary value mappings and field corrections, if you want to provide a common set of reliable fields and entities for various system and device types under a common integration.
The integration also shows more values than you can see in the App home screen. So invalid cloud fields may become only visible through the integration, but never to Anker App testers or App users. At the end, Anker might not even care about fixing wrong cloud field values if they are not relevant for the mobile App and you have no capability to address it, if they become visible only through an unsupported Api.
Anyway, hopefully I got it right this time for the battery power in your systemπ€·.
[!NOTE]
The Solarbank battery power value was never provided reliably by the cloud for discharging and charging conditions. This even got worse with models that contain hybrid inverter and support AC charging, and reliable power data was always spread across various fields, including new fields that were introduced with newer Solarbank models. Therefore a reliable power value to/from battery always had to be calculated by the Api library, to allow usage of a common, reliable battery power entity for various system constellations.
[!TIP]
If you observe weird power value constellations for your system, you can utilize the Get system info action to see the Api response with the consumption values for a Solarbank system. If that does not tell you much (since you don't know how fields are mapped to entities and eventually corrected by the library), you can utilize the Export systems action and provide a zip file in an issue from the time where you see the weird values, along with a description what appears to be wrong to you. But keep in mind, most of the wrong or missing cloud values cannot be corrected, but calculated values should be adopted to work correctly for your system.
Following are all changes since 3.2.0:
Enhancements: π’
- Dynamically update output preset number entity limits if they are changing #332
- Output preset limits may change depending on solarbank model and actual device settings, such as maximum inverter output power, or the defined inverter model for Solarbank 1 devices
- If a Solarbank device setting was changed in the mobile App and caused a modification of the min or max limit given in the schedule plans, the number entity limits have never been updated during the active Api session
- This enhancement will now always update the entity limits with the min and max load values as reported in the active schedule plan.
- This will prevent that number modifications via HA frontend or number entity actions can set values beyond the limits being applied by the device
- It will ensure that the presented entity state value is really being applied. Otherwise it would cause confusion if values would be accepted by the device schedule plan, but capped by the solarbank device without feedback/confirmation to HA users via the entity.
- The preset value limits for Anker Solix schedule actions remains unchanged
[!NOTE]
Since the action number field limits are fix, they must define the outer possible limits for all device types supported by the action. A value capping may still occur if the action setting is beyond the device model specific limits once the action is being applied, but this capping will be reflected in the resulting number entity state. However, if that value is still beyond the actual device limits which may be smaller, capping will still be applied by the device itself, which is NOT reflected back to the number entity. The entity shows only the active setting given in the schedule plan as you can also find it in the Anker mobile app.
[!IMPORTANT]
This change will NOT fix issue #309 to allow output preset > 800 W. That is an Anker cloud or device problem which seems to be specific for SB3, because the active device limits in the schedule plan are not longer reflecting the applied limits, but 800 W although device setting is 1000 or 1200 W. However, the reported device limits in the schedule plan must be taken as active entity limits, to avoid confusion with number entity settings as described above.
Breaking changes: π₯
- SB1 users may notice an increase in the minimum limit of the output preset entity to 150 W, since that is now adopted to the actual limit applied by the device and depends on the defined inverter type.
- This prevents situations where 100-140 W are applied to the entity, but the actual Solarbank lower limit is 150 W due to the configured inverter type, and therefore the min. home load preset that is being applied.
- You need HA 2025.3.0 or later to upgrade to the 3.2.x version of the integration #339 #341
- Earlier HA versions should not allow installation of this version, but who knows how you setup your HA core and install upgrades?
- If you upgraded anyway and see exceptions, you may try to exclude the 'Vehicle' category from your hub configuration options. But it is not validated, whether that will avoid trying import of classes your HA version does not have yet.
Fixes π¨ and other changes: π§
- Integration broke after update to 3.2.0 #337
- Old HA releases do not know the new device class energy distance
- Updated minimum HA release to 2025.3.0 which introduced the energy distance device class and units
- The new min version will prevent integration can be updated on older HA releases which do not have all requirements
- Fixed exception when pressing device refresh button #333
- Problem was introduced with new vehicle details refresh button
- Solarbank not longer delivering negative battery power values since update to 3.2.0 #338
- Problem was introduced by utilization of new battery charge/discharge fields and is fixed again π
- Fixed exception while setting up select entity domain with 3.2.1 #339
- Exception: Error adding entity None for domain select with platform anker_solix
- Problem was introduced with a code optimization for option settings of select entities
- Solarbank AC charging power not longer reflected in battery power entity since update to 3.2.0 #340
- Problem was introduced by utilization of new battery charge/discharge fields and is fixed again π
- Battery power calculation will now consider also AC charge for proper battery power calculation if new charge/discharge fields do not provide any values.
Full Changelog https://github.com/thomluther/ha-anker-solix/compare/3.2.0...3.2.3 and link to previous release notes 3.2.0
Notes: π
- The device sensor for battery energy is just a theoretical value and calculated by the Api library from calculated (or customized) battery capacity and SOC. Changes of this entity should NOT be considered for the energy dashboard or helper sensors, since this battery energy sensor can never reflect the battery efficiency or capacity loss over time. Furthermore the SOC value may be inaccurate as well since that is difficult to determine for LiFePo batteries.
- I do NOT recommend to use the Anker Solix integration daily energy statistic sensors directly in your energy dashboard, even if that is possible since they are classified as total_increasing sensors. The reasons for that are described in the discussion how to integrate the Solarbank into you energy dashboard. There you can also find the recommended approach for creating the required entities for easiest and most flexible energy dashboard integration.
[!TIP]
Anker relaxed the restriction of a single active login token per account. You can now use you owner account in the App and the integration in parallel without disabling the Api switch. See Switching between different Anker Power Accounts to modify your hub configuration entry.
Contribution: π
- YOUR HELP is required if you have new Anker Solix systems or if new features are introduced by Anker and you want them being integrated into HA
- I have no chance to test any Anker devices or explore the cloud Api requests and responses for new devices or features. Since the Api is not official, no documentation exists and the Api library can only be enhanced with your support and willingness to explore and test the Api queries:
- Enhancements may only be possible when exclusive owner access to the system is available.
- But since the system belongs to you and the Api usage is not officially supported, it is up to you to test and verify Api capabilities
Appreciation: β¨
If you like this integration and you want to show your appreciation for the countless hours spent to enhance and maintain it, I would be happy for a coffee.

Renewable Energy - Photovoltaics and Solar Energy
- Python
Published by thomluther 7 months ago
Anker Solix Integration for Home Assistant - 3.2.2
Fix Release 3.2.2
Enhancements: π’
- Dynamically update output preset number entity limits if they are changing #332
- Output preset limits may change depending on solarbank model and actual device settings, such as maximum inverter output power, or the defined inverter model for Solarbank 1 devices
- If a Solarbank device setting was changed in the mobile App and caused a modification of the min or max limit given in the schedule plans, the number entity limits have never been updated during the active Api session
- This enhancement will now always update the entity limits with the min and max load values as reported in the active schedule plan.
- This will prevent that number modifications via HA frontend or number entity actions can set values beyond the limits being applied by the device
- It will ensure that the presented entity state value is really being applied. Otherwise it would cause confusion if values would be accepted by the device schedule plan, but capped by the solarbank device without feedback/confirmation to HA users via the entity.
- The preset value limits for Anker Solix schedule actions remains unchanged
[!NOTE]
Since the action number field limits are fix, they must define the outer possible limits for all device types supported by the action. A value capping may still occur if the action setting is beyond the device model specific limits once the action is being applied, but this capping will be reflected in the resulting number entity state. However, if that value is still beyond the actual device limits which may be smaller, capping will still be applied by the device itself, which is NOT reflected back to the number entity. The entity shows only the active setting given in the schedule plan as you can also find it in the Anker mobile app.
[!IMPORTANT]
This change will NOT fix issue #309 to allow output preset > 800 W. That is an Anker cloud or device problem which seems to be specific for SB3, because the active device limits in the schedule plan are not longer reflecting the applied limits, but 800 W although device setting is 1000 or 1200 W. However, the reported device limits in the schedule plan must be taken as active entity limits, to avoid confusion with number entity settings as described above.
Breaking changes: π₯
- SB1 users may notice an increase in the minimum limit of the output preset entity to 150 W, since that is now adopted to the actual limit applied by the device and depends on the defined inverter type.
Fixes π¨ and other changes: π§
- Integration broke after update to 3.2.0 #337
- Old HA releases do not know the new device class energy distance
- Updated minimum HA release to 2025.3.0 which introduced the energy distance device class and units
- The new min version will prevent integration can be updated on older HA releases which do not have all requirements
- Fixed exception when pressing device refresh button #333
- Problem was introduced with new vehicle details refresh button
- Solarbank not longer delivering negative battery power values since update to 3.2.0 #338
- Problem was introduced by utilization of new battery discharge fields and is fixed again π
- Fixed exception while setting up select entity domain with 3.2.1 #339
- Exception: Error adding entity None for domain select with platform anker_solix
- Problem was introduced with a code optimization for option settings of select entities
Full Changelog https://github.com/thomluther/ha-anker-solix/compare/3.2.0...3.2.2 and link to previous release notes 3.2.0
[!TIP]
Anker relaxed the restriction of a single active login token per account. You can now use you owner account in the App and the integration in parallel without disabling the Api switch. See Switching between different Anker Power Accounts to modify your hub configuration entry.
Notes: π
- The device sensor for battery energy is just a theoretical value and calculated by the Api library from calculated (or customized) battery capacity and SOC. Changes of this entity should NOT be considered for the energy dashboard or helper sensors, since this battery energy sensor can never reflect the battery efficiency or capacity loss over time. Furthermore the SOC value may be inaccurate as well since that is difficult to determine for LiFePo batteries.
- I do NOT recommend to use the Anker Solix integration daily energy statistic sensors directly in your energy dashboard, even if that is possible since they are classified as total_increasing sensors. The reasons for that are described in the discussion how to integrate the Solarbank into you energy dashboard. There you can also find the recommended approach for creating the required entities for easiest and most flexible energy dashboard integration.
Contribution: π
- YOUR HELP is required if you have new Anker Solix systems or if new features are introduced by Anker and you want them being integrated into HA
- I have no chance to test any Anker devices or explore the cloud Api requests and responses for new devices or features. Since the Api is not official, no documentation exists and the Api library can only be enhanced with your support and willingness to explore and test the Api queries:
- Enhancements may only be possible when exclusive owner access to the system is available.
- But since the system belongs to you and the Api usage is not officially supported, it is up to you to test and verify Api capabilities
Appreciation: β¨
If you like this integration and you want to show your appreciation for the countless hours spent to enhance and maintain it, I would be happy for a coffee.

Renewable Energy - Photovoltaics and Solar Energy
- Python
Published by thomluther 7 months ago
Anker Solix Integration for Home Assistant - 3.2.1
Fix Release 3.2.1
Enhancements: π’
- Dynamically update output preset number entity limits if they are changing #332
- Output preset limits may change depending on solarbank model and actual device settings, such as maximum inverter output power, or the defined inverter model for Solarbank 1 devices
- If a Solarbank device setting was changed in the mobile App and caused a modification of the min or max limit given in the schedule plans, the number entity limits have never been updated during the active Api session
- This enhancement will now always update the entity limits with the min and max load values as reported in the active schedule plan.
- This will prevent that number modifications via HA frontend or number entity actions can set values beyond the limits being applied by the device
- It will ensure that the presented entity state value is really being applied. Otherwise it would cause confusion if values would be accepted by the device schedule plan, but capped by the solarbank device without feedback/confirmation to HA users via the entity.
- The preset value limits for Anker Solix schedule actions remains unchanged
[!NOTE]
Since the action number field limits are fix, they must define the outer possible limits for all device types supported by the action. A value capping may still occur if the action setting is beyond the device model specific limits once the action is being applied, but this capping will be reflected in the resulting number entity state. However, if that value is still beyond the actual device limits which may be smaller, capping will still be applied by the device itself, which is NOT reflected back to the number entity. The entity shows only the active setting given in the schedule plan as you can also find it in the Anker mobile app.
[!IMPORTANT]
This change will NOT fix issue #309 to allow output preset > 800 W. That is an Anker cloud or device problem which seems to be specific for SB3, because the active device limits in the schedule plan are not longer reflecting the applied limits, but 800 W although device setting is 1000 or 1200 W. However, the reported device limits in the schedule plan must be taken as active entity limits, to avoid confusion with number entity settings as described above.
Breaking changes: π₯
- SB1 users may notice an increase in the minimum limit of the output preset entity to 150 W, since that is now adopted to the actual limit applied by the device and depends on the defined inverter type.
Fixes π¨ and other changes: π§
- Integration broke after update to 3.2.0 #337
- Old HA releases do not know the new device class energy distance
- Updated minimum HA release to 2025.3.0 which introduced the energy distance device class and units
- The new min version will prevent integration can be updated on older HA releases which do not have all requirements
- Fixed exception when pressing device refresh button #333
- Problem was introduced with new vehicle details refresh button
- Solarbank not longer delivering negative battery power values since update to 3.2.0 #338
- Problem was introduced by utilization of new battery discharge fields and is fixed again π
Full Changelog https://github.com/thomluther/ha-anker-solix/compare/3.2.0...3.2.1 and link to previous release notes 3.2.0
[!TIP]
Anker relaxed the restriction of a single active login token per account. You can now use you owner account in the App and the integration in parallel without disabling the Api switch. See Switching between different Anker Power Accounts to modify your hub configuration entry.
Notes: π
- The device sensor for battery energy is just a theoretical value and calculated by the Api library from calculated (or customized) battery capacity and SOC. Changes of this entity should NOT be considered for the energy dashboard or helper sensors, since this battery energy sensor can never reflect the battery efficiency or capacity loss over time. Furthermore the SOC value may be inaccurate as well since that is difficult to determine for LiFePo batteries.
- I do NOT recommend to use the Anker Solix integration daily energy statistic sensors directly in your energy dashboard, even if that is possible since they are classified as total_increasing sensors. The reasons for that are described in the discussion how to integrate the Solarbank into you energy dashboard. There you can also find the recommended approach for creating the required entities for easiest and most flexible energy dashboard integration.
Contribution: π
- YOUR HELP is required if you have new Anker Solix systems or if new features are introduced by Anker and you want them being integrated into HA
- I have no chance to test any Anker devices or explore the cloud Api requests and responses for new devices or features. Since the Api is not official, no documentation exists and the Api library can only be enhanced with your support and willingness to explore and test the Api queries:
- Enhancements may only be possible when exclusive owner access to the system is available.
- But since the system belongs to you and the Api usage is not officially supported, it is up to you to test and verify Api capabilities
Appreciation: β¨
If you like this integration and you want to show your appreciation for the countless hours spent to enhance and maintain it, I would be happy for a coffee.

Renewable Energy - Photovoltaics and Solar Energy
- Python
Published by thomluther 7 months ago
Anker Solix Integration for Home Assistant - 3.2.0
Release 3.2.0, it's all about π vehicles π ...
Vehicles? What the heck should you do with vehicles in your Anker account? π
Well, the answer is the announced Solix EV Charger V1. Electric Vehicle charging capability will require that users define vehicles in their account, which can then be used for charge management via the EV Charger. Vehicles can be considered as virtual devices with certain attributes that are defined per user account. The Solix EV Charger device is probably the first Solix device category, which can be shared amongst user accounts to allow each user to manage charging of the owned vehicle, independent of the owner of the EV Charger device or integrated system. Every Anker account can create, modify and remove vehicles. However, vehicle support is not available yet in the current mobile App version 3.10, and may likely be added with support for the EV Charger V1.
This integration release adds support to list, modify and remove vehicles in your configured hub account, in order to be prepared once V1 Charger support can be added as well. Creation of vehicles via a config flow could also be added in a future release (maybe π€·).
Check the details for other enhancements and fixes.
Enhancements: π’
-
Added support for modification of vehicles in the user account
- Any existing vehicle definition will be added as vehicle device that is connected to your account device
- All vehicle attributes can be modified, after the default attributes have been set based on brand/model/year/model-ID selection
- A model ID selection will reset the attributes to the defined attributes of that model ID
- All selection options will be queried in the cloud and cached in the Api cache for better performance of electable options
- Vehicles can be removed from your account by removing the device in HA
- Vehicle related devices and entities can be completely deactivated by excluding the Vehicles category in your hub configuration options
- Vehicle information is only refreshed with device details updates (every 10 data refreshes per default)
- A manual vehicle information refresh can be triggered via button in the account device
- See also special notes for EV devices for more details
-
Added support for dynamic device updates if a device change is discovered in your account
- Since vehicles are virtual devices, changes within your account can occur more frequently, for example adding or removing EV's via the mobile app
- Previously the integration had to be reloaded, reconfigured or Api switch toggled to update the active device and entity registration for the configured hub entry
- The integration has now implemented a device registration mechanism and each new or removed device will now be recognized by the active Api session
- New devices will be added silently to the HA registry, missing devices will be removed from your hub configuration and HA registry and a warning for each removed orphaned device will be logged
- Depending on the device type, the device change recognition may happen only during the device details refresh cycle (every 10 data update cycles per default)
-
Introduced usage of charge status description for Solarbank 2+ devices, which no longer support various charging status codes #326
- If charging status code 0 is found for Solarbank 2 or later generations, a proper status description will now be set based on actual constellation of power and SOC values
- The same descriptions as used for Solarbank 1 devices will be set when appropriate
- A new description for 'charge_ac' was added, which will indicate any battery AC charge from external PV or grid
- The charge_ac status will be prioritized over other charge conditions, which means during charge_ac status also PV charge may occur in parallel. If charge_ac is not active, then no charge via house grid should be done
- This enhancement should avoid the never changing 'Detection' mode for Solarbank 2 AC or 3 in most cases π
[!NOTE]
Since this is only an assumed charging description, it may be wrong based on weird power or SOC value constellations from the cloud
-
Updated Api system export routine for additional endpoints/parameters and randomization of new sensitive data fields
- Added/updated used Api endpoints
- Additional queries for vehicles, device grouping and power chargers
-
Upgraded to latest Api library 3.2.0 with new endpoints and enhancements for coming devices and features
- Added new fields to Solarbank device details
-
Updated documentation to reflect addition of vehicles and special notes about unsupported Solarbank Multisystems: README.md and INFO.md
Breaking changes: π₯
- Added new device pictures (again) to the image folder
[!NOTE]
If you want to utilize device pictures, please update them accordingly after integration update as described in the README
Fixes π¨ and other changes: π§
- Yet another fix for Power Panel average grid export power calculation in first interval #306
- Reduce HA core warnings if new cloud energy value is slightly smaller than previous energy value #319
- A reduction of Total Increasing sensors is not expected
- This may be rounding differences by the cloud
- The fix will ignore the new value if it is larger than 0 and the decrease is within 1 step decrement of the sensor precision definition (that is 0.01 kWh for most energy sensors)
- Larger decreases or 0 values for Total Increasing classified energy sensors must be considered as sensor reset to let the HA recorder count the statistics appropriately
- Fixed some 0 value reporting issues from the cloud for Solarbank AC, if a proper value can be assumed from other power field constellations
- Fixed some value reporting issues from the cloud if a Solarbank multi-system is in use
- Value breakdown per device is not available for every Solarbank power data point in the cloud structures (e.g. AC socket power)
- See also special notes about Solarbank Multisystems with Power Dock
[!IMPORTANT]
Solarbank multi-systems still have significant consumption data reporting issues to the cloud, see Add support for multi-system Solarbanks. Full multi-system support can just be provided after Anker fixed the reporting issues and after further system exports of such constellations are provided by the community. Especially the schedule management and usage mode dependencies across such multi-system devices is completely unknown at this point. It is also questionable whether each Solarbank can still be managed individually our a combined usage must be applied, which is automatically shared/spread across all devices in the multi-system.
Full Changelog https://github.com/thomluther/ha-anker-solix/compare/3.1.1...3.2.0 and link to previous release notes 3.1.1
[!TIP]
Anker relaxed the restriction of a single active login token per account. You can now use you owner account in the App and the integration in parallel without disabling the Api switch. See Switching between different Anker Power Accounts to modify your hub configuration entry.
Notes: π
- The device sensor for battery energy is just a theoretical value and calculated by the Api library from calculated (or customized) battery capacity and SOC. Changes of this entity should NOT be considered for the energy dashboard or helper sensors, since this battery energy sensor can never reflect the battery efficiency or capacity loss over time. Furthermore the SOC value may be inaccurate as well since that is difficult to determine for LiFePo batteries.
- I do NOT recommend to use the Anker Solix integration daily energy statistic sensors directly in your energy dashboard, even if that is possible since they are classified as total_increasing sensors. The reasons for that are described in the discussion how to integrate the Solarbank into you energy dashboard. There you can also find the recommended approach for creating the required entities for easiest and most flexible energy dashboard integration.
Contribution: π
- YOUR HELP is required if you have new Anker Solix systems or if new features are introduced by Anker and you want them being integrated into HA
- I have no chance to test any Anker devices or explore the cloud Api requests and responses for new devices or features. Since the Api is not official, no documentation exists and the Api library can only be enhanced with your support and willingness to explore and test the Api queries:
- Enhancements may only be possible when exclusive owner access to the system is available.
- But since the system belongs to you and the Api usage is not officially supported, it is up to you to test and verify Api capabilities
Appreciation: β¨
If you like this integration and you want to show your appreciation for the countless hours spent to enhance and maintain it, I would be happy for a coffee.

Renewable Energy - Photovoltaics and Solar Energy
- Python
Published by thomluther 7 months ago
Anker Solix Integration for Home Assistant - 3.1.1
Fix release 3.1.1 for Solarbank 3 and Powerpanel devices
[!NOTE]
It is now official with Anker app 3.10 release notes: Anker finally relaxed the restriction of a single active login token per account. That means you can now use you owner account in the App and the integration in parallel without disabling the Api switch. π
The documentation was updated to reflect this change.
Enhancements: π’
- Added Wifi Mac address to the device wifi connection entity if provided by device
- Upgraded to latest Api library with new endpoints and enhancements for coming devices and features
- Updated Api system export routine for additional endpoints/parameters and randomization of new sensitive data fields
- Updated documentation to reflect new account sharing capability: README.md and INFO.md
Breaking changes: π₯
- None
Fixes π¨ and other changes: π§
- Fix for Power Panel average grid export power calculation being too low #306
- Added work around for the bad 'cloud change' that may impact max home load setting for Solarbank 3 users π‘ #309
- Fix for new depreciation warning with HA 2025.08.x (Thanks @ReneNulschDE)
Full Changelog https://github.com/thomluther/ha-anker-solix/compare/3.1.0...3.1.1 and link to previous release notes 3.1.0
Notes: π
- The device sensor for battery energy is just a theoretical value and calculated by the Api library from calculated (or customized) battery capacity and SOC. Changes of this entity should NOT be considered for the energy dashboard or helper sensors, since this battery energy sensor can never reflect the battery efficiency or capacity loss over time. Furthermore the SOC value may be inaccurate as well since that is difficult to determine for LiFePo batteries.
- I do NOT recommend to use the Anker Solix integration daily energy statistic sensors directly in your energy dashboard, even if that is possible since they are classified as total_increasing sensors. The reasons for that are described in the discussion how to integrate the Solarbank into you energy dashboard. There you can also find the recommended approach for creating the required entities for easiest and most flexible energy dashboard integration.
Contribution: π
- YOUR HELP is required if you have new Anker Solix systems or if new features are introduced by Anker and you want them being integrated into HA
- I have no chance to test any Anker devices or explore the cloud Api requests and responses for new devices or features. Since the Api is not official, no documentation exists and the Api library can only be enhanced with your support and willingness to explore and test the Api queries:
- Enhancements may only be possible when exclusive owner access to the system is available.
- But since the system belongs to you and the Api usage is not officially supported, it is up to you to test and verify Api capabilities
Appreciation: β¨
If you like this integration and you want to show your appreciation for the countless hours spent to enhance and maintain it, I would be happy for a coffee.

Renewable Energy - Photovoltaics and Solar Energy
- Python
Published by thomluther 8 months ago
Anker Solix Integration for Home Assistant - 3.1.0
New release 3.1.0 with more enhancements for Solarbank 3, X1 and Powerpanel devices
This release is focused again on dynamic prices and expands its support also to X1 home energy systems. While dynamic price forecasts were already supported for Solarbank 3 systems in last release, their new solar forecast capability was lacking behind. This was now added as well to provide even more monitoring capabilities for the Solarbank 3 'Smart' mode behavior.
Following is an example screenshot of the new Solarbank 3 forecast data and entities, including dynamic prices and hourly solar production and 24h forecast data:
HA users who want to monitor and manage their Anker systems in different time zones now also get some relief. HA server and Anker system timezone offsets are now considered on places where it matters. This is still experimental, like the detection of the time zone offset is experimental and may not work reliably in all cases. π€·
Last but not least there are enhancements to the new customization capabilities to avoid your customization is lost after re-enabling the Api refresh switch or in other situations.
BTW: If you are interested in the Apex chart card with the forecast data used in the screenshot, you can find it here. (It is a revised version of the card from last releaseπ)
[!NOTE]
As pointed out by @KUHLwasStolen in the anker-solix-api library, it appears Anker finally relaxed the restriction of a single active login token per account. That means you can now use you owner account in the App and the integration in parallel without disabling the Api switch. π
Enhancements: π’
- Added support for Solarbank 3 solar forecast data #299
- The Solarbank 3 provides hourly solar forecast for next 24h while running in 'Smart' mode
- The data that is visible in the solar intraday chart in the mobile app and much more is now available in following entities:
- Entity to show solar forecast for actual and next hour
- Entity to show 24h forecast, today's forecast, today's remaining production, hourly forecast data for today and the next 24h
- Old entity for daily solar yield got a new attribute to show today's hourly solar production breakdown to map data directly with hourly forecast
[!IMPORTANT]
The solar forecast entities cannot be used for your HA energy dashboard. They provide data only when the Solarbank 3 is running in 'Smart' mode and provides the data via the cloud. They were neither designed for the Energy dashboard, nor are they tested against it. There are other core and HACS integrations available for solar forecast data in your energy dashboard.
- Revised restore capability for customized entities to be more resilient and maintain customization during Api switch toggling #307π
- New features lead to new problems and it turned out that toggling the Api switch caused your customization to be lost. This is now fixed π
- During the exercise of fixing it, I had to understand the hard way that loss of customization cannot be avoided for all corner cases
- HA triggers the state dump to storage of all restore entities in 15 minute intervals and prior graceful shutdown
- If in that situation the entities have unknown state or attribute values, those will be saved and there is nothing left from your customization that can be restored during the start
- The integration now also triggers the state dump to storage for certain scenarios, e.g. before a hub configuration entry is reconfigured which may require a new registration of all devices and entities. This prevents that unsaved state customization is lost before the regular 15 minute state dump can save last states for restore.
- Furthermore any customization is now also provided as entity attribute value. This will be used as fallback during restore if the entity state at time of the dump was unknown or unavailable
[!IMPORTANT]
There is no option to exclude certain entities from the state dump or dump only dedicated entities. π€· The restore states file is the latest dump of all restore entities in your HA state machine. Following is an example corner case where your customization therefore will still be lost:
- Api switch is disabled (which wipes all entity states and attributes in the state machine) while HA is being restarted. A state dump in that situation will overwrite any previous customization and it cannot be restored when HA is restarted and restores the entity states, since neither states nor attributes may have been known at time of state dump.
-
Updated mark down card for Solarbank 1 and Solarbank 2+ schedules:
- Added time in local time zone of the device to map the time slots with actual device time in case it is in different time zone as HA server
- Considered different time zone as well for highlighting the active slot in the schedule
- Added optional AI monitoring and state information (just shown if the device can enable smart mode)
- Other fixes to prevent template exceptions in various conditions
-
Added missing grid export power average value for Powerpanel systems
- This value is missing for the intervals in the intraday energy statistics used to extract the 5 minute average values
- A work around was implemented to approximate that value, either initially from the other values or from total export change since previous interval.
-
Added customizable battery capacity for Powerpanel systems
- While Powerpanels have no battery on their own, the attached PPS F3800(P) are not recognizable as part of the system through the known Api queries because they are shown as standalone devices (not bound to any system)
- Furthermore the standalone devices can only be queried by owner accounts
- The virtual customizable capacity is therefore calculated with the bare minimum Powerpanel configuration of a single F3800 PPS
- It can be adjusted to the real installed capacity to let the integration calculate the approximated battery energy depending on SOC level
-
Further added entities:
- Added hourly solar production attribute to system entity daily solar yield if hourly solar forecast data is available
- Added PV and inverter input channel names as attribute to the corresponding device solar power channel entities (This may become customizable in a future App version for SB3 multi-system support π€·)
- Added hourly solar production attribute to system entity daily solar yield if hourly solar forecast data is available
-
Updated Api system export routine for additional endpoints/parameters and randomization of new sensitive data fields
Breaking changes: π₯
- Timezone offset support hopefully did not break known reporting and control behavior for your system. π
- You may open an issue if the detected offset is wrong or the reporting / schedule control is weird
- Added missing X1 device model pictures (again) to the image folder as well as new device pictures of models to come. π
[!NOTE]
If you want to utilize device pictures, please update them accordingly as described in the README)
Fixes π¨ and other changes: π§
- Not really release changes, but good and bad Anker power cloud changes. Here is the good one π:
- Multiple logins with same account are now possible across various devices! Actually there is no need anymore (at least as of now) to decide which Anker account to be used per device for preventing kickoff of your cloud login.
- Toggling off the Api switch may no longer be required to manage the owned devices of the account in parallel in the mobile app.
- The bad 'change' may impact Solarbank 3 users π‘:
- Max output setting of 1200 W does not seem to be reported correctly anymore via the cloud within the schedule object since mid July?
- Incorrect limit reporting is leading to 'wrong' limit being applied to output preset entity #309 and you may no longer be able to set output above 800 W via the entity or the HA schedule actions.
- Unknown 'changes' may impact all Solarbank 2 and 3 users for the work in progress to support the announced Solarbank 3 Multisystems π€·:
- It is expected that multiple Solarbank 2/3 devices in a power system are not well supported by the integration.
- This most likely leads to more than one Solarbank 2/3 device appearing in a single system that was never considered so far.
- Only cascaded Solarbank 1 devices with a single Solarbank 2 device are properly supported by the integration
- This may require new or differently used structures and fields
- E.g. will multisystems support multiple device schedule objects in a single power system or a new merged schedule that disables individual device schedules? Which schedule will have to be modified for output preset or plan changes?
- This may introduce significant change to the energy statistics since they are probably not broken down to individual solarbanks or PV channels.
- So far, all energy statistics are only for the whole power system
- The cascaded Solarbank 1/2 support required already significant work arounds in the library to properly report energy types and SOC which was never implemented correctly by Anker for the mobile app.
- There is already a feature request #310 where owners can contribute with data exports and Api exploration for such systems.
- It is expected that multiple Solarbank 2/3 devices in a power system are not well supported by the integration.
Full Changelog https://github.com/thomluther/ha-anker-solix/compare/3.0.0...3.1.0 and link to previous release notes 3.0.0
Notes: π
- The device sensor for battery energy is just a theoretical value and calculated by the Api library from calculated (or customized) battery capacity and SOC. Changes of this entity should NOT be considered for the energy dashboard or helper sensors, since this battery energy sensor can never reflect the battery efficiency or capacity loss over time. Furthermore the SOC value may be inaccurate as well since that is difficult to determine for LiFePo batteries.
- I do NOT recommend to use the Anker Solix integration daily energy statistic sensors directly in your energy dashboard, even if that is possible since they are classified as total_increasing sensors. The reasons for that are described in the discussion how to integrate the Solarbank into you energy dashboard. There you can also find the recommended approach for creating the required entities for easiest and most flexible energy dashboard integration.
Contribution: π
- YOUR HELP is required if you have new Anker Solix systems or if new features are introduced by Anker and you want them being integrated into HA
- I have no chance to test any Anker devices or explore the cloud Api requests and responses for new devices or features. Since the Api is not official, no documentation exists and the Api library can only be enhanced with your support and willingness to explore and test the Api queries:
- Enhancements may only be possible when exclusive owner access to the system is available.
- But since the system belongs to you and the Api usage is not officially supported, it is up to you to test and verify Api capabilities
Appreciation: β¨
If you like this integration and you want to show your appreciation for the countless hours spent to enhance and maintain it, I would be happy for a coffee.

Renewable Energy - Photovoltaics and Solar Energy
- Python
Published by thomluther 8 months ago
Anker Solix Integration for Home Assistant - 3.0.0
New release 3.0.0 with Solarbank 3 support and exciting new capabilities
This release is packed with new features around dynamic price support and support for toggling to new usage modes of the Solarbank 3 system. Further backend enhancements in the Api library and the Integration provide also new customization capabilities and allow you to adjust how some of the Api data is being provided to you. This includes a new battery capacity entity for all known devices with batteries, which can be customized to adjust the calculated sensor for your device battery energy.
Following is an example screenshot of the new dynamic price entities and the forecast data:
Unfortunately, the HA core cards do not offer any configuration features to use number entities with input fields on your dashboard. The 'more info' dialog typically can be used to enter numbers directly if the number entity was defined with a box mode. Slider mode number entities do not provide input fields at all in HA UI panels. However, sliders or box spinners can become very painful for providing accurate values to number entities that provide a very large range. With this release, I want to feature a very flexible card extension that is available in HACS community store. The latest version of 'Custom Features for Home Assistant Cards' allows you to enable much more features for your tile cards. It allows you to easily add an input field for any number entity on your HA dashboards. A very valuable frontend extension for missing HA core capabilities as you can see in the screenshot. Please show you appreciation to @Nerwyn for his great work.
You can implement dynamic price forecast also through other integrations, either specifically for your energy provider or as a common spot market integration like the HACS integration for EPEX spot from @mampfes. However, using the Anker cloud prices with the Anker Solix integration will provide you further entities that are needed to calculate your total energy price as defined to your Solarbank 3 system. Therefore you can monitor and compare the prices as used by automated modes of your Solarbank 3 system for its charge and discharge optimization behavior.
BTW: If you are interested in the Apex chart card with the dynamic price diagram used in the screenshot, you can find it here. (You are welcome π)
Enhancements: π’
- Added support for Solarbank 3 #248
- All new Solarbank 3 usage modes can now be toggled through the integration
- The new 'Time Slot' mode structure is not provided via known Api calls and is unknown. Therefore any configuration for Time Slot mode options cannot be implemented for the time being.
- Also the 'Smart' mode configuration options are unknown for the cloud Api and must be configured through the mobile App anyway (data collection authorization and location information for PV forecast data).
[!IMPORTANT]
Neither the Smart mode nor the Time Slot mode configuration will not be provided by the integration and requires the mobile app to admit all required authorizations or customize all parameters. Therefore both new modes should only be toggled once configured. I have no clue what happens if you toggle them before initial setup via the App is completed π€
-
Added capability to customize certain values in Api cache π
- This new feature is something you probably never missed, because the integration is supposed to provide data as delivered from the devices and that data is nothing you typically need to customize
- However, some data is not provided at all by Anker Solix devices and therefore is virtually calculated by the integration to provide you more useful information, such as the battery capacity and contained energy
- If such virtual data is based on assumptions that may be wrong (like the battery expansion capacity for intermix installations), the calculated data is wrong as well but cannot be adjusted
-
Add restore capability for certain entities π
- This is another feature you never missed, but essential if entities can be customized in a cache and their state needs to be maintained across HA restart or integration hub reconfiguration and re-registration of its devices
- It allows that you need to customize the entity only once, even if the Api cache has to be build from scratch upon each Api session start (Magic, I know π)
-
Before you start wondering 'What the hack are you talking about' π€and question 'Why are my dynamic price fee and tax changes not applied to my system settings' π€·, read Customizable entities of the Api cache
-
Added dynamic provider options and price sensors #280
- The price provider can be selected and price fee and tax settings have been implemented as customizable cache entities
- This allows you to modify them for proper price calculation even if the configured system values have not been found through the cloud Api yet
-
Added calculated capacity entities to any device that contains batteries and spec data for the capacity
- The battery capacity has been implemented as customizable cache entity
- The capacity will also be used to calculate the battery energy if a SOC value is available
- Battery capacity was also implemented for X1 devices.
- For more details and cautions, please see README for HES systems
-
Further added entities:
- Added wired connection support as diagnostic sensor if devices report this value (e.g. X1 systems)
- Added diagnostic sensor for smart plugs to indicate new information whether they are automatically controlled by Smart mode
- Added AI monitoring sensor to SB3 systems to indicate runtime status information
- Added AI enabled sensor to SB3 devices to indicate whether AI is activated and whether it was trained completely
- Added AI profit sensor to SB3 system to provide Smart advantage data as provided in the mobile app
- Added CO2 ranking data to the CO2 sensor attributes for any system type supporting it. Now you can find you CO2 ranking in the Anker universe and get a feeling of how much trees your system has already compensated (Not to be underestimated π)
Breaking changes: π₯
-
Adjusted user mode translations #294
- Solarbank 2 and 3 models introduced new usage modes and their naming changed over time
- I adjusted the translations to be closer to how they are called in the mobile App, but left their backend option name as is. This should avoid your scripts and automations will break
- However, a few sensor translations also had to be adjusted and your frontend may show unavailable entities in cards if you ever need to re-register the entities from scratch (This is when the new translations may be used for automated entity_id naming...)
-
Removed BWS surplus sensor #297
- This value was reported by the Api since the very beginning for every device, but it was always 0
- It was deactivated by default because the purpose was never known
- However since you may have been curious as I was in the beginning, you maybe activated it and added it to your dashboards
- Now after 1,5 year of waiting for this sensor to show anything else than 0 π΄, I decided to completely remove it
- I'm pretty sure you won't miss it, but you may have to remove it manually from your devices since it is no longer provided by the integration
-
Added new device model pictures to the image folder. If you want to utilize device pictures, please update them accordingly as described in the README)
Fixes π¨ and other changes: π§
-
Battery Energy sensor is reporting wrong capacity #277
- This is not really a fix since it never was a defect. The required data is simply not provided by the Api.
- But now the calculated capacity can be adjusted by you and your customization is restored by HA upon restart and reload
-
Fixed missing sensor for home load demand #288
- Thanks to the community for reminding me that this value is available in the cache but for unknown reason not shown as entity π
- I fixed the sensor description and it is now shown as system entity whenever it is used (this value requires a smart meter or smart plugs in your installation, otherwise your system cannot calculate the home demand)
-
Fixed missing sensor for the device error code
- This value even did not got a sensor description yet π―
- It was now added as device diagnostic sensor
- But don't ask me what an error code other than 0 means π€·
-
Fixed function of auto-update switch
- I think I caught that one before anyone noticed that I have broken it some time ago π
- At least nobody complained about it...
Full Changelog https://github.com/thomluther/ha-anker-solix/compare/2.8.0...3.0.0 and link to previous release notes 2.8.0
Notes: π
- The device sensor for battery energy is just a theoretical value and calculated by the Api library from nominal or customized battery capacity and SOC. Changes of this entity should NOT be considered for energy dashboard helper sensors, since this sensor can never reflect the battery efficiency or capacity loss over time.
- The daily battery discharge statistic value for Solarbank 1 is no longer correct since mid June 2024. The cloud statistics changed this value when introducing support for Solarbank 2. The daily battery discharge value for Solarbank 1 now includes also bypassed PV energy, so it is not longer dedicated to battery discharge only. You can see this wrong value also in your Anker App statistics for the battery.
- For such and other reasons, I do NOT recommend to use the Anker Solix integration daily energy statistic sensors directly in your energy dashboard, even if that is possible since they are classified as total_increasing sensors. The reasons for that are described in the discussion how to integrate the Solarbank into you energy dashboard. There you can also find the recommended approach for creating the required entities for easiest and most flexible energy dashboard integration.
Contribution: π
- YOUR HELP is required if you have new Anker Solix systems or if new features are introduced by Anker and you want them being integrated into HA
- I have no chance to test any Anker devices or explore the cloud Api requests and responses for new devices or features. Since the Api is not official, no documentation exists and the Api library can only be enhanced with your support and willingness to explore and test the Api queries:
- Enhancements may only be possible when exclusive owner access to the system is available.
- But since the system belongs to you and the Api usage is not officially supported, it is up to you to test and verify Api capabilities
Appreciation: β¨
If you like this integration and you want to show your appreciation for the countless hours spent to enhance and maintain it, I would be happy for a coffee.

Renewable Energy - Photovoltaics and Solar Energy
- Python
Published by thomluther 9 months ago
Anker Solix Integration for Home Assistant - 2.8.0
Fix release 2.8.0 with updated Systems Export
Enhancements: π’
- Enhanced Systems Export action with additional new queries in preparation for Solarbank 3 Support and dynamic tariff providers
Breaking changes: π₯
- The Inverter Limit entity for Stand Alone inverters (MI80) has been changed from number platform to select platform #268
- It turned out that this particular endpoint only supports 600 and 800 W settings
- If other endpoints will be found to support Solarbank inverter limits, those will have a fixed selection too
- The supported limit options are better presented in a select entity than in a number entity
Fixes π¨ and other changes: π§
- Avoid logging of various control entity changes in normal integration mode
- Tolerate unknown solarbank usage modes in system sensor #275
- The integration failed to setup entities for a hub entry when new and unknown usage modes are provided by devices such as Solarbank 3
- Avoid Api calls being triggered if control entity values are not changing #272
- If users run actions against control entities, such as the number entity for output preset, each action will typically trigger 2 Api calls to set and query the value
- A good practice is to run actions to an entity only if the new value is really different to the current entity value, otherwise the action is not required
- Number entities may also have a step (interval) defined on how the new value will be rounded
- To generally avoid unnecessary Api calls, the integration now validates that the new (rounded) value or option is really different from the current value or option and only applies the change via Api calls if there is a modification required.
Full Changelog https://github.com/thomluther/ha-anker-solix/compare/2.7.0...2.8.0 and link to previous release notes 2.7.0
Notes: π
- The device sensor for battery energy is just a theoretical value and calculated by the Api library from nominal battery capacity and SOC. Changes of this entity should NOT be considered for energy dashboard helper sensors, since this sensor can never reflect the battery efficiency or capacity loss over time.
[!IMPORTANT]
The battery energy sensor may have to be removed in a future release since the calculation will not longer be correct if battery packs of different capacity can be mixed between SB2 and the new SB3 systems. Currently there is no data point to provide the installed battery capacity or the type of expansion pack. For mixed battery expansions you will need to create your own template sensor to calculate battery load Wh from the SOC sensor and your installed total capacity.
- The daily battery discharge statistic value for Solarbank 1 is no longer correct since mid June 2024. The cloud statistics changed this value when introducing support for Solarbank 2. The daily battery discharge value for Solarbank 1 now includes also bypassed PV energy, so it is not longer dedicated to battery discharge only. You can see this wrong value also in your Anker App statistics for the battery.
- For such and other reasons, I do NOT recommend to use the Anker Solix integration daily energy statistic sensors directly in your energy dashboard, even if that is possible since they are classified as total_increasing sensors. The reasons for that are described in the discussion how to integrate the Solarbank into you energy dashboard. There you can also find the recommended approach for creating the required entities for easiest and most flexible energy dashboard integration.
Contribution: π
- YOUR HELP is required if you have new Anker Solix systems or if new features are introduced by Anker and you want them being integrated into HA
- I have no chance to test any Anker devices or explore the cloud Api requests and responses for new devices or features. Since the Api is not official, no documentation exists and the Api library can only be enhanced with your support and willingness to explore and test the Api queries:
- Enhancements may only be possible when exclusive owner access to the system is available.
- But since the system belongs to you and the Api usage is not officially supported, it is up to you to test and verify Api capabilities
Appreciation: β¨
If you like this integration and you want to show your appreciation for the countless hours spent to enhance and maintain it, I would be happy for a coffee.

Renewable Energy - Photovoltaics and Solar Energy
- Python
Published by thomluther 10 months ago
Anker Solix Integration for Home Assistant - 2.7.0
Support for standalone MI80 inverter systems with release 2.7.0
The Anker Solix mobile app 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, which is a different approach as used for other Anker device types. Thanks to the contribution and support of @ocarthon in feature request Support charging_pv_svc endpoints, some new endpoints have been discovered, tested and were added to the Anker Solix library.
Version 2.7.0 now picks up those enhancements and brings them to the HA integration to allow monitoring and energy tracking of your MI80 standalone inverter. Even the persistent inverter limit can be changed via the integration. π
The cloud update interval for the produced power 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.
In order to merge entities for standalone inverters with the common integration device hierarchy, a virtual system (site) will be created as home for the data polling and all entities that are typically related to a system device.
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.
[!IMPORTANT]
It is assumed that any inverter limit change will be applied to persistent memory in the hardware. Write cycles are limited by the hardware, therefore it is NOT recommended to modify the limit permanently for any kind of output regulation. The limit change is currently not supported if the inverter is part of a solarbank system since the api functionality still has to be verified by such system owners.
Your help and contribution is needed. System owners can assist the testing and exploration of Api capabilities by using Api calls directly in your HA developer tools Actions panel without coding knowledge that is required to use the Anker Solix Api python library.
Enhancements: π’
-
Support for standalone MI80 inverter devices
- Monitor produced power and cloud connection
- Adjust persistent inverter limit
- Monitor total system statistics and daily energy yields
- Adjust power price and currency for the cloud statistic savings calculation
-
Added new attributes to the account sensor for unread messages.
- The cloud now differentiates between unread system or device messages which has been added as attributes to the sensor
- The cloud now differentiates between unread system or device messages which has been added as attributes to the sensor
-
Updated README for new standalone inverter support
Breaking changes: π₯
- New device pictures have been added to the images directory
- If you want to utilize them, you need to copy them manually after the integration update was installed (prior HA restart)
Fixes π¨ and other changes: π§
- Avoid creation of empty devices if the device type is excluded in the hub configuration options
- Bumped anker-solix-api library to latest improvements
Full Changelog https://github.com/thomluther/ha-anker-solix/compare/2.6.0...2.7.0 and link to previous release notes 2.6.0
Notes: π
- The device sensor for battery energy is just a theoretical value and calculated by the Api library from nominal battery capacity and SOC. Changes of this entity should NOT be considered for energy dashboard helper sensors, since this sensor can never reflect the battery efficiency or capacity loss over time.
[!IMPORTANT]
The battery energy sensor may have to be removed in a future release since the calculation will not longer be correct if battery packs of different capacity can be mixed between SB2 and the new SB3 systems. Currently there is no data point to provide the installed battery capacity or the type of expansion pack.
- The daily battery discharge statistic value for Solarbank 1 is no longer correct since mid June 2024. The cloud statistics changed this value when introducing support for Solarbank 2. The daily battery discharge value for Solarbank 1 now includes also bypassed PV energy, so it is not longer dedicated to battery discharge only. You can see this wrong value also in your Anker App statistics for the battery.
- For such and other reasons, I do NOT recommend to use the Anker Solix integration daily energy statistic sensors directly in your energy dashboard, even if that is possible since they are classified as total_increasing sensors. The reasons for that are described in the discussion how to integrate the Solarbank into you energy dashboard. There you can also find the recommended approach for creating the required entities for easiest and most flexible energy dashboard integration.
Contribution: π
- A big Thank You to @ocarthon for discovering the new inverter endpoints, contributing to the Api library and test the code changes to enable support for standalone inverters.
- YOUR HELP is required if you have new Anker Solix systems or if new features are introduced by Anker and you want them being integrated into HA
- I have no chance to test any Anker devices or explore the cloud Api requests and responses for new devices or features. Since the Api is not official, no documentation exists and the Api library can only be enhanced with your support and willingness to explore and test the Api queries:
- via the Api library
- via the integration action Anker Solix Api request
- Enhancements may only be possible when exclusive owner access to the system is available.
- But since the system belongs to you and the Api usage is not officially supported, it is up to you to test and verify Api capabilities
Appreciation: β¨
If you like this integration and you want to show your appreciation for the countless hours spent to enhance and maintain it, I would be happy for a coffee.

Renewable Energy - Photovoltaics and Solar Energy
- Python
Published by thomluther 11 months ago
Anker Solix Integration for Home Assistant - 2.6.0
Solarbank AC enhancements and X1 monitoring support with release 2.6.0
Full support for Solarbank 2 AC models
The Anker Solix integration support has been further enhanced to fully support the Solarbank 2 AC models with additional control entities and Actions to modify the Usage Time plan, as well as the Backup plan. A weird Api behavior for the schedule management on the AC models is now also understood and the previous issue for controlling the output preset is now working also for the AC model. π
However, the AC still fails to post updates for all values in the cloud, which is assumed to be a firmware issue.
Initial monitoring support for X1 Home Energy Systems
The Anker Solix X1 residual storage system can now also be monitored by the integration. However, the known HES Api endpoints do not provide any power values as you can see them in real time on your App home screen. Most likely those real time values are merged from the MQTT cloud while the App home screen is open, but they are not posted to the power cloud. To have at least some average power metrics in HA, the last data points of the intraday energy statistics from the power cloud will be extracted every 5 minutes as average power (similar to the US Power Panel systems). However, that comes with a cost of cloud traffic. It appears the X1 systems also have a slow cloud post interval of 5 minutes, similar to Solarbank 2 and Power Panel systems. Therefore more actual values would not be available anyway in the power cloud.
New Action to execute Anker Solix Api queries directly via the HA integration
The Anker Solix Api is not documented at all and usage is completely unofficial and unsupported. To simplify exploration of Api capabilities for your systems and devices, you can now use Api calls directly in your HA developer tools Actions panel without coding knowledge that is required to use the Anker Solix Api python library.
Last but not least:
π The repository has beed added to HACS community store π
You can now find the Anker Solix integration when you search for Anker Solix in HACS and you can install it directly from your HACS store without adding it as custom repo. Your previous custom repo entry can be removed from your HACS settings.
Enhancements:
-
Support for SB2 AC Usage Time plan modifications #202
- More details for Usage Time plan control entities
- More details for Usage Time plan Action
- The Usage Time plan also has dependencies with your [system price tariff and currency settings](Toggling system price type or currency settings).
- Those are fully supported to ensure the cloud will have most relevant tariff and prices set depending on usage time plan availability and use
-
Support for SB2 AC backup charge modification via Action #202
- More details for new backup charge Action, that was already supported via control entities
-
Unknown SB2 charging status when battery is full #232
- @HA-Tom originally observed and reported this unknown charging status 5 for his SB2 system
- It appears to be used when the battery is fully charged and has been implemented as such
- I noticed this charging status code only once on my SB1 for a single cloud update interval, since the SB1 typically switches to the bypass charging status code once full
- Note: The SB2 AC models do not properly update their charging status to the cloud. They remain 0 most of the time which is typically the 'detection' status for other Solarbank models.
-
Add initial support for X1 systems #245
- More details are here
-
Add action to issue Api requests #240
- See Api request action usage details for exploring the Api capabilities of your systems and devices
-
Add diagnostic account sensors for last data refresh and details refresh #230
- Those new sensors are deactivated by default and can be enabled to get more insights about your hub data and details refresh intervals as well as durations
- For more details you can review the data refresh configuration options
-
Updated INFO and README documentation
- Markdown card for SB2 schedule has been updated to fully support schedule object structures, including the AC plans.
- Script code to adjust Solarbank 2 AC backup charge has been added
- Script code to adjust Solarbank 2 AC usage time plan has been added
-
Created an article to describe the device hierarchy and attributes that are used by the integration
- It also describes how you can access the device attributes in your Jinja templates
- The examples include obtaining the device serial number, model ID or the site ID of your power system and other device attributes as they can be utilized by integrations
Breaking changes:
-
The system sensors that count the various device types in the system are no longer created if they have a count of 0
- Since not many device types can be mixed in a system and their count changes barely, those 0 count sensors do not make much sense
-
New device pictures have been added to the images directory
- If you want to utilize them, you need to copy them manually after the integration update was installed (prior HA restart)
Fixes and other changes:
-
βDaily...β Sensors in the Anker βSystemβ do no longer update #234
- The new refresh staggering of multiple hub entries may cause details refresh to be delayed forever
- Staggering routine has been improved to avoid unnecessary delays and prioritize clients the are already delayed for device details polls
-
SB2 AC Feed-in specification not applied #212
- It was found to be an inconsistent use of the set_device_parm endpoint in the cloud
- The Solarbank AC systems require a weird object separation when the schedule plans are being applied
- Once unique AC plans are contained in the set schedule object, the common SB2 plans are being ignored by the cloud
- To modify common SB2 plans (manual plan and blend plan for smart plugs), the AC unique plans must be removed from the schedule object that will be set
-
Bumped anker-solix-api library to latest improvements
- Reuse intraday energy totals from average power queries for daily energy queries
- This reduces the amount of queries ran against the energy statistic endpoint
- Add time offset option to daily energy methods to provide better indication when full day data is recorded for proper date selection
- Add helper method to create, modify and clear elements and structures within the use_time plan
- This will provide full modification capabilities for the Solarbank 2 AC Usage Time plan
- Extending the solution to support Anker Solix X1 systems
- This provides initial support for monitoring the X1 systems (similar to Power Panel system capabilities)
- Fix modification of common SB2 schedule plans for AC models, like Output power preset in manual_plan or blend_plan.
- Reuse intraday energy totals from average power queries for daily energy queries
Full Changelog: https://github.com/thomluther/ha-anker-solix/compare/2.5.7...2.6.0
Link to previous release notes 2.5.7
Notes:
- The device sensor for battery energy is just a theoretical value and calculated by the Api library from nominal battery capacity and SOC. Changes of this entity should NOT be considered for energy dashboard helper sensors, since this sensor can never reflect the battery efficiency or capacity loss over time.
- The daily battery discharge statistic value for Solarbank 1 is no longer correct since mid June 2024. The cloud statistics changed this value when introducing support for Solarbank 2. The daily battery discharge value for Solarbank 1 now includes also bypassed PV energy, so it is not longer dedicated to battery discharge only. You can see this wrong value also in your Anker App statistics for the battery.
- For such and other reasons, I do NOT recommend to use the Anker Solix integration daily energy statistic sensors directly in your energy dashboard, even if that is possible since they are classified as total_increasing sensors. The reasons for that are described in the discussion how to integrate the Solarbank into you energy dashboard. There you can also find the recommended approach for creating the required entities for easiest and most flexible energy dashboard integration.
Contribution:
- YOUR HELP is required if you have new Anker Solix systems or if new features are introduced by Anker and you want them being integrated into HA
- I have no chance to test any Anker devices or explore the cloud Api requests and responses for new devices or features. Since the Api is not official, no documentation exists and the Api library can only be enhanced with your support and willingness to explore and test the Api queries:
- via the Api library
- via the integration action Anker Solix Api request
- Enhancements may only be possible when exclusive owner access to the system is available.
- But since the system belongs to you and the Api usage is not officially supported, it is up to you to test and verify Api capabilities
- A special thanks to @noseshimself for granting me temporary admin access to his AC system for testing and debugging the AC schedule modifications with the Usage Time plan, the Backup Charge plan and the output preset of the common manual plan.
Appreciation:
If you like this integration and you want to show your appreciation for the countless hours spent to enhance and maintain it, I would be happy for a coffee.

Renewable Energy - Photovoltaics and Solar Energy
- Python
Published by thomluther 12 months ago
Anker Solix Integration for Home Assistant - 2.5.7
More Api enhancements in release 2.5.7
With last release 2.5.5, a couple of Api enhancements has been implemented for better toleration of request errors on busy Api or too many requests. As I figured out, the enforced Anker Cloud endpoint limits may vary and be different for various endpoints. It appears the balcony power energy statistic endpoint is throttled most around 10 requests per IP and minute, while other energy statistic endpoints for Power Panels or Home Energy Systems like the X1 are not limited that much (yet).
To better align with the various endpoint request limits, the recently implemented request throttle is no longer active by default, but is now activated per endpoint once the first 429 Too Many Requests error is received. This will activate throttling and the delay loops for this endpoint for the remainder of the Api client session being active.
Changing the endpoint limit to 0 temporarily in the configuration options will now also reset the active endpoint throttles, similar to reloads of the configuration entry which is starting a new Api client.
Following warning will be logged upon first 429 error:
2025-03-16 17:18:57.109 INFO (MainThread) [custom_components.anker_solix] Api Coordinator tolu** is updating deferred energy data
2025-03-16 17:19:04.119 WARNING (MainThread) [custom_components.anker_solix] Api tolu** exceeded request limit with 13 known requests in last minute, throttle will be enabled for endpoint: power_service/v1/site/energy_analysis
2025-03-16 17:19:04.120 WARNING (MainThread) [custom_components.anker_solix] Throttling next request of api tolu** for 59.6 seconds to maintain request limit of 10 for endpoint power_service/v1/site/energy_analysis
Important:
I strongly recommend to exclude the balcony power energy categories from your Anker hub configuration if you want to avoid such request throttling delays that have been implemented to avoid exceeding the endpoint limit for larger or multiple systems configurations.
For more details on recently implemented Api improvements, please see 2.5.5 release notes.
Enhancements:
-
Relax endpoint throttling and activate it only for affected endpoints #227
-
Reduce energy endpoint queries for Power Panels and upcoming Home Energy Systems support
- Those systems do not seem to report live power data to the cloud and therefore require a work around to extract some recent average power data from the intraday energy statistics
- The initial queries have been significantly reduced which aim to find the lowest time offset until a new data point becomes available in the 5 minute intraday energy statistics
- The pretty large intraday statistics also contain the total energies of today. This data is now extracted as well for the daily energy values and therefore the queries for today's energies will now be skipped
-
In the background: Added an energy or cloud data time offset to the cached Api systems data
- This time offset is approximated by the energy data toggle from intraday energy queries (if used), or from the Solarbank data update timestamps in the cloud (although they also have a time shift to the energy data updates).
- This approximate offset will initially be used by the integration to indicate a proper day switch for cloud energy recording and correct start of polling the next day (date) from the cloud. Also the additional one time queries for the finished energy recording of previous day can now be done at correct day toggle in the cloud.
- Note: The finished previous day data was always recorded in the attributes of the daily energy sensors
- Knowing the cloud energy offset allows proper energy data polling even if your HA server instance is running with a different time zone than your Anker System that is typically time synchronized with the Anker cloud through your router.
- The approximate cloud time offset can further be used in future to anticipate the timezone offset between your HA server and the Anker System in the cloud. This will become important for improvement of schedule related entities, which currently require that your HA instance and all accessible Anker Power systems are using not only similar time, but also running in same timezone.
-
Implemented new one time query for currency list supported by the Anker Cloud.
- The listed currencies will be merged with hard coded currencies for currency selection entities
-
Updated INFO documentation for Api changes and configuration options.
Breaking changes:
None
Fixes and other changes:
-
Reactivation of Api refresh switch failed to perform an initial data poll and left entities unavailable until next detail refresh interval
- This error was introduced with the deferred energy data polls in 2.5.5 and has been fixed now
- The behavior will now be the same as during (re)load of the configuration and energy polling will be deferred after reactivation of the Api refresh switch until next update cycle
- This change ensures quick reactivation of all entities except the energy sensors
- Keep in mind that your energy entities are therefore delayed for at least one update cycle to become available again.
- If throttling delays must be applied, this may take even more minutes!
-
Power Panel average power queries have been driven much more often than necessary
- The initial sequence to find the smallest energy time offset was restarted after each details refresh cycle, causing by far too many unnecessary intraday requests with pretty large 50-100 KB data responses
- There have been also more requests than necessary in this initial sequence until the smallest offset was found. The data in the 4 various energy responses won't change until the toggle to next 5 minutes energy data point was identified. Therefore just a single energy request will now be used to identify the cloud data update toggle, which can also be applied for new data availability of the other energy types.
-
Bumped anker-solix-api library to latest improvements
- Removed query to list third party product devices since that is no longer providing data since 2025
- Device names of supported third party device models, such as the Shelly smart meters, are now used from hard coded names if not listed anywhere in the Api responses
- Added one time hes product list query since that may contain Anker products not listed in the other product list queries
- Updated export module to version 2.6.0
- Removed query to list third party product devices since that is no longer providing data since 2025
Full Changelog: https://github.com/thomluther/ha-anker-solix/compare/2.5.0...2.5.5
Link to previous release notes 2.5.5
Notes:
- The device sensor for battery energy is just a theoretical value and calculated by the Api library from nominal battery capacity and SOC. Changes of this entity should NOT be considered for energy dashboard helper sensors, since this sensor can never reflect the battery efficiency or capacity loss over time.
- The daily battery discharge statistic value for Solarbank 1 is no longer correct since mid June 2024. The cloud statistics changed this value when introducing support for Solarbank 2. The daily battery discharge value for Solarbank 1 now includes also bypassed PV energy, so it is not longer dedicated to battery discharge only. You can see this wrong value also in your Anker App statistics for the battery.
- For such and other reasons, I do NOT recommend to use the Anker Solix integration daily energy statistic sensors directly in your energy dashboard, even if that is possible since they are classified as total_increasing sensors. The reasons for that are described in the discussion how to integrate the Solarbank into you energy dashboard. There you can also find the recommended approach for creating the required entities for easiest and most flexible energy dashboard integration.
Contribution:
- YOUR HELP is required if you have new Anker Solix systems or if new features are introduced by Anker and you want them being integrated into HA
- I have no chance to test any Anker devices or explore the cloud Api requests and responses for new devices or features. Since the Api is not official, no documentation exists and the Api library can only be enhanced with your support and willingness to explore and test the Api queries via the Api library.
Appreciation:
If you like this integration and you want to show your appreciation for the countless hours spent to enhance and maintain it, I would be happy for a coffee.

Renewable Energy - Photovoltaics and Solar Energy
- Python
Published by thomluther about 1 year ago
Anker Solix Integration for Home Assistant - 2.5.5
Maintenance Release 2.5.5 to reduce Api errors
You may have noticed in the Anker mobile App, that energy charts may no longer display after watching about 10 different charts quickly. This is not a cloud problem, but related to the fact that Anker reduced their Cloud Api endpoint limit from about 25 requests down to 10-12 requests per ~minute per IP address. This may result in request errors in the integration, especially if you include energy categories in your Anker hub configuration options similar to following example:
2025-02-28 16:54:34.343 ERROR (MainThread) [custom_components.anker_solix] Api Request Error: 429, message='Too Many Requests', url='https://ankerpower-api-eu.anker.com/power_service/v1/site/energy_analysis'
2025-02-28 16:54:34.344 ERROR (MainThread) [custom_components.anker_solix] Response Text: {"error_msg":"Request too soon. Your actions have been recorded."}
Furthermore there may be request errors when you configured more than one Anker Solix hub account (or use the Anker App in parallel) for any endpoint in case multiple requests are done in parallel to the cloud Api from the same IP address, even if the requests are for different accounts or systems. This is logged with error code 21105 as following:
[custom_components.anker_solix] (21105) Anker Api Error: Failed to request. 2024-09-26 08:59:39.442 ERROR (MainThread) [custom_components.anker_solix] Response Text: {"code":21105,"msg":"Failed to request.","trace_id":"<trace_id>"}
This typically may result that entities become temporarily unavailable, or even cause the configuration (re)load to fail.
This release contains some changes and enhancements to the Api session and the integration data poller to address these issues.
Please review them carefully along the breaking changes to understand what impact this change may have to your setup.
Important:
I strongly recommend to exclude the energy categories from your Anker hub configuration if you want to avoid such request errors or the new throttling delays that have been implemented to avoid exceeding the endpoint limit for larger or multiple systems configurations.
Enhancements:
-
Add daily energy stats for SB2 AC external inverter input #215
- The external inverter input for SB2 AC models is considered as additional PV input channel for the system when collecting solar energy
- This new metric requires an additional request to the energy stats (yet one more...), similar to each other PV channel
- A new daily energy sensor for micro inverter 'solar channel' was added for the SB2 AC device types to show this value
-
Allow a query retry upon request errors that may occur when multiple clients communicate in parallel
- The Anker cloud accepts only one request per IP address at any given point in time
- If you have multiple Anker configuration entries, there is no request serialization across the various client sessions
- Also using the App in parallel can cause issuing queries in parallel, which may result in a request error with code 21105
- A single request retry capability was added to the client session for Api return codes that can be classified as Api busy error
- The specific request error code 21105 is now considered as Api busy error and a single retry will be attempted after random delay between 2-5 seconds
- A warning will be logged for each busy error and retried request to allow monitoring how often this may occur in your setup
- If that occurs too often or retries will also fail, you will have to reduce parallel usage of Api clients in your setup
- Multiple Anker Systems can be shared with a single account and typically you need to add only 1 Anker Hub configuration, which will serialize all its requests with the specified request delay in your configuration entry options.
-
Add request endpoint throttling capability #209
- Anker reduced the endpoint request limit per ~minute from ~25 requests down to ~10-12 requests per IP address
- This may cause that you now see more often a 'Too many requests' error from the Api #214
- The Api client session now applies a default throttle of 10 requests per endpoint per minute
- The limit can be changed to any positive number, 0 will disable the throttling
- When the throttling is being used, following warning will be logged:
2025-02-28 16:49:18.726 WARNING (MainThread) [custom_components.anker_solix] Throttling next request for 59.9 seconds to maintain request limit of 10 for endpoint power_service/v1/site/energy_analysis- IMPORTANT: The client session cannot know which other clients (App, other sessions) consumed already endpoint requests within last minute for the same IP address. Therefore the throttle works only reliably for a single client session to the Anker cloud. If you run parallel client sessions, you can reduce the throttle limit by half for each session to avoid exceeding the limit.
-
Added re-authentication flow to configuration entries
- This should assist in flagging any authentication issues in the affected configuration entry and track this as problem in HA
- Users can then re-authenticate with existing credentials or change them as during the reconfiguration dialog
- This allows to restart a new Api client session if the previous session stopped due to authentication errors of active session that could not be resolved automatically by a single re-authentication attempt
- The existing credentials are still usable if you did not change your password, but you may have to confirm it to re-start a new client session because a parallel connection with the same account may have kicked out the active session repetitively while trying to re-authenticate.
-
Updated INFO documentation for Api changes and configuration options and README for known SB2 AC issues when using the integration.
Breaking changes:
- Due to unforeseeable throttling requirements, site updates and device details updates may take much longer than previously.
- If you have only a single system with few energy entities, you should not notice any difference in data refresh duration
- The setup or (re)load of a configuration entry drives most queries, but is required to create all entities for your setup
- Especially the energy details update runs multiple queries against same endpoint and is highly affected by throttling requirements.
- Therefore the initial energy data poll is now deferred to next update cycle, which will cause that all energy related entities will no longer be created immediately. The will be (re)created with a delay of 1 or more minutes!
- Try to avoid running energy details updates or other methods that must run against the energy statistical endpoints too often to avoid running into the endpoint throttling, that must delay next endpoint request for up to 1 minute to stay below the endpoint limit
Fixes and other changes:
-
Reduce blocking period of Api cache while running a Systems Export action
- An Api export can take from few seconds to multiple minutes, depending on the throttling loops that must be applied for various energy statistic exports
- With a previous fix the Api cache was marked invalid for the whole export duration, which may cause other queries to delay or not work.
- With this release, the Api is marked invalid only a short amount of time when the exported files are parsed to create the randomized Api cache files.
- Other Api requests are now safely delayed while the cache is invalid, to avoid those Api calls will act on invalid cache data.
-
Avoid HA code warning about non existing via_device when setting up platform entities #220
- A core change now requires that a specified via_device already exists when a device is being registered
- So far, the integration registered the devices only with the entity platform setup
- Since the device types of your account can vary, it could happen that a device was registered before its via_device was registered
- A change was implemented to register all devices upfront with the first entity platform setup to avoid this new core warning
-
Bumped anker-solix-api library to v2.5.5
-
Bump ruff from 0.9.9 to 0.9.10 by dependabot in #223
-
Bump ruff from 0.9.7 to 0.9.9 by dependabot in #216
-
Bump ruff from 0.9.6 to 0.9.7 by dependabot in #210
-
Bump ruff from 0.9.5 to 0.9.6 by dependabot in #205
Full Changelog: https://github.com/thomluther/ha-anker-solix/compare/2.5.0...2.5.5
Link to previous release notes 2.5.0
Notes:
- The device sensor for battery energy is just a theoretical value and calculated by the Api library from nominal battery capacity and SOC. Changes of this entity should NOT be considered for energy dashboard helper sensors, since this sensor can never reflect the battery efficiency or capacity loss over time.
- The daily battery discharge statistic value for Solarbank 1 is no longer correct since mid June 2024. The cloud statistics changed this value when introducing support for Solarbank 2. The daily battery discharge value for Solarbank 1 now includes also bypassed PV energy, so it is not longer dedicated to battery discharge only. You can see this wrong value also in your Anker App statistics for the battery.
- For such and other reasons, I do NOT recommend to use the Anker Solix integration daily energy statistic sensors directly in your energy dashboard, even if that is possible since they are classified as total_increasing sensors. The reasons for that are described in the discussion how to integrate the Solarbank into you energy dashboard. There you can also find the recommended approach for creating the required entities for easiest and most flexible energy dashboard integration.
Contribution:
- YOUR HELP is required if you have new Anker Solix systems or if new features are introduced by Anker and you want them being integrated into HA
- I have no chance to test any Anker devices or explore the cloud Api requests and responses for new devices or features. Since the Api is not official, no documentation exists and the Api library can only be enhanced with your support and willingness to explore and test the Api queries via the Api library.
Appreciation:
If you like this integration and you want to show your appreciation for the countless hours spent to enhance and maintain it, I would be happy for a coffee.

Renewable Energy - Photovoltaics and Solar Energy
- Python
Published by thomluther about 1 year ago
Anker Solix Integration for Home Assistant - 2.5.0
Exiting new Release 2.5.0 with experimental Solarbank 2 AC support and important fixes and improvements
Enhancements:
-
Add support for new Solarbank 2 AC model #175 #198
- Support modifications of Manual Backup settings
- Note: NO SUPPORT yet for modifying the use time plan
- Note: NO SUPPORT yet for modifying the use time plan
- Support for switching to Manual Backup mode and Usage Time mode (if a Use Time plan was defined in the Anker App)
- When backup mode is enabled via Mode setting or backup option switch, a default of 3 hour backup charge will be applied by the Api library starting from now.
- This is a convenience setting to apply meaningful datetime values when the mode is 'enabled' by a toggle entity
- 3 hours with 1000-1200 W AC charge should be sufficient to load an empty Solarbank with 1 battery pack from 10 to 100 % SOC
- You can always customize the backup end time and apply the change by re-enabling the backup option switch
- Please give some feedback how your typical backup duration would be, and whether the default should be changed
- The backup mode will be deactivated automatically at 100% SOC
- Note that each datetime change will deactivate also the backup option switch, but those changes occur only in Api cache to avoid too many Api calls. Only when the backup option switch is re-enabled, the Api call will be made to apply the datetime settings from the cache.
- Support for switching the system price between fixed price and Use Time price (if Use Time plan was defined in the Anker App)
- Note: Use Time price will be enabled automatically when Use Time mode is being enabled like it is done by the Anker App. Toggling back to fixed price setting must be done manually.
- Note: Use Time price will be enabled automatically when Use Time mode is being enabled like it is done by the Anker App. Toggling back to fixed price setting must be done manually.
- Additional sensors, most are specific to AC model
- Note the separate heating power, which seems to be reported and does not longer reduce the reported solar power
- The Solar power is the combination of all inputs, the 2 PV channels as well as the external inverter power input (if used)
- Notes:
- These new controls will only become available when the owner account is used
- It is not determined yet, if all new fields are fully used, and what exactly the values will represent. Usage may also depend on the firmware,
- The inverter power seems to be accumulated with PV1 and PV2 into Solar power. Therefore it is assumed this it NOT the internal inverter power, but the external inverter that optionally can be plugged into the AC model as additional PV source.
- The grid to battery power should reflect AC charge
- The grid to battery daily energy was also added to the system energy entities #199
- Updated Solarbank 2 markdown card to support displaying the new AC plan types.
- See INFO documentation for more details on using the new Solarbank 2 AC controls in HA
- Support modifications of Manual Backup settings
-
IMPORTANT:
- The controls will represent the active settings according to HA system time and schedule plan defined times. Therefore any time offset between your Solarbank and HA server will cause incorrect active setting extracts from the schedule
- While you make any change to the usage mode or presets, it may take up to 5-6 minutes in worst case until you see this reflected in other Integration values, because the SB2 sends updated data only every 5 minutes. It is just a reporting delay, but the change is typically applied immediately. See #194 for how this delay can impact the monitoring of an output preset change.
-
Added new system sensors for Off Grid Alert, Inverter Limit Exceeded, Heating #187 and Active Usage Mode as reported by the Solarbank 2
- Those sensors are also visible as system member, but only if used by the specific system type
- Those sensors are also visible as system member, but only if used by the specific system type
-
Important changes and fixes to support combined Solarbank 2 and Solarbank 1 systems #181
- While Anker supports now 1-2 SB1 in a Solarbank 2 Pro/Plus system, they do not correctly adopt the statistics and system totals.
- See the README documentation for incorrect system values from the cloud and how the Api library corrects them for correct reporting in the HA integration via the System SB total values
-
Important changes and fixes for Power Panel support #183
- It was found that upon cloud problems/errors, there may be statistical records showing 0% SOC in intraday stats.
- These are also visible in the Anker App SOC diagram
- All Power Panel 5 minute average values are extracted from the intraday stats, using the last valid, non 0 SOC entry as indication for the minimum offset into the stats to extract all other values.
- So far, this last valid timestamp lookup happened from past into future to find first 'invalid' 0 SOC entry, not considering that there might be any 0 entry gaps. This led to wrong offset calculations and extraction of incorrect timestamps.
- The lookup algorithm was changed to search from the future back to the first timestamp showing anything different from 0 SOC as last valid entry.
- The algorithm was also improved to re-adjust if a newer valid timestamp is found at regular queries that shows less offset to actual time.
- This automatically reduces the reporting delay as much as possible, but especially in case the integration queries were started while there are no cloud stat recordings being made (during a recording gap).
- It was found that upon cloud problems/errors, there may be statistical records showing 0% SOC in intraday stats.
-
Added documentation for combined system usage and new SB2 AC controls
-
Added table of contents to the documentation and further video and blog resources to the README
Breaking changes:
- Renamed translations for system price sensor to distinguish the existing fixed price entity from another entity that will be introduced to reflect the active dynamic price as defined in the Solarbank 2 AC Use Time plan.
- The translation change will also rename your price entity_id when the integration is reconfigured or devices must be re-registered. The previous entity history will NOT be maintained
- Due to security alerts, the minimum aiohttp version was bumped to 3.10.11
- Home Assistant bumped this version with 2024.11.2, which has been set as new minimum release for this integration
- For combined SB2 systems containing also SB1, the system battery power entity cannot longer be used to extract the total charge or discharge power. The reason and recommended method to generate total charge/discharge entities for energy dashboard integration is described in the README.
Fixes and other changes:
- Prevent that Api export action can be triggered again while still active
- An Api export can take 5-30 seconds, depending on how the configuration entry Api options have been defined
- Especially via UI it happened that users clicked the Run Action button more than once without waiting that previous export has been finished (The button will become green only once the started action finished)
- Multiple parallel exports cause corrupted data sets that does not really match together due to various serial randomization
- It will also kick off a mass of unnecessary duplicate Api queries
- An error will now be raised when the action is triggered by automation or UI while an export is still active via the Api switch entity
- This prevents that multiple clicks on the Run Action button kick off more than one single export.
- Prevent that control entities, when changed via UI or automation, may trigger value updates or Api queries while they are unavailable
- Note: The UI may present unavailable control entities in a weird display format. Especially number sliders may show the middle value of an allowed range while unavailable, They also appear to allow value changes, although no value is actually present for the number entity.
- Fixed unexpected value clearance for SOC reserve setting entity
- Fixed and improved handling of index numbers in schedule plans
- Gaps in schedule index numbers caused index out of bound errors and therefore plan updates failed, e.g. when changing output preset
- Index numbers will now be curated automatically when schedule plans are modified #195
- Fixed some translation errors
- Bumped anker-solix-api library to v2.5.1
- Bump actions/setup-python from 5.3.0 to 5.4.0 by @dependabot in #196
- Update pip requirement from <24.4,>=21.0 to >=21.0,<25.1 by @dependabot in #192
- Bump softprops/action-gh-release from 2.2.0 to 2.2.1 by @dependabot in #186
- Bump ruff from 0.9.4 to 0.9.5 by @dependabot in #201
- Bump ruff from 0.9.3 to 0.9.4 by @dependabot in #197
- Bump ruff from 0.9.2 to 0.9.3 by @dependabot in #191
- Bump ruff from 0.9.1 to 0.9.2 by @dependabot in #188
- Bump ruff from 0.8.6 to 0.9.1 by @dependabot in #185
- Bump ruff from 0.8.5 to 0.8.6 by @dependabot in #180
Full Changelog: https://github.com/thomluther/ha-anker-solix/compare/2.4.0...2.5.0
Link to previous release notes 2.4.1 and 2.4.0
Notes:
- The device sensor for battery energy is just a theoretical value and calculated by the Api library from nominal battery capacity and SOC. Changes of this entity should NOT be considered for energy dashboard helper sensors, since this sensor can never reflect the battery efficiency or capacity loss over time.
- The daily battery discharge statistic value for Solarbank 1 is no longer correct since mid June 2024. The cloud statistics changed this value when introducing support for Solarbank 2. The daily battery discharge value for Solarbank 1 now includes also bypassed PV energy, so it is not longer dedicated to battery discharge only. You can see this wrong value also in your Anker App statistics for the battery.
- For such and other reasons, I do NOT recommend to use the Anker Solix integration daily energy statistic sensors directly in your energy dashboard, even if that is possible since they are classified as total_increasing sensors. The reasons for that are described in the discussion how to integrate the Solarbank into you energy dashboard. There you can also find the recommended approach for creating the required entities for easiest and most flexible energy dashboard integration.
Contribution:
- Many thanks to @thealkly for his blog post (DE) and new video (DE) about the Anker Solarbank usage and HA integration. The links have been added to the README.
- YOUR HELP is required if you have new Anker Solix systems or if new features are introduced by Anker and you want them being integrated into HA
- I have no chance to test any Anker devices or explore the cloud Api requests and responses for new devices or features. Since the Api is not official, no documentation exists and the Api library can only be enhanced with your support and willingness to explore and test the Api queries via the Api library.
Appreciation:
If you like this integration and you want to show your appreciation for the countless hours spent to enhance and maintain it, I would be happy for a coffee.

Renewable Energy - Photovoltaics and Solar Energy
- Python
Published by thomluther about 1 year ago
Anker Solix Integration for Home Assistant - 2.4.1
New Release 2.4.1 with minor fixes for 2.4.0
Enhancements:
None
See 2.4.0 release notes for all enhancement details
Breaking changes:
None
Fixes and other changes:
- Update INFO Documentation to latest changes and enhancements
- Fix some German translations
- Fix proper version display for integration
- Bump ruff from 0.8.4 to 0.8.6 by @dependabot in https://github.com/thomluther/ha-anker-solix/pull/180
Full Changelog: https://github.com/thomluther/ha-anker-solix/compare/2.4.0...2.4.1
Link to previous release notes 2.4.0
Renewable Energy - Photovoltaics and Solar Energy
- Python
Published by thomluther about 1 year ago
Anker Solix Integration for Home Assistant - 2.4.0
New Release 2.4.0 with a few enhancements
Enhancements:
-
Add support for new Solarbank discharge priority switch #173
- This new switch entity will only become available when the owner account is used and all Solarbank 1 devices in the system are on required FW level 2.0.9 or higher to support this new feature
- Anker App 3.3.2 or later is required to modify this new setting via the Anker App
- The switch entity will represent the actual discharge priority setting according to the active schedule time slot settings. Any change of the entity will update the schedule accordingly for the current time slot
-
The solarbank schedule actions have been updated to support the optional discharge priority switch setting as well
- Like other Solarbank 1 time slot fields, the new discharge priority field is optional
- Per default the discharge priority will be disabled if a new time slot is being created/added
- Existing slot settings will be re-used if the option is not specified
- The given discharge priority option will be ignored if the setting is not supported yet by the system
-
INFO Documentation was changed to provide updated script examples for Solarbank 1 schedule modifications and for mark down cards showing the Solarbank 1 schedules with this additional setting option
Breaking changes:
None
Fixes and other changes:
- Entity registrations not being updated after re-enabling Api refresh switch #172
- Previously, when the owner account was used in the integration and the Api refresh switch was temporarily disabled to use the same account for activities in the Anker App, the reactivation of the Api refresh switch did not clear the Api cache or register any new entities, which may have been configured via the Anker App meanwhile
- A manual reload of the integration entry was needed to refresh the cache and register any new entities for the account connection.
- Starting with 2.4.0, the reactivation of the Api refresh switch will behave similar to an integration entry reload action.
- Any removed or renamed devices or systems will be recognized and declared as removed entities, new entities will be created as found for the account.
- This change prevents seeing active but stale/obsolete entities in case system or device reconfiguration has been made via the App while the HA integration entry was not being reloaded
- That means you can now also briefly disable and re-enable the Api refresh switch to trigger a complete refresh for your account systems and devices and update the available entities accordingly.
- Attention: The refresh after switch activation may run a couple of seconds and needs to process all initial Api queries to scan your Anker cloud account. Do not use the switch toggle repetitively in short time periods.
- Fix deprecated warning for setting option flow config_entry explicitly #164
- config_entry will only be set explicitly if HA version < 2024.11.99
- Bump ruff from 0.7.4 to 0.8.0 by @dependabot in https://github.com/thomluther/ha-anker-solix/pull/170
- Bump ruff from 0.8.0 to 0.8.1 by @dependabot in https://github.com/thomluther/ha-anker-solix/pull/171
- Bump ruff from 0.8.1 to 0.8.2 by @dependabot in https://github.com/thomluther/ha-anker-solix/pull/174
- Bump softprops/action-gh-release from 2.1.0 to 2.2.0 by @dependabot in https://github.com/thomluther/ha-anker-solix/pull/176
- Bump ruff from 0.8.2 to 0.8.3 by @dependabot in https://github.com/thomluther/ha-anker-solix/pull/177
- Bump ruff from 0.8.3 to 0.8.4 by @dependabot in https://github.com/thomluther/ha-anker-solix/pull/178
Full Changelog: https://github.com/thomluther/ha-anker-solix/compare/2.3.0...2.4.0
Link to previous release notes 2.3.0
Notes:
- The daily battery discharge statistic value for Solarbank 1 is no longer correct since mid June 2024. The cloud statistics changed this value when introducing support for Solarbank 2. The daily battery discharge value for Solarbank 1 now includes also bypassed PV energy, so it is not longer dedicated to battery discharge only. You can see this wrong value also in your Anker App statistics for the battery.
- The device sensor for battery energy is just a theoretical value and calculated by the Api library from nominal battery capacity and SOC. Changes of this entity should NOT be considered for energy dashboard helper sensors, since this sensor can never reflect the battery efficiency or loss of capacity over time.
- For such and other reasons, I do NOT recommend to use the Anker Solix integration daily energy statistic sensors directly in your energy dashboard, even if that is possible since they are classified as total_increasing sensors. The reasons for that are described in the discussion how to integrate the solarbank into you energy dashboard. There you can also find the recommended approach for creating the required entities for easiest and most flexible energy dashboard integration.
Contribution:
- YOUR HELP is required if you have new Anker Solix systems or if new features are introduced by Anker and you want them being integrated into HA
- I have no chance to test any Anker devices or explore the cloud Api requests and responses for new devices or features. Since the Api is not official, no documentation exists and the Api library can only be enhanced with your support and willingness to explore and test the Api queries via the Api library.
Appreciation:
If you like this integration and you want to show your appreciation for the countless hours spent to enhance and maintain it, I would be happy for a coffee.

Renewable Energy - Photovoltaics and Solar Energy
- Python
Published by thomluther about 1 year ago
Anker Solix Integration for Home Assistant - 2.3.0
New Release 2.3.0 with a couple of exciting enhancements
Enhancements:
-
Restructured the device model topology for an Anker hub representation #141
- So far, only defined power systems and connected end devices accessible by the configured hub account have been structured into device types by the integration
- This had the disadvantage, that common account related entities had no direct owning device type, but where duplicated under each system accessible by the account
- Also stand alone Solix devices had no direct home
- For users with multiple hub entries or multiple systems per account, the Anker cloud topology could not be properly reflected in HA
- Therefore a new device type (Model) for the hub account was implemented
- The account device manages all system devices (power sites) where your account has access to
- Solix devices which are assigned to a system continue to be owned by the system device
- Solix devices which are not assigned to a system (stand alone devices), are now owned by the new account device.
- This allows to recognize by which of the hub entries the stand alone device is managed
- Note: Keep in mind that stand alone Solix devices do not provide any utilization data to the cloud and have barely entities that can be monitored or managed via cloud Api
- So far, only defined power systems and connected end devices accessible by the configured hub account have been structured into device types by the integration
-
Improved device information
- Added proper device name in end device info if name is not available from standard Api responses
- Added system type description, derived from main device type category that is configured into a power system
- Added email, api server and alias name to the account model
- Account related entities have been moved to the account device
- Their entity name will now contain your account alias and country code
-
Added partial support for Power Panel systems as supported in US marked (not supported on EU cloud server)
- Added support for daily energy statistic entities
- Added support for system total metrics, which must be queried from another Api endpoint specific for power panels
- Added work around to extract last 5 min average power and SOC values from today's energy statistics for the Power Panel device
- This is the only power information that was found in the cloud so far.
- The value is lagging 5-8 minutes behind and is the 5 min average power only
- Consider it as the last data point that becomes visible in your mobile app diagrams for today. The data time stamp is provided as well
-
Changed service description structure to match new schema #139
- New schema was introduced with HA core 2024.9.0, which became new minimum version for the integration
- Structured the various options of some actions into sections with descriptions where this makes sense
- This only affects the action representation in UI mode usage
- Introduced section icons
-
Added a new option to the get system info action to allow merge of additional system data from Api cache with the new response of the scen_info request
-
Picked up enhancements from Api library v2.3.0
- Added Api request metrics to Api refresh switch entity attributes
- Added OTA component info to attributes of OTA update binary sensor
- The children field will contain a list with a dictionary for each component
- The children field will contain a list with a dictionary for each component
- Added new Solarbank 2 entity for heating power
- This is still experimental, since it is a new field introduced along the support of new Solarbank 2 AC
- It is not clear if and how the heating power will be reported to the cloud, and if all Solarbank 2 types will support this upon certain firmware levels
- If you start seeing heating power in the Anker mobile app, there are good chances that the heating power will be reflected in HA as well
- Added Solarbank charging status description for new code 116, which seems to be used instead of code 4 (wakeup)
- Since this seems to be used only at cold temperatures, it will be named cold_wakeup
- Since this seems to be used only at cold temperatures, it will be named cold_wakeup
- Added Api request metrics to Api refresh switch entity attributes
-
Bumped Api export tool to 2.3.0.0
Breaking changes:
- Moved following entities due to device topology change
- binary_sensor for unread messages of the account moved from system to new account device to avoid duplication
- switch for Api refresh moved from system to new account device to avoid duplication
- Changed target entity for Export Systems action (service) due to device topology change
- Since everything for your account will be exported by this service, it does not make sense to select a dedicated system entity for the export
- The target for the action now requires the single Api refresh switch entity of the new account device type
- Renamed some daily energy sensors to support a broader spectrum of Anker Solix devices and avoid confusion in the naming
- "Daily AC to home" => "Daily battery home"
- This should typically be the AC energy delivered to the house from the battery
- "Daily grid import" => "Daily grid home"
- Former "Daily grid import" naming must be used for the combination of grid charging energy and grid home usage energy.
- Note: For Solarbank systems, it is not clear yet whether the new AC model will distinguish between grid home and grid charging energy, and what the meaning of the existing grid import energy value will become. For now it is assumed this is the grid home energy
- "Daily AC to home" => "Daily battery home"
- Attention:
- Renamed entities means that you will see orphaned entities after the update.
- Also their history may be lost, since their unique ID may had to be changed as well
- Recommendation: You can reconfigure your Hub entries to clear orphaned entities automatically instead of removing them manually
- When reconfirming your account access, all devices and entities will be unregistered and recreated with the new names
- Orphaned entities will be removed automatically
- Note: Any entities that have been manually deactivated will become active again. In other words they will be recreated based on actual exclusion categories and default activation setting.
- You need to modify the moved entity names in your dashboard, automations, scripts and helpers if you used any of them
- Renamed entities means that you will see orphaned entities after the update.
- New device pictures have been added.
- Optionally update the device pictures for your entities if you want to make use of them.
- You can copy the new images folder after integration update and prior HA restart by using a File Explorer add on
- See the description in the update procedure.
- Make sure to reload your HA dashboard without cache after HA restart to ensure the new images will be utilized in the UI frontend
- Increased minimum HA version to 2024.9.0 to support changed service schema descriptions and sections
Fixes and other changes:
- Block actions when Api usage is deactivated by the switch entity #163
- Previously, when an action was run while the Api usage was deactivated for temporary account usage on another device, the action could have kicked out the account on the other device
- Bump api library to 2.3.0
- Bump ruff from 0.7.1 to 0.7.2 #156
- Bump ruff from 0.7.2 to 0.7.4 #167
- Bump colorlog from 6.7.0 to 6.9.0 #155
- Bump softprops/action-gh-release from 2.0.8 to 2.0.9 #157
- Bump softprops/action-gh-release from 2.0.9 to 2.1.0 #166
Notes:
- The daily battery discharge statistic value for Solarbank 1 is no longer correct since mid June 2024. The cloud statistics changed this value when introducing support for Solarbank 2. The daily battery discharge value for Solarbank 1 now includes also bypassed PV energy, so it is not longer dedicated to battery discharge only. You can see this wrong value also in your Anker App statistics for the battery.
- The device sensor for battery energy is just a theoretical value and calculated by the Api library from nominal battery capacity and SOC. Changes of this entity should NOT be considered for energy dashboard helper sensors, since this sensor can never reflect the battery efficiency or loss of capacity over time.
- For such and other reasons, I do NOT recommend to use the Anker Solix integration daily energy statistic sensors directly in your energy dashboard, even if that is possible since they are classified as total_increasing sensors. The reasons for that are described in the discussion how to integrate the solarbank into you energy dashboard. There you can also find the recommended approach for creating the required entities for easiest and most flexible energy dashboard integration.
Contribution:
- YOUR HELP is required if you have new Anker Solix systems or if new features are introduced by Anker and you want them being integrated into HA
- I have no chance to test any Anker devices or explore the cloud Api requests and responses for new devices or features. Since the Api is not official, no documentation exists and the Api library can only be enhanced with your support and willingness to explore and test the Api queries via the Api library.
Appreciation:
If you like this integration and you want to show your appreciation for the countless hours spent to enhance and maintain it, I would be happy for a coffee.

Renewable Energy - Photovoltaics and Solar Energy
- Python
Published by thomluther over 1 year ago
Anker Solix Integration for Home Assistant - 2.2.0
New Release 2.2.0 with a lot of enhancements
Breaking changes:
-
Adopted use of new device model ID in device description Info
- Was introduced in HA 2024.8.0 which is the new minimum version for the integration
- See HA developer blog Model ID attribute for Device Info
-
New device pictures have been added.
- Optionally update the device pictures for your entities if you want to make use of them.
- You can copy the new images folder after integration update and prior HA restart by using a File Explorer add on
- See the description in the update procedure.
- Make sure to reload your HA dashboard without cache after HA restart to ensure the new images will be utilized in the UI frontend
Enhancements:
-
Added support for Shelly smart meter 3EM and 3EM Pro when they are configured in a power system with Solarbank 2, #152
- The reported entities and values are similar to how the Anker Smart meter entities are provided
- When a Shelly smart meter is configured into the power system and the Integration is using the system owner account, the smart meter usage mode can now also be configured in the integration
- Thanks to @koehntopp for providing exports and confirming functionality
-
Added support for Anker Smart plugs when they are configured in a power system with Solarbank 2. #149
-
The smart plug total power and energy will be provided as system entities
-
The other load power in the system entities reflects the added output power during smart plug usage mode according to the blend plan settings in the schedule
-
Individual plug power and energy entities will be provided along other standard device entities
-
The smart plug mode can be set in the solarbank 2 usage mode entity when using a system owner account in the integration and smart plugs are configured in the system
-
Thanks to @rwe87 and @steghoja for providing required system exports and confirming usage of blend plan for smart plugs
-
The device entity for system output power preset will change the additional load in the blend plan of the schedule that will be added immediately to the measured smart plug total power when the smart plug usage mode is active. If the smart plug usage mode is not active, this entity will modify the actual manual system output preset in the custom rate plan as previously. The manual system output preset however is only applied when manual usage mode is active or smart meter mode is active but smart meter has lost connection to the solarbank.
-
NOTE: Individual smart plug settings have not been discovered yet in the cloud api. YOUR HELP is needed if you have such devices and you are willing to explore existing or new queries and parameters to identify additional smart plug information or setting capabilities.
-
-
Added support to modify the blend plan in the solarbank 2 schedule (this plan is used for smart plug usage mode)
- All schedule based actions (services) have been updated with an additional option of the plan that should be modified with the action
- If no plan is provided with the action options, the active plan according to the active usage mode will be modified.
-
Picked up enhancements from Api library for new rssi field of devices and proper allocation of signal strength to individual devices
- Previous devices typically reported the Wifi signal strength in %, but newer devices did not report that at all. Furthermore the signals could not be allocated to a specific device.
- The wifi_list query now returns also rssi values for newer devices that are supporting it. Furthermore it reports the signal values per device SN, which allows proper signal allocation per device
- Although the rssi value is typically a relative index value, the Anker cloud seems to report a negative absolute value which typically is the signal dBm
- The api library uses the rssi dBm value to calculate the signal strength % if not provided by the device, where higher dBm values mean better signal strength
- Following range is considered for the calculation: Between -50 dBm (100 %) and -85 dBm (0 %)
- The rssi information was added as further attribute to the Wifi entity
- The additional information and proper allocation per device now allow better tracking of Wifi signal strength in the Integration
-
Reintroduced OTA update binary sensor with enhancements from Api library for new ota_batch query
- This query seems to provide latest available OTA versions for a list of provided devices
- It also contains children structures (like for Solarbank battery packs), however the possible response structures are not fully understood yet, so proper OTA version parsing is very limited
- The available OTA version will be listed in the OTA update entity attributes
- YOUR HELP is required to provide system exports when your main or sub devices are showing available updates.
- The more examples can be provided, the better the response accuracy and structures can be validated for proper information parsing.
- You can upload valuable exports as system owner to the Api library issue 138.
-
Updated script to modify solarbank 2 schedule and added the new plan option.
-
Updated dashboard markdown card to display solarbank 2 schedule
- Now includes the blend plan if defined
- The active slot in currently used plan is highlighted appropriately
-
Updated README and INFO with new device support and related information of this release.
-
Bumped Api export tool to 2.2.1.0 with additional queries and new endpoint categories for the system export action
- Added ota_batch query to get available OTA versions for a list of devices
- Removed previous OTA queries since they did not work for every device
- Added queries for charging_service endpoints as used for Power Panel sites (currently not supported in EU market or cloud Api servers)
- Added queries for hes_svc_charging_service endpoints as used for Home Energy Systems like X1
- The new endpoint categories will be processed only if corresponding power site types are found for the account
- NOTE: The endpoints may not be supported on every cloud server or may require additional parameters that are unknown at this point and therefore trigger request errors in the logs during the export action
- YOUR HELP is required if you have such new systems and you are willing to explore those new queries and parameters to enhance product support of the underlying Api library.
Fixes and other changes:
- Removed device label sensor when devices not really using it #151
- Currently only the smart plugs are using labels (tags)
- Device label entities can still be generally excluded from the integration by the options of your configuration entry
- Note: You may have to remove the unused label entity manually after integration update. Optionally you can reconfigure and just confirm your integration account to have all device entities unregistered and recreated.
- Bump api library to 2.2.1 #137
- Bump ruff from 0.6.5 to 0.6.7 #128
- Bump ruff from 0.6.7 to 0.6.8 #131
- Bump ruff from 0.6.8 to 0.6.9 #133
- Bump ruff from 0.6.9 to 0.7.0 #142
- Bump ruff from 0.7.0 to 0.7.1 #147
- Bump actions/checkout from 4.2.0 to 4.2.1 #131
- Bump actions/checkout from 4.2.1 to 4.2.2 #144
- Bump actions/setup-python from 5.2.0 to 5.3.0 #145
- Update pip requirement from <24.3,>=21.0 to >=21.0,<24.4 #146
Notes:
- The daily battery discharge statistic value for Solarbank 1 is no longer correct since mid June 2024. The cloud statistics changed this value when introducing support for Solarbank 2. The daily battery discharge value for Solarbank 1 now includes also bypassed PV energy, so it is not longer dedicated to battery discharge only. You can see this wrong value also in your Anker App statistics for the battery.
- The device sensor for battery energy is just a theoretical value and calculated by the Api library from nominal battery capacity and SOC. Changes of this entity should NOT be considered for energy dashboard helper sensors, since this sensor can never reflect the battery efficiency or loss of capacity over time.
- For such and other reasons, I do NOT recommend to use the Anker Solix integration daily energy statistic sensors directly in your energy dashboard, even if that is possible since they are classified as total_increasing sensors. The reasons for that are described in the discussion how to integrate the solarbank into you energy dashboard. There you can also find the recommended approach for creating the required entities for easiest and most flexible energy dashboard integration.
Appreciation:
If you like this integration and you want to show your appreciation for the countless hours spent to enhance and maintain it, I would be happy for a coffee.

Renewable Energy - Photovoltaics and Solar Energy
- Python
Published by thomluther over 1 year ago
Anker Solix Integration for Home Assistant - 2.1.2
New Release 2.1.2 with some fixes and enhancements
Breaking changes:
- None
Enhancements:
- Added new service to create an Api export from your assigned systems and devices in the configured Anker account #116
- This capability was already available as stand alone tool in the Anker Solix Api library and helps to provide an overview of Api responses for various system constellations and situations.
- Such exports are required to understand the Api behavior, debug issues and develop enhancements upon Api changes.
- The Api responses will be anonymized and saved into JSON files in an export folder that is created for the nickname of your Api connection
- The export folder will also be zipped and the service response will provide the url path to the zipped file
- You can directly download the zip file from your HA server through your browser by extending the server url with the url filename path from the service response
- Future exports will clear and re-use an existing nickname export folder, but each zip file will have its own filename to keep an export history
- Old zip files are located in
www/community/anker_solix/exportsand can be deleted manually with a File Manager Add-On (e.g. File Editor or VSC) if you have no direct file system access to your HA server
- Bump Api library to 2.1.2 #127
Fixes:
- Reduced situations when devices are unregistered during integration reloads or configuration option changes to reduce an automated reactivation of manually deactivated entities, which will be reset to integration defaults upon new registration of devices #114, #118
- Unregistering devices is a necessary step to clear orphaned entities upon account changes or exclude category changes. Also system or device renaming actions in the Anker App can cause orphaned entities in your integration.
- The unregistration will clear the whole device and all associated (orphaned) entities, to register only the provided entities from the Api responses again
- When devices are registered again, they will pickup previous deleted entities due to same unique_id which is based on device SN and an entity key. However, when not excluded by the configuration options, the entities will be enabled with the default integration settings, which is enabled for all entities except the device bws_surplus entity (The purpose of this entity is not clear and its always 0).
- Any user disabled entities will be reactivated based on HA core design, like also entity_id naming could change on registration based on HA core rules. The entity_id is automatically composed by device name (alias) and the translated entity key.
- The improvement will now unregister devices only for following situations:
- Added any new exclude category when changing configuration entry options. The affected devices for the additional exclude category are unregistered since they must be registered again with less entities.
- A confirmed reconfiguration of an integration entry (Anker account). This is to ensure changed accounts with less entities don't leave orphaned entities.
- Even if the account user remains the same during the reconfiguration confirmation, all devices of the configuration entry will be unregistered. This provides a fallback option to enforce a new registration of all devices. Alternatively, the whole configuration entry would have to be deleted and re-created to achieve the same.
- Therefore a simple configuration entry reload or HA restart will no longer trigger any device unregistration.
- Replace os module with pathlib module #126
- Bump ruff from 0.6.1 to 0.6.2 #113
- Bump ruff from 0.6.2 to 0.6.3 #119
- Bump ruff from 0.6.3 to 0.6.4 #124
- Bump ruff from 0.6.4 to 0.6.5 #125
- Bump actions/setup-python from 5.1.1 to 5.2.0 #120
Notes:
- Since there have been more and more questions on how to integrate the solarbank into the HA energy dashboard (#100 #104), a reference to the corresponding discussion post #16 has been added to the resources in README .
- I do NOT recommend to use the Anker Solix integration daily energy statistic sensors directly in your energy dashboard, even if that is now possible since they are classified as total_increasing sensors. The reasons for that are described in the discussion how to integrate the solarbank into you energy dashboard. There you can also find the recommended approach for creating the required entities for easiest and most flexible energy dashboard integration.
- The daily battery discharge statistic value is no longer correct. The cloud statistics changed this value in June 2024 when introducing support for Solarbank 2. The daily battery discharge value for Solarbank 1 now includes also bypassed PV energy, so it is not longer dedicated to battery discharge only. You can see this wrong value also in your Anker App statistics for the battery.
Renewable Energy - Photovoltaics and Solar Energy
- Python
Published by thomluther over 1 year ago
Anker Solix Integration for Home Assistant - 2.1.1
New Release 2.1.1 for required documentation and link updates due to renaming of the git repository to ha-anker-solix
- Rename became required to get the repo added to HACS default repositories in future
- If you added the old custom HACS repo to HA, this link should automatically be redirected to the changed repo name. If it would not, you would not get notified automatically about this 2.1.1 release
New Release 2.1.0 with Solarbank 2 home load preset & schedule support and simplified integration account reconfiguration
Breaking changes:
- Increased min. HA version to 2024.4.0 to support reconfiguration of account used in active configuration #110
Enhancements:
- Full Support for Solarbank 2 schedule modifications to complete enhancements for Solarbank 2 #60 #112
- The system output preset entity is now also available for Solarbank 2 devices when the integration configuration uses the Anker owner account
- It can be used to adjust the SB2 output directly when the
Manualusage mode is active
- It can be used to adjust the SB2 output directly when the
- In the backend, any adjustment of the preset or the usage mode will always result in 2 api requests to update and verify the required schedule structure on the SB2 via the cloud api
- Subsequent value increases either directly or via services (now actions) will therefore have a cool down of 30 seconds to avoid uncontrolled stress to the api by UI usage or HA automation (identically to the schedule support implementation for SB1)
- All schedule services (now actions) have been enhanced with an optional
week_dayfield to support SB2 time interval adjustments- The new field is ignored for SB1 schedule services, like the SB1 specific fields are ignored for SB2 schedule services (actions)
- The resulting changes and usage implications are described in the INFO
- The system output preset entity is now also available for Solarbank 2 devices when the integration configuration uses the Anker owner account
- Simplified switching of your Anker account used for the integration #110
- Previously, you had to delete the active configuration and recreate a new configuration with you other Anker account if you wanted to switch seamlessly between your main and shared account
- Since HA 2024.4.0, there is support to reconfigure static parameters of an active configuration, such as account information for example
- Support for reconfiguration was now added to the integration. You can now reconfigure the used account via the configuration entry menu item 'Reconfigure...' as described here
- Added support for new tag field reported by devices (Label entity)
- The Api cloud introduced a new
tagfield for devices, mainly to support the new smart plugs and allow to tag/label them to a location/room in the house. This tag is used in the Anker app to display a proper icon for the device to indicate its location to the user. - This field may be empty or use a senseless default value for devices that do not really make use of the new tag field in the Anker App, like solarbank or smart meter devices
- You can deactivate this entity individually for your devices if not needed, or optionally exclude the
device labelscategory completely in the options of your integration configuration entry - If you have Anker smart plugs however, you may want to see their tag/label too. Eventually this new tagging mechanism will be supported in the Anker app for additional devices in future and that might be the reason why this field was added to most of the devices.
- Note: Translation for the new label entity state (tag) is not provided since it is not clear which tags will be supported now and in future.
- The Api cloud introduced a new
- Added more guideline posts to discussions section of the repo
- Updated README and INFO with changes for Solarbank 2 schedule support and added further references for related blogs and videos
- Thanks to @TheRealSimon42 for his first contribution and providing additional resources for usage of the integration
- Thanks also to @thealkly for his previous contributions to the repo and his videos for usage of the integration
Fixes:
- Adjusted home load helper methods for SB1 and SB2 to prevent existing gaps in the schedule are automatically filled up when inserting or adjusting a slot that has start and end times provided.
- For Pre-release 2.0.2: Changed appliance_load minimum to 0 W for schedule services usability with SB2 (#107)
- Bump ruff from 0.5.5 to 0.5.6 #103
- Bump ruff from 0.5.6 to 0.57 #106
- Bump ruff from 0.5.7 to 0.6.1 #111
Note:
Since there have been more and more questions on how to integrate the solarbank into the HA energy dashboard (#100 #104), a reference to the corresponding discussion post #16 has been added to the resources in README .
I do NOT recommend to use the Anker Solix integration daily energy statistic sensors directly in your energy dashboard, even if that is now possible since they are classified as total_increasing sensors. The reasons for that are described in the discussion how to integrate the solarbank into you energy dashboard. There you can also find the recommended approach for creating the required entities for easiest and most flexible energy dashboard integration.
Renewable Energy - Photovoltaics and Solar Energy
- Python
Published by thomluther over 1 year ago
Anker Solix Integration for Home Assistant - 2.1.0
New Release 2.1.0 with Solarbank 2 home load preset & schedule support and simplified integration account reconfiguration
Breaking changes:
- Increased min. HA version to 2024.4.0 to support reconfiguration of account used in active configuration #110
Enhancements:
- Full Support for Solarbank 2 schedule modifications to complete enhancements for Solarbank 2 #60 #112
- The system output preset entity is now also available for Solarbank 2 devices when the integration configuration uses the Anker owner account
- It can be used to adjust the SB2 output directly when the
Manualusage mode is active
- It can be used to adjust the SB2 output directly when the
- In the backend, any adjustment of the preset or the usage mode will always result in 2 api requests to update and verify the required schedule structure on the SB2 via the cloud api
- Subsequent value increases either directly or via services (now actions) will therefore have a cool down of 30 seconds to avoid uncontrolled stress to the api by UI usage or HA automation (identically to the schedule support implementation for SB1)
- All schedule services (now actions) have been enhanced with an optional
week_dayfield to support SB2 time interval adjustments- The new field is ignored for SB1 schedule services, like the SB1 specific fields are ignored for SB2 schedule services (actions)
- The resulting changes and usage implications are described in the INFO
- The system output preset entity is now also available for Solarbank 2 devices when the integration configuration uses the Anker owner account
- Simplified switching of your Anker account used for the integration #110
- Previously, you had to delete the active configuration and recreate a new configuration with you other Anker account if you wanted to switch seamlessly between your main and shared account
- Since HA 2024.4.0, there is support to reconfigure static parameters of an active configuration, such as account information for example
- Support for reconfiguration was now added to the integration. You can now reconfigure the used account via the configuration entry menu item 'Reconfigure...' as described here
- Added support for new tag field reported by devices (Label entity)
- The Api cloud introduced a new
tagfield for devices, mainly to support the new smart plugs and allow to tag/label them to a location/room in the house. This tag is used in the Anker app to display a proper icon for the device to indicate its location to the user. - This field may be empty or use a senseless default value for devices that do not really make use of the new tag field in the Anker App, like solarbank or smart meter devices
- You can deactivate this entity individually for your devices if not needed, or optionally exclude the
device labelscategory completely in the options of your integration configuration entry - If you have Anker smart plugs however, you may want to see their tag/label too. Eventually this new tagging mechanism will be supported in the Anker app for additional devices in future and that might be the reason why this field was added to most of the devices.
- Note: Translation for the new label entity state (tag) is not provided since it is not clear which tags will be supported now and in future.
- The Api cloud introduced a new
- Added more guideline posts to discussions section of the repo
- Updated README and INFO with changes for Solarbank 2 schedule support and added further references for related blogs and videos
- Thanks to @TheRealSimon42 for his first contribution and providing additional resources for usage of the integration
- Thanks also to @thealkly for his previous contributions to the repo and his videos for usage of the integration
Fixes:
- Adjusted home load helper methods for SB1 and SB2 to prevent existing gaps in the schedule are automatically filled up when inserting or adjusting a slot that has start and end times provided.
- For Pre-release 2.0.2: Changed appliance_load minimum to 0 W for schedule services usability with SB2 (#107)
- Bump ruff from 0.5.5 to 0.5.6 #103
- Bump ruff from 0.5.6 to 0.57 #106
- Bump ruff from 0.5.7 to 0.6.1 #111
Note:
Since there have been more and more questions on how to integrate the solarbank into the HA energy dashboard (#100 #104), a reference to the corresponding discussion post #16 has been added to the resources in README .
I do NOT recommend to use the Anker Solix integration daily energy statistic sensors directly in your energy dashboard, even if that is now possible since they are classified as total_increasing sensors. The reasons for that are described in the discussion how to integrate the solarbank into you energy dashboard. There you can also find the recommended approach for creating the required entities for easiest and most flexible energy dashboard integration.
Renewable Energy - Photovoltaics and Solar Energy
- Python
Published by thomluther over 1 year ago
Anker Solix Integration for Home Assistant - 2.0.2
New Pre-release 2.0.2
Breaking changes:
- None
Enhancements:
- Full Support for Solarbank 2 schedule modifications to complete enhancements for Solarbank 2 #60
- The system output preset entity is now also available for Solarbank 2 devices when the integration configuration uses the Anker owner account
- It can be used to adjust the SB2 output directly when the
Manualusage mode is active
- It can be used to adjust the SB2 output directly when the
- In the backend, any adjustment of the preset or the usage mode will always result in 2 api requests to update and verify the required schedule structure on the SB2 via the cloud api
- Subsequent value increases either directly or via services (now actions) will therefore have a cool down of 30 seconds to avoid uncontrolled stress to the api by UI usage or HA automation (identically to the schedule support implementation for SB1)
- All schedule services (now actions) have been enhanced with an optional
week_dayfield to support SB2 time interval adjustments- The new field is ignored for SB1 schedule services, like the SB1 specific fields are ignored for SB2 schedule services (actions)
- The resulting changes and usage implications are described in the INFO
- The system output preset entity is now also available for Solarbank 2 devices when the integration configuration uses the Anker owner account
- Updated README and INFO with changes for Solarbank 2 schedule support and added further references for related blogs and videos
- Thanks to @TheRealSimon42 for his first contribution and providing additional resources for usage of the integration
- Thanks also to @thealkly for his previous contributions to the repo and his videos for usage of the integration
Fixes:
- Adjusted home load helper methods for SB1 and SB2 to prevent existing gaps in the schedule are automatically filled up when inserting or adjusting a slot that has start and end times provided.
- Bump ruff from 0.5.5 to 0.5.6 #103
Note:
Since there have been more and more questions on how to integrate the solarbank into the HA energy dashboard (#100 #104), a reference to the corresponding discussion post #16 has been added to the resources in README .
I dot NOT recommended to use the Anker Solix integration daily energy statistic sensors directly in your energy dashboard, even if that is now possible since they are classified as total_increasing sensors. The reasons for this are described in the discussion how to integrate the solarbank into you energy dashboard. There you can also find the recommended approach for creating the required entities for easiest and most flexible energy dashboard integration.
Renewable Energy - Photovoltaics and Solar Energy
- Python
Published by thomluther over 1 year ago
Anker Solix Integration for Home Assistant - 2.0.1
New release 2.0.1
Breaking changes:
- Moved all energy statistic related entities to the system device
- This became necessary after discovering that all energy statistics tracked on the cloud are only available as totals per device type in a power system.
- That means for dual Solarbank 1 power systems, you get only the total charge, discharge and solar energy values, but no break down per device. As logical consequence, the whole energy Api methods had to be restructured to query also additional smart meter and Solarbank 2 statistics and it became necessary to track all energy with the system device instead.
- This will have an impact to your existing device energy entities since their unique ID as well as their name and entity ID will change.
- In case you directly used any of them in your energy dashboard directly, you have to replace them after the integration update from releases before 2.0.0.
- The energy history will be lost when switching entities in the energy dashboard.
- For that reason, I recommend to use only template or helper entities from real devices or integration entities in the energy dashboard
- Then you never have to replace the energy dashboard entity itself, but only modify the helper or template accordingly upon breaking changes
- If you need to migrate the history from one entity to another one, this community post may help. Basically you need to modify the DB structures with SQL depending on the DB type that you use for Home Assistant. It is complex, but doable with some SQL skills and lot of caution (create HA backup upfront and stop the recorder via the HA service to avoid potential DB corruptions when applying DB changes in a running system via an Add On).
- The helper and template entities, as well as automation and scripts using any of the energy entities must be updated as well.
- This change does NOT effect the total yield which was always tracked with the system device, but all previous device energy related entities
- You may have to remove old energy entities from your devices manually since they are no longer provided by the integration. Check all your Anker Solix devices for entities no longer provided.
- Changed the state class of all energy stat entities from
totaltototal_increasing#100- This should only be relevant if you use those entities directly in your energy dashboard, which I would NOT recommend as discussed here.
- Removed the OTA update binary sensor since this query does not work for all devices and for Solarbank 1 is does not reflect available updates reliably
- Updated optional entity pictures
- In case you utilize the optional integration entity pictures, after installing the update you need to repeat the manual copy of the integration images subfolder to your www folder.
- See the README for instructions
Breaking changes since Pre-Release 2.0.0:
- Changed option names for Solarbank 2 power usage mode select entity to support various types of automatic modes
- The previous automatic mode was changed to smartmeter
- A new automatic mode was added for smartplugs
Enhancements:
- Support for Solarbank 2 devices #60 #77 #83
- Added all new entities available via cloud api
- Added select entity for power usage mode when smart meter is installed
- Added new energy statistics to system device
- Support for Smart Meter devices #83
- Added all new entities available via cloud api
- Enhanced configuration options
- The former 0 W value reporting for Solarbank 2 and smart meter devices is completely avoided #89
- Instead of 0 values, unavailable entities will now signal invalid Api data responses, which allows history tracking for invalid data
- Added new option to skip invalid/stale Api value responses to avoid entities become unavailable most of the time. When enabling this option, you also loose tracking capabilities for invalid data periods. Only valid data responses (every 5 minutes or less frequently) will cause updates of affected entities.
- Added device type and energy type exclude options to configuration options
- All energy statistics are excluded per default from new configurations since they may need significantly more Api requests during the device refresh interval.
- Bump ruff from 0.5.1 to 0.5.2 #86
- Bump ruff from 0.5.2 to 0.5.4 #90
- Bump ruff from 0.5.4 to 0.5.5 #99
- Bump actions/setup-python from 5.1.0 to 5.1.1 #87
- Update pip requirement from <24.2,>=21.0 to >=21.0,<24.3 #98
- Updated README and INFO with changes for Solarbank 2 and smart meter devices
Fixes:
- Optimized the schedule update sequence to limit the number of required requests to 2 per update
- Removed the OTA update binary sensor since this query does not work for all devices and for Solarbank 1 is does not reflect available updates reliably
- Only the applicable options will now be available for the Solarbank 2 power usage mode select entity, depending on the installed device types for the system
- If you add a smart meter or smart plug devices to the system, you have to reload the HA configuration entry to reconfigure the possible entity options accordingly
- Changed the state class of all energy stat entities from
totaltototal_increasing#100- This should allow the recorder to properly build sums for short and long term statistics as described in the documentation examples
- However it might also cause incorrect cycle resets and wrong statistics upon erroneous data provided by the cloud api.
- It is NOT recommended to use the integration energy statistics directly in your energy dashboard for such and other reasons.
Renewable Energy - Photovoltaics and Solar Energy
- Python
Published by thomluther over 1 year ago
Anker Solix Integration for Home Assistant - 2.0.0
New release 2.0.0
Breaking changes:
- Moved all energy statistic related entities to the system device
- This became necessary after discovering that all energy statistics tracked on the cloud are only available as totals per device type in a power system.
- That means for dual Solarbank 1 power systems, you get only the total charge, discharge and solar energy values, but no break down per device. As logical consequence, the whole energy Api methods had to be restructured to query also additional smart meter and Solarbank 2 statistics and it became necessary to track all energy with the system device instead.
- This will have an impact to your existing device energy entities since their unique ID as well as their name and entity ID will change.
- In case you directly used any of them in your energy dashboard directly, you have to replace them after the integration update from releases before 2.0.0.
- The energy history will be lost when switching entities in the energy dashboard.
- For that reason, I recommend to use only template or helper entities from real devices or integration entities in the energy dashboard
- Then you never have to replace the energy dashboard entity itself, but only modify the helper or template accordingly upon breaking changes
- If you need to migrate the history from one entity to another one, this community post may help. Basically you need to modify the DB structures with SQL depending on the DB type that you use for Home Assistant. It is complex, but doable with some SQL skills and lot of caution (create HA backup upfront and stop the recorder via the HA service to avoid potential DB corruptions when applying DB changes in a running system via an Add On).
- The helper and template entities, as well as automation and scripts using any of the energy entities must be updated as well.
- This change does NOT effect the total yield which was always tracked with the system device, but all previous device energy related entities
- You may have to remove old energy entities from your devices manually since they are no longer provided by the integration. Check all your Anker Solix devices for entities no longer provided.
- Updated optional entity pictures
- In case you utilize the optional integration entity pictures, after installing the update you need to repeat the manual copy of the integration images subfolder to your www folder.
- See the README for instructions
Enhancements:
- Support for Solarbank 2 devices #60 #77 #83
- Added all new entities available via cloud api
- Added select entity for power usage mode when smart meter is installed
- Added new energy statistics to system device
- Support for Smart Meter devices #83
- Added all new entities available via cloud api
- Enhanced configuration options
- The former 0 W value reporting for Solarbank 2 and smart meter devices is completely avoided #89
- Instead of 0 values, unavailable entities will now signal invalid Api data responses, which allows history tracking for invalid data
- Added new option to skip invalid/stale Api value responses to avoid entities become unavailable most of the time. When enabling this option, you also loose tracking capabilities for invalid data periods. Only valid data responses (every 5 minutes or less frequently) will cause updates of affected entities.
- Added device type and energy type exclude options to configuration options
- All energy statistics are excluded per default from new configurations since they may need significantly more Api requests during the device refresh interval.
- Bump ruff from 0.5.1 to 0.5.2 #86
- Bump actions/setup-python from 5.1.0 to 5.1.1 #87
- Updated README and INFO with changes for Solarbank 2 and smart meter devices
Fixes:
- Optimized the schedule update sequence to limit the number of required requests to 3 per update.
Renewable Energy - Photovoltaics and Solar Energy
- Python
Published by thomluther over 1 year ago
Anker Solix Integration for Home Assistant - 1.3.2
New release 1.3.2
Enhancements:
- Bump ruff from 0.4.9 to 0.4.10 #75
- Bump ruff from 0.4.10 to 0.5.0 #79
- Bump ruff from 0.5.0 to 0.5.1 #82
- Update pip requirement from <24.1,>=21.0 to >=21.0,<24.2 #74
- Bump softprops/action-gh-release from 2.0.5 to 2.0.6 #73
- Updated README with supported device models
Fixes:
- Avoid creation or artifact system entities #85
- This prevents that System device entities will be created even if not configured in the power system (e.g. PPS entities)
- Fixed Warning: Detected blocking call to os.scandir inside the event loop
- This was only seen when running integration in test mode
Renewable Energy - Photovoltaics and Solar Energy
- Python
Published by thomluther over 1 year ago
Anker Solix Integration for Home Assistant - 1.3.1
New release 1.3.0/1.3.1
Enhancements in 1.3.0:
- Support for individual solarbank output power preset in dual solarbank systems:
- New number entity to modify the device load preset
- New sensor to indicate the active output power preset mode
- Limits for appliance and device presets are now automatically adjusted based on number of installed solarbanks #48
- Enhanced schedule services and added an optional device load preset, which also allows to specify the device load and appliance load in combination for the given interval. The difference will then be applied to the other solarbank automatically. This allows a single service call against one of the two solarbanks to adjust both individually
- Note: Individual device load preset requires solarbank firmware 1.5.6 or later
- The new entities will not be created for single solarbank systems or when the existing schedule structure does not support this feature yet.
- After you updated both of your solarbanks to a supported firmware level but don't see the new entities yet, you need to reload the configuration of your Anker Solix integration to trigger a recreation of all entities.
- New entity to report on available OTA updates for solarbank devices
- This binary sensor will flag when there is a firmware update available for your solarbank
- Unfortunately the cloud api does not provide information about the available firmware version
- The sensor can be used for notifications when an update is available, which has to be performed through the mobile app
- Updated the README and INFO with the 1.3.0 enhancements
Enhancements in 1.3.1:
- Reduced Api calls for Solarbank Energy stats in Dual Solarbank systems #63
- Energy stats are reported on System level only, but Api query must be done against a device of a system
- Logic was changed to copy the energy data from devices that were already updated in previous Api query for same system
- Bump ruff from 0.4.5 to 0.4.8 #67
- Bump ruff from 0.4.5 to 0.4.9 #70
- Bump actions/checkout from 4.1.6 to 4.1.7 #69
Fixes:
- Missing preset entities when no schedule is defined bug dependencies #52
- HA 2024.6 Warning: Detected blocking call to open inside the event loop #71
Attention:
It was observed that sending a single solarbank schedule time interval via the cloud Api may result in a weird schedule on the solarbank. While the cloud and the integration shows correct output preset values, the appliance has a 0W preset. This cannot be corrected via the cloud Api. Any interval update or addition will result in the 0 W preset for all intervals. This will cause that the solarbank does NOT discharge anymore although the settings show correctly in the cloud and the HA integration. This firmware issue may depend on your firmware and your inverter configuration vs. real inverter setup. I noticed this problem while having configured MI80 inverter (to allow min. of 100 W preset), but not having a MI80 really installed. You can correct this problem only via the Anker mobile app which seems to use a different process to modify and query the solarbank schedule than via cloud Api.
Renewable Energy - Photovoltaics and Solar Energy
- Python
Published by thomluther almost 2 years ago
Anker Solix Integration for Home Assistant - 1.2.2
New release 1.2.2
Enhancements:
- Completely reworked the configuration flow:
- Options can now be changed before the first data collection will be running
- When excluded entity type selection will be changed, excluded entities will now be removed automatically from registry and UI
- Added more device and type categories to the entity exclusion option #27
- This allows better customization of the integration. For example you can now exclude device types like PPS or Power Panels completely if they are not relevant to your Anker setup
- Excluding various entity categories may help to reduce the number or regular Api requests as well, especially the solarbank energy statistics.
- For an overview on number of requests per device type and category refer to Api Request overview #32
- Improved Api error categorization and the Api response will now be included in error message
- The configured Api Request delay is now enforced for each request to reduce hitting a request limit for larger configurations
- Added request statistics to debug information and to error exception when request limit was exceeded
- Updated the README and INFO with the 1.2.0 enhancements
Fixes:
- Avoid complete reload of a configuration if only timing options have been modified when testmode is not defined
Fixes for 1.2.0:
- Bumped aiohttp version back to 3.9.3 to allow installations on HA < 2024.4.3 #47 #46
- Minor documentation updates
- Bump actions/checkout from 4.1.3 to 4.1.4 #45
- Bump ruff from 0.4.1 to 0.4.2 #44
Fixes for 1.2.1:
- Bumped minimum HA core to 2024.1.6 due to aiohttp 3.9.3 dependency #58 #57
- Bump actions/checkout from 4.1.4 to 4.1.5 #54
- Bump ruff from 0.4.2 to 0.4.3 #50
- Bump ruff from 0.4.3 to 0.4.4 #55
- Bump softprops/action-gh-release from 2.0.4 to 2.0.5 #53
Attention:
It was observed that sending a single solarbank schedule time interval via the cloud Api may result in a weird schedule on the solarbank. While the cloud and the integration shows correct output preset values, the appliance has a 0W preset. This cannot be corrected via the cloud Api. Any interval update or addition will result in the 0 W preset for all intervals. This will cause that the solarbank does NOT discharge anymore although the settings show correctly in the cloud and the HA integration. This firmware issue may depend on your firmware and your inverter configuration vs. real inverter setup. I noticed this problem while having configured MI80 inverter (to allow min. of 100 W preset), but not having a MI80 really installed. You can correct this problem only via the Anker mobile app which seems to use a different process to modify and query the solarbank schedule than via cloud Api.
Renewable Energy - Photovoltaics and Solar Energy
- Python
Published by thomluther almost 2 years ago
Anker Solix Integration for Home Assistant - 1.2.1
New release 1.2.1
Enhancements:
- Completely reworked the configuration flow:
- Options can now be changed before the first data collection will be running
- When excluded entity type selection will be changed, excluded entities will now be removed automatically from registry and UI
- Added more device and type categories to the entity exclusion option #27
- This allows better customization of the integration. For example you can now exclude device types like PPS or Power Panels completely if they are not relevant to your Anker setup
- Excluding various entity categories may help to reduce the number or regular Api requests as well, especially the solarbank energy statistics.
- For an overview on number of requests per device type and category refer to Api Request overview #32
- Improved Api error categorization and the Api response will now be included in error message
- The configured Api Request delay is now enforced for each request to reduce hitting a request limit for larger configurations
- Added request statistics to debug information and to error exception when request limit was exceeded
- Updated the README and INFO with the 1.2.0 enhancements
Fixes:
- Avoid complete reload of a configuration if only timing options have been modified when testmode is not defined
Fixes for 1.2.0:
- Bumped aiohttp version back to 3.9.3 to allow installations on HA < 2024.4.3 #47 #46
- Minor documentation updates
- Bump actions/checkout from 4.1.3 to 4.1.4 #45
- Bump ruff from 0.4.1 to 0.4.2 #44
Attention:
It was observed that sending a single solarbank schedule time interval via the cloud Api may result in a weird schedule on the solarbank. While the cloud and the integration shows correct output preset values, the appliance has a 0W preset. This cannot be corrected via the cloud Api. Any interval update or addition will result in the 0 W preset for all intervals. This will cause that the solarbank does NOT discharge anymore although the settings show correctly in the cloud and the HA integration. This firmware issue may depend on your firmware and your inverter configuration vs. real inverter setup. I noticed this problem while having configured MI80 inverter (to allow min. of 100 W preset), but not having a MI80 really installed. You can correct this problem only via the Anker mobile app which seems to use a different process to modify and query the solarbank schedule than via cloud Api.
Renewable Energy - Photovoltaics and Solar Energy
- Python
Published by thomluther almost 2 years ago
Anker Solix Integration for Home Assistant - 1.2.0
New release 1.2.0
Enhancements:
- Completely reworked the configuration flow:
- Options can now be changed before the first data collection will be running
- When excluded entity type selection will be changed, excluded entities will now be removed automatically from registry and UI
- Added more device and type categories to the entity exclusion option #27
- This allows better customization of the integration. For example you can now exclude device types like PPS or Power Panels completely if they are not relevant to your Anker setup
- Excluding various entity categories may help to reduce the number or regular Api requests as well, especially the solarbank energy statistics.
- For an overview on number of requests per device type and category refer to Api Request overview #32
- Improved Api error categorization and the Api response will now be included in error message
- The configured Api Request delay is now enforced for each request to reduce hitting a request limit for larger configurations
- Added request statistics to debug information and to error exception when request limit was exceeded
- Updated the README and INFO with the 1.2.0 enhancements
Fixes:
- Avoid complete reload of a configuration if only timing options have been modified when testmode is not defined
Attention:
It was observed that sending a single solarbank schedule time interval via the cloud Api may result in a weird schedule on the solarbank. While the cloud and the integration shows correct output preset values, the appliance has a 0W preset. This cannot be corrected via the cloud Api. Any interval update or addition will result in the 0 W preset for all intervals. This will cause that the solarbank does NOT discharge anymore although the settings show correctly in the cloud and the HA integration. This firmware issue may depend on your firmware and your inverter configuration vs. real inverter setup. I noticed this problem while having configured MI80 inverter (to allow min. of 100 W preset), but not having a MI80 really installed. You can correct this problem only via the Anker mobile app which seems to use a different process to modify and query the solarbank schedule than via cloud Api.
Renewable Energy - Photovoltaics and Solar Energy
- Python
Published by thomluther almost 2 years ago
Anker Solix Integration for Home Assistant - 1.1.2
Fix release 1.1.2
Fixes:
- Fixed issue with currency symbol for total savings entity that might exist on some browsers #35
- The configured Api request delay is now enforced for any subsequent request
Enhancements:
- Added a new service to clear the solarbank schedule
Attention:
It was observed that sending a single solarbank schedule time interval via the cloud Api may result in a weird schedule on the solarbank. While the cloud and the integration shows correct output preset values, the appliance has a 0W preset. This cannot be corrected via the cloud Api. Any interval update or addition will result in the 0 W preset for all intervals. This will cause that the solarbank does NOT discharge anymore although the settings show correctly in the cloud and the HA integration. This firmware issue may depend on your firmware and your inverter configuration vs. real inverter setup. I noticed this problem while having configured MI80 inverter (to allow min. of 100 W preset), but not having a MI80 really installed. You can correct this problem only via the Anker mobile app which seems to use a different process to modify and query the solarbank schedule than via cloud Api.
Renewable Energy - Photovoltaics and Solar Energy
- Python
Published by thomluther almost 2 years ago
Anker Solix Integration for Home Assistant - 1.1.1
Fix release 1.1.1
This is mainly a fix release for users that run into the 429: Too many requests issue, resulting in integration load failure or stale/unavailable entities from time to time. Please see Api Request Overview for more details on number of requests driven by the integration.
Fixes:
- Fixed a bug for dual solarbank setups that may have causing incorrect output preset values reported by device entities #30
- Added removal of integration services from HA when no more integration configurations exist
- The 3 changeable entities for a solarbank schedule time slot are now updated from the cached schedule during each refresh interval.
- This will ensure they are up to date once time passes and another time interval has become valid
Enhancements:
- Added config options to limit entities and/or Api requests #27
- The Api library was prepared to support exclusion of various device types or categories in the internal methods that update the Api cache with system and device information
- For this release, only Solarbank energy statistics can be excluded (which are now excluded by default). The energy statistic queries typically ran into the Api request limitation
- Future releases will add more categories or device types that can be excluded from the integration to limit required Api requests and reduce entities that should be presented to users.
- Added configuration option to configure Api request delay
- This helps to avoid driving too many requests per second.
- The default is set to 0,3 sec delay (instead of 0,0 sec previously)
- Larger account configurations may now take noticeably longer to load, but also reduce requests per second. A minimal configuration with 1 system and 1 Solarbank now loads in about 4 seconds per default. Larger configs need exponentially more requests (see Api Request Overview), and therefore need more time to complete the load as well as the regular refresh cycles
- The delay can be adjusted and reduced again in the options of the configuration entry if you do not face the '429: Too many requests' problem
- Updated documentation for enhanced option settings and added a note that standalone devices do not provide much information via the cloud Api. The integration only fully supports solarbank and inverter devices. Other devices may present some data, but nothing was ever tested.
Renewable Energy - Photovoltaics and Solar Energy
- Python
Published by thomluther almost 2 years ago
Anker Solix Integration for Home Assistant - 1.1.0
Hello Anker friends and Solarbank owners
This is a major enhancement release for your Anker Solix integration. It allows modifications for most of the customizable Solarbank settings that are accessible via the cloud Api. To understand the modification capabilities, read the updated INFO prior upgrade and usage of the new capabilities.
π₯Happy Easter!!!π₯
Following is now possible:
- Modify Appliance Home Load preset settings within the current time slot in the defined schedule:
- Change Output Power 0-800 W (min. 100 W applied by appliance for this setting)
- Change Discharge/Export switch
- Change Charge Priority Limit (0-100 %)
- Modify/Request the Solarbank schedule via 3 services when settings must be defined that are beyond the current time slot. The start and end times of the defined interval support minute granularity (unlike 30 min granularity like in the Anker App):
- Set new Solarbank schedule: Allows wiping of defined schedule and definition of new interval with the customizable schedule parameters above
- Update Solarbank schedule: Allows inserting/updating/overwriting a time interval into the existing schedule with the customizable schedule parameters above. Adjacent intervals will be adjusted automatically
- 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 output preset sensor.
- Change the Power Cutoff setting (reserve battery SOC)
- Change system price and currency symbol settings (provides more currency symbols than the Anker App)
Following further enhancements have been made:
- Added a Solarbank Data Update sensor to the system, which indicates when the Solarbank data have been last updated in the cloud. This helps to understand how old the Api data might be.
- Added changeable entities for system energy unit price and currency
- Added System sensor to show whether unread messages are flagged for the account (may indicate warnings/errors/update notifications?)
- Added Energy Sensors for the Solarbank: The energy data is pulled from the cloud statistics and require up to 4 additional Api requests per Solarbank. Therefore they will be updated only with the device refresh interval. They present the Energy for today and the attributes show the date for 'today' as well as the values of the previous day (yesterday). This is the energy data that you can find in the Anker app on the system home screen. Note: While the statistics are queried by device, I have no chance to validate whether the values are combined for dual Solarbank systems or individual per Solarbank.
- Added French translation, thanks @olivr2s for this contribution, I hope my French extensions using a translation engine are also understandable for the added entities and services :-)
- Added more entity pictures for various Anker power devices that might be supported as standalone devices based on their model types (PN).
After integration update and before HA restart, you need to copy the pictures manually again to your www subfolder. See installation instructions on README. - The device entity picture is now presented for the Device Refresh Button entity instead of the Cloud Connection status entity. This is the only entity that is for sure available also for any stand alone device, even when using the shared account.
- Fixed a problem with Api data cache for stand alone devices: Their sensors will no longer become unavailable upon more frequent Api System refresh queries
Breaking change:
- The power cut off sensor entity is replaced with a select entity to support modifications of the setting
Important:
Care must be taken when using the new modification capabilities, especially in automation.
Read the updated usage instructions: INFO.
The installation instruction can be found in the README.
For discussions, refer to Discussions
Appreciation is always welcome

Keep in mind that you as the user bear the sole risks for the usage of the Integration, that may include loss of Manufacture's warranty or any damage that may have been caused by use of this integration or the underlying Api python library.
Renewable Energy - Photovoltaics and Solar Energy
- Python
Published by thomluther almost 2 years ago
Anker Solix Integration for Home Assistant -
Fixes:
- add state description for charging_status 6 #14
For initial release notes, please refer to
Initial Release is there !!!
Renewable Energy - Photovoltaics and Solar Energy
- Python
Published by thomluther about 2 years ago
Anker Solix Integration for Home Assistant - 1.0.0
Hello Anker friends and Solarbank owners
You may have looked around since a while for a possible integration of your Solarbank or Inverter devices into Home Assistant, allowing you to monitor your energy flow and eventually integrate it into your energy management.
The first integration is now available, based on the anker-solix Python library I release few weeks ago. The integration supports translations which can easily be expanded by the community. It also comes with dynamic icons based on sensor states and optionally provides entity pictures for the supported Anker devices.
Try the new integration and see if it fits your needs. Share your experience and observations with the community.
The installation instruction can be found in the README.
For detailed usage instructions, refer to the INFO.
For discussions about this release, refer to Initial Release is there !!!
Keep in mind that you as a user bear the sole risks for the usage of the Integration, that may include loss of Manufacture's warranty or any damage that may have been caused by use of this integration or the underlying Api python library.
Some heads up information about this release before you ask:
- If you do not find details you are interested in, look first in the sensors attributes. For instance the whole schedule json is provided with the actual device out power preset sensor
- No, there is no modification capability to set the home load (yet). This is complex since it can only be applied with a schedule, which is probably the whole but modified json schedule structure. It needs more testing and proper design for a user friendly utilization in HA
- No, there is no Solarbank temperature sensor unfortunately. I miss that too, but I have not seen this value in the known Api responses. I assume the temperature is provided only via Bluetooth like the real time data updates you can view in the solarbank details view of the Anker App.
- Yes, there are extra sensors that are not provided by the Anker cloud Api itself and you will not find in the Anker App, like remaining battery energy and battery capacity attribute. They are provided/created by the Api python library to provide more useful information of your device.
- Be aware that the status descriptions which are provided also by the Api python library are based on experience. They may not always reflect the correct situation, in this case let me know with an example to correct this accordingly. Those sensors have the status code from the cloud Api as attribute. You should also know, that for example the charging_status code of 3 (= charging) is translated to three different charge status descriptions, depending on the other power metrics seen (charge, charge_priority and charge_bypass). The solarbank does not distinguish them when charging, however the descriptions should be more meaningful to users, reflecting a more accurate status condition.
- The Api library also converts some of the returned power fields since their meaning is not always identical and various weird values are presented in various situations, especially for the charging power. The Api library now converts/corrects the charging_power values to positive charging values and negative discharge values, giving a direct indication for the power direction. This can also easier be integrated into your HA power flow cards without the need of template sensors to indicate the power direction.
- The cloud Api may also sum up various values per reported device category, which are presented in the system device. For example if you have installed 2 Solarbanks, the System device will report the overall power values and SOC for both Solarbanks. Of course, those sensors are redundant if only 1 solarbank is installed, because they will show the same value as the individual device sensor.
- If end device sensors are added by the Api library, they are not necessarily accumulated in the system again for the device category (like the battery energy). You can create a template or group sensor, if you want to sum or average individual device values for your dashboard.
Renewable Energy - Photovoltaics and Solar Energy
- Python
Published by thomluther about 2 years ago