Tube's ZB Coordinators and Routers (was Zigbee router on steroids?)

try running universal-silabs-flasher without the probe-method. the bootloader needs to be manually pulled up for this method to work as it shouldn’t actually try any probing with that enabled. other wise the tool probes by sending ezsp and cpc/rpc commands to put the device into bootloader mode without physical intervention.

Hi, Iv’e just checked your recommentation without success :frowning:
Gateway is set in this state:


and the universal-silabs-flasher throm me an error without --probe-method bootloader parameter

root@flasher:~# /usr/local/bin/universal-silabs-flasher -vv --device socket://172.16.80.11:6638   flash --force --firmware tubeszb-mgm21-2022_7.4.3.gbl
2024-09-11 08:10:07.280 flasher asyncio DEBUG Using selector: EpollSelector
2024-09-11 08:10:07.284 flasher universal_silabs_flasher.flash INFO Extracted GBL metadata: NabuCasaMetadata(metadata_version=1, sdk_version='4.4.3', ezsp_version='7.4.2.0', ot_rcp_version=None, fw_type=<FirmwareImageType.NCP_UART_HW: 'ncp-uart-hw'>, baudrate=115200)
2024-09-11 08:10:07.284 flasher universal_silabs_flasher.flash DEBUG Probing app type ApplicationType.EZSP first
2024-09-11 08:10:07.284 flasher universal_silabs_flasher.flash DEBUG Probing with 115200 baudrate first
2024-09-11 08:10:07.285 flasher universal_silabs_flasher.flasher INFO Probing ApplicationType.GECKO_BOOTLOADER at 115200 baud
2024-09-11 08:10:07.285 flasher zigpy.serial DEBUG Opening a serial connection to 'socket://172.16.80.11:6638' (115200 baudrate)
2024-09-11 08:10:07.287 flasher universal_silabs_flasher.common DEBUG Connection made: <_SelectorSocketTransport fd=3 read=idle write=<idle, bufsize=0>>
2024-09-11 08:10:07.287 flasher universal_silabs_flasher.common DEBUG Sending data b'\n'
2024-09-11 08:10:07.287 flasher universal_silabs_flasher.common DEBUG Sending data b'3'
2024-09-11 08:10:09.290 flasher universal_silabs_flasher.flasher INFO Probing ApplicationType.EZSP at 115200 baud
2024-09-11 08:10:09.291 flasher zigpy.serial DEBUG Opening a serial connection to 'socket://172.16.80.11:6638' (115200 baudrate)
Traceback (most recent call last):
  File "/usr/local/bin/universal-silabs-flasher", line 8, in <module>
    sys.exit(main())
             ^^^^^^
  File "/usr/local/lib/python3.11/dist-packages/click/core.py", line 1157, in __call__
    return self.main(*args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/dist-packages/click/core.py", line 1078, in main
    rv = self.invoke(ctx)
         ^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/dist-packages/click/core.py", line 1688, in invoke
    return _process_result(sub_ctx.command.invoke(sub_ctx))
                           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/dist-packages/click/core.py", line 1434, in invoke
    return ctx.invoke(self.callback, **ctx.params)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/dist-packages/click/core.py", line 783, in invoke
    return __callback(*args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/dist-packages/click/decorators.py", line 33, in new_func
    return f(get_current_context(), *args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/dist-packages/universal_silabs_flasher/flash.py", line 40, in inner
    return asyncio.run(f(*args, **kwargs))
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.11/asyncio/runners.py", line 190, in run
    return runner.run(main)
           ^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.11/asyncio/runners.py", line 118, in run
    return self._loop.run_until_complete(task)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.11/asyncio/base_events.py", line 653, in run_until_complete
    return future.result()
           ^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/dist-packages/universal_silabs_flasher/flash.py", line 341, in flash
    await flasher.probe_app_type()
  File "/usr/local/lib/python3.11/dist-packages/universal_silabs_flasher/flasher.py", line 200, in probe_app_type
    result = await probe_funcs[probe_method](baudrate=baudrate)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/dist-packages/universal_silabs_flasher/flasher.py", line 139, in probe_ezsp
    async with self._connect_ezsp(baudrate) as ezsp:
  File "/usr/lib/python3.11/contextlib.py", line 204, in __aenter__
    return await anext(self.gen)
           ^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/dist-packages/universal_silabs_flasher/emberznet.py", line 41, in connect_ezsp
    ezsp = await bellows.ezsp.EZSP.initialize(app_config)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/dist-packages/bellows/ezsp/__init__.py", line 136, in initialize
    await ezsp.startup_reset()
  File "/usr/local/lib/python3.11/dist-packages/bellows/ezsp/__init__.py", line 117, in startup_reset
    await self._gw.wait_for_startup_reset()
  File "/usr/local/lib/python3.11/dist-packages/bellows/uart.py", line 170, in wait_for_startup_reset
    await self._startup_reset_future
asyncio.exceptions.CancelledError

Is option Pull Bootloader pin (PA0) to Low pulling the right booloader pin ? ou said pull boolloader pin up, but descpription says pull low? So I’m a bit confused is this is the same bootloader pin you metioned.

So today I’ve recieved in HA update for Silicon Labs flasher (version 0.3.4.0 )
After that, I was able to flash Tubes gateway from 7.4.2 to 7.4.3 without any problems.

image

1 Like

Just to inform - my journey with 7.4.3 was short.
Z2M reports Transaction failures every couple on minutes on this version:


So i reverted back to 7.4.2 and everythins is fine again.
I need to dig on Z2M forums and search what is the couse oft this errors.

Hi, I have now excatly the same issue.
IP address is ok. WebUI working. As soon as I switch on Z2M I see new client connected and after some time client disconnected. In Z2M log I see:

[2024-09-17 20:21:17] error: z2m: Exiting…

[2024-09-17 20:21:17] error: z2m: Error: Failed to connect to the adapter (Error: SRSP - SYS - ping after 6000ms)

This is completely different.

Please try refashing the esp32 running the network side of you device over USB, if that fails to resolve re flash the coordinator firmware.

I was refering to the old post…

coordinator firmware re-flashed 2x already. Unfortunately did not help.
Unfortunetly the USB port is defective on my device so I do have power directly soldered on the board. It was working approx 1 year till it just stopped.
Also the device is 1000 km away from me. I have just remote access to locally runing PC over VPN… any other idea?

which device is this? that would help me, but without physical access options are very limited. are you able to fully power cycle it remotely?

it is tube_zb_gw_cc2652p2, tube_gateways/models/retired/tubeszb-cc2652-eth at main · tube0013/tube_gateways · GitHub

power cycle I have done already.


Just did try also with ZHA (z2m container off) and it is also not possible.

And one more update: I did OTA using webUI and then I did re-flash again using: CC1352P2_CC2652P_launchpad_coordinator_20240710

Still not wokrking

EDIT2:
working !!!
It was the jumper on the board. Probably lost contact - someone had to push the device out of the table…

1 Like

@tube0013

I have the tubeszb-cc2652p7-poe-2023 which was working up until the other day. I tried upgrading the firmware and now I can no longer get it to register with ZHA or Zigbee2MQTT.

| have tried flashing several times with [ESPHome] New Configuration Request · Issue #26 · tube0013/TubesZB-ESPHome-Builder · GitHub
I have flashed the 2652 several times with CC1352P2_CC2652P_launchpad_coordinator_20240710 (I also tried a previous version)

The debug log in ESP Home shows:

12:48:01|[D]|[stream_server:081]|New client connected from 192.168.1.200|
| --- | --- | --- | --- |
|12:48:01|[D]|[binary_sensor:036]|'TubesZB Serial Connected': Sending state ON|
|12:48:21|[D]|[stream_server:163]|Client 192.168.1.200 disconnected|
|12:48:21|[D]|[binary_sensor:036]|'TubesZB Serial Connected': Sending state OFF|

The Zigbee2MQtt shows (I’m trying z2m since it gives some output):

[2024-10-18 12:48:00] info: 	z2m: Logging to console, file (filename: log.log)
[2024-10-18 12:48:00] debug: 	z2m: Can't load state from file /app/data/state.json (doesn't exist)
[2024-10-18 12:48:00] info: 	z2m: Starting Zigbee2MQTT version 1.40.2 (commit #e06848d)
[2024-10-18 12:48:00] debug: 	z2m: sd-notify loaded
[2024-10-18 12:48:00] info: 	z2m: Starting zigbee-herdsman (2.1.3)
[2024-10-18 12:48:00] debug: 	z2m: Using zigbee-herdsman with settings: '"{\"network\":{\"panID\":6754,\"extendedPanID\":[221,221,221,221,221,221,221,221],\"channelList\":[11],\"networkKey\":\"HIDDEN\"},\"databasePath\":\"/app/data/database.db\",\"databaseBackupPath\":\"/app/data/database.db.backup\",\"backupPath\":\"/app/data/coordinator_backup.json\",\"serialPort\":{\"path\":\"tcp://192.168.40.243:6638\",\"adapter\":\"zstack\"},\"adapter\":{\"disableLED\":false}}"'
[2024-10-18 12:48:01] debug: 	zh:controller: Starting with options '{"network":{"networkKeyDistribute":false,"networkKey":"HIDDEN","panID":6754,"extendedPanID":[221,221,221,221,221,221,221,221],"channelList":[11]},"serialPort":{"path":"tcp://192.168.40.243:6638","adapter":"zstack"},"adapter":{"disableLED":false},"databasePath":"/app/data/database.db","databaseBackupPath":"/app/data/database.db.backup","backupPath":"/app/data/coordinator_backup.json"}'
[2024-10-18 12:48:01] info: 	zh:zstack:znp: Opening TCP socket with 192.168.40.243:6638
[2024-10-18 12:48:02] info: 	zh:zstack:znp: Socket connected
[2024-10-18 12:48:02] info: 	zh:zstack:znp: Socket ready
[2024-10-18 12:48:02] info: 	zh:zstack:znp: Writing CC2530/CC2531 skip bootloader payload
[2024-10-18 12:48:02] debug: 	zh:zstack:unpi:writer: --> buffer [239]
[2024-10-18 12:48:03] info: 	zh:zstack:znp: Skip bootloader for CC2652/CC1352
[2024-10-18 12:48:03] debug: 	zh:zstack:znp: --> SREQ: SYS - ping - {"capabilities":1}
[2024-10-18 12:48:03] debug: 	zh:zstack:unpi:writer: --> frame [254,0,33,1,32]
[2024-10-18 12:48:09] debug: 	zh:zstack:znp: --> SREQ: SYS - ping - {"capabilities":1}
[2024-10-18 12:48:09] debug: 	zh:zstack:unpi:writer: --> frame [254,0,33,1,32]
[2024-10-18 12:48:15] debug: 	zh:zstack:znp: --> SREQ: SYS - ping - {"capabilities":1}
[2024-10-18 12:48:15] debug: 	zh:zstack:unpi:writer: --> frame [254,0,33,1,32]
[2024-10-18 12:48:21] error: 	z2m: Error while starting zigbee-herdsman
[2024-10-18 12:48:21] error: 	z2m: Failed to start zigbee
[2024-10-18 12:48:21] error: 	z2m: Check https://www.zigbee2mqtt.io/guide/installation/20_zigbee2mqtt-fails-to-start.html for possible solutions
[2024-10-18 12:48:21] error: 	z2m: Exiting...
[2024-10-18 12:48:21] error: 	z2m: 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:113:27)
    at Controller.start (/app/node_modules/zigbee-herdsman/src/controller/controller.ts:137:29)
    at Zigbee.start (/app/lib/zigbee.ts:69:27)
    at Controller.start (/app/lib/controller.ts:161:27)
    at start (/app/index.js:154:5)

Is there anything else I can do to troubleshoot? Thanks!

It looks like the firmware I actually wanted was CC1352P7_coordinator_20240710.hex

I’m still having some issues but I’ve gotten a lot further.

1 Like

what happens with ZHA?

Can you try running an energy scan with zigpy-cli command line or my addon?

If you have flashed new firmware you will need to form network before it can do the scan.

But the fact that you can successfully flash the coordinator firmware means it’s working over the tcp serial connection.

I managed to get things working. With ZHA (once I had the correct firmware), I told it to form a new network. ZHA would eventually show an Error. I didn’t notice the first few times but it had added the tubeszb as a coordinator. I was able to then re-pair my zigbee devices.

1 Like

I’ve got a tubeszb-cc2652p7-poe-2023 and it keeps dropping off the network. The lights are still on, but it’s not reachable via IP. The switch port (Cisco 3850) shows no errors. Doing a shut/no shut brings it right back up.

I can automate detection/resolution of course, or set up a nightly PoE reboot, but if there’s a way to prevent this, I’m all ears.

Z2M logs:

[12:35:05] INFO: Preparing to start...
[12:35:05] INFO: Socat not enabled
[12:35:06] INFO: Starting Zigbee2MQTT...
Starting Zigbee2MQTT without watchdog.
[2024-10-28 12:35:07] info: 	z2m: Logging to console, file (filename: log.log)
[2024-10-28 12:35:07] info: 	z2m: Starting Zigbee2MQTT version 1.40.2 (commit #unknown)
[2024-10-28 12:35:07] info: 	z2m: Starting zigbee-herdsman (2.1.3)
[2024-10-28 12:35:08] info: 	zh:zstack:znp: Opening TCP socket with 10.13.15.65:6638
[2024-10-28 12:35:34] info: 	zh:zstack:znp: Socket error
[2024-10-28 12:35:34] error: 	z2m: Error while starting zigbee-herdsman
[2024-10-28 12:35:34] error: 	z2m: Failed to start zigbee
[2024-10-28 12:35:34] error: 	z2m: Check https://www.zigbee2mqtt.io/guide/installation/20_zigbee2mqtt-fails-to-start.html for possible solutions
[2024-10-28 12:35:34] error: 	z2m: Exiting...
[2024-10-28 12:35:34] error: 	z2m: Error: Error while opening socket
    at Socket.<anonymous> (/app/node_modules/zigbee-herdsman/src/adapter/z-stack/znp/znp.ts:166:24)
    at Socket.emit (node:events:529:35)
    at emitErrorNT (node:internal/streams/destroy:151:8)
    at emitErrorCloseNT (node:internal/streams/destroy:116:3)
    at processTicksAndRejections (node:internal/process/task_queues:82:21)

/app/node_modules/winston/node_modules/readable-stream/lib/_stream_writable.js:264
  var er = new ERR_STREAM_WRITE_AFTER_END();
           ^
Error: write after end
    at writeAfterEnd (/app/node_modules/winston/node_modules/readable-stream/lib/_stream_writable.js:264:12)
    at DerivedLogger.Writable.write (/app/node_modules/winston/node_modules/readable-stream/lib/_stream_writable.js:300:21)
    at DerivedLogger.log (/app/node_modules/winston/lib/winston/logger.js:231:12)
    at Logger.log (/app/lib/util/logger.ts:198:25)
    at Logger.info (/app/lib/util/logger.ts:211:14)
    at Znp.onPortClose (/app/node_modules/zigbee-herdsman/src/adapter/z-stack/znp/znp.ts:96:16)
    at Object.onceWrapper (node:events:632:26)
    at Socket.emit (node:events:517:28)
    at TCP.<anonymous> (node:net:350:12)

Can you try a static ip build of ESPHome? What are you using for a router for your network? Devices dropping off every few hours is know to be an issue with pfsense for example. Using static ip solves that.

It’s the latest rev of OPNSense. Only thing on my network that has a static IP is OPNSense and my switch management interfaces. The other 150+ devices, including 13 ESPHome devices, don’t exhibit this behavior using DHCP reservations.

That said, I’ll give the static build a try. Brilliant use of GitHub actions! =)

thanks, let me know if it makes a difference.

I got tired of building one off firmware builds. Used some back and forth with chatgpt to create the action.

Now we’re in a loop.

The firmware flash seemed to go well:

% ./cc2538-bsl.py -p socket://10.13.15.65:6638 -evw CC1352P2_CC2652P_launchpad_coordinator_20240710.hex
Opening port socket://10.13.15.65:6638, baud 500000
Reading data from CC1352P2_CC2652P_launchpad_coordinator_20240710.hex
Your firmware looks like an Intel Hex file
Connecting to target...
CC1350 PG2.0 (7x7mm): 704KB Flash, 20KB SRAM, CCFG.BL_CONFIG at 0x000AFFD8
Primary IEEE Address: 00:12:4B:00:2E:0E:1F:03
    Performing mass erase
Erasing all main bank flash sectors
    Erase done
Writing 360448 bytes starting at address 0x00000000
Write 104 bytes at 0x00057F988
    Write done
Verifying by comparing CRC32 calculations.
    Verified (match: 0xd9dd0124)

Here’s what I see from the TubesZB web interface:

15:16:41	[D]	[stream_server:081]	New client connected from 10.13.13.22
15:16:41	[D]	[binary_sensor:036]	'TubesZB Serial Connected': Sending state ON
15:17:00	[D]	[stream_server:163]	Client 10.13.13.22 disconnected
15:17:00	[D]	[binary_sensor:036]	'TubesZB Serial Connected': Sending state OFF
15:17:03	[D]	[stream_server:081]	New client connected from 10.13.13.22
15:17:03	[D]	[binary_sensor:036]	'TubesZB Serial Connected': Sending state ON
15:17:22	[D]	[stream_server:163]	Client 10.13.13.22 disconnected
15:17:22	[D]	[binary_sensor:036]	'TubesZB Serial Connected': Sending state OFF

This is what shows in the Z2M logs repeatedly:

[15:14:27] INFO: Preparing to start...
[15:14:27] INFO: Socat not enabled
[15:14:27] INFO: Starting Zigbee2MQTT...
Starting Zigbee2MQTT without watchdog.
[2024-10-28 15:14:29] info: 	z2m: Logging to console, file (filename: log.log)
[2024-10-28 15:14:29] info: 	z2m: Starting Zigbee2MQTT version 1.40.2 (commit #unknown)
[2024-10-28 15:14:29] info: 	z2m: Starting zigbee-herdsman (2.1.3)
[2024-10-28 15:14:29] info: 	zh:zstack:znp: Opening TCP socket with 10.13.15.65:6638
[2024-10-28 15:14:29] info: 	zh:zstack:znp: Socket connected
[2024-10-28 15:14:29] info: 	zh:zstack:znp: Socket ready
[2024-10-28 15:14:29] info: 	zh:zstack:znp: Writing CC2530/CC2531 skip bootloader payload
[2024-10-28 15:14:30] info: 	zh:zstack:znp: Skip bootloader for CC2652/CC1352
[2024-10-28 15:14:48] error: 	z2m: Error while starting zigbee-herdsman
[2024-10-28 15:14:48] error: 	z2m: Failed to start zigbee
[2024-10-28 15:14:48] error: 	z2m: Check https://www.zigbee2mqtt.io/guide/installation/20_zigbee2mqtt-fails-to-start.html for possible solutions
[2024-10-28 15:14:48] error: 	z2m: Exiting...
[2024-10-28 15:14:48] error: 	z2m: 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:113:27)
    at Controller.start (/app/node_modules/zigbee-herdsman/src/controller/controller.ts:137:29)
    at Zigbee.start (/app/lib/zigbee.ts:69:27)
    at Controller.start (/app/lib/controller.ts:161:27)
    at start (/app/index.js:154:5)
[15:14:49] INFO: Preparing to start...

I’ve verified that I can get to the TubesZB device on 80 and 6638 from the box HA is running on. Z2M config is as shown below.