This makes sense for a digitial actuator, but it doesn't leave room for returning an error condition.
The need for this came to light when using a PWM acutator with a motor ball valve as target in this scenario:
The actuator is opened (by the PWM actuator)
The controller reboots when the valve is halfway
Now the controller reads the feedback switches from the valve and sees that it is neither fully open nor closed. Yet due to the boolean function signature it has to choose between the 2.
If true is chosen, a half open valve will be interpreted as open. This makes sense if the valve is passing some liquid. But if the valve is nearly closed in reality, a driving class can chose not to activate it because it is already open. In this scenario, the process can be not cooling/heating when the controller thinks it is.
If false is chosen, a half open valve will be interpreted as closed. This can result in the process being heated/cooled and it is never stopped because the controller thinks the actuator is already off.
Clearly, we cannot map a digital actuator that can have error or unknown state to a boolean value.
So this pull requests changes the actuator state to an enum.
If OneWire communication fails or the feedback switches of a valve say it is neither open nor closed, it will return Unkown. The driving class (like ActuatorPwm) can then handle the error, for example by driving the actuator back to a known state.
ActuatorDigital has virtual functions:
This makes sense for a digitial actuator, but it doesn't leave room for returning an error condition. The need for this came to light when using a PWM acutator with a motor ball valve as target in this scenario:
Now the controller reads the feedback switches from the valve and sees that it is neither fully open nor closed. Yet due to the boolean function signature it has to choose between the 2. If true is chosen, a half open valve will be interpreted as open. This makes sense if the valve is passing some liquid. But if the valve is nearly closed in reality, a driving class can chose not to activate it because it is already open. In this scenario, the process can be not cooling/heating when the controller thinks it is. If false is chosen, a half open valve will be interpreted as closed. This can result in the process being heated/cooled and it is never stopped because the controller thinks the actuator is already off.
Clearly, we cannot map a digital actuator that can have error or unknown state to a boolean value.
So this pull requests changes the actuator state to an enum. If OneWire communication fails or the feedback switches of a valve say it is neither open nor closed, it will return Unkown. The driving class (like ActuatorPwm) can then handle the error, for example by driving the actuator back to a known state.
This PR should resolve #85.