ITead Zigbee 3.0 USB dongle/stick/adapter based on Silicon Labs EFR32MG21

So I had a look at this log, and it seems fine. The binding comes up and the network is ONLINE. There is no initialisation - the system uses the existing network.

I am about to make a small change to where the network configuration is updated as I think at the moment there is the potential for it to be updated just before the network comes ONLINE, and that may be the cause of the PANID of FFFF. Otherwise I don’t really see anything wrong here.


Hm, there is a “reset” option. This is what I have used as “initialization”.

I think we’re talking at crossed purposes… I wasn’t referring to the configuration in the UI - I was simply referring to the log. This shows that the binding did not perform an initialisation of the dongle - it used the existing network.

I thought that this is what you waned to do - ie to use an existing network. If not, then yes, you need to reset the stick.

I don’t understand why the backup and restore is now not working?

As I’ve said earlier, I think this is extremely unlikely that there is really a PANID change.

I think this is simply a race condition - the binding is probably not setting this in quite the right place as it’s reading it just before the network comes online. I will create a PR to change this,.

1 Like

It should not work when panid is FFFF as valid panid is 1-FFFE.
I will test this when the race condition is fixed ( see below)

I hope the first log I posted was of any help ( in message #97 )
It looks to me as the race condition is happening there.

Thank you, I will test as soon a build is availible :slight_smile:

Is the PAN ID returning 0xFFFF? I didn’t think it was and I think this is quite unlikely to be the case.

The race condition has nothing to do with the backup function - if the backup is now broken (!!!) then it will not be fixed, but I don’t see why the backup will be broken?

It’s impossible to see this in the logs. The race is simply something I have found by analyses.

1 Like

This should already be available as far as I know.

1 Like

Yes, zigbee netbackup reports FFFF when the UI shows FFFF (in dec)
I will test when I get back from work. Is the build availible in a snapshot, or must I download the binding from somewhere else?

That’s strange, and this will not be fixed then in the recent change. Please provide the output with debug to show the issue.

edit: to clarify - console commands are not linked in any way to the binding - they are part of the low level zigbee libraries, so will not be impacted by any changes in the binding.

1 Like

I guess the build is available where-ever you normally get the builds from. I’m not 100% sure but I checked on CI and it was built a couple of hours ago.


So, I installed 3.1.0~S2350-1 over apt with sources.lst pointing to “unstable”.
I let it run for about 5 hours and restarted now.
But panid changed to 65535 after the restart.

openhab.log (606.6 KB)

openhab> zigbee netbackup                                                                                                                                    

openhab> zigbee ncpstate
Local Node Type     : EMBER_COORDINATOR
IEEE Address        : 847127FFFEC9A4E1
NWK Address         : 0000
Network PAN Id      : 0403
Network EPAN Id     : 1111000011110000
Radio Channel       : 16
Network Manager Id  : 0000
Radio TX Power      : -1
Board Name          : 
Manufacturer Name   : 
Stack Version       :
Custom Version      : 

I am not sure if I got the latest changes in snapshot 2350…

I would suggest not to worry too much about this for now. It is not impacting the operation of the binding and it will get fixed when all the updates I’ve made in the past few weeks slowly filter into the binding over the next week or two.

I noticed I seem to get the below error always when panid = 65535

Maybe you can make it spit a more useful message ?

2021-04-28 10:22:18.280 [DEBUG] [systems.zigbee.dongle.ember.EmberNcp] - EzspSetConfigurationValueRequest [networkId=0, configId=EZSP_CONFIG_FRAGMENT_DELAY_MS, value=50]
2021-04-28 10:22:18.280 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - TX EZSP: EzspSetConfigurationValueRequest [networkId=0, configId=EZSP_CONFIG_FRAGMENT_DELAY_MS, value=50]
2021-04-28 10:22:18.281 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - ASH: TX EZSP queue size: 1
2021-04-28 10:22:18.283 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - --> TX ASH frame: AshFrameData [frmNum=5, ackNum=5, reTx=false, data=DD 00 01 53 00 1D 32 00]
2021-04-28 10:22:18.297 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - <-- RX ASH frame: AshFrameData [frmNum=5, ackNum=6, reTx=false, data=DD 80 01 53 00 00]
2021-04-28 10:22:18.297 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - ASH: Frame acked and removed AshFrameData [frmNum=5, ackNum=5, reTx=false, data=DD 00 01 53 00 1D 32 00]
2021-04-28 10:22:18.299 [DEBUG] [zigbee.dongle.ember.ZigBeeDongleEzsp] - RX EZSP: EzspSetConfigurationValueResponse [networkId=0, status=EZSP_SUCCESS]
2021-04-28 10:22:18.299 [DEBUG] [systems.zigbee.dongle.ember.EmberNcp] - EzspSetConfigurationValueResponse [networkId=0, status=EZSP_SUCCESS]
2021-04-28 10:22:18.300 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - --> TX ASH frame: AshFrameAck [ackNum=6, notRdy=false]
2021-04-28 10:22:18.300 [DEBUG] [systems.zigbee.dongle.ember.EmberNcp] - EzspSetConfigurationValueRequest [networkId=0, configId=EZSP_CONFIG_PACKET_BUFFER_COUNT, value=255]
2021-04-28 10:22:18.301 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - TX EZSP: EzspSetConfigurationValueRequest [networkId=0, configId=EZSP_CONFIG_PACKET_BUFFER_COUNT, value=255]
2021-04-28 10:22:18.302 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - ASH: TX EZSP queue size: 1
2021-04-28 10:22:18.303 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - --> TX ASH frame: AshFrameData [frmNum=6, ackNum=6, reTx=false, data=DE 00 01 53 00 01 FF 00]
2021-04-28 10:22:18.322 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - <-- RX ASH frame: AshFrameData [frmNum=6, ackNum=7, reTx=false, data=DE 80 01 00 00 00]
2021-04-28 10:22:18.324 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - ASH: Frame acked and removed AshFrameData [frmNum=6, ackNum=6, reTx=false, data=DE 00 01 53 00 01 FF 00]
2021-04-28 10:22:18.325 [DEBUG] [s.zigbee.dongle.ember.ezsp.EzspFrame] - Error creating instance of EzspFrame
java.lang.reflect.InvocationTargetException: null
        at jdk.internal.reflect.GeneratedConstructorAccessor293.newInstance(Unknown Source) ~[?:?]
        at jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance( ~[?:?]
        at java.lang.reflect.Constructor.newInstance( ~[?:?]
        at com.zsmartsystems.zigbee.dongle.ember.ezsp.EzspFrame.createHandler( [bundleFile:?]
        at com.zsmartsystems.zigbee.dongle.ember.internal.ash.AshFrameHandler$ [bundleFile:?]
Caused by: java.lang.ArrayIndexOutOfBoundsException: Index 6 out of bounds for length 6
        at com.zsmartsystems.zigbee.dongle.ember.internal.serializer.EzspDeserializer.deserializeUInt8( ~[?:?]
        at com.zsmartsystems.zigbee.dongle.ember.ezsp.command.EzspVersionResponse.<init>( ~[?:?]
        ... 5 more
2021-04-28 10:22:18.332 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - ASH: No frame handler created for AshFrameData [frmNum=6, ackNum=7, reTx=false, data=DE 80 01 00 00 00]
2021-04-28 10:22:18.333 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - --> TX ASH frame: AshFrameAck [ackNum=7, notRdy=false]

On a sidenote - writing here as you said Karaf uses the libs directly i.e. to open an issue on the binding wouldn’t be right - it’s setBridgeUid not setBridgeId, and requires exact camelCase, please make it also work with all-lowercase. And please also give a hint how to retrieve this BridgeUid (it’s the OH thing name but that’s not obvious).

openhab> openhab:zigbee ncpstate
Error: Multiple ZigBee bridges found; please select one using the setBridgeId command
openhab> openhab:zigbee setBridgeId zigbee:coordinator_ember:sonoff
Error: Multiple ZigBee bridges found; please select one using the setBridgeId command
openhab> openhab:things list| grep Coordinator
zigbee:coordinator_ember:elelabselr023 (Type=Bridge, Status=UNINITIALIZED (DISABLED), Label=EleLabs Coordinator Ember chipset, Bridge=null)
zigbee:coordinator_ember:sonoff (Type=Bridge, Status=UNKNOWN, Label=SOnOff Coordinator Ember chipset, Bridge=null)
openhab> openhab:zigbee setBridgeUid zigbee:coordinator_ember:sonoff
Set bridge UID to zigbee:coordinator_ember:sonoff

This isn’t relevant - it’s just a presentation issue so you can ignore this. The PAN ID is not 65535.

I had a look at this error that you posted a few days ago, but it was different to this and there was no obvious reason for the error. It’s definately not related to any PAN ID issue.

You can find this in the UI - it’s just the UID - nothing special.

Well, I’ve just issued ‘Reset’ on the coordinator thing after some trouble with pairing but forgot to check the PAN ID before. Now the coordinator fails to initialize, and I see

openhab> openhab:zigbee ncpstate
Ember NCP state     : EMBER_NO_NETWORK
Local Node Type     : EMBER_COORDINATOR
IEEE Address        : 847127FFFEC9A74E
NWK Address         : FFFE
Network PAN Id      : FFFF
Network EPAN Id     : C7C31E35CD9E6DB2

so it has become the PAN ID now :frowning:
Right now browsing jsondb backups for the old ID else I’ll lose my little network…

No, that’s incorrect. You are getting hung up on this and it’s not the cause. Something has caused the network not to start and then of course the PAN ID will be FFFF. If you’re going to report an error, then please provide a logfile.

You have reinitialised the network - so you have already lost the network. When you reset the network, you will need to join all devices again.

To be clear, I’ve clicked ‘Reset’ on the controller thing under ‘Advanced’, then ‘Save’.
Some days ago you told me this is safe to do as the binding does it every time it starts, too, and now you say it is not ? Confused.
There’s nothing else I remember I have done what could have caused the network to fail.

I doubt that I said you should use this command to reset the controller. This command will reinitialise the controller completely. The binding performs a reset/restart on the controller each time it starts - but it doesn’t use this command and I don’t think I told you to use this (I hope not anyway :wink: ).

Again - please provide the log. It is absolutely not related to the PANID - you seem to be fixated on the PAN ID for some reason, but this is not the issue.

I updated to build 2350 yesterday with no issues and zigbee and zwave networks on the Pi4 are both running fine.

I am still using SW flow control and the zigbee network is behaving though the RF range is limited. I am getting about 50% less range than the zwave stick installed in the same machine for direct communication. I do have an AP in the same room so there could be interference for ZigBee which would not impact zwave.

I am not seeing any errors or warnings in the logs.

What I have observed that might be related to the observations on panid is that the reported figures for the controller thing properties are empty or []. I will keep putting snapshots on and see if this is resolved with the fixes Chris has made as I am sure there are neighbours. Like panid the standard operation is not impacted.

zigbee_lastupdate   empty
zigbee_neighbors   []
zigbee_routes    []
zigbee_devices   []

I have just restarted because I was moving things around on my desk and now some values are showing.

zigbee_lastupdate   empty
zigbee_neighbors [{"joining":"UNKNOWN","address":"40318","depth":"15","lqi":"255","macaddress":"60A423FFFE02...
zigbee_routes    [{"next_hop":"0","destination":"0","state":"INACTIVE"}]
zigbee_devices   []