If i remember right I also used the Dual CP2104 Driver. But I can find it out if you have some more trouble in the future.
To extend the range of your zigbee network you can do 2 things:
In the PaperUi there are some settings for the Zigbee Dongle. You can set the Transmit Power to High.
Every Zigbee device that is connected to the power behaves like a ārange extenderā (dont know whats the right name). So if you have many light bulbs in your home they communicate with each other and and can be controlled even if they are to far away from your dongle.
Just a heads upā¦ ATM I would not recommend the elelabs dongle, their communication is non existent right now, I just hope it has nothing to do with the virus. I have trouble with my order (it did not ship), tried to contact them trough 3 different email, no response for a week now. There is no information on their website either. If there is any update from them Iāll edit this post.
They did reply to me after all, turned out they accidently gave me the wrong tracking number, and my order is still on the route.
Just bought a stick + shield from them, delivered in ~1 week, and both working fine.
One of their team members is active on Github and they seem to have a few updates in the pipeline.
@Elelabs would you mind letting us know when the v7/v8 firmwares and the flashing utility will be ready for download?
Small side note: the documentation for your shield is incorrect - 115200 + Hardware flow control is the right setting now
Iāve also seen this recently with my larger network tests but Iāve not had a chance to properly characterise this yet. I am surprised though to see these as the EFR32 should have āplentyā of spare memory and I donāt think the collective settings that the binding uses are that demanding on memory.
It should work fine as a high ram concentrator. In general this would be the best configuration (especially in larger networks) - I donāt use this as the default as many people are using older devices (eg the EM357) and Iām not sure how well it works with the 357 due to memory.
Iām not sure there is one as such. If possible, using the high-ram concentrator is better as it will reduce network traffic, but it requires more memory on the coordinator. If the coordinator has the resources to do this, then it should be used.
With the Ember NCPs, there are lots of configuration parameters - they āallā take certain memory, so itās not possible to increase everything. ZigBee 3 pushes up the number of keys required to be stored, so if every device requires a link key, we use a lot of memory and we canāt then bump up the source route tableā¦ Itās always a tradeā¦
This is kind of why I mentioned earlier (I think in this thread) that I wanted to look at doing the source routing on the host as this can relax the memory requirements on the coordinator for storing the source routes, and allow this memory to be used for other things that canāt be offloaded to the host - such as link key management.
Without checking, I suspect that it canāt - memory allocation is done prior to starting the stack for the reasons partly eluded to aboveā¦ The stack needs to know all these settings, as there is another setting for the number of packet buffers used, and the stack will allocate all unused memory to this when the stack starts.
Sorry, asked the wrong question there - obviously some parameters are set on stack startup, so disabling/re-enabling the coordinator is necessary. I wanted to ask if itās necessary to wipe/re-pair all the devices when changing that value
No. All that changes is the way that the coordinator requests routes. Once it has been configured as a concentrator, it will periodically send the MTORR (Many To One Route Requests) to discover routes.
There is I suspect some optimisation I can do in the driver, and Iāll look at this over the coming week or three.
Probably not - but testing/breaking would be great (so long as I can fix ), and of course some documenting would really be good (and much appreciated ).
Regarding that - the network seems to work, even after the error during initialization. Does it fall-back to the default value? Whatās the practical effect of the value not being correctly set?
I think it just ignores the last setting. If you are looking in the binding logs, you should see 3 sets of configuration logging - first, it reads the initial settings, then it updates, then it reads again, so you should be able to confirm the final setting.
We will have a look into the issue with pairing more than 15 devices.
In the meantime Iām happy to announce that we have released a public utility to update ours (and others EZSP compatible adapters though not tested) as well as EZSP v8 firmware for our products.
Feel free to check out and leave your comments/feedback.
Thanks @Elelabs. I assume youāre using the standard Xmodem bootloader? If so, it would be great if you could release the file zipped with the metadata so that it can be booted directly in openHAB?
), and of course some documenting would really be good (and much appreciated 
).