Cannot get PID to work with sensor - works fine with input number

[dmshimself]

I know people will say - "you must have put the entity in wrongly" on this issue, but I don't think I have!

I have added the PID config in and things work fine with the default entity_id being the 'reading' input_number. I've enclosed a screen shot of this here:

But when I change the entity_id to be the one I actually want, the PID value sticks at 0 instead of changing to 1. I've enclosed a screen shot of this, but more importantly also of the attributes the PID sees and this shows the value of the entity value. It's the value of the Fermentor shown.

and

I've tried rebooting the machine but this makes no difference.
I've add debugging in and I get an log entry saying:
2022-06-29 09:22:46 DEBUG (MainThread) [custom_components.pid_controller] setup

but nothing else when I change and enable the PID

Any thoughts much appreciated!

BTW, I noticed an attribute called tunning set to false and I wondered if this might be to turn on autotune, but I haven't altered that at all, although I would be interested to know if there is functionality behind it.

[Guspaz]

I have observed a similar bug, though in my case the PID doesn't update regardless of if the input sensor is an input number or a sensor. Restarting doesn't help, I enable the pid controller and the output stays pegged at the minimum despite both the PID settings and the internal PID values all being 0. The pid controller shows the correct value of the input sensor in its attributes, but the pid output never changes from the minimum.

EDIT: The problem appears to be that the PID controller does not update itself periodically (even if a sample_time is set), but only when the state of the input sensor changes. Because the input sensor's value may never change if the PID controller output never changes, this can form a deadlock if the current state is stable, no matter how far away the input sensor is from the setpoint. Even if the input sensor is slowly changing over time, the pid controller will get very few updates if the sensor resolution is only for example 0.1 degrees, not enough to properly drive the output. I see this as a bug: the pid controller should update itself at the sample_time interval instead of relying on external state change events that may be rare or non-existent.

My workaround to this bug is to change the pid input to an input_number, and create an automation that every 5 seconds, it updates the input number to the real sensor's value plus 0.0001, and then updates it immediately again to the real sensor value. This causes a state change event that updates the pid controller. I set the sample_time to 5 seconds to avoid double-triggering it.

[reklame33]

My workaround to this bug is to change the pid input to an input_number, and create an automation that every 5 seconds, it updates the input number to the real sensor's value plus 0.0001, and then updates it immediately again to the real sensor value. This causes a state change event that updates the pid controller. I set the sample_time to 5 seconds to avoid double-triggering it.

What does this automation look like?

[dmshimself]

I've moved to using a hardware PID for the time being. I'll revisit this software implementation in HA at a later date.

[SEKCobra]

I have observed a similar bug, though in my case the PID doesn't update regardless of if the input sensor is an input number or a sensor. Restarting doesn't help, I enable the pid controller and the output stays pegged at the minimum despite both the PID settings and the internal PID values all being 0. The pid controller shows the correct value of the input sensor in its attributes, but the pid output never changes from the minimum.

EDIT: The problem appears to be that the PID controller does not update itself periodically (even if a sample_time is set), but only when the state of the input sensor changes. Because the input sensor's value may never change if the PID controller output never changes, this can form a deadlock if the current state is stable, no matter how far away the input sensor is from the setpoint. Even if the input sensor is slowly changing over time, the pid controller will get very few updates if the sensor resolution is only for example 0.1 degrees, not enough to properly drive the output. I see this as a bug: the pid controller should update itself at the sample_time interval instead of relying on external state change events that may be rare or non-existent.

My workaround to this bug is to change the pid input to an input_number, and create an automation that every 5 seconds, it updates the input number to the real sensor's value plus 0.0001, and then updates it immediately again to the real sensor value. This causes a state change event that updates the pid controller. I set the sample_time to 5 seconds to avoid double-triggering it.

Thank you for your post, I was ripping my hair out, trying to find the error in my setup, I had almost assumed the integration was just broken. Turns out this is a serious issue if the input doesn't change for a while. I would definitely agree with your post that the implementation needs to update at the sample time, regardless of changes in the input entity.

[soloam]

Sorry for the delay in response, some personal problems made me be off for some time.

The tunning should not be in this release, it's a work in progress and at the moment is does nothing.

I'll look at this.

Regarding the sample_time, some miss interpretation is happening. sample time is the minimum time that a sample should be considered. If you have a report every 1 second, and a sample time of 5s, only 1 input will be considered, all the other 4 will be ignored.

What you would need is a way to repeat the same input every x seconds, if no input occurs. This indeed is missing and I'll take a look at this.

Thank you

[dmshimself]

Let me know when you think this is worth having another go. I've just installed the latest HACS version and my HA is also the current version. The switch for the heater is still not being turned on and the number of points for my PID (fermenter) is always 0 still. I've enclosed a screen shot and I have a test rig ready to go!

[soloam]

First of all your maximum should not be zero. The minimum and the maximum should be the minimum and maximum values of your output. Or if you prefer, you can set it to 0 and 1 (or 0 and 100) and use the output as a percent.

Second, a pid control does not control a switch, it outputs a value that should be used in a system that has influence in the set value. For example raising the heater temperature would influence the room temperature. You can use it as a switch if you use only the plug-in without the p, i and d values, and mapping 1 and zero to on and off on the switch, but that would not be a pid system and this plug-in would be overkill.

[dmshimself]

I shall give it another go. On your second point - I do have an automation that looks at the value of the PID 'fermenter' and switches the heater on/off.

After further testing, I get a much better result, many thanks. I found that setting Maximum to 0 had no effect, but when I changed it to be (say) 34 , I got action. The PID is now changing its value and so the heater is turning on and off. Curiously the average temperature it seems to be hovering around is 26.5 but the set point is 28. I shall continue testing....

[soloam]

Is your heater on/off, or can you set the temperature?

[Guspaz]

If the heater is on/off, then fractional PID output can still be used to produce PWM output.

…

On Tue, Oct 18, 2022 at 3:40 PM Soloam ***@***.***> wrote: Is your heater on/off, or can you set the temperature? — Reply to this email directly, view it on GitHub <#18 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AGUNEHDN2BNTNRZZCJDZKQDWD34LTANCNFSM52DSNRNQ> . You are receiving this because you commented.Message ID: ***@***.***>

[dmshimself]

My heater is either on or off - it's not very sophisticated!

I've just reset PID to all be 0 so I can start the tuning again as per the docs. I'll report back later ....

[soloam]

So basicly you should set the minimum to 0 and the maximum to 0
1, and no decimals, this will produce 0 and 1, you then can make your heater turn on or off with that, if 0 you turn it off, if 1 you will turn it on. Try also setting p, i and d to zero.

Set your set point and the it should turn on, turning off again when it crosses the set point!

[dmshimself]

I don't think that Maximum works like that. I have the following 2 screenshots that seem to show this. The first has Maximum at 1 and the PID never goes above 0. When I change Maximum to be 34, it kicks in

As you see, not a lot happens. When changed to be 34, the PID kicks in

[soloam]

It depends what you are doing with the pid returned value! The PID alone does nothing its the output acting on something that make things happen. For some the minimum can be 16 and the maximum 32 and use that values to regulate a thermostat. But for others the minimum could be 0 and 100 and use that value to reguiate the percentage of a pump working....

Every case as is specific use case. In the end basicly a value is entered in the pid (the entity) and that value is compared to the desired set point! if it's off it uses the p, i, and d values to calculate the output... That output should have a minimum and a maximum... That values are those minimum and maximum of the variables... With that you have to make something happen that has a effect on the system... When the that happens it starts all over again. This is the PID loop.

[dmshimself]

I have an automation which turns the heater on if the PID is > 0 points and turns it off if the PID is 0 points. The comment I was trying to make is that the instructions in the README.MD for setting up the PID say to set Minimum to 0 and Maximum to 1.

If you do that, in my experience, the PID sticks at 0 points and so no automation to turn on any heater is ever triggered.