ZBbridge connection problems - Need to configure port 8888 every day. #18184
Comments
|
Two days ago I changed up two things in my setup:
Yesterday I first experienced this exact issue. ZHA also used the zbbridge on the same TCP port and had been rock solid for weeks. @ryny24 You say you upgraded Tasmota while trying to fiix this. What was the old version of Tasmota you had these problems with? If you also had this issue with Tasmota 12.3.1 or older, the combination of Zigbee2mqtt and Tasmota seems to be the culprit, as those versions worked just fine with ZHA. |
|
I don't know the exact version I flashed with, but whatever version was released before 6/14/22. Since then, I've upgraded maybe 3 times. Each one having the same issue from the beginning. Please let me know if you switch back to one (or both) of those, and the problem goes away. I would suggest ZHA first, as I've never had my ZBBridge on ZHA. |
|
I couldn't take it anymore. I tried switching the ZBBridge gateway to a Moes ZHUB Ethernet Gateway, and so far so good. My devices have been online for a week now. I'm not sure if the MOES is running Tasmota or not, but it works. The flashing process is here. |
|
Problem seems to be caused by zigbee2mqtt, not tasmota. I'm also switching to a different Zigbee Gateway that is better suited for use with Zigbee2mqtt. This issue can probably be closed. |
|
Z2M working rock solid now with my Moes ZHUB Ethernet Gateway. Will close this issue. |
|
I am running the following script using crontab every minute. This will restart tcp if it stops: #!/bin/bash
HOST=192.168.1.102
WEB_PORT=80
TCP_PORT=8888
if (nc -z -w 2 $HOST $WEB_PORT 2>&1 >/dev/null)
then
if !(nc -z -w 2 $HOST $TCP_PORT 2>&1 >/dev/null)
then
echo "[$(date)] tcp not running. Will start!" >> zbbridge.log
curl http://$HOST/cm?cmnd=TCPStart%20$TCP_PORT
fi
else
echo "[$(date)] zbbridge not reachable!" >> zbbridge.log
fi |
|
Why are you doing that? Why not a rule to start tcp at startup. The only reason tcp would stop is if you explicitly stop it or reboot |
|
@s-hadinger there is currently a bug in zigbee2mqtt (maybe also home-assistant) that somehow causes the tcp connection to crash. For me it also breaks the startup rule and I need to set the rule again. |
|
I must be missing some information. TCP connections don't crash. And if Z2M remotely makes Tasmota rules not to work, that is a serious bug that needs to be addressed. Can you provide more information? |
|
Well it's most definitely happening, at least, in terms of us needing to reconfigure the TCP port to get it working again. I switched to a different gateway to mitigate my problems, but I'll summarize it once more, it might help others experiencing this problem:
I never took the effort to use tcpdump to see what actually happens at the TCP level, the underlying cause might be at another level. However, me and others definitely needed to reconfigure the TCP port to get it working again. As this problem only occurs in recent versions of Z2M, and the changelog of Z2M reports several changes to the EZSP code in recent versions, I suspect the bug is in the Z2M codebase, not the Tasmota codebase. That's why I suggested the issue be closed here. |
|
You haven't provided any actual and detailed information and logs about Tasmota. TCPbridge would likely stop only on a restart so that's what you should track |
|
Ok. I think I get it now. You mean that the TCP connection is still alive but zigbee2mqtt can't use it anymore. Hence you need to restart tcp on Tasmota side to kill the previous connection? |
|
Hello, I am also encountering the same issue with the combination of HA(2023.7.3) + Zigbee2MQTT(v1.32.0, Coordinator Type EZSP V8, revision 6.7.8.0 build 373) + Sonoff ZBBridge(Tasmota 13.0.0). I have set the following rule to start the TCP on boot: However, that works until TCP crashes/stops and Z2M service is complaining that it's not able to connect to the bridge on port 8888. Testing it with telnet confirms: port is closed. I can confirm that the issue is happening exactly like @ryny24 described it. I am not an expert with Tasmota, but i would like to contribute by providing information, logs, anything - please suggest. So far i can tell:
Next that I will try(and report after):
However, I dare to say that Sonoff ZBBridge is not the best choice for HA+Z2M - not with the current (buggy) versions. I wish I knew that 2 year ago when I bought multiple bridges to cover all areas. |
|
Could you please decompose the problem and do some simple tests. When the problem occurs, can you check with a computer whether the TCP port is open on port 8888. It's unclear whether it's Z2M that can't connect, or if it's Tasmota that lost the TCP server. You mention TCP to "crash". Do you really see a Tasmota crash? Or is just the TCP port 8888 refusing connections? |
|
One more thing, what does the Tasmota logs says when you try to connect with TCP? |
|
Please try again with the latest version in development. #19199 might solve an IP filtering problem since we enabled IPv6. |
|
While I can't say for sure, yet, It looks like Tasmota is losing the TCP server. I believe that since the telnet from my computer(or any other device in the same network) to port 8888 fails.
I have downgraded Z2M to 1.29.2 for all bridges, also installed Tasmota 13.0.0.3 which includes the ip filter fix/feature on one(only) of the bridges and I configured a syslog-ng docker container which is now collecting all the logs from my tasmota(level 4 logging - more debug). As soon as I notice any issue with the current setup, I will post here. |
|
@s-hadinger I'm running tasmota 13.1.0 which should include #19199 but I'm still having the issue described in this thread. |
|
You didn't provide the logs. Did you get some? |
I periodically run |
@mklan |
|
Clearly, that script is not run on a Tasmota device, it would typically be on a Linux PC. |
|
Hello, Updated to 13.1.0 that I am running, same problem. Some random, but mostly at least once a day, it loses conection to my HA. |
|
Hi. I'm happy to work on this problem but nobody has provided any meaningful logs. I understand the symptoms, they have been clearly explained. Now we need logs from Tasmota when tcp connection fails |
|
Can you please help me how to obtain them? |
|
My Home Assistant reports that my Zigbee sensors went unavailable at 3:28:02 but due to 10 min delay in mqtt, the real time when it happened is 03:18:xx(or maybe 3:17:xx). I don't see anything abnormal but maybe the comm between the two MCUs may reveal something. ! private data was scrambled |
|
Same here, look at 8:42. Home Assistant reported data until 8:52(crash time + 10 min delay from MQTT) |
Hey, no it is running on a linux machine where my smart home system is running. I now switched to the sonoff usb stick. You can use zigpy to easily migrate without having to pair every device again. |
|
I tried by this order:
none of this worked. only copy and pasting the rule would work, for a day, and the process of losing conectivity would repeat. Googling, I read somewhere "I am running Tasmota 9.3.1 rock solid" and "I am running Tasmota 9.2.0 and don't have problems." I downgraded first to 9.3.1, had to run "module 75" in the console before flashing the zigbee firmware, because it said some error about signature. I lost my zigbee nodes, had to repair them all. for now it is running rock solid, for some days only, but it is more time than previously... |
|
As usual, as soon I made this comment, it lost the connection, 😄 but it seemed more robust, it held on for several days. to put it back to work, i just had to write "Rule 1" in tasmota console previously, i cpied and pasted the whole rule, I don't know if it's different or not |
|
I've been involved in some other discussions on the zigbee topics because of the same issue. The conclusion I got from there is that the zigbee coordinator running on the bridge and is pretty stable. So tasmota always communicates with the ZB chip on the board, and exposes the info on the port you set(usually 8888). The problem is that tasmota stops listening on port 8888 randomly(apparently). I am collecting logs from zbbridges on my Syslog server, and i've saw during the time that at the moment when the sensors became unavailable in Home Assistant, Syslog shows either ZbBridge restarts or Wifi disconnects. Considering this, i see the following:
My suggestion here, although i am sorry i can't help due to lack of programming knowledge, is that Tasmota should get a mechanism to restart the listener when the wifi connection is back, or listen on all interfaces. |
|
The listener is listening at |
|
not trying to be ironic or something, but you could stop the wifi router for a moment and see what happens after everything is back online. Also, listening on all interfaces may not be helpful if there is no other interface apart from the WIFI one. There must be at least loopback interface to prevent the listener drop. Is this the case with Tasmota? |
|
This wouldn't work because my router always gives back the same address if the device was already connected |
|
mine too. The idea is to make the listener crash when the WIFI drops, not necessary preventing the Tasmota to get the same IP after reconnecting. |
PROBLEM DESCRIPTION
I'm using a ZBBridge with Tasmota to Home Assistant (Zigbee2MQTT) for a year now. It works great, when it does. But almost every day or every other day I see my lights are offline. I restart Z2M but it won't connect until I enter this into the console of the ZBBridge
backlog rule1 on system#boot do TCPStart 8888 endon ; rule1 1 ; template {"NAME":"Sonoff ZHABridge","GPIO":[56,208,0,209,59,58,0,0,0,0,0,0,17],"FLAG":0,"BASE":18} ; module 0I've updated to the latest Tasmota. I've searched for others having this issue, and mapped a GPIO15 to a relay but that hasn't helped.
Thank you for your help!
REQUESTED INFORMATION
Make sure your have performed every step and checked the applicable boxes before submitting your issue. Thank you!
Backlog Template; Module; GPIO 255:Backlog Rule1; Rule2; Rule3:Status 0:weblogto 4 and then, when you experience your issue, provide the output of the Console log:TO REPRODUCE
Steps to reproduce the behavior:
EXPECTED BEHAVIOUR
A clear and concise description of what you expected to happen.
SCREENSHOTS
If applicable, add screenshots to help explain your problem.
ADDITIONAL CONTEXT
Add any other context about the problem here.
(Please, remember to close the issue when the problem has been addressed)
The text was updated successfully, but these errors were encountered: