I am using a Dome type water sensor which provides wet and dry feed back with a horizontal float switch connected to the cradle of the Dome type sensor. When the water level is "low", the float switch is closed giving the water sensor a short as if water is present to the sensor contacts, a wet condition which then opens a zwave valve to begin filling the pool. When the water level reaches a point were the float switch is open fully, (not making/breaking contact), then the sensor detects "Dry" and then issues a command to close the zwave valve to stop filling the pool.
I read several topics on "Delay and Cancelable", reviewed examples/suggestions but the Rule I'm using does not seem to work. I am trying to use delay and cancelable to "NOT open the zwave valve" when the pool water is choppy due to someone being in the pool, due to wind or when in that in-between point causing the float switch to make & break contact. FYI... part of the function of the rule is working, meaning when the float switch closes, the pool fill valve will open and when the float switch opens, the pool fill valve closes, each after their delay time expires. It's the cancelable part that I don't have right, don't understand, using wrong, etc.....
Here is the "rule" to open the pool fill valve, (I have another rule to close the valve.);
ogiewon, thank you for the reply and information. Since I have two rules, one to start pool filling and one to stop pool filling, I don't understand how the suggested change will make the cancelable command work when the float switch is making/breaking contact multiple times, not in a steady state, either open or closed.
I apologize for my lack of understanding.
Currently, the way you have your rule written, it will only trigger when the sensor goes to WET. Your actions will never run when the sensor changes to DRY, therefore your Cancel Delayed Actions action will never execute.
Many thanks for explaining and helping me. I made the change as suggested and it did not work until I deleted the rule and re-created the rule then it worked. I don't know what I did wrong the first time but the main thing it seems to be working. I will test and will let you know.
Over the past few weeks, the water sensor and float switch has been operational in the real environment, meaning, I'm not trying to simulate the pool water level or water oscillation by moving the float switch to make or break the contact. Unfortunately, either the rule or Dome type water sensor with float switch is not working correctly. The Dome type water sensor would detect the switch closure but would not detect the switch open state. I'm not sure the water sensor can handle the frequent change of state caused by the water oscillation. I have also removed and re-created the "cancelable conditional rule" with the suggested changed.
I don't know what I am doing wrong with this rule. Am I using the cancelable wrong, should I use wait for whatever or a combination of both. Maybe a local variable would work, I just don't know because it is not making any sense to me why the rule is not working.
That rule should work fine. However, I have seen rules get messed up when the triggerās state changes very quickly. Is there any chance that the water sensor is rapidly changing?
The float switch signal really needs to be processed with a simple low-pass filter to smooth things out before being passed on to the sensor. A simple RC circuit should do the trick, with the time constant being sufficiently long (a second or more) to smooth things out.
Actually, no. But there is a method to debounce something like this.
The issue is that every event fires up a new instance of an app. So you can have multiple instances running simultaneously, and that can mess with your logic. So doing a debounce is really the right fix.
There is an app in our public GitHub repo that debounces contact sensors. This could be easily modified for some other type of device.
maybe add a rm4 global variable as a counter ?
if switch is closed => water lever low
if switch is open => add 1 to counter
after 1 minute,
if switch is still closed and counter is 0 => real low level => open valve
if counter is > 5 (example) => oscillation => valve remains closed and counter reset to 0
Note: I have also a pond and simplified the process without automation:
A built-in floater connected to the water output:
when there is some water missing, the mechanical valve opens. I clean the valve (debris) once per 3 months.
bravenel,
Thank you for the information to let me know there is no way within RM-4 but there is an App on GitHub to try which I think I will give it a go.
PPz,
Thank you for the suggestion on global variable as a possibility. As for the "Automatic Water Level Float" device, that unit will not work with our pool design, but thanks for the info.
Note that if you use a modified version of that app, it would create a virtual switch, that behaves as post-debounce. That could then be used in Rule Machine or other automations. If it's not obvious what changes to make to it, just ask!
I have the Debouce App downloaded and made the changes to provide the list of water sensors.
Is there anything else I need to change?
Does this App run with the Pool Fill rule?
If so, how do I get it integrated to the rule?
