Don't let an ambiguous cause code raise a fault

Two review findings on the new appliance-status and electricity metadata.

The cause-only fallback kept the first-seen mapping when several display
codes share a cause. Nine causes have display variants that disagree, and
two of them turn a normal state into a fault: cause 273 is a 24h safety
shutdown under display 3F but flame monitoring under 0U, and 280 is a
restart-time fault under 7L but a fan start under 0U. 0U codes 270-274,
280 and 281 are the normal ignition sequence, so a boiler that is merely
starting up with no display code would report a safety shutdown. Build
the fallback only from causes whose variants agree; ambiguous ones read
unknown and keep their raw codes on the entity attributes.

Also revert the electricity dayAverage/monthAverage promotion to
device_class=ENERGY + state_class=TOTAL + last_reset. The paths are named
average, and an average that falls as well as rises is not a TOTAL: HA
reads each decrease as a meter reset and the sensor becomes selectable as
an Energy Dashboard source. Wrong long-term statistics are painful to
unwind, so these stay plain sensors until someone watches the value
across a full day on real hardware.

Author: CaseyRo

custom_components/bosch/pointtapi_entities.py

@@ -174,14 +174,23 @@ def _build_appliance_status_by_cause(
 ) -> dict[int, str]:
     """Build a cause-only fallback map from the pair table.
 
-    Keep the first seen mapping for a cause code to preserve the intended
-    primary meaning when multiple display codes share the same cause.
+    Only causes whose display variants all mean the same thing get a fallback.
+    Where they disagree the cause alone does not identify the state — cause 273
+    is a 24h safety shutdown under display 3F but normal flame monitoring under
+    0U, and 280 is a restart-time fault under 7L but a normal fan start under
+    0U — so those are left out and read as unknown rather than raising a fault
+    for a boiler that is simply starting up. The raw codes stay on the entity
+    attributes either way.
     """
 
-    by_cause: dict[int, str] = {}
+    candidates: dict[int, set[str]] = {}
     for (_display, cause), status in by_code.items():
-        by_cause.setdefault(cause, status)
-    return by_cause
+        candidates.setdefault(cause, set()).add(status)
+    return {
+        cause: statuses.pop()
+        for cause, statuses in candidates.items()
+        if len(statuses) == 1
+    }
 
 
 _APPLIANCE_STATUS_BY_CAUSE: dict[int, str] = _build_appliance_status_by_cause(
@@ -785,12 +794,6 @@ def _start_of_today() -> Any:
     return dt_util.start_of_local_day()
 
 
-def _start_of_month() -> Any:
-    """Return start of the current month in local timezone for last_reset."""
-    now = dt_util.now()
-    return now.replace(day=1, hour=0, minute=0, second=0, microsecond=0)
-
-
 # ── Hourly gas usage helper functions ────────────────────────────────────────
 
 
@@ -1473,35 +1476,29 @@ def _pointtapi_electricity_average_sensor_descriptions(
 
     Exposes /energy/electricity/dayAverage and /energy/electricity/monthAverage
     only when the appliance reports those resources as available.
+
+    Deliberately carries no device_class/state_class: the paths are named
+    "average", and an average that falls as well as rises is not a TOTAL. Given
+    state_class=TOTAL plus last_reset, HA reads every decrease as a meter reset
+    and the sensor becomes selectable as an Energy Dashboard source — wrong
+    statistics that are painful to unwind. Promote these only once someone has
+    watched the value across a full day on real hardware.
     """
     if not data:
         return ()
 
     candidates = (
-        (
-            "/energy/electricity/dayAverage",
-            "electricity_day_average",
-            _start_of_today,
-        ),
-        (
-            "/energy/electricity/monthAverage",
-            "electricity_month_average",
-            _start_of_month,
-        ),
+        ("/energy/electricity/dayAverage", "electricity_day_average"),
+        ("/energy/electricity/monthAverage", "electricity_month_average"),
     )
 
     descriptions: list[BoschPoinTTAPISensorEntityDescription] = []
-    for path, translation_key, last_reset_fn in candidates:
+    for path, translation_key in candidates:
         if isinstance(data.get(path), dict) and _path_available(data, path):
             descriptions.append(
                 BoschPoinTTAPISensorEntityDescription(
                     key=path,
                     translation_key=translation_key,
-                    device_class=SensorDeviceClass.ENERGY,
-                    native_unit_of_measurement=UnitOfEnergy.KILO_WATT_HOUR,
-                    state_class=SensorStateClass.TOTAL,
-                    value_fn=lambda d, p=path: _val(d, p),
-                    last_reset_fn=last_reset_fn,
                 )
             )
     return tuple(descriptions)

unittests/test_pointtapi_new_entities.py

@@ -194,10 +194,24 @@ def test_electricity_average_sensors_are_added_when_available(self):
         assert "/energy/electricity/monthAverage" in descs
         assert descs["/energy/electricity/dayAverage"].translation_key == "electricity_day_average"
         assert descs["/energy/electricity/monthAverage"].translation_key == "electricity_month_average"
-        assert descs["/energy/electricity/dayAverage"].native_unit_of_measurement == "kWh"
-        assert descs["/energy/electricity/monthAverage"].native_unit_of_measurement == "kWh"
-        assert descs["/energy/electricity/dayAverage"].device_class == "energy"
-        assert descs["/energy/electricity/monthAverage"].device_class == "energy"
+
+    def test_electricity_averages_carry_no_statistics_metadata(self):
+        """An average is not a TOTAL — keep it out of long-term statistics.
+
+        With state_class=TOTAL, every dip in a rolling average reads as a meter
+        reset and the sensor becomes an Energy Dashboard source. Until someone
+        confirms on hardware that these accumulate, they stay plain sensors.
+        """
+        data = {
+            "/energy/electricity/dayAverage": {"value": 3.21, "available": "true"},
+            "/energy/electricity/monthAverage": {"value": 4.56},
+        }
+        descs = {d.key: d for d in _pointtapi_sensor_descriptions(data)}
+
+        for path in ("/energy/electricity/dayAverage", "/energy/electricity/monthAverage"):
+            assert descs[path].device_class is None
+            assert descs[path].state_class is None
+            assert descs[path].last_reset_fn is None
 
     def test_electricity_average_sensors_are_not_added_when_unavailable(self):
         data = {
@@ -453,6 +467,27 @@ def test_appliance_status_sensor_available_with_only_fault_flags(self):
         assert desc.value_fn is not None
         assert desc.value_fn(data) == "locking_fault_code_active"
 
+    def test_ambiguous_cause_alone_does_not_report_a_fault(self):
+        """Causes whose display variants disagree must not guess a fault.
+
+        273 is a 24h safety shutdown under display 3F but normal flame
+        monitoring under 0U; 280 is a restart-time fault under 7L but a normal
+        fan start under 0U. With no display code the cause alone cannot tell
+        them apart, so it must read unknown rather than alarm on a boiler that
+        is only starting up.
+        """
+        descs = {d.key: d for d in _pointtapi_sensor_descriptions()}
+        desc = descs["/system/appliance/status"]
+        assert desc.value_fn is not None
+        for cause in (273, 280):
+            data = {"/system/appliance/causeCode": {"value": float(cause)}}
+            assert desc.value_fn(data) == "unknown"
+        # Unambiguous causes still resolve without a display code.
+        assert (
+            desc.value_fn({"/system/appliance/causeCode": {"value": 203.0}})
+            == "standby_no_heat_demand"
+        )
+
     def test_appliance_status_sensor_maps_0a_305_to_dhw_lockout(self):
         descs = {d.key: d for d in _pointtapi_sensor_descriptions()}
         desc = descs["/system/appliance/status"]