@george.erhan There’s a use case for battery powered heating valve actuators to update the output less frequently, when the setpoint is reached to save battery. Maybe there are other use cases where minor changes to the output should be avoided. Are there any PID mechanisms we can implement in this PID controller to support this use case? It seems I’m missing the correct search terms to find anything useful on this topic concerning control theory. Can you point me in the right direction?
Hi, I was just upgrading my whole solution to new instance of OH 3.1 - I saw that PID is now added to default plugin list but there seem to be changes compared to previous implementation.
It took me some time to figure it out - AFAIK:
output changed to itemName
pidcontroller.action → core.ItemCommandAction
Where there any other changes?
PS. Next time it would be nice to add it somewhere to the official documentation. Probably rule sample (as text would also be a nice starting point)
PS2. Addon is not throwing any error if items for debugging are not existing but are placed in the rule (at least I think the rule was not executed at all)
The change was done to a milestone release. It was mentioned here: New Automation: PID Controller - #91 by fwolter. Breaking changes to milestone releases are not announced separately, since it’s prototype code.
Would be awesome if you could add an example to the documentation!
I added a pull request logging an error message if an inspector Item doesn’t exist.
Regarding documentation - I’m planning to write a tutorial on how I have set up my heaters using your PID controller. I hope it would be enough documentation on possible approach. I was just surprised that my rules stopped working all of a sudden and tracking down the issue was hard as I couldn’t figure out what is wrong.
rule "Bedroom TRV PID controller reset"
when
Item BedroomTrvPidControllerResetScene changed to ON
then
// reset PID controller
logInfo("Bedroom", "Manual request, resetting Bedroom TRV PID controller")
BedroomTrvPidCommandItem.sendCommand("RESET")
BedroomTrvPidCommandItem.sendCommand("")
end
When it was working before I found I had to send an empty string after the ‘RESET’ otherwise it sticks on ‘RESET’ and the PID controller cannot see the change the next time it is run.
It seems you run a pre-3.1.0 version, if your posted config is working. You are using the action type pidcontroller.action which should be core.ItemCommandAction, now. Also, the inspector items must be configured within the trigger module. Your config before the edit looked better.
The issue with the self-resetting RESET command should have been fixed in 3.1.0.
Thanks for the tip! I installed the PID controller addon from the GUI and there are no error messages now.
I am still having an issue with the PID reset though - I am not sure if this is working correctly, or if its behaviour is different to the prototype.
I have a scene that I can trigger manually to reset the PID. This sends the RESET string to the command item:
2021-10-26 10:25:29.923 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'BedroomTrvPidCommandItem' received command RESET
2021-10-26 10:25:29.924 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'BedroomTrvPidCommandItem' changed from NULL to RESET
2021-10-26 10:25:29.925 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'BedroomTrvPidCommandItem' changed from RESET to NULL
I can see that the PID Controller has received the reset command because it gets set back to NULL immediately afterwards.
However, in the past I would expect this to set the ‘I’ value to zero and then change on the next PID trigger. I am seeing a non-zero value in the ‘I’ Inspector immediately.
The integral and derivative part are internally reset to 0, but the inspector Items are only updated on the next trigger. In the meantime, the I part could be risen again. So, this should be only a cosmetic issue.
Yes - that is how I am using it. You have to create each PID controller instance in the GUI Rules configuration but the Setpoint, Input, and Output Items can be ones created as Text Items. Therefore it is also possible to use the Text Rules engine to process the PID output.
I’m facing a problem when PID controller is not setting up the PID_Control item to Null value post sending RESET.
In my case it works in a way that whenever a new SetPoint value is set on heaters I’m sending RESET command. PID controller seems to pick it up but the value remains instead of being clearead.
Is there any log somewhere to track any error/exception?
In technical environments it is common to limit the I part, so the whole PID controller produces an output in a predetermined area. Otherwise the PID controller gets to a point with no return. (eg. The I part is growing continuously to values which are way out of the possible values of the plant)
How can I limit the I part with upper and lower bounds?
I added a min and a max configuration parameter to limit the I-Part. The linked JAR file in the original post has been updated.
The I-part can be limited via `integralMinValue`/`integralMaxValue`.
This is useful if the regulation cannot meet its setpoint from time to time.
E.g. a heating controller in the summer, which can not cool (min limit) or when the heating valve is already at 100% and the room is only slowly heating up (max limit).
When controlling a heating valve, reasonable values are 0% (min limit) and 100% (max limit).
@Dominik_Jeziorski Maybe you can use these limit parameters, too. IMHO it’s cleaner instead of resetting the I-Part on every setpoint change.
Thank you really much!
I will test it and give you feedback.
To apply this new functionality I have to manually transfer the JAR file to my openhab instance instead of installing it via the Main UI Binding installation option?
Can I discuss with you another possible feature for your PID?
I try to control a heating ventilation via analog signals. These signals can be in the range of 0 to 10000 mV. So I need to keep my output of the PID in this range and also as an integer. Currently I do this with a second rule which takes the output of the PID as an input and limits the number.
What do you think about adding also limits to the output and define the data type (eg.: integer, decimal). If the limits are overs hooted, the algorithm chooses the nearest limit.
I’m currently not using the D-part, but from the mathematical point of view this D-part could also increase or decrease to numbers, where the PID will not get back. Would it be useful to limit the D-part as well?
You can simply drop the JAR into your addons folder. It should be loaded without restarting OH. You can uninstall the PID controller beforehand via MainUI, but you don’t need to. The snapshot version will take precedence.
Most devices, which are fed by the PID output limit their values internally. E.g. your 0-10V output probably won’t become negative or way above 10V, although if the PID output exceeds this range. So, I don’t think it’s a common use case, that the output needs to be limited.
Limiting the I-part is some special thing as it can run away over time. In contrast to the D-part, which will tend to 0, if the regulation is stable. The D-part can take extreme values on sudden changes, but it also decreases again on its own.
The decimal data type should be casted to integer by the binding controlling your 0-10V actuator. What 0-10V actuator are you using?
