physical buttons not working when wifi is down

[bkbartk]

PROBLEM DESCRIPTION

When My wifi is down I cannot use the physical buttons to turn on or off switches.

I have several different sonoff devices. This morning there was an issue with the wifi. Wifi was available, but I think the DHCP server failed to lease addresses.
The ugly think was that I was unable to turn on or off any of the lights.

Is it possible to have the inputs still working when there is a hickup with the wifi or internet?

REQUESTED INFORMATION

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

• [V ] Read the Contributing Guide and Policy and the Code of Conduct
• [V] Searched the problem in issues
• [V] Searched the problem in discussions
• [ V] Searched the problem in the docs
• [ V] Searched the problem in the chat
• [ v] Device used (e.g., Sonoff Basic): Sonoff Basic, Sonoff MINIR2,Sonoff T0 2CH
• Tasmota binary firmware version number used: Tasmota 10.1.0 by Theo Arends
  • [ v] Pre-compiled
  • [ v] Self-compiled
• [ f] Flashing tools used: OTA, Vs code with platform IO, Postman
• [v ] Provide the output of command: Backlog Template; Module; GPIO 255:

12:00:58.591 CMD: Backlog Template; Module; GPIO 255
12:00:58.672 MQT: stat/tasmota_E784A6/RESULT = {"NAME":"Generic","GPIO":[1,1,1,1,1,1,1,1,1,1,1,1,1,1],"FLAG":0,"BASE":18}
12:00:58.883 MQT: stat/tasmota_E784A6/RESULT = {"Module":{"1":"Sonoff Basic"}}
12:00:59.138 MQT: stat/tasmota_E784A6/RESULT = {"GPIO0":{"32":"Button1"},"GPIO1":{"0":"None"},"GPIO2":{"0":"None"},"GPIO3":{"0":"None"},"GPIO4":{"0":"None"},"GPIO5":{"0":"None"},"GPIO9":{"0":"None"},"GPIO10":{"0":"None"},"GPIO12":{"224":"Relay1"},"GPIO13":{"320":"Led_i1"},"GPIO14":{"0":"None"},"GPIO15":{"0":"None"},"GPIO16":{"0":"None"},"GPIO17":{"0":"None"}}

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

  Rules output here:

• Provide the output of this command: Status 0:

  Status 0

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

  can't do without wifi

TO REPRODUCE

disable DHCP server,
reboot the sonoff,
button fails to work

EXPECTED BEHAVIOUR

when there is no wifi, phisical buttons should still work

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)

[crllsn]

If it can help someone more expert than me: I was experiencing a similar problem with 9.X version (but it looks like it's fixed with 10.X). The real problem was that in case of wifi failure the device was losing the template config, resetting to "generic" so GPIO were misconfigured and wall button did not work.
Again this is not a solution, just a hint to help to investigate in right direction!

[pkkrusty]

I have a similar problem with a Sonoff Basic with a button attached to Rx pin. When my MQTT/Syslog/Influx server is down, the button is inoperative. Wifi and dhcp is available, unit has a static address in any case.

[charettepa]

I have the same issue with Sonoff mini and gosund light switch. I have tried all the 10.x versions.
Im not sure if its WiFi or DHCP or Network Connectivity, but when its unreachable the buttons stop working.
I have made some network configuration changes that seem to help, however there is still an issue preventing the buttons from working when network issues exist.

[rt400]

I have the same issue on some Touch wall devices, I change the WifiConfig to 5 (Wait) and hope it will fix this issue. I Still track on it

[ghost]

Same problem here with some sonoff mini R2's

This is a real dealbreaker, as I don't want to rely on a WiFi connection as a single point of failure to be able to switch my lights

[ascillato2]

This is a recurring bug from the Arduino core. It has been fixed several times but it shows up in newer versions. Just for reference: #9886, #7533, #1992, esp8266/Arduino#6454

We have to look into it again.

[ghost]

I got my Sonoff Mini R2 to work as expected. I've configured it via a template. It seems like it is necessary to select the created template in Configuration -> Configure Module for it to function correctly, while mine was still set to Sonoff Basic. After selecting the correct template, it even switches without a WiFi connection.

[bkbartk]

If you configure an R2 as basic it should work every other button click.
but if I understand @ascillato2 correctly the problem is related to mqtt. So if you don’t use this. This issue won’t occur.

[github-actions]

This issue has been automatically marked as stale because it hasn't any activity in last few weeks. It will be closed if no further activity occurs. Thank you for your contributions.

[Jason2866]

@ascillato2 any news?

[ascillato]

I haven't time to look into it. As soon as I can, I will do it.

[github-actions]

This issue has been automatically marked as stale because it hasn't any activity in last few weeks. It will be closed if no further activity occurs. Thank you for your contributions.

[ascillato]

Bump

[bkbartk]

Hello,

Today I have internet downtime again, and apparently it will take until tomorrow evening to fix this. So there goes my national holiday surfing the web.
now enough complained about Ziggo.
While my internet is down, and I'm not sure how it is related since wifi and MQTT just works. All my devices are acting differently, or random.
sometimes switches just work,
sometimes I have to press a couple of times,
sometimes they never respond.
sometimes I can only use them in Home assistant, and when I do the switches start working.
sometimes devices won't connect to MQTT, which is strange since my local environment is just up and running and I don't know the relation between the issues.
Maybe the MQTT server is to bussy trying to connect to the internet or something.

But the strange thing is that the behavior varies.
all my switches are running Tasmota 11.0.0 and 11.1.0
not sure if this information is helpfull or you already know all of this.

[edit]
also device grouping, which is unrelated to MQTT as it uses broadcast sometimes works, sometimes it works with a delay of a few minutes, and sometimes it doesn't work at all.

[github-actions]

This issue has been automatically marked as stale because it hasn't any activity in last few weeks. It will be closed if no further activity occurs. Thank you for your contributions.

[bkbartk]

Any update on this one?

[arendst]

Nope.

[arendst]

I see no status 0 output. PPls provide this information for further analysis.

[arendst]

Did some testing today and, as expected, cannot reproduce but that's not that strange. From your latest comment I gather by internet you mean the outside connection to the world while your modem/router keeps providing wifi.

I tested wifi down and saw no issues with delayed button control, especially with the latest changes adding longer retry time to connect to the router (which is the tricky part as this will hang the device during trying to find a connection and therefor unable to handle any keypress). Also devicegroups seized to work but were still able to switch using the local buttons.

I can think off issues introduced by your ziggo modem trying to re-connect to the outside world and hampering local intranet/wifi.

You might want to consider to add a local router connected to the ziggo modem providing your wifi (instead of the ziggo modem). This way when the modem hicksup you're wifi should stay active.

[arendst]

Did tests by using a dedicated router with it's own wifi network. All works well as long as the wifi is active. When router is powered off all still works well but device groups won't as wifi is gone. Local control is still possible so no bad things to report.

It get's weird when the router is still up but I remove the network cable from it. Wifi is still up but MQTT drops connection and devices try to reconnect to MQTT. ESP8266 based device detect quick no connection possible and retry. ESP32 based devices seem to hang for over 12 seconds not allowing any button action. This is strange as they both use the same library.

I will dive into the ESP32/MQTT issue.

Do you use ESP32 based devices which show this behaviour?

[bkbartk]

since the beginning of may I added my own router, and I haven't had issues since.

I'm using Home Assistant to connect to using MQTT on the same server as HA
And what I actually think is that when the internet connection goes down HA is going in to a loop, consuming all resources while there are no resources left for the MQTT server to work. Even the MQTT server an HA addon.
At that point tasmota devices keep trying to connect, or are connecting and waiting for response and during this time keypresses are unhandled.

I was just planning to Comment and see your response:
I have this issue primarily with ESP8266 devices. I only have 2 ESP32 devices with buttons, And I actually don't know if they are affected too.

[arendst]

In their infinite wisdom the ESP32 core designers decided to change function WiFiClient::setTimeout() from accepting milliseconds (as in ESP8266 core) into seconds. The Tasmota default of 200 milliseconds suddenly turns into 200 seconds blocking any code from executing during 13 seconds!!!!

Bugger! Making a workaround in Tasmota fixing this. Hold on.

UPDATE: It's not that simple. The complete function as currently implemeneted is useless. See espressif/arduino-esp32#6835

[bkbartk]

Thanks. But that wouldn’t explain why I had the issue initially on esp8266 devices.

[arendst]

What initially happens is that both NTP and MQTT fail to resolve their names when access to the DNS server is lost. For the NTP server(s) this adds up to 3 * 10 seconds blocking during every minute once NTP needs to be updated after every hour. For ESP8266 MQTT there is almost no blocking. For the ESP32 MQTT there was major blocking as in the meantime the Arduino Core library changed function setTimout from accepting msecs into seconds resulting in major blocking as it is default set to 200.

A workaround is using a local NTP server and local MQTT server both with stored IP addresses instead of names. This way no DNS is needed.

Latest change tries to connect to the DNS server BEFORE resolving a name. This reduces lost connections to 1 second blocking.

[bkbartk]

That would make sense,
I use my DNS(pi.hole) en MQTT(Mosquitto broker) locally, but still the ntp server is directed to the internet. So that would mean a 30sec TO every minute, so half of the time.
I guess ESP modules don't support threading.

One question about DNS.
I see there are 3 servers configured
{"NtpServer1":"pool.ntp.org","NtpServer2":"nl.pool.ntp.org","NtpServer3":"0.nl.pool.ntp.org"}
not sure how it decides for nl, I live in NL but I sure didn't configure to use the nl pool time.
The question, doen tasmota select the ntp server random? or first try 1, then 2 and finally 3?
It's important to know how I should modify the config.

[joba-1]

I recommend installing an ntp server that uses a pool to sync itself (eg install along with your dns and mqtt servers). Then let your local clients use this local server. Easy and robust

[bkbartk]

That is what I am going for,
I just installed chrony as an add on in HA.
I however decided to still use names instead of IP's.
I know IP is better/more stable/faster.
But it gave me a lot of headages the last time in needed to modify my network range. And I have a local DNS server(pi.hole)
so now I have
{"NtpServer1":"homeassistant","NtpServer2":"nl.pool.ntp.org","NtpServer3":"0.nl.pool.ntp.org"}
but is it better if I set
{"NtpServer1":"homeassistant","NtpServer2":"","NtpServer3":""}
or
{"NtpServer1":"homeassistant","NtpServer2":"homeassistant","NtpServer3":"homeassistant"}
that's why I'm wondering I which order the NTP servers get handled, random or ascending.

[joba-1]

I use the second option. Sorry, misleading.

I configure only my local ntp on tasmota.
And my local ntp server uses 3 nearby pool servers

[arendst]

The NTP servers are used as follows:

• once an update is requested it first tries to find the DNS server if it fails it bails out after one second and tries again in one minute
• it then tries to resolve ntpserver1 if it is defined. If not defined it selects the ntpserver2. If not defined it selects ntpserver3. If not defined it tries defualt ntp server <random number 0-3>.pool.ntp.org. If fails bails out after some seconds. (The point here is that it's of no ude to define the same ntp server name three times; it delays the search for ntp servers times 3. An empty ntpserver is just fine)
• Once resolved or hard ip address it tries to get the ntp time within a second. It uses this same ntpserver name the next time as a starting point.

You'll notice the search for DNS even if you use a fixed ip address for your NTP server. This is a choice I had to made based on the current sequence of resolving up to three ntp servers before bailing out. I use another approach for the MQTT server as that's only one host. There I first check if it's a hard ip address. If not check for DNS access and then used resolved ip address. If I did this for the three ntp servers it would take 3 x 1 second for not finding the DNS server.

In hindsight I might change the search for NTP server to do it only one per minute using the MQTT approach.

[arendst]

Try latest release v12.0.2. This should solve most longer lasting blocking when wifi or DNS is unavailable.

[Jason2866]

Closing since it is fixed. Please reopen if you still encounter the problem