feat(NodOn): add SEM-4-1-00 energy reset, configureReporting and apparent power

[nthiers]

Problem

The existing entry uses m.electricityMeter() without a configure function.
As a result:

• The device falls back to firmware-default continuous reporting (~5 s interval regardless of
  load). A future firmware update will implement threshold-based reporting natively, using the
  same thresholds as defined in this PR.
• No energy_reset capability
• apparentPower and acFrequency missing from configureReporting

Fix

• Add explicit configure with manual bind, multiplier reads, and batched configureReporting
• Add energy_reset via genBasic/resetFactDefault
• Add m.identify()

Why configureReporting: false + explicit configure

Without configure, the device uses factory-default reporting (~5 s for all attributes).
With threshold-based reporting, ×63 fewer messages were observed on a stable circuit.

Manual bind is required because m.electricityMeter({ configureReporting: false }) skips its
own bind/configure step entirely.

Multiplier attributes (acVoltageMultiplier/Divisor, acCurrentMultiplier/Divisor,
acPowerMultiplier/Divisor, acFrequencyMultiplier/Divisor) are read before
configureReporting so ZHC has them in cluster cache to scale the first received reports.

haElectricalMeasurement configureReporting is split into batches of ≤5 attributes: a single
call with 6 attributes exceeds the ~85-byte ZCL frame limit and returns status=FAIL.

Why energy_reset via genBasic/resetFactDefault

This is the only counter-reset mechanism available in the current firmware. resetFactDefault
resets all cluster attributes to factory defaults — it does not affect Zigbee network membership,
bindings, or configureReporting (ZCL spec).

Tested

• Device: SEM-4-1-00
• Platform: Z2M 2.12.0 / zigbee-herdsman-converters 26.72.0
• voltage, current, power, power_apparent, ac_frequency, power_factor, energy,
  produced_energy confirmed working
• energy_reset confirmed working
• identify confirmed working

[Koenkk]

Why do we not set configureReporting: true?

[nthiers]

During my tests with the external converter, I observed that a single configureReporting call with 6+ haElectricalMeasurement attributes returns status=FAIL on our device. Splitting into batches of ≤ 5 attributes solved that.

The custom configure also reads multiplier/divisor attributes before the first configureReporting call, so ZHC has the correct scaling factors cached when the first reports arrive.

[Koenkk]

During my tests with the external converter, I observed that a single configureReporting call with 6+ haElectricalMeasurement attributes returns status=FAIL on our device. Splitting into batches of ≤ 5 attributes solved that.

For this I propose to add an argument to m.electricityMeter to change this behaviour.

so ZHC has the correct scaling factors cached when the first reports arrive.

I think we should also do this in the m.electricityMeter , read divisor/multiplier before doing the configureReporting