Then why do the iris plugs list themselves as connector type: none? That doesn't make a whole lot of sense.
And 8.02.11 interference wouldn't make any sense either. That would just make the case for this plug further away from the hub to use one of the avilable repeaters instead of trying to connect directly to the hub. If i was expecting a direct hub connection and it was routing through another repeater, then interference could be an explanation. But how could interference result in a device not picking the better route to the hub but trying for the "more difficult" one?
Okay...that I did not understand. I thought that since it is in the Neighbor table that this was the way it was communicating with the hub.
What really ticks me off is that for some reason, the plug that had the terribly low LQI is now showing an LQI of 250...so it obviously doesn't need a repeater to get to the hub. Sometimes you just can't win. lol
I do appreciate the explanation. It makes a lot more sense now.
Could there be something else other than wifi causing RF noise affecting the plug with intermittently low LQI values? Microwaves, Bluetooth, motors, fluorescent lights, cordless phones, etc. all can jam up the frequencies used.
Not long ago I went to a customer site to troubleshoot a poor wifi signal and found the entire spectrum was flooded with RF noise. The source ended up being a cell tower several hundred feet away.
Again, the issue is not the low LQI. Because of it's distance from the hub, I would not expect this device to connect directly. So, the Low LQI is expected. What was not expected was the device showing up in the neighbor table. But I believe that has been explained now.
Just because a device is capable of acting as a router does not mean that it is.. I have many Smart Plugs, last time I mapped out my mesh with an XBee, over half were effectively end devices. I also do not think that record (concentrator type) is defining the capability of the distant device. That device does not appear on the neighbor list so the hub is not aware of what its routing capabilities are.
If you look carefully, you will see every device in the Route Table Entry section has a device that it communcates through (via).
[Keypad, Back Stairs, 7D52] via [Microwave, 3EF3]
This means the hub is routing messages to the Keypad, Back stairs through the Microwave.
If you look at the Neighbor table, you'll see that the Microwave is there as a first hop router. That's all the knowledge the hub has of that route. I have SmartPlugs that appear as the second hop in that list..
Devices that more than those 2 hops won't never appear in the list, which I just confirmed with a distant plug..
I think the confusion here is that ChildAndRoute shows just one small part of the overall routing topology.
Agree. I had that discussion on here a few months ago. It is why that page is very misleading if you don't understand what it is / is for.
For instance, I have probably 20 zigbee devices that don't ever show up on that page (that I've ever been able to catch anyway). They are probably routed through too many other nodes, or are child devices that are popping on and back off the list before I see them.
Anyway, I rarely ever look at that page for that reason - it is just a slice of the whole story.
No one is throwing them away. I moved my one plug over to my "bulbs" zigbee network. You really need to stop being so presumptuous.
And the reason I did that is that no one could explain to me why it was jumping from one repeater to another so frequently in the router table. Once every few seconds. Since it didn't seem right to me and no one could tell me why it was doing it, I removed it to see what effect it would have on my network.
I did not throw anything out. You have been on this forum for a total of 9 days and so far you have contributed nothing but criticism and nastiness. Please stop.
I was looking at the table to try and figure out the other issue that we were discussing. While doing so, I noticed that my one peanut plug would jump from one repeater to another in the router table every time I refreshed the page. That didn't seem right and no one could tell me that it was fine or why it was doing it. So, I kicked it over to my "problem children" zigbee network. Since I have added a few zigbee devices to my main network and I removed a repeater, I'm giving it a day before i compare the performance to that with the peanut.
I put mine in the “drawer of home automation stuff”. I have the giant TP-Link plugs, a couple Lightify hubs, and about 12 Lightify bulbs. I’m down to 5 Peanuts because when I pulled one of them from the outlet the ground plug stayed. I haven’t seen any difference in device response without them and Hub Watchdog readings are still kind of bouncing around, but I did a zigbee heal after removing them.
IMHO the ChildandRouteInfo page is useful not for the nuggets of routing information it contains, but for the information it gives on the state of what are likely the most critical radio links in your Zigbee network-- the ones that the hub will use to send and receive every routed message. Want a good Zigbee mesh? First make sure that those repeaters you put in range of your hub are doing what you think they are doing (if your Neighbor Table has room for them, the ones that aren't capable of doing much will show up as well, to compare and contrast). The age counters, in/outCosts, and LQI figures are the only measures used by the Zigbee protocol to determine route viability and they are all exposed on that page. It shows not only how well the hub can hear its neighbor repeaters, but how well those devices are hearing the hub. You can tell from the link status figures which routers are doing anything useful, those that are on the fringe or are in the process of establishing (or re-establishing) neighbor status, those that have stopped reporting status, etc.
Unfortunately it isn't intuitive and the terminology is sometimes misleading (zero cost route==not viable; inCost is computed by the hub for traffic outbound to a router; the age counter for an established route always resets to 3; etc.). It requires some digging to understand what is being shown and obviously if you don't know what you're looking at, you won't get much out of it. Too bad nothing similar (and as easily accessible) exists in the Z-Wave domain.
Is there any way to make the LQI worse for a bulb that is a repeater with a better LQI than a zigbee repeater like the Iris plug? I recently added (5) of the Iris plug in repeaters, and have 10 Sage bulbs that are zigbee repeaters all on the same mesh. Unfortunately still some of the bulbs are preferred repeaters due to their better LQI from what I can tell.
I'm wondering if the base part of the bulb can be covered or something to block the signal just enough to make it slightly lower? I'm guessing here, but very frustrated that this technology is so poorly implemented by vendors.
The point being if the bulb sucks at being a repeater, don't repeat as a feature!
I was going to try that. The base of these bulbs by touch were not warm at all, so I was going to tape foil around the base. It sounds crazy, but I'm seeing some bulbs with an LQI of 255, and my repeater with 254. If I can get LQI to 253 or lower, maybe it will not be suitable for repeating. I've only got a couple of problem bulbs that are winning the route entry, so I'll try it and see if it makes a difference.
After wrapping foil around the base of the bulb, the LQI did go down,
[Ricks Lamp, 89B8], LQI:247, age:4, inCost:3, outCost:2
But I'm still seeing things route through the bulb:
[Great Room Repeater, 7F64] via [Ricks Lamp, 89B8]
That repeater has this:
[Great Room Repeater, 7F64], LQI:255, age:4, inCost:1, outCost:1
I wonder how long it takes this to migrate....
I work on data networks, and I'm used to routing protocols (ospf, eigrp, bgp, etc) but man o man is this has got to be a terrible protocol for this many vendors to write their drivers this bad. I moved over to HE from Smartthings for the latency reduction and local processing. I never had any issues with things taking seconds to respond. I'm not blaming HE, just saying this did not happen with Smartthings, and I added 5 Iris repeaters to this network to fix it.
It sounds like the fix is another hub to isolate bulbs. Its a tough pill to swallow when this all worked so much better on the cloud based system....
I pictured the same! So dumb to have to come to this. It did lower LQI, I just need to see if LQI lower alone will make their IN/OUT costs low enough for my repeaters to 'win the battle'
In the end, It sound like I'm going to need another hub for this. Frustrated since I did not see these problems with ST. In a home automation environment with 10 light bulbs, some switches, etc, would require two hubs to operate. Again more of a zigbee problem....
Sometimes you just can't win. lol
