[App] huABus - Huawei Solar Modbus to MQTT (SUN2/3/5/000 → MQTT → Home Assistant + Auto Discovery)

arboeh · January 17, 2026, 9:23am

Hey! Great question - they’re complementary rather than direct alternatives. Here’s the breakdown:

Different Architectures

wlcrs/huawei_solar is a native HA integration with direct Modbus access. This add-on is an MQTT bridge with Home Assistant MQTT Discovery.

Why I developed this

Personal use case: I wanted MQTT-based monitoring because:

MQTT data accessible to other systems (Node-RED, external dashboards, logging)
Monitoring-only approach - no write operations needed
Lightweight JSON payload for all sensors
Better suited for my inverter scenario

Key Differences

wlcrs/huawei_solar strengths:

Active control services (battery charge/discharge)
GUI configuration
Optimizer data support
Larger community (756 stars)
Serial RS485 + Network support

This add-on strengths:

MQTT-native architecture (pub/sub pattern)
Fast cycle times: 2-5s read cycles for 57 essential registers
Advanced error tracking with downtime statistics
Detailed performance monitoring in DEBUG mode
Simple YAML configuration
MQTT stability features (v1.5.0 - COMING SOON!): wait-loop, retry logic, connection resilience
No HACS required

When to use which?

Use wlcrs if you:

Need battery control services
Want GUI configuration
Need optimizer monitoring
Use serial RS485 connection

Use this add-on if you:

Prefer MQTT architecture
Only need monitoring (read-only)
Want data accessible to non-HA systems
Need granular performance metrics

Important Note

Both share the same limitation: Huawei inverters allow only ONE Modbus connection. To run both simultaneously, you’d need a Modbus Proxy to multiplex the connection.

Development Philosophy

wlcrs targets feature-rich integration with HA’s native capabilities. This add-on focuses on reliable MQTT-based monitoring with detailed observability (error tracking, performance metrics, cycle statistics).

Both use the same excellent huawei-solar Python library underneath, so register compatibility is identical.

TL;DR: Different tools for different needs - wlcrs for active control + native HA integration, this add-on for MQTT-based monitoring with performance insights. Not competitors, just different approaches to the same hardware.

ThomDietrich · January 18, 2026, 9:24pm

Great answer! Sounds like it’s not necessarily for me but many others.

You might want to add this message to the end of your README.

HANT · January 21, 2026, 2:27pm

Hi there,

I have an issue with the reported solar export value in kWh. This value sometimes drops to ZERO. This results in heavy jumps in export values, when it is used in a helper defined as a utility meter for daily export values.

Is there an easy way to prevent this?
Or can the daily export value calculated by the add-on itself?

Maybe I am just doing stupit things.

Here you see the frequent drops to ZERO.

Each time it seems the helper sees the restored value as a new happened export leading to absurd values for the daily export.

Thanks,
HANT

HANT · January 21, 2026, 5:54pm

I want to add, that polling frequency is set to a reasonable 30s.
That should not cause it?

Thanks,
HANT

arboeh · January 22, 2026, 6:23am

Hello, which version of the add-on are you using? What does the log say? Is the connection stable? Without a log, it’s just guesswork.

HANT · January 22, 2026, 7:54am

The log looks fine to me. I could not find errors.
The cycle time fluctuates quite a bite though, but connection seem to be stable. Other entities do not show such a behavior (drop value to an initial state).

In theory, the value should only increase. The time it drops is when the inverter is changed (but I have not checked, if the value can be resetted in the inverter itself).

Running version: 1.5.1 of the add-on (latest to my knowledge)

Dongle: V200R022C10SPC312
Inverter: (20KTL-M2) V100R001C00SPC173
HA OS 2026.1.2

Hope this helps!
Thanks,
HANT

arboeh · January 22, 2026, 5:20pm

Hi,

thanks for reporting this issue. Before we implement any filtering solution, I’d like to understand the root cause of why the export values are dropping to zero.

Diagnostic Request

Could you please check your add-on logs during the times when the export value drops to 0? Specifically, look for:

Modbus communication errors (timeouts, connection failures)
Inverter state changes (standby, shutdown, restart)
Any warnings or error messages in the logs

In my own testing, I don’t see these drops because my Modbus communication remains stable without interruptions. This suggests the zeros might be:

Actual values returned by your inverter under certain conditions
Communication issues at specific times
A specific inverter state/behavior

Potential Solutions (in order of preference)

1. Identify and fix the root cause (Best)

If logs show communication errors or inverter state changes, we should address why this happens rather than masking it.

2. Template filter sensor in Home Assistant (Workaround)

template:
  - sensor:
      - name: "Solar Export Filtered"
        state: >-
          {% set current = states('sensor.huawei_solar_inverter_grid_energy_exported') | float(0) %}
          {% set previous = states('sensor.solar_export_filtered') | float(0) %}
          {{ current if current > 0 else previous }}

Caveat: This treats symptoms, not the cause. We’re ignoring zeros without understanding why they occur.

3. Filter zeros in the add-on (Last resort)

Implementing zero-value filtering in the add-on would also just mask the underlying issue. While it would provide a cleaner solution than individual template sensors, it still doesn’t address why the inverter is reporting zeros.

My Assessment

I believe we should first diagnose the actual cause before implementing any filtering. The zeros might indicate:

A legitimate inverter behavior we need to understand
A configuration issue that can be fixed
A timing issue with register reads

Could you share your logs from a period where the drops occurred? This will help us determine if this is a data quality issue or expected inverter behavior.
Reports of similar problems from other users would of course also be helpful - unfortunately there aren’t that many yet…

HANT · January 24, 2026, 9:42am

AI at work?

It has happened again overnight. Unfortunately the logs do not go all the way back to the time (e.g. 4 am) so how could I capture the log the best way?
The log in HA just covers the last minutes it seems to me.
Loglevel is set to DEBUG.

I have no means to trigger the error nor can I set next to the machine and wait for the error to happen.
So as of now, I can not provide the requested logs, or I just do not know how.

Can you tell me the register involved?
[Is it 37119?]

As stated above from other incidents, I have not seen any reported errors in the log and such.
It happens during the day randomly it seems.

Thanks,
HANT

arboeh · January 24, 2026, 9:59am

Hey, yes AI at work. I will see what AI can do for you.

arboeh · January 24, 2026, 10:03am

Hi HANT,

No, 37119 is not the problematic register - that’s “Positive active electricity” (total exported energy in kWh from the meter). The “Low Insulation Resistance” error typically comes from a diagnostic register in the insulation monitoring range (often around 32000–40000, depending on your model).

Capture Persistent Logs

Stop the add-on, then run in HA Supervisor console (or SSH):
docker logs -f addons_data/<your-addon-slug> --tail 1000 > /config/huawei_logs.txt
(Replace <your-addon-slug> with the actual folder name, e.g. a0d7b954_huawei_solar - find it under /addons_data/).
Let it run (-f follows live), wait for the overnight error, then Ctrl+C and download the logs.

Alternatively, disable log rotation in add-on config.yaml: add max_log_lines: 0 alongside log_level: debug if supported.

Fix Random Drops

Downgrade Dongle Firmware: Use V200R022C10SPC126 (not 312 - known Modbus bottleneck).
Reduce Load: Set poll interval >10s, disable diagnostic registers (less stress on Huawei).
Single Connection: Completely disable Huawei integration (only 1 Modbus connection allowed).

Send those DEBUG logs once the error hits - we’ll pinpoint the exact register!

HANT · January 24, 2026, 3:05pm

While you might be correct about being the wrong register, the current issue has nothing to do with insulation monitoring (a parameter I did miss at first and though was not included).

Please see here:

If it is not clear, please let me know.

Thanks for the explanation how to extend the log. I going to try b/c otherhise it would be pure luck to get the right log timing.

Yes, the firmware might be an issue. Some get lucky with 312 some not.
The R022…126 seem to the best compromise, but the downgrade is not straight forward, at least for me and my case.
But it is on the list of the todo list

Regardless of this and as this is the only parameter failing, it would be too easy to blame the connection and the less optimal firmware here. If the connection breaks every once in a while I would expect various different parameters go missing and tilting and not only this one (so far).

So it is worth to get to the bottom of this, if at all possible IMHO.
Especially when the firmware progresses and new users come with a new firmware facing the possible the same thing.

Let me adjust he logging (and hoping to not break the available storage).

Thanks for your effort!
HANT

PS. I run the full HA OS so that docker logging approach does not suit me I guess

arboeh · January 24, 2026, 5:31pm

Hi HANT,

thanks for the detailed info and logs - super helpful! Your observation about the export counter dropping on inverter state changes is spot on and explains the behavior perfectly.

Root Cause Confirmed

The Huawei SUN2000 export total energy register (37119) gets reset by the inverter itself during certain state transitions (standby → running, night mode, or firmware-specific resets). This is normal Huawei behavior - the raw Modbus value isn’t always strictly monotonic.(Sun2000 Modbus Register – Debacher-Wiki)

Your logs confirm stable communication (no errors), so the add-on is working correctly by reporting the actual inverter value.

Quick Fixes for Utility Meters

Use these HA configurations to handle the drops:

utility_meter:
  daily_export:
    source: sensor.huawei_export_total_energy  # your MQTT sensor
    cycle: daily
    delta_values: true  # Ignores resets/drops, calculates only positive deltas

Or add a Riemann sum integration for true energy calculation:

integration:
  - platform: riemann_sum
    source: sensor.huawei_export_power
    name: Huawei Daily Export
    unit_time: kWh
    unit_prefix: k

Long-term Add-on Enhancement

I’ll add optional delta filtering in the next release:

Config option: filter_energy_resets: true
Keeps last valid total, calculates deltas internally
Publishes both raw + filtered values

Firmware Note: SPC312 dongle is indeed slower (5-15s cycles). Downgrading to SPC126 would halve your poll times.

Does delta_values: true solve your utility meter jumps immediately? Let me know how it goes!

Cheers,
Arend

HANT · January 24, 2026, 8:38pm

The only thing (today e.g), there was no such thing as a firmware update or any other event I am aware of. No meter change, no nothing, nor does it reset at night w/ no production (currently it still gives the reasonable number and not zero). At least the add-on does not give a zero here.

It happens randomly during the day. Today about three times.

From your knowledge, what other registers show that behavior as well?
Shouldn’t they show the same thing and ZERO out at such an event?

I could then go and double-check.
Maybe a pattern will emerge.

Thanks,
HANT

arboeh · January 25, 2026, 12:40pm

Version 1.6.0 Released - Protecting Your Energy Statistics!

I’m excited to announce version 1.6.0 of the Huawei Solar Modbus to MQTT add-on, featuring a major improvement for energy statistics reliability!

What’s New: total_increasing Filter

The Problem

Modbus read errors occasionally cause energy counters (total yield, grid export/import, battery totals) to temporarily return 0 or invalid values. When Home Assistant’s total_increasing state class receives these drops, it interprets them as legitimate counter resets, corrupting your long-term energy statistics.

Result: Your Energy Dashboard shows false spikes, wrong accumulated values, and broken statistics that are nearly impossible to fix manually.

The Solution

Version 1.6.0 introduces an intelligent filter that automatically detects and prevents these false counter resets:

Filters negative values (physically impossible for energy counters)
Filters drops > 5% (likely Modbus read errors, configurable via HUAWEI_FILTER_TOLERANCE)
Replaces invalid values with the last known valid value instead of 0
Automatic reset on connection errors to ensure fresh state after reconnects
Visible in logs with inline indicators and periodic summaries

Protected Sensors

The filter automatically protects these critical sensors:

sensor.solar_total_yield
sensor.grid_energy_exported
sensor.grid_energy_imported
sensor.battery_total_charge
sensor.battery_total_discharge

Filter Monitoring

The filter activity is completely transparent in your logs:

Normal operation (INFO level):

2026-01-25 13:25:06 - huawei.main - INFO - Essential read: 6.1s (57/57)
2026-01-25 13:25:06 - huawei.main - INFO - 📊 Published - PV: 890W | AC Out: 296W | Grid: -3W | Battery: 600W
2026-01-25 13:25:06 - huawei.main - INFO - 🔍 Filter summary (last 20 cycles): 0 values filtered - all data valid ✓

When filtering occurs (inline indicator):

2026-01-25 13:25:06 - huawei.main - INFO - 📊 Published - PV: 788W | AC Out: 211W | Grid: 11W | Battery: 569W 🔍[2 filtered]

Every 20 cycles (periodic summary at INFO level):

2026-01-25 13:25:06 - huawei.main - INFO - 🔍 Filter summary (last 20 cycles): 3 values filtered | Details: {'energy_yield_accumulated': 2, 'battery_charge_total': 1}

DEBUG level provides detailed filter info at every event for troubleshooting.

Configuration

The filter works automatically with sensible defaults (5% tolerance).

Advanced: Adjusting Filter Tolerance

If you need to adjust the tolerance, you can set the HUAWEI_FILTER_TOLERANCE environment variable:

Note: This is currently not available in the add-on UI and requires manual configuration via environment variables in your Docker setup or by modifying the add-on configuration files directly.

HUAWEI_FILTER_TOLERANCE: 0.05  # Default: 5% tolerance

Understanding tolerance:

0.05 (5%) - Default, optimal for most installations - no configuration needed!
0.10 (10%) - Less strict, only filters larger drops
Lower values (e.g., 0.03) - More strict, filters smaller drops
Occasional filtering (1-2 per hour) is normal and expected
Frequent filtering indicates Modbus connection issues

For 99% of users: The default 5% works perfectly - no action needed!

Additional Fixes in 1.6.0

Fixed datetime serialization: startup_time now correctly converted to ISO string for JSON compatibility
Improved exception handling: More robust Modbus exception catching
Enhanced documentation: Extensive inline comments (German) for better maintainability

Full Details

Check out the complete CHANGELOG and updated DOCS for all technical details.

Upgrade Notes

Fully backwards compatible - no configuration changes required
Filter activates automatically on first start with optimal 5% tolerance
Filter status visible at INFO log level
Your energy statistics are now protected!
Advanced users can adjust tolerance via environment variables (see docs)

Feedback welcome! If you notice any issues or have suggestions, please open an issue on GitHub.

Happy monitoring!

HANT · January 26, 2026, 9:36am

Cool. I did not expect the update so fast.
Tiptop.

I did not come around to fiddle with my setting more this weekend, so I went ahead and installed just the update.
Now, I am curious what will happen with the counter.

Yesterday was no good day for counting the export as it had many jumps:

Due tothe export parameter visiting the ZERO mark quite frequently yesterday:

But I hope these jumps become a thing of the past.
Too bad that I have caught yet the right log of such incident as I am curios what’s really at work.

Cheers,
HANT

HANT · January 26, 2026, 9:47am

One question comes to mind now.

Rarely but it will happen that some does change or has to change the smart meter (e.g. installing EMMA and removing the smartmeter e.g. DTSU 666-H) is changed?

Will that still work?
As I suspect that the new meter start with a register standing at 0 kWh rightfully so. Or what needs to be done in such case?

Thanks,
HANT

arboeh · January 28, 2026, 8:34pm

Version 1.6.1 Released - Critical Filter Bug Fixed

Hey everyone!

I’ve just released v1.6.1 with an important bug fix that some of you might have been experiencing without even realizing it.

What Was Fixed?

The total_increasing filter (introduced in 1.6.0) was running after MQTT publish instead of before. This meant that temporary Modbus read errors (when the inverter returns 0 for energy counters) could briefly reach Home Assistant and mess up your Utility Meter calculations.

Symptom: Your daily energy counters suddenly jump by thousands of kWh (the entire accumulated energy since installation)

Fix: Filter now runs in the correct order:

Old: Modbus → Transform → Publish (0!) → Filter ❌
New: Modbus → Transform → Filter → Publish ✅

The Challenge of Finding This Bug

Here’s the tricky part: I personally don’t experience these Modbus drops on my system. My inverter behaves nicely and consistently returns valid values. This made it incredibly difficult to debug and reproduce the issue.

Thanks to AI assistance (yes, really! ), I was able to:

Analyze the timing and data flow in detail
Understand how Utility Meters process the data
Identify the exact moment where the zero value was slipping through
Implement the fix in the right place

But here’s where I need your help…

Please Report Back!

If you were experiencing jumps in ANY of these sensors:

sensor.huawei_solar_inverter_energy_yield_accumulated (Solar Total Yield)
sensor.huawei_solar_inverter_grid_energy_exported (Grid Export)
sensor.huawei_solar_inverter_grid_energy_imported (Grid Import)
sensor.huawei_solar_inverter_battery_charge_total (Battery Charge)
sensor.huawei_solar_inverter_battery_discharge_total (Battery Discharge)

Or if your Utility Meters showed unrealistic daily totals

Please update to v1.6.1 and let me know if it’s fixed!

Specifically, I’d love to see:

Confirmation that jumps are gone

Debug logs showing filter activity (set log_level: DEBUG):

DEBUG - Replaced energy_grid_exported: 0 → 5432.1 (filtered)
📊 Published - PV: 0W | ... 🔍[1 filtered]

Filter summary after 20 cycles:

└─> 🔍 Filter summary (last 20 cycles): 3 values filtered | Details: {'energy_grid_exported': 3}

This helps me understand:

How often these Modbus errors actually occur in the wild
Whether the fix is working for everyone
If there are edge cases I haven’t considered

Update Instructions

Update the add-on to v1.6.1
Restart
Monitor your energy counters for 24-48 hours
(Optional) Enable log_level: DEBUG to see filter activity

Why Community Feedback Matters

I can’t test scenarios I don’t experience myself. Your logs and reports are incredibly valuable for:

Validating the fix works in real-world conditions
Understanding different inverter behaviors
Catching edge cases I might have missed
Improving the add-on for everyone

So if you update and it works or if you still see issues , please drop a comment below or open an issue on GitHub!

Changelog: v1.6.1
Issue that triggered this fix: #7

Thanks for being part of this journey!

— arboeh

HANT · January 28, 2026, 11:14pm

I guess it works most of the time, but it might miss the first bit of production (the very first amount of energy produced) as ZERO value is ignored?

Example:

new meter is installed
the reported first ZERO is ignored
0,03 kWh are exported and 0.03 kWh is the first value reported

Question: Is this 0.03kWh being added to the export energy?

Nevertheless, that ‘loss’ seem to be acceptable as long as the updates from the inverter happened frequently.

For now, I have installed the newest version (1.6.1) and I will report back, if that issue of ZERO values has become a thing of the past or not.

Thanks,
HANT

arboeh · January 29, 2026, 6:43am

Great question! Let me address your concern about the meter change scenario.

Yes, the 0.03 kWh WILL be reported correctly!

Here’s why: The filter only ignores backwards jumps (drops) that are likely read errors, not legitimate small values.

Your scenario:

New meter installed → First read: 0 kWh (accepted as first value)
Next cycle: 0.03 kWh (accepted, it’s higher than 0)
Next cycle: 0.15 kWh (accepted, still increasing)

The filter logic is:

IF current_value < last_value * (1 - tolerance):  # Default 5% tolerance
    → Filter it (likely a read error)
ELSE:
    → Accept it (normal increase or first value)

So 0.03 after 0 is totally fine — it’s an increase, not a drop!

The Only Edge Case (Very Rare)

The only time you’d lose a tiny bit of data is if:

The very first read after meter installation returns a Modbus error (e.g., 0 due to timeout)
The filter replaces it with the “last known value” (which doesn’t exist yet)
So it might skip that first error and wait for the next valid read

But this is:

Extremely rare (would require a Modbus error at exactly the first read)
Negligible loss (at most one poll interval’s worth, maybe 0.01-0.05 kWh)
Much better than the alternative (false resets adding thousands of kWh!)

Looking Forward to Your Report!

Thanks for updating to 1.6.1 and committing to report back! That’s exactly the kind of real-world feedback I need.

If you enable log_level: DEBUG, you’ll see exactly when the filter activates:

DEBUG - Replaced energy_grid_exported: 0 → 5432.1 (filtered)

This will tell us how often these Modbus glitches actually happen on your system.

TL;DR: Your 0.03 kWh will be counted. The filter protects against drops (errors), not small increases (real data).

— arboeh

HANT · January 29, 2026, 8:12am

I think that’s missing one or two :
4. Next cycle: 0.00 kWh not accepted and not published to MQTT [??]
5. Next cycle: 0.25 kWh (accepted, still increasing from 0.15kWh or from 0.00kWh?)

If it compares it with 0.00 kWh, it is fine I guess (for a meter change?). So what does the last_value hold? Last value received or last value published to MQTT?

Nevertheless, the data is polled top frequently to create any meaningful difference under normal circumstances, I suppose.

Issue is still there
Back to the issue here w/ the ZERO drops [sensor.huawei_solar_inverter_grid_energy_exported].
Unfortunately, they still happen quite frequently for me:

Running the latest 1.6.1 version currently.

Thanks,
HANT