Weird Zigbee Routing

It all depends on the orientation of the antenna within the device and the composition of the obstructions between the hub and the device. For example, I have a couple devices that choose to go through repeaters on the other side of the house. That's because between them and the closest repeater is a giant air duct which makes a great RF shield. So, there is a rhyme and reason as to why it chooses the routes it does.

That said, this is a good reason why you should always pair your devices "in-place" where they will be used rather than close to the hub. That way it picks the best route right off the bat. Zigbee is a self-healing mesh, which means is there is a problem, it will re-route it's messages eventually. However, I have seen that in cases where a device is on the edge of communicating or not but never quite goes over the line to not working, it will stay in the bad route.

You can force the zigbee mesh to heal itself faster. If the Coordinator of your mesh is not present for 20 minutes, your zigbee devices will go into panic mode. When the coordinator comes back online, they will assume that the mesh has been relocated and will rediscover routes to the coordinator. That said, it is not recommended to do this often because it eats up a ton of battery power in your battery powered zigbee devices.

I definitely pair all of my devices in place. Two of the Zigbee Repeaters on the list were added in the last couple of days and I did do the zigbee mesh force heal. All of my devices, Zigbee and Z-Wave, are working great so I can't complain. I just thought the routing table was goofy.

The getChildAndRouteInfo link isn't the whole routing story and isn't meant to be. To get a better picture, you need something like an Xbee and specialized software.

Stop trying to get me to buy more stuff!

7 Likes

Hey Stephen, couple questions...

  • What are you using to monitor the Zigbee mesh?
  • What Device Type are you using with your EcoSmart Bulbs?

There seems to be an issue with the Generic ZigBee CT Bulb (dev) reporting the Color Temperature correctly.

Thanks, Glenn

I was just looking at the native zigbee information you can get from hub using: http://HubIPAddress/hub/zigbee/getChildAndRouteInfo

I am using the Generic CT Zigbee Bulb (dev) but that is not the device type that was assigned when it paired to hub. That was the suggestion in this post:

I haven't noticed any issues with the reporting and they seem to working as repeaters. I am about to buy an Xbee to confirm.

I tried that device type but when I change the color temperature say from 2700 to 3300 it reports back a color temperature of 46 until I refresh the device.

Weird. I did notice when I change the bulb temperature using the device page, the page shows that the temperature always goes to 46 first then up to whatever value I entered.

What type of bulb are you controlling?

Any other neat tricks like this I don't know about?

I agree. The xbee will tell you a better story. I see my Zigbee mesh changes very often.
It's good practice to pair your device in place but not always possible. I usually get initialization failed if I paired the device a couple of repeaters away so I bring the device closer to the hub for pairing and just give the mesh enough time for healing after.
Also agree with Ryan about battery life during healing. I have 100+ Zigbee devices so mesh and battery are the 2 most troublesome on my list.

I have been fortunate in that other than the first time I paired one of my Eria dimmers, I have been able to pair devices in place and it makes perfect sense why we should do that.

I am getting an Xbee. I am just trying to decipher which one to buy and what other pieces that are required from the multiple posts about them on this forum.

We are discussing those Ecosmart Bulbs that were just on clearance at HD with the remote that you & I are waiting on Broderick to release the DTH for on ST.

And the CT is going to 46?? That's very odd. I'm not seeing the same. But min is currently connected to ST.

model: Ecosmart-ZBT-A19-CCT-Bulb
manufacturer: The Home Depot

When the color temperature is updated to any value, the bulb updates correctly with the new CT but the Current State always shows 46/Sodium until it's refreshed at which point it displays the correct information.

Yeah, when I change color temperature, my device page always goes to "Sodium" and "46" but only momentarily then it goes to assigned name and temp.

Mine changes to 46/Sodium then looks like it's going to updates correctly but then quickly flips back to 46/Sodium.

You're using the Generic Zigbee CT Bulb driver?

Out of curiosity, I played with my bulbs when I got home and a few of my bulbs do in fact get stuck on 46-Sodium on the device page but the bulb is the correct temperature best I can tell. The ones that don't get stuck go there momentarily before going to the correct temperature. Finally, I have those bulbs in a group of 5 and group of 7. When controlling those groups, the group page shows the bulbs going directly to the temperature I designate. WEIRD!!!

This is doesn't occur when I use the General ZigBee RGBW driver.

To overcome the issue, I created a rule that does a refresh when the color temperature changes. Seems to have resolved the issue at least until there's a fix.