The issue in your screenshot could probably be solved by the driver letting the platform filter events instead of doing so itself, but if there is indeed Zigbee activity behind that (as there probably is), this might be possible on C-8 and newer hubs as mentioned above, yes.
yah im confused as to why the App can't just use the platforms' activity logs.. i mean it's right there hehe clearly the device had activity (it reported its latest state) but this App/driver didnt consider that at all.
If an event is posted by the driver it updates the Last Activity date which is what this app uses. As already explained, some drivers filter out events instead of letting the platform take care of it as it is designed to do (I think old bad habits from SmartThings drivers). If no event is posted, the date does not update. The system log is just that, a log file of text, it is not a data point. Even though most drivers will send info logs for all events that is a totally separate things from the actual events being posted.
Hello.
Like many others, I use this app to figure out if a device has fallen off the mesh.
I noticed that Zigbee repeaters (e.g. Ikea Repeater) cannot be selected.
Manually, I figure out if this type of device is on or off the mesh, by clicking on one of the two buttons on the device page (get link quality, get route table), and then checking the Zigbee Logging page to see if this device has showed up.
Is it possible to include these types of devices?
If it doesn't show up, the driver must not implement any capabilities (in the Hubitat driver sense of the term). It doesn't really matter what driver you use for a repeater unless you want a specific attribute or command it offers, so another driver might work around your issue; otherwise, maybe you can convince someone to change the Ikea repeater driver.
I do have to say that I'm not sure this kind of device is really a good fit for this app, either (if a repeater stops working, your network must have some other problem), but it's not intentional.
You can try this driver, however as Robert said, any other driver that implements a standard capability will work.
Enhancement request: make snooze of a device only snooze it for the group that alert is in.
Reason: I have a group that is triggered by battery going to 0%. I consider that a low priority alert, especially since most of my devices work past that point. I also have several groups for device being recently active. This is my high priority alert.
Last time I was away from home I had a device show up as 0% battery, so I snoozed it so that I would get an alert on it every day. Some time a few days later (after I got home), it actually died. But I didn't get an alert for activity. When I checked a few days later, the device showed up as snoozed on both groups in the report.
Hmm, interesting request. That would require re-working the way snooze works right now (it's tied to the device ID, so it applies everywhere). Not impossible; something I can consider if there is demand.
But one thing you might consider is making two separate parent instances of the app instead of separate groups. There are two independent reasons that this might help:
- snooze is tracked separately in each app, so that alone would address the specific concern; and
- you can set different notification techniques for each group, so you don't have to get the "low priority" notifications with the same frequency as the one you care more about in the first place
Put together, these are likely to be even better reasons.
I had meant to mention that as a workaround for snoozing in this case, but much like your reasons here, I don't want two separate notifications.
Thank you for considering it.
I'll still consider it for the future. But one of the reasons I noted there was "same schedule"--while here it sounds like a different one might actually be helpful to mitigate this in the first place.
But I do want them done on the same schedule -- once a day, every day. I just find one (battery at 0%) not as important as the other (no longer responding).
(and it would be a downside to deal with two different inactive device reports, to select snooze)
But if you want to snooze "both" and use the same schedule, you're back to a single app with device-level snooze being the best choice--exactly how it is now. (My suggestion above was to consider whether different schedules might be a good idea for your use case as well, not a suggestion that you were already wanting it. Just an idea!)
In any case, this is something I can consider for the future, but there are a lot of other things I know I'm going to work on first, so no guarantees. Just trying to provide some possible solutions that would already work using existing functionality. Thanks for the idea!
Hi,
I am looking for a way to monitor inactive dumb appliances from smart sensors.
Exemple:
- Monitor a sum-pump based on a vibration sensor
- Monitor a fridge/freezer based on a power meter outlet
In these cases, I want an alert if
- The vibration sensor has not reported any motion in the past 24 hours (or defined delay)
- If the power reported by the outlet has stayed the same for more than 1 hour (fridges/freezers typically cycle, so a power of close to zero for an extended period of time indicates a failure of the fridge/freezer, while a power of a finite value, but always the same for an extended period of time may indicate a smart outlet that is no longer reporting, maybe a power outage).
Is this something that could be added to this app ?
Basically, alert if a specific attribute (power, motion) has not changed for a defined period.
No, this app looks at the "Last Activity At" data (or the value of a couple other attributes if configured to do so), the idea being to catch devices that may have stopped working for some reason. It does not subscribe to any device events/attributes, and that is not a feature I am likely to consider adding to the app given its purpose.
It may still work for what you need: does the problem you're trying to address also coincide with the "Last Acitivty At" data not getting updated? If so, that alone seems like it should work.
If this is related to the question you asked in your other posts and the above doesn't work, I'd still suggest a rule for this (yes, you will need a different one for each device).
ok, thanks.
I use Zooz Zen15s to monitor my Sump pump(s). The Sump pulls a fairly predictable peak power (800 Watts), and by watching the peak power, I can Count events (pumps). You could then set a watch on the number of occurences in a 24 hour period.
Fairly simple to do in RM. I recently started dumping the events to files with the idea of playing around with Node-Red to do some tracking over time.
S
How can I get this app to check every hour for the condition instead of a specific time or when a button is pressed?
First, I'm not sure I would recommend that -- what is the reason for such frequency? If you are dealing with a device or network problem, addressing that first would be better. Maybe this app isn't the best approach.
But, to directly answer the question: this is possible. As you are aware, the app lets you "trigger" a notification with button presses. It can also do so with switches (either in addition to or instead of the scheduled time; FWIW, I use mine once a day and am even thinking of adding less frequent options). Therefore, all you need to do is create such a virtual device and couple it with a rule or other automation that performs the necessary command (e.g., push button 1 or turn on) at the desired frequency.
I believe this occurred when I ran a Device Activity Report this morning:
Debug logging is set to off:
The log message is accurate and also has the solution. If you don't use the LAN or cloud report pages (the links that open "outside" the app, not the in-app report), you can ignore it. If to want to use them, you'll need to enable Oauth as described in the installation/upgrade instructions and as is also documented in general here:
https://docs2.hubitat.com/en/user-interface/developer/apps-code#enabling-oauth
Also, FWIW, those log entries could only cold from opening the app and hitting "Done," not from having run a notification/report.