New Automation: PID Controller

george.erhan · January 10, 2021, 11:15am

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).

fwolter · January 10, 2021, 11:47am

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:
1. RESET_I_PART: Sets the I part to 0. An optional double argument can be used to set the I part to a specific value.
2. RESET_D_PART: Sets the D part to 0. An optional double argument 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?

george.erhan · January 10, 2021, 11:59am

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.

fwolter · January 10, 2021, 12:14pm

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.

planesweep · January 13, 2021, 8:59am

Hi,

I am so happy to see that the PID controller idea was revived.
I hope the PWM part is available soon as well.

Morgano · January 13, 2021, 4:42pm

@fwolter
Please let me know when your new JAR is ready as I’d like to test it!

fwolter · January 13, 2021, 5:57pm

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

rgabo74 · January 14, 2021, 1:07pm

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

Morgano · January 14, 2021, 3:22pm

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.

fwolter · January 14, 2021, 3:29pm

I didn’t update the link in the original post.

Morgano · January 14, 2021, 3:34pm

I used the JAR in your recent post, size 27,828 bytes.

rgabo74 · January 14, 2021, 3:35pm

I don’t have the new parameter either. I have the following version installed:
22 x Active x 80 x 3.1.0.202101131754 x openHAB Add-ons :: Bundles :: Automation :: PID Controller
(downloaded from your latest post)

fwolter · January 14, 2021, 3:58pm

Seems like I uploaded some older version. I updated the link in one of my last post. Now it should be the right one.

rgabo74 · January 14, 2021, 6:19pm

Seems like I uploaded some older version. I updated the link in one of my last post. Now it should be the right one.

Yes, it works now, thanks.

Morgano · January 15, 2021, 11:13am

Tried it on a couple of TRVs - seems to be working better than the TRV’s internal controller already - even running without an ‘I’ component!

I had a couple of thoughts/suggestions:

Would there be any mileage in linking the config options (gains etc.) to a set of Items so that they could be edited via a sitemap or even changed through Rules if necessary? Maybe once the PID parameters are all set they might not be changed much, but having them linked to Items would make tweaking them in the initial setup phase possible in other ways rather than just through the GUI. An alternative would be to expand the ‘Command’ Item’s capabilities so that the controller can receive changes to the parameters that way.
I’m not sure if this is anything, but I noticed that when I send a “RESET” command via the Command Item it doesn’t always clear to NULL - it remains with “RESET” in the Item. Should the PID controller clear the Command Item once it has processed the command or is it OK if it leaves the previous command there? I thought if there was something already in the Item whether it might not notice a subsequent command.

Morgano · January 17, 2021, 4:53pm

@fwolter
In fact I don’t think it ever clears. So, if I send “RESET” the first time it works, but not subsequently; I presume this is because the controller sees no change in the command as the “RESET” remains in a buffer. I can work arround this by clearing the Command Item after I send the “RESET” command by sending an empty string “”.
I think it would be much better if the PID Controller were to clear the Command Item itself once it has received the command.

fwolter · January 19, 2021, 6:03pm

I updated the link to the JAR in the original post. The command is now reset to NULL after the reset command has been processed.

Would there be any mileage in linking the config options (gains etc.) to a set of Items so that they could be edited via a sitemap or even changed through Rules if necessary?

I didn’t suffer any pain when tuning my PID controller. I could modify the gain parameters pretty quickly in the UI. I’m wondering if that would be an improvement tuning them via Items?

CrazyIvan359 · January 19, 2021, 6:11pm

I have implemented this thing yet but I do intend to and am following along here.

A binding can provide a setting for autoupdate (not sure how, haven’t looked yet). Setting the value to false for the command channel will prevent the state changes of the command item entirely. Assuming the binding is listening for commands on that channel of course.

For the purpose of tuning the controller via items, one could use rules. They wouldn’t need to be pretty since it would only be a temporary measure. The target thing could be changed in the rule when one decides to tune a particular PID thing.

Morgano · January 20, 2021, 9:00am

Thanks for sorting out the reset commmand issue. Regarding the linking of the PID parameters to Items, I think it would be an improvement where there are many instances of the PID controller e.g. one per TRV (as in my situation); going into each one and changing in the GUI is quite slow. If they were in Items I could change them in a Sitemap. Maybe there is another way, but I am not very familiar with the new Rules engine, all my Rules (apart from PID Controller) are in the old Rules DSL.

george.erhan · January 23, 2021, 8:53am

It’s the best way. This way you can create external rules to auto-tune!