Is this a common problem with Hue bulbs then, or just a problem with @FranzS system? I’ve not been able to get hold of the logs yet so can’t assess the issues there. One thing I know with older Hue bulbs is the binding table only had a single entry which means some reports aren’t sent. This shouldn’t cause them to be marked offline, but can cause other status update issues.
The binding uses reporting to keep tabs on a device, and if it doesn’t receive a report in twice the reporting period, plus 30 seconds, then it will send a poll to try and get the status, and if that also fails, it will be marked offline. So the binding is trying quite hard to see if the device is really there or no before marking offline and I think that after this, if it’s offline, then there’s probably a communication issue down in the network.
There’s no real fix to this. Once you send a command, you have to go through the motions, and it takes up to 8 seconds for this to timeout due to the way 802.15.4 works. The NCP can handle around 5 or 6 commands at a time, and the binding (actually the zigbee libs) will pace this - only sending enough commands to keep the NCP busy, but not choke. If you try and send more commands, then it will slow down in the binding.
Sending commands to devices that the coordinator hasn’t seen for a while can cause it to perform a route discovery - this is dependant on a bunch of things, including the way memory is configured in the devices so it’s hard to provide general answers here. For commercial customers where there is some control over the firmware, there are changes that can be made to improve this for larger networks, but here people get firmware from “somewhere on the net” so it’s hard to be sure how this is all configured.
It’s sort of both. The binding “allows” the NCP to discover routes if it doesn’t know the route. Actually this isn’t something the binding can control as it’s managed down in the zigbee library. I don’t think there’s a lot of option here though - if the device route isn’t known, then it needs to be discovered otherwise it’s not possible to communicate with it.
I don’t know if this is a good idea either. The problem here is that if it’s offline, and we never send commands, and the device isn’t reporting for some reason, then it will never come online, and therefore never work.
I am open to good ideas here though so feel free to offer solutions - even if they don’t make sense, they might inspire something in my mind that does make sense (but don’t be offended if I shoot them down - it’s just part of the engineering process ).