Sonoff basic tasmota lag when turning it on/off

Platform: Openhab 3 on ubuntu 20.04 on raspberry pi 4
Sonoff basic running Tasmota 9.2.0 by Theo Arends

Hello all,

I’ve been noticing some lag lately in some of my sonoff devices running tasmota.

Firing an on/off event from openhab mobile app or web app triggers the switch on openhab immediately:

2022-01-31 22:34:08.621 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'SonoffBasic22_SonoffBasic22' received command ON
2022-01-31 22:34:08.622 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'SonoffBasic22_SonoffBasic22' predicted to become ON
2022-01-31 22:34:08.634 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'SonoffBasic22_SonoffBasic22' changed from OFF to ON

But actually the lights turn on after 4-5 seconds.

Is there any settings that can help reduce this lag? I tried to change mqtt broker qos from 0 to 1 but this does not seem to have any effect.

Thanks

Configuration of this particular sonoff:

UID: mqtt:topic:398e2a4556:dc17131da9
label: Sonoff Basic 22
thingTypeUID: mqtt:topic
configuration:
  payloadNotAvailable: Offline
  availabilityTopic: tele/tasmota-FBD17F/LWT
  payloadAvailable: Online
bridgeUID: mqtt:broker:398e2a4556
channels:
  - id: SonoffBasic22
    channelTypeUID: mqtt:switch
    label: Sonoff Basic 22
    description: null
    configuration:
      commandTopic: cmnd/tasmota-FBD17F/POWER
      stateTopic: stat/tasmota-FBD17F/POWER
      off: OFF
      on: ON

Configuration of the mqtt broker:

UID: mqtt:broker:398e2a4556
label: MQTT Broker
thingTypeUID: mqtt:broker
configuration:
  lwtQos: 1
  publickeypin: true
  keepAlive: 60
  clientid: e3de8a74-1a5e-4485-9a23-6b6f3de29832
  qos: 1
  reconnectTime: 60000
  port: 1883
  host: 192.168.1.10
  secure: false
  certificatepin: true
  lwtRetain: true
  enableDiscovery: true

Next step is to work out when the message reaches your MQTT Broker - use MQTT Explorer or MQTT.fx to monitor your broker.

1 Like

Thanks @hafniumzinc anything specific to look for in mqtt explorer?

I noticed below in the particular topic. Also noticed that the lag does not happen every single time - when turning it on/off repeatedly. the lag happens approximately 1 out of 8 times.

cmnd
tasmota-FBD17F
POWER = ON  ----> this turns on immediately
stat
tasmota-FBD17F
RESULT = {"POWER":"ON"} ----> this remains off and turns on when the light turns on after 4-5 seconds
POWER = ON

So you’re saying that data into the MQTT broker on the cmnd topic is almost instantaneous, but data on the RESULT topic is much slower?

The cmnd topic comes from openHAB, so if the above is true then openHAB seems to be running fine.

The stat/.../RESULT topic comes from Tasmota, so if the above is true then there seems to be an issue within Tasmota itself.

Next thing to check: go to the Tasmota console and watch that as you switch the light on and off with openHAB.

1 Like

That’s right for both the statements.

The behavior is as below when checking on tasmota console.

Turn on lights:
Immediately on openhab:

2022-02-01 09:50:12.503 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'SonoffBasic22_SonoffBasic22' received command ON
2022-02-01 09:50:12.505 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'SonoffBasic22_SonoffBasic22' predicted to become ON
2022-02-01 09:50:12.513 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'SonoffBasic22_SonoffBasic22' changed from OFF to ON

After 4-5 seconds, on tasmota console when the lights turn on:

18:37:13.621 MQT: stat/tasmota-FBD17F/RESULT = {"POWER":"ON"}
18:37:13.625 MQT: stat/tasmota-FBD17F/POWER = ON
18:41:25.435 MQT: tele/tasmota-FBD17F/STATE = {"Time":"1970-01-13T18:41:25","Uptime":"7T16:10:14","UptimeSec":663014,"Heap":27,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":19,"MqttCount":220,"POWER":"ON","Wifi":{"AP":1,"SSId":"XXX","BSSId":"XXX","Channel":6,"RSSI":100,"Signal":-35,"LinkCount":1,"Downtime":"0T00:00:06"}}

Also, using the toggle from tasmota turns lights on/off immediately:

18:43:16.024 MQT: stat/tasmota-FBD17F/RESULT = {"POWER":"OFF"}
18:43:16.027 MQT: stat/tasmota-FBD17F/POWER = OFF
18:43:18.093 MQT: stat/tasmota-FBD17F/RESULT = {"POWER":"ON"}
18:43:18.097 MQT: stat/tasmota-FBD17F/POWER = ON
18:43:19.682 MQT: stat/tasmota-FBD17F/RESULT = {"POWER":"OFF"}
18:43:19.686 MQT: stat/tasmota-FBD17F/POWER = OFF
18:43:21.061 MQT: stat/tasmota-FBD17F/RESULT = {"POWER":"ON"}
18:43:21.065 MQT: stat/tasmota-FBD17F/POWER = ON
18:43:22.470 MQT: stat/tasmota-FBD17F/RESULT = {"POWER":"OFF"}
18:43:22.474 MQT: stat/tasmota-FBD17F/POWER = OFF

Can you set the date of your tasmota device correctly? I don’t know much about what’s going on in MQTT in the background, but it could be that you have problems since the time/date of your broker and your device are not really in sync.
openHAB and the broker are in 2022, your tasmota device is in the 70s :man_dancing:

1 Like

Try “SetOptions41” in your tasmota device, change it to

SetOption41 30
1 Like

Lol true. I’ve changed it but it seems that a reboot/powercut defaults it back to the 70s :slight_smile:
After changing the time, timezone and ntpserver as below, it seems to be better but I did get the lag a couple of times. I’m currently facing some power cuts and can’t test more extensively, will try and reproduce the lag tomorrow and feedback.

00:05:56.538 CMD: ntpserver
00:05:56.545 MQT: stat/tasmota-FBD17F/RESULT = {"NtpServer1":"mu.pool.ntp.org","NtpServer2":"nl.pool.ntp.org","NtpServer3":"0.nl.pool.ntp.org"}
00:06:07.058 CMD: time
00:06:07.066 MQT: stat/tasmota-FBD17F/RESULT = {"Time":"1970-01-01T00:06:07"}
00:08:13.530 CMD: timezone +04:00
00:08:13.537 MQT: stat/tasmota-FBD17F/RESULT = {"Timezone":"+04:00"}
00:08:29.482 CMD: status 7
00:08:29.491 MQT: stat/tasmota-FBD17F/STATUS7 = {"StatusTIM":{"UTC":"1970-01-01T00:08:29","Local":"1970-01-01T00:08:29","StartDST":"1970-01-01T00:00:00","EndDST":"1970-01-01T00:00:00","Timezone":"+00:00","Sunrise":"20:13","Sunset":"05:47"}}
00:08:46.440 CMD: time 1643726904
00:08:46.448 MQT: stat/tasmota-FBD17F/RESULT = {"Time":"1970-01-01T00:08:46","Epoch":1643726903}
18:48:30.488 CMD: status 7
18:48:30.498 MQT: stat/tasmota-FBD17F/STATUS7 = {"StatusTIM":{"UTC":"2022-02-01T14:48:30","Local":"2022-02-01T18:48:30","StartDST":"1970-01-01T00:00:00","EndDST":"1970-01-01T00:00:00","Timezone":"+04:00","Sunrise":"11:20","Sunset":"20:46"}}

Thanks, I updated this. Will test and feedback tomorrow. It was set to 0 - you think the reason for the lag might be that the sonoff and wifi network gets “disconnected”?

00:07:37.402 CMD: SetOption41
00:07:37.408 MQT: stat/tasmota-FBD17F/RESULT = {"SetOption41":0}
00:08:13.569 CMD: SetOption41 30
00:08:13.576 MQT: stat/tasmota-FBD17F/RESULT = {"SetOption41":30}

I had the same problem. After watching the LWT status from my devices i saw that they disconect from time to time just for a few seconds.
Since i set SetOption41 to 30 everything is working as expected.

Tasmota2

It is somewhere around half a second

1 Like

Thanks @Rolli @Sascha_Billian @hafniumzinc

I’m getting other issues now following the power cuts and am researching on tasmota forums - basically around 6 out of 20 sonoff devices (including 22 on which I was testing) did not come up after the multiple outages and they are not responding, as in:

  1. no effect of tripping the breaker to cause it to reboot again
  2. no led lights on the device light up
  3. pressing the button on the sonoff does not do anything (on the other hand on the working sonoff devices, pressing the button turns on/off the lights connected to it
  4. no AP displayed which means it did not reset

Seems to be a known issue… https://github.com/arendst/Tasmota/issues/5163

As for the lag, for now I’ve reconfigured all the sonoff devices that are up (local ntpserver for correct time + SetOption41 30) and the response time observed is definitely much better :slight_smile:

Thanks!

1 Like

That is such an unexpected effect :crazy_face:

I have a Sonoff Basic in a similar state. I’m pretty sure it does power up (I am able to reflash it, for example) but I think something with the WiFi is broken. On first boot up it no longer presents as an access point. Are you sure yours are definitely dead, rather than just not connecting with WiFi?

Not sure, I think it’s unlikely that 5-6 devices drop dead (hope not :expressionless:)
I’ll have to check whether it’s drawing power before taking it out. Now am trying to find out ways to reset it without taking it out of the circuit and flashing through serial connection like I did originally using tasmotizer.
How are you reflashing it by the way?

Hold the button (Button1) down, if available, for 40 seconds. After that the device should reset and reboot. Fully cycle power after that is done to make sure everything is starting from scratch.

Or this?

  1. Cut power from the device completely for 30 seconds
  2. Power the device on and off six times with intervals lower than 10 seconds and leave it on after seventh time
  3. Fast power cycle device recovery should activate and the device should be reset to firmware defaults

As i had the plroblem with the slow respond of the sonoff´s, i tryed all possible settings with the wifi connection.

SetOption 127 1 //default 0
SetOption 60 1  //default 0

Those options froze the sonoffs as you described, a reflash broght them back up.
My setup is now as follows.

SetOption 127 0
SetOption 60 0 
SetOption 57 1 
SetOption 41 30  

I always powercycle my devices if a reset is needed.

Oh I see. Likely the same issue then. How did you reflash, take it out, connect USB serial and tasmotise?

In that case i took the devices out of the circuit and reflashed via USB to TTL and VisualStudioCode and Platformio.
With that software i compile also my own binary files.
If you do so and you have to powercycle your device, it connects directly to your wifi network.

Did you try to powercycle your devices?

Oh, I actually mean properly reflashing with a new Tasmota using the USB to serial adaptor I have. Yeah, like you, no combination of startup voodoo made the thing come to apparent life!

Yes a few times, no luck.

I’ll disconnect and flash them over the weekend.

Lol. Indeed looks like it.