[RELEASE] Aeotec Range Extender 7

Range Test and Power Test are standard Z-Wave tests for a repeater.

Range Test sends pings to a given target at the power specified, and reports how many replies it receives. This is useful for testing repeater placement.

Power Test operates the radio at reduced transmit power for a period of time. This is useful for general testing of paths through the repeater.

For both items testing at lower power levels gives you an indication of reliability. If the repeater functions at -9dBm in testing, you can be pretty confident that it will preform reliably at normal power level. However, if the repeater starts to loose packets by -2dBm, you probably need to find a better location.

3 Likes

I installed this repeater yesterday. I expected the repeater to appear in the routes of some devices buit it doesn't. Is this normal? Also ... wouldn't (some) routes change because of the added repeater?

Today I updated the driver from the "Generic z-wave repeater" to the driver from this thread. Is it okay that now or before I was not asked for the DSK?

I am trying to do range tests to 2 nearby fibaro motion sensors which I excluded and added after installing the repeater but with no success. Does the range test work to battery powered devices?

Thanks for who has time and patience to enlighten me.

Don't be worried about the repeater not showing up in routes. The repeater will generally be used over time as routes are recalculated. With Plus devices, this generally occurs in response to the device being operated, either physically or by Z-Wave command. With non Plus devices, you will have to perform a repair.

You will only be asked for the DSK at initial pairing. Changing the driver will not affect that. Nothing to worry about.

Range test will only work with a battery powered device if the device is awake for the duration of the test. This means that you have to wake the device up, run a test that fits in the time that the device stays awake, and the driver has to not send a wakeUpNoMoreInformation command to the device.

NB: You can suppress the wakeUpNoMoreInformation by using the "DEVICE" driver rather than the real one while you are testing. If you do this, be sure to run a configure after changing the device driver back, and then wake up the device to ensure the config is communicated to the device.

5 Likes

Thanks for the info and thanks for making the driver :+1:

3 Likes

I am trying to get the Range Extender 7 with my August Pro Lock for over a month. It will never route through the range extender. I just found your driver and tried to use it since it can perform the range test. What I am finding is that the range test succeeds for every device but my August Pro lock and a quickset lock, which report back as failed. The August Pro is included at S2 and the Quickset is at S0. I have tried the range extender included at no security and S2, but it makes no difference. Do you have any ideas for why the Range Extender doesn't seem to talk to the smart locks?

Are there are currently more than 2 hops from hub to lock?

Options I can think of without more information:

  1. perform a repair on the repeater and lock
  2. exclude and re-include the lock
  3. relocate the extender, repeat 1/2
  4. 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.



but if i do a range test

so ovbiously it is working

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