Looking for ideas...

I am Setting up an automatic refill system for a swimming pool. I have a float-switch that operates when the pool reaches a preset level. That all work fine.

The issue I need to address has to do with removing noise from the float-switch. That is, as it nears the switch point, it oscillates (1 or more times per second) between On (low water) and Off (pool full). These fluctuations are caused by surface turbulence in the pool. I have a lot of damping between the pool and float-switch, but I still get oscillations. Since the difference between On and Off is <2mm, I could just ignore the oscillation and accept the level at whatever time I test it (that is done once a day). But, just to keep things clean, I would like to define two states: low and full and store that value in a variable, and update it no more than once a minute, maybe once every 5 minutes.

The question is how to do this. I have thought of a few ways, but I really wanted to see what creative (and maybe even elegant) suggestions the community here might have.
Here is a quick summary of the challenge: I have an Indigo Device which represents the float-switch. It has one state: on or off. I wish to maintain a variable which indicates some smoothing of the device state. It could be an average, last observed, or whatever you think might be appropriate. One note. It is better to error in the direction of stating the pool is full, when it is actually slightly low. That is, over-filling is worse than too low a water level.

Ideas?

BTW, just to keep this interesting, I'd like to try to do this using standard Indigo features. I.e., avoiding custom scripting.

[jay (support)]

BTW, just to keep this interesting, I'd like to try to do this using standard Indigo features. I.e., avoiding custom scripting.

Not sure I see the point of not using scripts or plugins since all copies of Indigo 7 support plugins and scripts...

BTW, just to keep this interesting, I'd like to try to do this using standard Indigo features. I.e., avoiding custom scripting.

Not sure I see the point of not using scripts or plugins since all copies of Indigo 7 support plugins and scripts...

Mostly because I was curious about the flexibility and versatility of all the recent features, plus the built in and 3rd party plugins. And, to make it a bit more challenging... and, for the benefit of users to whom script is a four letter word.

[jay (support)]

Going on the theory that once you get the first full notification, you'll get fewer boundary crossings from "full" to "low" as time progresses, you could just start a timer the first time you get the "full" notice (once you start filling the pool), and cancel it each time you get a "low" trigger. When the timer expires because you haven't received a "low" trigger, you can be pretty confident that it's full and disable the triggers. Determining the timer amount will require you to do some data mining to determine the right interval.

It goes against your desire to keep things interesting, but I built my Timed Devices plugin for exactly this sort of thing.

With it you could create a device called 'Pool is Full' with asymmetric timers so that low->full is instant, but full->low won't happen unless your sensor stays on for 5 min (or 2 hr, or whatever).

Thanks Jay and kmarkley for two, coincidentally quite similar, yet different approaches to the issue.

Going on the theory that once you get the first full notification, you'll get fewer boundary crossings from "full" to "low" as time progresses, you could just start a timer the first time you get the "full" notice (once you start filling the pool), and cancel it each time you get a "low" trigger. When the timer expires because you haven't received a "low" trigger, you can be pretty confident that it's full and disable the triggers. Determining the timer amount will require you to do some data mining to determine the right interval.

I thought there might be a "timers and Pesters" application here. Although, the actual system performs somewhat differently that you presume. The process starts out with the pool level on "low" and as the water rises it eventually hits an occasional "full" and then the transitions become more frequent until the switch is locked on full. Also, as for filling the pool, I am content to stop at the first hint (I.e. first low to full transition).

In terms of a thermostat, I need to maintain a dead band, the difference between the turn-on and turn-off points to keep the system from thrashing. So, it is detecting when the pool is "low enough" to start filling that is my main concern and this idea should work for detecting a "low" condition, as that operates as noted above.

It goes against your desire to keep things interesting, but I built my Timed Devices plugin for exactly this sort of thing. ... ...With it you could create a device called 'Pool is Full' with asymmetric timers so that low->full is instant, but full->low won't happen unless your sensor stays on for 5 min (or 2 hr, or whatever).

Actually, this kind of suggestion is exactly what I was hoping for. An application for a plugin I have not previously used and hadn't seen a need for and that seems to address the issue head on.

...I built my Timed Devices plugin for exactly this sort of thing.... ...With it you could create a device called 'Pool is Full' with asymmetric timers so that low->full is instant, but full->low won't happen unless your sensor stays on for 5 min (or 2 hr, or whatever).

I decided to give this a try, especially since it implements the same algorithm Jay suggested, but is nicely contained in a single interface.

To be sure I understand, since I didn't see a reference to asymmetric timers in your post, I am assuming I would use a Persistence Timer since that allows for separate on/off transition detection settings. Also, I did not find an instant setting. But, I'll assume 1 Persist cycle in Seconds is effectively the same thing.

Now I just have to wait for evaporation, a backwash, or a bunch of kids, to lower the pool level.

Thanks.

... I have thought of a few ways, but I really wanted to see what creative (and maybe even elegant) suggestions the community here might have.

BTW, the approach I had thought of, using a Python script, was to read the Device's onOff state value every 10 seconds or so, and assign a value of 1 to Off observations (full) and 0 to On observations (low) and keep track of the last 20 or so) observations in an array(as a FIFO buffer) and then total all entries on each observation. I could then set a variable to "low" when the total reached 0 and "full" when it went > 0.

In the end, that pretty much accomplishes the same thing as the timer based suggestions. But, I am intrigued with the Timed Devices idea, so I'll go that route for now.

You could have a variable you increase every time you measure full and decrease when you measure empty. Set limits >=0 and < 20. Then when count is > 10 you assume it is really full now
Start filling when count has reached 0



Sent from my iPhone using Tapatalk

You could have a variable you increase every time you measure full and decrease when you measure empty. Set limits >=0 and < 20. Then when count is > 10 you assume it is really full now
Start filling when count has reached 0 ...

Thanks Karl. That is an interesting idea. However, it does mean setting up a schedule to run permanently (say, every 60 seconds) to take the observations. The problem with that is, the more time you allow between observations, the greater the chance of missing an event (basically, quantization error) and observing too often is a waste of CPU resources. Although, since I only want to refill once a day, I could enable the Schedule ahead of the refill time and disable it after. But, that requires another schedule.

You can do everything in one script. Let it run every x seconds and put some if's into the code

In principle any solution has to do something like this.

You need a threshold and some hysteresis in both directions. The CPU usage should be very small.


Sent from my iPhone using Tapatalk

To be sure I understand, since I didn't see a reference to asymmetric timers in your post, I am assuming I would use a Persistence Timer since that allows for separate on/off transition detection settings.

Yes, that is correct.

Also, I did not find an instant setting. But, I'll assume 1 Persist cycle in Seconds is effectively the same thing.

0 (zero) persist cycles also works and is as close to instant as communication between Indigo and the plugin allows.