Here’s my version. Not much different from yours. If you make the changes I suggested, some groups become unnecessary so you can flatten/simplify even more, which is always a good thing:
It may be the case in your testing that you’ve had your ReactorSensor throttle–if you send too many changes per minute, Reactor attempts to protect the system by slowing things down. The default limits for this (30 changes per minute, 5 tripped state changes per minute) are quite conservative, but you can tune them and probably should for this application, as there is little risks of “loops” (one of the problems the throttling tries to catch). You can set the
MaxChangeRate state variables on your ReactorSensor to a fairly high value (say 60 on both) for this application.
The last thing I noticed in my testing that if I change the levels too quickly, the default pulse time of the changes operator catches the second change and thinks it’s part of the first, so no second firing of the action happens. The default is 2 seconds, and sometimes that will be too long for this purpose. To shorten that hysteresis, change the
ValueChangeHoldTime state variable to 1 on your ReactorSensor. If your RS is older, you may not have that variable, so then go to the Advanced tab, “New Service” subtab, and enter the following (copy-paste–it must be exact):
- New Service:
- New Variable:
- New Value:
Since Reactor 3.4 has some additional controls for pulse timing of this type, this variable and its behavior will not be used in 3.4 and after.