This is a hotfix release addressing the installation failure on Raspberry Pi 4 and other ARM-based systems reported in #22.
What was fixed
Users on aarch64 (RPi 4/5) were unable to install the add-on due to a hardcoded amd64 base image in the Dockerfile. Home Assistant Supervisor tried to build for aarch64 but Docker couldn’t resolve the image for that platform — resulting in a build error.
The fix:
Added a build.yaml with correct architecture-specific base images for all supported platforms (aarch64, amd64, armhf, armv7, i386)
Removed the hardcoded amd64 default from the Dockerfile
If you were affected by this, simply reinstall the add-on — it should now build and run without issues.
Coming in v1.9.0
Thanks to a great contribution by @Stepyon (PR #23), the next release will bring batched Modbus polling — replacing the current per-register reads with grouped get_multiple() calls. On his setup this reduced cycle time from ~5s down to ~1.2s. I’ll be reviewing and merging this into dev for testing in the next few days before it lands in main.
I’ve implemented detailed performance diagnostics to help identify the root cause of your slow cycle times. The new features are available in the development version for testing.
What’s New in DEV (v1.9.0)
Per-Register Timing Analysis - When you enable log_level: DEBUG, the add-on now measures and logs:
Individual read time for each of the 67 registers
Statistical analysis (average, min, max, median)
The top 5 slowest registers
Warnings for registers taking >200ms
This will show us exactly where the time is being lost - whether it’s network latency, specific registers, or rate-limiting.
How to Test
Install the dev version:
Supervisor → Add-on Store → ⋮ (top right) → Repositories
Add: https://github.com/arboeh/huABus-dev
Install "huABus | Huawei Solar Modbus to MQTT (DEV)"
Enable diagnostics:
log_level: DEBUG
poll_interval: 120 # Temporarily increase during diagnosis
Let it run one complete cycle, then check the logs for:
Hi Arend,
thanks for the analysis options. However, I wouldn’t invest much more effort into this. Yesterday I received a new SDongleA-05 with PN 02312QMV-004. With that, I’m down to ~5 seconds . My previous SDongle (PN 02312QMV-005) apparently lost badly in the CPU lottery and has been completely overwhelmed since the communication towards the FusionSolar cloud became encrypted. Some details in German that ultimately led me to switch: Das Elend mit dem langsamen Huawei SDongleA-05 hat ein einfaches Ende · evcc-io/evcc · Discussion #22534 · GitHub
huABus v1.9.0 is out! This release focuses on performance diagnostics — a foundational step toward making slow cycle times much easier to understand and fix.
What's new:
When log_level: DEBUG is enabled, you now get detailed per-register timing measurements after every read cycle
Automatic warnings for slow registers (>200ms) and a Top 5 slowest registers list in the logs
Statistical summary per cycle: average, min, max, and median read times
Connection establishment time is logged with host/port/slave details
Expanded Performance Troubleshooting section in DOCS.md with step-by-step diagnosis, network latency testing, and firmware update guidance
This is especially useful if you're experiencing slow update intervals or timeouts — the logs will now tell you exactly where the time is going.
Would love to hear your feedback, particularly if you're running an SDongle over WiFi or a slow network. Real-world timing data will directly shape the next release.
UPCOMING: Batch Register Reading (planned for v1.10.0)
Title:feat: batch register reads to reduce TCP overhead
Currently, huABus performs 67 individual TCP calls per read cycle. v1.10.0 will introduce batch reads using client.get_multiple() from the huawei_solar library, consolidating them into a small number of calls — potentially a massive performance improvement.
Hi, quick feedback regarding v1.10.0: There seems to be an issue with batching when a storage unit is connected. Should storage_unit_%_soc perhaps be excluded from the batch read under certain circumstances?
2026-05-08 10:43:21,744 - huawei.main - INFO - Batch read not supported on this inverter (Did not recognize register names: storage_unit_1_soc, storage_unit_2_soc, storage_unit_3_soc), using sequential mode (this is normal for inverters with optional registers)
Thanks for the feedback. This behavior is currently known and expected on the DEV repository. The new batching logic is not fully implemented there yet, especially for setups with optional registers such as storage-related values like storage_unit_%_soc.
In the current development state, batch reads can fail when the inverter does not expose all requested optional registers. In that case, the integration falls back to sequential mode, which is why you see the log message:
Batch read not supported on this inverter (...) using sequential mode
So yes, this is related to a known limitation around optional registers in the DEV branch, and it is not yet handled by dynamically excluding those registers. This issue is already known and part of the ongoing work for v1.10.0.
If you are looking for the stable version - v1.9.0 (without batch), it is always available here: https://github.com/arboeh/huABus
huABus v1.8.5 released
Coming in v1.9.0
line + 
section)
. My previous SDongle (PN 02312QMV-005) apparently lost badly in the CPU lottery and has been completely overwhelmed since the communication towards the FusionSolar cloud became encrypted. Some details in German that ultimately led me to switch: 
Batch read not supported on this inverter (Did not recognize register names: storage_unit_1_soc, storage_unit_2_soc, storage_unit_3_soc), using sequential mode (this is normal for inverters with optional registers)