Zigbee PAN Identifier Conflict

I don't know if they are doing Emperor for a month yet, but I would certainly second that! @Kings


Let's wait and see if it actually helps before we name him Emperor. LOL.

I expect it will help, though.


Ah yes good point. Proof & pudding & eating, or suchlike. If it doesn't work then I will lead the outrage, accusations and vitriol heaped on him lol :stuck_out_tongue_winking_eye: :rofl:

1 Like

Do remember that the fix coming is only for one of the two major issues causing mass-device drops in an otherwise stable mesh. That fix in itself is also not the complete and final solution. The final solution would need to be more complex than just changing EMBER_PAN_ID_CONFLICT_REPORT_THRESHOLD. That is a change which will take more time and resources to develop, I'm sure when they have the time they'll get to it :slight_smile: At least we get this one for now.
The other major issue occurring due to repeaters changing their 16-bit address is not entirely possible to "fix" from the controller, but plenty can be done to mitigate and reduce the risk and frequency of such changes. This is again something which will take some serious development resources to get right and while I hope they will put the resources needed into doing this I have no idea how this will be prioritized.
Then we have all the other possible issues that can plague a mesh, but most of those are not something that can be fixed/mitigated from the controller. Some can be reduced in severity, others can be reduced in frequency and likelihood, but in the end you still have to build a good mesh :stuck_out_tongue:


@markus I was wondering if you see the improvement you expected with this change?


I've not yet moved my Zigbee mesh back to the channel where this was a problem for me, but will do so when I have the time to re-pair my devices. It should help, but without looking at the traffic in Wireshark it would be hard to know for sure. If anyone does that, please let me know :slight_smile:

1 Like