Problem with part D - value peaks

[mcih8]

I have underfloor heating with huge inertia. I have Zigbee temperature sensors. I set their resolution to 0.01 degrees to obtain a more precise temperature reading for heating control. With a resolution of 0.1 degrees, I get temperature updates every 1.5-2 hours. The house is well insulated, it is still warm outside and that is why the temperature drops so slowly.

At this resolution, part D does not hold values, and only has peaks of value as in the screenshot. This looks like a bug in the plugin.

Steps to reproduce the behavior:

1. Set the temperature sensors to a resolution of 0.01
2. Turn on the heating
3. Monitor the behavior of the P I D values and see what happens.

I would like the D value to be maintained until the next temperature update. This behavior allows you to maintain smoother, more precise heating control.

Screenshots

The above problem occurs when I do not use sampling period. When I run this function the behavior is as follows:

These are my settings. In the first screenshot, sampling periods were commented out. In the second screenshot, sampling period is turned on.

I would like to not have to use sampling period. When I use this function the value of the D part is lost after this period if the temperature does not change.

Smart thermostat (PID) 2023.10.0 Home Assistant 2023.10.5 Supervisor 2023.10.1 Operating System 11.1 Interfejs użytkownika: 20231005.0 - latest

Conbee + Zigbee2MQTT Temperature sensor Tuya WSD500A (https://www.zigbee2mqtt.io/devices/WSD500A.html#tuya-wsd500a)

[mcih8]

This may be the cause. Maybe someone also has this problem and it can be bypassed programmatically - if the next time you call Smart Thermostat and the temperature difference is 0, do not update part I and D?

[Chupaka]

Was going to tell that repeating state updates can be the reason. So, sampling period is exactly for those cases: set it to 1 second - and PID will ignore multiple updates within 1 second interval.

[mcih8]

I set the sampling period to 1 second and still the same problem. I changed the setting after 19:00

[Chupaka]

Huh... 10 seconds to be sure? :)

[mcih8]

Still the same problem

Pls look at my second screenshot in first post. There are sampling period 1200 s. Part D is not ok. Part D is updated every 1200 s and is calculating as delta temp and delta time, where time is 1200 s. When i set sampling period 1 od 3 s it return very high value of part d on very short time because i have small delta temp in very small delta time. In next calling the function i have zero delta temp and 3s delta time, do part d is zero.

[mcih8]

And if i have resolution of temperature sensor 0.01, climate chart still show 0.1 resulotion, but calculating is on 0.01 resolution. You can see it here. At 17:40 is d part peak because sensor temperature drops from 23.03 to 23.01 but on chart climate aktualne temp is still 23.0*. This is not a problem. Its only answer why there are part D peak when on chart climate temperature is still the same.

[danieltwagner]

Did you ever get this resolved? I was just trying out the smart thermostat and found that the derivative becomes essentially useless as it only ever produces small peaks, which makes it near impossible to dial in underfloor heating.

I suppose one way to not lose the values would be to have a pwm value that is at most the size of the sampling period, but I didn't try that as I was hoping to react quickly to temperature changes.

[mcih8]

Yes, i use debounce function in Zigbee2MQTT and now it works.

I only have a small problem with external causes of temperature increase - cooking, human presence, etc. At high Kd values, such causes cause the temperature to increase by 0.2-0.4*C above the set point, and when the temperature drops later, the thermostat tries to maintain it. Even though the current temperature is above setpoint. But this is how the algorithm works, this is how it comes out of the calculations.

[Chupaka]

@danieltwagner

found that the derivative becomes essentially useless

in underfloor heating

Derivative is for fast processes, and underfloor heating is very slow to react, so I can't think of any cases where derivative is useful with it...

[mcih8]

Derivative does a great job with underfloor heating. See when the house is cold, the heating starts at full power and brakes sharply as soon as the temperature in the room starts to rise. Despite this, the temperature continues to rise. At 12:30 you have a correction because the rate of temperature rise has decreased and at 15:00 we have reached the set point. It's perfect for me.

There is only one problem. The screenshot showed pizza being made in the oven. The temperature dropped quickly and the heating was turned on for a while unnecessarily. But that's a small problem.

[danieltwagner]

That is exactly my experience from other PID loops with very high delay (hours, not minutes) that should get to temperature reasonably quickly without high overshoot.

[tomasxvavra]

How about feeding PID with a temperature filtered by e.g. moving average? PID would react to an averaged house temperature which corresponds to it's heat accumulation ability. Effect of very quick changes like quick ventilation or pizza making would be reduced based on amount of filtering. This would still maintain kD's ability to prevent over/undershooting. Either in plugin build filtering or HA entity level filtering?

I think that those quick but temporary temperature changes should be from a large part considered as a noise. Especially if you have a underfloor heating with very large delay and accumulation ability.

I will try this: https://www.home-assistant.io/integrations/filter

Edit: HA SMA filter will probably not work correctly, because it will not match PID's sampling rate. It's not updating periodically but based on sensor's event. https://github.com/home-assistant/core/issues/57337 https://github.com/home-assistant/core/pull/53053 Maybe I will try to code this directly into the plugin, some day..