I was thinking about this; for my application I would be controlling thermostatic radiator valves. After the heating has been shut off overnight I would need some way of resetting the PID controller so that the integral part is reset and the controller can start fresh for the next heating cycle. I would have thought either a Boolean switch or a method to reset the integral part to zero would work.
Let me explain with a real life example:
We assume we have a system that controls ambient temperature, a slow system that does not really require a derivative part. Assuming we have a measured value of 20 degrees Celsius and a set point of 23 degrees Celsius, the output of the PID would first be positive with a proportional part that encapsulates the 3 degrees error and an initial integral of 0. After the 1st loop the integral shall become greater than 0. Now, because we assume we have a system properly designed, the system responds with an increase of the measured value of 21,5, thus the proportional value decreases and the integral increases but with a smaller increment. This means that the PID output increment cools down.
The moment the system responds with a measured value equal to the set point, the proportional value becomes 0 and the integral part does not increase.
Next step the system over runs and the proportional part becomes negative and the integral part decreases. The next loops should calm the PID increment to the point of getting to zero or even negative (this is where the oscillation part starts, that’s why you need limiting for the output of the PID, or set some external decision rules based on the output). This example explains the working model for slow control loop properly tuned with no derivative part involved.
When dealing with PID control, tuning is very important. I know the concept of the PID controller is abstract and if I shall have time and @fwolter would be willing to help, I can develop an auto tuning feature of a PID controller (and it seems is necessary for this automation module).
1 Like
OK, so in my practical example of a TRV heating control system that only works for part of a day, what should happen to the PID controller during the period when control is not required e.g. overnight? If the controller continues to run (loop) it will accumulate a large integral error which might cause an issue when control is resumed. Maybe this is not a problem? However, it would seem to me that I would need to be able to reset the controller when starting the next heating cycle.
If “it works part of the day” does it mean you have a set point? Why don’t you set the set point to a lower temperature and have a PID output of 0 (lower limit set to 0) for that period of time?
No, there would be no set point for part of the day (actually night time). The boiler would be turned off and the TRVs closed. It would seem to me during this period I would need to stop the PID controller from looping or be able to reset it when the system is restarted the next day.
You could disable the PID rule via the REST interface: Design Pattern: Rule Disable That resets the PID.
Yes, maybe I need to approach this from another angle. Possibly setting a low setpoint on all TRVs to effectively shut down the heating. I would need to add some logic to control the boiler so that it is only activated when the radiators require heat e.g. sum of all TRV valve percentages is greater than ‘x’. That might be a more efficient way of running the boiler anyway and stop it cycling on/off when heat is not needed (i.e. when TRVs have closed).
Thanks - that’s useful information.
@george.erhan Could you answer my question on the integral limit vs reset topic? If we take the example of the PV zero export control as mentioned in the first message of this thread, the control loop is regularly failing to reach the setpoint when the battery is empty or the building’s power consumption is too high. I’m wondering how to keep the I part in a reasonable range, then?
When you say “reset” do you mean to reset it to zero or to a specific value?
Resetting should be done for the time dependent parts of the PID, I and D. Resetting means setting the value to 0 (no influence on the PID output).
Here we have 2 possibilities:
- The system is not capable of reaching the set point - this should always be treated with a limit on the overall PID (the integral internal value should infinitely accumulate, but the total PID output should be limited). When setpoint is changed a PID reset should occur.
- The system is capable of reaching the setpoint, then the properly tuned PID should naturally oscillate using the Integral part.
To conclude: A PID reset should be done when constants are changed, setpoint is changed, and probably an external triggered reset would be of help.
+1. I think this would be more elegant than disabling/enabling the PID Rule.
In the example of the PV zero export, the setpoint is always 0, as the power consumption from the grid should be 0. What could be the reset condition, then?
I think your model should be changed. Set the load as a dynamic setpoint and send the output of the PID to the corresponding energy source producers. An intermediate calculation rule is needed (not a PID).
Ok, interesting approach. I’ll take a look into this, although the load is not directly measured but can be calculated across three meters.
It’s a tough topic to make the PID controller as flexible as necessary but don’t implement any application specific or dodgy features. Here is my suggestion how to change the current implementation:
- Add a command Item, which can receive String commands to control the PID controller:
-
RESET_I_PART: Sets the I part to 0. An optionaldoubleargument can be used to set the I part to a specific value. -
RESET_D_PART: Sets the D part to 0. An optionaldoubleargument can be used to set the D part to a specific value.
-
- Keep the static I part limit for convinience. I think many users can achieve fast results with it, although it’s a bit dirty if I understood correctly.
By setting the I/D part to specific values, you could even implement a dynamic limitation within a Rule. I think this gives max flexibility to the user.
WDYT?
Both should be reset at the same time. Resetting only one breaks the PID as a closed control loop, but it is fun in a lab setup.
This should not be done in my opinion. Badly designed systems should not modify a respectable closed control loop algorithm. It only adds confusion to the model. Even the limitation of the PID output is a compromise.
This really breaks a PID controller model. I think it is useful only in lab setups.
Let me test your jar first, I will come up with some ideas for tuning/auto tuning.
1 Like
Good point with the possibility of a glitch when resetting them consecutively. I’m gonna implement only one reset command for I and D and I remove the limits at all. Adding features is always easier than removing one when it comes to backward compatibility.
1 Like
Hi,
I am so happy to see that the PID controller idea was revived.
I hope the PWM part is available soon as well.
Here is the new JAR.
- Added reset command: Send the String “RESET” to the command Item configured in the PID controller.
- Removed the limits on I part and output
For those, who are running troubles updating the JAR manually on the same version (like me), here is my way of doing it:
- Copy JAR to /srv/openhab-addons/
- Stop openhab
- Clear cache (
sudo openhab-cli clean-cache) - Start openhab
I have added the new JAR and I can create a PID Controller rule in the GUI. I can’t see where I can add the ‘command Item’ that you mention. Do I need to do that manually in the ‘Code’ tab that shows the text config? There doesn’t appear to be a way to do it through the GUI.
Apologies if I am missing something obvious - this is my first time using GUI Rules.