What is the downside to a high frequency piston?

[msmith]

1) Give a description of the problem
My app checks a number of sensors and takes action only under certain conditions. I have it run once every 5 minutes. What would be the downside though to having it run once every 5 seconds instead of 5 minutes? Does it drain battery life of sensors? Is it too taxing on WebCore? Or is there no issue with me changing it to once every 5 seconds? Ideally I would have it run that frequent.

2) What is the expected behavior?
As soon as conditions are present, actions are taken.

3) What is happening/not happening?
There is up to a 5 minute delay due to the low frequency I set…but I want to know if that’s necessary or not?

4) Post a Green Snapshot of the piston

[c1arkbar]

That would be pretty taxing on webcore. There is probably another way to write your piston without using the timer.

Can you elaborate on what your goal is with this piston?

[Mike1616]

I would agree with that assessment.

But if your goal is to monitor devices, then I think you would be better off using the native “triggers” that are inherent within those devices. Meaning that I would use “changes” rather than “did not change” for the tests.

But it’s hard to say with certainty without knowing more about what you’re ultimately trying to do.

[msmith]

Ok, thanks. Wasn’t sure if WebCore’s servers got hit for every piston firing, but now that I know I definitely won’t increase the frequency to that.

The goal was to accurately set my away and back home status. Having a delay for away isn’t a big deal (and away needs the ‘did not change’ parts), but the one for getting back home I do want to happen without delay, which is why I was looking to increase the frequency. Instead though, I’ll just create a second piston with sensor-based triggers as Mike1616 suggested to capture my back home status more quickly.

Glad I asked. Thanks!

[Mike1616]

This is basically what I do for Home/Away. My phone tends to throw a lot of false events…so i account for that by adding in the delay to where it only executes if I’m really gone for 5 minutes (“stays” starts a Timer event).

For the home part…I ensure that I’ve been away for at least 5 minutes so that it does not run my Home routine even though I never left. Both are in the same piston…just monitoring my phone to see if I leave or go…but I suppose you could expand this to include your other sensors. The home part executes at soon as my presence is detected and I’ve really been gone for at least 5 minutes though…so that works out well too.