Known Issues
Issues have been reported with data; these vary by firmware version. Newer firmware may resolve these or introduce new issues.
Production & Consumption data
data |
envoy |
issue |
in firmware |
|---|---|---|---|
whToday |
Mtr |
late reset some time after midnight |
|
reset to non-zero value |
|||
sudden value step changes |
|||
whLastSevenDays |
Mtr |
sudden value step changes |
|
watt_hours_lifetime |
NoCT |
reset to zero when reaching 1.19 MWh |
<8.x |
Std |
1.19 MWh value stepdown |
||
all production |
NoCT |
stalled values in V1 Production Endpoint |
>= 8.2.4264 |
all production |
Std |
zero values V1 Production Endpoint |
|
all production |
Mtr with prod-ct |
silent fallback to /production inverter values |
|
consumption data |
Mtr, (tot-ct ?) |
consumption values are |
Inverter device data
The inverter device data includes a deviceDataLimit that appears to be fixed at 50. If more inverters are installed, only data for the first deviceDataLimit inverters is included, resulting in missing inverter data. When the reported deviceCount is greater than or equal to deviceDataLimit, data falls back to /api/v1/production/inverters to avoid data loss; device detail data will then be unavailable for all inverters.
Daily Outage at 11 PM
Each day, shortly after 11 PM local Envoy time, the Envoy performs some internal resets and cleanups. These cause the Envoy to become unresponsive. How long this outage lasts, varies by hardware type and/or firmware version.
Pyenphase uses retries when a request fails. Default retry setup is no more than 240 seconds elapsed, or 6 attempts. Each try uses the timeout specified in pyenphase.Envoy or a 45 seconds default. With the default timeout of 45 seconds, this results in maximum 6 attempts, 5 retries. Or up to 6 attempts if the failure occurs quicker.
If this 11 PM outage still results in errors, use the pyenphase.Envoy.set_retry_policy() method to set a more relaxed retry scheme.
Enlighten cloud overwriting locally-set battery mode
The IQ Gateway maintains a persistent outbound connection to the Enlighten cloud service, which periodically uses this connection to push tariff configuration to the gateway. When a local API write via pyenphase.Envoy.set_storage_mode() sets a mode that differs from the cloud-held configuration, the cloud will typically overwrite it within one to two minutes. The overwrite is identifiable in the tariff response: the date field is updated to a timestamp that was not written by the local PUT request, opt_schedules is restored to true, and the mode reverts to self-consumption. Enphase have confirmed this behaviour is intentional.
Blocking the IQ Gateway’s outbound internet access at the network level prevents the cloud push and causes locally-set modes to persist. Note that this also prevents the Enlighten platform from receiving monitoring data from the gateway, and may lead to unexpected behaviour when sustained over long periods of time.
Intermittent storage CT zero phase data and aggregate value drop in 8.3.6087
In firmware 8.3.6087 and later, a metered Envoy with a storage CT in split mode, two-phase configuration, intermittently reports data of one phase with all zero values and the aggregate values drop to the values of the other phase that still has data, typically 50% of normal value. As a result the aggregate values which are the sum of the 2 phases, switch between the sum of both and the value of the single non-zero phase.
This version detects this issue and returns None instead of the incorrect aggregate and phase storage CT values in ctmeters and ctmeters_phases. Be aware that with a broken storage CT, the None value may exist for extended time instead of the intermittent issue.
As a breaking change, None has been added to the envoy data model for ctmeters and ctmeters_phases.
Consumption data set to net consumption data in 8.3.5433
In 8.3.5433 firmware, the production report has (total-)consumption data equal to net-consumption data. This is reported for metered Envoy with TOTAL-CONSUMPTION CT installed. It is not (yet) clear whether this is the case as well for NET-CONSUMPTION CT installations. Pyenphase now checks values of lifetime energy and power of both consumption types and if equal, adds production values to the consumption values to obtain correct data.
For anyone already running 8.3.5433, the consumption total has previously dropped to the net value. Upgrading to this pyenphase version makes it jump back up in a single reading. For example Home Assistant’s total_increasing energy statistics interpret a jump as real consumption, so users can see a large one-off spike in their energy dashboard on the update that lands this fix. Nothing in the library can avoid this, this is not another bug, but rather the repair of the issue that came with firmware 8.3.5433.
Standard Envoy (not-metered) zero data in 8.3.5422
As of 8.3.5422, the Standard Envoy, not-metered type, reports all zeros in its /api/v1/production endpoint. The library detects the situation and switches to using the inverters data section of the /production endpoint. The inverters section is lacking Today and Last 7 days values, these will be set to zero.
Envoy metered silently falls back to inverter data from /production in 5.3.5528
As of firmware 5.3.5528 (and maybe earlier) metered envoy with production CT installed, intermittently report bogus data in /production type=eim section, recognizable by activeCount: 0.
A silent fallback from production to inverters data section of /production then happens because of the activecount (and potentially other values as well) being 0. The inverter data segment for this and others firmwares has incorrect values that differ from the eim segment. This results in step changes in the value, from the original type=eim values to the wrong type=inverters value and back.
The library detects the situation and will not fallback to the faulty data, instead it will return None in the system_production data record. None will be returned as long as activeCount remains zero. In prior versions (incorrect) data from the /api/v1/production endpoint was returned.
If the Envoy firmware is also reporting total consumption as net-consumption, consumption data for aggregate and phase data will be reported as None as well. This because no reliable production data is available to apply the needed correction.