All my Tasmota devices reverted to Sonoff Basic

1,045 views
Skip to first unread message

Bada Bing

unread,
Jun 17, 2019, 6:31:57 PM6/17/19
to SonoffUsers

Hi,

All my devices are on Sonoff 6.5.0, all kinds of different module types from Sonoff Basic all the way to custom modules.

I was playing with my Unifi AP and it got disrupted for a while, afterwards most of my devices (majority, perhaps with the exception of 2 or 3) had reverted to Module type Sonoff Basic


I didn't realize this at first, but then I opened the fridge and there was no power, (the fridge is attached to Teckin power monitoring smart plug (Module type: Teckin US 59)
At first I thought the PowerOnState 1 hadn't kicked it, so I tried to turn it on through HA, no luck, I tried to turn it on through Tasmota UI, still no go, even the power button on the device didn't work.


Checked the Freezer, the other fridge, wine fridge ...
All had the same issue
Panicked and to avoid ruining the food, I unplugged my devices.


Then started investigating what was the problem only to realize that the module type had reverted to Sonoff basic, corrected the module type and the devices started working as before.


This is the first time that has ever happened to me, and I have many devices and been using Tasmota for years.


It can't be a coincidence that this happened, something in the code flow (a bug? or a feature?) must have caused this.


Anyone has any clues? how can I avoid this? can't afford connecting essential appliances on these smart devices without assuring that this won't happen again.


Thanks
BB

Michael Ingraham

unread,
Jun 17, 2019, 11:12:15 PM6/17/19
to SonoffUsers
Tasmota will reset firmware settings back to defaults (including module type) in a five step process when it detects a bootloop  (a restart caused by any exception or watchdog timer within less than BOOT_LOOP_TIME (default 10) seconds):

  • 1st restart: disable ESP8285 generic GPIOs interfering with flash SPI
  • 2nd restart: disable rules causing boot loop
  • 3rd restart: disable all rules
  • 4th restart: reset user defined GPIOs to disable any attached peripherals
  • 5th restart: reset module to Sonoff Basic (1)

It appears that somehow the Wi-Fi reconnects with the changes to your network caused Tasmota to bootloop.

Regards.

Mike

Philip Knowles

unread,
Jun 18, 2019, 12:26:05 AM6/18/19
to Bada Bing, SonoffUsers

May have been caused by loss of the MQTT broker. If you are going to leave the devices running when you take your network down for any significant period of time click the MQTT enable in Configuration>Other. You could create a batch job to turn it off and on using
http://x.x.x.x/cm?cmnd=SetOption3%200
and
http://x.x.x.x/cm?cmnd=SetOption3%201
or increase MQTTRetry time from 10 seconds.

The config should still be there after you select the correct module.

Regards

Phil K

--
You received this message because you are subscribed to the Google Groups "SonoffUsers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sonoffusers+unsubscribe@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/sonoffusers/d8e65926-bb46-4dc6-971c-4978825ee1ae%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Bada Bing

unread,
Jun 18, 2019, 7:01:02 AM6/18/19
to SonoffUsers
Thank you Michael and Phil for your replies.
I think what Michael describes is what might have happened to me, the big question is why would re-provisioning the Unifi or restarting it cause bootloops.
Certainly looking at this thread https://github.com/arendst/Sonoff-Tasmota/issues/5054 it's obvious that it's put in place as a safety measure, and mostly people running into issues with this safety mechanism are folks who have flickering AC, but AP going up and down causing this?

Could setting WifiConfig option to 0 cause this? I guess if the restart is under 10 seconds and the code considers it a bootloop it could.
Anyone knows what is the restart time with WifiConfig 0?
Many of my devices were set to WifiConfig 0, but not all, only one of the Teckin smart switches survived the ordeal (and couple of non Teckins) and that had wificonfig set to 4

It looks like SetOption 36 can disable the feature, but I prefer lowering the threshold from 10 seconds to perhaps 1s and increasing the counter to 200.
I see no SetOption to change the BOOT_LOOP_TIME I guess I'd have to customize it with user_config_override.h

Phil, why would MQTT not being available cause this? that would be very bad,
MQTT could go down for various reasons, and unlike a bootloop it's much more likely that MQTT server is down, and some of those could be totally out of my control, relying on batch scripts to disable / enable mqtt would be unreliable.

It is also worth to note that one of my devices was actually Sonoff Basic, and it had additionally set GPIO14 to switch 1
that setting was lost which I guess was expected to happen at 4th restart.

Many thanks
BB

Philip Knowles

unread,
Jun 18, 2019, 7:41:09 AM6/18/19
to Bada Bing, SonoffUsers

There’s a known issue with it rebooting with people leaving MQTT enabled when they haven’t got a broker. It will have so many tries to find the broker and then restart (roughly 3 minutes)

It needs to be able to do that because it doesn’t know why it can’t see MQTT so the logical thought is ‘it’s probably there so the problem must be me so I’ll reboot’.

The honest answer to all this is to remember that you’re working with a live control system. Making a change in the telephone exchange part of that system could have implications so you should do a graceful shutdown before making changes and then do a restart and check afterwards.

I recently changed ISP and changed my router. All my devices had static IP addresses (including the MQTT broker). The new router ignored the static addresses and the broker ended up on a new IP address. It took me several hours to get it all working again.

If you have a power cut and everything goes down it will be fine - the issue is with losing your router for a significant period of time (15 minutes or so). You can set the MQTTRetry to over 8 hours if you’re really concerned.

 

Regards

 

Phil K

 

Sent from Mail for Windows 10

--

You received this message because you are subscribed to the Google Groups "SonoffUsers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to sonoffusers...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/sonoffusers/3de37920-cf8c-42a3-b489-8ee577b8c82c%40googlegroups.com.

Colin Law

unread,
Jun 18, 2019, 8:23:48 AM6/18/19
to SonoffUsers
I thought an MQTT problem would not cause this as it should not reboot
multiple times within the critical time to invoke the algorithm
described.

However I avoid such problems by keeping all setup params in retained
topics in mqtt, then when a device connects it is immediately
reconfigured as it should be.

Colin
> To view this discussion on the web, visit https://groups.google.com/d/msgid/sonoffusers/5d08cdd1.1c69fb81.3288e.5c8e%40mx.google.com.

Piotr Antczak

unread,
Jun 18, 2019, 8:33:11 AM6/18/19
to SonoffUsers
Phill,
Today I have a planned power outage. It started at 8:30 AM and the plan was to finish at 2:00 PM... but finally the AC power came back to my house at 9:45AM.
All my Tasmota devices where... well off (no power), but also my ups send signal (after 40 minutes) to all my virtual machines to shut down - mosquitto, nodered, and all this stuff was powered off.
When the power came back, all my Tasmota devices back to life... but mosquitto was offline so they ware not able to connect to it (all my Wifi APs came back to life also, so Tasmota devices ware able to connect to Wifi). I just started mosquitto 15 minutes ago - the configuration on all devices is fine. I don't think that MQTT server unavailability can lead to such behavior, but maybe there was a "sum" of factors?

To view this discussion on the web, visit https://groups.google.com/d/msgid/sonoffusers/5d08cdd1.1c69fb81.3288e.5c8e%40mx.google.com.

For more options, visit https://groups.google.com/d/optout.


--
Piotr Antczak

Philip Knowles

unread,
Jun 18, 2019, 9:45:20 AM6/18/19
to Piotr Antczak, SonoffUsers

In your case he devices were off too. All I know is that I have had several devices which have lost their config when I have been doing things like upgrade openHAB, changing router or when setting devices up without the MQTT settings being correct.

 

Sent from Mail for Windows 10

 

Colin Law

unread,
Jun 18, 2019, 12:24:27 PM6/18/19
to Paul Smith, SonoffUsers
Forwarding to the list as you accidentally sent this only to me.

On Tue, 18 Jun 2019 at 13:47, Paul Smith <paul....@ptu.biz> wrote:
>
> How do you go about doing that.

First work out what mqtt command topic is required for each option you
want, so for example if I want SetOption1 'on' I need
some_device/cmnd/SetOption1 on
Then write the value to that topic using your favourite mqtt client
with the retain flag set, so using mosquitto I do something like
mosquitto_pub -t some_device/cmnd/SetOption1 -m on -r
then to check it has taken correctly
mosquitto_sub -t some_device/cmnd/SetOption1

Colin

>
> Regards
>
> Paul
>> To view this discussion on the web, visit https://groups.google.com/d/msgid/sonoffusers/CAL%3D0gLvv%3Dh7QPZaxLNpAJ7k_AEO%3DSuzb_VOAUkn00BSWXO_WbA%40mail.gmail.com.
>> For more options, visit https://groups.google.com/d/optout.
>
>
>
> --
> Paul Smith
>
> Your Local Computer Specialist, Supporting Your Business When You Need It Most
>
> We also now do Portable Appliance Testing, if you would like to know more please drop us a line.
>
> Tel:- 0845 009 6226
>
> This email and any attachments may be confidential and/or privileged. Everything is intended for use of the addressee only. If you receive this message in error then you must not print it or pass it on to anyone else or use the information it contains. Please inform Phoenix Technology UK of the error by email or by telephoning (+44)(0)845 009 6226. Please then delete all copies from your system.
> If you are not the intended recipient then you must not use the information in the message or attachments or allow anyone else to do so.

Piotr Antczak

unread,
Jun 19, 2019, 12:53:32 AM6/19/19
to SonoffUsers, knowles...@gmail.com
Yes, but all my devices came back to life after 1:15 and my MQTT broker came back 4 hours later... So all devices ware trying to connect to broker for four hours.
--
Piotr Antczak

Philip Knowles

unread,
Jun 19, 2019, 1:20:42 AM6/19/19
to Piotr Antczak, SonoffUsers

I have one Sonoff device and a couple of the LC Technologies which don't like losing MQTT.
The rest are fine. I don't know why these ones cause trouble but watching them on serial they connect to wifi attempt to connect to MQTT fail and reboot straight away.
All I was saying that, with any type of live control system, making changes without checking afterwards that it's working as expected could be foolhardy.
I changed my router and lost my MQTT broker connection and the original poster was making changes to wifi.
We need to realise that these 'little' changes may have consequences and not just assume that everything is OK.

To unsubscribe from this group and stop receiving emails from it, send an email to sonoffusers+unsubscribe@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "SonoffUsers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to sonoffusers+unsubscribe@googlegroups.com.


 

--

Piotr Antczak

--
You received this message because you are subscribed to the Google Groups "SonoffUsers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to sonoffusers+unsubscribe@googlegroups.com.

 



--
Piotr Antczak

Piotr Antczak

unread,
Jun 19, 2019, 1:33:12 AM6/19/19
to Philip Knowles, SonoffUsers
Hmmm. That is really strange because the restarts should have been really fast to make Tasmota consider them as "fastreboot"... Anyway I do agree that it can be all those "little changes" which finally caused that problem. Maybe the problem is a combination of particular Tasmota version + Core Version + PubSubClient viersion? 

To unsubscribe from this group and stop receiving emails from it, send an email to sonoffusers...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "SonoffUsers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to sonoffusers...@googlegroups.com.


 

--

Piotr Antczak

--
You received this message because you are subscribed to the Google Groups "SonoffUsers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to sonoffusers...@googlegroups.com.

 



--
Piotr Antczak


--
Piotr Antczak

eas...@gmail.com

unread,
Mar 29, 2021, 7:35:26 AM3/29/21
to TasmotaUsers
Thank you for suggestion.
Reply all
Reply to author
Forward
0 new messages