Previously, when the source sensor's state remains constant, the derivative
sensor repeats its latest value indefinitely.
This patch fixes this bug by consuming the state_reported event and updating
the sensor's output even when the source sensor doesn't change its state.
* if the derivative is negative, ignore it
* add option to ignore the negatives or not
* add tests for a new ignore negative derivative
* add missing description when editing
* rename to ignore_negative_derivative
to increase clarity of which negative I mean
in case in the future we want a ignore_negative_value...
* use state_class=total_increasing to ignore the negative derivative
* remove ignore negative from the config
* add test for total_increasing_reset case
* add comments
* update test_total_increasing_reset with history tests
Also remove the last comment because the test is already clear
My existing comment there isn't unique to this unit test but applies to the entire component. The existing web documentation pointing to Wikipedia should suffice.
---------
Co-authored-by: Erik Montnemery <erik@montnemery.com>
* Add and use time related constants
* Sort time constants and reuse them in data rate constants
* Fix greeneyemonitor import
* Fix greeneyemonitor import V2
* Fix failing here_travel_time test
* Add TIME_MONTHS and TIME_YEARS
* Use TIME_MINUTES in opentherm_gw and isy994
* Add and use TIME_MILLISECONDS
* Change inconsistent ones
* Add TIME_MICROSECONDS and TIME_WEEKS
* Use constants in apcupsd and travisci
* Fix import error in upnp sensor.py
* Fix isy994 sensor.py using TIME_YEARS
* Fix dyson tests
* Use TIME_SECONDS in more places
* Use TIME_DAYS in google wifi
* keep track of the derivative for unit_time
In this way, you will get a better estimate of the derivate during
the timescale that is relavant to the sensor.
This solved a problem where sensors have a low output resolution.
For example a temperature sensor that can only be integer numbers.
It might report many values that are the same and then suddenly go up one value.
Only in that moment (with the current implementation) the derivative will be finite.
With my proposed implementation, this problem will not occur, because it takes the average
derivative of the last `unit_time`.
* only loop as much as needed
* treat the special case of 1 entry
* add option time_window
* use cv.time_period
* fix comment
* set time_window=0 by default
* rephrase comment
* use timedelta for time_window
* fix the "G" unit_prefix and add more prefixes
https://en.wikipedia.org/wiki/Unit_prefix
* add debugging lines
* simplify logic
* fix bug where the there was a division of unit_time instead of multiplication
* simplify tests
* add test_data_moving_average_for_discrete_sensor
* fix test_dataSet6
* improve readability of the tests
* better explain the test
* remove debugging log lines
* create derivation component
based on integration component
remove left and right
* Update test
(was'n saved)
* add some functionnal point test
* Change derivation to derivative
* Continue migration from derivation to derivative
* Add codeowners info
* fix tests typo and values
* Improve code from reviewer
add test case
fix test values
still a prefix issue that should not
* create derivation component
based on integration component
remove left and right
* Update test
(was'n saved)
* add some functionnal point test
* Change derivation to derivative
* Continue migration from derivation to derivative
* Add codeowners info
* fix tests typo and values
* Improve code from reviewer
add test case
fix test values
still a prefix issue that should not
* Update homeassistant/components/derivative/sensor.py
Fix test issue with unit of measurement
Co-Authored-By: Santobert <tobhaase@gmail.com>
* Fix review
Move ValueError to SyntaxError
* precise state test
* un comment original tests and remove error tests
* Fix isort issue
* Fix review
- update doc link
- migrate to general const import
* Rollback import conf_unit, just defined localy
Co-authored-by: Santobert <tobhaase@gmail.com>
