The trend integration is using the timestamp of the system everytime a new state change happens on your sensor. It uses these timestamps to calculate the rate of change.
In your graph, to me, it looks like your temperature sensor sent 2 updates immediately. One at the current temperature, and one at the new temperature. Lets say they are milliseconds apart. (Look at the update history log to see the real time difference)
So, trend has 2 samples, a few milliseconds apart. 0.1 degree change over a few milliseconds will correlate to hundreds of degree change in a second. Thus, it turns on. And it wont change until the next update happens on the sensor since the calculation only happens on state changes.
You need to figure out why the temp sensor is sending the 2 updates so close. What kind of sensor is it?
That shouldn’t be a problem if he actually has 60 samples like his configuration alludes to. The sensor fits a trendline to all available samples within the time range or the samples specified. that trendline would be very flat if he had 60 samples across that full minute.
I maybe confused you with the graph from Grafana. The dots “before” the actual value was just to produce a square-staircase. Sorry!
This is the values:
Actually I guess its just maybe max 4 samples, because the MQTT sensor updates about every 15 second. I’m actually just interested in the time here (not samples). I want it to trigger if its rising above 3 deg / minute. I can understand I get a high gradient if I get two values very close to each other, but can I filter that out and just evaluate one minute, or how should I do?
Yes, and no…
It’s from HA, but the screenshoot are from Grafana. How can I list the values directly in HA? I only find a 24h graph on the sensor, and allot of values, need to list the values and times or be able to zoom in on the particular timeframe…
Are the gradient always calculated between the last and second last value? Then I understand two values coming in a short period of time will make this happen. Or can I change the config of the trend - sensor?
so you only have 4 data points here and depending on when you restarted the system, only 2 of them could be within your time window. This would make your slope incredibly large because the 2 points are close together.
Personally I’d try to get more data from the sensor. It seems like it’s not reporting enough info IMO. But your other option is to use filters to smooth the data or go with @tom_l’s method of delaying the data to 1 update per minute.
I think this is working fine. The first two data points are a very steep gradient, far in excess of 3 degrees per minute. You just need more data for it to average out. So just leave it collecting data. After a while it will sort itself out.
Yes, sure its correct, two very close data points wit 0.1 deg rise will give a high gradient. But I cannot use it to trigger a potential fire-alarm here… Will be allot of false alarms if datapoints comes to close.
Unfortunately the filter seems only to take hh:mm, not seconds (I wanted about 30 seconds).
So I’ll try to take that filter. time-throttle produces a very similar graph, but as it’s a variation in 0.1 deg, it just takes the value that happens to come in the time-window, so an average seems to be more correct. Anyways, 0.1 deg are not interesting in this application, as its to low accuracy in the sensor.