Problem
Two issues with the Shelly 1PM Gen 4 (S4SW-001P16EU, firmware 20260120-145255/1.7.4):
1. seMetering configureReporting is rejected by the firmware
The device returns Status 'FAILURE' when Z2M tries to configure reporting for the seMetering cluster. Since this exception is unhandled, the entire configure step is aborted — meaning haElectricalMeasurement never gets properly configured either, and meta.configured stays 0 so Z2M keeps retrying forever.
Failed to configure 'Device', attempt 1
ZCL command seMetering.configReport([...]) failed (Status 'FAILURE')
2. Default MAX interval (65000 s / ~18 h) is too long for energy monitoring
With a stable load like a heating power supply at 7–8 W, the activePower ±5 W change threshold is never crossed. Result: no values reported all day, only when pressing manual refresh.
This is a catch-22: even if you fix the intervals manually via the frontend, Z2M resets them on the next configure attempt because of issue 1.
Fix (PR attached)
modernExtend.ts: catch configureReporting failures per-cluster and log a warning instead of aborting. Same pattern as the existing try/catch on endpoint.read. Also helps with the INVALID_DATA_TYPE issue on powerFactor already noted in shellyPowerFactorInt16Fix().shelly.ts: custom configure for S4SW-001P16EU and S4SW-001P8EU that skips seMetering.configureReporting and uses 300 s max interval for haElectricalMeasurement instead of MAX.
Problem
Two issues with the Shelly 1PM Gen 4 (
S4SW-001P16EU, firmware20260120-145255/1.7.4):1. seMetering configureReporting is rejected by the firmware
The device returns
Status 'FAILURE'when Z2M tries to configure reporting for theseMeteringcluster. Since this exception is unhandled, the entire configure step is aborted — meaninghaElectricalMeasurementnever gets properly configured either, andmeta.configuredstays0so Z2M keeps retrying forever.2. Default MAX interval (65000 s / ~18 h) is too long for energy monitoring
With a stable load like a heating power supply at 7–8 W, the
activePower ±5 Wchange threshold is never crossed. Result: no values reported all day, only when pressing manual refresh.This is a catch-22: even if you fix the intervals manually via the frontend, Z2M resets them on the next configure attempt because of issue 1.
Fix (PR attached)
modernExtend.ts: catchconfigureReportingfailures per-cluster and log a warning instead of aborting. Same pattern as the existing try/catch onendpoint.read. Also helps with theINVALID_DATA_TYPEissue onpowerFactoralready noted inshellyPowerFactorInt16Fix().shelly.ts: custom configure for S4SW-001P16EU and S4SW-001P8EU that skipsseMetering.configureReportingand uses 300 s max interval forhaElectricalMeasurementinstead of MAX.