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
I’m really happy to share that huABus v1.10.0 is now available — and it finally brings batch register reading
Until now, huABus performed 67 individual TCP calls per read cycle. With v1.10.0, those reads can now be grouped into just a small number of batch requests using client.get_multiple() from the huawei_solar library. The result: much less TCP overhead and a massive performance improvement on many setups, especially if network latency has been a bottleneck.
What’s new in v1.10.0
smarter register reading with configurable batching
new options:
enable_batching
batch_max_gap
graceful fallback to single reads if batching runs into trouble
full unit tests for batch building and fallback behavior
batch timing integrated into the existing DEBUG statistics
Some of you may remember the earlier DEV-branch feedback about batching problems with optional storage-related registers like storage_unit_1_soc, storage_unit_2_soc, and storage_unit_3_soc.
That issue was real and was part of the reason I didn’t want to rush this feature out too early. The DEV version still had limitations around optional registers, which could cause batch reads to fail and fall back to sequential mode. With the final v1.10.0 implementation, this should now be handled much more cleanly — including the case discussed in issue #25
Huge thanks to everyone who tested, reported issues, and shared logs along the way
That feedback really helped shape this release.
Just wanted to clarify something for anyone seeing the warning ⚠️ Batch 3 failed (1 < count 156 < 125 !) in their logs with the new batching implementation:
This is expected behavior and not a bug.
Batch 3 attempts to read optional registers (typically for storage units or other hardware components that may not be present on all inverter models). When these registers don't exist on your device, the system gracefully falls back to sequential reads for that batch and continues normally.
You can tell it's working fine if:
Your data is publishing correctly ✓
All sensor values look accurate ✓
The cycle completes successfully ✓
The warning is just the system saying "Hey, those registers aren't available on this device" – and then it handles it automatically.
No action needed – your setup is working as intended!
If you saw this in your logs after upgrading to v1.10.0:
Batch 3 failed (1 < count 156 < 125 !), falling back to sequential
This is now fixed in v1.10.1. The default batch_max_gap has been reduced from 100 to 50, which keeps batches within the inverter's internal register limit and avoids the sequential fallback.
If you already set batch_max_gap: 50 manually – you're good, no change needed. If you haven't touched that setting – just update the add-on, the new default kicks in automatically.
Thanks to @mauromognon and @Stepyon for the quick feedback and logs!
v1.10.2 is out – mostly a stability and housekeeping release, no new features. Here's what changed and what it means for you.
Filter reset is now safer
The most relevant fix for day-to-day use: reset_filter() now resets the filter state in-place instead of destroying and recreating the singleton. In practice this closes a brief unprotected window during error recovery (e.g. after a Modbus timeout) where a zero-drop could slip through to your Home Assistant Utility Meters. Shouldn't have been noticeable in normal operation, but it's cleaner now.
Slave-ID auto-detection is more robust
During failed detection attempts, the client.stop() call is now bounded to 2 seconds. Previously a hanging stop could silently block the next attempt. Failures are now logged instead of swallowed – so if detection is struggling, you'll actually see why in the logs.
Internals cleanup (no user impact)
Replaced some scattered module-level globals with a proper _BridgeState dataclass. No runtime behavior change, but it makes the test suite significantly more reliable and avoids state leaking between test runs.
batch_max_gap stays at 50
As introduced in v1.10.1: the default batch_max_gap is 50, not 100. If you're upgrading from v1.10.0 and have batch_max_gap: 100 explicitly in your config, please update it to 50 to avoid the sequential fallback on every cycle.
I’ve released a new version of my app for the Huawei Solar
Modbus/MQTT bridge. This update fixes an issue that caused hanging
connections for some users.
What’s new?
Bugfix: Hanging connection during connection setup
If the connection to the inverter (TCP handshake) got stuck, the
integration could in rare cases hang indefinitely instead of failing
and retrying. This is now fixed — a 15-second timeout kicks in, after
which the integration cleanly reconnects.
Improvement: Cleaner error handling
Under the hood, error handling was reworked so that “expected”
connection issues (timeout, connection refused, Modbus exceptions) are
correctly recognized and handled automatically, while truly unexpected
errors now show up in the logs instead of being silently swallowed.
This will also make troubleshooting future issue reports easier.
Who should update?
If your integration occasionally seems to “freeze” or doesn’t
reconnect on its own after a network hiccup, this update should help
noticeably. For everyone else, this is a pure stability update with no
configuration changes — no action needed beyond the regular update.
Update
As usual, via HACS or manually through the GitHub release.
Version 1.11.0 brings a major upgrade of the Huawei Solar communication stack and makes Modbus batching more reliable.
Highlights
Upgraded huawei-solar from 2.5.0 to 3.0.7
Migrated from pyModbus to the newer tModbus transport layer
Fixed smart batching to respect the Modbus limit of 125 registers
Improved error handling and failure visibility
Fixed storage-unit register mappings and import issues
Added more error-tracker tests
The new huawei-solar version also provides a more modern and maintainable foundation for upcoming releases.
The updated transport layer and current library APIs should make future compatibility improvements, bug fixes, and additional Huawei device support easier to integrate.
Please report any connection or batching issues after upgrading, ideally including the relevant logs.
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)
Batch 3 failed (1 < count 156 < 125 !), falling back to sequential
Filter reset is now safer
Slave-ID auto-detection is more robust
Internals cleanup (no user impact)
huABus v1.10.4 – Stability Update (Modbus Connection)
Bugfix: Hanging connection during connection setup
Fixed smart batching to respect the Modbus limit of 125 registers
Added more error-tracker tests