Zigbee2MQTT failing to start herdsman following coordinator firmware update

Configuration
, ,
1

I’m sure this is going to be something fairly simple but I’m going round and round in circles trying to resolve this, so looking for a little help if possible please?

Runnning HA OS on an Intel NUC
Home Assistant 2022.9.6
Supervisor 2022.09.1
Operating System 9.0
Frontend 20220907.2 - latest
and also Zigbee2MQTT 1.27.2-1

My Zigbee coordinator is a Sonoff ZBBridge flashed with Tasmota. I have a handful of Zigbee devices which have been working flawlessly.
Today I browsed to my Zigbee coordinator webpage and noticed it was still on an older version of Tasmota, V10, so I decided to do an OTA update to V12.1.1 which flashed fine.

I was prepared to have to re-pair my handful of Zigbee devices to the coordinator, which I have done successfully, and can see the devices communicating in the console of the coordinator, however performing this Tasmota update on the coordinator seems to have caused problems with Zigbee2MQTT in Home Assistant.

Zigbee2MQTT no longer loads the webUI and I get a 502 error, and the Add-on logs show

Zigbee2MQTT:info  2022-09-25 16:07:03: Starting Zigbee2MQTT version 1.27.2 (commit #unknown)
Zigbee2MQTT:info  2022-09-25 16:07:03: Starting zigbee-herdsman (0.14.53)
Zigbee2MQTT:debug 2022-09-25 16:07:03: Using zigbee-herdsman with settings: '{"adapter":{"concurrent":null,"delay":null,"disableLED":false},"backupPath":"/config/zigbee2mqtt/coordinator_backup.json","databaseBackupPath":"/config/zigbee2mqtt/database.db.backup","databasePath":"/config/zigbee2mqtt/database.db","network":{"channelList":[11],"extendedPanID":[221,221,221,221,221,221,221,221],"networkKey":"HIDDEN","panID":6754},"serialPort":{"adapter":"ezsp","path":"tcp://192.168.1.193:8888"}}'
Zigbee2MQTT:error 2022-09-25 16:07:03: Error while starting zigbee-herdsman
Zigbee2MQTT:error 2022-09-25 16:07:03: Failed to start zigbee
Zigbee2MQTT:error 2022-09-25 16:07:03: Check https://www.zigbee2mqtt.io/guide/installation/20_zigbee2mqtt-fails-to-start.html for possible solutions
Zigbee2MQTT:error 2022-09-25 16:07:03: Exiting...
Zigbee2MQTT:error 2022-09-25 16:07:03: Error: Error while opening socket
    at Socket.<anonymous> (/app/node_modules/zigbee-herdsman/src/adapter/ezsp/driver/uart.ts:146:24)
    at Socket.emit (node:events:539:35)
    at emitErrorNT (node:internal/streams/destroy:157:8)
    at emitErrorCloseNT (node:internal/streams/destroy:122:3)
    at processTicksAndRejections (node:internal/process/task_queues:83:21)

I’ve followed the link suggested for the Z2M fails to start page but cannot find a solution.

I’ve tried uninstalling Z2M and reinstalling, but no difference. I have also restored yesterdays full backup of HA but again no difference, so I’m wondering how this coordinator firmware update could be breaking things in HA?

2

I have exactly the same problem. Already found a solution?
The problem persists even after reinstalling zigbee2mqtt. Changing to a new coordinator doesn’t help either.

3

Hi @Stefan28L welcome to the forum!

I did, but forgot to update here as I didn’t get any response. All I needed to do in the end was to recreate the rule within the Tasmota console on my newly flashed coordinator which starts the TCPBridge on boot.

‘Rule1 ON System#Boot do TCPStart 8888 endon’

I dont know if this rule should normally carry over during an update of Tasmota firmware, but it didn’t appear to for me with my update. All working fine again now.

4

Hi, I suspect that you are touching onto something important here.
I added this command and got a “Command:unknown” error.
Even just typing TCPStart 8888 resulted in the same error.
But with the rule intact, I reflashed Tasmota and for the first time I managed to make v13.3.0 connect successfully with Z2M.
Earlier, I had not been able to go beyond v13.2.0
So, if - by any chance - the rule is carried over during an update, and that it may be working (no error) in an intermediate step (between minimal and full?), then it could explain my result.
However, I don’t know how to test this.
Before moving on, I’d like to know why everyone seems to indicate that such a rule is required, yet it only produces an error message on my device (Sonoff ZHABridge).