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

Oh then we misunderstand. If that’s easier with a custom handler, of course do it like that .
All I want is to get those cheapish sensors to work.

They do work don’t they? What is the problem - it’s hard to fix a problem that isn’t reported.

Oh I thought you were aware as you yourself said those (Aqara sensors) violate the standards.

Well my current problem is they work for some time then drop offline. Problems are 1) it seems to at least vary with different coordinators and 2) so far I couldn’t reproduce this with debug logging on to really show what’s going wrong. I’m missing messages at times (e.g. sometimes when I click the sensor button) so I’m unsure if there’s more to it such as a HW or radio problem. Will try again.

Might not be your problem but suggest read all these Aqara and Xiaomi tips by the Hubitat community:

1 Like

I had that problem, this solved it for me: zigbee_childtimeout=1209600
LUMI lumi.sensor_magnet.aq2, LUMI lumi.sensor_wleak.aq1, LUMI lumi.weather

But I can’t change this. As I understand, they violate the standards at the network layer mainly - and this is something that the binding cannot resolve.

Standards violations at application layer can already be accounted for in the binding, but that’s not the main issue here.

FYI, firmware released with it has AT LEAST one serious bug so require a firmware upgrade before use.

https://github.com/xsp1989/zigbeeFirmware/tree/master/firmware/Zigbee3.0_Dongle

Firmware can be updated via Elelabs EZSP Firmware Update Utility after stop any software that use it.

https://github.com/Elelabs/elelabs-zigbee-ezsp-utility/

Example command:

#python3 Elelabs_EzspFwUtility.py flash -f data/ncp-uart-sw_679_115200.gbl -p /dev/ttyUSB0
#python3 Elelabs_EzspFwUtility.py probe -p /dev/ttyUSB0

Alternatively can update firmware using Docker image → https://github.com/walthowd/husbzb-firmware

Note! FW or HW still has more bugs as per info in https://github.com/home-assistant/core/issues/48592

PS: Maybe unrelated to problems experienced so far but FYI; CH340E (WCH CH340 E) USB to Serial chip the dongle uses is apparently infamously known to have driver issues in both Linux and Mac OS.

1 Like

Careful with general statements like this. Most people complaining have not really analysed their problem end-to-end so it’s unclear where their trouble is and what kernel/… versions and parameters these relate to (well, or not relate to).
In principle, the chipset works in openHABian, using the ch341 driver.
The Elelabs USB adapter, too, uses this chipset.

I’ve successfully loaded the 6.7.9 firmware but while it worked with the unflashed stick,
the controller now already fails to get online, stuck in a loop attempting, the only error shown see below.

I’m still unsure about RF interference as the box is located right next to my 2.4GHz WiFi router.

@hedda could you pls confirm which parameters I would need to use ?
115200 baud
No (?) Flow Control
High Transmit Power (relevant ?)
Power Mode Boost (relevant ?)
High RAM (relevant ?)

2021-04-16 13:21:03.898 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - --> TX ASH frame: AshFrameAck [ackNum=5, notRdy=false]
2021-04-16 13:21:03.898 [DEBUG] [systems.zigbee.dongle.ember.EmberNcp] - EzspSetConfigurationValueRequest [networkId=0, configId=EZSP_CONFIG_FRAGMENT_DELAY_MS, value=50]
2021-04-16 13:21:03.899 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - TX EZSP: EzspSetConfigurationValueRequest [networkId=0, configId=EZSP_CONFIG_FRAGMENT_DELAY_MS, value=50]
2021-04-16 13:21:03.899 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - ASH: TX EZSP queue size: 1
2021-04-16 13:21:03.900 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - --> TX ASH frame: AshFrameData [frmNum=5, ackNum=5, reTx=false, data=4C 00 01 53 00 1D 32 00]
2021-04-16 13:21:03.916 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - <-- RX ASH frame: AshFrameData [frmNum=5, ackNum=6, reTx=false, data=4C 80 01 53 00 00]
2021-04-16 13:21:03.917 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - ASH: Frame acked and removed AshFrameData [frmNum=5, ackNum=5, reTx=false, data=4C 00 01 53 00 1D 32 00]
2021-04-16 13:21:03.918 [DEBUG] [zigbee.dongle.ember.ZigBeeDongleEzsp] - RX EZSP: EzspSetConfigurationValueResponse [networkId=0, status=EZSP_SUCCESS]
2021-04-16 13:21:03.918 [DEBUG] [systems.zigbee.dongle.ember.EmberNcp] - EzspSetConfigurationValueResponse [networkId=0, status=EZSP_SUCCESS]
2021-04-16 13:21:03.918 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - --> TX ASH frame: AshFrameAck [ackNum=6, notRdy=false]
2021-04-16 13:21:03.918 [DEBUG] [systems.zigbee.dongle.ember.EmberNcp] - EzspSetConfigurationValueRequest [networkId=0, configId=EZSP_CONFIG_PACKET_BUFFER_COUNT, value=255]
2021-04-16 13:21:03.919 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - TX EZSP: EzspSetConfigurationValueRequest [networkId=0, configId=EZSP_CONFIG_PACKET_BUFFER_COUNT, value=255]
2021-04-16 13:21:03.920 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - ASH: TX EZSP queue size: 1
2021-04-16 13:21:03.920 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - --> TX ASH frame: AshFrameData [frmNum=6, ackNum=6, reTx=false, data=4D 00 01 53 00 01 FF 00]
2021-04-16 13:21:03.939 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - <-- RX ASH frame: AshFrameData [frmNum=6, ackNum=7, reTx=false, data=4D 80 01 00 00 00]
2021-04-16 13:21:03.940 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - ASH: Frame acked and removed AshFrameData [frmNum=6, ackNum=6, reTx=false, data=4D 00 01 53 00 01 FF 00]
2021-04-16 13:21:03.940 [DEBUG] [s.zigbee.dongle.ember.ezsp.EzspFrame] - Error creating instance of EzspFrame
java.lang.reflect.InvocationTargetException: null
        at jdk.internal.reflect.GeneratedConstructorAccessor237.newInstance(Unknown Source) ~[?:?]
        at jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) ~[?:?]
        at java.lang.reflect.Constructor.newInstance(Constructor.java:490) ~[?:?]
        at com.zsmartsystems.zigbee.dongle.ember.ezsp.EzspFrame.createHandler(EzspFrame.java:475) [bundleFile:?]
        at com.zsmartsystems.zigbee.dongle.ember.internal.ash.AshFrameHandler$1.run(AshFrameHandler.java:219) [bundleFile:?]
Caused by: java.lang.ArrayIndexOutOfBoundsException: Index 6 out of bounds for length 6
        at com.zsmartsystems.zigbee.dongle.ember.internal.serializer.EzspDeserializer.deserializeUInt8(EzspDeserializer.java:85) ~[?:?]
        at com.zsmartsystems.zigbee.dongle.ember.ezsp.command.EzspVersionResponse.<init>(EzspVersionResponse.java:58) ~[?:?]
        ... 5 more
2021-04-16 13:21:03.946 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - ASH: No frame handler created for AshFrameData [frmNum=6, ackNum=7, reTx=false, data=4D 80 01 00 00 00]
2021-04-16 13:21:03.947 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - --> TX ASH frame: AshFrameAck [ackNum=7, notRdy=false]

Depends on which firmware image file that you choose to flash, (as xsp1989 has “sw” and “nsw”), see:

https://github.com/xsp1989/zigbeeFirmware/tree/master/firmware/Zigbee3.0_Dongle#abbreviations-legend

ZHA devs recommend to use the image configured with Software Flow Control (so “sw”, not “nsw” FW).

Sounds as if High Transmit Power / Power Mode Boost might be relative if Itead did not tune antenna capacitors correctly in hardware design so could get more signal noise if use higher TX power output.

More info in

and

Not sure about that “High RAM” parameter but the MCU chip it uses certainly have loads of RAM.

This is kind of strange - there can only be one correct way to configure the system since the firmware is either compiled for hardware or software flow control, and the application side should be configured the same.

Again - this completely depends on the firmware. Whoever wrote the firmware should know the answer.

ITead provides different firmware images for “sw” = software flow control and “nsw” = no flow control:

https://github.com/xsp1989/zigbeeFirmware/tree/master/firmware/Zigbee3.0_Dongle

  • ncp-uart-sw_679_115200.gbl = v6.7.9 (EZSP v8), software flow control, 115200 baud rate
  • ncp-uart-nsw_679_115200.gbl = v6.7.9 (EZSP v8), no flow control, 115200 baud rate
  • ncp-uart-sw_678_115200.gbl = v6.7.8 (EZSP v8), software flow control, 115200 baud rate
  • ncp-uart-nsw_678_115200.gbl = v6.7.8 (EZSP v8), no flow control, 115200 baud rate
  • ncp-uart-sw_655_115200.gbl = v6.5.5 (EZSP v7), software flow control, 115200 baud rate

Home Assistant’s ZHA integration (based on bellows and zigpy) works with their “sw” firmware image, but the ZHA installation configuration flow for applikation allow you to set flow control method setting.

PS: They have not yet provided any firmware images preconfigure for “hw” (hardware flow control).

Strange - this is not what Silabs provide. There is either SW, or HW - I’d be surprised if they’ve modified the flow control (I’m not sure if this is possible as some of these libraries are precompiled by Silabs).

Personally I would recommend the hardware flow control - it’s what we normally use for most or all of our commercial systems.

I could not find the reasoning behind this.
My guess is the existing ZHA software stack…

I am thinking the meaning is Chinese for “HW flow control not working (properly)”
:smiley:

1 Like

EDIT: Apparently the engineer of this ITead stick missed connecting RTS and CTS to the CH340E chip:

https://github.com/xsp1989/zigbeeFirmware/issues/15

Support for hardware flow control was just now added to zigpy / bellows about a month ago:

https://github.com/zigpy/bellows/pull/403

See related discussion in:

https://github.com/zigpy/bellows/pull/391

Right now, it does not work at all to access the stick
I even flash-downgraded, tried with and without Flow Control, rebooted, etc … nothing works.
I don’t understand why because the tool recognizes the stick:

2021/04/19 17:19:17 Elelabs_EzspFwUtility:   Generic EZSP adapter detected:
2021/04/19 17:19:17 Elelabs_EzspFwUtility:   Firmware: 6.7.8-117
2021/04/19 17:19:17 Elelabs_EzspFwUtility:   EZSP v8
[17:19:17] root@devpi:/home/openhabian/elelabs-zigbee-ezsp-utility#

But OH keeps saying:


2021-04-19 17:20:17.708 [INFO ] [bee.handler.ZigBeeCoordinatorHandler] - ZigBee dongle inactivity timer. Reinitializing ZigBee
2021-04-19 17:20:18.723 [ERROR] [nding.zigbee.serial.ZigBeeSerialPort] - Serial Error: Port /dev/ttyUSB0 does not exist.
2021-04-19 17:20:18.725 [ERROR] [zigbee.dongle.ember.ZigBeeDongleEzsp] - EZSP Dongle: Unable to open serial port
2021-04-19 17:20:23.731 [INFO ] [bee.handler.ZigBeeCoordinatorHandler] - ZigBee dongle inactivity timer. Reinitializing ZigBee

EDIT: checking serial bundle seems to be fine

openhab> bundle:list|grep -i seri
226 x Active x  80 x 5.2.1                 x nrjavaserial
248 x Active x  80 x 3.1.0.202104111549    x openHAB Add-ons :: Bundles :: ZigBee Serial Driver
252 x Active x  80 x 3.1.0.202104180908    x openHAB Core :: Bundles :: Configuration USB-Serial Discovery
253 x Active x  80 x 3.1.0.202104180909    x openHAB Core :: Bundles :: Configuration USB-Serial Discovery for Linux using sys
254 x Active x  80 x 3.1.0.202104180906    x openHAB Core :: Bundles :: Configuration Serial
256 x Active x  80 x 3.1.0.202104180904    x openHAB Core :: Bundles :: Serial Transport
257 x Active x  80 x 3.1.0.202104180905    x openHAB Core :: Bundles :: Serial Transport for RXTX
258 x Active x  80 x 3.1.0.202104180905    x openHAB Core :: Bundles :: Serial Transport for RFC2217

But that has no bearing on the stick itself :confused:

Since it can’t open the serial port, this is a basic issue with serial port configuration, access, or something like that.

I had an issue at first try. I moved forward by changing the security setting but have not fully understood the implications yet as testing has not gone further. Device shows online with this set but have no idea if you can make it it control devices.

Well that setting is about device security not the coordinator itself. I, too, had set that already, but it’s unrelated to my coordinator not coming ONLINE.
Just found a silly mistake I made myself:
I had another thing configured to use the same controller. So that one seems to have “taken” the serial port internal to OH. Removed that and complaints on serial ceased. It’s still failing to come ONLINE though, probably because of the exception (see below). This happens when I reset the coordinator thing:

2021-04-20 15:09:14.600 [DEBUG] [bee.handler.ZigBeeCoordinatorHandler] - Initializing ZigBee network [zigbee:coordinator_ember:sonoff].
2021-04-20 15:09:14.601 [DEBUG] [bee.handler.ZigBeeCoordinatorHandler] - Channel 0
2021-04-20 15:09:14.602 [DEBUG] [bee.handler.ZigBeeCoordinatorHandler] - PANID 65535
2021-04-20 15:09:14.603 [DEBUG] [bee.handler.ZigBeeCoordinatorHandler] - EPANID 5FA27AE284189C81
2021-04-20 15:09:14.603 [DEBUG] [bee.handler.ZigBeeCoordinatorHandler] - Network Key A693DE70C945122BABEC0EEF33D645DF
2021-04-20 15:09:14.604 [DEBUG] [bee.handler.ZigBeeCoordinatorHandler] - Link Key 5A6967426565416C6C69616E63653039
2021-04-20 15:09:14.605 [DEBUG] [bee.handler.ZigBeeCoordinatorHandler] - Config: zigbee_initialise found, initializeNetwork=true
2021-04-20 15:09:14.605 [DEBUG] [bee.handler.ZigBeeCoordinatorHandler] - Network Key String A693DE70C945122BABEC0EEF33D645DF
2021-04-20 15:09:14.606 [DEBUG] [bee.handler.ZigBeeCoordinatorHandler] - Network key final array A693DE70C945122BABEC0EEF33D645DF
2021-04-20 15:09:14.607 [DEBUG] [bee.handler.ZigBeeCoordinatorHandler] - Link Key String 5A6967426565416C6C69616E63653039
2021-04-20 15:09:14.608 [DEBUG] [bee.handler.ZigBeeCoordinatorHandler] - Initialising network
2021-04-20 15:09:14.609 [DEBUG] [bee.handler.ZigBeeCoordinatorHandler] - Channel set to 11.

[...]


2021-04-20 15:09:15.694 [DEBUG] [nding.zigbee.serial.ZigBeeSerialPort] - Connecting to serial port [/dev/ttyUSB1] at 115200 baud, flow control FLOWCONTROL_OUT_XONOFF.
2021-04-20 15:09:15.730 [DEBUG] [nding.zigbee.serial.ZigBeeSerialPort] - Serial port [/dev/ttyUSB1] is initialized.

[...]
(lots of EzspGetConfigurationValueRequest and EzspGetConfigurationValueResponse)

2021-04-20 15:09:19.097 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - ASH: TX EZSP queue size: 1
2021-04-20 15:09:19.099 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - --> TX ASH frame: AshFrameData [frmNum=5, ackNum=5, reTx=false, data=AC 00 01 53 00 1D 32 00]
2021-04-20 15:09:19.113 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - <-- RX ASH frame: AshFrameData [frmNum=5, ackNum=6, reTx=false, data=AC 80 01 53 00 00]
2021-04-20 15:09:19.114 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - ASH: Frame acked and removed AshFrameData [frmNum=5, ackNum=5, reTx=false, data=AC 00 01 53 00 1D 32 00]
2021-04-20 15:09:19.115 [DEBUG] [zigbee.dongle.ember.ZigBeeDongleEzsp] - RX EZSP: EzspSetConfigurationValueResponse [networkId=0, status=EZSP_SUCCESS]
2021-04-20 15:09:19.115 [DEBUG] [systems.zigbee.dongle.ember.EmberNcp] - EzspSetConfigurationValueResponse [networkId=0, status=EZSP_SUCCESS]
2021-04-20 15:09:19.116 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - --> TX ASH frame: AshFrameAck [ackNum=6, notRdy=false]
2021-04-20 15:09:19.116 [DEBUG] [systems.zigbee.dongle.ember.EmberNcp] - EzspSetConfigurationValueRequest [networkId=0, configId=EZSP_CONFIG_PACKET_BUFFER_COUNT, value=255]
2021-04-20 15:09:19.117 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - TX EZSP: EzspSetConfigurationValueRequest [networkId=0, configId=EZSP_CONFIG_PACKET_BUFFER_COUNT, value=255]
2021-04-20 15:09:19.118 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - ASH: TX EZSP queue size: 1
2021-04-20 15:09:19.118 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - --> TX ASH frame: AshFrameData [frmNum=6, ackNum=6, reTx=false, data=AD 00 01 53 00 01 FF 00]
2021-04-20 15:09:19.140 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - <-- RX ASH frame: AshFrameData [frmNum=6, ackNum=7, reTx=false, data=AD 80 01 00 00 00]
2021-04-20 15:09:19.141 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - ASH: Frame acked and removed AshFrameData [frmNum=6, ackNum=6, reTx=false, data=AD 00 01 53 00 01 FF 00]
2021-04-20 15:09:19.142 [DEBUG] [s.zigbee.dongle.ember.ezsp.EzspFrame] - Error creating instance of EzspFrame
java.lang.reflect.InvocationTargetException: null
        at jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) ~[?:?]
        at jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) ~[?:?]
        at jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) ~[?:?]
        at java.lang.reflect.Constructor.newInstance(Constructor.java:490) ~[?:?]
        at com.zsmartsystems.zigbee.dongle.ember.ezsp.EzspFrame.createHandler(EzspFrame.java:475) [bundleFile:?]
        at com.zsmartsystems.zigbee.dongle.ember.internal.ash.AshFrameHandler$1.run(AshFrameHandler.java:219) [bundleFile:?]
Caused by: java.lang.ArrayIndexOutOfBoundsException: Index 6 out of bounds for length 6
        at com.zsmartsystems.zigbee.dongle.ember.internal.serializer.EzspDeserializer.deserializeUInt8(EzspDeserializer.java:85) ~[?:?]
        at com.zsmartsystems.zigbee.dongle.ember.ezsp.command.EzspVersionResponse.<init>(EzspVersionResponse.java:58) ~[?:?]
        ... 6 more
2021-04-20 15:09:19.147 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - ASH: No frame handler created for AshFrameData [frmNum=6, ackNum=7, reTx=false, data=AD 80 01 00 00 00]
2021-04-20 15:09:19.148 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - --> TX ASH frame: AshFrameAck [ackNum=7, notRdy=false]
2021-04-20 15:09:29.118 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - Sending EZSP transaction timed out after 10 seconds
2021-04-20 15:09:29.119 [DEBUG] [systems.zigbee.dongle.ember.EmberNcp] - EzspSetConfigurationValueRequest [networkId=0, configId=EZSP_CONFIG_END_DEVICE_POLL_TIMEOUT, value=225]
2021-04-20 15:09:29.119 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - TX EZSP: EzspSetConfigurationValueRequest [networkId=0, configId=EZSP_CONFIG_END_DEVICE_POLL_TIMEOUT, value=225]
2021-04-20 15:09:29.120 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - ASH: TX EZSP queue size: 1
2021-04-20 15:09:29.121 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - --> TX ASH frame: AshFrameData [frmNum=7, ackNum=7, reTx=false, data=AE 00 01 53 00 13 E1 00]
2021-04-20 15:09:29.128 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - <-- RX ASH frame: AshFrameData [frmNum=7, ackNum=0, reTx=false, data=AE 80 01 53 00 00]
2021-04-20 15:09:29.129 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - ASH: Frame acked and removed AshFrameData [frmNum=7, ackNum=7, reTx=false, data=AE 00 01 53 00 13 E1 00]
2021-04-20 15:09:29.130 [DEBUG] [zigbee.dongle.ember.ZigBeeDongleEzsp] - RX EZSP: EzspSetConfigurationValueResponse [networkId=0, status=EZSP_SUCCESS]
2021-04-20 15:09:29.130 [DEBUG] [systems.zigbee.dongle.ember.EmberNcp] - EzspSetConfigurationValueResponse [networkId=0, status=EZSP_SUCCESS]
2021-04-20 15:09:29.130 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - --> TX ASH frame: AshFrameAck [ackNum=0, notRdy=false]
2021-04-20 15:09:29.130 [DEBUG] [systems.zigbee.dongle.ember.EmberNcp] - EzspSetConfigurationValueRequest [networkId=0, configId=EZSP_CONFIG_END_DEVICE_POLL_TIMEOUT_SHIFT, value=3]
2021-04-20 15:09:29.131 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - TX EZSP: EzspSetConfigurationValueRequest [networkId=0, configId=EZSP_CONFIG_END_DEVICE_POLL_TIMEOUT_SHIFT, value=3]

On an unrelated sidenote:
one thing I noticed along the way is that you cannot use udev rules to force /dev/myCoordinatorDeviceName point to your stick (you may need this when you have multiple sticks as they can change their port name on booting).
Trouble is, it’s showing vendor & product ID of the USB to serial chip not the zigbee chip. And the CH340 seems to be used about everywhere (at least iTead and EleLabs and most RS485 controllers use it)