Are there are currently more than 2 hops from hub to lock?
Options I can think of without more information:
- perform a repair on the repeater and lock
- exclude and re-include the lock
- relocate the extender, repeat 1/2
- Give it more time...
I don't have issues with the Kwikset, which is in the same room as the C7 hub. The August Pro either routes directly to the hub or with up to two hops between. The lock is unstable and will work shortly after a power down of either the hub or the lock itself. But shortly after, it stops responding so I figured the range extender should help.
Do you expect that the range test to be able to work with the locks? It is weird that right after a exclusion/inclusion of the range extender it is able to test all other devices, but fails when trying the locks?
I don't have much familiarity with various locks, but I do know that they are battery powered and spend most of their time sleeping to conserve power.
The range test is a direct (non routable) transmission from the range extender to the device under test. If the device sleeping, there is nothing to wake it up and the range test will fail. To test sleepy devices, you have to manually wake them up immediately prior to testing. You may also need to temporarily change the driver for the target device to the generic "Device" driver to prevent the hub from immediately sending a command to put the device back to sleep. Don't forget to put the proper driver back after testing.
Also, based upon what I've read in passing, you probably want the range extender relatively close to the lock... but I think you should confirm this with people who have more experience with locks. The thread that you started in the Support board is probably a good place.
Hope this helps.
1 Like
That makes a lot of sense about the lock and range test. Thanks for your response.
1 Like
Thanks for this. The range test is very useful. Also, thank you for the description about "waking" the lock prior to testing. Works perfectly!
2 Likes
Welcome to the community! And you are most welcome.
2 Likes
thanks for this driver .. a couple of requests.
i have had one drop off the net and never noticed.. it is possible to add some checkin code or something.. refresh() function does not return anything..
Maybe a runin command addeed with refresh() assuming refresh actually returned something.
I have to do a power or range test to see if it is still working.. would like to be able to schedule something say once a day to have something go into the event log to make sure it is still working and then use the device activity app to report to me if and when it drops off the net..
thanks in advance.
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.
