Tasmota restarting and comes on all the time after reboot

[savage872]

00:00:04 MQT: tele/fireplace/INFO1 = {"Module":"Sonoff Basic","Version":"5.11.1","FallbackTopic":"DVES_72DFB7","GroupTopic":"sonoffs"} 00:00:04 MQT: tele/fireplace/INFO2 = {"WebServerMode":"Admin","Hostname":"fireplace-8119","IPAddress":"192.168.0.101"} 00:00:04 MQT: tele/fireplace/INFO3 = {"RestartReason":"Fatal exception:9 flag:2 (EXCEPTION) epc1:0x402559ae epc2:0x00000000 epc3:0x00000000 excvaddr:0x00944ec2

Does anyone know what the problem is? Version 5.11.1

[MTGS69]

If by "comes on after restart" you mean the item you are controlling gets turned on after a reboot there are settings (see Supported Commands on the right side of the Wiki under Usage). For example, by default the PowerOnState is set to "3" which means the relay will be set to whatever it was before it crashed or you lost power. Setting it to 1 forces the relay to the off position on restart, 2 forces it to the on position etc. As for the restart problem itself, I do not know what all the return error codes are but my experience is they are typically caused by a bad flash, a bad power source, wifi interference, and I once had bad node-red code sending bad MQTT commands which crashed my device. If you are working with a basic Sonoff it probably is not power source unless you got a bad unit or overheated something soldering in a header for flashing....but that is probably the most frequent cause for generic 8266 devices. You might try turning MQTT off to see if that fixes it. I only say that because the error message above comes right after an MQTT tel message. Does it crash after the same messages every time? Are you sure that IP address is correct? Most people, not all, would have a 1 rather than a 0 in 192.168.X.101. But it is indeed possible that your system is setup like that and even if bad it should not crash the Sonoff. For an interference check can you move the Sonoff closer to your router and see if that helps? If so, you can add a low bypass noise filter (Google "low pass filter for Sonoff").

[savage872]

Thanks for your reply! I appreciate it! I've done a bit of research, the problem is from the flash, I didn't go into to much detail.

The sonoff switch is almost ok now apart from a 10-15% packet loss on the wifi. It does restart frequently caused by this fatal error or watchdog. It is a bit annoying when you try do turn it on and off and it's not responding due to packet loss.. (try explaining that to the wife) It doesn't crash after sending the same message it's just out of the blue.

The IP is correct, it's set to static and there are no other devices with the same IP. As long as I can connect to it the IP is right.

I have two sonoff's at the moment, RSSI on 1 is 84 and on the other it is 100. That is the signal strengh isn't it?

I've tried changing poweronstate on a second sonoff which has a toggle switch on gpio14 and regardless if it's set to 0, 2 or 3 if I do a restart it will either turn on or off but doesn't retain the last saved state, I have disabled mqtt just to see if it makes a difference and it doesn't. My problem is that when it does restart if the switch was off it doen't stay off, so in the middle of the night the lights come on which is not brilliant. I did read about the low bypass noise filter, that is to avoid ghost switchid isn't it? I just bought a Sonoff CH4 PRO and I'm hopping once I have flashed tasmota on it that I won't be using soft switching via gpio14 and straight from the relay do a 2-way (3-way, 4-way whatever you want to call it) light switch system. Once again I really appreciate your reply!

[MTGS69]

RSSI is signal strength. I created a monitor in Node Red that graphs it and I have a dozen sonoffs around. 84 and 100 are very good signals (100 is the highest the sonoffs will report in my experience). I have one in the garage that hovers around 60 with no problems. Are you using Node Red? If not I suggest you try it out. I control everything thru a SmartThings hub but will one day switch over to that (work in progress). For now, I use it to monitor my Sonoffs state conditions over time. Did you read the PowerOnState Configuration topic? The MQTT PowerRetain flag overrides everything else including the PowerOnState configuration. For the longest time I had a bunch of retained messages stuck in my system. I finally created a Node-Red sketch to catch these and once caught, changed the payload to null or an empty string. That is how you clear them (publish to the same topic......look for a message that has LWT in the topic and "Offline" in the payload) The messages with LWT and "Online" in the topic seem to be harmless. Also be sure to turnoff the retain flag in your MQTT setup so you do not create more. If you are using Node-Red I can send you a a flow I use to monitor my Sonoff devices and catches the LWT topics so you can clear them out of your system. Although your signal strength are good, you may still be getting wifi interference from your neighbors. I have a dozen sonoffs (basic 10 amp single relay ones) and have no problems. However, I am using a Negear Orbi system which is a blow torch. It dominates any of my neighbors signals. I heard they went on sale the other day and may still be. It works great for me as I live in a congested So Cal neighborhood with lots of Wifi. My neighbors probably hate me! With that said, I suggest you first setup Node Red and a monitor flow to track what is going on over time. Again, I will send you mine if you like.

[MTGS69]

To clarify.....I'm not an expert in any of this but the LWT (Last Will and Testimont or something) is created when a device dies....thus the name. If you are using MQTT to control the on/off state of the sonoff directly through OpenHab or some other system where you handle the state changes yourself (see the SwitchMode/SwitchTopic link in the Wiki), this is probably useful. Otherwise, they are a nuisance and you probably need to flush them out of your system.

[savage872]

Really helpful, thanks! You made a lot of good points, I did disable MQTT when I was restarting the sonoff basic and power retain was set to 0. So I'm not to sure why it wasn't keeping state when restarting.

I do get some ghost switching, I know how to fix it but haven't done it yet.

Just to clarify, Theo has confirmed that loss of packets on wifi is due to wemo/hue Emulation being on and to much traffic on UDP uPnP, the advice was to switch it off. I would love to switch it of if there is an alternative on how to use Alexa with the Sonoff's. Any suggestions?

I got the fastest delivery ever on the CH4 PRO, orderded it yesterday (Saturday) 6pm and got it 11am today (Sunday). I have flashed it and now I'm trying to figure out a way to get the correct bulb state on a 2way(3way) wiring system.

[MTGS69]

Wow...that is fast shipping. As I mentioned previously, I am mainly using SmartThings with a custom device handler that allows me to control the Sonoff switches. Anything I can add to Smartthings I can control with my Google Home. I suspect the same would be true with Alexa. I'm stuck with Smartthings until I can figure out how to migrate all my other stuff over to Node Red (lots of Zwave and Zigbee devices). Unfortunately, I do not know anything about other hubs. One suggestion......have you tried the Stringify app? It works with both Android and iPhones. I loved that app and I believe anything you can add to that you can control with a voice assistant. I can add my Sonoff switches because Stringify connects to Smartthings. But it may support what you are using and solve your problem. Note that I moved off of it because Comcast bought them out recently. It is still free but that is what sent me down the path of trying to make my own server out of a raspberry pi. Attached is a screen capture of my Node-Red Sonoff/other 8266 device monitor. Note that I have devices with RSSIs below 60 and they still work no problem. The uptime bar chart is in hours. I've been messing around over the weekend which required disconnecting devices (thus two bars are low).

[MTGS69]

Notice the one device running at a very low voltage.....around 3......that is a wemos mini. I tested a bunch of them and they all run that low.

[MTGS69]

I have 10 wemo D1 chips and 7 more sonoffs waiting to be installed somewhere. Beats paying $50 for an off the shelf switch. But it definitely makes having a good modem and router critical!!!

[MTGS69]

I may have a solution for you on the 2-way switch. I've been working on that this weekend and am close to final test.

[MTGS69]

I was able to get 2 way switching to work. This method can be extended to any number of switches 3, 4, 5 etc. The only restriction is you must use MQTT for this method to work. Setup the first switch as normal (e.g. toggle switch connected to GPIO14, SwitchMode = 0, and SwitchTopic-off/0. Important - do not use SwitchMode=1....I will explain why later. You need to locate this switch in the box that has the lines going to your load (i.e. the lights) and power. Since you are replacing an existing 2 way switch system you should have enough wires to make it work from either box but you may have to make some changes (e.g. hook the red wire to power so you always have power in the second box). Note that you do not need a traveler for this hookup (I will try and post a picture at some point). For all remaining switches (2 thru n) you only need the power in. In fact, you do not even need a relay which is why I used a Wemo D1 mini but a Sonoff will work too. If you do use a Wemos or other device it appears you have to set one of the GPIOs to Relay for this to work. However, you have plenty of I/O on the Wemos and you do not actually have to hookup a relay.....it is a software thing. Next set the SwitchMode to 0 and the SwitchTopic to the MQTT topic you used for the first switch. When you toggle this switch it simply sends a message to the MQTT broker and since you are using the same SwitchTopic as the main switch Topic it acts as if you toggled the first switch. This is why you do not need any outlet wires on 2 thru n. You only need inlet wires to power the Sonoff or other 8266 device so that it can send MQTT messages. I mentioned near the top to set the SwitchMode to 0 not 1. Normally I would set it to 1 for a toggle switch which means the relay state and switch state attempt to stay synced. When you have more than one switch the system cannot sync all the switch states with the power state (because sometimes up is off and vice-versa depending on what switches were toggled previously). If you set SwitchMode =1 then sometimes when you toggle the 2nd switch you have to toggle it twice to work. If you set SwitchMode=0 it always work. Finally, if you have a choice (depends on your wiring) locate the first switch (one with input power and output to light load) put it in the more often used location. If you lose internet or your MQTT broker the 2nd switch will not work. Also, if you are running your broker in the cloud and there is a delay, this will impact the 2nd and any additional switches. The first switch is coupled to the relay so that is always fast and more reliable.

[savage872]

I already have this setup in place with my sonoff basic, not I'm trying to setup the CH4 PRO and get the correct bulb state when the toggle switch in the wall is actioned.

There is a video tutorial online on how to link as many sonoff basic as you want to act as a virtual 3way(4way...) switch controlled by home assistant with automation when one remote sonoff is turned on/off to action the main sonoff that has the bulb attached on as well.

[joealmonte]

When Tasmota senses a Wi-Fi disconnect, the BlinkCount counter initiates. By default, the rate for this counter is set to 1 blink per second. Yes, a Wi-Fi disconnect is one of the instances when your Sonoff's green LED starts flashing. After 10 seconds elapse, Tasmota will trigger the Sonoff to restart. It will continue to do this until it re-establishes a connection with the Wi-Fi. Once it reconnects, Tasmota initiates its safe mode System Restart procedure:

00:53:35 MQT: tele/sonoff5/INFO1 = {"Module":"Sonoff Basic","Version":"5.12.0","FallbackTopic":"DVES_7C6F6F","GroupTopic":"sonoffs"}

00:53:35 MQT: tele/sonoff5/INFO2 = {"WebServerMode":"Admin","Hostname":"sonoff5-3951","IPAddress":"192.168.0.205"}

00:53:35 MQT: tele/sonoff5/INFO3 = {"RestartReason":"Software/System restart"}

...causing the garage door to open without consent. To minimize these events from happening, the BlinkCount can be increased.

I own a Netgear R8000P router, and every time I manually reboot the router, it will trigger my garage door to open. The router I own takes over to minutes to power cycle. In my case, the garage door Sonoff restarts about 15 times before reconnecting to Wi-Fi. So to workaround the issue, I increased the BlinkCount to 180 (3 minutes).

01:02:44 CMD: blinkcount 01:02:44 MQT: stat/sonoff5/RESULT = {"BlinkCount":10} 01:05:19 CMD: blinktime 01:05:19 MQT: stat/sonoff5/RESULT = {"BlinkTime":10} 01:09:06 CMD: blinkcount 180 01:09:06 MQT: stat/sonoff5/RESULT = {"BlinkCount":180}

This configuration now gives enough time for the router to restart, and the Sonoff to re-connect to WiFi without triggering a power restore condition, or restarting. I hope this helps a few of you guys!!!

[mdelpire]

Hi TOBYBEAR69,

Would you mind sharing with us your node-red for monitoring please? It seems really interesting and I would like to do the same.

Thanks a lot,

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale[bot]]

This issue will be auto-closed because there hasn't been any activity for a few months. Feel free to open a new one if you still experience this problem.

[meingraham]

Are you controlling your devices through MQTT? Perhaps your broker has retained some messages that need to be cleared out.

See if this tutorial helps - https://www.youtube.com/watch?v=31IyfM1gygo

[robcollyer]

Hi

No not through MQTT I don’t use it, urgently I just have the board wired up 9n my desk to a led NO Led circuit. I can make the relay come on for a pulsetime which works great, the issue I have is when I reset the board on boot the relay pulses the relay causing the led to flash thus completing the relay, this behaviour will open my garage door.

I have power on state set to zero/off but no joy. Running out of things to try... any help would be greatly appreciated?

ThansRob

Sent from my iPad

On 14 Jan 2019, at 21:21, Michael Ingraham notifications@github.com wrote:

Are you controlling your devices through MQTT? Perhaps your broker has retained some messages that need to be cleared out.

See if this tutorial helps - https://www.youtube.com/watch?v=31IyfM1gygo

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[meingraham]

@robcollyer

My hunch then is that there is probably another configuration parameter (or more) that needs to be adjusted. Since this is a closed issue, you're not likely to get much joy in terms of response. I would either pursue this on the TASMOTA Discord interactive chat, or create a new issue here on GitHub. In either case, you should point your browser to the switch's IP address so you can examine its configuration. One of the first questions you're going to be asked for is the output of a STATUS 0 command from the console. That command prints out every part of the device's configuration and will give folks trying to troubleshoot your issue a lot of information to go from.

Mike

[robcollyer]

Thanks mike will do all the best rob

Sent from my iPhone

On 14 Jan 2019, at 21:35, Michael Ingraham notifications@github.com wrote:

@robcollyer

My hunch then is that there is probably another configuration parameter (or more) that needs to be adjusted. Since this is a closed issue, you're not likely to get much joy in terms of response. I would either pursue this on the TASMOTA Discord interactive chat, or create a new issue here on GitHub. In either case, you should point your browser to the switch's IP address so you can examine its configuration. One of the first questions you're going to be asked for is the output of a STATUS 0 command from the console. That command prints out every part of the device's configuration and will give folks trying to troubleshoot your issue a lot of information to go from.

Mike

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[ahmeaqas]

Have a look on to Ghost / Random Switching on Sonoff Devices (MQTT Retained)