My apologies, the CC2652 is Texas instruments, not Silicon Labs.
I’m eyeing those EFR32 based hubs. Moving to a new place soon that doesnt have any ethernet routing, so i’m eyeing USB adaptors until I can get cabling done (wont be for 6+ months)
Im told that we flashing of ti cc2652 is just a bug fix away with one of the backend packages.
Web flashing to local network devices may be an issue due to web browser security. We’ll see. The command line flasher is not bad.
1 Like
Trying my best to follow along, so forgive me if this has already been answered.
Do either the EFR32 or CC2652 support OpenThread with the current firmware? I’m not worried about concurrent mode, but do have some thread devices I’d like to get into HA as soon as this part is stable. I also would like to use a POE version if that matters.
Current fw is zigbee only. I am working on Thread Firmware for both.
And both currently will require a update via command line tools.
2 Likes
Hi all,
I’ve got the cc2652p2 adapter in use. Unfortunately, zigbee2mqtt is working unreliabely and often the adapter cannot be connected:
info 2023-02-12 13:20:37: Logging to console and directory: '/config/zigbee2mqtt/log/2023-02-12.13-20-37' filename: log.txt
info 2023-02-12 13:20:37: Starting Zigbee2MQTT version 1.30.1 (commit #unknown)
info 2023-02-12 13:20:37: Starting zigbee-herdsman (0.14.89)
error 2023-02-12 13:20:57: Error while starting zigbee-herdsman
error 2023-02-12 13:20:57: Failed to start zigbee
error 2023-02-12 13:20:57: Check https://www.zigbee2mqtt.io/guide/installation/20_zigbee2mqtt-fails-to-start.html for possible solutions
error 2023-02-12 13:20:57: Exiting...
error 2023-02-12 13:20:57: Error: Failed to connect to the adapter (Error: SRSP - SYS - ping after 6000ms)
at ZStackAdapter.start (/app/node_modules/zigbee-herdsman/src/adapter/z-stack/adapter/zStackAdapter.ts:103:27)
at Controller.start (/app/node_modules/zigbee-herdsman/src/controller/controller.ts:132:29)
at Zigbee.start (/app/lib/zigbee.ts:58:27)
at Controller.start (/app/lib/controller.ts:101:27)
at start (/app/index.js:107:5)
My configuration.yaml:
homeassistant: true
mqtt:
server: mqtt://core-mosquitto:1883
user: hassio
password: ###
serial:
port: tcp://192.168.0.50:6638
frontend:
port: 8099
advanced:
homeassistant_legacy_entity_attributes: false
legacy_api: false
legacy_availability_payload: false
device_options:
legacy: false
permit_join: true
devices:
#...
After seeing several connects/disconnects on the GUI from HA of the coordinator, the addon stops.
We then went outside and after 2 hours not being touched, I gave it another try and started it and…
debug 2023-02-12 16:55:08: Loaded state from file /config/zigbee2mqtt/state.json
info 2023-02-12 16:55:08: Logging to console and directory: '/config/zigbee2mqtt/log/2023-02-12.16-55-08' filename: log.txt
debug 2023-02-12 16:55:08: Removing old log directory '/config/zigbee2mqtt/log/2023-02-12.12-58-57'
info 2023-02-12 16:55:08: Starting Zigbee2MQTT version 1.30.1 (commit #unknown)
info 2023-02-12 16:55:08: Starting zigbee-herdsman (0.14.89)
debug 2023-02-12 16:55:08: Using zigbee-herdsman with settings: '{"adapter":{"concurrent":null,"delay":null,"disableLED":false},"backupPath":"/config/zigbee2mqtt/coordinator_backup.json","databaseBackupPath":"/config/zigbee2mqtt/database.db.backup","databasePath":"/config/zigbee2mqtt/database.db","network":{"channelList":[11],"extendedPanID":[221,221,221,221,221,221,221,221],"networkKey":"HIDDEN","panID":6754},"serialPort":{"path":"tcp://192.168.0.50:6638"}}'
info 2023-02-12 16:55:16: zigbee-herdsman started (resumed)
info 2023-02-12 16:55:16: Coordinator firmware version: '{"meta":{"maintrel":1,"majorrel":2,"minorrel":7,"product":1,"revision":20220219,"transportrev":2},"type":"zStack3x0"}'
debug 2023-02-12 16:55:16: Zigbee network parameters: {"channel":11,"extendedPanID":"0x00124b002a2eb892","panID":6754}
info 2023-02-12 16:55:16: Currently 16 devices are joined:
What could the cause be? This coordinator never has been used by ZHA, although ZHA has been used in the past with deCONZ.
I wish I new what was the cause of that error. which specific model cc2652 do you have?
the most reliable way to solve this is doing a complete reflash of the esphome fw over serial so that the entire flash is erased first.
Oooh, excellent. Looking forward to it. (despite me having zero thread devices)
I’m going to reflash today because I’m running into those problems again 
now it’s stuck even after a reboot of Home Assistant
debug 2023-02-14 12:41:51: Loaded state from file /config/zigbee2mqtt/state.json
info 2023-02-14 12:41:51: Logging to console and directory: '/config/zigbee2mqtt/log/2023-02-14.12-41-51' filename: log.txt
debug 2023-02-14 12:41:51: Removing old log directory '/config/zigbee2mqtt/log/2023-02-12.13-01-36'
info 2023-02-14 12:41:51: Starting Zigbee2MQTT version 1.30.1 (commit #unknown)
info 2023-02-14 12:41:51: Starting zigbee-herdsman (0.14.89)
debug 2023-02-14 12:41:51: Using zigbee-herdsman with settings: '{"adapter":{"concurrent":null,"delay":null,"disableLED":false},"backupPath":"/config/zigbee2mqtt/coordinator_backup.json","databaseBackupPath":"/config/zigbee2mqtt/database.db.backup","databasePath":"/config/zigbee2mqtt/database.db","network":{"channelList":[11],"extendedPanID":[221,221,221,221,221,221,221,221],"networkKey":"HIDDEN","panID":6754},"serialPort":{"adapter":"ezsp","path":"tcp://192.168.0.50:6638"}}'
debug 2023-02-14 12:46:51: Saving state to file /config/zigbee2mqtt/state.json
Is this a TI CC2652 or EFR32 coordinator?
The sys ping error is cc2652 only the but above mentions ezsp. 
CC2652P2 based Zigbee to Ethernet/USB Serial Coordinator
Any suggestions? Sorry if I missed something
looks like you have ezsp defined in the above output you posted:
I’d remove the adaptor line first and try if still doesn’t work then move to the esp32 re-flash I originally recommended.
Which I did now… I will reflash today and report. 
I just tried to flash the cc2652p2 coordinator and this is what I get when I tried to do that.
python c:\temp\cc2538-bsl-master\cc2538-bsl.py -p socket://192.168.X.Y:6638 c:\temp\CC1352P2_CC2652P_launchpad_coordinator_20221226.hex
Opening port socket://192.168.X.Y:6638, baud 500000
Connecting to target...
CC1350 PG2.0 (7x7mm): 352KB Flash, 20KB SRAM, CCFG.BL_CONFIG at 0x00057FD8
Primary IEEE Address: 00:12:4B:00:2A:2E:B8:92
I’m missing a confirmation like stated in the doc
Verifying by comparing CRC32 calculations.
Verified (match: 0xddfc152d)
How can I make sure that the update worked and how can I read out the current fw version?
It is only reading the device, you need to put the commands to flash it in
cc2538-bsl.py -p socket://IP:6638 -evw path_to_firmware_file
pip install intelhex
1 Like
Can the EFR32 ethernet adaptor support ZigBee and thread at the same time (same as the skyconnect) with a firmware update?
Edit: or, what about an ethernet to USB adaptor? So we could plug whatever ZigBee USB stick we have into the adaptor?
The efr32 chips are compatible with the multiprocol rcp firmware for zigbee thread.
I’m also keeping my eye on this branch in Silicon Lab’s fork of OpenThread, as I believe if it is added to upstream openthread it will allow multiprotocol rcp on other chips like nordic and TI. (I could be horribly wrong) but they all currently support rcp firmware for thread, and the multiprotocol stuff from SiLabs just tags the packets to then get directed by the cpc daemon to thread or a host based zigbee ncp called zigbeed. And this branch seems to add that to the main OpenThread.
There was a PR in OpenThread for this support over a year ago but it wasn’t kept up to date and was closed saying they would resubmit after it was brought up-to-date, which seems to be what this branch is doing.
Sorry, for my understanding, if this update was to be progressed, it would allow ZigBee and Thread concurrently on existing TI chips (such as the CC2652)? If so that would be great and anyone with your CC2652 ethernet adaptors can use thread with a firmware update.
That is my hope, but there maybe some caveats.
As it is now the CC2652 can run a RCP FW that works with Thread only.
The caveat being the rcp firmware is really just pushing raw packets to a host in a standard format. and since the multiprotocal stuff is done by SiLabs, zigbeed is an ezsp ncp firmware running on the host. So not great for Z2M users, which is best paired with z-stack firmware.