Ah - OK , that will explain it then! It might be useful if there was a setting in the controller to reduce the frequency of triggers on a time basis, although maybe this would compromise the ‘purity’ of the PID controller. I can achieve a similar effect by making changes to my rules.
By the way, for a bit of background, I am using the PID controller to control battery-powered TRVs so wanted to reduce the frequency of small valve position changes to improve battery life. I’ve also been experimenting with a ‘minimum percentage change’ figure in my rules and ignoring small control output changes this way too.
Ok, new to this PID thing…
I have a Eurotronic TRV that does not work very well (its own PID does overheat often), so I am experimenting with this automation addon.
First, thank you for providing it
So I installed the addon, and created items for it.
rule "PID Workaround"
when
Item pid_LRM_o changed
then
var Number oldValue = (trv_n2_valve_aperture.state as Number)
var Number newValue = (pid_LRM_o.state as Number)
if (newValue < 0) {
newValue = 0
pid_LRM_RESET.sendCommand("RESET")
}
else if (newValue > 100) newValue = 100
else newValue = (newValue + 0.5).intValue
if (newValue != oldValue) {
trv_n2_valve_aperture.sendCommand(newValue)
}
end
rule "PID Reset"
when
Item pid_LRM_step changed
then
// reset PID controller
pid_LRM_RESET.sendCommand("RESET")
end
I will see overtime.
Since this heating PID is only controlling heating and not cooling, I also put in the workaround rule a test to reset the PID when the input temperature is equal or greater than the setpoint (negative PID output). If not, it builds up a negative integral value that IMO is not accurate here.
Yes, I had been wondering about that; as a radiator is unable to cool the room when there is an external influence heating it (e.g. it warms up outside). A large negative integral builds up which then delays the valve from opening as it should when the room cools again (e.g. when it gets colder outside).
I have updated to openHAB 3.2.0.M1 and I have checked the rules, there I got the problem that the status is “uninitilized”.
There seems a problem with “pidcontroller.action”.
@Morgano@bolemo I’m able to relate concerning the negative integral part. Honestly, I’m using an old version of the PID controller where the limits on the integral part can still be applied, because I don’t know how to use the reset method in my use case (PV zero export). I then removed the limits as they seem hackish from a controlling point of view. On the other side you can achieve results fast by limiting the i-part, if you aren’t a control expert, which I guess is the majority of the users. I think I will add them again.
@Koechi The custom action module was dropped because the OH core already provides a module for that purpose. Simply add an “Item Action” instead:
To configure a rule, you need to add a Trigger (“PID controller triggers”) and an Action (“Item Action”). Select the Item you like to control in the “Item Action” and leave the command empty.
@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.
