That’s perfectly fine for me.
The backup can be missed for a quite a while until it would start to matter. So no probs there.
Due to time constraints I did not look much at logs at all.
Thanks,
HANT
I just saw 1.7.4 version announced in HA.
But I am afraid that the update, via the usual way, is still failing:
Thanks,
HANT
Hey HANT, can you delete the addon completely and delete repo as well and install again? Maybe it’s a HA caching problem…
I did that (uninstalled add-on, restarted HA, installed latest version 1.7.4) and it got up and running.
The log states the following:
[16:17:21] INFO: ========================================================
[16:17:21] INFO: 🌞 huABus v1.7.4
[16:17:21] INFO: 📦 https://github.com/arboeh/huABus
[16:17:21] INFO: ========================================================
[16:17:21] INFO: >> Starting huABus - Huawei Solar Modbus MQTT Add-on...
[16:17:21] INFO: >> Log level: DEBUG
[16:17:22] INFO: --------------------------------------------------------
[16:17:22] INFO: 🔌 Inverter: 192.168.XXX.XXX:502 (Slave ID: 2)
[16:17:22] INFO: 📡 MQTT: 192.168.XXX.XXX:1883 (custom)
[16:17:22] INFO: 🔐 Auth: enabled (custom)
[16:17:22] INFO: 📍 Topic: huawei-solar
[16:17:22] INFO: ⏱️ Poll: 30s | Timeout: 180s
[16:17:22] INFO: 📊 Registers: 58 essential
[16:17:22] INFO: --------------------------------------------------------
[16:17:22] INFO: >> System Info:
[16:17:22] INFO: - Python: 3.12.12
[16:17:24] INFO: - huawei-solar: 2.5.0
[16:17:24] INFO: - pymodbus: 3.11.4
[16:17:24] INFO: - paho-mqtt: 2.1.0
[16:17:24] INFO: - Architecture: x86_64
[16:17:24] INFO: >> Starting Python application...
2026-02-04 16:17:25,120 - huawei.main - INFO - 📋 Logging initialized: DEBUG
2026-02-04 16:17:25,120 - huawei.main - DEBUG - 📋 External loggers: pymodbus=INFO, huawei_solar=INFO
2026-02-04 16:17:25,120 - huawei.main - INFO - 🚀 Huawei Solar → MQTT starting
2026-02-04 16:17:25,120 - huawei.main - DEBUG - Host=192.168.178.193:502, Slave=2, Topic=huawei-solar
2026-02-04 16:17:25,121 - huawei.mqtt - DEBUG - MQTT auth configured for mqttman2
2026-02-04 16:17:25,121 - huawei.mqtt - DEBUG - LWT set: huawei-solar/status
2026-02-04 16:17:25,121 - huawei.mqtt - DEBUG - Connecting MQTT to 192.168.178.20:1883
2026-02-04 16:17:25,128 - huawei.mqtt - INFO - 📡 MQTT connected
2026-02-04 16:17:25,529 - huawei.mqtt - DEBUG - MQTT connection stable
2026-02-04 16:17:26,531 - huawei.mqtt - DEBUG - Status: 'offline' → huawei-solar/status
2026-02-04 16:17:26,531 - huawei.mqtt - INFO - 🔍 Publishing MQTT Discovery
2026-02-04 16:17:26,600 - huawei.mqtt - DEBUG - Published 56 numeric sensors
2026-02-04 16:17:26,611 - huawei.mqtt - DEBUG - Published 11 text sensors
2026-02-04 16:17:26,613 - huawei.mqtt - INFO - ✅ Discovery complete: 68 entities
2026-02-04 16:17:26,613 - huawei.main - INFO - ✅ Discovery published
2026-02-04 16:17:26,717 - huawei.main - INFO - 🔌 Connected (Slave ID: 2)
2026-02-04 16:17:26,719 - huawei.mqtt - DEBUG - Status: 'online' → huawei-solar/status
2026-02-04 16:17:26,720 - huawei.main - INFO - 🔍 TotalIncreasingFilter initialized (simplified)
2026-02-04 16:17:26,720 - huawei.main - INFO - ⏱️ Poll interval: 30s
As I have no storage - I guess it must be failing?
2026-02-04 16:21:02,405 - huawei.main - DEBUG - Failed storage_unit_1_soc
2026-02-04 16:21:02,405 - huawei.main - DEBUG - Failed storage_unit_2_soc
2026-02-04 16:21:02,406 - huawei.main - DEBUG - Failed storage_unit_3_soc
Thanks,
HANT
Edit: the first version was about it not working, but I was looking at a non-configured add-on. Of course, not much worked.
I forgot that a reinstallation will require the cofig again
But this still happens to me when I stay in the log tab of the add-on for a little while:
Reloading is fine though.
HANT
Hey HANT,
great to hear it’s working now! 
Your logs look perfectly normal.
Regarding the “Failed storage” messages: This is expected behavior when you don’t have a battery/storage system connected. The huABus attempts to read all registers by default (including storage SOC for systems with batteries). Since you don’t have storage, these queries fail – but that’s completely fine and has no negative impact. These messages only appear at DEBUG log level and actually show that everything is working correctly.
Regarding the “Failed to get /addons/…” error: This is a known Home Assistant frontend issue that occurs when you stay on the log page for an extended period. The Supervisor API times out. This is not related to the add-on itself – as you’ve already noticed, everything works fine after a reload.
Your setup is running smoothly! The important logs show:
Modbus connection to inverter successful- MQTT connection stable
- 68 entities created via Discovery
- 30s poll interval active
If you’d like to reduce the DEBUG messages, you can set the log level to INFO in the add-on configuration – this will hide the “Failed storage” messages.
Happy monitoring! 
I understand that the faling reads happen b/c there is no battery installed. Nevertheless, the wording might worry one.
It has failed for a good reason (and it is not failing in the sense of an error), maybe it is possible to adjust the wording a bit in some future version.
So far [version 1.7.4] serves me well with the reinstallation.
Thanks,
HANT
I’ve added it to my to-do list.
But it is not essential. Whenever it fits.
No real urge here.
Thanks for the good support of your add-on!
HANT
Running confing vs. config tab
I noticed one thing. Not sure if it relates to this add-on specifically.
I was playing around w/ the config and I found the discrepancy between the config value shown, and the value actually used.
Or is it standard HA behaviour?
e.g. I set the slave ID =16 which in invalid (I know that one is not working for me, but it was meant as test a few things).
It does accept this value when the add-on restarts, but the config page flips back to original value, and it does not show an active save button and so on.
So one can come to the conclusion that these the actual config values the add-on runs with, which it is not.
Loglevel: DEBUG
[16:25:28] INFO: >> System Info:
[16:25:28] INFO: - Python: 3.12.12
[16:25:31] INFO: - huawei-solar: 2.5.0
[16:25:31] INFO: - pymodbus: 3.11.4
[16:25:31] INFO: - paho-mqtt: 2.1.0
[16:25:31] INFO: - Architecture: x86_64
[16:25:31] INFO: >> Starting Python application...
2026-02-05 16:25:32,145 - huawei.main - INFO - 📋 Logging initialized: DEBUG
2026-02-05 16:25:32,146 - huawei.main - DEBUG - 📋 External loggers: pymodbus=INFO, huawei_solar=INFO
2026-02-05 16:25:32,146 - huawei.main - INFO - 🚀 Huawei Solar → MQTT starting
2026-02-05 16:25:32,146 - huawei.main - DEBUG - Host=192.168.XXX.XXX:502, Slave=**16**, Topic=huawei-solar
2026-02-05 16:25:32,147 - huawei.mqtt - DEBUG - MQTT auth configured for mqttman2
2026-02-05 16:25:32,147 - huawei.mqtt - DEBUG - LWT set: huawei-solar/status
2026-02-05 16:25:32,147 - huawei.mqtt - DEBUG - Connecting MQTT to 192.168.XXX.XXXX:1883
2026-02-05 16:25:32,156 - huawei.mqtt - INFO - 📡 MQTT connected
2026-02-05 16:25:32,556 - huawei.mqtt - DEBUG - MQTT connection stable
2026-02-05 16:25:33,558 - huawei.mqtt - DEBUG - Status: 'offline' → huawei-solar/status
2026-02-05 16:25:33,559 - huawei.mqtt - INFO - 🔍 Publishing MQTT Discovery
2026-02-05 16:25:33,718 - huawei.mqtt - DEBUG - Published 56 numeric sensors
2026-02-05 16:25:33,752 - huawei.mqtt - DEBUG - Published 11 text sensors
2026-02-05 16:25:33,756 - huawei.mqtt - INFO - ✅ Discovery complete: 68 entities
2026-02-05 16:25:33,758 - huawei.main - INFO - ✅ Discovery published
2026-02-05 16:25:33,863 - huawei.main - INFO - 🔌 **Connected (Slave ID: 16)**
2026-02-05 16:25:33,869 - huawei.mqtt - DEBUG - Status: 'online' → huawei-solar/status
2026-02-05 16:25:33,871 - huawei.main - INFO - 🔍 TotalIncreasingFilter initialized (simplified)
2026-02-05 16:25:33,872 - huawei.main - INFO - ⏱️ Poll interval: 20s
2026-02-05 16:25:33,875 - huawei.main - DEBUG - Cycle #1
2026-02-05 16:25:33,876 - huawei.main - DEBUG - Starting cycle
2026-02-05 16:25:33,876 - huawei.main - DEBUG - Reading 67 essential registers
2026-02-05 16:25:33,877 - huawei_solar.huawei_solar - INFO - Waiting for connection
2026-02-05 16:25:35,296 - backoff - INFO - Backing off _do_read(...) for 1.0s (huawei_solar.exceptions.SlaveFailureException)
2026-02-05 16:25:36,305 - backoff - INFO - Backing off _do_read(...) for 2.0s (huawei_solar.exceptions.SlaveFailureException)
2026-02-05 16:25:38,310 - backoff - INFO - Backing off _do_read(...) for 4.0s (huawei_solar.exceptions.SlaveFailureException)
2026-02-05 16:25:42,320 - backoff - INFO - Backing off _do_read(...) for 8.0s (huawei_solar.exceptions.SlaveFailureException)
2026-02-05 16:25:50,335 - backoff - INFO - Backing off _do_read(...) for 16.0s (huawei_solar.exceptions.SlaveFailureException)
2026-02-05 16:26:06,346 - backoff - ERROR - Giving up _do_read(...) after 6 tries (huawei_solar.exceptions.SlaveFailureException)
Thank you!
HANT
PS. Edit - now the running values are shown in the config page.
A weird caching issue at last?
Hey @HANT.
Yes, I’ve noticed that too, and it happens with every app – formerly known as an Add-on. 
It’s due to a problem with reloading the page after saving and retrieving the configuration data. If you leave a specific app’s page and reopen it, the configuration values are displayed correctly. Unfortunately, there’s nothing I can do about it.
Ok. I thought so. I have never fiddled around w/add-ons aeh apps yet, so I did not notice it until now.
So, no worries here.
HANT
It’s nice to see this new Huawei Integration (Addon, App,. Whatever).
However, I think the most beneficial thing would be a fusion of both projects. wlcrs offers a lot, especially with active controls that I use daily (battery charging, setting charge power so my EV doesn’t drain the Luna etc), but Modbus is a bottleneck. Connection anything else just doesn’t work, unless you use a Modbus Proxy, and my experience with Modbus Proxy has been…bad.
So no way to get evcc working or linking to the Everhome ecosystem etc.
If we could use the wlcrs Integration with mqtt added in, that would be perfect IMHO!
Hi @CommanderROR!
Thanks for the feedback - I totally understand where you’re coming from!
The Modbus bottleneck challenge
You’re absolutely right: the “one connection only” limitation is frustrating. I tried Modbus proxies myself and… let’s just say they cost me my last nerve. 
That’s partly why I built huABus the way I did.
Why separate projects make sense (for now)
wlcrs/huawei_solar and huABus have fundamentally different philosophies:
- wlcrs: Native HA integration with active control (battery management, power limits)
- huABus: MQTT bridge focused on read-only monitoring
Merging them would mean adding control features → liability & complexity I deliberately want to avoid.
Your EV charging concern
Regarding “setting charge power so my EV doesn’t drain the Luna” - that’s exactly what EVCC handles brilliantly!
My setup (which uses huABus):
- EVCC is the orchestrator (wallbox = leading device, not inverter)
- huABus provides real-time data via MQTT
- EVCC reads solar/battery/grid and controls the wallbox charging rate
- No active inverter control needed at all!
Been running this for months - rock-solid. The intelligence sits in EVCC, not in the inverter integration.
Future: MQTT in wlcrs?
That would be ideal! Maybe worth opening a feature request there? I’d be happy to contribute knowledge if @wlcrs is interested.
My stance
I built huABus with KISS, stability, and legal safety as core principles. Control features introduce hardware risks and liability I’m not comfortable with as a solo maintainer.
Never say never though! 
If there’s massive demand + someone wants to co-maintain that part - I’m open to discussion.
Feature requests within my principles (read-only, MQTT improvements, external integrations)? Happy to implement!
1 Like
Thanks for your reply.
evcc is a nice project, but so far it has always been something I have avoided since it never really did what I needed it to do. evcc is heavily focused on EV Chargers (and my Zappi isn’t supported anyway) and I mostly control my Luna and Zendure battery😁
Coming Soon: huABus v1.8.0 - Auto Slave ID Detection
Tired of guessing your inverter’s Slave ID? v1.8.0 fixes that!
What’s New
Automatic Slave ID Detection 
No more trial-and-error. The add-on now automatically detects the correct Slave ID (tries 0, 1, 2, 100).
Before: 
slave_id: 1 # Wrong? Restart... try 0... restart...
Now:
New toggle in the UI - just enable and forget!
Setup in Seconds
🔍 Auto-detecting Slave ID for 192.168.1.100:502...
✅ Auto-detected Slave ID: 1
Key Features
- Zero configuration - works out of the box
- 100% backward compatible - existing setups unchanged
- Manual mode available - for advanced users
Release Status
Currently in final testing. Release: Very soon!
Want to beta test? Please contact me directly!
Links
Very interesting as I ended up with my set-up to have to use ID: 2 a rather unusual setting.
An automatism would have been helpful to me
Good idea! Looking forward to V1.8.0.
HANT
huABus v1.8.0 Released - Automatic Slave ID Detection & Enhanced MQTT Auto-Config
Hi everyone! 
I’m excited to announce huABus v1.8.0 - a major usability update that makes installation significantly easier!
What’s New
Automatic Slave ID Detection
No more guessing! The addon now automatically tries common Slave IDs (0, 1, 2, 100) on startup. Just configure your inverter IP and you’re good to go:
modbus_host: "192.168.1.100"
modbus_auto_detect_slave_id: true # Default
log_level: "INFO"
Startup logs now show:
INFO - Inverter: 192.168.1.100:502 (Slave ID: auto-detect)
INFO - Trying Slave ID 0... ⏸️
INFO - Trying Slave ID 1... ✅
INFO - Connected (Slave ID: 1)
Enhanced MQTT Auto-Configuration
The addon now seamlessly uses Home Assistant MQTT Service credentials - just leave the MQTT settings empty and it handles everything automatically!
Dynamic Register Count
Startup logs now display the exact number of registers read from your inverter for better transparency.
About huABus
For those new here: huABus is a Home Assistant addon that bridges your Huawei Solar inverter to MQTT using Modbus TCP, providing:
- 69+ entities with automatic Home Assistant discovery
- Fast polling (~2-5s cycle time, 58 essential registers)
- Total increasing filter to prevent false counter resets in energy statistics
- Comprehensive monitoring: PV strings, battery, 3-phase grid, smart meter
- All architectures supported: aarch64, amd64, armhf, armv7, i386
Links
- GitHub Repository: arboeh/huABus
- Documentation: DOCS.md
- Changelog: CHANGELOG.md
- Quick Install: Settings → Addons → Addon Store (⋮) → Repositories → Add
https://github.com/arboeh/huABus
Compatibility
Fully tested with SUN2000 series (2KTL-100KTL). Compatible with SUN3000/5000 models - if you’re using one, please share your experience!
Feedback Welcome
Questions, issues, or suggestions? Feel free to:
- Open a GitHub Issue
- Reply to this thread
- Submit a Compatibility Report
Happy monitoring! 
