#Hello, using the ZHA integration with a
1 messages ยท Page 1 of 1 (latest)
I see it connect "New Client connected from %IP%" and "TubesZB Serial Connected sending state ON" when ZHA starts up but after about 5-10 seconds "Client %IP% disconnected"
so after restarting HA it now won't connect, there is nothing additional in the logs, even with "debug on" on the ZHA integration
Any suggestions on where to look or anything to try to see why the connection isn't opening?
Are you referring to the gateway web interface debug logs, or the ZHA logs? If you click the "disable debug logging" button, it'll download a log file for ZHA
If you could send me that log file, I can take a look
Thanks @uneven oracle I appreciate that! I enabled debug logging, restarted the integration, then disabled after it failed to load and here is the file it spit out: https://www.chrisuthe.com/FileShare/home-assistant_zha_2023-12-18T15-33-05.205Z.log
All that I see within is basically a timeout error, I do have 32 devices, some of which are off/not powered at the moment if that contributes.
and it's exactly 10 seconds from the connected to disconnected, if that helps
This isn't really something that can be fixed, unfortunately:
2023-12-18 09:32:50.031 DEBUG (MainThread) [zigpy_znp.uart] Connecting to socket://10.0.0.10:6638 at 115200 baud
2023-12-18 09:32:50.031 DEBUG (MainThread) [zigpy.serial] Opening a serial connection to 'socket://10.0.0.10:6638' (115200 baudrate)
2023-12-18 09:32:50.034 DEBUG (MainThread) [zigpy_znp.uart] Opened socket://10.0.0.10:6638 serial port
2023-12-18 09:32:50.034 DEBUG (MainThread) [zigpy_znp.uart] Connected to socket://10.0.0.10:6638 at 115200 baud
2023-12-18 09:32:50.034 DEBUG (MainThread) [zigpy_znp.api] Toggling RTS/DTR pins to skip bootloader or reset chip
2023-12-18 09:32:50.486 DEBUG (MainThread) [zigpy_znp.api] Sending request: SYS.Ping.Req()
2023-12-18 09:32:50.991 DEBUG (MainThread) [zigpy_znp.api] Sending CC253x bootloader skip bytes
2023-12-18 09:32:53.493 DEBUG (MainThread) [zigpy_znp.api] Sending request: SYS.Ping.Req()
2023-12-18 09:32:54.494 DEBUG (MainThread) [zigpy_znp.api] Sending request: SYS.Ping.Req()
2023-12-18 09:32:55.494 DEBUG (MainThread) [zigpy_znp.api] Sending request: SYS.Ping.Req()
2023-12-18 09:32:56.495 DEBUG (MainThread) [zigpy_znp.api] Sending request: SYS.Ping.Req()
2023-12-18 09:32:57.496 DEBUG (MainThread) [zigpy_znp.api] Sending request: SYS.Ping.Req()
2023-12-18 09:32:58.499 DEBUG (MainThread) [zigpy_znp.api] Sending request: SYS.Ping.Req()
2023-12-18 09:32:59.501 DEBUG (MainThread) [zigpy_znp.api] Sending request: SYS.Ping.Req()
2023-12-18 09:33:00.037 DEBUG (MainThread) [zigpy_znp.api] Connection to socket://10.0.0.10:6638 failed, cleaning up
It tries repeatedly to get a response from your network coordinator for nearly 10 seconds without a single reply
If it takes two attempts for the network coordinator to start up, it just means that it's slow to boot up
If you want to try tweaking it, here is where the connect timeout is defined: https://github.com/zigpy/zigpy-znp/blob/8b86f677ab1b8ae4a7fce735af5fcf3dc024dfe4/zigpy_znp/api.py#L49. Try changing it to 30s and see how long it takes to actually connect.
really appreciate the information puddly
Of course, I appreciate the logs! If you do find a timeout that works better, let me know and I can change it globally
CC @quick condor ๐
thanks for the ping, I'll take a look shortly.
is this a 2022 or 2023 cc2652 Coordinator? an alterante esphome fw may help too.
so the round one?
Yes indeed
okay let me see what I have and I'll post a binary for you to try, you will need to flash it over USB as it will change the flash partitions on the esp32 whcih can't be done with an OTA flash. to access the micro usb port, disconnect from PoE and live the pcb slightly out of the case and you should be able to plug in a cable.
cool, thank you very much, I'll go grab it and get it plugged in
here is the binary and the yaml it is built from. the biggest difference is it's using the ESP-IDF framework which in my on-going testing has been a bit faster.
okay I'll give it an upload here
For USB flash, check out the esphomeflasher
yep that's what I'm using ๐
I flashed that bin file, ad the log after flashing shows:
rst:0x10 (RTCWDT_RTC_RESET),boot:0x1b (SPI_FAST_FLASH_BOOT)
invalid header: 0x64253a69
invalid header: 0x64253a69
invalid header: 0x64253a69
invalid header: 0x64253a69
invalid header: 0x64253a69
invalid header: 0x64253a69
invalid header: 0x64253a69
invalid header: 0x64253a69
ets Jul 29 2019 12:21:46
I can just shove in the ESPhome config and build too
yes of course.
same thing with the firmware out of the zip, building based on the config now
I have one of these set up, I'm not near it today, but I was testing a variant of this FW on it, testing it now with an OTA flash since I'm remote.
built, installed, getting same timeout after 10 seconds
let me see if I see the same.
it has been really solid until recently, and I had been running the same zigbee/esphome versions as what shipped on it until a few months ago when I was having trouble adding a new zigbee item, so I figured out how to update both, which really helped the adoption issues I was having
but unsure if that change, or the fact that I added a handful of new devices after that impacted it
I should also note that I had always had success with it eventually linking up until this morning when I upgraded to 2023.12.1 HA
good to know, I do not think any of that should of changed it.
I can see if I can figure out how to go back a version
is it ever able to come up? can you issue a reset from the web console to restart the cc2652 and then reload zha?
I wasn't able to re-produce. but I don't have many any devices on the network with this coordinator.
I can reset the coordinator via web then reload ZHA and I get the same results
which z-stack version did you update too?
CC1352P2_CC2652P_launchpad_coordinator_20230507
I'd recommend flashing the previous 20221226 version
there are a lot of folks having issues with 20230507, maybe more z2m related but I'm still shipping with the earlier release as it seem much less problematic.
I had downloaded 20230507 from https://github.com/Koenkk/Z-Stack-firmware/tree/master/coordinator/Z-Stack_3.x.0/bin but I don't see the older version, do you happen to know of a location to get it?
it's linked on the releases page, but here's the directory where you can pull it: https://github.com/Koenkk/Z-Stack-firmware/tree/Z-Stack_3.x.0_coordinator_20221226/coordinator/Z-Stack_3.x.0/bin
Ahhhhh of course, sorry thank you
giving this a flash now
flashed, rebooted, enabled ZHA the initialization is not failing quickly after 10 seconds, so I assume that is a good thing...
and I mis-types it was 2023.12.3 that I upgraded HA to
aaand it's loaded successfully
Thank you, very much @quick condor and @uneven oracle for the suggestions and time helping, I really appreciate it
You have no sponsor option on Github and no tip link, lmk if there is a way to slide you a thank you for your time @quick condor
no worries, I'm good, and like to support folks who buy my stuff.
It's been absolutely rock solid for 2 years, (and solved the original problem of the HA host being in the basement running in docker) I have a handful of the router/repeaters spread around the house as well and the network has always been great.
that's awesome to hear. spread the word if you ever have the chance. I don't really market which keeps things managable but do appreciate when satisfied customers let me know and also spread the word ๐
Sorry to bug you tube, I migrated HA to a new server and the first time or two it started up ZHA started fine, now it tries real hard (read: takes a while) and eventually fails. I put in an order on your site for a new TubesZB EFR32 MGM24 with the intent to transition to Zigbee2mqtt when it arrives, but is there anything you might suggest in the meantime? I've got a skyconnect stick sitting here but frankly the POE adapters let me really put it in a better spot than the network rack in my basement.
Try the migrate radio feature and select reconfigure current radio, confirm the ip is correct and go through and keep current network settings. Also enable debug and post the logs to a share site if possible.
will do, ty!
is this really an interference issue?! I guess I'll move my gateway and see if that helps...
weahlp not sure if moving it helped or not but it started up this time, so... case closed. I'll try to find a better place for the new gateway when it arrives and continue to migrate from ZHA to zigbee2mqtt
that log doesn't lie, the radio chip was refusing to start up due to the rf envirement it saw.
well that's entirely on me, gotta do some thinking about AP coverage and location for this gateway
if you have ZHA for a while, it would have defaulted to channel 15
I guess I can loom in the log
it's on 15 yes
but you can change the channel in ZHA and it will auto pick the best
and most devices will migrate
even if moving to z2m, good idea to know best channel. z2m defaults to 11 no matter
why do you want to move to z2m? the MGM24 should work with their new "ember" option but that only just came out last release.
Honestly, just due to issues like this where I didn't feel like ZHA was giving me information on what was going on but perhaps I don't really need to
I was worried about migration of HA but that went smooth as butter honestly with ZHA
seems like I just need to sort out my enviroment problems and leave well enough alone
the channel change should help, just be prepared to have to reset a few devices. the folks I know who have done it have had to do non- to just a few. (mostly sleepy battery powered).
You can run an energy scan with zigpy-cli if you want to look at the environment yourself - (what the coordinator sees)
is moving to the new coordinator a worthwhile move with 30 devices?
Nah I don't think so. The MGM24 is a beast, some guy is attempting to get 600 devices running on it with zha, last I heard he was up to 330 with no issues. I am running one and nearing 200 devices with some new additions lately. The cc2652p2 is fine for 30 devices + more
Happy to cancel the order if you are having second thoughts
heck no, I've got a lakehouse to get up and going and I'm a sucker for cheap zigbee lights so I'll need a coordinator for there anyway. That is crazy 600+ devices.
thank you again for the help, going ot try to get your CLI-Tools add on running later and powerscan. Takes a few extra steps for us docker based step childrend
https://community.inovelli.com/t/large-zigbee-network-experiences/15878/48 he has some updates here if interested.
you can run it from another machine, in either case just make sure you disable zha before running.
Also if you just look in the downloaded diagnostics it will have a single run stored within from when you trigger the diagnostics
(I'm always forgetting this is now in there)