Hi LLwarrenP, Thank you very much, I will test this today, I did not answer your questions because I was travel last days.
HI @LLwarrenP I am here again to suggestion another feature, I am still made some test on my Sump Pump so on Smartthing App I accidentally touch on screen and the switch turn “OFF”, I only see this one day after when tried turn on pump manually, could you add an way to hold always “ON” or if turn OFF"" send an notification.
Yes, in fact I do this by simply creating a Smart Lighting rule that says if it’s off, turn it on which works quite nicely. It usually responds within less than a second if I manually turn it off.
Thank you very much.
For anyone interested, v2.5 is up on GitHub. Basically, I added a “keep it on” option, an “alert if off” option, and an “every 15 minutes check” option. The options are controlled via three separate settings so you can mix and match it up to suit.
For the “keep it on” option, interestingly enough, though both exec in the cloud, I found that the Smart Lighting rule executes much faster but it’s still within a couple of seconds max. I think the ST app is perhaps more optimized. The feature triggers on an off event and turns it on and then does a quick check and reissues the command if it still thinks it is off just to be sure. You can of course still use the ST Smart Lighting rule instead.
The “alert if off” is pretty self explanatory - just a push or SMS if it finds that it is off at any point. If this option is off you won’t get any of the “it’s off” messages to your app/phone (but you will see the status in the full logging in the IDE).
The “every 15 minutes check” simply checks the status every 15 minutes to verify it is on and alerts you (if you have the “alert if off” option above also enabled). If you have the “keep it on” option above enabled it will attempt to turn the switch on first and then only alert if it seems to still be off.
I have all three of these enabled personally but honestly you could probably get away with either a) just the Smart Things Smart Lighting rule plus the off alert option and nothing else or b) just the every 15 minutes check and alert. I like that the app has control of everything vs. the separate ST rule though.
Small update to v2.6 is up on GitHub. I had noticed the occasional false positive so I added some code to basically ignore multiple pump firings within 5 seconds - something that would be pretty much impossible. The signature of the “false positive” was an alert where the “pump ran twice in 0 minutes” and I think 5 seconds should be enough to do the trick but the window could be larger. In reality, the pump isn’t firing and it’s likely just the drop or spike in voltage or similar that is making it seem like it is firing. A sort of software “debounce” seemed necessary.
If anyone has any issues or thinks the window should be larger, let me know.
Small update to code (v2.7) to further reduce false positives on the device off / not reporting alerts. I think I’ve finally got them down to a minimum but I have noticed that I occasionally get one here and there around the “device hasn’t reported in x hours” alert. But this update seems to eliminate any false positive “device is off” alerts.
There are some limits here since ST doesn’t really allow you to poll or refresh a device’s status which would be the ideal thing.
Updated to v2.8 on GitHub.
A combo of a very wet NE fall and the v2.7 tweaks must have inspired me to add a simple new feature that allows you to be alerted when the pump stops running on a regular basis. It’s important to know that the pump has started to run but I realized I was also always wondering when it was no longer running, especially if I wasn’t around to hear it.
Of course the crux of that is “what is a regular basis” since that depends on how you have the app configured and your pump’s normal amount of running. I decided that meant twice as long as your “alert window” (not the “run detection window”). This seemed to make the most sense given that in wet conditions, the pump will start run and then as the amount of water subsides will run less and less until it just stops. Thus, the “cycle finished” alert will always lag by a bit. Note a single random run isn’t considered a cycle but 2 or more is.
So for instance, if you set the app up to detect 2+ runs in a 30-minute window but have your pump run alert window set at 24 hours (so you only get one alert a day even though the pump runs lots of times in a day), the app will conclude that the pump is done running for the foreseeable future 48 hours after the last run in this case.
The new alert (if enabled) will push/SMS something like this:
Summary: <Sump Pump Name> is no longer running on a regular basis. The pump ran 39 times between Wed, November 14 2018 14:57:04 EST and Sun, November 18 2018 09:11:33 EST
Where the two dates are the first run and the last run in the cycle.
It might make sense to dial back the window to get the alert sooner, maybe 1.5x instead of 2, but I wanted to err on the side of longer is better.
Hi @LLwarrenP I will move to Hubitat, as possible to you write the code to work on Hubitat?
Sorry, unlikely as I am sticking with ST for the foreseeable future.
FYI, I re-released v2.8 to fix an issue with the notification message for end of cycle (oops).
I also added a refresh() call to further improve the monitoring and eliminate false positives. The intent is to ensure that the device status is as accurate as possible and it seems that if the DTH for the monitored switch supports refresh() that seems to help ensure the status is correct instead of alerting on an incorrect status.
I found that the alert tracking logic left a lot of room for improvement so I’ve reworked the code to make it more robust. So for anyone using this feature and receiving questionable End of Cycle notifications, some updates are in the works. Just doing some testing - be on the lookout for a new version soon.
v2.9 is now up on GitHub.
I did some simplifying of the code as well as made the End of Cycle more robust as I discovered that I was getting incorrect dates for the start of the cycle sometimes. As always, any feedback or issues welcome!
Hi Can I try modified your code to work on Hubitat?
Sure, don’t see why not…
Basically, I’d just say give credit where do but of course if you want to do the porting I am all for it.