Troubleshooting - RTurala/Sonoff-Tasmota GitHub Wiki
- Wifi stops working
-
Wifi does not connect
- mainly on a freshly flashed device
-
WIFI Issues (FW > 5.12.x), ExpressIf Versions
- WebUI unresponsive
- Energy saving
- Alexa "Device does not respond"
- Wifi unstable
- RSSI low after update
- Relay clicks/LED flashes at 1 sec interval
- Running out of memory
- Config problems (can cause boot loops, items set in user_config to not appear, etc)
- Flashing Issues
-
esptool usage
- Clear flash completly
- PlatformIO + esptool
- Device does not respond/freeze for short time (with MQTT on)
- Device keeps restarting ( after changing Config over MQTT )
-
Disconnects and Reconnects
- MQTT Log, already connected, no service found
- Troubleshooting Tools
There have been many reports of wifi no longer working when it was working for a while.
Every time this has been reported, it's ended up being a hardware or interference problem.
On the hardware side, we've seen reports of bad solder joints on the board that when touched up seem to solve the problem (capacitors being loose can cause this)
We've also seen reports then when a specific LED light bulb was hooked up near one, the signal quality dropped to unusable.
All you can really do is check the solder joints, move them around (try hooking up different loads), and if all else fails, replace the units.
If your device does not connect to your Wifi, its mostly causing by special chars or white spaces in your SSID or Password of your wifi. Remove them and try again.
(Dont forget to change the CFG_HOLDER => CFG_HOLDER explained )
With some wifi routers (i.e. Linksys with DD-WRT), you may have conflicts with the 5GHz radio. Don't choose "Mixed" option. Select "AC/N-Mixed" instead. Moreover, you probably should disconnect 5GHz radio during the configuration process.
By releasing the firmware 5.12, the new ExpressIf library 2.4.0 is being used by default.
For now, there are several issues known for this Version:
-
2.4.0)
- HUE Emulation still bugged (Issue & Workaround)
- WIFI Disconnects flooding Router Logs
- WebUI very unresponsive (cuz of Wifi DC ?)
- Devices often does not respond to Alexa (cuz of Wifi DC ?) => Seems its the sleep/wifi_light_sleep, but its saves alot of money (see Wiki Energy Saving).
- WIFI RSSI going down by 10-20%
-
upcoming 2.4.1)
- Devices still freeze with wifi_light_sleep (tested with latest git)
- Energy saving for WIFI is disabled! #2559
-
While 2.3.0 Version is working fine
- Alexa working
- Energy saving working
- Stable WIFI connection
Conclusion: Change to the 2.3.0 Library and see if it fix your problems.
HowTo Change: Atom&PlatformIO: Locate the platformio.ini file in the project directory of TASMOTA Change the following:
[common] ; ************************************************************
; *** Esp8266 core for Arduino version
platform = [email protected] ; v2.3.0
;platform = [email protected] ; v2.4.0
;platform = [email protected] ; v2.4.1
;platform = espressif8266
You can see the ExpressIf Version on the Tasmota WebUI under the Information Menu entry: Core-/SDK-Version: 2_3_0/1.5.3(aec24ac9)
See also:
This indicates that the ESP-8266 did not get flashed properly. In this case it will toggle all it's pins at 1 sec intervals
This typically shows up in the device working when it first starts up (hitting the button toggles the relay), but some time later it either reboots or some function won't work.
For example, you can't load the module configuration page.
The only fix for this is to recompile the firmware and disable features you don't need.
Known large features are webserver and TLS, but other things to consider disabling if you don't need them are emulation support, domoticz support, ws8212 support
By default, this firmware tries to preserve the existing config (to support automated updates via OTA upgrades), but various things can happen that cause the existing config to be a problem.
When you change the settings in the code, that doesn't directly change the
settings on the running machine when you load it. What happens is that when it
boots up, the firmware looks to see if it has a valid config (is it an upgrade
to an older tasmota version), and if the CFG_HOLDER value is in the right
place,it assumes that the existing config is valid. If it doesn't find the right
value, it assumes that this is not an upgrade and takes the compiled-in config
data and writes it out to the config area.
There are multiple ways to force the config to what's set in user_config to recover a system.
- hold button1 down for 40 seconds
- issue a reset command (
reset 1via the web console,/cmnd/sonoff/reset 1via mqtt) - change the value of CFG_HOLDER in user_config and re-flash the device (CFG_HOLDER is a 0xYYYYDDMM setup. Just change it to today. Any future updates should not be hindered by that).
In short: The CFG_HOLDER is the place where the config is stored on your device. The Device checks if a config is saved in this CFG_HOLDER (value from the user_config.h and always loads this if exists. => wont load new applied configs in your user_config.h
To get the new config on your device, you need to change the CFG_HOLDER. BUT: You should always try to stay on the default CFG_HOLDER, to reach this, you need to flash two times
- change your config in the user_config.h or better user_config_override.h
- change the CFG_HOLDER +1 or -1 is enough (e.g. 0x20161208)
- flash
- change the CFG_HOLDER back to default ( 0x20161209 )
- flash again
After this, your new config is saved in the default CFG_HOLDER on your device.
This is necessery to avoid loosing your config if you update to a new firmware by using the pre-build images or if you forget to change the CFG_HOLDER to your custom one if you build the firmware yourself.
How CFG_HOLDER works: The config of your Tasmota is stored in an area of the flash memory (flash config area or FCA). Using a new device (where Tasmota firmware runs the first time) the FCA does not contain a Tasmota configuration so on the very first start of Tasmota it uses your settings from user_config.h or user_config_override.h and copy this into the FCA. To prevent that the following Tasmota starts will overwrite your FCA settings again (e.g. because you has changed some things using commands) the FCA will be marked by a header value to indicate not copy the values from user_config.h/user_config_override.h again. This header becomes the value from CFG_HOLDER.
On every start the device compares the header of FCA with the CFG_HOLDER from your source code and only if this header value is not identical, Tasmotat will copy the data from user_config.h/user_config_override.h to flash settings area - this is normaly only the case on a fresh device or if you has changed the CFG_HOLDER value.
Summarize: To force Tasmota to overwrite current (valid or invalid) settings in FCA with your settings from user_config.h/user_config_override.h you can
- change CFG_HOLDER value once, compile, reflash device (as described above). To avoid overwriting settings by new versions don't forget etiher
- repeat the step above using original CFG_HOLDER value
- or never forget to change CFG_HOLDER value for even all upcoming version to your value
- or use the Management command
Reset 1orReset 2after changes in your user_config.h/user_config_override.h without the need to double reflash your device and/or double change your CFG_HOLDER value:- change values in user_config.h/user_config_override.h
- leave CFG_HOLDER as is
- start your device and push command
Reset 1orReset 2
If you try to update the Tasmota FW over the WebUI and get the message
Upload Failed
Upload buffer miscompare
you forgot to upload a minimal version first. This is necessery because there is no free space on the flash chip for the new firmware
- Upload a minimal firmware first
- Upload the new firmware
Read this:
FIRSTLY: NEVER EVER FLASH WITH 5V! If you did, your device may be damaged and cannot be flashed. Best way to figure it if your device is broken now, try another device to be sure your connection and flashing is working.
Following are the most known flashing issues:
Double check if you connected the device correct to the FTDI. Almost every Sonoff Device need to have RX to TX and TX to RX. Check the WIki for your device for the correct connection.
Another often problem are the jumper cables from the FTDI to the Device. Try other cable you keep getting connection errors or check the cables for connectivity. Most of them are made cheap in China and it happens quite often that those cables does not have good connection because of bad crimping or broken copper lines in them.
Be sure to use a USB DATA Cable and not a cheap loading cable for mobile phones for the connection from the FTDI to your computer. If you are unsure, just try another USB Cable. The Data Cables are often thickier than the normal loading cables.
Another problem can be the connection of GPIO0 and GND. Be sure to press the Button ( not all devices have a button for GPIO0 -> GND ) correctly, you must "feel" a click. If your device does not have a button, be sure to get a save GND connection. You can also use a ground Pin on your FTDI Flasher, it doesn't matter where you get the GND from.
If you still fail flashing or the progress interrupts, it could be that your PC (mainly MacBooks, Notebooks, Raspberry/Arduino or USB HUBs) have a too low power output (Ampere). Try another PC or try to use a USB Hub with an external Power Supply.
Use the correct FTDI driver. You can find them here: D2XX Direct Drivers Check the number on your FTDI Flasher to get the correct driver.
Hints:
- If esptool.py stops at "Uploading stub...", use --no-stub
Only Sonoff 4CH V2.0: Testing with two different (fairly new) FTDI boards and two new (Purchased 28/06/2017) Sonoff 4CH v2.0 and the Sonoff Dual v2.0 boards I found that I was getting errors uploading sketches i.e. "warning: espcomm_sync failed" basically a lack of communication between the two devices.
I found that the problem in both Sonoff's was that instead of the FTDI Sonoff cross-over TX->RX and RX->TX I had to do TX->TX RX->RX this then allowed me to upload the sketch.
Flashing is failing under MacOS High Sierra. ref: #957
- Install the VCP drivers for Mac from the FTDI website : http://www.ftdichip.com/Drivers/VCP.htm
- After install, reboot (it does not work if you do not reboot).
- After reboot, plug the FTDI USB/serial converter. Accept the security alert from MacOS.
- Restart the flash process. It works!
%USERPROFILE%.platformio\python27\Scripts>esptool --port COM12 write_flash --flash_mode dout --flash_size 1MB 0x0
firmware.bin
esptool.py v2.1
Connecting....
Detecting chip type... ESP8266
Chip is ESP8266
Uploading stub...
Running stub...
Stub running...
Configuring flash size...
Compressed 475008 bytes to 327693...
Writing at 0x00008000... (14 %)
A fatal error occurred: Timed out waiting for packet header
Maybe because of: https://vilimpoc.org/blog/2016/05/03/esptool-ck-esp8266-and-ftdi-bug-hunting/
Clearing the configuration flash area can also solve unbootable systems. Using the latest esptool supported by espressif makes this process "rather" easy.
- Go to https://github.com/espressif/esptool and read the README.md regarding installing esptool which comes down to
- Install python 2.7.x for your operating system from https://www.python.org/
- Open a command prompt and install pyserial with command
pip install pyserial - Install esptool with command
pip install esptool
- Clear the Tasmota configuration flash area
- Connect your device to a known serial port (say COM5)
- Hold the push button and apply 3V3 power to the device from the USB/serial connecting device (ie FTDI)
- Open a command prompt and execute command
esptool.py --port COM5 erase_region 0x0F4000 0x008000
- Optional Clear the complete flash with command
esptool.py --port COM5 erase_flash - Optional Load Tasmota into a device with command
esptool.py --port COM5 write_flash -fs 1MB -fm dout 0x0 sonoff.bin
With the Command Prompt execute:
- cd %USERPROFILE%\.platformio\python27\Scripts\
- pip install pyserial
- pip install esptool
After this you can use the same commands as above:
- esptool --port COM5 erase_region 0x0F4000 0x008000
- esptool --port COM5 erase_flash
- esptool --port COM5 write_flash --flash_mode dout --flash_size 1MB 0x0 firmware.bin
The default library that is being used to make the TCP connection to the MQTT server has a 5 second timeout, during which the firmware is stuck and can do nothing else (including switching the relay locally)
When the connection fails, the firmware can then operate locally for a little bit until it attempts a new connection.
Note that if it has no network connection at all, this problem doesn't happen, because it detects it doesn't have a network to try and connect over, and local operation can work without delays.
FIX: change to MQTT_TASMOTAMQTT library within the user_config.h file
/*-------------------------------------------------------------------------------------------*\
* Select ONE of possible three MQTT library types below
\*-------------------------------------------------------------------------------------------*/
// Default MQTT driver for both non-TLS and TLS connections. Blocks network if MQTT server is unavailable.
//#define MQTT_LIBRARY_TYPE MQTT_PUBSUBCLIENT // Use PubSubClient library
// Alternative MQTT driver does not block network when MQTT server is unavailable. No TLS support
#define MQTT_LIBRARY_TYPE MQTT_TASMOTAMQTT // Use TasmotaMqtt library (+4k4 code, +4k mem) - non-TLS only
// Alternative MQTT driver does not block network when MQTT server is unavailable. No TLS support
//#define MQTT_LIBRARY_TYPE MQTT_ESPMQTTARDUINO // Use (patched) esp-mqtt-arduino library (+4k8 code, +4k mem) - non-TLS only
If the serial debugger shows repeated messages like this -
02:32:54 MQTT: tele/MYSONOFF/LWT = Online (retained)
02:32:54 MQTT: cmnd/MYSONOFF/POWER =
02:32:55 MQTT: Attempting connection...
02:32:56 mDNS: Query done with 0 mqtt services found
02:32:56 MQTT: Connected
or your mosquitto log shows messages like this -
1496455347: New client connected from IP_addr_1 as SONOFF (c1, k15, u'SONOFF_USER').
1496455349: New connection from IP_addr_1 on port 1883.
1496455349: Client SONOFF already connected, closing old connection.
1496455349: Client SONOFF disconnected.
1496455349: New client connected from IP_addr_2 as SONOFF (c1, k15, u'SONOFF_USER').
1496455350: New connection from IP_addr_2 on port 1883.
1496455350: Client SONOFF already connected, closing old connection.
1496455350: Client SONOFF disconnected.
Then you have more than one device connected with the same client_ID. Its important that each device has a unique client_ID, not just PROJECT
If you changed the config (device configuration) over MQTT, the command can fail and due a bug in the HA the comand is repeatly sended, causing the device to restart.
Hint: The restart is normal if you change something at the device configuration.
FIX: You need to clear the retain messages of your HA/Broker/MQTT Server.
Read also:
The logs are available via syslog, the web console, or the serial port.
The default logging level is set in user_config* and is set separately for each log destination The higher the log level is set, the more information is logged.
If you have a Linux system around (say a Pi), it is probably running syslog already and you just need to configure it to listen on the network.
On systems running rsyslog (most linux distros), edit the file /etc/rsyslog.conf. Adding (or uncommenting) the following lines will probably start making the logs show up in some file under /var/log
$ModLoad imudp $UDPServerRun 514
These show up on the web console (http://device/cs)
WARNING, on sonoff POW you cannot be connected to the serial port while the device is connected to mains power. You can still collect the logs, but only when powering it via your serial connection The sonoff dual uses the serial port to control the relays, so serial logging interferes with the relay control
Through either a terminal program or the android serial monitor, set the baud rate to 115200 and disable hardware flow control and you will see the logs
If the ESP-8266 crashes, it frequently dumps information about the crash out the serial port, so the process listed above to see serial logs can provide extremely useful information These show up on the web console (http://device/cs)