Hi!
I have a trend sensor for temperature, to detect potential fire outbreak by heat.
binary_sensor:
- platform: trend
sensors:
temp_rising_kok:
entity_id: sensor.nibe_bt50_room_temp_s1
sample_duration: 60
max_samples: 60
min_gradient: 0.05 #(3 deg in one minut: 3/60=0.05)
device_class: heat
Start and end of triggers are marked here…
Logbook
Am I missing something, but its just a change of 0.1deg C.
You sure you have 60 samples there? Looks like 2, maybe 3 to me.
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.
Thanks for responding! 
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? 
is that coming from HA? If no, can we see the HA history?
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…
or you can set the time in the history to display the window you want and show a image of it
@tom_l yes, maybe that’s the solution?..
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.
Ok, I’ve learned allot!
Changing the frequency of the sensors are not an option. Maybe the best option are then to make the graph more smooth, by filtering it.
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.
Or you could increase the sample period.
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).
sensor:
- platform: filter
name: "Temp Moving Average"
entity_id: sensor.nibe_bt50_room_temp_s1
filters:
- filter: time_simple_moving_average
window_size: "00:01"
precision: 1
Filtered:
Unfiltered:
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. 
Time throttle will probably help, you could set it to only pick up results every two minutes or so, this will shallow out the gradient.
@zamb Hey, did you ever figure that out? I’m trying to do the same, but I think the easieast way would be AppDaemon
