If you refresh() the device, Last Activity will be updated if the device is functional. You can use an idle monitoring tool, such as Simple Idle Alerts, to monitor the device.
2 Likes
no it is not working.. i have 3 of these devices and refresh shows nothing in events but other fxs work fine.. ie see here.
Activity is not the same as Event. Look at column "Last Activity" on the Devices tab. This is generally what idle monitors look at.
To be clear, I use a combination of Idle Node Refresher and Simple Idle Alerts to monitor for devices falling off my network.
ok i made the changes myself to my version.. as you can see above refresh was not causing any events in the logs..
here is the modified version
namely these changes
attribute "indicator", "string"
attribute "powerLevel", "string"
attribute "rangeTest", "string"
attribute "rangeTestReceived", "string"
attribute "lastUpdate", "string"
input name: "logEnable", title: "Enable debug logging", type: "bool", defaultValue: true
input name: "txtEnable", title: "Enable descriptionText logging", type: "bool", defaultValue: true
input name: "enableScheduledRefresh", title: "Enable daily scheduled refresh", type: "bool", defaultValue: false
def scheduledRefresh()
{
if (logEnable) log.debug "Scheduled Refresh"
refresh()
if (enableScheduledRefresh)
{
if (logEnable) log.debug "Scheduled Refresh is true, re-scheduling for one day."
unschedule()
runIn(86400,"scheduledRefresh")
}
}
def updated()
{
if (logEnable) log.debug "Updated preferences"
log.warn "debug logging is ${logEnable}"
log.warn "description logging is ${txtEnable}"
if (enableScheduledRefresh)
{
if (logEnable) log.debug "Scheduled Refresh is true, scheduling for one day."
unschedule()
runIn(86400,"scheduledRefresh")
}
runIn(1, configure)
}
def parse(String description)
{
hubitat.zwave.Command cmd = zwave.parse(description,commandClassVersions)
if (cmd)
{
def now = new Date().format('MM/dd/yyyy h:mm a',location.timeZone)
sendEvent(name: "lastUpdate", value: now, descriptionText: "Last Update: $now")
return zwaveEvent(cmd)
}
if (logEnable) log.debug "Non Z-Wave parse event: ${description}"
return null
}
You aren't looking at the right page. To be clear, Last Activity for a devices is NOT an Event and does not show up in the log. It isn't something that you find on the individual device page.
To see the last activity time for a device, open the Devices tab (under the green Hubitat banner on the left side of the web interface) and look at the Last Activity column. This is the only place you will find this information in the UI.
Note the time of the last activity for the repeater. Now open the repeater device, and press the Refresh button. Now go back to the Devices tab and refresh the browser. You will see that the Last Activity for the repeater device has changed. This is what idle monitors look at--not events.
2 Likes
thanks.. good to know.. i still like to look in the events to see if a device is active.. i have another ring extender v2 that now has dropped off the net and not reporting.. i had one here and re-paired it to get it working again..
unfortuately this new one is in my empty house.. wonder if there is a known issue with ring firmwares.
I have 6 Ring Alarm Extender V2 and they have never fallen off the net, all keep reporting. However, I believe that there is a bug in the built-in driver, such that Refresh (whether by hitting the button on the device page, or programmatically from Rule Machine) doesn't seem to work. When an extended power down event happens, the Hub correctly receives the "switch to battery" event. After a scheduled time, the Hub shuts down (I've got a voting rule on the Ring Extenders). As expected, when mains power eventually comes back up, the Hub misses the switch to mains event because the Ring Extender boots before the Hub, and so the device driver believes that the power state is on "battery". However, hitting the Refresh button, or, programmatically doing a Refresh on the device (in a systemStart() rule), does not restore the power to Mains status. The only way to get the device back to Mains status seems to be to pull it out of the wall, let it send the "switch to battery" event, then plug it back in, let it send the "switch to mains" event, both of which are caught by the already booted Hub.
I turned in a bug report last March to @bcopeland, he said he'd look at it. Then, about a month ago, I turned in a repeat bug report to him. Not a word in response.
FWIW, refresh on this diver covers the mains/battery status:
1 Like
Thanks, I will switch over to your driver and see what happens.
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.
