Develco SPLZB-137/SPLZB-141: acFrequency reports every 5 seconds due to reporting default

What happened?

Develco/frient power plugs report acFrequency every 5 seconds, permanently.

reporting.acFrequency in zigbee-herdsman-converters uses min: 5, max: 300, change: 10:

https://github.com/Koenkk/zigbee-herdsman-converters/blob/master/src/lib/reporting.ts

export const acFrequency = async (endpoint, overrides?) => {
    const p = payload("acFrequency", 5, repInterval.MINUTES_5, 10, overrides);
    await endpoint.configureReporting("haElectricalMeasurement", p);
};

The change threshold of 10 is in raw attribute units and is not divisor-aware. Grid frequency never holds still within it, so the minimum interval is hit on essentially every cycle and the maximum of 300 is never reached.

Consecutive raw values from an SPLZB-141: 49966, 49977, 50000, 49988 — differences of 10–30 against a threshold of 10.

Measured on a 51-device network with two SPLZB-141 plugs, lamps switched off:

The two plugs produced 40% of all traffic on the network while doing nothing.

reporting.acFrequency has exactly two call sites, both in develco.ts: SPLZB-137 (line 746) and SPLZB-141 (line 891).

Related: #9497 reports the identical symptom on SPLZB-131 (5-second reporting, log flooding). It was closed as stale without the cause being identified.

What did you expect to happen?

Reporting proportional to meaningful change, not a fixed 5-second heartbeat driven by grid noise.

How to reproduce it (minimal and precise)

1. Pair an SPLZB-141 (or SPLZB-137).
2. Run Configure.
3. With debug logging enabled, the device sends a haElectricalMeasurement report containing acFrequency every 5 seconds, indefinitely, with no load attached.

Zigbee2MQTT version

2.14.1

Adapter firmware version

7.4.2 (EmberZNet)

Adapter

Home Assistant Yellow, built-in Silicon Labs radio (ember driver)

Setup

Home Assistant add-on on Home Assistant OS, Home Assistant Yellow

Device database.db entry

No response

Debug log

No response

Notes

Four other Develco meters in the same file already use the modernExtend path, which handles this correctly and is divisor-aware:

// Report change every 1 Hz
ac_frequency: {
    attribute: "acFrequency",
    divisor: "acFrequencyDivisor",
    multiplier: "acFrequencyMultiplier",
    change: 1,
},

SPLZB-131, SPLZB-132, SPLZB-134 and SMRZB-143 use m.electricityMeter({acFrequency: true, ...}). Only SPLZB-137 and SPLZB-141 still use the legacy reporting.* calls, and they are the only two devices affected.

Migrating those two to m.electricityMeter() is likely the better fix and would make them consistent with their siblings. Note that SPLZB-141 has genOnOff on endpoint 1 under a manufacturer profile (profId 49353, inClusterList [5, 6]), the same shape as SPLZB-131, so it would likely need the same m.onOff({powerOnBehavior: false, configureReporting: false}) workaround described in #29548.

Additionally, SPLZB-141 never reads the frequency divisor: readEletricalMeasurementMultiplierDivisors only reads acFrequencyDivisor / acFrequencyMultiplier when called with readFrequencyAttrs = true. SPLZB-137 passes true, SPLZB-141 does not — which is why it publishes the raw attribute value ("ac_frequency": 49988) rather than Hz.

I have a PR migrating both to m.electricityMeter(), tested on SPLZB-141, which fixes both the reporting rate and the divisor.