tubezb-cc2652p2-ethusb-2022 + Z2M -------- Connection loop?

[diphen]

I'm running Z2M with the tubezb-cc2652p2-ethusb-2022 as the coordinator over ethernet.

It works occasionally, but sometimes Z2M seems to end up in a state that looks to be a reconnect loop on the tubezb-cc2652p2-ethusb-2022 logs, but in the Z2M logs it looks like the coordinator does not respond.

If I fully restart HA everything will occasionally come back up and work properly for maybe a day, but will usually end up in this state where Z2M won't be able to start because it can't connect to the coordinator.

I've recently tried enabling socat which doesn't seem to help - any guidance would be appreciated!

---

Details

• zigbee2mqtt version 1.33.2-1
• MQTT broker version 6.3.1
• cc2652p2-ethusb-2022 running 2022.12.3 firmware

---

Logs from the cc2652p2-ethusb-2022 web interface look like this:

        09:17:31 | [D] | [streamserver:074] | New client connected from 192.168.50.133
        09:17:31 | [D] | [binary_sensor:036] | 'TubesZB Serial Connected': Sending state ON
        09:17:50 | [D] | [streamserver:102] | Client 192.168.50.133 disconnected
        09:17:50 | [D] | [binary_sensor:036] | 'TubesZB Serial Connected': Sending state OFF
        09:20:46 | [D] | [streamserver:074] | New client connected from 192.168.50.133
        09:20:46 | [D] | [binary_sensor:036] | 'TubesZB Serial Connected': Sending state ON
        09:21:06 | [D] | [streamserver:102] | Client 192.168.50.133 disconnected
        09:21:06 | [D] | [binary_sensor:036] | 'TubesZB Serial Connected': Sending state OFF

Z2M logs:

---

        [08:57:12] INFO: Preparing to start...
        [08:57:12] INFO: Socat enabled
        [08:57:13] INFO: Starting socat
        Socat startup parameters:
        Options:     -d -d
        Master:      pty,raw,echo=0,link=tcp4:192.168.50.209:6638,mode=777
        Slave:       tcp4:192.168.50.209:6638,keepalive,nodelay,reuseaddr,keepidle=1,keepintvl=1,keepcnt=5
        [08:57:13] INFO: Starting socat process ...
        2023/11/20 08:57:13 socat[53] N PTY is /dev/pts/0
        2023/11/20 08:57:13 socat[53] N opening connection to AF=2 192.168.50.209:6638
        2023/11/20 08:57:13 socat[53] N successfully connected from local address AF=2 172.30.33.3:36190
        2023/11/20 08:57:13 socat[53] N starting data transfer loop with FDs [5,5] and [7,7]
        [08:57:13] INFO: Zigbee Herdsman debug logging enabled
        [08:57:14] INFO: Starting Zigbee2MQTT...
        Zigbee2MQTT:info  2023-11-20 08:57:18: Logging to console and directory: '/config/zigbee2mqtt/log/2023-11-20.08-57-18' filename: log.txt
        Zigbee2MQTT:info  2023-11-20 08:57:18: Starting Zigbee2MQTT version 1.33.2 (commit #unknown)
        Zigbee2MQTT:info  2023-11-20 08:57:18: Starting zigbee-herdsman (0.21.0)
        2023-11-20T16:57:18.663Z zigbee-herdsman:adapter Failed to validate path: 'Error: spawn udevadm ENOENT'
        2023-11-20T16:57:18.665Z zigbee-herdsman:controller:log Starting with options '{"network":{"networkKeyDistribute":false,"networkKey":[116,185,185,175,206,189,181,135,208,119,45,101,109,82,202,178],"panID":64019,"extendedPanID":[118,120,141,50,173,109,120,170],"channelList":[25]},"serialPort":{"path":"tcp://192.168.50.209:6638"},"databasePath":"/config/zigbee2mqtt/database.db","databaseBackupPath":"/config/zigbee2mqtt/database.db.backup","backupPath":"/config/zigbee2mqtt/coordinator_backup.json","adapter":{"disableLED":false,"concurrent":null,"delay":null}}'
        2023-11-20T16:57:18.666Z zigbee-herdsman:adapter:zStack:znp:log Opening TCP socket with 192.168.50.209:6638
        2023-11-20T16:57:18.692Z zigbee-herdsman:adapter:zStack:znp:log Socket connected
        2023-11-20T16:57:18.692Z zigbee-herdsman:adapter:zStack:znp:log Socket ready
        2023-11-20T16:57:18.693Z zigbee-herdsman:adapter:zStack:znp:log Writing CC2530/CC2531 skip bootloader payload
        2023-11-20T16:57:18.694Z zigbee-herdsman:adapter:zStack:unpi:writer --> buffer [239]
        2023-11-20T16:57:19.697Z zigbee-herdsman:adapter:zStack:znp:log Skip bootloader for CC2652/CC1352
        2023-11-20T16:57:19.699Z zigbee-herdsman:adapter:zStack:znp:SREQ --> SYS - ping - {"capabilities":1}
        2023-11-20T16:57:19.701Z zigbee-herdsman:adapter:zStack:unpi:writer --> frame [254,0,33,1,32]
        2023-11-20T16:57:25.705Z zigbee-herdsman:adapter:zStack:znp:SREQ --> SYS - ping - {"capabilities":1}
        2023-11-20T16:57:25.705Z zigbee-herdsman:adapter:zStack:unpi:writer --> frame [254,0,33,1,32]
        2023-11-20T16:57:31.706Z zigbee-herdsman:adapter:zStack:znp:SREQ --> SYS - ping - {"capabilities":1}
        2023-11-20T16:57:31.708Z zigbee-herdsman:adapter:zStack:unpi:writer --> frame [254,0,33,1,32]
        Zigbee2MQTT:error 2023-11-20 08:57:37: Error while starting zigbee-herdsman
        Zigbee2MQTT:error 2023-11-20 08:57:37: Failed to start zigbee
        Zigbee2MQTT:error 2023-11-20 08:57:37: Check https://www.zigbee2mqtt.io/guide/installation/20_zigbee2mqtt-fails-to-start.html for possible solutions
        Zigbee2MQTT:error 2023-11-20 08:57:37: Exiting...
        Zigbee2MQTT:error 2023-11-20 08:57:37: 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:60:27)
            at Controller.start (/app/lib/controller.ts:101:27)
            at start (/app/index.js:107:5)

[tube0013]

Is z2m able to re-connect after toggling a zigbee module reset from the web frontend of the coordinator?

What types of devices do you have connected to the mesh any tuya and if so what models/types?

thanks.

[diphen]

Triggering a module reset does seem to let Z2M connect successfully.

There are about 60 devices on the network at the moment:

• 36 Inovelli 2-1 Blue switches
• 10ish Sengled RGB bulbs
• 5ish Ikea devices
• 3 Tubezb's CC2652P2 repeater/routers
• 4 Tuya RGB GU40 bulbs
• 4 Enbrighten Switches

[tube0013]

Interesting. the module reset would mean it's a z-stack coordinator firmware issue.

One thing I will note, is that the Sengled bulbs can be problematic when used along side the z-stack routers like my TubesZB router, I note this now in the product description. Do you find you have to power cycle those frequently?

[diphen]

Yeah, the sengled bulbs have always been a pain for me, but we don't change their settings very often so I usually have the Inovelli switches cut off their power rather than run them in smart bulb mode.

I haven't tried using the coordinator over USB since I switched from ZHA to Z2M, but I was wondering if that would change the behavior, since the errors seem to show the coord. as non-responsive.

Would that be worth testing?

[tube0013]

You can try USB, I don't think it will make a difference, but still a good test to make sure nothing in the tcp communication is causing the coordinator crash.

[diphen]

Sure, might as well rule it out.

Is there anything I can do to get further logging to understand better what is happening?

[tube0013]

Not really, just seeing if it still crashes with the same message in the log.

[LordNex]

Is there a benefit of using z2m vs just ZHA?

I've been running just standard ZHA and it works perfectly. I have some tazmota and Sonoff devices that I run through MQTT but I don't see the benefit of adding another thing to the equation.

[diphen]

In my case, ZHA was incredibly unstable.

I decided I needed to swap channels, figured I'd try out Z2M at the same time.

Personally, I like Z2M more for direct access to the data being passed on the network, and OTA updates, but it sure is ugly :D

[LordNex]

In my case, ZHA was incredibly unstable.

I decided I needed to swap channels, figured I'd try out Z2M at the same time.

Personally, I like Z2M more for direct access to the data being passed on the network, and OTA updates, but it sure is ugly :D

I've only had a few battery powered contact switches or so drop out. And that's usually in the rooms without a bulb repeater or otherwise. IMO adding z2m is just adding a middle man. I guess you can at least include logic there that if the device comes back unresponsive, you could have it toggle the main power switch or something.

A lot of times when mine drop off and go unresponsive, I have to repair them with ZHA but it retains the name and all the settings except the location.