Solarmax: History drops to 0.0 kWh when a meter's `energy` register is removed — no fallback to power integration for existing entities

[thebrainkafka]

Description

Title: History drops to 0.0 kWh when a meter's energy register is removed — no fallback to power integration for existing entities

Follow-up to #32324 / #32497.

#32497 fixed the whole-kWh-resolution problem for solarmax-inverter-smt.yaml by dropping the energy register and relying on power integration for the history instead. The same fix later landed for solarmax-maxstorage.yaml (pv usage, register 150) as well.

However, after this change, my PV Dach meter (SolarMax Ultimate, solarmax-maxstorage.yaml, pv usage) stopped accumulating any history at all — the daily chart showed a flat 0.0 kWh all day, even though live power was completely normal and non-zero throughout the day. A second pv meter (different device) on the same instance continued to work correctly in parallel.

Root cause (from inspecting the sqlite DB, entities table):

id | group | name  | title    | is_temp | energy_meter | return_energy_meter
4  | pv    | db:6  | PV Dach  |         | 54716.0      |
8  | pv    | db:21 | PV West  | 0       | 123.894082   | 0.00942500000000291

energy_meter for PV Dach is a flat whole number (54716.0) — clearly a stale leftover from when the meter still had a working energy register, not something produced by power integration (compare PV West: fine-grained decimals, actively updated). After the register was removed from the template, this entity's energy_meter appears to simply stop being updated at all, instead of falling back to power integration.

As a workaround I re-added the energy register (150, int32s, no scale) via a custom meter, which restores history accumulation (with the original whole-kWh-resolution gaps from #32324, but at least a moving/plausible total — preferable to a flat 0.0 kWh).

Expected: once a meter's energy capability is removed from its template, existing entities for that meter should transparently start being computed via power integration, the same way a newly configured meter without an energy register would.
Actual: the entity's energy_meter in the DB stays frozen at its last known value, and daily history shows 0.0 kWh despite normal live power.

Happy to provide further sqlite dumps or logs if useful.

Steps to Reproduce

Custom Meter

⚠️ RETURN TO EVCC TAB → COPY STEP 2 → PASTE HERE

Version

v0.315.0-dev+a578893ed

System

linux/arm64, CEST +02:00

[thebrainkafka]

Logs

[lp-1  ] DEBUG 2026/08/22 19:36:35 !! plan: plan time zero
[lp-1  ] DEBUG 2026/08/22 19:36:35 limitSoc reached: 85.0% > 85%
[site  ] DEBUG 2026/08/22 19:37:05 ----
[lp-1  ] DEBUG 2026/08/22 19:37:05 charge power: 0W
[lp-1  ] DEBUG 2026/08/22 19:37:05 charge currents: [0 0 0]A
[GoECharger] DEBUG 2026/08/22 19:37:05 power: 0W
[GoECharger] DEBUG 2026/08/22 19:37:05 current: 0A
[main  ] DEBUG 2026/08/22 19:37:05 power: -76W
[main  ] DEBUG 2026/08/22 19:37:05 current: 0A
[site  ] DEBUG 2026/08/22 19:37:05 grid power: -76W
[site  ] DEBUG 2026/08/22 19:37:05 battery 2 power: 125W
[site  ] DEBUG 2026/08/22 19:37:05 battery 1 power: 142W
[site  ] DEBUG 2026/08/22 19:37:05 pv 2 power: 373W
[site  ] DEBUG 2026/08/22 19:37:05 pv 1 power: 36W
[site  ] DEBUG 2026/08/22 19:37:05 pv power: 409W
[site  ] DEBUG 2026/08/22 19:37:05 battery 1 soc: 87%
[site  ] DEBUG 2026/08/22 19:37:05 battery 2 soc: 93%
[site  ] DEBUG 2026/08/22 19:37:05 battery power: 267W
[site  ] DEBUG 2026/08/22 19:37:05 battery soc: 92%
[site  ] DEBUG 2026/08/22 19:37:05 site power: 291W
[lp-1  ] DEBUG 2026/08/22 19:37:05 charge voltages: [232 232 232]V
[lp-1  ] DEBUG 2026/08/22 19:37:05 charge total import: 14553.526kWh
[lp-1  ] DEBUG 2026/08/22 19:37:05 charger status: B
[lp-1  ] DEBUG 2026/08/22 19:37:05 !! plan: plan time zero
[lp-1  ] DEBUG 2026/08/22 19:37:05 limitSoc reached: 85.0% > 85%

[github-actions]

Analysis

Confirmed root cause in core/metrics/collector.go.

Collector.AddEnergy decides whether a direction is "metered" (and therefore skips power integration) with:

hasEnergyMeter := energyTotal != nil || c.accu.energyMeter != nil

c.accu.energyMeter is seeded once at startup from the persisted entities.energy_meter DB column (collector.go:44-52, via Accumulator.Restore). This heuristic was added in #30605 to stop a transient failed meter read (a single nil) from causing a double-count on the next successful read — a direction that has ever reported a total keeps being treated as metered even through a temporary read failure.

The problem: once solarmax-maxstorage.yaml's energy register was removed (#32986, following #32497), the meter permanently stops implementing api.MeterEnergy, so energyTotal is nil on every single poll from now on (see core/site.go:1026, capability is a static Go-interface check, not a per-read outcome). For an entity that already had a stale non-nil energy_meter value in the DB from before the template change, c.accu.energyMeter != nil stays permanently true, so hasEnergyMeter never becomes false and AddPower (the fallback integration) is never invoked. The stale DB value is also never overwritten, matching the flat 54716.0 observed for "PV Dach" while "PV West" (never had that register) accumulates normally.

A newly-configured entity for the same meter type doesn't hit this, because it starts with energy_meter = NULL, so hasEnergyMeter correctly evaluates to false from the start.

Affected code: core/metrics/collector.go (Collector.AddEnergy, NewCollector/Accumulator.Restore). Not specific to SolarMax — any meter/entity whose template drops an energy register (or otherwise loses MeterEnergy capability) while it has a previously-persisted energy_meter value will hit the same permanent freeze.

This looks fixable, but the correct fix needs a bit of design thought: the collector currently has no way to distinguish "capability permanently gone" from "transient read failure" purely from a nil reading, and the transient-failure tolerance from #30605 is intentional and should be kept. A caller-supplied capability flag (rather than inferring solely from the DB-restored/observed total) is probably needed to resolve it correctly, so I'm not opening a PR for this myself.

cc @andig

🤖 Generated with Claude Code

[thebrainkafka]

Thanks for the fix — I can confirm it works, but only partially in my testing on 0.314.3.

Setup: SolarMax MAX.STORAGE Ultimate, pv usage, register 110 (power), no energy register per the current template.

Case A — official template (solarmax-maxstorage selected via the UI meter picker):
History showed the old cumulative/jumpy pattern from #32324 (large sporadic bars instead of a smooth curve), not power-integrated values.

More telling: when adding a brand-new meter from this template, the "test connection" step in the config dialog — before saving, before any DB row exists — already reports Energie: 54,8 MWh alongside Leistung: 0,0 kW. Screenshot attached. This is not a DB checkpoint issue: there's no entity yet at this point. The template's live test/probe mechanism itself is returning an energy value, despite the rendered YAML for usage: pv having no energy key at all (see full template below). That strongly suggests something in the template instantiation/probing path queries register 150 independently of what's actually in the render block — possibly a generic capability probe tied to the SolarMax product/device rather than the specific configured usage.

Official template (templates/definition/meter/solarmax-maxstorage.yaml, current master):

template: solarmax-maxstorage
products:
  - brand: SolarMax
    description:
      generic: MAX.STORAGE / MAX.STORAGE Ultimate
capabilities: ["battery-control"]
requirements:
  description:
    de: Für Batteriesteuerung muss über den Solarmax Support die Funktion "Connectivity+" freigeschaltet werden. Verfügbar ab Software 3.4.4. Ohne Freischaltung bleibt die Funktion ohne Wirkung.
    en: For batter control, the "Connectivity+" function must be activated via the Solarmax support. Available from software version 3.4.4. Without activation, the function remains without effect.
params:
  - name: usage
    choice: ["grid", "pv", "battery"]
  - name: modbus
    choice: ["tcpip"]
    id: 1
  - name: maxacpower
  - preset: battery-params
  # battery control
  - name: watchdog
    default: 60s
render: |
  type: custom
  {{- if eq .usage "grid" }}
  power:
    source: modbus
    {{- include "modbus" . | indent 2 }}
    register: # manual non-sunspec register configuration
      address: 118 # Einspeise-/Bezugsleistung
      type: input
      decode: int32s
    scale: -1
  {{- end }}
  {{- if eq .usage "pv" }}
  power:
    source: modbus
    {{- include "modbus" . | indent 2 }}
    register: # manual non-sunspec register configuration
      address: 110 # PV-Leistung MAX.STORAGE
      type: input
      decode: int32s
  # energy removed: register 150 (Produzierte PV-Energie) only resolves whole kWh (#32324)
  maxacpower: {{ .maxacpower }}
  {{- end }}
  {{- if eq .usage "battery" }}
  power:  
    source: modbus
    {{- include "modbus" . | indent 2 }}
    register: # manual non-sunspec register configuration
      address: 114 # Batterie-Leistung
      type: input
      decode: int32s
    scale: -1
  soc:
    source: modbus
    {{- include "modbus" . | indent 2 }}
    register: # manual non-sunspec register configuration
      address: 122 # Batterie Soc
      type: input
      decode: int16
  batterymode:
    source: watchdog
    timeout: {{ .watchdog }}
    reset: 1 # reset watchdog on normal
    set:
      source: switch
      switch:
      - case: 1 # normal
        set:
          source: sequence
          set:
          - source: const
            value: 7000
            set:
              source: modbus
              {{- include "modbus" . | indent 12 }}
              register:
                address: 140
                type: writemultiple
                decode: int16
          - source: const
            value: 7000
            set:
              source: modbus
              {{- include "modbus" . | indent 12 }}
              register:
                address: 141
                type: writemultiple
                decode: int16
          - source: const
            value: 0
            set:
              source: modbus
              {{- include "modbus" . | indent 12 }}
              register:
                address: 142
                type: writemultiple
                decode: int16
      - case: 2 # hold
        set:
          source: sequence
          set:
          - source: const
            value: 0
            set:
              source: modbus
              {{- include "modbus" . | indent 12 }}
              register:
                address: 140
                type: writemultiple
                decode: int16
          - source: const
            value: 0
            set:
              source: modbus
              {{- include "modbus" . | indent 12 }}
              register:
                address: 141
                type: writemultiple
                decode: int16
          - source: random
            set:
              source: modbus
              {{- include "modbus" . | indent 12 }}
              register:
                address: 142
                type: writemultiple
                decode: int16
      default:
        source: error
        error: ErrNotAvailable
  {{- include "battery-params" . }}
  {{- end }}

Case B — hand-built custom meter (same power register, same device, configured directly instead of via the template picker):

# PV-Leistung
  power:
    source: modbus
    uri: 192.168.xxx:502
    id: 1
    register:
      address: 110   # PV-Leistung MAX.STORAGE
      type: input
      decode: int32s

    
  # Optional: AC-Leistungsgrenze (falls benötigt)
  # maxacpower: 6000
watchdog: 30s

Same power register, no energy block, configured directly (not via template picker). History for this one shows a smooth, correctly tapering curve all evening, consistent with proper power integration — no test-dialog energy value either.

Same physical device (same host/id), same power register, same day — only difference is template-based vs. hand-built custom config, and the template path shows an energy value even at the connection-test stage, before any entity/DB row exists.

This points away from a DB-checkpoint-inheritance explanation and toward something in the template's connection-test/probing path (or how a templated meter registers its capabilities on instantiation) independently surfacing energy for this product, regardless of the render block's actual usage: pv output. Happy to provide DB entity dumps, more screenshots, or anything else that helps narrow this down.