Use RESCHEDULE source route discovery mode

[TheJulianJES]

DRAFT/TODO: Check if we want this at startup.

AI summary

SourceRouteDiscoveryMode.ON only schedules the periodic MTORR; it does not trigger an immediate broadcast. Devices joining or rejoining during the first interval after startup therefore have no source-route table entry on the NCP and fall back to AODV/route discovery — the opposite of what enabling the concentrator is meant to achieve. With MTOR_MAX_INTERVAL currently at 3600s, that gap can be up to an hour.

Per the SDK enum docs (sl_zigbee_types.h /
ember-types.h):

• SL_ZIGBEE_SOURCE_ROUTE_DISCOVERY_OFF no source route discovery is scheduled
• SL_ZIGBEE_SOURCE_ROUTE_DISCOVERY_ON source routes discovery is scheduled, and it is triggered periodically
• SL_ZIGBEE_SOURCE_ROUTE_DISCOVERY_RESCHEDULE source routes discoveries are re-scheduled to be sent once immediately and then triggered periodically

zigbee-herdsman's ember adapter uses RESCHEDULE for this reason. Switch bellows to match.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 99.54%. Comparing base (4b97a6d) to head (9c778fa).

Additional details and impacted files

@@           Coverage Diff           @@
##              dev     #716   +/-   ##
=======================================
  Coverage   99.54%   99.54%           
=======================================
  Files          61       61           
  Lines        4147     4147           
=======================================
  Hits         4128     4128           
  Misses         19       19           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[zigpy-review-bot]

LGTM in intent; the SDK-enum semantics check out and the fix is minimal and well-targeted.

Verification

• SDK enum — confirmed against Silicon Labs Ember ZNet 8.0 docs (source-route.h): SL_ZIGBEE_SOURCE_ROUTE_DISCOVERY_OFF=0x00, ON=0x01, RESCHEDULE=0x02. The SDK API ref does describe the function as setting “MTORR scheduling mode to on/off/reschedule”; the published HTML doesn’t spell out the “ON = periodic-only / RESCHEDULE = immediate + periodic” split in prose, but the bellows enum names + uint32_t return value (= ms until next MTORR) and the herdsman implementation are consistent with the AI summary in the PR body. A code-comment citation of sl_zigbee_types.h would be nice but not necessary.
• Cross-adapter parity — zigbee-herdsman’s ember adapter uses EmberSourceRouteDiscoveryMode.RESCHEDULE in its initNCPConcentrator() and logs Started source route discovery. ${remainTilMTORR}ms until next broadcast. This PR brings bellows in line.
• Bellows enum (bellows/types/named.py:2853): SourceRouteDiscoveryMode.{OFF=0, ON=1, RESCHEDULE=2} matches the SDK. The constant exists and is what gets serialized over EZSP setSourceRouteDiscoveryMode (EZSP v8+, bellows/ezsp/v8/commands.py:42).

MTORR-storm risk: low

set_source_routing is called from ApplicationController.start_network (bellows/zigbee/application.py:233), which zigpy invokes from startup() only (zigpy/application.py:255) — not from the connection_lost path (zigpy/application.py:906). So switching from ON to RESCHEDULE adds one extra MTORR broadcast per integration startup / radio reset, not per silent reconnect. That’s safe.

Companion PRs

This pairs naturally with #717 (capture the uint32_t return value as a log line) and #718 (drop MTOR_MAX_INTERVAL 3600→60s). With #718 alone the worst-case AODV-fallback gap shrinks from ≤1h to ≤1m; this PR makes it ~0 for the startup window specifically. They’re independent and correct on their own merits.

Nits

• Test change (tests/test_ezsp.py:434) is mechanical — it just mirrors the constant. Fine; there isn’t much else to assert at this layer.
• Draft body says “DRAFT/TODO: Check if we want this at startup.” — worth resolving in the PR body before un-drafting. The case for RESCHEDULE-at-startup is strong (otherwise enabling the concentrator at all does nothing for up to MTOR_MAX_INTERVAL seconds), and zigpy doesn’t loop on it.
• No code comment on why RESCHEDULE rather than ON — a one-liner referencing the herdsman behavior would help future readers who diff this against the SDK and wonder whether RESCHEDULE is appropriate for the “initial enable” call. Optional.