Release 3.4.1

❄ More MQTT enhancements 🎁 and some fixes 🔧

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

• Bumped Api library from 3.4.0 to 3.4.1 and 3.4.2

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:
    1. Update the integration and restart HA
    2. 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)
    3. 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)
    4. Check the entity_id of the new one, it should be suffixed with '_2' if you did not customize the original entity_id
    5. Now check the entity_id of the old one, which should be the same. Copy the entity_id and delete the old entity
    6. Go to the new entity details again and change the entity_id to the old one and update the entity.
    7. 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 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.

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 will...

Release 3.4.0

❄ The temperature has finally arrived 🌡

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

• 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)

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 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.

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 Anker Solix action Api Request in HA developer tools actions
• 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.

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 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.

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 Anker Solix action Api Request in HA developer tools actions
• 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.

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.

• 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

• 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

• 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

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 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.

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 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.

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 Anker Solix action Api Request in HA developer tools actions
• 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.

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🤷.

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

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 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.

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 no...

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

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 3.2.0...3.2.2 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.

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 Anker Solix action Api Request in HA developer tools actions
• 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.

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

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 3.2.0...3.2.1 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.

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 Anker Solix action Api Request in HA developer tools actions
• 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.

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 😎

• 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

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

Full Changelog 3.1.1...3.2.0 and link to previous release notes 3.1.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.

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...