That link above SPECIFICALLY says not to use core 2.4 because it has bugs. I am using sleep 0 with core 2.5
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
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
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.
Hello guys! How about the newer versions of Tasmota? Has anyone tested with core 2.3? Thanks.
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.
Iāve updated my sonoffs from 5.12 to 6.4.1 yesterday. It took me two nights to stabilize my setup. 
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.
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ā¦
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). 
Yeah I found 5.14 and even 6.3 were really good and stable (before they ditched core 2.3 for 2.4.2)
- Jan.: Devices prefixed by āSonoffā are Tasmota 5.12 devices
- Jan.: Devices updated to 6.4.1 SDK 2.4.2. Later the day 6.4.1 SDK 2.5.0.
- 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.
1 Like
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.
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.
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.
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
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.
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.
Iām using Core 2.3.0 now. No issues for 12 hours.
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.