[enphase] Consumption channels flatline on IQ Gateway firmware D8.x

[enphase] Consumption channels flatline on IQ Gateway firmware D8.x — the binding reads the legacy `/api/v1/consumption` endpoint, which has frozen on my system after it was updated to 8.3.x (from a pre-v7 version before hand). ## Expected Behavior On a metered Envoy/IQ Gateway, the `consumption#*` channels (`wattsNow`, `wattHoursToday`, `wattHoursSevenDays`, `wattHoursLifetime`) should track real household consumption, matching the Enphase Enlighten app. ## Current Behavior On firmware **D8.3.x**, `consumption#wattsNow` flatlines at a stale value (constant `517 W` for day/weeks in my case) and `wattHoursToday`/`wattHoursSevenDays` read `0`, while the Enphase app shows correct, varying consumption. Production channels are unaffected. Cause: for firmware ≥ 7 the binding uses the token-auth connector (`EnvoyEntrezConnector`), which overrides `getProduction()` (→ `/ivp/pdm/energy`) but **not** `getConsumption()`, so consumption falls through to the base class's legacy `/api/v1/consumption`. On D8.x firmware this endpoint and the related `/ivp/pdm/energy` PDM/EIM aggregation freeze after a firmware update; the underlying CT meters stay healthy. Verified live on the gateway (same instant, all HTTP 200): ``` /api/v1/consumption wattsNow = 517 (frozen; today/sevenDays = 0) /ivp/pdm/energy cons.eim wattsNow = 517 (frozen) /ivp/meters/readings net-consumption activePower = 1021 W (live) /production.json consumption[total-consumption] wNow = 1000 W (live) ``` This is a recurring, firmware-update-related breakage of the legacy local-API aggregates; the maintained ecosystem (Home Assistant / `pyenphase`) has migrated off them to `/ivp/meters/readings`. ## Possible Solution For the firmware-≥7 `EnvoyEntrezConnector` path, source consumption from a live endpoint instead of `/api/v1/consumption`: - **Preferred (minimal):** override `getConsumption()` to read `/production.json` and return the `consumption[]` entry with `measurementType == "total-consumption"`. `ProductionJsonDTO` already parses this (it just needs a `measurementType` field added to disambiguate from `net-consumption`); the existing—but currently unused—`getProductionJson()` plumbing can be reused. Field shape (`wNow`/`whToday`/`whLastSevenDays`/`whLifetime`) maps 1:1 onto the existing `EnvoyEnergyDTO`, so channels/items are unchanged. - **Future-proof:** use `/ivp/meters` + `/ivp/meters/readings` (`activePower`), deriving `total-consumption = production + net-consumption` when only a `net-consumption` CT is fitted (confirmed within ~1.4% on my unit). Backwards compatibility: scope the change to `EnvoyEntrezConnector` only (leave the pre-7 `EnvoyConnector`/`/api/v1/consumption` untouched); keep throwing the existing exception when no consumption meter is present so non-metered gateways still degrade cleanly; optionally fall back to the legacy endpoint when `/production.json` has no consumption block (cache the decision; fall back only on structural absence, not transient errors). Workaround for affected users: rebooting the gateway may temporarily unstick the PDM aggregation, but it tends to recur after firmware updates. ## Steps to Reproduce (for Bugs) <!-- Provide a link to a live example or an unambiguous set of steps to reproduce this bug. Include code/configuration lines to reproduce if applicable. --> 1. Configure an `envoy` bridge for a metered IQ Gateway on firmware D8.3.x using the token (autoJwt) connector, and link `consumption#wattsNow`. 2. Observe the channel flatline at a constant value while the Enphase app shows live, varying consumption. 3. With a valid token, compare `https://<envoy>/api/v1/consumption` (frozen) against `https://<envoy>/ivp/meters/readings` and `https://<envoy>/production.json` (live). ## Context <!-- How has this issue affected you? What are you trying to accomplish? --> <!-- Providing context helps us come up with a solution that is most useful in the real world. --> I rely on the `consumption#wattsNow` channel to ingest live household power draw. After an Envoy firmware update it silently froze, so all downstream automation/metering based on consumption is now stuck at a constant value despite the gateway itself reporting correct data on its newer endpoints. References: - Enphase Community — local API WH counters zeroed/broken after firmware updates: https://support.enphase.com/s/question/0D53m00009INBskCAH/local-api-return-0-for-wh-counters-for-production-after-new-firmware-update , https://support.enphase.com/s/question/0D53m00009KYfCMCA1/why-did-apiv1production-stop-working - Home Assistant core issue referencing firmware D8.3.x local-API problems: https://github.com/home-assistant/core/issues/156189 - `pyenphase` migrated to `/ivp/meters/readings`: https://github.com/pyenphase/pyenphase/issues/69 - Enphase official token-auth / local API technical brief: https://enphase.com/download/iq-gateway-access-using-local-apis-or-local-ui-token-based-authentication-tech-brief - Endpoint field docs (community): https://github.com/Matthew1471/Enphase-API/blob/main/Documentation/IQ%20Gateway%20API/IVP/Meters/Readings/All.adoc ## Your Environment <!-- Include as many relevant details about the environment you experienced the bug in as possible. --> * Version used: openHAB 5.1.4 (Build) * Environment name and version: apt package install (`openhab 5.1.4-1`), systemd service; Java: Azul Zulu OpenJDK 21.0.11 LTS (21.0.11+10) * Operating System and version: Ubuntu 24.04.4 LTS (noble), kernel 6.8.0, x86_64 * Add-on / Binding Version: org.openhab.binding.enphase 5.1.4 * Gateway: IQ Gateway, PN 800-00654-r06, metering enabled (`imeter=true`), firmware **D8.3.5528** (app 08.03.5528); meters enabled: `production`, `net-consumption` (both `meteringStatus: normal`)