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

2026getgib · February 4, 2024, 6:54pm

Dude! Excellent, I haven’t tried that FW. in that github there are lots of files 20230507 and I grabbed the first one. damn.

So while you’re online, when this is done updating the FW, do you know what the mqtt configuration should be in HA Zigbee2MQTT…

server: mqtt://core-mosquitto
user: mqtt-user
password: “password”

2026getgib · February 4, 2024, 7:04pm

Awesome, I’m up and running now.

FYI - the paper that came with the coordinator had 20221226 launchpad as what was pre-flashed. I don’t know what was actually on the device. The main page for the P7 should specifically say CC1352P7_coordinator_20230507.zip because the link goes to the bin full of 20230507’s … THANK YOU for being so helpful on here.

liyanage · February 5, 2024, 11:18pm

This thread seemed most relevant but please let me know if I should start a new one.

I just got one of the TubesZB PoE adapters, the “CC2652 P7 Based Zigbee to PoE Coordinator 2023” one.

I am trying to get it set up with Z2M and I am not having any luck. In the Z2M logs it always fails like this:

2024-02-05T23:01:06.779Z zigbee-herdsman:controller:log Starting with options '{"network":{"networkKeyDistribute":false,"networkKey":[220,244,213,95,137,77,231,226,132,15,138,222,109,127,226,36],"panID":28825,"extendedPanID":[176,66,41,155,232,77,219,31],"channelList":[11]},"serialPort":{"path":"tcp://192.168.20.27:6638","adapter":"ezsp"},"databasePath":"/config/zigbee2mqtt/database.db","databaseBackupPath":"/config/zigbee2mqtt/database.db.backup","backupPath":"/config/zigbee2mqtt/coordinator_backup.json","adapter":{"disableLED":false,"concurrent":null,"delay":null}}'
2024-02-05T23:01:06.781Z zigbee-herdsman:adapter:ezsp:uart Opening TCP socket with 192.168.20.27:6638
2024-02-05T23:01:06.789Z zigbee-herdsman:adapter:ezsp:uart Socket connected
2024-02-05T23:01:06.790Z zigbee-herdsman:adapter:ezsp:uart Socket ready
2024-02-05T23:01:06.790Z zigbee-herdsman:adapter:ezsp:uart Uart reseting
2024-02-05T23:01:06.790Z zigbee-herdsman:adapter:ezsp:uart --> Write reset
2024-02-05T23:01:06.791Z zigbee-herdsman:adapter:ezsp:uart --> [1ac038bc7e]
2024-02-05T23:01:06.792Z zigbee-herdsman:adapter:ezsp:uart -?- waiting reset
2024-02-05T23:01:16.800Z zigbee-herdsman:adapter:ezsp:uart --> Error: Error: {"sequence":-1} after 10000ms
Error: Reset error: Error: {"sequence":-1} after 10000ms
    at /app/node_modules/zigbee-herdsman/src/adapter/ezsp/driver/uart.ts:323:23
    at Queue.execute (/app/node_modules/zigbee-herdsman/src/utils/queue.ts:35:20)
    at Socket.<anonymous> (/app/node_modules/zigbee-herdsman/src/adapter/ezsp/driver/uart.ts:152:17)

On the TubesZB side in its log in the web UI I just see a series of:

15:00:50	New client connected from 192.168.20.28
15:00:50	TubesZB Serial Connected': Sending state ON
15:01:00	Client 192.168.20.28 disconnected
15:01:00	TubesZB Serial Connected': Sending state OFF
15:01:06	New client connected from 192.168.20.28
15:01:06	TubesZB Serial Connected': Sending state ON
15:01:16	Client 192.168.20.28 disconnected
15:01:16	TubesZB Serial Connected': Sending state OFF

FWIW, I was able to successfully flash the Zigbee module firmware from within HA using the TubesZB flasher add-on, so the network connection seems to be fine. I flashed the CC1352P7_coordinator_20230507.zip firmware, hoping that would help.

I separately also successfully flashed the ESPHome firmware using a MicroUSB cable.

Both of those firmware updates happened after I first tried to set it up out of the box. So it didn’t work either before or after the firmware update. The error in the Z2M logs is always that same one, Error: Error: {"sequence":-1} after 10000ms.

Any ideas what I can try next?

tube0013 · February 5, 2024, 11:33pm

Looks like you have the ezsp parameter in your z2m config. Remove that and it should work

liyanage · February 6, 2024, 3:18am

Oh interesting! I did not notice that and I’m a bit surprised, because in the HA Z2M config web UI, I cleared out the adapter: ezsp line when I switched from a USB dongle to the PoE one.

I’m surprised that it is still using it. All I have left in the serial section is:

port: tcp://192.168.20.27:6638

I will try to clear that out more thoroughly. Thank you for your super quick help!

liyanage · February 6, 2024, 4:57am

I double checked that the adapter: line was not present in the config. I had to add it back in with a different value:

adapter: zstack

Now Z2M is starting up and communicating with the network adapter successfully.

Thanks again for the tip!

parallelsys · February 20, 2024, 4:16am

Hello New to TubesZB

I own TubesZB CC2652P7.

Is there an order to update the firmwares?
Can you update the Esp32 board without updating the zigbee side?

Any side effects of updating the esp or zigbee?

Thanks!

tbhova · February 28, 2024, 4:31am

TLDR how can I tell if my CC2652P2 chip is dead? If the chip is dead, is the CC2652P7 a solder-able replacement on the 2022 UEXT board?

The Olimex on my “CC2652P2 Based Zigbee to PoE Coordinator 2022” recently died (not on the network, not recognized as a USB COM device).

The latest ESPHome firmware for 2022 board flashed to a new ESP32-POE-ISO (didn’t mean to order the ISO, but it should work) and the TubesZB web UI works.

I can’t add the device to ZHA (starting from scratch).

The HA logs look like (I have a download too):

2024-02-27 20:09:36.114 DEBUG (MainThread) [zigpy_znp.uart] Connecting to socket://192.168.1.121:6638 at 115200 baud
2024-02-27 20:09:36.114 DEBUG (MainThread) [zigpy.serial] Opening a serial connection to 'socket://192.168.1.121:6638' (115200 baudrate)
2024-02-27 20:09:41.114 DEBUG (MainThread) [zigpy_znp.api] Connection to socket://192.168.1.121:6638 failed, cleaning up
2024-02-27 20:10:08.398 DEBUG (MainThread) [zigpy_znp.uart] Connecting to socket://192.168.1.121:6638 at 115200 baud
2024-02-27 20:10:08.399 DEBUG (MainThread) [zigpy.serial] Opening a serial connection to 'socket://192.168.1.121:6638' (115200 baudrate)
2024-02-27 20:10:13.399 DEBUG (MainThread) [zigpy_znp.api] Connection to socket://192.168.1.121:6638 failed, cleaning up

The TubesZB UI logs look like:

20:05:00	[D]	[streamserver:074]	
New client connected from 192.168.2.252
20:05:00	[D]	[binary_sensor:036]	
'TubesZB Serial Connected': Sending state ON
20:05:05	[D]	[streamserver:102]	
Client 192.168.2.252 disconnected
20:05:05	[D]	[binary_sensor:036]	
'TubesZB Serial Connected': Sending state OFF

I’m also unable to update with cc2538-bsl.py and receive the error ERROR: Timeout waiting for ACK/NACK after 'Synch (0x55 0x55)'

tube0013 · February 28, 2024, 12:01pm

Which ESPHome yaml did you flash? There were pin changes between 2022 and 2023. That’s the only thing I can think of that could cause issues like you see unless there are hardware issue. I do t recall an instance where the cc2652 module died.

Can work out a replacement zigbee module with which ever radio you want - email me at store @ TubesZB.com for that.

Thanks

tbhova · February 29, 2024, 4:59am

Which ESPHome yaml did you flash?

Good question!

This is the YAML:

substitutions:
  name: "tubeszb-cc2652-poe-2022"
packages:
  tubezb.cc2652-poe-2023: github://tube0013/tube_gateways/models/current/tubeszb-cc2652-poe-2023/firmware/esphome/tubeszb-cc2652-poe-2023.yaml
esphome:
  name: ${name}
  name_add_mac_suffix: false
api:
  encryption:
    key: <redacted>

My original order was for 1/1/23 for a “CC2652P2 Based Zigbee to PoE Coordinator 2022”, so I assume this is correct.

That’s the only thing I can think of that could cause issues like you see unless there are hardware issue.

Yep! I already diffed the '22 and '23 yamls and also saw that.
I also diffed the POE and POE-ISO board and the only difference is 0.33A vs 0.5A max on the 3.3V rail. Both seem like plenty for the sub 100ma draw of the CC2652

Can work out a replacement zigbee module with which ever radio you want - email me

This would be awesome! Will do!

tbhova · March 7, 2024, 3:44am

Quick update for everyone. Everything’s working again - even with the POE ISO Olimex.

I bought a replacement UEXT radio board from Tubes. The board has a P4 radio and the silkscreen indicates a different pinout.

I switched my ESPHome entity name from tubeszb-cc2652-poe-2022 to tubeszb-cc2652-poe-2023 and amazingly ESPHome even rewrote the script to point at the correct GitHub YAML.

I’m going to blame recent bad weather and brownouts on killing the boards.

The POE ISO board is longer than the non-ISO board, I’m going to try printing/making a case. If I get something I like, I’ll be sure to share it here!

tube0013 · March 7, 2024, 1:27pm

There are fusion360 and step files up on GitHub:

The fusion360 version is has variables you can change for length, width and height to chance the case size.

MnM · March 28, 2024, 5:58pm

hi @tube0013 - I have received the tubeszb-mgm24 and I wanted to give it a test today.
However, I can not make it work with ZHA.

HomeAssistant sees it but I cannot add it at all. I get this error:

On the ESP side I see this:

A probe of the device shows this:

D:\Sonoff-E>universal-silabs-flasher.exe --device socket://172.50.255.193:6638 probe
2024-03-29 01:48:55.142 ODIN universal_silabs_flasher.flasher INFO Probing ApplicationType.GECKO_BOOTLOADER at 115200 baud
2024-03-29 01:48:57.156 ODIN universal_silabs_flasher.flasher INFO Probing ApplicationType.CPC at 460800 baud
2024-03-29 01:49:01.515 ODIN universal_silabs_flasher.flasher INFO Probing ApplicationType.CPC at 115200 baud
2024-03-29 01:49:05.890 ODIN universal_silabs_flasher.flasher INFO Probing ApplicationType.CPC at 230400 baud
2024-03-29 01:49:10.271 ODIN universal_silabs_flasher.flasher INFO Probing ApplicationType.EZSP at 115200 baud
2024-03-29 01:49:15.666 ODIN universal_silabs_flasher.flasher INFO Detected ApplicationType.EZSP, version '7.4.1.0 build 0' (7.4.1.0.0) at 115200 baudrate (bootloader baudrate None)
2024-03-29 01:49:15.666 ODIN universal_silabs_flasher.flash INFO Dumping EmberZNet Config
CONFIG_PACKET_BUFFER_COUNT=255
CONFIG_NEIGHBOR_TABLE_SIZE=26
CONFIG_APS_UNICAST_MESSAGE_COUNT=20
CONFIG_BINDING_TABLE_SIZE=32
CONFIG_ADDRESS_TABLE_SIZE=16
CONFIG_MULTICAST_TABLE_SIZE=16
CONFIG_ROUTE_TABLE_SIZE=16
CONFIG_DISCOVERY_TABLE_SIZE=8
CONFIG_STACK_PROFILE=0
CONFIG_SECURITY_LEVEL=5
CONFIG_MAX_HOPS=30
CONFIG_MAX_END_DEVICE_CHILDREN=32
CONFIG_INDIRECT_TRANSMISSION_TIMEOUT=3000
CONFIG_END_DEVICE_POLL_TIMEOUT=8
CONFIG_TX_POWER_MODE=0
CONFIG_DISABLE_RELAY=0
CONFIG_TRUST_CENTER_ADDRESS_CACHE_SIZE=0
CONFIG_SOURCE_ROUTE_TABLE_SIZE=254
CONFIG_FRAGMENT_WINDOW_SIZE=1
CONFIG_FRAGMENT_DELAY_MS=0
CONFIG_KEY_TABLE_SIZE=12
CONFIG_APS_ACK_TIMEOUT=1600
CONFIG_ACTIVE_SCAN_DURATION=3
CONFIG_PAN_ID_CONFLICT_REPORT_THRESHOLD=2
CONFIG_REQUEST_KEY_TIMEOUT=0
CONFIG_APPLICATION_ZDO_FLAGS=0
CONFIG_BROADCAST_TABLE_SIZE=30
CONFIG_MAC_FILTER_TABLE_SIZE=15
CONFIG_SUPPORTED_NETWORKS=1
CONFIG_SEND_MULTICASTS_TO_SLEEPY_ADDRESS=0
CONFIG_ZLL_GROUP_ADDRESSES=0
CONFIG_ZLL_RSSI_THRESHOLD=216
CONFIG_MTORR_FLOW_CONTROL=1
CONFIG_RETRY_QUEUE_SIZE=16
CONFIG_NEW_BROADCAST_ENTRY_THRESHOLD=24
CONFIG_TRANSIENT_KEY_TIMEOUT_S=300
CONFIG_BROADCAST_MIN_ACKS_NEEDED=255
CONFIG_TC_REJOINS_USING_WELL_KNOWN_KEY_TIMEOUT_S=300
CONFIG_CTUNE_VALUE=92
CONFIG_ASSUME_TC_CONCENTRATOR_TYPE=1
CONFIG_GP_PROXY_TABLE_SIZE=5
EZSP_CONFIG_GP_SINK_TABLE_SIZE=0

So the device seems to be there but I cant use it.
Would you have any pointers on how to:

Upload the new ESPHome firmware to it (current firmware does not have an OTA option)
How to re-upload the latest zigbee firmware to it (7.4.1)
And finally how get it going with ZHA? (I have no other ZHA devices in HA)

Thanks

tube0013 · April 1, 2024, 7:52pm

Can you enable zha debug logging - likely will need to add to configuration.yaml if zha is not already configured, and try and add again, so I can see the log output.

The probe succeeds so all should be good with the coordinator.

MnM · April 2, 2024, 4:37pm

Hi - thanks for getting back to me.
I think ZHA has some issues on my install. I have started a new zigbee network in z2m now.
So far soo good - and yes the coordinator was fine, nothing wrong with it.

Any idea when you will be releasing new ESPHome firmware for it that will support OTA?

tube0013 · April 2, 2024, 4:49pm

you can adopt it and flash OTA. It’s running the ESP32-IDF platform, so there is no OTA through the web with it.

MnM · April 3, 2024, 1:57pm

@tube0013 - Thanks.

So I got it going with zigbee2mqtt however the ESPHome page is constantly displaying this:

21:45:46 | [E] | [stream_server:145] | Failed to write to client 172.50.255.252 with error 128!
21:45:46 | [W] | [stream_server:168] | Failed to read from client 172.50.255.252 with error 128!
21:45:46 | [E] | [stream_server:145] | Failed to write to client 172.50.255.252 with error 128!
21:45:46 | [W] | [stream_server:168] | Failed to read from client 172.50.255.252 with error 128!
21:45:46 | [E] | [stream_server:104] | Incoming bytes available, but outgoing buffer is full: stream will be corrupted!

21:49:05 | [E] | [stream_server:145] | Failed to write to client 172.50.255.252 with error 128!
21:49:05 | [W] | [stream_server:168] | Failed to read from client 172.50.255.252 with error 128!
21:49:05 | [E] | [stream_server:145] | Failed to write to client 172.50.255.252 with error 128!
21:49:05 | [W] | [stream_server:168] | Failed to read from client 172.50.255.252 with error 128!
21:49:05 | [E] | [stream_server:145] | Failed to write to client 172.50.255.252 with error 128!
21:49:05 | [W] | [stream_server:168] | Failed to read from client 172.50.255.252 with error 128!
21:49:05 | [E] | [stream_server:145] | Failed to write to client 172.50.255.252 with error 128!
21:49:05 | [W] | [stream_server:168] | Failed to read from client 172.50.255.252 with error 128!
21:49:05 | [E] | [stream_server:145] | Failed to write to client 172.50.255.252 with error 128!
21:49:05 | [W] | [stream_server:168] | Failed to read from client 172.50.255.252 with error 128!
21:49:05 | [E] | [stream_server:145] | Failed to write to client 172.50.255.252 with error 128!
21:49:05 | [W] | [stream_server:168] | Failed to read from client 172.50.255.252 with error 128!
21:49:05 | [E] | [stream_server:145] | Failed to write to client 172.50.255.252 with error 128!
21:49:05 | [W] | [stream_server:168] | Failed to read from client 172.50.255.252 with error 128!
21:49:05 | [E] | [stream_server:145] | Failed to write to client 172.50.255.252 with error 128!
21:49:05 | [W] | [stream_server:168] | Failed to read from client 172.50.255.252 with error 128!
21:49:05 | [E] | [stream_server:145] | Failed to write to client 172.50.255.252 with error 128!
21:49:05 | [W] | [stream_server:168] | Failed to read from client 172.50.255.252 with error 128!
21:49:05 | [E] | [stream_server:145] | Failed to write to client 172.50.255.252 with error 128!
21:49:05 | [W] | [stream_server:168] | Failed to read from client 172.50.255.252 with error 128!
21:49:05 | [E] | [stream_server:145] | Failed to write to client 172.50.255.252 with error 128!
21:49:05 | [W] | [stream_server:168] | Failed to read from client 172.50.255.252 with error 128!
21:49:05 | [E] | [stream_server:145] | Failed to write to client 172.50.255.252 with error 128!
21:49:05 | [W] | [stream_server:168] | Failed to read from client 172.50.255.252 with error 128!
21:49:05 | [E] | [stream_server:145] | Failed to write to client 172.50.255.252 with error 128!
21:49:05 | [W] | [stream_server:168] | Failed to read from client 172.50.255.252 with error 128!
21:49:05 | [E] | [stream_server:145] | Failed to write to client 172.50.255.252 with error 128!
21:49:05 | [W] | [stream_server:168] | Failed to read from client 172.50.255.252 with error 128!
21:49:05 | [E] | [stream_server:145] | Failed to write to client 172.50.255.252 with error 128!
21:49:05 | [W] | [stream_server:168] | Failed to read from client 172.50.255.252 with error 128!
21:49:05 | [E] | [stream_server:145] | Failed to write to client 172.50.255.252 with error 128!
21:49:05 | [W] | [stream_server:168] | Failed to read from client 172.50.255.252 with error 128!
21:49:05 | [E] | [stream_server:145] | Failed to write to client 172.50.255.252 with error 128!

172.50.255.252 IP address is the IP address for the virtual server that is running zigbee2mqtt and mqtt (docker versions for both)

Any idea what that is and why is showing these errors?

tube0013 · April 3, 2024, 2:30pm

I’ve seen that a few time, if you just power cycle the device it should clear it out. I haven’t noticed any issues on the zigbee side when it is occuring.

tube0013 · April 3, 2024, 2:50pm

I’ver also just posted the yaml, so adopting and re-compiling the esphome fw and updating from the esphome dashboard should now work. Let me know if you have any issues.

MnM · April 3, 2024, 2:52pm

The issue is that this keeps coming back. So power cycle the device is not really an option as after a little while the issue is back.

Also the first time I have tried it with z2m the stick crashed after a while (assume this logs will eventually fill out some buffer/space on the device and will crash it eventually).

I have a quick search around and this issue is definitely related to the ESPHome side of things:

github.com/tube0013/tube_gateways

Failed to read to client 192.168.2.33 with error 128!

opened 05:14PM - 05 Feb 24 UTC

closed 06:41PM - 13 Feb 24 UTC

frank2604

Hi Byron. After one of my coordinators stopped sending commands twice in the …last few days and had to be restarted, I had a look at the web UIs of all 5 coordinators. 3 out of 4 tubeszb-cc2652p7-poe-2023 continuously show these entries in the log: ``` Failed to write to client 192.168.2.33 with error 128! Failed to read to client 192.168.2.33 with error 128! ``` <img width="1860" alt="2024-02-05_17-50-23" src="https://github.com/tube0013/tube_gateways/assets/51050855/3568bca0-3ea1-427d-87ed-0ba807a3a719"> <br class="Apple-interchange-newline"> One tubeszb-cc2652p7-poe-2023 and the tubeszb-efr32-mgm210-poe-2023 have no log entries. The cc2652p7 with no log entries seems to have hung up and is no longer transmitting commands as described above. All devices of this coordinator are displayed as offline in Z2M. The IP address is that of the Ubuntu server on which the Docker containers of HA, Mosquitto and the 5 Zigbee2MQTT are running. So actually the same as issue #172. As you know, I have set fixed IP addresses on all coordinators, you had already installed the firmware for this before I sent it.

and

github.com/tube0013/tube_gateways

Failed to read from client 192.168.10.153 with error 128!

opened 12:51PM - 23 Nov 23 UTC

closed 01:41PM - 27 Nov 23 UTC

pugmandan

12:45:01 | [E] | [stream_server:145] | Failed to write to client 192.168.10.153 …with error 128! 12:45:01 | [W] | [stream_server:168] | Failed to read from client 192.168.10.153 with error 128! Getting the above error in my tubeszb-cc2652p7-poe-2023 after it had been running for a number of hours. I confirmed that the client (zigbee2mqtt) was still operational (and showing no issues on its end or in its logs). I also operated a Zigbee device (turned light on and off) and it worked without delay. The tubeszb logs was creating 10's of new log lines per second. I suspect this has been the cause of the stick crashing as it just logs endlessly until I suspect it runs out of memory. Is there any information as to what error 128 means please? I have tried google with no success. Furthermore both the stick and zigbee2mqtt were both accessible so there should not have been any errors.

and

Some something on the ESPHome side of things needs to be updated/fixed.

However just like the user i the fist Github post I will also need your assistance to compile a new binary (and yes if static IP can be used I will like to use that and can provide the required details).

Thanks.