ITead’s “Sonoff Zigbee 3.0 USB Dongle Plus” model “ZBDongle-E” based on Silicon Labs EFR32MG21 +20dBm radio MCU/SoC (for EmberZNet/EZSP/Ember)

[Hedda]

FYI, ITead just released a new "ZBDongle-E" adapter as an improved replacement for ITead's previous barebone Silabs EFR32MG21 adapter and an alternative to ITead's TI CC2652P based "Sonoff Zigbee 3.0 USB Dongle Plus" (which is now renamed to "ZBDongle-P"), meaning they will continuously sell both variants, and while both type of SoC chips they are based in practically have the same specifications on paper it is worth noting before buying that they use different Zigbee stack firmware which will affect compatibility/support with different Zigbee gateway application implementations, were most notable is that Zigbee2MQTT currently only has experimental support for EZSP adapter in its zigbee-herdsman library. Check out:

https://itead.cc/product/zigbee-3-0-usb-dongle/

https://sonoff.tech/product/gateway-and-sensors/sonoff-zigbee-3-0-usb-dongle-plus-e/

Both can act as either a Zigbee Coordinator (by default) or Zigbee Router device (if flashed with such firmware instead), and if flash OpenThread/Spinel Radio Co-Processor (RCP) firmware also Thread network protocol for the upcoming Matter/CHIP standard (Project Connected Home over IP). As Silicon Lab and Texas Instruments adapters offer different compatibility ITead will now sell both of these so DIY users will now have more options.

Comparing "ZBDongle-P" vs. "ZBDongle-E" vs. barebone EFR32MG21 dongle

ITead's Zigbee USB dongles versus versus

Feature/Model	ZBDongle-P	ZBDongle-E	9888010100045
Radio SoC/MCU chip	Texas Instruments CC2652P	Silicon Labs EFR32MG21	Silicon Labs EFR32MG21
Zigbee Stack (Serial Interface Protocol API/CLI)	Z-Stack v3 (ZNP 3)	EmberZNet (EZSP v8)	EmberZNet (EZSP v8)
Optional Zigbee Router firmware	Yes (9dBm firmware available from Koenkk)	Yes (20dBm firmware available from ITead)	Yes (20dBm firmware available from ITead)
USB to UART/Serial Converter Chip	CP2102 or CP2102N	CH9102F	CH340
USB EEPROM Product Description ID	SONOFF Zigbee 3.0 USB Dongle Plus	SONOFF Zigbee 3.0 USB Dongle Plus V2	None (no USB chip EEPROM)
Flow Control	None by default (Hardware flow control optional with alternative firmware and flipped dip-switch）	Software flow control	Software flow control
RF Transmit Output Power	9dBm (firmware hardcoded), Max: 20dBm	20dBm (default)	20dBm (default)
Antenna	External (rotatable and tiltable)	External (rotatable and tiltable)	Onboard circuit board antenna
Enclosure/case	Aluminum all-metal shell casing	Aluminum all-metal shell casing	None
Length	63mm	52mm	?
Packaging	Retail-box with manual	Retail-box with manual	Anti-static bag only
Home Assistant ZHA	Supported (including USB Auto Discovery for plug-and-play)	Supported	Supported
Zigbee2MQTT	Supported	In development by zigbee-herdsman dev	In development by zigbee-herdsman dev
IoBroker	Supported	In development by zigbee-herdsman dev	In development by zigbee-herdsman dev
OpenHAB ZigBee Binding	Not yet	Supported	Supported
Domoticz Zigbee Plugin	Supported	Supported	Supported
Jeedom Zigbee Plugin	Supported	Supported	Supported

This new Silabs based dongle also targets users of multiple open-source home automation software applications so it comes pre-flashed with a firmware known to be stable and compatible with several popular DIY projects. Physically the dongle features the same external antenna + metal-enclosure too as ITead's TI based dongle does, as well as shipping in similar retail packaging to make it more attractive for sale in brick and mortar stores.

Both their Silicon Labs and Texas Instruments adapters are compatible out-of-the-box with Zigbee2MQTT which does have experimental supports Silabs EZSP (EmberZNet Serial Protocol) as well as mature support for TI Z-Stack Serial Interface, (Zigbee2MQTT's depedency the zigbee-herdsman library has support for other more manufacturers Zigbee adapters such as ConBee/RaspBee and ZiGate as well). One of the benefit to Silicon Labs is that that the same Silicon Labs EFR32MG21 based adapter will also used by the upcoming Home Assistant SkyConnect USB Stick (and is also used in ITead's Sonoff ZBBridge and ZB-GW03 eWeLink Ethernet Zigbee Gateway which with Zigbee Coordinator NCP firmware they are compatible with Home Assistant's ZHA integration, OpenHAB's ZigBee Binding, Zigbee Plugin for Domoticz, and Zigbee Plugin for Jeedom, while the Texas Instruments CC2652P based adapter is also fully compatible with IoBroker which also uses the same zigbee-herdsman library as Zigbee2MQTT, but again note that it currently only has experimental support for Silicon Labs based adapters, see Koenkk/zigbee-herdsman#319

Again, both variants still look to be great value for premium hardware that is sold for a low price.

As both are sold at a lower price it is assumed ITead hope to make money on attach rate sales, so if you are new to Zigbee also recommend to buy some of their other Sonoff branded Zigbee devices as well:

https://itead.cc/?s=zigbee&post_type=product&type_aws=true

I personally recommend Sonoff battery-operated Zigbee door/motions/temperature sensors and button.

Also, I can personally recommend using a few of their USB adapters flashed as Zigbee Routers too.

Zigbee 3.0 USB Dongle Plus - ZBDongle-E variant

https://itead.cc/product/zigbee-3-0-usb-dongle/

It uses the same EFR32MG21A020F768IM32 (EFR32 Mighty Gecko Series 2) SoC used on the first ITead Zigbee 3.0 USB Dongle, as well as on CoolKit Technologies "SM-011 V1.0" module used in th ITead Sonoff ZBBridge Zigbee Bridge and in Tuya ZS3L and Tuya ZSLC5 SoC modules. It includes a 80 MHz ARM Cortex-M33 core, 768 Flash Storage, 64 RAM, in a QFN32 package, which radio has + 20 dBm maximum power output and receive sensitivity of -104 (250 kbps O-QPSK DSSS) dBm.

TIPS!

• Note that support for Silicon Labs EZSP support in Zigbee2MQTT's zigbee-herdsman library is still experimental so great if you are a developer wanting to help the project however maybe not so great if you are an end-user that is just looking for a stable Zigbee experince, see -> [WIP]: EFR32 EZSP adapter implementation and test zigbee-herdsman#319
• This new "ZBDongle-E" adapter uses a WCH CH9102F USB-to-UART bridge (USB-to-serial converter) chip so if using Windows OS or Mac OS then need to install CH9102/CH343 device drivers from WCH -> http://www.wch-ic.com/products/CH9102.html
• First batch will come pre-flashing with EmberZNet 6.10.3 firmware which does work out-of-the-box with ZHA and Zigbee2MQTT, however Zigbee2MQTT only offers experimental support for Silabs EZSP.
• To avoid EMF interference strongly recommended buy and use -> Long USB extension cable
  • Another reason for using a USB extension cable is that the USB-plug design of ITead’s Sonoff Zigbee 3.0 USB dongle hardware adapters is a little short which makes it harder and sometimes impossible to plug it into some USB ports if the computer enclosure/chassis/casing is to thick around the USB-port as that will physically prevent the USB dongle from actually making a proper connection inside the USB port even if it looks like it is plugged in all the way that is possible.
  • Also follow all the general tips in https://github.com/zigpy/zigpy/wiki/General-tips-on-improving-Zigbee-network-range as all Zigbee Coordinator adapters is very sensitive to EMI/RFI interference (e.g. a noisy radio frequency environment will jam the signal and prevent it from receiving all Zigbee messages to it without errors). Connecting the dongle via a long "shielded" USB extension cable in a USB 2.0 port or USB 2.0 hub (and not a USB 3.0 port) to get it away from EMF sources will usually help a lot if experiencing connection or pairing symptoms/issues.
• Should be possible to use dongle hardware as Zigbee router (a.k.a. repeater) with different firmware.

FIRMWARE UPGRADE REQUIREMENTS AND FLASHING SOFTWARE LINKS

Older and newer firmware as linked to by ITead:

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

Elelabs EZSP Firmware Upgrade Utility can be used to flash the firmware to a newer or older version:

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

This firmware upgrade tool has also been packaged by walthowd in a docker image to make it easier:

https://github.com/walthowd/husbzb-firmware

Unofficial community resources:

• https://github.com/Elelabs/elelabs-zigbee-ezsp-utility
• https://github.com/walthowd/husbzb-firmware
• https://github.com/xsp1989/zigbeeFirmware/
• https://github.com/grobasoz/zigbee-firmware/
• https://github.com/zha-ng/EZSP-Firmware
• https://github.com/MattWestb/EFR32-FW

Dongle firmware upgrade prerequisites key points are:

• Use a USB extension cable (due to USB plug on the dongle being very short it might not be fully inserted physically on some chassis/enclosures unless use USB extension cable with longer plug).

FYI! Basically the serial protocol API for EmberZNet Zigbee coordinator application running on the Silicon Labs SoC/MCU does not deal well with unexpected loss of communication caused by network drops. The reason Ember remote bridges over serial-to-IP proxy server is not recommended is that clients using the EZSP serial protocol requires a robust connection between the EmberZNet Zigbee stack running on EFR32 MCU and the serial port of the Zigbee radio. With solutions such as ITEAD Sonoff ZBBridge or a Ser2Net serial proxy connection over a WiFi network it is expected to see NCP entered failed state or similar in the logs. The use of serial network proxies/bridges/servers over WiFi is therefore not recommended when wanting a stable Zigbee environment with Silicon Labs Ember based Zigbee radios. See:

https://www.zigbee2mqtt.io/how_tos/how_to_connect_to_a_remote_adapter.html

[kirovilya]

Personally, I don't like that EZSP-adapters support is still referred to as "experimental". The stack works well and I don't see any serious problems.
Also, I don't like that on some Aliexpress slots it is indicated that support in Zigbee2MQTT of such sticks is in the "(pre-alpha)" state.
It has a very negative reputation.

Because of this, some bloggers don't even test new sticks (like Sonoff's new stick) with Z2M.

Has someone already checked of this stick with Z2M? I am not yet.

[Teropi]

It seem the dev branch indeed worked much better. I was able to pair ikea devices directly. Lidl motion sensor still failed so I backed up my config and changed into new channel. In a clean setup, I paired lidl sensor and it paired immediately. However, it didn't send any events and red led didn't indicate it was even sending them.

I switched back to original channel and restored my config. Then I was able to pai Lidl sensor and against my expectation, now it also worked. I don't know if this is a problem in a sensor or z2mqtt, but for me, I can start to test actual system and it's stability.

With conbee 2, devices frequently became non functional and after adding new device or having power failure, it required voodoo rituals to get everything working again.

[MattWestb]

@Teropi The "old" LIDL sensor is working great for some (like MY in ZHA and EZSP) and some other user is not getting it working and having problem with pairing and reset of motion.

deCONZ coordinators is also tricky and can needing one power off and on for working OK and can adding devices for some time and then it back to squarer one (re power the host system).

Pleas do more testing with the dev branch then its using updated paring that shall working better with most device but its only 24 hours "old" but all is looking much better then before the last fixes being added.

[Teropi]

Yes. I'll test it in a practice but I'm a bit limited to do much more than observations. To pair three of he devices, I need to take down 5 meter high light poles so I can reset them. I have gutted Lidl power outlets moulded into 3d printed casing controlling my outdoor lights and couple of them under my roof with access from small hatch in 6m high.

[Hedda]

@Teropi also consider contributibuting to development further by providing detailed bug reports with debug logs to zigbee-herdman issues like here -> https://github.com/Koenkk/zigbee-herdsman/issues

[Teropi]

I'll do in a future if I find some new problems. Now I can't reproduce previous issues anymore. My logs can be a bit messy since there is lots of messaging going on.

[Hedda]

@Daniel-zhan-itead Can you check if ITead can donate some of these new adapters to Zigbee2MQTT and IoBroker's developers and testers?

Zigbee2MQTT and IoBroker development depend on zigbee-herdsman library and they will need multiple dongles/adapters for debugging.

[Daniel-zhan-itead]

@Hedda I arranged to send the Dongle-E to @Koenkk last week, I think he will receive it soon.
If you have any other recommended developers/testers for the debugging, feel free to send me the contact by mail.

[kirovilya]

Itead has already sent me a example - it's on its way.

[Hedda]

@Hedda I arranged to send the Dongle-E to @Koenkk last week, I think he will receive it soon.
If you have any other recommended developers/testers for the debugging, feel free to send me the contact by mail.

@Koenkk and @kirovilya Do you know of any more interested Zigbee2MQTT/IoBroker/zigbee-herdsman developers and/or testers?

As per above, Daniel Zhan got mail daniel.zhan@itead.cc so they or you can contact him directly.

FYI, also got reply message that "Archarr Wu" archarr.wu@itead.cc is the project manager for this new “ZBDongle-E” adapter product.

[Koenkk]

@Daniel-zhan-itead I received the Dongle-E yesterday, thanks, will test it soon.

[Hedda]

Here is by the way link to FCC filing/report for the new “ZBDongle-E” (a.k.a. "ZBD-E" ) adapter which contains copy of the user manual + a lot more detailed + many more internal and external pictures:

https://fccid.io/2APN5ZBD-E

https://fccid.io/2APN5ZBD-E/User-Manual/User-Manual-6012461.pdf

https://fccid.io/2APN5ZBD-E/Internal-Photos/Internal-Photos-6012455

https://fccid.io/2APN5ZBD-E/External-Photos/External-Photos-6012451

[Hedda]

@kirovilya FYI, someone reported in CNX Software blog post that ZGP (Zigbee Green Power) devices does not yet work with Silicon Labs EFR32/EZSP adapters in zigbee-herdsman with Zigbee2MQTT, do you know if that is still true? https://www.cnx-software.com/2022/08/05/sonoff-zbdongle-e-zigbee-3-0-usb-dongle-features-efr32mg21-mcu-with-20dbm-radio/

[kirovilya]

hmm. Unfortunately, I can't test such devices - I don't have ZGP devices at hand. It is also possible that this is a problem with the firmware of the coordinator, where the functionality of working with the ZGP is disabled. need to understand, look at the logs.

[tedzhouhk]

Any idea how to get it work with the current release? I accidentally got this version E (I though it is just a facelift of version D) today and it only works in ZHA but not Z2M now.

[Hedda]

Best to read into here:

Koenkk/zigbee-herdsman#319

Settings:

specify port parameter or gateway address
set adapter to "ezsp"

Zigbee2MQTT is configured using YAML based configuration.yaml file:

https://www.zigbee2mqtt.io/guide/configuration/

and

https://www.zigbee2mqtt.io/guide/configuration/adapter-settings.html

Obviously, you will first need to disconnect and/or disable ZHA first so it does not try to connect to the serial port of the adapter.

[kirovilya]

add parameter to configuration.yml:
adapter: ezsp

[Hedda]

Could Zigbee2MQTT documentation be made better to explain that user will need to type in correct radio type and not assume, see:

https://www.zigbee2mqtt.io/guide/configuration/

and

https://www.zigbee2mqtt.io/guide/configuration/adapter-settings.html

ZHA GUI let the end user pick the radio type in the initial configuration flow wizard:

https://www.home-assistant.io/integrations/zha/#configuration---gui

Better yet could automatic discovery of radio adapter type be added in a similar way that Homa Assistant ZHA and zigpy detects it?

ZHA integration in Home Assistant (depends on zigpy library) has a feature to automatically scan and detect the radio adapter type:

https://www.home-assistant.io/blog/2021/09/01/release-20219/#usb-discovery

https://www.home-assistant.io/integrations/usb/

https://www.home-assistant.io/integrations/zha/#discovery-via-usb-or-zeroconf

https://www.home-assistant.io/integrations/zwave_js/#discovery-via-usb

https://community.home-assistant.io/t/community-help-wanted-to-whitelist-all-compatible-zigbee-and-z-wave-usb-adapters-for-automatic-discovery-in-home-assistant-os/344412

The integration (zigpy) is given the serial port by it and then it does serial probe that integrates the adapter to figure out radio type.

[Hedda]

FYI, I asked ITead was got the reply that the pinout definition for the EFR32MG21 SoC chip on the new model ZBDongle-E board is the same as the original first-generation barebone Zigbee 3.0 USB Dongle model 9888010100045, but they answered that the new model ZBDongle-E adapter can still not use the exact same firmware images as their old barebone model 9888010100045 adapter, so I guess that must mean that they do not use the exact same EFR32MG21 SoC chip model or?

https://github.com/xsp1989/zigbeeFirmware/blob/master/firmware/Zigbee3.0_Dongle/EZSP/README.md

I also asked ITead about the default RF output power configuration and was told that the new ZBDongle-E adapter currently ships with Zigbee NCP 6.10.3 firmware that has enabled 20 dBm output RF power default, however is not hardcoded in the firmware so users/applications can choose to lower output RF power if they want.

In addition, got part of Configuration Parameter values Table for Silicon Labs EmberZNet PRO Zigbee networking protocol stack:

Configuration Parameter	Value
EMBER_APS_UNICAST_MESSAGE_COUNT	32
EMBER_PACKET_BUFFER_COUNT	250
EMBER_NEIGHBOR_TABLE_SIZE	26
EMBER_SOURCE_ROUTE_TABLE_SIZE	200
EMBER_ADDRESS_TABLE_SIZE	32

It does not mention "Child Table Size" but I guess that is probably configured to 32 same as for old model 9888010100045 as per https://github.com/xsp1989/zigbeeFirmware/blob/master/firmware/Zigbee3.0_Dongle/EZSP/README.md or?

PS: The "ZBDongle-E" USB "product description id" has also "SONOFF Zigbee 3.0 USB Dongle Plus V2" written to EEPROM of WCH CH9102F USB-to-UART bridge on the board to enable auto-discovered of the USB-adapter for ZHA integration in Home Assistant.

https://www.home-assistant.io/integrations/zha/#discovery-via-usb-or-zeroconf

https://www.home-assistant.io/blog/2021/09/01/release-20219/#usb-discovery

https://www.home-assistant.io/integrations/usb/

https://community.home-assistant.io/t/community-help-wanted-to-whitelist-all-compatible-zigbee-and-z-wave-usb-adapters-for-automatic-discovery-in-home-assistant-os/344412

[dami1337]

Yes to adding the new dongle more explicit to the documentation and even better to autodiscovery it. Bought the new E version by accident and spent a Saturday trying to figure out how to solve 502 error until I found the issue being the Dongle version :)

Connected it successfully now by using the "adapter: ezsp" parameter with An Aqara double switch )probably this: https://www.zigbee2mqtt.io/devices/QBKG12LM.html). So far this works.

Trying to add either of these Aqara devices and they don´t show when trying to discover them via "permit join" at all. The 2 models not working are:
https://www.zigbee2mqtt.io/devices/RTCGQ11LM.html
https://www.zigbee2mqtt.io/devices/MCCGQ14LM.html

Any advice why they might not show up? They were in the past connected to the Aqara old hub but not anymore since some time. Happy to help troubleshooting this.

[dami1337]

Have also more Aqara devices here and just paired successfully a different motion sensor: https://www.zigbee2mqtt.io/devices/RTCGQ11LM.html#xiaomi-rtcgq11lm

It doesn´t provide yet any data but it might be also caused by old batteries. Will probably have to exchange all batteries first to be on safe side since these were not in use for some time. Initial baterries probably 3 years old. Don´t want to report issues which are caused by low battery level.

When adding logging into the HA configuration, suddenly I am getting this error loop:

zigbee2mqtt@1.27.0 start
node index.js
Error: ENOENT: no such file or directory, open 'null/configuration.yaml'
at Object.openSync (node:fs:585:3)
at Object.readFileSync (node:fs:453:35)
at Object.read (/app/lib/util/yaml.ts:7:29)
at read (/app/lib/util/settings.ts:311:20)
at getInternalSettings (/app/lib/util/settings.ts:418:21)
at Object.reRead (/app/lib/util/settings.ts:696:5)
at start (/app/index.js:93:14)
[13:35:24] INFO: Handing over control to Zigbee2MQTT Core ...

Seems to be related to this error when restarting. Gosh HA will never find consumer product market fit...

Failed to restart Zigbee2MQTT
Can't create container from addon_45df7312_zigbee2mqtt: 409 Client Error for http+docker://localhost/v1.41/containers/create?name=addon_45df7312_zigbee2mqtt: Conflict ("Conflict. The container name "/addon_45df7312_zigbee2mqtt" is already in use by container "90b444ec836e5705b36c919292b5bb846475708069677413245d7104bf4af046". You have to remove (or rename) that container to be able to reuse that name.")

[dami1337]

Some logging seems to have worked, had to reset the debug config options to get the whole thing working after above error: https://pastebin.com/AxM9KgeC

Also I assume there should be a line? This is https://www.zigbee2mqtt.io/devices/RTCGQ11LM.html#xiaomi-rtcgq11lm

[kirovilya]

yes, the line should be there if the device is connected.
I don’t see connection errors in your log, I need a zigbee-nerdsman log of the process of connecting problem devices (it will be large).

[gerardsyd]

I'm getting the same issue as well. I can connect it to the coordinator but it then immediately fails to respond / send any further information. I'm seeing the same issue on ZHA as well so I'm wondering if it's a dongle issue or a software issue

[kirovilya]

can you try it with dev-version (edge) of z2m?

[dami1337]

Enabled nerdman log and here is the pastebin: https://pastebin.com/aHUrpSRy
And here is also the normal logging from earlier: https://pastebin.com/BK0YfUdi

Let me know if this is what you need or if there is anything missing :)

[kirovilya]

:) no luck. it should have looked something like this https://pastebin.com/QSEn4wCn

[dami1337]

Hm this log looks like the format you are looking for: https://pastebin.com/kD9cC7kn

What is strange is, that I copied this log from the addon -> log HA frontend. But it doesn´t save earlier timeframe and when I go into the logs folder, I am getting the entire log but not with this type of format :(

[jussbba]

Hello, I have similiar problems. None of my 3 aqara motion sensors (RTCGQ11LM) are working with Dongle-E. Neither is the door sensor MCCGQ11LM. However, Tuya door sensor TS0203 is working fine. Here is my herdsman log: https://pastebin.com/S1WZrADP

Thanks.

edit: and here is another log when adding aqara motion sensor: https://pastebin.com/KVc6Ef6w

[kirovilya]

@jussbba @dami1337 can you try again the dev-version (edge) of z2m and tell if it works or not.

[kirovilya]

sorry again... my changes merged, but it not into the dev version yet...

[kirovilya]

Now you can test dev-version

[dami1337]

Do I need to uninstall the stable z2m addon first? Besides copying the config, any other best practice to keep all z2m configuration in place? Am So., 28. Aug. 2022 um 10:25 Uhr schrieb Ilya Kirov < ***@***.***>:

…

@jussbba <https://github.com/jussbba> @dami1337 <https://github.com/dami1337> can you try again the dev-version (edge) of z2m and tell if it works or not. — Reply to this email directly, view it on GitHub <#13373 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHJXNPIESSDFAAOH3V4KLPLV3MO75ANCNFSM55LP3HQQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[kirovilya]

:( can you record herdsman log? https://www.zigbee2mqtt.io/guide/usage/debug.html#enabling-logging
I don't understand why events are not coming...

[gerardsyd]

Sure - I have done that, see below.

These are the steps. This is running the dev branch on my windows machine.

• I started Z2M in debug mode
• Paired a Aqara motion sensor. As you'll see from the logs and Screenshot 1 and 2, the first pairing doesn't show any of the battery details or any payload details.
• After leaving for a while, I re-pair it and I can then get payload data (screenshot 3 and 4)
• then it reports the change of state on time out (90s)
• Then nothing, no other events from the aqara device...

Configuration.yaml (redacted for personal details)

homeassistant: false
frontend: true
permit_join: true
mqtt:
  base_topic: zigbee2mqttwin
  server: mqtt://[ip address]:[port]
  user: [username]
  password: [password]
serial:
  adapter: ezsp
  port: \\.\COM7
advanced:
  log_syslog:
    app_name: Zigbee2MQTT
    eol: /n
    host: localhost
    localhost: localhost
    path: /dev/log
    pid: process.pid
    port: 123
    protocol: tcp4
    type: '5424'
  channel: 25
  log_level: debug

Debug logs

Info 2022-08-31 08:16:42Device '0x00158d000894fa97' joined
Info 2022-08-31 08:16:42MQTT publish: topic 'zigbee2mqttwin/bridge/event', payload '{"data":{"friendly_name":"0x00158d000894fa97","ieee_address":"0x00158d000894fa97"},"type":"device_joined"}'
Info 2022-08-31 08:16:42MQTT publish: topic 'zigbee2mqttwin/bridge/log', payload '{"message":{"friendly_name":"0x00158d000894fa97"},"type":"device_connected"}'
Info 2022-08-31 08:16:42Starting interview of '0x00158d000894fa97'
Info 2022-08-31 08:16:42MQTT publish: topic 'zigbee2mqttwin/bridge/event', payload '{"data":{"friendly_name":"0x00158d000894fa97","ieee_address":"0x00158d000894fa97","status":"started"},"type":"device_interview"}'
Info 2022-08-31 08:16:42MQTT publish: topic 'zigbee2mqttwin/bridge/log', payload '{"message":"interview_started","meta":{"friendly_name":"0x00158d000894fa97"},"type":"pairing"}'
Debug 2022-08-31 08:16:43Received Zigbee message from '0x00158d000894fa97', type 'attributeReport', cluster 'genBasic', data '{"appVersion":5,"modelId":"lumi.sensor_motion.aq2"}' from endpoint 1 with groupID 0
Debug 2022-08-31 08:16:43Skipping message, definition is undefined and still interviewing
Debug 2022-08-31 08:16:43Received Zigbee message from '0x00158d000894fa97', type 'attributeReport', cluster 'genBasic', data '{"65281":{"1":3055,"10":0,"100":0,"11":142,"3":24,"4":424,"5":62,"6":[0,0]}}' from endpoint 1 with groupID 0
Debug 2022-08-31 08:16:43Skipping message, definition is undefined and still interviewing
Debug 2022-08-31 08:16:45Received Zigbee message from '0x00158d000894fa97', type 'attributeReport', cluster 'msIlluminanceMeasurement', data '{"measuredValue":120}' from endpoint 1 with groupID 0
Debug 2022-08-31 08:16:45Skipping message, definition is undefined and still interviewing
Debug 2022-08-31 08:16:45Received Zigbee message from '0x00158d000894fa97', type 'attributeReport', cluster 'msOccupancySensing', data '{"occupancy":1}' from endpoint 1 with groupID 0
Debug 2022-08-31 08:16:45Skipping message, definition is undefined and still interviewing
Debug 2022-08-31 08:16:52Received Zigbee message from '0x00158d000894fa97', type 'attributeReport', cluster 'msIlluminanceMeasurement', data '{"measuredValue":135}' from endpoint 1 with groupID 0
Debug 2022-08-31 08:16:52Skipping message, definition is undefined and still interviewing
Info 2022-08-31 08:17:12Successfully interviewed '0x00158d000894fa97', device has successfully been paired
Info 2022-08-31 08:17:12Device '0x00158d000894fa97' is supported, identified as: Xiaomi Aqara human body movement and illuminance sensor (RTCGQ11LM)
Info 2022-08-31 08:17:12MQTT publish: topic 'zigbee2mqttwin/bridge/event', payload '{"data":{"definition":{"description":"Aqara human body movement and illuminance sensor","exposes":[{"access":1,"description":"Remaining battery in %","name":"battery","property":"battery","type":"numeric","unit":"%","value_max":100,"value_min":0},{"access":1,"description":"Indicates whether the device detected occupancy","name":"occupancy","property":"occupancy","type":"binary","value_off":false,"value_on":true},{"access":1,"description":"Temperature of the device","name":"device_temperature","property":"device_temperature","type":"numeric","unit":"°C"},{"access":1,"description":"Voltage of the battery in millivolts","name":"voltage","property":"voltage","type":"numeric","unit":"mV"},{"access":1,"description":"Measured illuminance in lux","name":"illuminance_lux","property":"illuminance","type":"numeric","unit":"lx"},{"access":1,"description":"Measured illuminance in lux","name":"illuminance","property":"illuminance","type":"numeric","unit":"lx"},{"access":1,"description":"Number of power outages","name":"power_outage_count","property":"power_outage_count","type":"numeric"},{"access":1,"description":"Link quality (signal strength)","name":"linkquality","property":"linkquality","type":"numeric","unit":"lqi","value_max":255,"value_min":0}],"model":"RTCGQ11LM","options":[{"access":2,"description":"Calibrates the device_temperature value (absolute offset), takes into effect on next report of device.","name":"device_temperature_calibration","property":"device_temperature_calibration","type":"numeric"},{"access":2,"description":"Calibrates the illuminance value (percentual offset), takes into effect on next report of device.","name":"illuminance_calibration","property":"illuminance_calibration","type":"numeric"},{"access":2,"description":"Calibrates the illuminance_lux value (percentual offset), takes into effect on next report of device.","name":"illuminance_lux_calibration","property":"illuminance_lux_calibration","type":"numeric"},{"access":2,"description":"Time in seconds after which occupancy is cleared after detecting it (default 90 seconds).","name":"occupancy_timeout","property":"occupancy_timeout","type":"numeric","value_min":0},{"access":2,"description":"Sends a message the last time occupancy (occupancy: true) was detected. When setting this for example to [10, 60] a `{\"no_occupancy_since\": 10}` will be send after 10 seconds and a `{\"no_occupancy_since\": 60}` after 60 seconds.","item_type":"number","name":"no_occupancy_since","property":"no_occupancy_since","type":"list"}],"supports_ota":false,"vendor":"Xiaomi"},"friendly_name":"0x00158d000894fa97","ieee_address":"0x00158d000894fa97","status":"successful","supported":true},"type":"device_interview"}'
Info 2022-08-31 08:17:12MQTT publish: topic 'zigbee2mqttwin/bridge/log', payload '{"message":"interview_successful","meta":{"description":"Aqara human body movement and illuminance sensor","friendly_name":"0x00158d000894fa97","model":"RTCGQ11LM","supported":true,"vendor":"Xiaomi"},"type":"pairing"}'
Debug 2022-08-31 08:20:29Received Zigbee message from '0x00158d000894fa97', type 'attributeReport', cluster 'genBasic', data '{"appVersion":5,"modelId":"lumi.sensor_motion.aq2"}' from endpoint 1 with groupID 0
Debug 2022-08-31 08:20:29lumi.sensor_motion.aq2: unknown key appVersion with value 5
Debug 2022-08-31 08:20:29lumi.sensor_motion.aq2: Processed data into payload {}
Debug 2022-08-31 08:20:29Received Zigbee message from '0x00158d000894fa97', type 'attributeReport', cluster 'genBasic', data '{"65281":{"1":3055,"10":0,"100":0,"11":187,"3":25,"4":424,"5":62,"6":[0,0]}}' from endpoint 1 with groupID 0
Debug 2022-08-31 08:20:29lumi.sensor_motion.aq2: unknown key 6 with value 0,0
Debug 2022-08-31 08:20:29lumi.sensor_motion.aq2: Processed data into payload {"voltage":3055,"battery":100,"device_temperature":25,"power_outage_count":61,"illuminance":187,"illuminance_lux":187}
Debug 2022-08-31 08:20:29lumi.sensor_motion.aq2: Processed data into payload {"voltage":3055,"battery":100,"device_temperature":25,"power_outage_count":61,"illuminance":187,"illuminance_lux":187}
Info 2022-08-31 08:20:29MQTT publish: topic 'zigbee2mqttwin/0x00158d000894fa97', payload '{"battery":100,"device_temperature":25,"illuminance":187,"illuminance_lux":187,"linkquality":208,"power_outage_count":61,"voltage":3055}'
Debug 2022-08-31 08:20:32Received Zigbee message from '0x00158d000894fa97', type 'attributeReport', cluster 'msIlluminanceMeasurement', data '{"measuredValue":115}' from endpoint 1 with groupID 0
Info 2022-08-31 08:20:32MQTT publish: topic 'zigbee2mqttwin/0x00158d000894fa97', payload '{"battery":100,"device_temperature":25,"illuminance":115,"illuminance_lux":115,"linkquality":160,"occupancy":true,"power_outage_count":61,"voltage":3055}'
Debug 2022-08-31 08:20:32Received Zigbee message from '0x00158d000894fa97', type 'attributeReport', cluster 'msOccupancySensing', data '{"occupancy":1}' from endpoint 1 with groupID 0
Info 2022-08-31 08:20:32MQTT publish: topic 'zigbee2mqttwin/0x00158d000894fa97', payload '{"battery":100,"device_temperature":25,"illuminance":115,"illuminance_lux":115,"linkquality":156,"occupancy":true,"power_outage_count":61,"voltage":3055}'
Debug 2022-08-31 08:20:39Received Zigbee message from '0x00158d000894fa97', type 'attributeReport', cluster 'msIlluminanceMeasurement', data '{"measuredValue":94}' from endpoint 1 with groupID 0
Info 2022-08-31 08:20:39MQTT publish: topic 'zigbee2mqttwin/0x00158d000894fa97', payload '{"battery":100,"device_temperature":25,"illuminance":94,"illuminance_lux":94,"linkquality":200,"occupancy":true,"power_outage_count":61,"voltage":3055}'
Debug 2022-08-31 08:20:39Received Zigbee message from '0x00158d000894fa97', type 'attributeReport', cluster 'msIlluminanceMeasurement', data '{"measuredValue":94}' from endpoint 1 with groupID 0
Info 2022-08-31 08:20:39MQTT publish: topic 'zigbee2mqttwin/0x00158d000894fa97', payload '{"battery":100,"device_temperature":25,"illuminance":94,"illuminance_lux":94,"linkquality":200,"occupancy":true,"power_outage_count":61,"voltage":3055}'
Debug 2022-08-31 08:20:39Received Zigbee message from '0x00158d000894fa97', type 'attributeReport', cluster 'msOccupancySensing', data '{"occupancy":1}' from endpoint 1 with groupID 0
Info 2022-08-31 08:20:39MQTT publish: topic 'zigbee2mqttwin/0x00158d000894fa97', payload '{"battery":100,"device_temperature":25,"illuminance":94,"illuminance_lux":94,"linkquality":200,"occupancy":true,"power_outage_count":61,"voltage":3055}'
Debug 2022-08-31 08:20:47Saving state to file C:\Users\Coding\Node\zigbee2mqtt\data\state.json
Info 2022-08-31 08:22:09MQTT publish: topic 'zigbee2mqttwin/0x00158d000894fa97', payload '{"battery":100,"device_temperature":25,"illuminance":94,"illuminance_lux":94,"linkquality":200,"occupancy":false,"power_outage_count":61,"voltage":3055}'
Debug 2022-08-31 08:25:47Saving state to file C:\Users\Coding\Node\zigbee2mqtt\data\state.json

[gerardsyd]

Hi @kirovilya, did the debug logs help?
Thanks!
G

[kirovilya]

@gerardsyd no. these logs are normal debug logs, not zigbee-herdsman logs. I think it's easier for me to buy a similar sensor and test it myself :)

[gerardsyd]

@kirovilya So I managed to get them to work. It took a while but basically just needed to keep re-pairing them multiple times until they transmitted constantly. I have three paired and working now -> let's see how long they last.
Thanks for the help / quick responses.

P.S. Sorry, I mis-read the instructions for the debug. I got it working now if you want to see them :)

[Hedda]

I'm sorry, I can't help because I don't use Home Assistant

@kirovilya @dami1337 FYI, @smarthomejunkie posted a video on how to install Zigbee2MQTT in Home Assistant with this "ezsp" adapter:

https://www.youtube.com/watch?v=4y_dDgo0i2g&ab_channel=SmartHomeJunkie

Tip is by the way to also check out these other related videos by him:

https://www.youtube.com/watch?v=z7d0OQjSiOI&ab_channel=SmartHomeJunkie

https://www.youtube.com/watch?v=IS8Jk4ckGQY&ab_channel=SmartHomeJunkie

https://www.youtube.com/watch?v=RWzzNe5gm5s&ab_channel=SmartHomeJunkie

PS: He did however install the production add-on version of "Zigbee2MQTT" and not "Zigbee2MQTT Edge" however he does mention both.

[digiblur]

I have heard the same about the conbee and luckily stuck to the CC2652 based devices with Z2M and it is has been solid. That combo definitely changed my tune about the usage of zigbee.

[smarthomejunkie]

Well, it "works" for most powered devices. For battery-powered devices, I found out the hard way that it is still flaky... Some batteries are drained very fast (Ikea Tradfri Remote) and it loses connection to the Philips Motion Sensors over here.

[digiblur]

It might need some "work" 😎

[Hedda]

For battery-powered devices, I found out the hard way that it is still flaky... Some batteries are drained very fast (Ikea Tradfri Remote) and it loses connection to the Philips Motion Sensors over here.

Which battery-operated devices exactly (make + model) and which exact firmware version do those devices have? ...I believe that there are some known firmware bugs for at least a few specific devices that are known to drain batteries.

Might be also worth trying to get an unofficial EmberZNet Zigbee NCP 7.0.x firmware image compatible with this ZBDongle-E adapter, see:

grobasoz/zigbee-firmware#28

[smarthomejunkie]

For battery-powered devices, I found out the hard way that it is still flaky... Some batteries are drained very fast (Ikea Tradfri Remote) and it loses connection to the Philips Motion Sensors over here.

Which battery-operated devices exactly (make + model) and which exact firmware version do those devices have? ...I believe that there are some known firmware bugs for at least a few specific devices that are known to drain batteries.

Might be also worth trying to get an unofficial EmberZNet Zigbee NCP 7.0.x firmware image compatible with this ZBDongle-E adapter, see:

grobasoz/zigbee-firmware#28

Thank you Hedda,
It's the IKEA E1524/E1810 remote control that has a battery drain problem. This did not happen when I used my Conbee 2 with Zigbee2MQTT. They are on the latest firmware I believe. According to Zigbee2MQTT it is 2.3.080

[Hedda]

Better yet could automatic discovery of radio adapter type be added in a similar way that Homa Assistant ZHA and zigpy detects it?

ZHA integration in Home Assistant (depends on zigpy library) has a feature to automatically scan and detect the radio adapter type:

https://www.home-assistant.io/blog/2021/09/01/release-20219/#usb-discovery

https://www.home-assistant.io/integrations/usb/

https://www.home-assistant.io/integrations/zha/#discovery-via-usb-or-zeroconf

https://www.home-assistant.io/integrations/zwave_js/#discovery-via-usb

https://community.home-assistant.io/t/community-help-wanted-to-whitelist-all-compatible-zigbee-and-z-wave-usb-adapters-for-automatic-discovery-in-home-assistant-os/344412

The integration (zigpy) is given the serial port by it and then it does serial probe that integrates the adapter to figure out radio type.

Any further thought about having some kind of auto-discovery of the USB adapter and serial probing to try to detect the radio type?

FYI, Home Assistant can already detect a few different Zigbee USB radio adapters, including the CC2652P-based Sonoff ZBDongle-P USB dongle from ITead, and it now looks like Home Assistant will soon support also be able to automatically do USB discovery for this new [ITead’s “Sonoff Zigbee 3.0 USB Dongle Plus V2” model “ZBDongle-E” based on Silicon Labs EFR32MG21, at least if they merge:

home-assistant/core#77523

That will add USB identifiers for VID (Vendor ID)+ PID (Product ID) in combination with "Product Description ID" as unique identifier for it:

core/homeassistant/components/zha/manifest.json

  {
      "vid": "1A86",
      "pid": "55D4",
      "description": "*sonoff*plus*",
      "known_devices": ["sonoff zigbee dongle plus v2"]
    },

core/homeassistant/generated/usb.py

    {
        "domain": "zha",
        "vid": "1A86",
        "pid": "55D4",
        "description": "*sonoff*plus*"
    },

The board of this new ZBDongle-E adapter uses a WCH CH9102F USB-to-UART/Serial converter chip (and CH9102/CH340 device drivers) which has VID (Vendor ID) "1A86 " and PID (Product ID) 55D4 as well as the new USB product description identifier "sonoff zigbee dongle plus v2" on this variant.

[kirovilya]

Already implemented autodetection https://github.com/Koenkk/zigbee-herdsman/blob/master/src/adapter/ezsp/adapter/ezspAdapter.ts#L24
But I noticed that it does not work on all operating systems

[Hedda]

But can zigbee-herdsman already during installation/configuration automatically detect known Zigbee USB adapters that the user connected, and more importantly perform a serial probe to check if the entered Zigbee adapter is using zstack, ezsp, deconz, or zigate adapter type, and test which baudrate it connects with, so that the end-user does not always manually have to enter adapter type and speed configuration manually and instead done "automagically" once select device path? ...I thought that Zigbee2MQTT currently assumed that all adapters are of zstack type and if not then the end-user need to manually change the configuration to for example ezsp, deconz, or zigate?

https://www.zigbee2mqtt.io/guide/configuration/adapter-settings.html

  # Optional: adapter type, not needed unless you are experiencing problems (default: shown below, options: zstack, deconz, ezsp)
  adapter: null
  # Optional: Baud rate speed for serial port, this can be anything firmware support but default is 115200 for Z-Stack and EZSP, 38400 for Deconz, however note that some EZSP firmware need 57600.
  baudrate: 115200
  # Optional: RTS / CTS Hardware Flow Control for serial port (default: false)
  rtscts: false

[kirovilya]

if no port is specified in config, all adapters are polled and must return a port it can serve. if such a port is found, then z2m will start with the adapter that found the port.
if a port is specified in config, the adapters are queried and must confirm that it can serve that port.

however, in both cases the port parameters will be by default: 115200, rtscts=false

thus, you can launch a new stick from Sonoff without even specifying a port and adapter, or specifying only a port.

[Hedda]

Ah, I think that most older Silicon Labs ezsp adapter firmware (like for Silabs EM35x, EM35xx, and ETRX35x based adapters) use ‭57600‬ baudrate as defasult so the major difference with the zigpy libraries (bellows radio library for zigpy specifically) serial probing method is that it will first test using 115200 as baudrate for ezsp but then if that baudrate fails it will continue to also test ‭probing with 57600‬as baudrate, ...however I am not sure if zigpy serial probing methods does the same type of failover probing for rtscts as it does for baudrate to test both values there to or not.

Could you make zigbee-herdsman automatically try connecting via 57600‬ baudrate if it fails to automatically connect using 115200 as baudrate for ezsp? That way there should be less use cases when a new user will need to manually configure the adapter radio type via xml.

[andreasbalzer]

I only get Bad Gateway. It would be great if someone can give me a pointer on how to proceed: #13734

[smarthomejunkie]

I managed to pair all my devices. But... battery-powered devices get drained very fast (1 or 2 days) The devices that get drained fast are Ikea Tradfri remotes (the round ones) and Heiman Smoke sensors. Philips Hue Motion sensors drop off often and have to be re-paired after that. The battery drain issue is a big one for me, especially for the Smoke Sensors.

…

On Fri, Sep 2, 2022 at 6:49 AM Gerard ***@***.***> wrote: @kirovilya <https://github.com/kirovilya> So I managed to get them to work. It took a while but basically just needed to keep re-pairing them multiple times until they transmitted constantly. I have three paired and working now -> let's see how long they last. Thanks for the help / quick responses. — Reply to this email directly, view it on GitHub <#13373 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQA4VX6ZSP74M7Z4LZLEGELV4GBL5ANCNFSM55LP3HQQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[gerardsyd]

This is with the dongle-e? I've got aqara motion sensors - let's see how the battery life goes.

[Daniel-zhan-itead]

I managed to pair all my devices. But... battery-powered devices get drained very fast (1 or 2 days) The devices that get drained fast are Ikea Tradfri remotes (the round ones) and Heiman Smoke sensors. Philips Hue Motion sensors drop off often and have to be re-paired after that. The battery drain issue is a big one for me, especially for the Smoke Sensors.
…
On Fri, Sep 2, 2022 at 6:49 AM Gerard @.> wrote: @kirovilya https://github.com/kirovilya So I managed to get them to work. It took a while but basically just needed to keep re-pairing them multiple times until they transmitted constantly. I have three paired and working now -> let's see how long they last. Thanks for the help / quick responses. — Reply to this email directly, view it on GitHub <#13373 (reply in thread)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AQA4VX6ZSP74M7Z4LZLEGELV4GBL5ANCNFSM55LP3HQQ . You are receiving this because you were mentioned.Message ID: @.>

How about the distance between the end devices and ZBDongle-E coordinator?

[Hedda]

Maybe post a Zigbee network map to also show if all the battery-operated sensors are connecting to the closest Zigbee Router devices or if they are all only connecting directly to the Zigbee Coordinator.

Bad reception caused by either long distances or interference will cause the Zigbee devices to keep resending their messages and thus draining the battery from battery-operated devices.

This is one of the main reasons why you want to do everything you can to avoid any source of interference, but it is also why you want to have many Zigbee Router devices in your Zigbee network mesh so that devices that are far away from the Zigbee Coordinator will connect through a Zigbee router instead of directly to the Zigbee Coordinator.

Should be noted that a few manufacturer's devices (most notably a few Aqara/Xiaomi and Tuya devices) have badly written firmware that either prevents them from routing messages from other manufacturer's brands of devices or refuses to connect through a Zigbee Router that is not of the same manufacturer and/or brand.

[smarthomejunkie]

Yes, It's with the Dongle-E. The Aqara motions sensor don't seem to have issues with draining batteries. I also use them.

…

On Fri, Sep 2, 2022 at 11:49 AM Gerard ***@***.***> wrote: This is with the dongle-e? I've got aqara motion sensors - let's see how the battery life goes. — Reply to this email directly, view it on GitHub <#13373 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQA4VX3U6JMDP2TXZRH4L2LV4HERXANCNFSM55LP3HQQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[kdober]

Hi.
Anyone tried to pair the aqara roller shade E1?

The device it is recognized, but it doesn't respond and there is no battery level information (for example).
On the logs it says it failed to configure it:

error 2022-09-01 18:51:40Failed to configure '0x54ef4410003a2d5c', attempt 3 (Error: Read 0x54ef4410003a2d5c/1 aqaraOpple([1034], {"sendWhen":"immediate","timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":true,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":4447,"transactionSequenceNumber":null,"writeUndiv":false}) failed (Timeout - 34010 - 1 - 17 - 64704 - 1 after 10000ms) at Timeout._onTimeout (/app/node_modules/zigbee-herdsman/src/utils/waitress.ts:64:35) at listOnTimeout (node:internal/timers:559:17) at processTimers (node:internal/timers:502:7))

[kirovilya]

Record herdsman log please https://www.zigbee2mqtt.io/guide/usage/debug.html#zigbee-herdsman-debug-logging

[johnypony3]

While using the dongle E with zha, I had to go to the devices final resting place and just keep pairing. Used this combination, flaky af.

The real dongle with zigbee2mqtt the experience is quite different. Paired right away, super solid.

I use a wired nettop with the dongle on a cable.

My advice is to get rid of the E and get the P. Also not zha, its fairly limited.

[digiblur]

It is usually best to pair in place. That pair near the coordinator is an old myth.

[smarthomejunkie]

I do have a very good mesh network with a lot of routers and did not have this issue with my Conbee 2 stick. I also had some battery-powered devices (Ikea Tradfri remotes) in the same room as the Zigbee stick and the battery drained in 2 days with the ZBDongle Plus. I cannot show a map now because all devices that were affected are currently dead because of this :( Do you know if there is a setting in Zigbee2MQTT where you can set that the stick may not connect to battery-powered (children) devices? This seems to be possible in ZHA.

…

On Thu, Sep 8, 2022 at 1:16 PM Hedda ***@***.***> wrote: Maybe post a Zigbee network map to also show if all the battery-operated sensors are connecting to the closest Zigbee Router devices or if they are all only connecting directly to the Zigbee Coordinator. Bad reception caused by either long distances or interference will cause the Zigbee devices to keep resending their messages and thus draining the battery from battery-operated devices. This is one of the main reasons why you want to do everything you can to avoid any source of interference, but it is also why you want to have many Zigbee Router devices in your Zigbee network mesh so that devices that are far away from the Zigbee Coordinator will connect through a Zigbee router instead of directly to the Zigbee Coordinator. Should be noted that a few manufacturer's devices (most notably a few Aqara/Xiaomi and Tuya devices) have badly written firmware that either prevents them from routing messages from other manufacturer's brands of devices or refuses to connect through a Zigbee Router that is not of the same manufacturer and/or brand. — Reply to this email directly, view it on GitHub <#13373 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQA4VX6PRT4OGLC6VUHFMLDV5HDHXANCNFSM55LP3HQQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[jerrm]

The Ikea remotes are notorious for the battery issue.

I saw one report that said disabling OTA updates resolved it. It only stood out because I don't recall seeing that elsewhere, though admittedly had only skimmed the posts since I don't have the device.

May be an irrevelant anecdote, or may be worth checking.

[smarthomejunkie]

Well, not if you use the Conbee 2 stick. With the Conbee 2 stick they don't drain for months.

[jerrm]

There are several threads at various forums about ikea remote battery life. I haven't followed too closely, but it seems to be both a ZHA and Z2M issue. I don't have the device, but was considering it. No idea if there was any indication about Conbee one way or the other.

[smarthomejunkie]

I can say that I used Conbee 2 on Deconz and Zigbee2MQTT for over two years. Never had an issue with the Ikea remotes. Might as well be an issue on the Dongle-P and Dongle-E then. Anyway, Conbee and Zigbee2MQTT has other issues unfortunately. You can't always get what you want I guess... 🙄

[jerrm]

Always trade offs unfortunately.

[Hedda]

FYI, there is now also an option to flash this ZBDongle-E with Zigbee Router firmware to repurpose it as a Zigbee signal repeater / Zigbee range extender device, and at least on paper it should be great for that purpose.

https://github.com/itead/Sonoff_Zigbee_Dongle_Firmware/tree/master/Dongle-E/Router

vs.

https://github.com/itead/Sonoff_Zigbee_Dongle_Firmware/tree/master/Dongle-E/NCP

EFR32MG2x (and EFR32xG1) chip adapters like these then it will have the newer Gecko Bootloader (GBL) that has the ability to enter bootloader mode automatically via software (also known as Auto-BSL) without the need to press holding physical BTL/reset button or short circuit any GPIO/soldering-pads. Silicon Labs can also be flashed over USB/UART by manually putting them in bootloader / BSL mode (also known as boot mode or firmware recovery mode.

For flashing Silabs EFR32MGxx chips checkout these different methods:

• Elelabs Firmware Update Utility (multi platform Python based command line tool)
• agners silabs-flasher - Silicon Labs Firmware flashing utility (multi platform Python based command line tool)
• walthowd husbzb-firmware script (community maintained multi platform bash script)
• Manual Xmodem sending commands over a terminal console (note that any terminal application with "Xmodem(N)" send can be used)
• Silicon Labs Simplicity Studio included "Flash Programmer" (instructions) (can't find your device? read below!)

[Hedda]

I have flashed https://github.com/itead/Sonoff_Zigbee_Dongle_Firmware/tree/master/Dongle-E/Router to ZBDongle-E using Elelabs.

But the device is not joining the Zigbee network as a router and the serial output from the dongle is looping in something which looks like an attempt to connect (the pan ID 0x1A71 and channel 11 are correct) with following errors:

What do you mean with serial output from the dongle? After you have flash the router firmware you should not connect it via USB/UART/serial but instead via Zigbee wireless just like any other Zigbee Router device.

https://www.zigbee2mqtt.io/advanced/zigbee/01_zigbee_network.html

That works the same as this:

https://www.zigbee2mqtt.io/advanced/zigbee/05_create_a_cc2530_router.html#what-do-i-need

That is, the purpose is to use it it as dedicated Zigbee Router device similar to example IKEA Trådfri Signal Repeater

https://www.ikea.com/gb/en/p/tradfri-signal-repeater-80424255/

[JirkaCadek]

Hi, I hope I understand how Zigbee router should work, the issue is that it doesn't seem to join existing Zigbee network (I do not see it in Zigbee2mqtt as a device). I was debugging why is that happening.

So I connected it back by USB while it was joining the existing zigbee wireless network and read serial interface - output of serialInterface.serial (as can be seen here https://github.com/Elelabs/elelabs-zigbee-ezsp-utility/blob/7fc415497f7e2b3410e3350b359ac5c71043399e/Elelabs_EzspFwUtility.py#L599 - I tweaked the Elelabs tool to read from the interface in loop to get the whole log I attached above).

When I set "Permit All" in zigbee2mqtt I can see in the log it discovers the network Examining beacon on channel 11 with panId 0x1A71 but probably because of mentioned errors it fails to join it.

[JirkaCadek]

hmm, I somehow managed to join the zigbee network once and see the dongle as an item in zigbee2mqtt, but after delete it is not joining again :/

[Hedda]

FYI, it sounds as if @sujithg9 might still be working on Dongle-E with Zigbee Router firmware, see -> #13894

[shoom3301]

but after delete it is not joining again :/

Same problem, @JirkaCadek have you solved it?

[rgutialo]

Hi all,
I bought a -E dongle and I discovered that this hardware is "experimental" for Zigbee2MQTT. I want them as a router so I would like to know if this device is compatible with Zigbee2MQTT, if the connection is stable and also how to join the router into an existing Zigbee network.

[Hedda]

It looks like converter support for "ZBDongle-E" with Zigbee Router device firmware has been added to zigbee-herdsman-converters 7-days ago, so likely Zigbee2MQTT ”Edge” (dev branch) will support it now but not in the master branch (mainline) or any stable releases as yet, see:

#13894

Koenkk/zigbee-herdsman-converters#4641

https://github.com/Koenkk/zigbee-herdsman-converters/tags

https://github.com/Koenkk/zigbee2mqtt/commits/dev

https://github.com/Koenkk/zigbee2mqtt/commits/master

https://github.com/Koenkk/zigbee2mqtt/releases

[ayenz]

I bought Sonoff Zigbee Dongle, but got ZBDongle-E version (I have ZBDongle-P version, and works flawlessly with all my sensors). I tried to pair the ZBDongle-E with my Aqara Door Sensor MCCGQ14LM and Motion Sensor RTCGQ11LM, none of them successfully paired. But I succeeded pair ZBDongle-E with other sensor (NEO Motion & NEO Sirene).

I already tried zigbee2mqtt dev branch, but still no luck. Can someone help me to pair with Aqara Sensor? Any help is welcome.

[smarthomejunkie]

I bought Sonoff Zigbee Dongle, but got ZBDongle-E version (I have ZBDongle-P version, and works flawlessly with all my sensors). I tried to pair the ZBDongle-E with my Aqara Door Sensor MCCGQ14LM and Motion Sensor RTCGQ11LM, none of them successfully paired. But I succeeded pair ZBDongle-E with other sensor (NEO Motion & NEO Sirene).

I already tried zigbee2mqtt dev branch, but still no luck. Can someone help me to pair with Aqara Sensor? Any help is welcome.

I paired my Aqara door sensors without any problem with the Dongle-E. I had to pair them close to the dongle though.

[ayenz]

I'm sorry for late reply, been busy lately. I'll try to sniff message from Aqara with Dongle-E this week.

I paired my Aqara door sensors without any problem with the Dongle-E. I had to pair them close to the dongle though.

Ohh I see, I tried to pair Aqara with 1 meter distance (still stick on my door) but none of them show up in zigbee2mqtt dashboard.

[ayenz]

I don't know if this file help you guys.
Dongle-E Sniff Filtered.pcapng.zip
I'm using this tutorial with default key and try to sniff Aqara Motion Sensor RTCGQ11LM (press sensor button several times).

[MattWestb]

@ayenz in the 802154 beacon replay from the coordinator of PAN-ID 0x1a65 (its also from one not coordinator PAN-ID 0x1a62) its not open for paring:

IEEE 802.15.4 Beacon, Src: 0x0000
    Frame Control Field: 0x8000, Frame Type: Beacon, Destination Addressing Mode: None, Frame Version: IEEE Std 802.15.4-2003, Source Addressing Mode: Short/16-bit
    Sequence Number: 161
    Source PAN: 0x276f
    Source: 0x0000
    Superframe Specification: PAN Coordinator
        .... .... .... 1111 = Beacon Interval: 15
        .... .... 1111 .... = Superframe Interval: 15
        .... 1111 .... .... = Final CAP Slot: 15
        ...0 .... .... .... = Battery Extension: False
        .1.. .... .... .... = PAN Coordinator: True
        0... .... .... .... = Association Permit: False
    GTS
    Pending Addresses: 0 Short and 0 Long
    TI CC24xx-format metadata: FCS OK

Its the 0... .... .... .... = Association Permit: False shall looking like
1... .... .... .... = Association Permit: True so the coordinator.

I cant see if the coordinator is sending permit joining then the sniff is not having one network key transaction and all Zigbee frames is not encrypted.

Perhaps your system is one one other PAN-ID and / or radio channel ?

[Daniel-zhan-itead]

I don't know if this file help you guys. Dongle-E Sniff Filtered.pcapng.zip I'm using this tutorial with default key and try to sniff Aqara Motion Sensor RTCGQ11LM (press sensor button several times).

Thanks for your info, we have checked the sniff file, the epid is TI info as you can see from the below screenshot.

It seems the sniff is not successful for ZBDongle-E, would you pls confirm that the ZBDongle-E Zigbee channel is the same as you configure in the sniffer?

[telefonmann]

Hi all,

I am running Home Assistant and zigbee2mqtt with a ITead ZBDongle-P and it works great.
Now I just received a second ZBDongle-P which I ordered as spare part, just in case...
On the box it says "ZBDongle-P", and both sicks have the exact same size. But when I connect the new one, the log says

[92352.045887] usb 1-1.4: Manufacturer: Silicon Labs
[92352.045893] usb 1-1.4: SerialNumber: 0001
[92352.055372] usb 1-1.4: cp210x converter now attached to ttyUSB0

However, it does work fine. I even flashed the same firmware (CC1352P2_CC2652P_launchpad_coordinator_20220219) which I also flashed to the first (ITead) stick - no problems.

Can anyone explain what is going on here? Is this really a ZBDongle-P or ZBDongle-E with wrong packaging?

Thanks in advance!

[telefonmann]

@TheJulianJES Thank you for your response! So no need to return it and I will just ignore the different manufacturers :)

[Hedda]

It's a Texas Instruments based ZBDongle-P then. The log mentions "Silicon Labs" because the USB to serial chip is made by Silicon Labs. (The Zigbee chip itself is made by TI)

That is correct. Though understandable confusing. The TI CC2652P based ZBDongle-P uses a Silicon Labs USB-to-UART bridge chip while the Silabs EFR32MG21 based ZBDongle-E uses as WCH based USB-to-UART converter chip instead.

[telefonmann]

@Hedda What confuses me more is that obviously my two ZBDongle-P use different USB-to-UART chips.

[MattWestb]

The CH340 can without HW flow control sending and receiving 1.5 M baud and the CH9102F (that is one updated version and i think its used in SkyConnect) shall being better and the cheep Silabs can only doing around 800K to 900K baud (the more expensive can doing much more speed) but all is more then enough for one simple NCP communication and its also depending how good the TTL interface is on the NCP side.

[Hedda]

@Hedda What confuses me more is that obviously my two ZBDongle-P use different USB-to-UART chips.

Yes that is correct, as I understand that is because they initially used CC2652P + CP2102N in combination then later switched to using CC2652P + CP2102 (instead of the CP2102N model) for the ZBDongle-P due to chip shortages, and that is why you will now see resellers sometimes documenting that ZBDongle-P as using "CP2102(N)" or "CP2102 N" with the "N" in parenthesis or separate, (which I guess is in case they have mixed old stock with new stock of it on their warehouse shelves).

CH9102F (that is one updated version and i think its used in SkyConnect)

Sonoff/ITead currently only use the CH9102F chip on the "ZBDongle-E" model and not any of their CC2652-based "ZBDongle-P" revisions.

FYI, the reason why they choose to use CH9102F as a USB-to-UART bridge chip is that it features a writable/ programmable EEPROM which enables them to change Product Description ID (Product Description String" string) for the USB device to allow for plug-and-play USB discovery, see -> https://community.home-assistant.io/t/community-help-wanted-to-whitelist-all-compatible-zigbee-and-z-wave-usb-adapters-for-automatic-discovery-in-home-assistant-os/344412

They could have alternatively gone with CH340B model by WCH or FT231 chips like FT231X by FTDI which also feature writable/ programmable EEPROM. From an end-users point-of-view it should in practice not really matter as long as you know which device drivers you need to install in your operating-system as a Zigbee Coordinator will never get up to the top speeds of any of those USB-to-UART converter chips.

Note that the CH340C and CH340E models in the CH340 series are less expensive but do not feature writable/ programmable EEPROM.

[tomergam]

try to flush version ncp-uart-sw_7.1.1.0_115200.gbl and back again to ncp-uart-sw_EZNet6.10.3_V1.0.1.gbl
with Elelabs_EzspFwUtility.py

but it failed or somthing
getting wired boot loader messege:
2022/10/27 01:26:03 Elelabs_EzspFwUtility: EZSP adapter in bootloader mode detected: 2022/10/27 01:26:03 Elelabs_EzspFwUtility: [ASSERT:D:/SiliconLabs/SimplicityStudio/v5/developer/sdks/gecko_sdk_suite/v3.2/platform/base/hal/micro/cortexm3/efm32/token.c:211] 2022/10/27 01:26:03 Elelabs_EzspFwUtility: Allready in bootloader mode. No need to restart 2022/10/27 01:26:04 Elelabs_EzspFwUtility: Successfully restarted into X-MODEM mode! Starting upload of the new firmware... DO NOT INTERRUPT(!) 2022/10/27 01:26:14 Elelabs_EzspFwUtility: Failed to restart into bootloader mode. Please see users guide.

not sure how to solved it

[thekev]

I was able to solve the assert error by flashing nvm3_initfile.gbl then ncp-uart-sw_v6.10.3_115200.gbl immediately thereafter. It now communicates as expected.

[mikesierra2]

I have the latest version of Hone Assistant running on a Pi 400, with ZBDongle-E from Sonoff. I only have a few ikea zigbee butoons. The zbdongle-e is plugged in to the usb 2.0 port on pi400, using a 1.5 meter usb cable to reduce interferange. I have configured zigbee2mqtt. This works for a short time. Within hours, the buttons don't work. I call always make it work again by restarting zigbee2mqtt. Is there any thing i can do to fix this issue?

I know that the zbdongle-p version has a firmware flash tool and a supported firmware for HA. Is there such a thing for zbdongle-e yet?

Cheers

[trackhacs]

I had the ZBD-E on a arm (rock64) for testing with 10 devices, basically flawless. Convinced I wanted to move the system to the big x86 box - copied all the files and started zigbee2qmt. It was working shortly, but after short time the devices just disappeared, and it was really difficult to pair devices. However - switching directly to ZHA, discovered almost all devices (without repairing).

so:
ARM7 - zigbee2mqtt 1.28.2-2 -> (perfectly working)
X86 - zigbee2mqtt 1.28.4-1 -> (very unstable and lost devices) (didnt unfortunately test the EZSP flag)

Manjaro/Install via pamac, non docker.

further:
on X86 mosquitto denied access to zigbee2mqtt via localhost, but putting the IP directly (192.168.2.90) solved it so far.

[grambas]

I have just connected ZBDongle-E to my new HA instance and Zigbee2MQTT version 1.29.1-1
I have successfully connected MCCGQ11LM and AB3257001NJ devices, but getting Attempt to access memory outside buffer bounds errors in loop.

Config:

data_path: /config/zigbee2mqtt
socat:
  enabled: false
  master: pty,raw,echo=0,link=/tmp/ttyZ2M,mode=777
  slave: tcp-listen:8485,keepalive,nodelay,reuseaddr,keepidle=1,keepintvl=1,keepcnt=5
  options: "-d -d"
  log: false
mqtt:
  base_topic: zigbee2mqtt
  server: mqtt://XXX
  user: XXX
  password: XXX
serial:
  adapter: ezsp
  port: >-
    /dev/serial/by-id/usb-ITEAD_SONOFF_Zigbee_3.0_USB_Dongle_Plus_V2_20220812143549-if00
advanced:
  log_level: warn
  channel: 15
  network_key:
    - 1
    - 3
    - 5
    - 7
    - 9
    - 11
    - 13
    - 15
    - 0
    - 2
    - 4
    - 6
    - 8
    - 10
    - 12
    - 13
zigbee_herdsman_debug: true

Logs:

2023-01-13T21:05:39.066Z zigbee-herdsman:adapter:ezsp:ezsp Time to watchdog ... 0
2023-01-13T21:05:39.066Z zigbee-herdsman:adapter:ezsp:ezsp ==> nop: null
2023-01-13T21:05:39.066Z zigbee-herdsman:adapter:ezsp:ezsp ==> {"_cls_":"nop","_id_":5,"_isRequest_":true}
2023-01-13T21:05:39.066Z zigbee-herdsman:adapter:ezsp:uart --> DATA (3,2,0): fb00010500
2023-01-13T21:05:39.066Z zigbee-herdsman:adapter:ezsp:uart --> [32b921a9512af6cf7e]
2023-01-13T21:05:39.067Z zigbee-herdsman:adapter:ezsp:uart -?- waiting (4)
2023-01-13T21:05:39.071Z zigbee-herdsman:adapter:ezsp:uart <-- [24b9a1a9512abc927e]
2023-01-13T21:05:39.071Z zigbee-herdsman:adapter:ezsp:uart <-- DATA (2,4,0): 24b9a1a9512abc927e
2023-01-13T21:05:39.071Z zigbee-herdsman:adapter:ezsp:uart --> ACK  (3)
2023-01-13T21:05:39.071Z zigbee-herdsman:adapter:ezsp:uart --> [83401b7e]
2023-01-13T21:05:39.071Z zigbee-herdsman:adapter:ezsp:ezsp <== Frame: fb80010500
2023-01-13T21:05:39.072Z zigbee-herdsman:adapter:ezsp:ezsp <== 0x5: {"_id_":5,"_cls_":"nop","_isRequest_":false}
2023-01-13T21:05:39.072Z zigbee-herdsman:adapter:ezsp:uart -+- waiting (4) success
2023-01-13T21:05:42.005Z zigbee-herdsman:adapter:ezsp:uart <-- [34b9b1a9902a7d38b259510a7e]
2023-01-13T21:05:42.005Z zigbee-herdsman:adapter:ezsp:uart <-- DATA (3,4,0): 34b9b1a9902a18b259510a7e
2023-01-13T21:05:42.005Z zigbee-herdsman:adapter:ezsp:uart --> ACK  (4)
2023-01-13T21:05:42.005Z zigbee-herdsman:adapter:ezsp:uart --> [8430fc7e]
2023-01-13T21:05:42.005Z zigbee-herdsman:adapter:ezsp:ezsp <== Frame: fb9001c4000d0000
2023-01-13T21:05:42.006Z zigbee-herdsman:adapter:ezsp:uart Error while parsing to ZpiObject 'RangeError: Attempt to access memory outside buffer bounds
    at new NodeError (node:internal/errors:387:5)
    at boundsError (node:internal/buffer:84:11)
    at Buffer.readUInt16LE (node:internal/buffer:243:5)
    at Buffer.readUIntLE (node:internal/buffer:180:17)
    at Function.deserialize (/app/node_modules/zigbee-herdsman/src/adapter/ezsp/driver/types/basic.ts:19:67)
    at new EZSPFrameData (/app/node_modules/zigbee-herdsman/src/adapter/ezsp/driver/ezsp.ts:83:54)
    at Ezsp.onFrameReceived (/app/node_modules/zigbee-herdsman/src/adapter/ezsp/driver/ezsp.ts:294:21)
    at SerialDriver.emit (node:events:513:28)
    at SerialDriver.handleDATA (/app/node_modules/zigbee-herdsman/src/adapter/ezsp/driver/uart.ts:228:14)
    at SerialDriver.onParsed (/app/node_modules/zigbee-herdsman/src/adapter/ezsp/driver/uart.ts:175:22)'
2023-01-13T21:05:42.036Z zigbee-herdsman:adapter:ezsp:uart <-- [44b9b1a9902a7d38b259fad17e]
2023-01-13T21:05:42.036Z zigbee-herdsman:adapter:ezsp:uart <-- DATA (4,4,0): 44b9b1a9902a18b259fad17e
2023-01-13T21:05:42.036Z zigbee-herdsman:adapter:ezsp:uart --> ACK  (5)
2023-01-13T21:05:42.036Z zigbee-herdsman:adapter:ezsp:uart --> [8520dd7e]
2023-01-13T21:05:42.036Z zigbee-herdsman:adapter:ezsp:ezsp <== Frame: fb9001c4000d0000
2023-01-13T21:05:42.037Z zigbee-herdsman:adapter:ezsp:uart Error while parsing to ZpiObject 'RangeError: Attempt to access memory outside buffer bounds
    at new NodeError (node:internal/errors:387:5)
    at boundsError (node:internal/buffer:84:11)
    at Buffer.readUInt16LE (node:internal/buffer:243:5)
    at Buffer.readUIntLE (node:internal/buffer:180:17)
    at Function.deserialize (/app/node_modules/zigbee-herdsman/src/adapter/ezsp/driver/types/basic.ts:19:67)
    at new EZSPFrameData (/app/node_modules/zigbee-herdsman/src/adapter/ezsp/driver/ezsp.ts:83:54)
    at Ezsp.onFrameReceived (/app/node_modules/zigbee-herdsman/src/adapter/ezsp/driver/ezsp.ts:294:21)
    at SerialDriver.emit (node:events:513:28)
    at SerialDriver.handleDATA (/app/node_modules/zigbee-herdsman/src/adapter/ezsp/driver/uart.ts:228:14)
    at SerialDriver.onParsed (/app/node_modules/zigbee-herdsman/src/adapter/ezsp/driver/uart.ts:175:22)'
2023-01-13T21:05:42.040Z zigbee-herdsman:adapter:ezsp:uart <-- [54b9b1a9902a7d38b259a92f7e]
2023-01-13T21:05:42.040Z zigbee-herdsman:adapter:ezsp:uart <-- DATA (5,4,0): 54b9b1a9902a18b259a92f7e
2023-01-13T21:05:42.040Z zigbee-herdsman:adapter:ezsp:uart --> ACK  (6)
2023-01-13T21:05:42.041Z zigbee-herdsman:adapter:ezsp:uart --> [8610be7e]
2023-01-13T21:05:42.041Z zigbee-herdsman:adapter:ezsp:ezsp <== Frame: fb9001c4000d0000
2023-01-13T21:05:42.041Z zigbee-herdsman:adapter:ezsp:uart Error while parsing to ZpiObject 'RangeError: Attempt to access memory outside buffer bounds
    at new NodeError (node:internal/errors:387:5)
    at boundsError (node:internal/buffer:84:11)
    at Buffer.readUInt16LE (node:internal/buffer:243:5)
    at Buffer.readUIntLE (node:internal/buffer:180:17)
    at Function.deserialize (/app/node_modules/zigbee-herdsman/src/adapter/ezsp/driver/types/basic.ts:19:67)
    at new EZSPFrameData (/app/node_modules/zigbee-herdsman/src/adapter/ezsp/driver/ezsp.ts:83:54)
    at Ezsp.onFrameReceived (/app/node_modules/zigbee-herdsman/src/adapter/ezsp/driver/ezsp.ts:294:21)
    at SerialDriver.emit (node:events:513:28)
    at SerialDriver.handleDATA (/app/node_modules/zigbee-herdsman/src/adapter/ezsp/driver/uart.ts:228:14)
    at SerialDriver.onParsed (/app/node_modules/zigbee-herdsman/src/adapter/ezsp/driver/uart.ts:175:22)'
2023-01-13T21:05:42.523Z zigbee-herdsman:adapter:ezsp:uart <-- [64b9b1a9902a7d38b2595d2d7e]
2023-01-13T21:05:42.523Z zigbee-herdsman:adapter:ezsp:uart <-- DATA (6,4,0): 64b9b1a9902a18b2595d2d7e
2023-01-13T21:05:42.524Z zigbee-herdsman:adapter:ezsp:uart --> ACK  (7)
2023-01-13T21:05:42.524Z zigbee-herdsman:adapter:ezsp:uart --> [87009f7e]
2023-01-13T21:05:42.524Z zigbee-herdsman:adapter:ezsp:ezsp <== Frame: fb9001c4000d0000
2023-01-13T21:05:42.524Z zigbee-herdsman:adapter:ezsp:uart Error while parsing to ZpiObject 'RangeError: Attempt to access memory outside buffer bounds
    at new NodeError (node:internal/errors:387:5)
    at boundsError (node:internal/buffer:84:11)
    at Buffer.readUInt16LE (node:internal/buffer:243:5)
    at Buffer.readUIntLE (node:internal/buffer:180:17)
    at Function.deserialize (/app/node_modules/zigbee-herdsman/src/adapter/ezsp/driver/types/basic.ts:19:67)
    at new EZSPFrameData (/app/node_modules/zigbee-herdsman/src/adapter/ezsp/driver/ezsp.ts:83:54)
    at Ezsp.onFrameReceived (/app/node_modules/zigbee-herdsman/src/adapter/ezsp/driver/ezsp.ts:294:21)
    at SerialDriver.emit (node:events:513:28)
    at SerialDriver.handleDATA (/app/node_modules/zigbee-herdsman/src/adapter/ezsp/driver/uart.ts:228:14)
    at SerialDriver.onParsed (/app/node_modules/zigbee-herdsman/src/adapter/ezsp/driver/uart.ts:175:22)'
2023-01-13T21:05:49.068Z zigbee-herdsman:adapter:ezsp:ezsp Time to watchdog ... 0

Any ideas how to fix it?

[Hedda]

@grambas Report and ask in Koenkk/zigbee-herdsman#319

[yayitazale]

Hi:

I am looking for the most powerful stick in terms of message processing capability as right now, my Slaesh's CC2652RB stick gets saturated at times and slows down the system a lot.

Is there any improvement by switching to an EZSP-based stick? Is there a table somewhere where I can see which is the most powerful chip in this regard?

Thanks

[Hedda]

By the way, also check out the other Sonoff dongle -> #8840

[Hedda]

By the way, I bought some months ago one of this https://www.nordicsemi.com/Products/nRF52840 to start tinkering with OpenThread that I'm not using yet, is this usable with Z2M?

No, at least not for anything other than a DIY "Zigbee Router" device or a DIY "Zigbee End Device" if you write a converter for Z2M.

Zigbee2MQTT depends on zigbee-herdsman Zigbee framework as a hardware abstraction layer for different Zigbee stacks and so far it supports Zigbee Coordinator adapters based on Zigbee stacks from Texas Instruments, Silicon Labs, dedonz (ConBee/RaspBee), and ZiGate:

https://www.zigbee2mqtt.io/guide/adapters/

https://github.com/Koenkk/zigbee-herdsman

To be used as a Zigbee Coordinator then need an Zigbee stack abstraction layer in the form of adapter code in zigbee-herdsman:

https://github.com/Koenkk/zigbee-herdsman/tree/master/src/adapter

PS: OpenThread is a completely different story that is not really in scope for Zigbee2MQTT but Thread is discussed indirectly here:

#14497

#7443

[yayitazale]

ok thanks!

[MattWestb]

ZNP is limited how many Trust center Link Key it can storing for Zigbee 3 in the NVM and EZSP is using hashed TC-Link keys so its dont have that limit if you is going over some hundred Zigbee 3 devices ZNP cant handling it.

[yayitazale]

OK, I already have done most of the steps of the the best practises but the issues started when I added 6 tuya presence detectors that are very noisy but what I want to keep using as they are very practical.

Tip on a suggested workaround could be to set up another Zigbee network using a separate secondary Zigbee2MQTT instance with its own dedicated Zigbee Coordinator adapter (with a different MCU SoC manufacturer than your primary Zigbee2MQTT instance) and then move the devices that are giving you problems to that other Zigbee network to keep it separately from your main "production" Zigbee network.

It looks like updating the sticks hardware did the trick. Anyway, do you recommend to switch to next-generation MCU SoCs like the EFR32MG24 series when they become available?

[besanur]

I have flashed it with this instruction
https://smarthomescene.com/guides/how-to-enable-thread-and-matter-support-on-sonoff-zbdongle-e/

[Hedda]

FYI, ITead released official Zigbee NCP EmberZNet 7.3.3.0 + 7.4.3.0 firmware for Sonoff ZBDongle-E:

https://github.com/itead/Sonoff_Zigbee_Dongle_Firmware/tree/master/Dongle-E/

Note that you can report firmware specific issues for Sonoff ZBDongle-E direcly to ITead on GitHub:

https://github.com/itead/Sonoff_Zigbee_Dongle_Firmware/issues

Better late than never! 😀

[Loic691]

Hey
Great info
But for now, a lot of ours have already flashed their firmware whith 7.4.1 or 7.4.3.
Is it better to stay on these firmware or may we have to switch to itead firmware ?
Is it the same working mode with Ember ?