Possible bothersom condition

[TLaren]

This may be worth looking into but not critical and may just be a side effect, but I have observed it.
My system is as follows:
Raspberry Pi
Ethernet connected to local network
WiFi, AP for all MQTT Devices Only
The other night the Pi crapped out, not sure why. It was behind a firewall but some ports open. Just in a testing mode, not in production mode yet. With a little work everything is back running but the WiFi will not connect.
Last night I needed a light that was controlled by a Sonoff and manually pressed the button on it. The light turned on. Within about a minute the light flashed, and about every minute after. I have not looked into it yet but all 'Off' devices have no side effect to the inability to connect to the server.
If I were in production mode, and all my lights did this, I might go crazy before I was able to repair the server. If it was my Air Conditioner or Freezer I may damage the units.
I'm guessing what is happening, but have not looked at the code, is the relay is being initialized to an off state and then checking the flash for it's last state, and setting it accordingly.
Thanks again for the great firmware and great interaction with the public.

[arendst]

Without wifi connection sonoff reboots and starts wifimanager. Every reboot will cause the activated relay to toggle momentarily as the esp8266 will always startup with gpio where relay is connected to in input mode.

Sonoff dual fixed this by using extra hardware leaving the state of the relay untouched.

[TLaren]

I was not sure if it was software or hardware. It looks like it is hardware and out of our hands.
Someone could put a pull-up resistor on the line, then everything that was off would flash on.

Thanks for the reply.

[dagbdagb]

@arendst Uhm... "if the wifi AP goes down, the Sonoff will continuously reboot and the relay will toggle every reboot". Is that an appropriate summary of what was stated here? Does this also apply to the Pow?

Is there some kind of forum/IRC-channel/mailing-list where discussing this excellent firmware replacement is considered polite conversation?

[arendst]

It also applies to pow (not having extra hardware as the dual has).

[arendst]

Version 2.1.2 provides an option to configure a second AP to be used as failover if connection to the first one fails. Depending on option WifiConfig it will restart and try again or start any of the three WifiConfig options to receive a valid AP from the user. After a minute of no response the sequence will start over.

That should solve a broken AP as long as you have two around...

[jhron]

Adding second AP is workaround how to avoid or postpone this problem and it is not good as permanent solution.

I think it is software problem. I will explain why I think it is software problem - however I did not check source code to confirm/reject it. So I can be totally wrong - take it as theory.

As far as I know the ESP8266 it self is in control. It means that it is doing what it must be done and in the mean time it gives (for some amount of time) control to "user" so he can execute his own code. But when user will not return control back to internal routines within given time the ESP will reboot it self. And I think it could be this case. When WiFi connection is down and it tries to send some MQTT data it will hang there until ESP is rebooted. I did not check source code yet which library is responsible for WiFi connection and sending data but I would bet that it will be this problem.

Another reason why I think it is this problem is, that I am using on another Sonoff unit ESPEasy firmware. In case that AP is down, it is automatically switched from client mode to AP mode and when original AP is back online it will automatically reconnect to it. And it stays on without any reboot - keeping last relay state.

Anyway thank you for great job Theo

[arendst]

Well that's a nice explanation as long as I didn't cater for these situation where wifi is lost.

I did and that's why I initially offered WPS, Smartconfig and WifiManager all with timeouts resulting in a controlled reboot (not WDT) of sonoff and retry the sequence. I do restarts as the three tools fail to release memory once initiated leading to memory leaks and eventually to reboots anyway. I do it also as some of my wifi routers just plainly fail to reconnect during retries.

By adding a second wifi router the chances of getting a reconnect (with or without restart) is even bigger.

The main reason of disconnection still is the router and not the sonoff software which runs for days in my environment. Doing a restart was in my opinion not a big deal.

Problems you may encouter are that most routers have a limit of amount of wifi clients they can serve; at around 20 clients it get crowded and at least my TP-LINK router fails to perform well leading to lost connections. This is just a problem of almost any wifi router. Time to invest in mesh or more routers as I did...

[arendst]

To disable restarts on search for one of two configured APs there's now an option WIFI_RETRY (4) for command WifiConfig which allows just that. It's in version 3.0.5 just released.

That should solve at least some kind of Wifi miss restart.

[tam481]

I've noticed weird behaviour when wifi is down. I'm on 3.0.2 still but my sonoff is behaving oddly if it loses wifi temporarily. It seems to turn on as soon as it loses wifi connectivity. Here is the console log
The first entry clearly shows that it was switched off (manually) and the message is retained. Then as soon as it loses connection and manages to reconnect, it switches on. Then I switch it off manually again hence hte last message.

01:07:35 MQTT: stat/home/livingroom/sonoff/LIGHT = OFF (retained)
01:12:05 UPnP: Multicast (re)joined
01:12:05 MQTT: Attempting connection...
01:12:06 MQTT: Connected
01:12:06 MQTT: stat/home/livingroom/sonoff/LIGHT = ON (retained)
01:12:12 UPnP: Multicast (re)joined
01:12:29 MQTT: stat/home/livingroom/sonoff/LIGHT = OFF (retained)

[arendst]

The messages you see do not indicate a wifi problem but a MQTT problem. I do not use retain but if you enabled retain on cmnd then you might receive the ON command induced by your MQTT broker. Having retain on stat does not control the relay in sonoff.

A possible solution to get rid of the MQTT Attempting connection messages is disable define USE_WEMO_EMULATION (Amazon Alexa use only) as this uses UDP which receives a lot of messages which might interfere with MQTT handling.

To disable restarts on wifi problems you could execute command wificonfig 4 which just retries the configured SSIDs for a wifi connection without a reboot.