Closed sldewit closed 3 years ago
derivative documentation derivative source (message by IssueLinks)
Hey there @afaucogney, mind taking a look at this issue as its been labeled with an integration (derivative
) you are listed as a codeowner for? Thanks!
(message by CodeOwnersMention)
Seems like there is no time_window
set? In that case, the derivative will only take the last two readings into account, thus no guarantee it is an window of an hour.
@frenck I did that before, but then I got completely different values in my trending. But if that is how it should be setup then I will try that for a while.
But if that is how it should be setup
There is no "how it should", as this is free to configure to your own likings and wishes.
What I want to do is have the same info as I used to get from the DSMR tooling. So if that requires the time_window
to be set to "01:00:00" then I will try that.
@frenck I just tried this and this also seems to give other values. What does the original DSMR derivative function do? Over what time period does that make a derivative? Like I said, I want to make the same function as will be depraved in the DSMR integration.
You can view the removed sensor here: https://github.com/home-assistant/core/pull/52147
You can view the removed sensor here: #52147
The way I read the code of the removed sensor there is that it simply creates a derivative based on the current and last update. And then I don't get why the regular derivative without time_window
doesn't show the same value. But reading Python code is not my best skill I must admit.
@frenck and @afaucogney I just tried a couple of options and this is how it shows now:
- platform: derivative
name: hourly_gas_consumption_2 (**Nieuwe meting 2**)
source: sensor.gas_consumption
unit_time: h
- platform: derivative
name: hourly_gas_consumption_3 (**Nieuwe meting 3**)
source: sensor.gas_consumption
unit_time: h
time_window: "01:00:00"
Nothing seems to do the same as the original sensor from DSMR does. Maybe you two can check what the difference in implementation is. At this moment the calculation number 2 follows the same profile in the graph. Only it is a factor 10 higher. And I cannot really understand that yet. Maybe I'm doing something wrong. But I think it is good for the current users of the DSMR integration to check what the correct form fit replacement would be for the depraved functionality.
If anything, i would consider the old implementation in DSMR the weird one. It has been removed as we don't allow for integrations to provide virtual sensors.
The question should not be: which looks the same. The question is: which one is correct?
That's the right question indeed. I did some quick testing with the current implementation:
I've calculated the area under the curve (AUC):
Total gas usage is 0.087 m3 when using the calculated "gas usage per hour".
When comparing this to the actual value from DSMR:
The real amount is 0.087, an exact match.
I think it is relevant to do the same with the derivative platform and compare the area under the curve (AUC). My expectation: the AUC will be exactly the same, but the hight and width of the curve will be different. That would make a lot of sense, since the Gas meter can only give a value once every couple of minutes (that is baked in the hardware of the physical Dutch gas meter itself), so every derivative setting will be suboptimal anyway (as compared to the "truth", which we simply cannot observe every milisecond).
As a comparison, see below the timestamps of my water usage of the same period:
As you can see, the real event started around 11:51, and ended at 11:58. Right in the 11:00-12:00 time window. This also supports my statement above: the gas meter can only show a value once every few minutes, because the gas meter is not precise enough to track every cm3 of gas usage. The gas meter will only trigger after more gas has been used.
I've implemented some test derivate sensors, so we can start comparing. I don't store DSMR sensor data in Home Assistant at all (it would flood the database), the values are stored directly in a LTSS database. Therefore, i cannot recreate the above event with the below derivate sensors. The only thing i can do, is to create a new event (turning on the hot water tap for a while), and start comparing. Stay tuned.
I hope to have some insights before the next release tomorrow. In this way, a potential guideline for DSMR derivate can be added in the changelog (i can tune in in the youtube release party as well).
`
I just tried to calculate the same with my info from InfluxDB:
This is the calculation I did: <html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:x="urn:schemas-microsoft-com:office:excel" xmlns="http://www.w3.org/TR/REC-html40">
Start | Eind | Duur | Value | Area under the curve -- | -- | -- | -- | -- 13:35:05 | 13:36:30 | 00:01:25 | 1,44 | 0,001416667 13:35:25 | 13:40:50 | 00:05:25 | 0,146 | 0,00054919
The problem
As I read in the pre-release notes in the next release of HassIO the DSMR gas per hour reading will be removed. This could be replaced with a derivative function. I tried that with below configuration (In YAML upload)
And this seems to work, however I also trend this new sensor using InfluxDB, but this seems to give a difference with a factor 10:
![image](https://user-images.githubusercontent.com/54032526/124446254-8b722c80-dd80-11eb-8cc8-9f68ac757e49.png)
Am I doing something wrong?
What is version of Home Assistant Core has the issue?
core-2021.6.6
What was the last working version of Home Assistant Core?
No response
What type of installation are you running?
Home Assistant OS
Integration causing the issue
Derivative DSMR
Link to integration documentation on our website
https://www.home-assistant.io/integrations/derivative/ https://www.home-assistant.io/integrations/dsmr/
Example YAML snippet
Anything in the logs that might be useful for us?
No response
Additional information
No response