Let me test some things out. In the mean time you can keep trying. I know that seems harsh but I’ve seen this happen a few times then it will just work.
Would it be possible to use the tube coordinator with 2 separate instances of Home Assistant. I’m hoping that since it’s a network device that it can communicate successfully with 2 devices.
More specifically:
I have the coordinator configured on my prod instance of HA via ZHA.
I’m slowly transitioning to a new VM based install (starting from scratch). I would like to try out zig2mqtt on this new instance. I’m hoping I can leave the original connection in place while I test separately with z2m.
Is any of this possible? 
unfortunately it can’t work that way, its one coordinator per instance (zha or z2m).
I’ve got one of the round PoE device here and was just able to flash it. I wasn’t able to do it via the software buttons to trigger the bootloader.
what I did was pull the the ethernet/poe line. popped the lid and held the BSL button on the pcb, plugged back in ethernet/power and kept holding it for about 10 seconds to allow everything to start/connect. then I ran the script I did include the -b flag for baudrate.
./cc2538-bsl.py -p socket://192.168.1.51:6638 -b 115200 -evw ./CC1352P2_CC2652P_launchpad_coordinator_20220219.hex
I have been testing out the newest esphome build on this device. which in the past flashing would fail with so that’s a good sign too. I posted this as beta to github in case you want to try.
I’m also trying to repeat a flash but not have great luck. so I’ll keep testing, but definitely try the manual button press.
Edit, I rolled back the FW image to the “latest” bin and the script to activate Bootloader and the flash all went okay.
Things I would try
- Physical hold the BSL button while powering on for a good 10-15 seconds then attempt to flash
- Do a hard re-flash of the esp32, over USB same instructions as here https://github.com/tube0013/tube_gateways/tree/main/models/current/tubeszb-cc2652-poe-2022#esp32-flashing just use the bin for the round model.
Thank you for your thorough responses, @tube0013!
I’ve tried to debug for some hours now, sadly without much luck. I started by trying the physical BSL button, but I was not successful in getting a connection which didn’t time out.
Went on to reflash over USB, with the beta version, as I’d already reflashed with the latest binary. After that I seemed to get a bit further into the process.
(venv) ➜ cc2538-bsl git:(master) ✗ python cc2538-bsl.py -p socket://192.168.1.192:6638 -evw CC1352P2_CC2652P_launchpad_coordinator_20220219.hex -b 115200
Opening port socket://192.168.1.192:6638, baud 500000
Reading data from CC1352P2_CC2652P_launchpad_coordinator_20220219.hex
Your firmware looks like an Intel Hex file
Connecting to target...
CC1350 PG2.0 (7x7mm): 352KB Flash, 20KB SRAM, CCFG.BL_CONFIG at 0x00057FD8
Primary IEEE Address: 00:12:4B:00:23:7E:07:C4
Performing mass erase
Erasing all main bank flash sectors
Erase done
Writing 360448 bytes starting at address 0x00000000
ERROR: Timeout waiting for ACK/NACK after 'Get Status (0x23)'
I still got a timeout, but as you can see it was another timeout message – Get Status (0x23), not the 'Synch (0x55 0x55)' as previously. On later inspection it looks like the order of CLI arguments matter, as the baudrate was incorrect…
After this I have been unable to get a connection through the cc2538-bsl.py-flasher. It seems like I’m also unable to access the ESPHome web server on the IP address. Because of this I have reflashed multiple times with USB. Each ESPHome flash seem to be successful
Is it possible that the CC2652P is hindering the ESP to work properly since the zigbee-chip has not been successfully flashed? Could it simply be my Unifi gear acting up? Have not been able to test with another network setup yet, but if we really want to get to the bottom of this, I could possibly fix a test with other network gear.
I do luckily have a spare zigbee USB dongle which I have migrated to for now, so the house is not in an emergency. Would be nice to figure this out even though. Have been very pleased with the gateway, so almost tempted to go the easy route and buy your 2022 version;D
the FW on the esp and cc2652 modules are independent of each other. if the cc2652 does have an incomplete or bad image it should automatically boot into bootloader mode.
I was seeing similar behavior last night when I was working with this. I initially tried with the beta esphome as that is what I’d had on it to test. The gpio based switches to put the device into bootloader mode never worked. the physical button did, and it flashed successfully the first time I tried it!
I tried to repeat it and could not get it to go, it would start, and then die in the middle (this was the original symptom of the serial connect issues with newer esphome releases).
I went back to the older main stay esphome image and tried the gpio routine again for bootloader and it worked straight away and I was able to flash it.
I am not sure what the magic is, When these were made the were all flashed over network from the beginning. I think I moved to flashing in a jig after getting some cc2652 modules with bad ipex placement and it made more sense to test before putting them on a board. with 2022 version I have a custom serial board I use to test/flash them.
if you have an usb to serial converter board, some pin headers, and soldering iron you can add the header to allow you to bypass the esp32 and flash directly from the pins as a last fall back.
The 2022 design was really just about speeding up the manufacturing on my end, but brought multiple added bonuses, the module design to be able to swap out the esp32 if something ever happened to it, and easier access to the the cc2652 pins. (custom serial board or just sticking male dupont wires into the right pins on the female 2x5 header.
I’m actively working with a developer (I just shipped them hardware) to try and get the custom serial stream esphome component working better with current esphome release, and make it more dependable. I think in general the older pre 2021.10 releases worked the best with the serial component.
1 Like
Just ordered a PoE model. This will be my first foray into Zigbee and it seems like the best option available for my needs. Thank you for making it.
1 Like
I’m having some trouble getting a tubeszb_cc2652p2_poe_2022 to get added as an integration as ZHA.
I’ve got a new HA install… The tube device has a DHCP reservation of 10.138.0.10. I can access the web server.
The issue seems to be that the integration wizard process is somehow connecting more than once. This is what I see from the tube’s web server:
[D][serial_server:103]: New client connected from 10.138.1.40
[D][binary_sensor:036]: ‘Serial Connected’: Sending state ON
[D][serial_server:042]: Not accepting new connection from 10.138.1.40, only one client allowed
[D][serial_server:068]: Client 10.138.1.40 disconnected
[D][binary_sensor:036]: ‘Serial Connected’: Sending state OFF
This seems to happen whether I try the zeroconf/discovered integration or whether I initiate the integration by searching ZHA.
My HA instance is a VM and I have a snapshot of it from before I ever plugged the tube device into my network so I’ve actually restored that snapshot several times and tried adding the device different ways but I keep getting this error.
I wondered about just configuring ZHA in YAML but I couldn’t find an example for ZHA. I may do some more searching for a YAML example - I’m new to HA but prepared to do YAML editing if that ends up helping.
Any suggestions? Thx!!!
Hi, yea there is a bug in the current in one of the support libs that is effecting network setup, I believe it will be fixed in the version release on Wednesday. but DM me if you want to work through a work around now, it involves a adding 2 lines of code to one of the zha component files.
1 Like
I’ll just post the workaround here in case anyone else comes across this before the fix is released.
First thing you need access to the HA instance, if using HASSOS you can do this with an add-on:
Grab the SSH & Web Terminal Addon from the Home Assistant Community Add-ons:
Disable Protection Mode, and start the add-on:
Open web Ui
Grab the fix from my github:
wget https://github.com/tube0013/tube_gateways/raw/main/misc/config_flow.py.fix
get a terminal in the HA docker:
docker exec -it homeassistant bash
move to ZHA component directory:
cd /usr/src/homeassistant/homeassistant/components/zha
remove the cache:
rm -Rf ./__pycache__
save the original config_flow.py and copy over the fix:
mv config_flow.py config_flow.py.orig
cp /config/config_flow.py.fix config_flow.py
you can then restart HA, and adding the coordinator should work again.
let me know if you have any questions.
1 Like
Thank you!! It took me a bit to gain access to the components folder. And it worked. Thanks again.
1 Like
Awesome. Sorry for the extra gymnastics to get it to work. All should be better once this PR is merged
The extra gymnastics were not a problem - it actually pushed me to learn a bit more about HA since I’m new to it. I had done the VM installation where I use a pre-existing QCOW2 file so I actually had no idea that it was internally dockerized. Then I struggled a bit to get into the docker instance but learned how.
1 Like
You really shouldn’t ever need to get into it! This is now fixed in 2022.10.
@petrepa were you ever able to get the FW to update?
I have new FW based on an updated serial component that in my testing is much more robust. I was able to flash multiple times over the network with no issues.
I’ve rolled out updated yaml and binaries based on ESPHome 2022.10 for most models. I maybe lagging on a few but will get them done in the next day or so. I’m still considering these beta for now, but in testing i’ve seen very reliable connections.
I just received a CC2652P2 based Zigbee to Ethernet/USB Serial Coordinator without Ethernet. I am replacing my existing CC2531 that is the coordinator for my Zigbee2MQTT network.
I assumed the coordinator would have shipped pre-flashed so following the instructions here: GitHub - tube0013/tube_gateways: Information and Documentation on Tube's Zigbee Gateways I simply changed my existing z2m config port to ‘tcp://192.168.1.165:6638’ but got this error “Error: Error while opening socket” so I changed to /dev/ttyUSB1 and got this error “Error: SRSP - SYS - getExtAddr after 6000ms”
So then I thought I would try and reflash it using the instructions here tube_gateways/models/current/tubeszb-cc2652-eth_usb at main · tube0013/tube_gateways · GitHub I moved the jumpers across and held down the boot button but as soon as I let the button go I kept getting a permission denied error 13. I tried espflasher 1.3 on my WIndows 7 computer with two different USB cables and then tried espflasher 1.4 on a Windows 10 laptop with the same two cables and no joy.
At one point I saw in the integrations that the device had been discovered by ZHA and I clicked on configure but that failed for a reason I can’t remember and it isn’t shown anymore. Just just confirming I do not have ZHA showing in SETTINGS>>INTEGRATIONS
Any ideas?
Does the coordinator have ethernet or not?
No ethernet
Then it is set up like any other USB/Serial device. no IP
OK so I tried /dev/ttyUSB1 and that didn’t work either