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.
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.
UPDATE:
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.
I donât have that device but if it is designed similarly to the other Zooz devices then it should work fine. The app just looks for events generated by the device so it isnât tied to any one type of device. Rather, it is tied to the type of event that the device generates (acceleration of power usage in this case). If the ZEN25 has a power meter then it should be generating these sorts of events.
Also, Iâm not sure what your exact application is but if it is a sump pump or similar, you might want to make sure that the ZEN25 can take the load of your pump and is rated for motor loads â if not, the pump might zap the switch or the ZWave electronics. The ZEN15 is designed to take those sorts of appliance loads so it is a good fit but I havenât looked at the ZEN25.
No it will not as I tried it this past summer. As @LLwarrenP mentioned the amperage draw of the sump pump exceeds the Zen25 10A max.
Thank you both @LLwarrenP and @ritchierich for your quick responses. I also contacted Zooz and they also said not to use ZEN25 for any kind of application involving a motor.
I will get the ZEN15 and try to work on get the monitor up and running.
Hello, this is my first time trying to add a custom device handler. Iâve followed the directions and keep getting and error:
â Java.lang.NullPointerException: Cannot get property âlastActionTimeStampâ on null objectâ
Any suggestions? I donât understand enough of the code to know what that means or how to dissect it.
Thank you in advance! Iâm looking forward to using the full potential for this outlet on my sump pump!