as supplied firmware and it comes online. As I said I have no idea if I can include any devices but possibly it needs that setting to be able to initialise the controller.
Possibly bad firmware behaviour but you can see hardware flow control works but only if you change that security setting. Possibly needs some form of network and the network is null out of the box?
Possibly after this first run or adding first device it might be possible to go back to default security settings.
For me it didnāt. Trying various parameter combos but whenever I hit āsaveā it takes a couple of packets then the exception is raised again then some more packets then the controller thing drops OFFLINE.
Also tried various firmwares meanwhile. @chris any idea on that exception ?
On a sidenote: what if I did get two controllers to both become online - which one would a device join ?
is there any means to control that ?
Thanks for confirming this was fluke not solution. I know these are not full production models so possible it is early niggle.
Have all of the properties configured yet or is it failing when it is reading them? Mine was passing a few packets then a timeout and none of the properties were set. The only other thing I did other than change that property was a hard restart but again seems unlikely to be the solution.
I have another one that I can try in another openHabian install and see if it behaves the same or differently.
Are the values for panid and networkkey the same you set at initialisation?
I get 65535 for panid no mather what I set it to, or that is when restoring the backup string from my Bitronvideo stick.
And networkkey changes sometimes I have not identified yet.
Edit: However the backup string seems to contain the right key.
Not sure about the extended panid, it my be a suspect to keep an eye on too.
I have tried many times, I did manage to restore the backup from my Bitron stick onto one of the Itead sticks once.
But I could not replicate this.
I did not keep track on witch of my two Itead sticks it did go wellā¦
Hmm.
I kept getting that exception (see above) throughout two sticks, different OH and firmware versions and various settings.
When I changed that panid and reset the controller it started working. Panid with my stick was 65535 before, too.
On the stick yes if from factory (and probably after flashing, didnāt try).
But PAN ID is stored in OH thing which then writes(?) it to the stick so unless you delete & recreate the thing itās persistent.
Apparently 65535 is chosen for some reason I donāt know but is probably not a valid value.
EDIT: I had another thing for another controller albeit disabled that also had the PAN ID 65535 set.
Possibly that same ID 2 times was causing the exception ?
Thanks for the insights. I hope I have now got a working stick to test with but I must do some research about how panid is generated.
I have just intentionally created another thing also pointing at the same port knowing it would fail and ended up with panid 65535 so that value is possibly assigned on a failed initialisation.
Delete other thing and set panid to 0 and external to 0000000000000000 which shows auto and the device looks better again when it comes back online.
I did the same to the one time I managed to get backup/restore to work.
Do you have firmware with software flow control on one of the sticks?
I was thinking to try that.
The values seen in UI (these can be seen in /var/lib/openhab/jsondb/org.openhab.core.thing.Thing.json too)
and the output from:
openhab> zigbee netbackup
Should contain the same values.
(To get a better view of what is what try to restore the backup string. remember toput the string in quotes).
Sometimes they do not match, but the mesh will work anyway, because it is the values in the stick that is used.
I need to have a look. I saw a recent statement that said Silabs were going to change some packet formats, and this would break things as it wasnāt backward compatible. IT might be related to that - what version of firmware is this?
As the exception seems to have gone away when I changed PAN IDs on some controller things Iām inclined to believe thatās related to PANID 65535 or maybe that there were 2 things with the same PAN ID.
Today my controller has panid 65535 according to the UI with no actions from me and as it has no devices so I donāt suppose a lot of interaction with the binding. I will set debug on to track what is happening.
What is the easiest way to check NVM on the stick to see if the value on the stick has changed?
I have now flashed one of the controllers with ncp-uart-sw_679_115200.gbl and the device has panid 53910 in the UI. Will monitor both sticks.
Note! Developers and users who tested this as a Zigbee coordinator now believe that device paring issues with this Zigbee 3.0 dongle from ITead seem to be due to extreme sensitivity to component and environmental noise in the form of electromagnetic interferences as they discovered that device pairing works much better if use a long USB extension cable and get it as far away from other electronic appliances as possible (including the computer that you run your home automation application software on as well as any devices such as example external harddrives or storage devices, and power-supplies, etc.).
Their troubleshooting has revealed that CCA fail count gets much lower with a USB extension cord.
It is true that using a USB extension cable and trying to keep it away from other possible sources that can interfere with receiving signals is the general recommendation for all RF radio dongles for home automation control, but in this specific case, the interference symptoms are so extreme that users are reporting not being able to pair any devices at all unless getting it some distance away from their computer plus devices/appliances like external harddrives (and of course any WiFi access points, etc.).
Note! As you can see from the pictures the radio chip and the crystal does circuit does not have a EMF shielding (metal plate cover) which means that this board will be very sensitive with its current hardware design will have very high receive sensitivity to electromagnetic interference (EMI) / radio-frequency interference (RMI). This means that it will be extra important to keep it away from any other electronic devices or appliances that may generate an electromagnetic field (EM Field) or send our interfering radio signals. That includes the computer that you run your home automation application software on as well as any devices such as for example external harddrives or storage devices, power-supplies, etc., and of course any Wi-Fi access points or routers nearby. It also means that the dongle in its current hardware revision is unlikley to ever pass FCC certification. If adding electromagnetic shielding to your other devices/appliances is not possible then one workaround is to use the dongle with a long USB extension cable to get it away as far as possible from any sources of electromagnetic interferances.
PS! As you can see from the pictures the radio chip and the crystal does circuit does not have a EMF shielding (metal plate cover) which means that this board will be very sensitive with its current hardware design will have very high receive sensitivity to electromagnetic interference (EMI) / radio-frequency interference. This means that it will be extra important to keep it away from any other electronic devices or appliances that may generate an electromagnetic field (EM Field) or send our interfering radio signals. It also means that the dongle in its current hardware revision is unliley to pass FCC certification.
