fix: dcdc_temp published 0.0 on every model without register 3176 (#360, #362)

A regression we shipped in v1.4.0, while fixing this exact class of bug.

7a0d194 identified register 3176 on MOD/MID as the DC-DC stage rather than battery
temperature, and added "dcdc_temp" to the shared TEMPERATURE_SENSORS group with the
note "only appears where a profile actually defines the register, so this is a no-op
elsewhere". That is the belief device_profiles.py exists to warn against: membership
of a profile's sensor set is what creates the entity, and the register only decides
whether it ever gets a value. Three register maps define dcdc_temp. Twenty-six
profiles included the group. Every one of those gained a DC-DC Temperature entity
reporting freezing point forever.

Inverted to opt-in via DCDC_TEMP_SENSOR, applied to the five profiles whose maps
define the register. A sensor group shared by everything is the wrong home for a
sensor only a few models can populate: adding to it is silent, and the failure is
invisible because nothing errors.

Found while auditing the same fault on SPA-TL3, prompted by the #360 scan CSV. That
scan also settled two things guessed at in v1.5.2:

  - registers 94/95 answer 20.0 C and 33.3 C alongside 93 at 37.8 C, so SPH-TL3's
    ipm_temp and boost_temp were phantoms fixable by mapping rather than removal.
    Both profiles sharing that map have been publishing 0.0 for them.

  - input 53/54 = 0/20 and 55/56 = 0/23139 -> 2.0 kWh today, 2313.9 kWh total, with
    the SPA extended block agreeing at 2053-2056. ENERGY_SENSORS was excluded from
    SPA-TL3 on the assumption those count PV generation; they count inverter output,
    which a discharging battery produces. Restored.

    Worth recording: the reporter checked the same registers and said there was no
    real data, because 53 and 55 are the HIGH words and read zero. The file settled
    in seconds what two rounds of asking had not.

test_phantom_temperatures.py fails if a temperature sensor is declared without a
register behind it. Six profiles have pre-existing phantoms with no scan to resolve
them - listed explicitly so the count can only go down, and the list is itself
checked so a name cannot linger there after being fixed.

Scoped to temperatures on purpose. The same check across all sensors is mostly false
positives, because status, last_update and the grid import/export pair are computed
in the coordinator rather than read from an address. A noisy test gets ignored.

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

Author: 0xAHA

RELEASENOTES.md

@@ -4,6 +4,40 @@
 
 ---
 
+## v1.5.3
+
+Issues: #360, #362
+
+- **Fix: a "DC-DC Temperature" sensor reporting 0.0 °C on models that have no such
+  sensor.** Introduced by us in v1.4.0, and it is the same bug that release was fixing.
+
+  v1.4.0 identified register 3176 on MOD/MID as the DC-DC stage rather than battery
+  temperature, and added `dcdc_temp` to the shared temperature sensor group — a group
+  almost every profile includes. Only MOD/MID, SPF and SPE define that register, so every
+  other model gained an entity that could never have a value and published freezing point
+  instead.
+
+  A sensor is created because it is in a profile's set; the register only decides whether
+  it has a value. The note added at the time said the opposite. It now belongs to the
+  profiles that can populate it, and a test fails if a temperature sensor is ever declared
+  without a register behind it.
+
+  **If you saw a DC-DC Temperature entity stuck at 0.0 °C, it will disappear on upgrade.**
+  MOD, MID, SPF and SPE keep theirs — those are real readings.
+
+- **SPH-TL3 and SPA-TL3 gain real IPM and Boost temperatures.** Both sensors were declared
+  but had no registers, so both reported 0.0 °C. A full scan of the #360 device answered
+  registers 94 and 95 with 20.0 °C and 33.3 °C alongside the inverter temperature at
+  37.8 °C, so these are now mapped rather than removed.
+
+- **SPA-TL3 regains Energy Today and Energy Total.** v1.5.2 excluded them, assuming they
+  counted solar generation an AC-coupled inverter does not have. The same scan shows
+  2.0 kWh today and 2313.9 kWh total, with the SPA extended block agreeing at a second
+  address. They measure what the inverter puts out, and a discharging battery produces
+  output like anything else.
+
+---
+
 ## v1.5.2
 
 Issues: #360, #362

custom_components/growatt_modbus/device_profiles.py

@@ -97,10 +97,20 @@
 # hard filter available, so exclusion has to happen here.
 NO_BATTERY_TEMP: Set[str] = {"battery_temp"}
 
-# Same mechanism, different sensor. dcdc_temp reads register 3176 (Bdc1Temp1) on MOD/MID
-# and has no equivalent anywhere in the SPA ranges, so a profile that wants the ordinary
-# inverter/IPM/boost temperatures has to subtract it or ship a permanent 0.0 °C.
-NO_DCDC_TEMP: Set[str] = {"dcdc_temp"}
+# dcdc_temp is NOT in TEMPERATURE_SENSORS, and must not be put back there.
+#
+# It was, briefly, and the consequences were the exact bug the change above exists to
+# prevent. The #362 fix identified register 3176 on MOD/MID as the DC-DC stage and added
+# "dcdc_temp" to the shared TEMPERATURE_SENSORS group — which almost every profile
+# includes. Only three register maps define the register at all, so every other model
+# gained a "DC-DC Temperature" entity reporting 0.0 °C: a phantom created while fixing a
+# phantom, verified on the two profiles that have the register and on none of the
+# twenty-six that don't.
+#
+# Opt in per profile instead. A sensor group shared by everything is the wrong home for
+# a sensor only a few models can populate, because adding to it is silent and the failure
+# is invisible — nothing errors, an entity simply reports freezing forever.
+DCDC_TEMP_SENSOR: Set[str] = {"dcdc_temp"}
 
 BMS_SENSORS: Set[str] = {
     "bms_status", "bms_error", "bms_warn_info",
@@ -112,10 +122,11 @@
 
 TEMPERATURE_SENSORS: Set[str] = {
     "inverter_temp", "ipm_temp", "boost_temp",
-    # MOD/MID expose Bdc1Temp1 at register 3176 — the battery-side DC-DC stage. It was
-    # mapped as battery_temp until #362 identified it against ShineApp. Only appears
-    # where a profile actually defines the register, so this is a no-op elsewhere.
-    "dcdc_temp",
+    # dcdc_temp deliberately absent — see DCDC_TEMP_SENSOR below. It was added here with
+    # the note "only appears where a profile actually defines the register, so this is a
+    # no-op elsewhere", which is the belief this whole file warns against: membership of
+    # the sensor set is what creates the entity, and the register only decides whether it
+    # has a value. It was not a no-op; it put 0.0 °C on twenty-six profiles.
 }
 
 STATUS_SENSORS: Set[str] = {
@@ -613,6 +624,11 @@
     # SPH TL3 SERIES - Hybrid Storage (Three Phase with Battery)
     # ========================================================================
 
+    # dcdc_temp is subtracted from both: it reads register 3176 (Bdc1Temp1), which
+    # exists on MOD/MID and nowhere in the SPH-TL3 map. It was in the sensor set anyway,
+    # so every SPH-TL3 install has been publishing a DC-DC temperature of 0.0 °C. Found
+    # while checking the same class of fault on SPA-TL3 (#360); the other two phantom
+    # temperatures here were fixable by adding registers 94/95, this one is not.
     "sph_tl3_3000_10000": {
         "name": "SPH-TL3 Series 3000-10000",
         "description": "Hybrid 3-phase inverter with battery storage (3-10kW)",
@@ -667,7 +683,7 @@
             # GrowattData field, so a hasattr() gate cannot suppress it — the sensor
             # would be created and publish 0.0 degrees forever. That is the v1.4.1
             # battery-temp bug exactly, and the sensor set is the only hard filter.
-            (TEMPERATURE_SENSORS - NO_DCDC_TEMP) |
+            TEMPERATURE_SENSORS |
             # Every BMS sensor is gated on hasattr(), so only the four registers this
             # profile actually defines (1083/1085/1095/1096) create entities (#360).
             BMS_SENSORS |
@@ -688,10 +704,21 @@
     # entry — the alternative considered was renaming the SPH-TL3 option to mention SPA,
     # which would have made phantom PV entities the documented behaviour.
     #
-    # ENERGY_SENSORS (energy_today/energy_total) is excluded for the same reason it is
-    # excluded from the single-phase SPA profile above: on the SPH map those count PV
-    # generation. Excluding a sensor that would have read zero costs nothing; including
-    # one is the defect being fixed here.
+    # ENERGY_SENSORS was excluded on the assumption that energy_today/energy_total count
+    # PV generation on the SPH map, which an AC-coupled unit has none of. A full scan of
+    # the #360 device refuted that:
+    #
+    #   input 53/54 = 0/20     -> 2.0 kWh today
+    #   input 55/56 = 0/23139  -> 2313.9 kWh total
+    #
+    # and the SPA extended block agrees exactly at 2053-2056, which is a second address
+    # reporting the same quantity. These count what the inverter puts out, and a battery
+    # discharging through it produces output like anything else. Restored.
+    #
+    # Worth recording how close this came to shipping wrong: the reporter checked the
+    # same registers and said there were no real values there, because 53 and 55 are the
+    # HIGH words and both read zero. The data was in 54 and 56. The scan CSV settled in
+    # seconds what two rounds of asking could not.
     "spa_tl3_4000_10000_v201": {
         "name": "SPA-TL3 (AC Storage) 4-10kW",
         "description": "Three-phase AC-coupled battery storage, no solar DC inputs (VPP V2.01)",
@@ -707,6 +734,7 @@
             POWER_FLOW_SENSORS |
             CONSUMPTION_SENSORS |
             ENERGY_BREAKDOWN_SENSORS |
+            ENERGY_SENSORS |
             BATTERY_SENSORS |
             BMS_SENSORS |
             TEMPERATURE_SENSORS |
@@ -791,7 +819,8 @@
         "has_pv3": True,
         "has_battery": True,
         "max_power_kw": 15.0,
-        "sensors": (HYBRID_3P_SENSORS | PV3_SENSORS | BACKUP_BOX_SENSORS) - NO_BATTERY_TEMP,
+        "sensors": ((HYBRID_3P_SENSORS | PV3_SENSORS | BACKUP_BOX_SENSORS | DCDC_TEMP_SENSOR)
+                    - NO_BATTERY_TEMP),
     },
 
     "mod_6000_15000tl3_xh_v201": {
@@ -803,7 +832,8 @@
         "has_pv3": True,
         "has_battery": True,
         "max_power_kw": 15.0,
-        "sensors": (HYBRID_3P_SENSORS | PV3_SENSORS | BACKUP_BOX_SENSORS) - NO_BATTERY_TEMP,
+        "sensors": ((HYBRID_3P_SENSORS | PV3_SENSORS | BACKUP_BOX_SENSORS | DCDC_TEMP_SENSOR)
+                    - NO_BATTERY_TEMP),
     },
 
     # MID 11-30KTL3-XH / MID 8-15KTL3-XHL/JP — three-phase commercial hybrid
@@ -821,7 +851,8 @@
         "has_pv3": True,
         "has_battery": True,
         "max_power_kw": 30.0,
-        "sensors": (HYBRID_3P_SENSORS | PV3_SENSORS | BACKUP_BOX_SENSORS) - NO_BATTERY_TEMP,
+        "sensors": ((HYBRID_3P_SENSORS | PV3_SENSORS | BACKUP_BOX_SENSORS | DCDC_TEMP_SENSOR)
+                    - NO_BATTERY_TEMP),
     },
 
     # ========================================================================

custom_components/growatt_modbus/manifest.json

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

custom_components/growatt_modbus/profiles/sph_tl3.py

@@ -90,7 +90,20 @@
         92: {'name': 'pv_energy_total_low', 'scale': 1, 'unit': '', 'pair': 91, 'combined_scale': 0.1, 'combined_unit': 'kWh', 'desc': 'Total PV energy lifetime LOW'},
 
         # Temperatures
+        #
+        # 94 and 95 were missing while `ipm_temp` and `boost_temp` were both in this
+        # profile's sensor set — so the entities existed and published 0.0 °C on every
+        # SPH-TL3 and SPA-TL3 install. Not a hardware limit: a full scan of the #360
+        # device read 94 = 200 (20.0 °C) and 95 = 333 (33.3 °C) alongside 93 = 378
+        # (37.8 °C), all three plausible and independent.
+        #
+        # The VPP copies at 31130-31132 are mapped further down and read zero on that
+        # device, so the fallback was never going to populate these either.
         93: {'name': 'inverter_temp', 'scale': 0.1, 'unit': '°C', 'signed': True},
+        94: {'name': 'ipm_temp', 'scale': 0.1, 'unit': '°C', 'signed': True,
+             'desc': 'IPM (power module) temperature (confirmed #360 scan)'},
+        95: {'name': 'boost_temp', 'scale': 0.1, 'unit': '°C', 'signed': True,
+             'desc': 'Boost converter temperature (confirmed #360 scan)'},
 
         # Status
         105: {'name': 'fault_code', 'scale': 1, 'unit': ''},

tests/test_phantom_temperatures.py

@@ -0,0 +1,95 @@
+"""Temperature sensors must have a register behind them (#360, #362).
+
+A sensor in a profile's sensor set is created unconditionally. Its `condition` cannot
+save it when the attribute is a `GrowattData` field, because the field always exists with
+a default — so a temperature with no register publishes 0.0 °C forever rather than going
+unavailable. On a dashboard that is a battery or a power module sitting at freezing, which
+reads as a measurement rather than as missing data.
+
+This is the #362 battery_temp bug. It recurred immediately: a full scan of the #360 device
+showed `ipm_temp` and `boost_temp` in the SPH-TL3 sensor set with nothing mapped to them,
+and `dcdc_temp` too — three phantom temperatures on hardware that has been confirmed since
+DTC 3601. Two were fixable by adding registers 94 and 95, which the device answers with
+plausible values; the third has no register anywhere in that map and had to be removed
+from the set.
+
+Scoped to temperatures deliberately. The same check across every sensor produces mostly
+false positives, because sensors such as `status`, `last_update`, `grid_import_power` and
+`grid_export_power` are computed by the coordinator rather than read from an address. A
+noisy test gets ignored, and this class is worth catching precisely.
+"""
+from __future__ import annotations
+
+import importlib
+
+import pytest
+
+_dp = importlib.import_module("growatt_under_test.device_profiles")
+_profiles = importlib.import_module("growatt_under_test.profiles")
+
+INVERTER_PROFILES = _dp.INVERTER_PROFILES
+
+TEMPERATURE_SENSORS = {
+    "inverter_temp", "ipm_temp", "boost_temp", "dcdc_temp", "battery_temp",
+}
+
+
+def _register_names(profile_key: str) -> set[str]:
+    """Every name a profile's register map can produce, including combined pairs."""
+    rmap = _profiles.get_profile(INVERTER_PROFILES[profile_key]["register_map"])
+    assert rmap is not None, (
+        f"{profile_key} names register map "
+        f"{INVERTER_PROFILES[profile_key]['register_map']!r}, which does not resolve"
+    )
+    names: set[str] = set()
+    for space in ("input_registers", "holding_registers"):
+        for reg in rmap.get(space, {}).values():
+            name = reg["name"]
+            names.add(name)
+            for suffix in ("_high", "_low"):
+                if name.endswith(suffix):
+                    names.add(name[: -len(suffix)])
+    return names
+
+
+# Profiles with pre-existing phantom temperatures, recorded rather than hidden.
+#
+# These predate the dcdc_temp regression and are a different problem: the sensor is
+# plausible for the hardware, but no register is mapped and there is no scan from one of
+# these models to say whether the device reports it. Fixing them blind means either
+# inventing an address or deleting a sensor that may work — both need a device.
+#
+# Listed explicitly so the count can only go down. A new profile with a phantom
+# temperature fails; these six are known debt, and removing a name from this list when a
+# scan settles it is the intended way to close them.
+KNOWN_PHANTOM_TEMPERATURES = {
+    "mic_2500_5500mtl_s": {"boost_temp"},
+    "mic_600_3300tl_x": {"boost_temp"},
+    "mic_600_3300tl_x_v201": {"boost_temp"},
+    "spe_8000_12000_es": {"battery_temp", "boost_temp", "ipm_temp"},
+    "spf_3000_6000_es_plus": {"battery_temp", "boost_temp", "ipm_temp"},
+    "tl3_s_3000_15000": {"boost_temp", "ipm_temp"},
+}
+
+
+@pytest.mark.parametrize("profile_key", sorted(INVERTER_PROFILES))
+def test_every_temperature_sensor_has_a_register(profile_key):
+    declared = INVERTER_PROFILES[profile_key]["sensors"] & TEMPERATURE_SENSORS
+    available = _register_names(profile_key)
+    known = KNOWN_PHANTOM_TEMPERATURES.get(profile_key, set())
+    phantom = sorted(declared - available - known)
+
+    # A name that stops being phantom must leave the list, or the list quietly becomes
+    # a place where fixed things are still described as broken.
+    stale = sorted(known - (declared - available))
+    assert not stale, (
+        f"{profile_key} lists {stale} as known phantom temperatures, but they now have "
+        f"registers. Remove them from KNOWN_PHANTOM_TEMPERATURES."
+    )
+
+    assert not phantom, (
+        f"{profile_key} declares temperature sensors with no register to populate them: "
+        f"{phantom}. They will be created and publish 0.0 °C. Either map the register, "
+        f"or subtract the sensor from this profile's set — a hasattr() condition cannot "
+        f"suppress it, because these are GrowattData fields with defaults."
+    )