[RELEASE] Low Battery Notification with Customizable Alert/Warning/Monitor, Configurable Thresholds and Device Monitoring Alerts

That would technically be part of of the new device health feature being implemented by ST. This may not be practically reliable to do in a SmartApp since different devices have different thresholds and mechanisms to report. Some devices reports every few days (second one is more technical in nature and related to the way the ST platform reports events). The last event from the device can only be reported by the device handler for that specific device and not by smartapps.

@RBoy The way I was envisioning it implemented in your smartapp was a child app like the battery threshold. For example, the monitor rules would be “one event daily” and I could pick all the Things that I want to monitor daily. Then, I could have another monitor rules for “one event every 5 days” and I can pick all the Things that I want to monitor every 5 days. It seems to me that it will follow the structure of your app.

SmartThings health feature doesn’t work at all. It’s so unrealiable I opted to turn it off. I was excited when I saw it, but it tell me that devices are offline when they are not and vice versa.

In the past, I was using Simple Device Viewer SmartApp to monitor events in my Things. It worked very good (so it’s possible to see events in a SmartApp) but it’s limited to only one threshold. In addition, if I add all my Things to that SmartApp, the next time I try to open the app using my mobile, it times out due to the 20 second rule. Since that apps reports all capabilities of all Things selected, I believe that is what causing the time out.

We’re going to experiment with this a little because if there are devices that don’t report battery events it will just create a lot of confusion for users. Even so it’ll likely be something like if the device hasn’t reported a battery event in 7 days then notify the user to keep it easy.

1 Like

Just to let you know that we’ve been experimenting with this feature. Found some interesting results,

  1. Not all devices report battery levels, sometimes never (e.g. some sensors only report 100% and 0%)
  2. Battery reporting is very device handler dependent, e.g. with some stock Device handlers they doesn’t specify the attribute isStateChanged: true, so when the device reports the same battery level ST internally doesn’t report it to the SmartApp as the value hasn’t changed. E.g. a sensor who’s battery level is 100% for 15 days in a row even though the device handler will “report” the battery as 100% every 6 hours, ST won’t report it to the SmartApp since the value hasn’t changed and the device handler didn’t specify isStateChanged: true.

So all in while it’s a good idea, it can very misleading and lead to many false positives because it depends on how the DH was written and how the device itself works.

@RBoy I see your point. Thanks for looking into it. I really appreciate it. By any chance have you tried the Simple Device Viewer Smartapp? There you have the ability to see when was the last “event”. That way you know that your Things are “working/active”. It seems to work reliable there. The situation is that I don’t have freedom to set multiple thresholds for “events” like in your Battery Smartapp. Also, since the Simple Device Viewer report many other parameters, once you add a decent amount of Things, the app becomes unstable.

@gferrari the purpose of this SmartApp is not to monitor all events, just battery events.

Having said that in the next release 01.02.00 we’ve added the code required to monitor battery events and notify the user if the devices don’t report battery events for XX (configurable) days.

However these inputs options for notifying if devices doesn’t report battery levels for X days will be disabled by default to avoid confusion for users for the reasons given above:

If you want you can enable the battery level not reported features by uncommenting the 4 lines (166 to 169) where it says UNCOMMENT THE NEXT 4 LINES TO ENABLE BATTERY REPORT MONITORING.

Like I said the purpose of this SmartApp is to track and report battery usage, you can modify as described above to track battery events, but please note that we cannot support custom versions of the SmartApp.

###Device Low Battery Notification and Monitoring - Version 01.02.00

Thanks I’ll give it a try!

1 Like

Hi @RBoy: I know you can’t support custom versions of the SmartApp, so rather than asking for help, I thought I’d just simply pass along feedback that I tested this tweak (i.e. deleting “battery”, from line 214) and while I am able to successfully save the Battery Monitor Rule itself, I get an error on the parent page when trying to save the SmartApp itself (a red “Error saving page” banned flashes across the top). Just FYI.

Just checked and verified it’s working here. Could be a typo while making the change or maybe just bad timing with the platform having a random error.

Ok, I’ll give it another try after they fix the current platform outage. Devices are totally haywire right now.

1 Like

No joy, I’m afraid. I’ve tried it on two completely unrelated SmartThings hubs, and they both result in the same error when trying to save the changes to the SmartApp if the argument (“battery”,) is removed from line 214.

I’m attaching a picture of the rule I created, as well as the error I get when trying to save the SmartApp.

I’m guessing it either a typo while making the modifications or something else is going on. Maybe your IDE Live Logs will tell you what’s going on. The custom mods seem to work here consistently.

Good call on the Live Logs; not sure why I didn’t think of that sooner. Here are the entries upon saving the SmartApp:

10:38:29 AM: error groovy.lang.MissingMethodException: No signature of method: script_app_Low_Batter_b3bff4d0_f7c5_4a29_85c1_4a83bef09a02_ver_0_7.subscribe() is applicable for argument types: (physicalgraph.app.DeviceWrapperList, java.lang.String, java.util.LinkedHashMap) values: [[Front Door, Side Door, Garage Door Sensor, …], …]
Possible solutions: subscribe(physicalgraph.app.InstalledSmartAppWrapper, java.lang.String, java.lang.String), subscribe(physicalgraph.app.DeviceWrapper, java.lang.String, java.lang.String), subscribe(physicalgraph.app.InstalledSmartAppWrapper, java.lang.String), subscribe(physicalgraph.app.LocationWrapper, java.lang.String), subscribe(java.util.Collection, java.lang.String, java.lang.String), subscribe(physicalgraph.app.HubWrapper, java.lang.String, java.lang.String)

10:38:29 AM: trace Initializing settings with rules [[index:1492906205947]]

10:38:29 AM: trace Updated called with settings [time:2017-04-22T10:00:00.000-0500, sms:1234567890, monitorDevicesReportingDays1492906205947:2, monitorDevicesReporting1492906205947:true, notify:true, deleteRule1492906205947:false, monitorDevices1492906205947:[Front Door, Side Door, Garage Door Sensor, Back Door, Side Door Sensor], batteryUpper1492906205947:10, disableUpdateNotifications:false]

There’s a typo somewhere in your modified code. It should read:

See this post:

Also, did you intend to include some sample output in this section of your previous post?

Looks like ST has removed the ability for SmartApps to track all events from devices. I’ve updated the post above, the app can be customized to monitor and report if devices don’t report battery events for a certain period of time as mentioned here:

Hi @RBoy, I just realized that the number of days since battery last reported is limited to a single digit…it appears that 9 is the max. I was going for two weeks (14), but anything above 9 won’t stick after clicking save (it reverts to the previous single digit setting). Any chance we could up that field to double digit? Thanks.

Update: I resolved this issue by deleting the errant battery Monitor Rule and recreating it.

1 Like

This morning I started getting a ton of low battery notifications that were for things I didn’t own. They looked like someone’s actual things but none of them were mine.

I went into the smart app, and reset everything (it didn’t seem to retain my actual setting I had set before).

Any idea what might have caused this @RBoy?

1 Like