Add Update by time filter
Proposed change
As currently implemented, the Time Simple Moving Average filter only gets updated when it receives a new value. This is counter to most people's expectations. See, for example, https://github.com/home-assistant/core/issues/57337 "the Time Simple Moving Average shows wrong state when the input sensor doesn't change state".
This is an old issue and Daniel Hjelseth Høyer had created and then abandoned https://github.com/home-assistant/core/pull/53053 as an enhancement to let the user ask HA to update the state periodically. That was about 3 years ago.
I rebased that deleted branch, fixed it a bit, and added a test. I think it's time we get this merged.
I followed his lead and left the old behavior intact and added a new flag update_by_time to the existing SMA filter that tells it to update as the time changes - not just on new data.
Type of change
- [ ] Dependency upgrade
- [ ] Bugfix (non-breaking change which fixes an issue)
- [ ] New integration (thank you!)
- [x] New feature (which adds functionality to an existing integration)
- [ ] Deprecation (breaking change to happen in the future)
- [ ] Breaking change (fix/feature causing existing functionality to break)
- [ ] Code quality improvements to existing code or addition of tests
Additional information
- This PR fixes or closes issue: https://github.com/home-assistant/core/issues/57337
- Link to documentation pull request: https://github.com/home-assistant/home-assistant.io/pull/36181
Checklist
- [x] The code change is tested and works locally.
- [x] Local tests pass. Your PR cannot be merged unless tests pass
- [x] There is no commented out code in this PR.
- [ ] I have followed the development checklist
- [ ] I have followed the perfect PR recommendations
- [x] The code has been formatted using Ruff (
ruff format homeassistant tests) - [x] Tests have been added to verify that the new code works.
If user exposed functionality or configuration variables are added/changed:
- [ ] Documentation added/updated for www.home-assistant.io
If the code communicates with devices, web services, or third-party tools:
- [ ] The manifest file has all fields filled out correctly.
Updated and included derived files by running:python3 -m script.hassfest. - [ ] New or updated dependencies have been added to
requirements_all.txt.
Updated by runningpython3 -m script.gen_requirements_all. - [ ] For the updated dependencies - a link to the changelog, or at minimum a diff between library versions is added to the PR description.
To help with the load of incoming pull requests:
- [ ] I have reviewed two other open pull requests in this repository.
Hey there @dgomes, mind taking a look at this pull request as it has been labeled with an integration (filter) you are listed as a code owner for? Thanks!
Code owner commands
Code owners of filter can trigger bot actions by commenting:
@home-assistant closeCloses the pull request.@home-assistant rename Awesome new titleRenames the pull request.@home-assistant reopenReopen the pull request.@home-assistant unassign filterRemoves the current integration label and assignees on the pull request, add the integration domain after the command.@home-assistant add-label needs-more-informationAdd a label (needs-more-information, problem in dependency, problem in custom component) to the pull request.@home-assistant remove-label needs-more-informationRemove a label (needs-more-information, problem in dependency, problem in custom component) on the pull request.
Not sure if update by time should be considered a filter
I'm not sure what you mean. Are you thinking that I should create a new filter for this rather than adding the flag to TimeSMAFilter? What would I call it? TimeSMAFilterV2? TimedTimeSMAFilter? Just TimedSMAFilter?
My own preference would be to treat this as a bugfix and get rid of the update_by_time flag - I really can't see anyone actually expecting the current behavior.
Filter is something that processes the output of a source sensor, this is more like a sampler (therefore the need to update by time which is not commanded by the source)
That's also the reason I created https://github.com/dgomes/ha_sampler to keep it separate.
But lets listen to other folks
@Danielhiversen If you're still active over here, would you be able to take a look at this PR? I took what you did in https://github.com/home-assistant/core/pull/53053/files added tests and fixed a couple of issues.
Filter is something that processes the output of a source sensor, this is more like a sampler (therefore the need to update by time which is not commanded by the source)
That's also the reason I created https://github.com/dgomes/ha_sampler to keep it separate.
But lets listen to other folks
My feeling is that if this issue with this filter isn't going to be fixed, we'd be better off documenting it as deprecated and creating a replacement rather than ignoring the issues that are opened periodically that keep getting closed: https://github.com/home-assistant/core/issues/72822 https://github.com/home-assistant/core/issues/62941 https://github.com/home-assistant/core/issues/57337 https://github.com/home-assistant/core/pull/53053 ...
Have I overlooked another, correct, implementation that we can point to?
There hasn't been any activity on this pull request recently. This pull request has been automatically marked as stale because of that and will be closed if no further activity occurs within 7 days. If you are the author of this PR, please leave a comment if you want to keep it open. Also, please rebase your PR onto the latest dev branch to ensure that it's up to date with the latest changes. Thank you for your contribution!
The issue still exists. Code has been rebased off current dev.
There hasn't been any activity on this pull request recently. This pull request has been automatically marked as stale because of that and will be closed if no further activity occurs within 7 days. If you are the author of this PR, please leave a comment if you want to keep it open. Also, please rebase your PR onto the latest dev branch to ensure that it's up to date with the latest changes. Thank you for your contribution!
The issue still exists. Code has been rebased off current dev.
Generally, we expect sensors to periodically report their value, changed or not.
The problem is that state change events are only fired when a sensor's value has changed. To be notified when a sensor value is reported but not changed, state reported events must be consumed in addition to state change events.
The helpers derivative, integration and statistic all support this, here's the PR adding support to derivative: https://github.com/home-assistant/core/pull/139230
We should add a state report listener to the filter integration too, before we add a new configuration variable.
To deal with sensors which only report their value when changed, an additional configuration parameter such as proposed in this PR makes sense. The helpers derivative and integration both have this feature, configurable by setting the configuration parameter max_sub_interval. A new feature added to the filter integration should work the same way and have the same name as the max_sub_interval parameter in the derivative and integration integrations, unless there's a really good reason why that is not suitable for filter.
I'm available to chat about this on Discord, my username there is also @emontnemery
There hasn't been any activity on this pull request recently. This pull request has been automatically marked as stale because of that and will be closed if no further activity occurs within 7 days. If you are the author of this PR, please leave a comment if you want to keep it open. Also, please rebase your PR onto the latest dev branch to ensure that it's up to date with the latest changes. Thank you for your contribution!