Constant MQTT devices disconnections (socket error)

mqtt
Tags: #<Tag:0x00007fd073a7b188>

#21

That link above SPECIFICALLY says not to use core 2.4 because it has bugs. I am using sleep 0 with core 2.5


#22

I found that out the hard way but it was 2.4.2 which is included in the latest stable pre compiled binaries so it was easy to fall into this problem with a standard OTA update…

I couldn’t work out if sleep 0 will turn off power saving, I have a lot of devices now so would want power saving to be as high as possible. I usually use sleep 250.

I think I will try 6.4.1 with 2.5.0 core

Versions compiled using 2.5.0 are labelled as beta


#23

Hello guys! Any advise on devices running version 5.14? All my sonoffs (21) are installed inside lamps, ceilings and all sorts of hard to access places. If there is an OTA solution will be much appreciated. I can take down all of them but would be my last move. Thanks


#24

Hey my friend… try this :slight_smile:
https://github.com/reloxx13/TasmoAdmin


#25

In my network (Asus router with Merlin firmware), the most stable connection I have with any Tasmota version with core 2.3 (dynamic sleep 50). With core 2.4.2 or 2.5 I have disconnect every few minutes.


#26

Hello guys! How about the newer versions of Tasmota? Has anyone tested with core 2.3? Thanks.


#27

2.3??? that is OLD. Latest Tasmota uses 2.4.2 by default. I have had nothing but trouble with dropouts with that so I switched to core 2.5.0 (compiling my own firmware). It’s much more stable but still not as good as 2.3 I also found setting sleep 50 crashed an inconveniently mounted Sonoff SV and I had to open it up again and reflash it.

I don’t see any reason 2.3 wouldn’t work with newer firmware. It says with 2.3 it’s not compatible with Mesh and has issues with Fritzbox router for one but I never saw that. It also seems like it plays nice with auto channel whereas 2.5 does not.

When you look at the release information it’s almost like asking if you want to be shot or hung as there’s issues everywhere you turn.


#28

I’ve updated my sonoffs from 5.12 to 6.4.1 yesterday. It took me two nights to stabilize my setup. :frowning: Lesson learned: Use SDK 2.5.0 for a stable WiFi connection. At the moment the MQTT connection is dropped occasionally (socket error). I use 3 devices with different settings now (12.01.2019 9:00):

sonoff-diningtable: Sleep 0
sonoff-workbench: SetOption60 1
sonoff-coffee: defaults

I hope one of the settings will bring back the stability from 5.12.


#29

Sleep 0 totally locked up one of my SV’s (The most inaccessible one of course). Needed to reflash it. Beware sleep 0 (yes I know they say to use it) I think I’m on sleep 50 now (the default)

Core 2.5 is pretty stable for me…


#30

I’m trying to gather some availability availibility graphs from HA at the moment. Compared to 5.12 it’s a mess (for me at the moment). :wink:


#31

Yeah I found 5.14 and even 6.3 were really good and stable (before they ditched core 2.3 for 2.4.2)


#32

  1. Jan.: Devices prefixed by “Sonoff” are Tasmota 5.12 devices
  2. Jan.: Devices updated to 6.4.1 SDK 2.4.2. Later the day 6.4.1 SDK 2.5.0.
  3. Jan.: Tasmota 6.4.1 SDK 2.5.0 drops the MQTT connection. I’ve changed some MQTT Server settings this morning (enable debug mode): Downtime for all devices. I will provide another graph tomorrow.

#33

For me Tasmota 6.4.1 with core 2.3 http://thehackbox.org/tasmota/release/020300/ has very stable WiFi connection. With core 2.4.x and 2.5 my switches very often are unavailable.


#34

This is the mosquitto.log of a dropped MQTT connection:

1547288042: Sending PINGRESP to sonoff-workbench
1547288052: Received PINGREQ from sonoff-workbench
1547288052: Sending PINGRESP to sonoff-workbench
1547288062: Received PINGREQ from sonoff-workbench
1547288062: Sending PINGRESP to sonoff-workbench
1547288072: Received PINGREQ from sonoff-workbench
1547288072: Sending PINGRESP to sonoff-workbench
1547288082: Received PINGREQ from sonoff-workbench
1547288082: Sending PINGRESP to sonoff-workbench
1547288083: Received PUBLISH from sonoff-workbench (d0, q0, r0, m0, 'tele/sonoff-workbench/STATE', ... (208 bytes))
1547288083: Received PUBLISH from sonoff-workbench (d0, q0, r0, m0, 'tele/sonoff-workbench/SENSOR', ... (225 bytes))
1547288083: Sending PUBLISH to homeassistant (d0, q0, r0, m0, 'tele/sonoff-workbench/SENSOR', ... (225 bytes))
1547288093: Received PINGREQ from sonoff-workbench
1547288093: Sending PINGRESP to sonoff-workbench
1547288103: Received PINGREQ from sonoff-workbench
1547288103: Sending PINGRESP to sonoff-workbench
1547288118: Client sonoff-workbench has exceeded timeout, disconnecting.
1547288118: Socket error on client sonoff-workbench, disconnecting.
1547288118: Sending PUBLISH to homeassistant (d0, q0, r0, m0, 'tele/sonoff-workbench/LWT', ... (7 bytes))
1547288128: New client connected from 192.168.130.33 as sonoff-workbench (c1, k10, u'sensors').
1547288128:     tele/sonoff-workbench/LWT
1547288128: Sending CONNACK to sonoff-workbench (0, 0)
1547288128: Received PUBLISH from sonoff-workbench (d0, q0, r1, m0, 'tele/sonoff-workbench/LWT', ... (6 bytes))
1547288128: Sending PUBLISH to homeassistant (d0, q0, r0, m0, 'tele/sonoff-workbench/LWT', ... (6 bytes))
1547288128: Received PUBLISH from sonoff-workbench (d0, q0, r0, m0, 'cmnd/sonoff-workbench/POWER', ... (0 bytes))
1547288128: Received SUBSCRIBE from sonoff-workbench
1547288128:     cmnd/sonoff-workbench/# (QoS 0)

There should be a PING (request/response) every 10 seconds. If there is no PING for > 15 seconds (keepalive) the MQTT server drops the connection.


#36

I upgraded some Sonoff’s from Tasmota 5.8.0 core 2.4.0_RC1 to 6.4.1 core 2.4.2 and my Mosquitto v4 logs are filled with socket errors and disconnects. I don’t see any issues with WiFi disconnects at this time.

I am going to follow this thread to seek solution.


#37

As next step I tried the firmware binaries from http://thehackbox.org/tasmota/020500/. Because of the MQTT error I made a custom build with a MQTT Keepalive of 30 seconds. This changed the log a bit:

1547307857: Received PINGREQ from sonoff-workbench
1547307857: Sending PINGRESP to sonoff-workbench
1547307867: Received PINGREQ from sonoff-workbench
1547307867: Sending PINGRESP to sonoff-workbench
1547307877: Received PINGREQ from sonoff-workbench
1547307877: Sending PINGRESP to sonoff-workbench
1547307887: Received PINGREQ from sonoff-workbench
1547307887: Sending PINGRESP to sonoff-workbench
1547307897: Received PINGREQ from sonoff-workbench
1547307897: Sending PINGRESP to sonoff-workbench
1547307908: Received PINGREQ from sonoff-workbench
1547307908: Sending PINGRESP to sonoff-workbench
1547307919: Client sonoff-workbench already connected, closing old connection.
1547307919: Socket error on client sonoff-workbench, disconnecting.
1547307919: New client connected from 192.168.130.33 as sonoff-workbench (c1, k10, u'sensors').
1547307919:     tele/sonoff-workbench/LWT
1547307919: Sending CONNACK to sonoff-workbench (0, 0)
1547307919: Sending PUBLISH to homeassistant (d0, q0, r0, m0, 'tele/sonoff-workbench/LWT', ... (7 bytes))
1547307919: Received PUBLISH from sonoff-workbench (d0, q0, r1, m0, 'tele/sonoff-workbench/LWT', ... (6 bytes))
1547307919: Sending PUBLISH to homeassistant (d0, q0, r0, m0, 'tele/sonoff-workbench/LWT', ... (6 bytes))
1547307919: Received PUBLISH from sonoff-workbench (d0, q0, r0, m0, 'cmnd/sonoff-workbench/POWER', ... (0 bytes))
1547307919: Received SUBSCRIBE from sonoff-workbench

This time the MQTT server doesn’t abort the connection because of a timeout (because it’s bigger now). Instead the Sonoff opens a new connection (because the old one died silently). My WiFi isn’t flacky in general. There is no raeson for delays >10 seconds. As next step I tried the SDK 3.0.0 / STAGE. This doesn’t solve the issue, too.

As last step I’m using the suggested Core 2.3 build as @Bieniu suggested. This is the same Core as my previous setup with Tasmota 5.12. Hopefully it will solve the issue. This is a nice write up for toubleshooting: https://github.com/arendst/Sonoff-Tasmota/wiki/Troubleshooting#wifi-issues-arduino-core-versions-and-expressif-sdk


#38

I after upgrading to the Mosquitto addon v4, I was getting lots of socket errors and disconnects showing in the Mosquitto log. I did have mqtt: and a bunch of settings in the configuration.yaml file left over from the Mosquitto v1. I also have each mqtt switch speicifed in that file.

I read that i needed to comment out those sections, save, check and restart. After doing so, my switches checked in and showed in the MQTT log, but did not show up in the Overview anymore.

So then I read about the Integrations in the Configuration menu. There was an option called “MQTT” and when I clicked on it, a popup dialog asked for IP, port, username and password as well as if I wanted automatic “Discovery”, which I said yes.

After another restart, my switches showed up again in the Overview and functioned correctly.
If I go back to MQTT Integrations, it reports “This integration has no devices”, which i have read is only for devices that were “Discovered” and since all mine are in the configuration.yaml file, it made sense.

I am using Sonoff switches flashed with Tasmota firmware. I can’t turn on MQTT_HOST_DISCOVERY in their firmware becasue my wife just bought am iRobot e6 from Costco and it has its own little local MQTT broker in it to talk to its phone APP. That makes all my Sonoff switches MQTT settings get overwritten to the iRobot’s IP address and they lose connection to HASS.IO’s Mosquitto broker obviously. SO no auto discovery for me!

Anyway, I am still getting socket errors and disconnects:

1547321982: New client connected from 192.168.1.33 as Sonoff-071A07 (c1, k60, u’mqttusername’).
1547322598: Socket error on client Sonoff-BD34A2, disconnecting.
1547322599: New connection from 192.168.1.30 on port 1883.
[INFO] found mqttusername on local database
1547322599: New client connected from 192.168.1.30 as Sonoff-BD34A2 (c1, k60, u’mqttusername’).
1547322657: New connection from 192.168.1.30 on port 1883.
[INFO] found mqttusername on local database
1547322658: Client Sonoff-BD34A2 already connected, closing old connection.
1547322658: Client Sonoff-BD34A2 disconnected.
1547322658: New client connected from 192.168.1.30 as Sonoff-BD34A2 (c1, k60, u’mqttusername’).

I am also getting some weird connections like:

1547321294: New client connected from 192.168.1.180 as 0a5595e8-e627-4aa8-880c-e51a560b182b (c1, k60, u’mqttusername’).

The part after the “as” is undecipherable and I never had anything look like that with v1.

Need help with fixing the socket errors.


#39

When I look at the table listing issues with different core’s, 2.3 has some gotchas as well. I’m using a Fritzbox and also Mesh. I switched from using auto channel on my WiFi. So from the notes, it seems as if 2.5 is the best core for me to use. Having said that I had 100% stability with 2.3 core in firmware 6.3 so go figure.

Even though I get ‘dropouts’ they seem to last only for a second and maybe I get 1 every few hours. I’d have to be pretty unlucky to get a dropout in the middle of an automation action so I think I can live with it for now and I guess they will eventually fix it.


#40

I’m using Core 2.3.0 now. No issues for 12 hours.


#41

I have the identical issue with some r1 basics (upgraded them all to R2 boards and issue went away in all but 1) and a T3 switch which i cannot resolve. The switch is now running (was on 5.12 with same issue)
Core/SDK Version 2_4_2/2.2.1(cfd48f3)
Program Version 6.4.1(sonoff) (was on 5.12 with same issue)

When checking console log on the switch you see
17:14:27 MQT: Attempting connection…
17:14:28 MQT: Connected
and when checking the Mosquitto log
1547828049: Client DVES_9876A2 has exceeded timeout, disconnecting.
1547828049: Socket error on client DVES_9876A2, disconnecting.
1547828050: New connection from 192.168.1.149 on port 1883.
[INFO] found DVES_USER on local database
1547828050: New client connected from 192.168.1.149 as DVES_9876A2 (c1, k10, u’DVES_USER’).
1547828061: Client DVES_B0EEA1 has exceeded timeout, disconnecting.
1547828061: Socket error on client DVES_B0EEA1, disconnecting.

Any ideas how to debug it would be appreciated.