Feature: Allow reset of PID controller to certain value

[anssih]

It would be useful in some use cases to reset the PID controller and force the output to a certain state.

My use case would be when HA switches my A/C from cooling to heat and reverse.

Some options would be:
a) A custom HA Action. Could take the wanted output as an optional parameter or just use the existing PID Start Mode mechanism.
b) A button entity that resets the controller. Output is set according to PID Start Mode mechanism.

On the implementation side the code would have to just set simple-pid auto-mode to off and then on again.

[bvweerd]

Thanks for your contribution in improving the integration. Please test your feature request with https://github.com/bvweerd/simple_pid_controller/releases/tag/v1.5.0-beta and let me know

[anssih]

Does not seem to work correctly, the output goes to the set value at first but then soon goes to zero instead.

This is because the simple-pid auto-mode is not disabled at all. Calling pid.reset() just resets PID controller to zero but keeps auto mode on, and then pid.set_auto_mode() is a no-op so the wanted output value is not actually set.

Just calling pid.set_auto_mode(False) instead of pid.reset() makes it work for me:

        handle.pid.set_auto_mode(False)
        handle.pid.set_auto_mode(True, output)

Setting auto-mode False => True will also reset the PID controller.

Thank you for the quick implementation :)

[bvweerd]

It seems like you're referring to codelines, I'm trying to think from user point-of-view first:

I created an action simple_pid_controller.set_output to force the output to a certain value. If you keep auto mode on, it ofcourse starts deviation from the set output.

So if you want to stop as a user, you have to set auto_mode off, and after that force the output to whatever you want. when restarting it will start on the pid_start_mode option you've selected.

---

From coding point of view:

pid.reset() is only called during init, nowhere in the running integration
pid.set_auto_mode(False) disables the PID but does not interfere with any numbers at that time. That's where the above action comes to help.
pid.set_auto_mode(True, output) does indeed reset the PID, and sets the output to one of the three options in pid_start_mode.

[anssih]

pid.reset() is only called during init, nowhere in the running integration

In the async_set_output function in v1.5.0-beta, line 201:

handle.pid.reset()

When auto-mode is on, this causes the output to go to zero instead of the output value supplied as service call parameter.

[bvweerd]

pid.reset() is only called during init, nowhere in the running integration

In the async_set_output function in v1.5.0-beta, line 201:

handle.pid.reset()

When auto-mode is on, this causes the output to go to zero instead of the output value supplied as service call parameter.

Ah crap, I'm sorry.

I removed these lines to be according what I intended, so that means that you either overrule the output while running, or you first have to stop the PID before setting if you want to have a fixed output:

            handle.pid.reset()
            handle.pid.set_auto_mode(True, output)

[bvweerd]

Now it seems like intended: https://github.com/bvweerd/simple_pid_controller/releases/tag/v1.5.0-beta3

[anssih]

The behavior is as follows now:

1. Auto-mode on, pid output is at 20.
2. I call force-output to 25 => pid output changes to 25.
3. On next coordinator call of update_pid() the pid output changes back to the previous 20 directly.

Is that indended?

In my use case I would like the control to continue from the new value instead of going back to the original one immediately.
I.e. I the behavior of pid.set_auto_mode(False), pid.set_auto_mode(True, 25).

[bvweerd]

The behavior is as follows now:

1. Auto-mode on, pid output is at 20.

2. I call force-output to 25 => pid output changes to 25.

3. On next coordinator call of update_pid() the pid output changes back to the previous 20 directly.

Is that indended?

In my use case I would like the control to continue from the new value instead of going back to the original one immediately. I.e. I the behavior of pid.set_auto_mode(False), pid.set_auto_mode(True, 25).

I get the point.. the coordinator is still running with your old value, en because your input probably has not changed between the manual change and the coordinator triggers, it won't recalculate anything in the next cycle.

This is the behavior I see when I give it a sling to 200 in beta-3, there you see that the input_sensor changes before the coordinator triggers again, so the PID starts changing in the consecutive cycles.

In short, I guess I'll have to add something like the thing below and restart the coordinator. What's your idea?

if auto_mode:
    handle.pid.set_auto_mode(True, output)