Intermittent disruptions in temperature measurements cause huge pid_d spikes

[MarkoPaasila]

Describe the bug
When temperature reporting device disconnects and reconnects, pid_d spikes: it results in values much larger than required by the actual derivative.

To Reproduce
Make target_sensor disconnect so that home-assistant reports it as unavailable, then reconnect. Repeat a few times if necessary.

Expected behavior
pid_d results purely from temperature measurements.

Screenshots
pid_d

target_sensor

Additional context
Used device is a Shelly 1PM wifi relay with DS18B20 temperature sensor addon. The disconnecting is a separate problem - but it appears to reveal this problem I report here. Home-assistant and hasmartthermostat are up to date.

[ScratMan]

Hello, looking a the curves, I would rather think about a high sensor sampling rate or forced refresh rate of the PID.
You need to identify on your curves when the sensor returns a new value to see if the PID refresh is due to sensor or internal thermostat refresh.

[MarkoPaasila]

The PID is refreshing at every update of the temperature sensor. That's why the spike ends so soon. That's also why the spike is so high; pid_d isn't derived from the last temperature change, but from the last update of the temperature sensor, which is a much shorter timedelta. I don't see how a higher refresh rate (of what?) would help.

Once I restarted the shelly device it stopped disconnecting, and the spikes in pid_d also stopped. So this isn't a problem for me. I just wanted to report it, as it might be a problem for someone with an intermittently unavailable temperature sensor. It looks to me like the pid_dt comes from temperature update and not from temperature change. Or is unavailable -> available regarded as change?

[ScratMan]

OK, understood. I'll make some trials on my side.