Just looked at the current docs - EFR32 is not mentioned. I’ll open a PR as soon as I get the new sticks and I can test them with the different firmwares.
Is your zigbee library compatible with EZSP v8, or should I stick to v7?
1 Like
Yes. I use this here with firmware version 6.7.
On zigbee2mqtt also? I’ve seen people on zigbee2mqtt forums with 40 nodes stable but didn’t try it myself.
On zigbee2mqtt also? I’ve seen people on zigbee2mqtt forums with 40 nodes stable but didn’t try it myself.
It seems to depend on the devices you have. Some routers are not very good at routing, and this has an impact on network performances too.
zigbee2mqtt is also less chatty on the network, having a devices database. And we go full circle now and go back to the original topic: renaming things triggers a node discovery, and that kills performances on CC2531 with ~20 nodes (with and without source_routing) 
Agree. It seems to be a mix of multiple problems.
One last question, and sorry for that 
I’ve seen that you tried the configs mentioned in this post, are they the same as the source routing firmware, or do they improve more?
I want to go with a solution that can help me complete my installation of 40 nodes until we have the new improvements on the binding.
This is a double edged sword. The database is a pain to administer, and it requires devices to be in the database before they work if you rely on it. This is the situation we have with ZWave and what I was trying to avoid with ZigBee. These protocols are self describing so no database should be needed.
The chattyness should only an issue during the very first discovery - this is when the data is downloaded from the device, and after this it is stored in a local database. It should not be re-requested each time discovery is started (in general) but there is some additional traffic that occurs at this time.
It is hard really to know what your problem is, so I cannot be sure what the solution will be and can’t say that the changes I’m making will help for sure. As I mentioned above, there are many issues here - each may require a different solution. There are certainly some issues in the framework at the moment with large networks - multiple broadcasts cause a problem, and if you try and command lots of devices at once, there are problems. This is only tested with the Ember NCP though - maybe these issues don’t exist with the CC2531 - I don’t know. Also depending on the network topology, there could be other issues - it’s quite complex and a lot of this is hidden because it is handled by the coordinator firmware.
My custom firmware is as following:
- stock ZNP-Pro-Secure-Standard 1.2.2a
- patch for source_routing coming from a post in the TI forum
- source_routing patches from z2m
- source_routing patches from Optimizing the cc2531 firmware for OpenHAB and the Zigbee binding
I’m adding devices to the network very slowly - 2/3 at a time and testing the network for ~1 week between changes. I’m currently at 22 devices.
Because of the broadcast issue (which may be a problem with Ember only) I initially had problems adding lots of devices at once. Once I changed the way the discovery worked to remove the broadcasts, I could add 10 bulbs at a time - basically just opening up join for 2 minutes and screwing the bulbs in to the holder as fast as I could 
. The bulbs came in packets of 10, hence why I was doing it like this, but it worked fine.
My only hesitation though is that this could be a problem that only appears with Ember, so I don’t want to say it will solve everyones discovery issues 
I think currently we have 2 main problems:
1- the cc2531 capabilities and how its firmware is configured. This had nothing to do with binding AFAIK.
2- The binding implementation and how chatty it’s on the network. I agree with you about the discovery and I think it is much better than database approach, but I think it is important to make sure that it is optimized and no unnecessary discovery/communication is happening, which I think it’s what you plan on improving.
I want to make sure that I optimize problem 1 while waiting for problem 2 optimizations.
Thank you for the hard work.
I’d love to learn more about your findings later, and maybe we can have your firmware as an option in future if it improves the performance.
But what does this mean exactly? What do you suggest that can be reduced? Currently, the binding requests the device information when the device joins the network. If you have suggestions about anything that is not necessary, then please let me know. This binding, and the libraries are used in tens of thousands of applications.
I don’t think there are any unnecessary discovery communications taking place. We request the endpoints and the descriptors, and information about the device (model ID etc) so that it can be identified. In general, this should only happen when a device first joins the network and all of this I would consider necessary, but if you have a better idea then please say - I may well be wrong?
As above, if you think that some of this is unnecessary then Im very happy to discuss this.
No - the changes that I’m making will not change the way that discovery works. I expect that with the Ember NCP at least, it will help by reducing broadcasts which have limitations on the number that can be sent in an 8 second period (the limitation comes from ZigBee).
https://drive.google.com/file/d/1xuWsZcx86t6Hcy0gkCODeAtrSvJ9RySK/view?usp=sharing
try it at your own risk. it shouldn’t brick your cc2531, and you might have to re-pair everything.
1 Like
I didn’t dig into the code yet, but I found a closed pull request from @giuseppeiannello that mentioned eliminating unnecessary rediscovery that happened on starting a scan, and I think you left an open issue about this.
Am I missing something here?
so far, even if the rediscovery still happens on starting a scan, I can add nodes to the network - I’m using the stock add-on, without my changes. but could be because of the custom firmware.
That is above how OH performs discovery - in theory it should not impact the network itself except in some circumstances such as rejoins (that should be very rare).
Possibly.
This is the binding code that you refer to - not the ZigBee code. The ZigBee code that performs the discovery is in a different library.
Maybe we are talking about different things. In general, I’m talking about how the ZigBee system performs a discovery - ie the network traffic that is gathered during discovery. Very little of this is done in the binding.
Then probably it’s the firmware limit. I should try the other firmwares that implement source routing and see if it can help me add more things and improves the performance.
Yes, I was able to add devices until I hit the ~35 mark, then things started to be different. I should try another firmware and see.
I just found out that the stick I am using has CC2538 + CC2592 
Apparently it is more powerful than the cc2531 or cc2530, and it seems that it works with the same 1.2.2a firmware as any cc253x.
I think the modified firmwares should work without problems, unless they have memory specific configurations which I will need to update according to the cc2538 **fingers crossed**
I was wrong, it uses a different firmware, which means I had to apply the optimization to the cc2538 firmware manually.
The chip also supports a more powerful firmware (Z-Stack_3.0.x) which according to Koenkk’s version should handle 200/400 routes. Although I am not sure if it is compatible with the Zigbee binding (worth testing)
I think the modified firmwares should work without problems, unless they have memory specific configurations which I will need to update according to the cc2538 fingers crossed
CC2538 is a different compile-time target, so my custom firmware linked above will not work with it.
On the other hand, you will hardly need those customizations, with that hardware
BTW, I’m experiencing big problems with 2.5.7. had to rollback, the network is pretty unusable otherwise.
I thought that my hardware was good enough to handle ~40 nodes, but unfortunately, I couldn’t add devices after 35, and worse my network collapsed after 2 days and many nodes are offline/unresponsive without doing anything. I am on 2.5.7 as well.
I was looking for a source routing firmware hoping that it might improve things and all I can find is Koenkk’s version which is based on Z-Stack 3.0.x.
I also have a cc2530+RFX2401 or CC2530+CC2591 (I am not sure) dongle which is refusing to work with the binding and showing the message:
Dongle reset failed. Assuming bootloader is running and sending magic byte 0xef.
Attempt to get out from bootloader failed.
I tried default firmware, modified, and everything I can find and it is still not responding. Although it worked with zigbee2mqtt!
I am having some bad luck with Zigbee so far 
I’ve split my system into 2 different ZigBee dongles with ~15 nodes each, and I upgraded to the latest version of the system. Now everything is working smoothly 
.