I ran network repair and my Honeywell thermostats is routing through a Yale z-wave lock. That should never happen. I’m using Rboys lock device handler.
That can’t happen. it has nothing to do with the device type handler. However, at one point there was an error in the reporting and it was listing the devices on the route backwards, which would mean that the lock was routing through the thermostat. So I’m wondering if that’s it.
2 Likes
I ran a repair on Sunday and on Monday my routes were all messed up. I ran one again yesterday and now they are fine.
1 Like
We got this issue resolved pretty quick, so this should no longer be an issue 
@RottenMutt, it is possible that the Z-Wave locks are actually acting as repeaters and therefore other devices would route through them. You can check this by looking at the Raw Description of the device in the IDE and seeing if it is lists zw:L. If so, that device will act as a Z-Wave repeater.
Battery powered Z wave locks are very zealous of protecting their battery life. That’s the whole reason beaming was invented.
I don’t believe there are any that are manufactured to act as repeaters. So if they are coded that way, that would sound like a platform issue.
zw:L type:4003 mfr:0129 prod:0002 model:0000 cc:72,86,98
Above is for the lock. Shouldn’t it be “S”? So it is acting as a repeater. My thermostats keep dropping off line, that is the problem I’m trying to resolve.
So does the device identify itself as a repeater or is it the device handler. Can you specify in the device handler if it is the device and you don’t want it to?
1 Like
I have in the past had problems when adding z wave devices and some part of the setup didn’t get the right data for the raw description. I wonder if that is what happened here.
Have you tried removing and then adding the device again?
What’s the model number? As far as I know, all Yale battery-operated locks identify themselves as “sleeping slaves“. Not repeaters.
You might also check with Yale support.
Hopefully this is added to the routing info they are building out. The zigbee equivalent is already listed for the device.
Looks like a Yale real living deadbolt. The L is definitely an issue, never seen that before. It could be one of 2 things:
- Data corruption while pairing causing the hub/platform to inadvertently mark it as a Listening device. I don’t think it’ll work as a listening device but it will probably cause issues with your routing and possibly packet loss/delays. Excluding the lock and pair it again. If it fixes itself (either as F or Fs) then it is probably just a temporary corruption.
- If after excluding and pairing it again, it still shows up as L then I would report it to ST support to investigate it as it may be something systemic. You may want to try to reset the lock and see if that helps and then exclude/pair it again. If that resolves it then it was a lock issue.
The type is set during pairing before the DTH kicks in, there’s nothing you can do about it after pairing the complete.
2 Likes
They are Yale touch pad keyless deadbolts. I have three of them and they all read the same.
Doesn’t the Aeotec multi sensor 6 switch To repeat or when plugged in, so one would think there mechanism to do so in device handler…
The Aeotec device which can be either a sleepy device when on battery or a repeater when on USB Power is determining this for itself at the time that it joins the network. The DTH doesn’t have anything to do with it. And if it was battery powered at the time that it joined and then you plug it in via USB it won’t start repeating. You have to exclude it and include it again while it is plugged in to get the repeater functionality.
1 Like
Honeywell thermostats act as repeater if connected to a C-Wire while pairing. It’s possible the locks are routing through the thermostat, so I’m wondering if something is backwards here. I’m assuming you’ve tried to exclude and re pair all the affected devices (try a hub reboot before pairing them again)
I have not tried to exclude/join as I don’t think that would correct anything, if one was correct and two were wrong I would be all over it.
I ran multiple repairs and now the thermostats are connected directly to the hub as they should be.
Can you post screenshots of the routes. This should not be happening and ST is looking into it.