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?
6.7.9
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.
Hi,
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.
zigbee_flowcontrol: 2
zigbee_baud: 115200
zigbee_panid: 53910
See above in one of my previous postings.
Use openhab-cli and execute zigbee netbackup
1 Like
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.
2 Likes
Actually I discovered the same with a different coordinator (Elelabs I think) and it makes somewhat sense because if your SBC has Wi-Fi enabled, too, or if it’s located next to your Wi-Fi router such as mine was by the time I had pairing problems, you’ll have strong(er) interference with that on the 2.4GHz band.
Not sure about the real extent of that effect but logical, isn’t it.
Yes it is a general recommendation too, but in this case interference symtoms are so extreme that users are reporting not being able to pair any devices at all unless get it some distance away from their SBC:
https://github.com/home-assistant/core/issues/48592
FYI, that includes reports from experienced Zigbee users who are aware of general interference issues.
ConBee/RaspBee (DeCONZ) is also known to be sensitive to component and environment interference so they therefore recommend USB extension cable but even those are not as sensitive as this is reported to be. Instead they can pair devices but are known to drop or loose connection due to RF/EMF interferance.
1 Like
I just failed to pair another sensor but apparently because of an exception ?
After that I’ve reset the sensor and that next time pairing went fine.
@chris if you don’t mind please take a look
Seems like there was some data missing which of course can happen but the binding shouldn’t throw an exception, should it.
2021-04-21 15:36:43.145 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - ASH: Frame acked and removed AshFrameData [frmNum=4, ackNum=5, reTx=false, data=04 00 01 18 00]
2021-04-21 15:36:43.146 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - --> TX ASH frame: AshFrameAck [ackNum=6, notRdy=false]
2021-04-21 15:36:43.382 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - <-- RX ASH frame: AshFrameData [frmNum=6, ackNum=5, reTx=false, data=04 90 01 80 00 42 44 56]
2021-04-21 15:36:43.388 [DEBUG] [zigbee.dongle.ember.ZigBeeDongleEzsp] - RX EZSP: EzspIncomingRouteErrorHandler [networkId=0, status=EMBER_MAC_INDIRECT_TIMEOUT, target=5644]
2021-04-21 15:36:43.390 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - --> TX ASH frame: AshFrameAck [ackNum=7, notRdy=false]
2021-04-21 15:36:43.455 [ERROR] [er.ZigBeeChannelConverterFactoryImpl] - 04CF8CDF3C78B536: Unable to create channel zigbee:device:sonoff:04cf8cdf3c78b536:04CF8CDF3C78B536_1_batteryalarm
java.lang.IllegalArgumentException: Endpoint was not found
at org.openhab.binding.zigbee.converter.ZigBeeBaseChannelConverter.initialize(ZigBeeBaseChannelConverter.java:192) ~[bundleFile:?]
at org.openhab.binding.zigbee.internal.converter.ZigBeeChannelConverterFactoryImpl.createConverter(ZigBeeChannelConverterFactoryImpl.java:118) [bundleFile:?]
at org.openhab.binding.zigbee.discovery.ZigBeeDiscoveryService$2.run(ZigBeeDiscoveryService.java:251) [bundleFile:?]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) [?:?]
at java.util.concurrent.FutureTask.run(FutureTask.java:264) [?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304) [?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [?:?]
at java.lang.Thread.run(Thread.java:834) [?:?]
2021-04-21 15:36:43.460 [DEBUG] [bee.discovery.ZigBeeDiscoveryService] - 04CF8CDF3C78B536: No channel converter found for zigbee:device:sonoff:04cf8cdf3c78b536:04CF8CDF3C78B536_1_batteryalarm
2021-04-21 15:36:43.461 [ERROR] [er.ZigBeeChannelConverterFactoryImpl] - 04CF8CDF3C78B536: Unable to create channel zigbee:device:sonoff:04cf8cdf3c78b536:04CF8CDF3C78B536_1_batteryvoltage
java.lang.IllegalArgumentException: Endpoint was not found
at org.openhab.binding.zigbee.converter.ZigBeeBaseChannelConverter.initialize(ZigBeeBaseChannelConverter.java:192) ~[bundleFile:?]
at org.openhab.binding.zigbee.internal.converter.ZigBeeChannelConverterFactoryImpl.createConverter(ZigBeeChannelConverterFactoryImpl.java:118) [bundleFile:?]
at org.openhab.binding.zigbee.discovery.ZigBeeDiscoveryService$2.run(ZigBeeDiscoveryService.java:251) [bundleFile:?]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) [?:?]
at java.util.concurrent.FutureTask.run(FutureTask.java:264) [?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304) [?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [?:?]
at java.lang.Thread.run(Thread.java:834) [?:?]
2021-04-21 15:36:43.464 [DEBUG] [bee.discovery.ZigBeeDiscoveryService] - 04CF8CDF3C78B536: No channel converter found for zigbee:device:sonoff:04cf8cdf3c78b536:04CF8CDF3C78B536_1_batteryvoltage
2021-04-21 15:36:43.466 [ERROR] [er.ZigBeeChannelConverterFactoryImpl] - 04CF8CDF3C78B536: Unable to create channel zigbee:device:sonoff:04cf8cdf3c78b536:04CF8CDF3C78B536_1_illuminance
java.lang.IllegalArgumentException: Endpoint was not found
at org.openhab.binding.zigbee.converter.ZigBeeBaseChannelConverter.initialize(ZigBeeBaseChannelConverter.java:192) ~[bundleFile:?]
at org.openhab.binding.zigbee.internal.converter.ZigBeeChannelConverterFactoryImpl.createConverter(ZigBeeChannelConverterFactoryImpl.java:118) [bundleFile:?]
at org.openhab.binding.zigbee.discovery.ZigBeeDiscoveryService$2.run(ZigBeeDiscoveryService.java:251) [bundleFile:?]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) [?:?]
at java.util.concurrent.FutureTask.run(FutureTask.java:264) [?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304) [?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [?:?]
at java.lang.Thread.run(Thread.java:834) [?:?]
2021-04-21 15:36:43.468 [DEBUG] [bee.discovery.ZigBeeDiscoveryService] - 04CF8CDF3C78B536: No channel converter found for zigbee:device:sonoff:04cf8cdf3c78b536:04CF8CDF3C78B536_1_illuminance
2021-04-21 15:36:43.469 [DEBUG] [bee.discovery.ZigBeeDiscoveryService] - 04CF8CDF3C78B536: Update ZigBee device zigbee:device with bridge zigbee:coordinator_ember:sonoff, label 'LUMI lumi.sen_ill.mgl01'
Why not? It has detected an error, so it has reported this error.
No - it was not related to that. Note also that PANID 65535 is invalid and simply means that the PANID is not configured. It’s a temporary value used in the binding during initialisation.
Do you know what the PANID is? It’s nothing at all to do with a device, or a thing - it’s the ID of the PAN - ie the Personal Area Network. So it is a 16 bit ID used in the packets to identify the network. If there is a conflict if you run multiple networks, then this will automatically be resolved by using the extended PAN ID. It will not be the cause of your issue.
Hmm my naive understanding of Java programming has been that all exceptions should be caught and produce a “proper” error message but you’re right, there is a proper reason for the exception given, and as it continues to work that’s alright, too.
I wasn’t aware that 65535 is an invalid value or that the process of network initialization failed.
So my idea was that on packet receipt, the binding took it as the index to determine the matching thing and didn’t cover the possibility that it can be there multiple times thus selected a wrong thing but as you explained you already cover that case with the extended ID.
Now since I’m not the only one to hit this, I think this (65535 is invalid) should be made clearer to users, with corresponding log messages in the first place and a proper display in Main UI.
No - as above - it is nothing to do with things. It is a network ID - not a device ID. In fact the binding doesn’t really even do anything with this - it’s handled at the network layer (so by the NCP) and not the application layer.
yes but since at some point in processing you have to map an incoming packet to a thing, I thought it might be done that way. It was pure speculation but would have explained my findings (as said I didn’t know 65535 is invalid). So how do you map with multiple controllers - use the serial port?
Also wonder about the other way round: I currently have 2 or 3 different ZigBee controllers in my box - all online - and I’ve recently reset another Aqara sensor. Scanning showed it to be found for the iTead controller.
Is it pure coincidence which coordinator the sensor will use or is there anything I can do to influence which one it finds (other than to temporarily disable the others) ?
Will the initial network join work all the time or just when I scan (like with zwave inclusion mode which is enabled by entering thing-add mode) ?
If always then what if there’s another controller around I cannot disable (like a Hue bridge or my neighbor’s bridge) ?
Simple answer - yes - if you have multiple networks, then you will have a different dongle for each network, and each network will therefore be on a different serial port. The long answer is more complex in that technically it’s possible for a controller to run multiple networks, but that’s not supported in the binding.
You should only enable discovery on one coordinator at a time. Unfortunately OpenHAB doesn’t support this, so yes, it will be luck of the draw (actually based on the network with the best signal at the location of the joining device).
I’m not sure I completely understand this… Do you mean is join enabled all the time? If so, no, that’s not possible in modern ZigBee networks - join is only enabled for a maximum of 254 seconds at a time. However the binding will disable it quicker than this (from memory it is only opened for 60 seconds).
1 Like
Today the stick with the ncp-uart-sw_679_115200 firmware still has a valid panid in the UI. A single entry in the logs.
2021-04-22 10:29:36.851 [DEBUG] [ding.zigbee.internal.ZigBeeDataStore] - 847127FFFEC9A76B: ZigBee saving network state complete.
The stick with the no flow control firmware has reverted to 65535 in the UI but like a fool I had failed to put debug on so I can’t say why other than the no flow control firmware does something differently.
1 Like
I see that as a user I cannot select the coordinator(s) to do discovery on in OH (I understand your comment such that the API doesn’t support it so you cannot do anything about it either), but just to make sure, does that mean that to first disable all coordinator things in OH except the one I want then scan is a safe (deterministic) process ? Or would I have to unplug the unwanted ones ?
yes that’s what I meant. Thanks!
@robmac Good!
These tings is starting to make some sense.
With the clarification from @chris about panid 65535 and the experiences @Hedda posted from around the homeautomation communities about firmware, flow control and shielding on the sticks we have something to work on.
I hope to find some time tonight for flashing with software flow control and testing.
No, not yet. Too many females to attend to, the fourlegged ones have started to give birth. And my dearest served old fashioned Norwegian fish soup with cob, salmon and shrimps. And some glasses wine. I am stuffed and pretty shot now. 
2 Likes