feat(smart): add historical energy stats via get_energy_data - #1735
Open
floatsmyboat wants to merge 2 commits into
Open
feat(smart): add historical energy stats via get_energy_data#1735floatsmyboat wants to merge 2 commits into
floatsmyboat wants to merge 2 commits into
Conversation
Copy link
Copy Markdown
Sorry, something went wrong.
Implement get_daily_stats/get_monthly_stats for SMART energy-monitoring
devices, which were previously stubbed to raise. They now call the
firmware's get_energy_data and map the result into the Energy interface
contract ({day/month: energy}, honouring kwh), following the response
continuation cursor for paging. PERIODIC_STATS is advertised for energy
monitoring v2 devices.
Hardware-verified on a KP125M(US). get_energy_data is parameterized, so
FakeSmartTransport generates a calendar-aligned response for it; adds
tests for the monthly/daily mapping and the continuation pager, and
updates the CLI emeter test to key off PERIODIC_STATS support.
Addresses python-kasa#1734.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Copy link
Copy Markdown
Codecov Report✅ All modified and coverable lines are covered by tests. @@ Coverage Diff @@
## master #1735 +/- ##
==========================================
+ Coverage 93.29% 93.35% +0.05%
==========================================
Files 157 157
Lines 9932 9972 +40
Branches 1022 1031 +9
==========================================
+ Hits 9266 9309 +43
+ Misses 471 468 -3
Partials 195 195 ☔ View full report in Codecov by Harness.
|
Sorry, something went wrong.
Add tests for the year/month defaults, Q4 quarter boundary, the get_energy_data continuation pager's no-progress guard and zero-width window, and erase_stats — bringing patch coverage on the new code to 100%. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
floatsmyboat
marked this pull request as ready for review
August 6, 2026 16:51
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Addresses #1734.
What
Implements historical energy statistics for SMART/KLAP energy-monitoring devices. get_daily_stats and get_monthly_stats were previously stubbed to raise KasaException("Device does not support periodic statistics") for all SMART devices, even though the firmware supports the get_energy_data method the library never called.
They now query get_energy_data and map the result into the existing Energy interface contract ({day: energy} / {month: energy}, honouring kwh).
Details
Hardware-verified against a KP125M(US) (fw 1.2.5 Build 241213): pulled a full year of monthly totals plus ~3 months of daily data, and daily-vs-monthly sums cross-check cleanly.
Testing
get_energy_data is parameterized (timestamp window + interval), which the static SMART fixtures can't represent, so FakeSmartTransport now generates a calendar-aligned response for it — the same approach already used for get_on_off_gradually_info. New tests cover the monthly mapping, the daily mapping + kwh scaling, and the continuation-cursor pager; the CLI emeter test now keys off PERIODIC_STATS support instead of IotDevice. Full suite green locally (22750 passed), ruff + mypy clean on changed files.
Open question for maintainers 🚩 (why this is a draft)
Capability detection. I gate PERIODIC_STATS on energy-monitoring v2, but I've only hardware-verified get_energy_data on the KP125M. There are ~15 v2 energy fixtures (P110 / P115 / EP25 / P210M / P304M / P316M / the S515D dimmer …) and I can't confirm the dimmer or the others actually implement get_energy_data.
Options I'd appreciate your steer on:
Happy to adjust to whichever you prefer. I'm also glad to capture a real get_energy_data fixture from the KP125M if you can point me at the preferred shape for parameterized-call fixtures.
🤖 Generated with Claude Code