Skip to content

Don't poll electrical measurement multipliers and divisors - #943

Merged
puddly merged 1 commit into
devfrom
zigpy-bot/em-poller-skip-multiplier-divisor
Oct 27, 2026
Merged

puddly merged 1 commit into
devfrom
zigpy-bot/em-poller-skip-multiplier-divisor

Conversation

@zigpy-review-bot

@zigpy-review-bot zigpy-review-bot commented Oct 13, 2026 •

Copy link
Copy Markdown
Collaborator

Summary

Fixes #942.

#348 set up reporting for the electrical measurement multiplier and divisor attributes and deliberately left them out of polling: they are read on startup, and a device that changes them at runtime reports the new value. Up to #657, the EM cluster handler polled a fixed ZCL_POLLING_ATTRS list that never contained them.

Since #657, AggregatedClusterPoller.async_update builds the poll list from every attribute that an enabled sibling sensor configures for reporting. The EM sensors configure reporting for their own multiplier and divisor attributes, so these are now read on every poll (every 30–45 s). On a SONOFF S60 this is 9 attributes per poll instead of 3, which zigpy splits into two Read Attributes requests (at most 5 attributes each) instead of one.

Changes

  • Sensor gets a _scaling_attribute_names property (empty by default). BaseElectricalMeasurement returns its multiplier and divisor attribute names, including the power_multiplier / power_divisor fallbacks.
  • AggregatedClusterPoller.async_update skips each sibling's own scaling attributes when building the poll list.
  • Initialization reads and reporting configuration are unchanged: the AttrConfigs are untouched, only the poller ignores these attributes. The AC power/current/voltage multipliers and divisors are read fresh on startup, the DC ones with cache allowed (read_on_startup=False).
  • Note for review: before Replace cluster handlers with entity attributes #657 the DC multipliers/divisors were also read fresh at initialization (they were in the EM handler's REPORT_CONFIG); since Replace cluster handlers with entity attributes #657 they are read_on_startup=False. This PR leaves that as is, but with polling gone they are now refreshed only at initialization and by reports, the same as the AC ones. Switching them to read_on_startup=True would be a one-line follow-up per attribute if wanted.
  • The Metering poller is unaffected: Metering's multiplier / divisor have no reporting config, so they were never polled.

Why not a per-attribute flag on AttrConfig: the scaling attributes are already named on each EM sensor class (the same names the _multiplier / _divisor properties read). Deriving the skip list from them keeps one source of truth, covers new EM sensors automatically, and avoids adding a flag to the 40 reporting-configured multiplier/divisor AttrConfig entries.

Testing

  • New test_em_poller_skips_multiplier_and_divisor_attributes (SONOFF S60 device fixture): AC multipliers/divisors are still read on startup and configured for reporting, and the poll is a single read of active_power, rms_current, rms_voltage.
  • New test_em_poller_skips_fallback_multiplier_and_divisor_attributes (generic EM mock): the poll includes no multiplier or divisor attribute, including the power_* fallbacks.
  • Both tests fail on dev and pass with this change. Full test suite: 1460 passed. pre-commit (codespell, ruff, mypy) passes.
  • Reviewed in three rounds by a Claude reviewer agent and Copilot: no blocking code findings; all corrections to this description and the commit message are folded in (the third round found wording issues only).

Related: #941

Since the cluster handler removal, `AggregatedClusterPoller` polls every
attribute that an enabled sibling sensor configures for reporting. The
electrical measurement sensors configure reporting for their own
multiplier and divisor attributes, so these are now read on every poll,
although #348 deliberately left them out of polling.

Skip each sensor's own scaling attributes (incl. the `power_multiplier`
/ `power_divisor` fallbacks) when building the poll list. They are still
read at initialization and configured for reporting.
@codecov

codecov Bot commented Oct 13, 2026

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 97.22%. Comparing base (2d2e88e) to head (cb7f496).

Additional details and impacted files
@@            Coverage Diff             @@
##              dev     #943      +/-   ##
==========================================
- Coverage   97.23%   97.22%   -0.01%     
==========================================
  Files          61       61              
  Lines       10668    10678      +10     
==========================================
+ Hits        10373    10382       +9     
- Misses        295      296       +1     

☔ View full report in Codecov by Harness.
📢 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.

@tube0013

Copy link
Copy Markdown

Tested this on a large ZHA network with 50 devices being polled for electrical measurements.I was trouble shooting some network performance issues. After applying this PR and restarting HA Core, PTI captures showed approximately 166 → 82 electrical-measurement Read Attributes transactions per minute, a reduction of about 50%.
The reads consolidated into one request containing frequency, active power, RMS current, and RMS voltage, instead of two requests per polling cycle. Subsequent samples remained around 79–84 reads/minute.
This reduced polling traffic substantially. We couldn’t establish a corresponding improvement in retries or routing errors because those varied independently during the investigation.

@puddly
puddly merged commit e326f5e into dev Oct 27, 2026
9 of 10 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bugfix This PR fixes a bug

Projects

None yet

Development

Successfully merging this pull request may close these issues.

EM poller reads multipliers/divisors on every poll again since #657

3 participants