fix: detect ZXB3 phase variant from Tuya datapoints

[analienx]

Superseded by #6.

The runtime phase-count classifier explored here is no longer the preferred design because absence of DP7/DP8 during startup/query was not reliable enough to classify a physical variant safely.

Final proposal: #6 keeps the collision family on the shared definition and makes phase order an explicit per-device phase_mapping option.

[analienx]

Supervisor review note for Koenkk#871:

The runtime approach is now implemented and CI-clean on this fork-local draft. The key behavior is intentionally one-way: an unclassified _TZE204_wbhaespm ZXB3 starts with DP6 exposed as generic voltage / current / power; observing DP7 or DP8 upgrades the device to the persisted 3p variant, refreshes exposes, and keeps DP6/7/8 mapped C/B/A thereafter. A later DP6-only report can never downgrade it.

The narrow sparse endpoint fingerprint is retained so the known SUTON _TZE204_wbhaespm sample with 0xED00 still falls back to the SUTON definition.

Before proposing this upstream, the remaining evidence point from Koenkk#871 is simple: please confirm from a physically affected single-phase unit whether DP7 or DP8 ever appears, even as zero-valued telemetry. If the 1P device is genuinely DP6-only, this runtime discriminator avoids guessing phase count from the shared static fingerprint.

Validation on current head: Build PASS, Biome Check PASS, full Test PASS, Bench PASS, autofix PASS.

[analienx]

New evidence from zigbee2mqtt/hassio-zigbee2mqtt#871 materially supports the runtime discriminator:

• both physically single-phase affected units were captured with Zigbee2MQTT debug logging;
• neither unit emitted DP7 or DP8 at all, including zero-valued reports;
• one unit was under an actual ~2 kW / ~8.9 A load during the capture;
• DP6 itself did not appear in that short capture, so the evidence supports absence of phase-specific DP7/DP8 on 1P, but does not yet prove the narrower wording "DP6-only";
• observed DPs were SZ1: 1, 9, 13, 16, 19 and SZ2: 1, 13, 16. DP19 therefore should not be treated as a required 1P/3P discriminator from this sample.

Supervisor interpretation: keep the draft implementation, but describe the heuristic as one-way runtime detection: an unclassified device remains single-phase-compatible unless DP7 or DP8 is observed; DP7/DP8 is positive evidence for 3P and is persisted. The remaining validation target is classification latency/safety on real 3P units (especially whether dataQuery reliably causes DP7/DP8 to appear promptly after configure), not proof that every 1P report contains DP6.

I would still welcome a longer Koenkk#871 capture until DP6 appears, because it would directly confirm the generic electrical decode path on the affected hardware, but the current evidence already confirms the most important negative condition: no DP7/DP8 on those physical 1P units.

[horiace]

Hi
I ran a longer Zigbee2MQTT debug capture.
Both affected physical single-phase units reported repeatedly during the capture. For each of them I saw DP1, DP9, DP13, DP16 and DP19, but no DP6, DP7 or DP8 at all.
As a useful control, another device in the same Zigbee network, GENERAL, which is a three-phase Tuya circuit breaker, did report DP6, DP7 and DP8 repeatedly in the exact same debug capture, so the logging setup is definitely capable of capturing those datapoints when they are emitted.
Therefore I can now confirm with much higher confidence that the two affected single-phase units do not emit DP7 or DP8 in normal operation. Interestingly, they also did not emit DP6 during this longer capture.
logs.txt

[analienx]

Additional Koenkk#871 evidence: the reporter repeated active debug captures on both physical 1P units and again saw no DP7 or DP8 at all, including zero-valued reports. DP6 still did not appear, so this draft should continue to describe the heuristic as one-way: unclassified remains 1P-compatible; DP7/DP8 is candidate positive evidence for 3P. The 1P negative condition is now substantially better supported, but upstream promotion remains blocked until our P019 test proves that the exact queryOnConfigure/dataQuery path causes both known physical 3P units to emit DP7 or DP8 promptly and reliably.