Release 3.8.1
Important
🚨 Read the breaking changes before upgrading 🚨
Originally this release was targeted as fix release with major code refactoring to satisfy new Ruff rules and HA core deprecation warnings. But at the end, a lot of new stuff was added as well 😎.
Please make sure to review the breaking changes for potential impact of those code changes, and enjoy support of additional PPS devices like C2000X Gen 2 and C1000X Gen 2, as well as Power Panel system enhancements which now reflect the correct system device topology and do proper overall battery capacity calculations. Furthermore, the latest PPS generations such as the S2000 and C2000(X) Gen 2 devices may support a manual backup mode and a Storm Guard feature to enable a backup charge window for maximum AC/PV battery charge. These new features can now be controlled as well through the integration,
💖A big THANK YOU to the community and your sponsoring and support to keep this project active. 💖
Enhancements: 📢
-
Bumped Api library to release 3.8.1 for enhanced MQTT device support
-
MQTT Enhancements for a couple of devices
- Added C1000X Gen 2 A1765 including full control (#342 Thanks to @rickt123 for confirmation)
- Mapped status message and MQTT controls supported by the devices
- Added C2000X Gen 2 A1785 including full control (#329 Thanks to @ajw1980 and others who helped decoding the MQTT data and enhanced schedule structures)
- Mapped status message and MQTT controls supported by the devices
- Added working status as known so far, some codes may be missing.
- Note: The App may display AC bypass mode although the working status code indicates discharging. I'm not sure how that mode is differentiated by the App
- Added more controls for various PPS, mainly S2000 and C2000(X) (Thanks to all people involved into this and sharing device access to a S2000 for testing and debugging)
- Switch of usage modes as supported by device
- Full control of backup plan and Storm Guard switch as supported by device.
- Note: Storm Guard is a cloud service, that is currently mainly supported in US. The feature support is verified through the Api and not controllable if not supported by the device
- Conversions of TOU schedule, Custom Schedule and AC output schedule if supported by the device
- Note: MQTT controls to modify custom, TOU or AC output schedules may be added in a future release
- Added C1000X Gen 2 A1765 including full control (#342 Thanks to @rickt123 for confirmation)
- Added MQTT control for AX170 power dock to modify the circuit priority (#312 Thanks to @tmcor for supporting this)
- Added full decoding and conversion for circuit setup structure, which is different for control and state and must be recreated completely if only one circuit priority is changed.
- The priority control considers paired circuits from the initial setup, like they are considered for the circuit power sensors.
- Improved management of Power Panel and its attached PPS F3800(P) devices
- The power panel Api class can now handle standalone PPS devices as well
- This allows to manage the cache data for the attached PPS which are reported as stand alone devices by the Api
- MQTT data from Power Panels may contain embedded MQTT messages from one of the 2 PPS, but also a few PPS data for both PPS, like SOC, output power and attached device SNs
- This allows to merge the PPSes to the same system as the Power Panel device, and link them as sub devices to the Power Panel device to show the correct system topology via the merged cache data
- It also improves the system battery capacity calculation, since all PPS and their extension batteries are now being considered for proper calculation of overall Power Panel capacity and remaining energy if MQTT data is available
- Following are some merged PPS entities that may be provided continuously by Power Panel real time MQTT data. Note that the power panel only provides a signed power value per PPS, which is converted into the appropriate 3 positive PPS sensors for AC input power, AC output power and Charge power (the converted PPS charge power cannot consider additional PV charge power which may exist during AC charge)
- Added disaster protection Api support for Power Panel systems and PPS stand alone devices for Storm Guard feature discovery and regular status queries
- The Storm Guard (auto disaster) feature is a cloud service, that is only supported for few regions/countries (e.g. US, PR)
- The Api queries for stand alone devices are the same as used for Power Panel systems, and currently only supported on the COM cloud server, not the EU server
- The required location setting for the Storm Guard feature must be done in the mobile App.
- Once the location for Storm Guard is supported and configured, it can be activated and deactivated through the Api
- Once auto disaster is activated via the cloud, the cloud will drive regular MQTT commands to the device to provide a disaster status, and eventually set an automatic backup charge window whenever there is an elevated disaster risk for the configured location
- The backup status of the Power Panel system or PPS device should now report whether a planned or automatic backup charge is in progress
- If the auto disaster feature is supported, the actual disaster status for the configured location will be queried with every site refresh poll,
- More disaster protection details can be found in the attributes of those new diagnostic sensors
- Added a normal switch entity to activate and deactivate the V1 EV charger charging mode. (#591 Thanks @GigiPompieru for the feature request)
- Other integrations like EVCC may expect a binary control to enable and disable the EV charging when certain conditions are met
- The new switch entity now allows to utilize the V1 charger directly by such integrations
- It is a binary translation of the various V1 charger usage modes and states, which are required to fully support all V1 charging controls and states.
Note
Activating the V1 EV charger does not mean it will start charging immediately. If no charging cable is plugged, it may automatically deactivate charging mode again after the plug timeout expired. If a random charging delay is enabled, this delay must elapse before charging really starts. This delay can be skipped only with the select entity, which provides full control about the V1 operational modes. The V1 charger may also pause and continue charge automatically, which will all be reflected as activated charge state of the switch entity.
- Updated README.md
- Added newly supported devices
- Added special device notes for PPS
Breaking changes: 💥
-
The timezone initialization for all datetime based instances should not break the existing methods or data reporting, but it cannot be fully validated either by the developer for all circumstances.
- Offsets between client time and system/device local time and cloud times may result in wrong day switch comparison, which is required to query to proper days in the cloud recording for daily energies or Solar forecasts or Dynamic price forecasts.
- Pls open a new issue with the particular time offset issue for wrong day switches in data query or reporting.
-
Some PPS or Power Panel entity translations had to be adopted for common use across various devices
- A translation change may result in a different default entity_id in case the entities are being re-registered by the integration
- This typically occurs only for new hub entries, hub authentication reconfiguration or additional exclusion categories selected in existing hub options.
- A changed entity_id may cause issues with your front end cards configuration or in scripts and automations
-
If complete entities remain unavailable and are not longer provided by the integration, they must be deleted manually
- In most cases, this occurs due to underlying name changes of the MQTT field descriptions for corrections or harmonization
- The values are now typically reflected in other sensors or as attributes of sensors
- The easiest way to see all available attribute values is to use the developer tools panel in HA and filter your Solix device entities
-
For upgrades from version < 3.8.0, see breaking changes in 3.8.0 release notes
Fixes 🔨 and other changes: 🔧
-
Major code refactoring to ensure all datetime instances will be initialized with a timezone as required by new Ruff rules
- See breaking changes for more details
-
Code changes to eliminate HA core deprecation warnings
-
CO2 savings sensor switches to t, which HA statistics cannot record (breaks long-term stats) (#589)
- The CO2 saving values are now converted to kg if the Api provides them with the ton unit
-
Updated export module
- Added queries to support the disaster endpoints also for stand alone PPS
-
@dependabot[bot] updates:
- Update pip requirement from <26.3,>=26.2 to >=26.2.1,<26.3 by @dependabot[bot] in #587
- Bump ruff from 0.16.1 to 0.16.3 by @dependabot[bot] in #594
- Bump ruff from 0.16.3 to 0.16.4 by @dependabot[bot] in #601
Full Change log 3.8.0...3.8.1 and link to previous release notes 3.8.0
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 the reported SOC. Changes of this entity should NOT be considered for the energy dashboard or energy 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 accumulated energy values from decoded MQTT data, they may provide a more accurate source for your helper sensors, which I recommend to be used for energy dashboards.
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 identify and describe the message data fields
- This must be done under various usage conditions of the device to allow recognition and 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 ☕ or if you become a sponsor 💖.





