To objectively say, I think you'd need to observe the network long term with a Zigbee sniffer and see if packets "disappear." This is what staff observed with certain bulbs in the early days of Hubitat and is what prompted the caution against using some of these, at least when mixed with non-bulb devices. I don't think anyone has done that with Innr bulbs—or done so recently at all.
So, all we have to go on are anectoes, and anecdotally, I've seen many people comment and say that they appear to be using them without problem. If I had a Hue Bridge (or second hub dedicated to just bulbs), I'd still probably play it safe and use it there instead, but otherwise, I'm not sure I'd be too concerned. There are other bulbs people have reported using without apparent problem as well, many of them being newer and many being Zigbee 3.0, both of which seem to correlate with less problematic behavor (though the Zigbee profile alone is no guarantee of a specific behavior, no matter what may get repeated over and over...).
Yup, experiential reality is all that I can reasonably ask. Having no obvious problem is the low threshold for consideration. Routing politely to other devices (as seen on getChildAndRouteInfo page) would be a huge gain for me.
I can say no issues what so ever and these lamps have some extra tricks up there sleeves aswell as a they support find and bind for example.
Not at home to be able to provide routing tables but I have some at mine and a few at my inlaws. Personally I will stick with inur for all my future purchases and can't recommend them enough.
I really appreciate the first hand account and endorsement. No need to go out of your way to provide your actual routing table ... I just wanted to make sure that folks had actually observed it being used as a repeater.
Note that this isn't exactly the problem with other bulbs (e.g., Cree) that have been demonstrably problematic--they are being used as repeaters, and the issue is that they just don't do a good job at it. Messages routing through them just get lost from time to time, something you can't really see from the getChildAndRouteInfo page and would need a sniffer to verify (though experiencing seemingly random Zigbee problems that disappear when you remove the bulbs from your network is pretty convincing evidence, too...).
Ah, got it now. There are more layers to this than I was previously aware. Once you navigate the application (can it be turned off) and the protocol (ZLL/ZHA/ZigBee3.0), you also have to beware of certain sketchy models. Thanks!
All I can say is I had issues before with old lamps and missed event's. They are old osram LL lamps and Philips hue I moved them to their own hub and all newer better quality and ZigBee 3.0 lamps are on my main hub and I have not had a issue since.
The theory being ZigBee 3.0 has to cope with a lot more traffic rather just LL lamp stuff. So the thinking is they increased the buffer sizes inorder to pass tests etc.
It's all antidotal as without a sniffer we can't check, but that's my "theory".
The INNR has been awesome - first, I went with them because the bulb socket was unique and they were the only good solution without dropping mega bux.
Second, INNR as Zig3 has been rock solid. More so than GE, than Sengled, none of my INNR has had an issue whatsoever. As a repeater, all are located out at far ends of my zigbee network so can't see any route specific data . I screened this for you in case it was interesting: