Fix utility meter next_reset shifting forward on entity rename#170957
Conversation
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
|
Hey there @dgomes, mind taking a look at this pull request as it has been labeled with an integration ( Code owner commandsCode owners of
|
There was a problem hiding this comment.
Pull request overview
Fixes a bug where renaming (or otherwise restoring) a utility meter entity caused next_reset to skip forward by one period because the cron scheduler was programmed before state restoration, starting from now() and missing the catch-up reset between last_reset and now().
Changes:
_config_schedulernow accepts an optionalstart_timeargument and uses it as the CronSim anchor when provided.- In
async_added_to_hass,_program_reset()is moved to after state restoration, and the scheduler is reconfigured from the restoredlast_resetso missed resets fire as catch-ups. - Adds a regression test verifying that after restore with a stale
last_reset, the meter performs the missed reset.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| homeassistant/components/utility_meter/sensor.py | Reorder scheduler programming after restore and anchor scheduler at restored last_reset. |
| tests/components/utility_meter/test_sensor.py | New test asserting last_reset advances on restore when a reset was missed. |
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
elupus
left a comment
There was a problem hiding this comment.
Looks good. Somewhat surprised that we serialize decimal that way but it is what it is.
…assistant#170957) Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com> Co-authored-by: AlCalzone <17641229+AlCalzone@users.noreply.github.com>
Proposed change
When a utility meter entity is renamed (or otherwise restored),
next_resetshifts forward by one period. This happens because_program_reset()was called before state restoration inasync_added_to_hass, so the CronSim scheduler started fromnow()instead of from the restoredlast_reset. Any reset that should have occurred betweenlast_resetandnow()was silently skipped.The fix moves
_program_reset()to after state restoration and reconfigures the scheduler from the restoredlast_resetwhen available. This ensures the scheduler picks up any missed resets (which then fire as catch-ups) rather than skipping them.Type of change
Additional information
Checklist
ruff format homeassistant tests)If user exposed functionality or configuration variables are added/changed:
If the code communicates with devices, web services, or third-party tools:
Updated and included derived files by running:
python3 -m script.hassfest.requirements_all.txt.Updated by running
python3 -m script.gen_requirements_all.To help with the load of incoming pull requests: