Bump version to v1.3.4 - a missing 32-bit pair partner no longer decodes as zero (#367)

Reported by tdalejandro: pv1_power published as 65,536,000 W and pv2_power as 109,544,683 W, with the same values recurring byte-for-byte 14 hours apart. The repetition identified the cause.

Decoded as 32-bit pairs, two of the three impossible values had a low word of exactly zero. _get_register_value() substituted 0 for a pair register missing from the read cache, so a truncated block capturing the high word but not the low word decoded as (high << 16) - a high word of 10000 becoming 65,536,000 W. Those values went into HA long-term statistics as real measurements.

The protocol is unambiguous: UINT32/INT32 are defined as high word first, low word last, and every 32-bit register table entry declares a length of 2. A 32-bit value always occupies both registers, so a missing partner cannot mean zero - it means the read did not complete. The decoder now returns None.

Protocol-level rather than profile-specific, so it applies to every 32-bit register in every profile. The only behaviour change is that a value which was previously garbage now reads as no value; a complete pair whose high word is genuinely 0 still decodes normally, which is covered by test.

Three regression tests added. 191 pass, including every pre-existing decode test.

NOT fixed: five call sites in the WIT battery-power path use the same substitution, but there pair_addr may legitimately be None - the profile genuinely having no high word - which is a different case from a register that exists but was not read. Separating those safely needs a WIT owner to verify given that path's history in #247 and #323.

Co-Authored-By: Claude <noreply@anthropic.com>

Author: 0xAHA

README.md

@@ -3,7 +3,7 @@
 # Growatt Modbus Integration for Home Assistant ☀️
 
 ![HACS Badge](https://img.shields.io/badge/HACS-Custom-orange.svg)
-![Version](https://img.shields.io/badge/Version-1.3.3-blue.svg)
+![Version](https://img.shields.io/badge/Version-1.3.4-blue.svg)
 [![GitHub Issues](https://img.shields.io/github/issues/0xAHA/Growatt_ModbusTCP.svg)](https://github.com/0xAHA/Growatt_ModbusTCP/issues)
 [![GitHub Stars](https://img.shields.io/github/stars/0xAHA/Growatt_ModbusTCP.svg?style=social)](https://github.com/0xAHA/Growatt_ModbusTCP)
 

RELEASENOTES.md

@@ -4,6 +4,45 @@
 
 ---
 
+## v1.3.4
+
+Issues: #367
+
+- **Fix: a truncated read could fabricate physically impossible values and write them into
+  long-term statistics.**
+  Reported by @tdalejandro with unusually good evidence — `pv1_power` published as
+  **65,536,000 W**, `pv2_power` as **109,544,683 W**, and the same values recurring
+  byte-for-byte 14 hours apart. That repetition is what identified the cause.
+
+  Decoded as 32-bit pairs, two of the three impossible values had a low word of *exactly
+  zero*. The decoder was substituting `0` for a pair register missing from the read cache,
+  so a truncated block that captured the high word and not the low word decoded as
+  `high << 16` — a high word of 10000 becoming 65,536,000 W.
+
+  The protocol leaves no ambiguity here: `UINT32`/`INT32` are defined as "high word first,
+  low word last", and every 32-bit entry in the register table declares a length of 2. A
+  32-bit value always occupies both registers, so a missing partner cannot mean zero — it
+  means the read did not complete. The decoder now returns no value in that case.
+
+  This is protocol-level rather than profile-specific, so it applies to every 32-bit
+  register across every profile.
+
+  **What changes for you:** nothing, unless your gateway is truncating responses. Values
+  that previously appeared as millions of watts will now read 0 for that poll instead.
+  Still not ideal, but it no longer corrupts Energy Dashboard history — which is
+  permanent, and has to be repaired by hand.
+
+- **Note:** if you already have corrupted hourly statistics, Developer Tools → Statistics
+  can correct the affected means without touching the database.
+
+- **Known remaining:** five call sites in the WIT battery-power path use the same
+  substitution. They are not fixed here because in that code `pair_addr` may legitimately
+  be `None` — meaning the profile genuinely has no high word — which is a different case
+  from "the register exists but wasn't read". Separating those safely needs a WIT owner to
+  verify, given that path's history in #247 and #323.
+
+---
+
 ## v1.3.3
 
 Issues: #361

custom_components/growatt_modbus/growatt_modbus.py

@@ -1229,16 +1229,36 @@ def _get_register_value(self, address: int) -> Optional[float]:
                 scale = reg_info.get('scale', 1)
                 return raw_value * scale
 
+            # A 32-bit value ALWAYS occupies both registers — the protocol defines
+            # UINT32/INT32 as "high word first, low word last", and every 32-bit entry in
+            # the register table declares a length of 2. So a partner missing from the
+            # cache never means "zero"; it means the read did not complete.
+            #
+            # Substituting 0 here fabricated values out of data that never arrived. A
+            # truncated block that captured the high word but not the low word decoded as
+            # (high << 16): a high word of 10000 was published as 65,536,000 W of PV power,
+            # and went straight into Home Assistant's long-term statistics (Issue #367).
+            #
+            # Returning None instead lets the caller treat the value as unread.
+            partner_value = self._register_cache.get(pair_addr)
+            if partner_value is None:
+                logger.debug(
+                    "Register %d is a 32-bit pair with %d, but %d was not read — "
+                    "returning no value rather than assuming 0",
+                    address, pair_addr, pair_addr,
+                )
+                return None
+
             # Check which register is HIGH and which is LOW
             if address < pair_addr:
                 # Current address is HIGH, pair is LOW
                 high_value = raw_value
-                low_value = self._register_cache.get(pair_addr, 0)
+                low_value = partner_value
                 combined_scale = pair_info.get('combined_scale', 1)
             else:
                 # Current address is LOW, pair is HIGH
                 low_value = raw_value
-                high_value = self._register_cache.get(pair_addr, 0)
+                high_value = partner_value
                 combined_scale = reg_info.get('combined_scale', 1)
 
             # Combine 32-bit value

custom_components/growatt_modbus/manifest.json

@@ -12,5 +12,5 @@
     "pymodbus>=3.0.0",
     "pyserial>=3.4"
   ],
-  "version": "1.3.3"
+  "version": "1.3.4"
 }

tests/test_register_decoding.py

@@ -130,6 +130,52 @@ def test_register_absent_from_cache_returns_none_not_zero():
     assert client._get_register_value(400) is None
 
 
+def test_pair_with_missing_partner_returns_none_not_a_fabricated_value():
+    """Regression guard for Issue #367.
+
+    A truncated block read can capture a 32-bit value's high word and not its low word.
+    The decoder used to substitute 0 for the missing half, producing (high << 16) — a
+    high word of 10000 was published as 65,536,000 W of PV power and written into Home
+    Assistant's long-term statistics as if it were a real measurement.
+
+    The protocol defines UINT32/INT32 as "high word first, low word last" and every
+    32-bit register table entry declares a length of 2, so a missing partner can only
+    mean the read failed. It must decode to nothing.
+    """
+    regs = {
+        5: {"name": "pv1_power_high", "scale": 1, "pair": 6},
+        6: {"name": "pv1_power_low", "scale": 1, "pair": 5, "combined_scale": 0.1},
+    }
+    # High word arrived, low word did not — exactly the reported failure.
+    client = _client(regs, {5: 10000})
+    assert client._get_register_value(5) is None
+
+    # And the same when only the low word arrived.
+    assert _client(regs, {6: 1234})._get_register_value(6) is None
+
+
+def test_the_exact_reported_value_can_no_longer_be_produced():
+    """65,536,000 W from Issue #367 was (10000 << 16) * 0.1 with a missing low word."""
+    regs = {
+        5: {"name": "pv1_power_high", "scale": 1, "pair": 6},
+        6: {"name": "pv1_power_low", "scale": 1, "pair": 5, "combined_scale": 0.1},
+    }
+    assert _client(regs, {5: 10000})._get_register_value(5) != pytest.approx(65536000.0)
+
+
+def test_complete_pair_still_decodes_when_partner_is_zero():
+    """A partner genuinely READ as 0 is valid and must still decode.
+
+    The fix keys on absence from the cache, not on the value being falsy — a high word
+    of 0 is the normal case for any value below 65536.
+    """
+    regs = {
+        5: {"name": "power_high", "scale": 1, "pair": 6},
+        6: {"name": "power_low", "scale": 1, "pair": 5, "combined_scale": 0.1},
+    }
+    assert _client(regs, {5: 0, 6: 2500})._get_register_value(6) == pytest.approx(250.0)
+
+
 def test_register_not_in_profile_returns_none():
     client = _client({400: {"name": "pv1_voltage", "scale": 0.1}}, {999: 123})
     assert client._get_register_value(999) is None