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
Since I had to stay awake for an hour or two;
Flashed one of the Itead USB stick with ncp-uart-sw_679_115200.gbl from zigbeeFirmware/firmware/Zigbee3.0_Dongle at master · xsp1989/zigbeeFirmware · GitHub
- Made a new test zigbee network on a Bitronvideo stick with one Ikea bulb.
- Copied aside coordinatorID, ch, panid, extended panid and networkkey
- used openhab-cli, executed zigbee backup
- Deleted the coordinator thing
- Removed the Bitronvideo stick
- waited some seconds
- Inserted the Itead stick
- added a new coordinator and pasted in the parameters copied out above (activated “Reset controller” too)
- used openhab-cli, executed zigbee backup “the string from the previous backup in quotes”
- restarted openhab
And Openhab came up with a working zigbee network on the Itead stick
3 Likes
It looks like that firmware is happier with openHAB.
As the stick has no option for HW flow do you think there will ever be an issue with the SW flow under conditions a network supports?
Software flow control provides some control over the flow of message strings.
If this flow was flawless we could use “no flow control”.
I might dig out my oscilloscope to see if I can see something.
Only long term use will reveal the stability.
It is a cheap design, so I do not expect too much.
1 Like
Hmmm - not really.
Flow control is there to prevent overflow of data being sent from one end or the other overflowing receive buffers on the other end. This can happen if (for example) your PC running OH gets busy for some time, then it may be that the NCP is sending data that overflows the buffers in the receiving chip if the computer doesn’t service it quick enough.
This will happen occasionally in pretty much all systems - hence flow control is highly desirable to prevent corrupted data which the system would then need to try and recover from. If it can’t recover, then the binding would need to reset the NCP and start the network up again.
1 Like
Yes, thank you for the clarification
My English is not so good, so my messages tend to be a bit short.
Also, with a oscilloscope one can only see the electrical side of it.
The panid in the UI of the stick with p-uart-sw_679_115200 firmware has changed to 65535.
The network is still functioning.
There are no debug lines mentioning Configuration update since adding the device and all of the lines appear to be status refresh from the network.
Is this an issue with the stick or a glitch that happens with all sticks?