Occasional EMBER_NOT_JOINED on startup

[zsmartsystems]

Occasional EMBER_NOT_JOINED on startup

[cschwer]

@cdjackson I noticed a post in the silicon labs community about it and I'm still experiencing this. I would be happy to help debug it. Has there been any progress on it, any direction I should look first?

[cdjackson]

Yep - this issue was the bane of my life for quite a while and I discussed it both on the forum and privately with Silabs for quite a while. In the end, it stopped happening and I've not worked out how to reproduce it. However, as more people have used the Zigbee binding in openHAB, there have been 2 people with this issue that I know of so I'm keen to find it.

For reference, the post you mention is here.

Unfortunately I don't really have any pointers on where to look and at the moment I can't reproduce it (I've tried a few times recently due to the OH issues). Do you have the Silabs devkit? I would suggest to discuss on the Silabs forum, but they will probably ask for the debug info from the chip.

[cschwer]

Do you know if the people who are experiencing the problem are also using the HUSBZB-1? I'd be happy to ship you one of mine if you are looking for a device that continues to experience the problem.

I do have the dev kit so I can reach out to them for some help. But i don't think I can get debug information off of the chip on this. When you were experiencing the problem were you using the CEL mesh connect modules that came with the dev kit or some other radio?

[cdjackson]

One is a HUSBZB, and one is using a CEL EM3588 USB stick. When I had the issue I was using the CEL USB stick rather than the ones that come with the devkit - I think it’s basically the same, but more convenient for development. I could try reflashing one of the dev boards to see if it does it. If you have the devkit maybe you can try this as well. It’s strange - when I had the issue, it was about 50/50 if it would start up ok or not. Then it stopped playing up and worked 100%. I’m not using the ember much right at the moment as I need to get the Telegesis stick working, but the EM35x is still my preferred option and would like to solve this issue.

[cschwer]

So I ended up rewriting ZigBeeDongleEzsp.initialize() to not use the stackConfiguration hashmap or stackPolicies hash map and instead just call setConfiguration or setPolicy for each setting, one after the other. In addition I tweaked the order and parameters some. Since that change I have not seen this error again.

This is what I do for the configuration:
// Perform any stack configuration
this.setConfiguration(EzspConfigId.EZSP_CONFIG_STACK_PROFILE, 2);
this.setConfiguration(EzspConfigId.EZSP_CONFIG_SECURITY_LEVEL, 5);
this.setConfiguration(EzspConfigId.EZSP_CONFIG_SUPPORTED_NETWORKS, 1);
this.setConfiguration(EzspConfigId.EZSP_CONFIG_APPLICATION_ZDO_FLAGS, 0x04);
this.setConfiguration(EzspConfigId.EZSP_CONFIG_TRUST_CENTER_ADDRESS_CACHE_SIZE, 2);
this.setConfiguration(EzspConfigId.EZSP_CONFIG_KEY_TABLE_SIZE, 1);
this.setConfiguration(EzspConfigId.EZSP_CONFIG_MAX_END_DEVICE_CHILDREN, 20);
this.setConfiguration(EzspConfigId.EZSP_CONFIG_TX_POWER_MODE, 1);
this.setConfiguration(EzspConfigId.EZSP_CONFIG_END_DEVICE_POLL_TIMEOUT, 113)

And this for the Policy:
setPolicy(EzspPolicyId.EZSP_TC_KEY_REQUEST_POLICY, EzspDecisionId.EZSP_DENY_TC_KEY_REQUESTS);
setPolicy(EzspPolicyId.EZSP_APP_KEY_REQUEST_POLICY, EzspDecisionId.EZSP_ALLOW_APP_KEY_REQUESTS);
setPolicy(EzspPolicyId.EZSP_TRUST_CENTER_POLICY, EzspDecisionId.EZSP_ALLOW_PRECONFIGURED_KEY_JOINS);

[cdjackson]

Thanks for the comment...

not use the stackConfiguration hashmap or stackPolicies hash map

I don't see how this can make any difference. This should be 100% exactly the same as calling the methods individually. What does the log show at EZSP/ASH level - I would guess it's 100% identical unless it somehow changes the timing.

I tweaked the order

I've also tried in the past to mess around with the order as I've felt it makes a difference.

I think it would be good if you can isolate the actual cause - possibly by reversing these changes until it stops working again? Without understanding the problem, there's no way to know if this is fixed...

[cdjackson]

The issue with changing to the individual commands rather than using the map is that the order of the commands can change. I came across the issue with the stack profile changing, and noticed that it always failed if this setting was set last, rather than in the order it is set into the map. I've now changed this to use a TreeMap so that order is fixed, and this seems to have stopped such problems.

I beleive from my discussions with Silabs over the stack order problem a couple of years back that order shouldn't mater, but that doesn't seem to be correct.......

I hope that this change will also fix this issue.

[cschwer]

👍