I also notice in the device page that there is a switch for "Hub Mesh Enabled" and it is off, should I toggle this on?
Hub Mesh is just for linking multiple Hubitat Hubs together.
Well from yesterday until today the lock went from 51% to 29%!
I contacted Yale and they are sending a replacement zigbee module and inside part of the unit.
She seemed upset I didn't contact them sooner, "since I knew the battery was draining"?
Thought that was strange, but hope this fixes my issues!
1 Like
Hopefully, the new Zigbee module will take care of the issue with battery drain.
Although you have multiple Zigbee outlets/repeaters around the house, the critical thing is to have one of those repeaters as close to the lock as you can get. Signal strength drops off inversely with the square of the distance. Thus, the signal strength 16 feet away from the repeater will be only 1/16th of the signal strength at 4 feet. The closer you can get the repeater to the lock, the stronger the signal and the more reliably the lock will function.
One thing your getChildandRouteInfo page's route table entries are showing is that virtually all of your devices are linked to the hub through the Kitchen Counter Light Plug 266B, including some of the hub's neighbor devices such as Dining Room Plug and Hallway Plug. The only other neighbor devices which are actually using direct RF links to the hub are Cabinet Lighting and Unused Bulb.
This isn't by itself an issue that requires fixing-- indeed you can't really change it without moving things or adding a repeater as the links get chosen for routing based on signal strength and error rate. It doesn't mean those neighbor devices aren't needed where they currently are, as they may be parents of sleepy child devices. And it wouldn't necessarily affect your lock, since the link between the 266B device (which the lock is using) and the hub is strong (*but it might, since the info page says nothing about the signal strength of the link between the lock and the 266B plug).
In fact, all of the neighbor table entries look OK, with the exception of Bedroom Dresser Light C731 which doesn't have a viable link to the hub, at least when this snapshot was taken. But it's worth keeping in mind since anything that disrupts that link to the 266B plug will have a big effect on much of the traffic through the mesh (at least temporarily until some less preferred link takes up the slack). I'd probably try adding another repeater in the vicinity of that 266B device to help balance the load if it were convenient, as that seems to be an RF sweet spot for links to your hub.
1 Like
That’s really interesting, I was trying to make sense of what that all meant.
That plug is the old peanut plug, not sure if that’s a bad thing? I’ve never had issues that I know of with the plug, but have read a lot of people have and dislike them. Unfortunately it is plugged into the only outlet in that area so can’t add anything else.
It’s an older 60s house so not a ton of outlets, but they now all have a zigbee plug, so hopefully creates the best mesh possible.
I don't have any experience with that type; but it seems to be working for you. It might be useful to look at the getChildandRoute info page once in a while and see if route table entries continue to show the lock routing through it. One thing that could cause battery drain is when an end device continually changes parents; Zigbee end devices typically don't do that unless something disruptive happens. That could cause higher battery drain. Edit: Without a mesh map, it's possible that the lock actually is not a child device of 266B but some other repeater that also routes through 266B; can't say for sure since the route table entry just means that the first hop from the hub (to get to the lock) will get routed to the 266B plug). But unless your mesh is fairly dense, it seems likely that it is.
A stable mesh will usually show the same devices in the neighbor table, but it's normal to see the age counters (measures of 15 sec time intervals between status exchanges) and costs change. Age counters will increment from 3 to 6 on normal links. Age 1 or 2 will be seen when a link is syncing up and age 7 when the link is considered stale; usually that's when 0 appears as an Outcost field meaning a status exchange has timed out. Those links won't be used for routed frames (but low non-zero cost numbers are better than higher ones).
Hole-in-one!
This is precisely the issue that some of us have observed with Peanut plugs.
3 Likes
