Fix fast polling when PollControl is not on first EP - #1817

Proposed change

This fixes an issue where fast polling is not correctly activated during initial pairing of a device (or a re-interview) if the PollControl cluster is not on the first endpoint. This is an issue with all/many Frient end-devices.

Skim the AI description below for more information. Note: Also read the related issue at the bottom.

Impact on Frient devices with limited binding table

However, this breaks Frient devices – at least my Frient Intelligent Smoke Alarm that shipped with v4.0.8.

Currently, we automatically bind 4 clusters on endpoint 35 using ZHA (BinaryInput, PowerConfiguration, IasWd, IasZone). They all bind properly without the patch. With it, PollControl is also bound now, which then causes a TABLE_FULL error for IasZone...

• Z2M explicitly unbinds the PollControl cluster and states that only 4 clusters can be bound: https://github.com/Koenkk/zigbee-herdsman-converters/blob/42d3b11e44fbdccf1bf75c0d63f8983e030af622/src/devices/develco.ts#L426-L432
  • Z2M first always binds the PollControl cluster here: https://github.com/Koenkk/zigbee-herdsman/blob/b7bf6264d3f178fcbf53d02c2906b0fe52e941d8/src/controller/model/device.ts#L1096-L1109
  • TODO: This may be a bit hard to replicate on our side... We can't really manage (ZHA) bindings from quirks v2, yet. But we could just copy this trick 1:1? Quirks custom configuration is done before the generic ZHA stuff, but after the zigpy PollControl binding during pairing..
• Apparently this was an issue introduced with firmware v4.0.8 – v4.0.7 was fine but no newer version is available:
  • EDIT: A Frient email mentioned in the Z2M thread says there isn't a difference binding-wise between .7 and .8. There may have been a semi-related issue where Z2M has no delay during an interview, making it required for (older) Z2M versions to re-interview the device multiple times, so all values show up. Either way, it's still an issue with the latest firmware, so something we need to work around / fix.
  • IntelligentSmokeAlarm 4.0.7 Develco-Products/frient_upgrade_images#1
  • SMSZB-120 Fails to configure due to TABLE_FULL Koenkk/zigbee2mqtt#23684
• Note: We also bind TemperatureMeasurement but that's on EP 38, not 35. The 4 bind limit is apparently per EP.
• Technically, we may not need the BinaryInput bind, as we don't use that cluster, but rely on IasZone instead.
  • Z2M seems to bind this to display the reliability attribute as a fault sensor
• We may also not need the IasZone bind because the write to "IAS CIE Address" should deal with the change notifications instead?
  • TODO: Why does Z2M explicitly bind this cluster then?
  • TODO: Or why do we in general? Look at spec and compare CIE address vs binding
• Note: A re-interview also does NOT clear bindings, only a factory reset does. This also seems to be the case for Z2M.
• Z2M does not bind the PowerConfiguration cluster on this endpoint.
  • TODO: Investigate if we still get battery voltage reports anyway?
  • EDIT: Not true. Z2M also binds this. See my comment below here.

This needs to be checked further.

AI description

Bug

In Device._discover(), fast polling is supposed to be set up "as soon as we are aware of a PollControl cluster" — begin_fast_polling is called after each endpoint is initialised, until it succeeds. The retry-stop signal was implemented as the else branch of a try/except (TimeoutError, DeliveryError):

for ep in self.non_zdo_endpoints:
    await ep.initialize()
    if not initiated_fast_polling:
        try:
            await self.begin_fast_polling()
        except (TimeoutError, DeliveryError):
            pass
        else:
            initiated_fast_polling = True

But begin_fast_polling() also returns silently (no exception) when find_cluster(PollControl.cluster_id) raises ValueError — i.e. when no endpoint has a PollControl cluster yet. Endpoint clusters aren't populated until ep.initialize() runs on that specific endpoint, so on a fresh multi-endpoint device whose PollControl lives on something other than the first endpoint in non_zdo_endpoints, the very first call (after ep1 init) returns silently, the else branch fires, initiated_fast_polling is set to True, and the retry on subsequent endpoints is suppressed. No Bind_req for cluster 0x0020 is ever sent, no fast_poll_timeout write happens, the device never starts emitting PollControl check-ins, and zigpy never reaches it again.

Real-world reproduction

A frient WISZB-131 with endpoints [1, 35, 38] and PollControl on EP35. After OTA + re-interview, the only Bind_reqs on the wire are ZHA's configure-phase ones (BinaryInput, PowerConfiguration, TempMeas, IAS Zone) — no 0x0020. The Device does not support fast polling debug line fires once after EP1's Simple_Desc_rsp and zigpy never re-checks. Devices that don't persist their binding table across reboot/firmware change then silently stop sending check-ins.

Fix

Use self._fast_polling (only set on a real bind inside begin_fast_polling()) as the retry-stop signal instead of the absence-of-exception:

if not initiated_fast_polling:
    with contextlib.suppress(TimeoutError, DeliveryError):
        await self.begin_fast_polling()
    initiated_fast_polling = self._fast_polling

Entry-state initiated_fast_polling = self._fast_polling is preserved at the top of the block, so devices that are already in fast polling mode (e.g. mid-OTA re-init) still skip the loop entirely. The symmetric if self.all_endpoints_init: ... branch is unchanged — that path only calls begin_fast_polling() once and is unaffected.

Test coverage

Three new tests in tests/test_device.py:

• test_initialize_fast_polling_pollcontrol_on_later_endpoint — multi-endpoint device with PollControl on ep2. Asserts dev._fast_polling is True, that bind() was called, and that fast_poll_timeout was written. Verified to fail against pre-fix code (the regression target).
• test_initialize_fast_polling_pollcontrol_on_first_endpoint — same shape but PollControl on ep1, ensuring the previously-working path still works after the change.
• test_initialize_fast_polling_no_pollcontrol — device with no PollControl anywhere; asserts no Bind_req is sent and _fast_polling stays False.

A small helper _make_fast_polling_init_mocks factors the shared mockepinit / mock_ep_get_model_info setup.

Full tests/test_device.py (66 tests) passes.

Out of scope

A separate, orthogonal issue exists in begin_fast_polling() itself: Cluster.bind() returns the Bind_req status tuple rather than raising on non-SUCCESS, so a TABLE_FULL (or other) bind failure is silently ignored and self._fast_polling is set to True regardless. Not addressed here — should be tackled separately.