I don't follow... What does a report have to do with a Peanut plug?
1 Like
That is what has got several on here considering replacing their peanut plugs based on the readings of that report.
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.
4 Likes
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.
1 Like
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.
2 Likes
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 have one Zigbee device that's always 20 points lower than surrounding devices, because it's inside a metal ceiling fan case.
Perhaps you could try wrapping the sockets of your bulbs in tin foil.
1 Like
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.
More to come... Thanks
1 Like
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....
OMG .. I laughed at this...
2 Likes
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....
