After power cycling my eachen zbbridge, zigpy/bellows ZHA integration can no longer connect to TCP

[R5fan]

PROBLEM DESCRIPTION

After power cycling my eachen zbbridge, zigpy/bellows can no longer connect to it. The only way I found to make it work again is applying the template that enables Z2T, then again applying the ZHA template. Then it will work, until the next power cycle.

REQUESTED INFORMATION

Make sure your have performed every step and checked the applicable boxes before submitting your issue. Thank you!

• [ x] Read the Contributing Guide and Policy and the Code of Conduct
• [ x] Searched the problem in issues
• [ x] Searched the problem in discussions
• [ x] Searched the problem in the docs
• [ x] Searched the problem in the chat
• [ x] Device used (e.g., Sonoff Basic): eachen zbbridge
• [x ] Tasmota binary firmware version number used: 9.5.0 and 9.5.0.3
  • [x ] Pre-compiled
  • [ x] Self-compiled (tried both)
• [x ] Flashing tools used: serial programmer
• [x ] Provide the output of command: Backlog Template; Module; GPIO 255:

14:06:47.496 RSL: RESULT = {"NAME":"ZHA-bridge","GPIO":[0,0,5472,0,5504,0,0,0,5793,5792,320,544,5536,0,5600,0,0,0,0,5568,0,0,0,0,0,0,0,0,608,640,32,0,0,0,0,0],"FLAG":0,"BASE":1}
14:06:47.717 RSL: RESULT = {"Module":{"0":"ZHA-bridge"}}
14:06:47.956 RSL: RESULT = {"GPIO0":{"0":"None"},"GPIO1":{"0":"None"},"GPIO2":{"5472":"TCP Tx"},"GPIO3":{"0":"None"},"GPIO4":{"5504":"TCP Rx"},"GPIO5":{"0":"None"},"GPIO9":{"0":"None"},"GPIO10":{"0":"None"},"GPIO12":{"5793":"Zigbee Rst2"},"GPIO13":{"5792":"Zigbee Rst1"},"GPIO14":{"320":"Led_i1"},"GPIO15":{"544":"LedLink"},"GPIO16":{"5536":"ETH POWER"},"GPIO17":{"0":"None"},"GPIO18":{"5600":"ETH MDIO"},"GPIO19":{"0":"None"},"GPIO20":{"0":"None"},"GPIO21":{"0":"None"},"GPIO22":{"0":"None"},"GPIO23":{"5568":"ETH MDC"},"GPIO24":{"0":"None"},"GPIO25":{"0":"None"},"GPIO26":{"0":"None"},"GPIO27":{"0":"None"},"GPIO28":{"0":"None"},"GPIO29":{"0":"None"},"GPIO30":{"0":"None"},"GPIO31":{"0":"None"},"GPIO32":{"608":"I2C SCL1"},"GPIO33":{"640":"I2C SDA1"},"GPIO34":{"32":"Button1"},"GPIO35":{"0":"None"},"GPIO36":{"0":"None"},"GPIO37":{"0":"None"},"GPIO38":{"0":"None"},"GPIO39":{"0":"None"}}
14:06:52.920 RSL: STATE = {"Time":"2021-10-12T14:06:52","Uptime":"0T00:40:10","UptimeSec":2410,"Heap":182,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":19,"MqttCount":0,"Wifi":{"AP":1,"SSId":"wifi6","BSSId":"B0:95:75:B4:09:7E","Channel":2,"Mode":"11n","RSSI":100,"Signal":-37,"LinkCount":1,"Downtime":"0T00:00:05"}}

• If using rules, provide the output of this command: Backlog Rule1; Rule2; Rule3:

  14:10:48.211 RSL: RESULT = {"Rule1":{"State":"ON","Once":"OFF","StopOnError":"OFF","Length":37,"Free":474,"Rules":"on system#boot do TCPStart 8888 endon"}}
14:10:48.435 RSL: RESULT = {"Rule2":{"State":"ON","Once":"OFF","StopOnError":"OFF","Length":30,"Free":481,"Rules":"on system#boot do Wifi 0 endon"}}
14:10:48.685 RSL: RESULT = {"Rule3":{"State":"OFF","Once":"OFF","StopOnError":"OFF","Length":0,"Free":511,"Rules":""}}

• [ x] Provide the output of this command: Status 0:

  STATUS 0 output here:
14:11:51.087 CMD: status 0
14:11:51.092 RSL: STATUS = {"Status":{"Module":0,"DeviceName":"Tasmota","FriendlyName":["Tasmota"],"Topic":"tasmota_D09F78","ButtonTopic":"0","Power":0,"PowerOnState":3,"LedState":1,"LedMask":"FFFF","SaveData":1,"SaveState":1,"SwitchTopic":"0","SwitchMode":[0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0],"ButtonRetain":0,"SwitchRetain":0,"SensorRetain":0,"PowerRetain":0,"InfoRetain":0,"StateRetain":0}}
14:11:51.098 RSL: STATUS1 = {"StatusPRM":{"Baudrate":115200,"SerialConfig":"8N1","GroupTopic":"tasmotas","OtaUrl":"http://ota.tasmota.com/tasmota32/release/tasmota32.bin","RestartReason":"Software reset CPU","Uptime":"0T00:00:17","StartupUTC":"2021-10-12T13:11:34","Sleep":50,"CfgHolder":4617,"BootCount":7,"BCResetTime":"2021-10-12T13:12:41","SaveCount":17}}
14:11:51.104 RSL: STATUS2 = {"StatusFWR":{"Version":"9.5.0(tasmota)","BuildDateTime":"2021-10-07T23:03:22","Core":"1_0_6","SDK":"v3.3.5-1-g85c43024c","CpuFrequency":240,"Hardware":"ESP32-D0WDQ6-V3","CR":"377/699"}}
14:11:51.109 RSL: STATUS3 = {"StatusLOG":{"SerialLog":0,"WebLog":2,"MqttLog":0,"SysLog":0,"LogHost":"","LogPort":514,"SSId":["wifi6",""],"TelePeriod":300,"Resolution":"558180C0","SetOption":["00008009","2805C8000100060000005A0A000000000000","00000080","00004000","00000000"]}}
14:11:51.116 RSL: STATUS4 = {"StatusMEM":{"ProgramSize":1445,"Free":1856,"Heap":222,"PsrMax":0,"PsrFree":0,"ProgramFlashSize":4096,"FlashSize":4096,"FlashFrequency":40,"FlashMode":2,"Features":["00000809","8FDAC787","00540001","000000CF","010013C0","40000981","40024000","00200000","0000002C"],"Drivers":"1,2,3,4,5,7,8,9,10,12,20,21,23,24,26,27,29,41,50,52,82","Sensors":"1,2,3,5,6,87"}}
14:11:51.122 RSL: STATUS5 = {"StatusNET":{"Hostname":"tasmota_D09F78-8056_eth","IPAddress":"192.168.1.175","Gateway":"192.168.1.1","Subnetmask":"255.255.255.0","DNSServer":"8.8.8.8","Mac":"94:B9:7E:D0:9F:7B","Webserver":2,"WifiConfig":4,"WifiPower":17.0}}
14:11:51.126 RSL: STATUS6 = {"StatusMQT":{"MqttHost":"","MqttPort":1883,"MqttClientMask":"DVES_%06X","MqttClient":"DVES_D09F78","MqttUser":"DVES_USER","MqttCount":0,"MAX_PACKET_SIZE":1200,"KEEPALIVE":30,"SOCKET_TIMEOUT":4}}
14:11:51.131 RSL: STATUS7 = {"StatusTIM":{"UTC":"2021-10-12T13:11:51","Local":"2021-10-12T14:11:51","StartDST":"2021-03-28T02:00:00","EndDST":"2021-10-31T03:00:00","Timezone":"+01:00","Sunrise":"07:06","Sunset":"18:06"}}
14:11:51.138 RSL: STATUS10 = {"StatusSNS":{"Time":"2021-10-12T14:11:51","ESP32":{"Temperature":53.3},"TempUnit":"C"}}
14:11:51.143 RSL: STATUS11 = {"StatusSTS":{"Time":"2021-10-12T14:11:51","Uptime":"0T00:00:17","UptimeSec":17,"Heap":221,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":19,"MqttCount":0}}

• Set weblog to 4 and then, when you experience your issue, provide the output of the Console log:

  Console output here:

TO REPRODUCE

Enable ZHA template. Disconnect power. Reconnect power. Try connecting ZHA

EXPECTED BEHAVIOUR

SCREENSHOTS

If applicable, add screenshots to help explain your problem.

ADDITIONAL CONTEXT

Initially raised the issue in zigpy/bellows:
zigpy/bellows#440
They recommended I open an issue here as it appears to be a tasmota problem.
I have tried precompiled 9.5.0.3 and self compiled 9.5.0. I tried with wifi and ethernet IP addresses and with wifi enabled and disabled. I tried both versions of the zigbee radio firmware. I double checked that TCP is running, and manually tried restarting it with tcpstart 8888. In Tasmota 9.5.0.3 I get several "TCP connected" messages from the IP of my HA server, but ZHA isnt connecting . In 9.5.0 I do not see those messages.

These are the templates I use:

backlog Template {"NAME":"ZB-GW03-V1.2","GPIO":[0,0,3552,0,3584,0,0,0,5793,5792,320,544,5536,0,5600,0,0,0,0,5568,0,0,0,0,0,0,0,0,608,640,32,0,0,0,0,0],"FLAG":0,"BASE":1} ; module 0

backlog template {"NAME":"ZHA-bridge","GPIO":[0,0,5472,0,5504,0,0,0,5793,5792,320,544,5536,0,5600,0,0,0,0,5568,0,0,0,0,0,0,0,0,608,640,32,0,0,0,0,0],"FLAG":0,"BASE":1} ; module 0

(Please, remember to close the issue when the problem has been addressed)

[jon6fingrs]

Hey I noticed the same thing. I think it has to do with the zigbee radio not being able to reset. I worked out a couple rules to automatically toggle between Z2T and ZHA which fixes it. I posted it here.

https://thehelpfulidiot.com/update-a-wired-sonoff-zigbee-alternative

[MattWestb]

Silab is recommending implanting hardware pin for resetting the Zigbee chip as one fallback and the original WiFi is having it but i dont knowing if the Eth version do.

Both first gen and second gen EFR32MG is working very well with software reset if the communication it is working OK and its only needing the reset pin for debricking chips if have flashing somthing bad like bootloader is wrong place with SWD.

Second clue is that Tube0013 EFR32MG2X devices with ESPHome is not having this problem so its somthing to do with tasmota ESP32 is not setting up the hardware UART OK after cold boot.
(The old module SM-011 was not having this kind of problem and is not expected with the updated module but you never knowing)

Have some trying changing the comport parameters like speed and flow control and see if the communication is start working ?
If then it can being one "faster way" for one work around and dont need restart the ESP32.

Still good is that the workaround is working :-))

[blakadder]

Try building using tasmota32idf4 environment that fixes some serial bugs in arduino core

[Jason2866]

After a soft restart the UART (serial connection Gpio 16 / 17) is not working correctly.
It is a known bug in the underlying IDF code. espressif/esp-idf#1981 (comment) This bug can not solved from Tasmota code.
Issue is related to #13445

[Jason2866]

Please try latest version from the link provided here #13445 (comment)
The i2c bug is fixed.

[jon6fingrs]

Hey that worked great. Thanks!

[ascillato2]

Thanks for reporting

[R5fan]

Its not solved for me, please reopen. The firmware linked in #13445 (comment) doesnt work for me, or the author of that issue. It bricks the device, with a red blinking led, and no web interface. pinging the device does work though.

[s-hadinger]

I just pushed a fix for IDF4.4 that could create a bootloop. To break the bootloop, try to connect to the Tasmota console and type module 1. You have ~10-20s window to do it.

After flashing the patched version, you can enable back Zigbee with module 0. The patched version should be available tomorrow.

[Trilis29]

Does Ethernet works for you? I have tried with my Mikrotik router DHCP offers IP but it's not getting bound...

[jon6fingrs]

Someone mentioned on the HA forum that you may need to specify 100mbps at your router if it doesn't autonegotiate the speed.

[Trilis29]

this has already been done, tried half duplex full duplex 100mb 10mb.... Console shows 100mbps Full Duplex connected after few seconds disconnected.

[perexg]

It seems that my little patch in #13874 resolves this issue. The RST (reset) pins must be always initialized, otherwise the ZigBee module does not respond on the cold boot. No more GPIO config toggling is required. Just start the TCP server using a BackLog rule on boot.

[MattWestb]

Great finding and fix !!

Is it the same for Sonoff ZBB ?
I asking then its looks like ZHA user is having problem with 10.X tasmota connecting to ZHA and 9.X have working great.

[perexg]

Great finding and fix !!

Is it the same for Sonoff ZBB ? I asking then its looks like ZHA user is having problem with 10.X tasmota connecting to ZHA and 9.X have working great.

I think that any hardware with the hardware reset pins is affected. You may give a test and report your result here. I'm running latest 10.X on eWelink bridge.

[MattWestb]

I running one IKEA FER32MG1P module on one WeMos D1 Mini but without hardware reset connected and one old Tasmota and i dont touching it then tasmota is not liking tricking to much around and its working OK.