link fixes

2018-05-13 15:14:41 +02:00 · 2018-05-13 15:14:41 +02:00 · 6141918c81
parent 9bd3ec1428
commit 6141918c81
1 changed files with 348 additions and 2 deletions
--- a/Troubleshooting.md
+++ b/Troubleshooting.md
@ -1,5 +1,6 @@

-# Common issues (in no particular order):
+
+### Common issues (in no particular order):


 - [Wifi stops working](#wifi-stops-working)
@ -19,7 +20,6 @@
 	- [Flashing is failing under MacOS High Sierra](#flashing-is-failing-under-macos-high-sierra-ref-957)
 	- [Update over WebUI not working](#update-over-webui-not-working)
 		- Upload buffer miscompare
-	- [Uploading Sketch via FTDI/UART Not Working](#uploading-sketch-via-ftdiuart-not-working)
 	- [Esptool/Flashing 'Timed out waiting for packet header'](#esptoolflashing-timed-out-waiting-for-packet-header)
 - [esptool usage](#esptool-usage)
 - [PlatformIO + esptool](#platformio--esptool)
@ -332,6 +332,352 @@ On systems running rsyslog (most linux distros), edit the file /etc/rsyslog.conf
 $ModLoad imudp
 $UDPServerRun 514
 ### Web Logs
+# Common issues (in no particular order):
+
+
+- [Wifi stops working](#wifi-stops-working)
+- [Wifi does not connect](#wifi-does-not-connect)
+	- mainly on a freshly flashed device 
+- [WIFI Issues (FW > 5.12.x), ExpressIf Versions](#wifi-issues-fw--512x-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](#relay-clicksled-flashes-at-1-sec-interval)
+- [Running out of memory](#running-out-of-memory)
+- [Config problems (can cause boot loops, items set in user_config to not appear, etc)](#config-problems-can-cause-boot-loops-items-set-in-user_config-to-not-appear-etc)
+	- [CFG_HOLDER explained](#cfg_holder-explained)
+- [Flashing Issues](#flashing-issues)
+	- [Flashing is failing under MacOS High Sierra](#flashing-is-failing-under-macos-high-sierra-ref-957)
+	- [Update over WebUI not working](#update-over-webui-not-working)
+		- Upload buffer miscompare
+	- [Uploading Sketch via FTDI/UART Not Working](#uploading-sketch-via-ftdiuart-not-working)
+	- [Esptool/Flashing 'Timed out waiting for packet header'](#esptoolflashing-timed-out-waiting-for-packet-header)
+- [esptool usage](#esptool-usage)
+- [PlatformIO + esptool](#platformio--esptool)
+- [Device does not respond/freeze for short time (with MQTT on)](#device-does-not-respondfreeze-for-short-time-with-mqtt-on)
+- [Disconnects and Reconnects](#disconnects-and-reconnects) 
+	- MQTT Log, already connected, no service found
+- [Troubleshooting Tools](#troubleshooting-tools)
+	- [Logs](#logs)
+	- [Crashdumps](#crashdumps)
+
+
+
+
+
+
+
+## Wifi stops working
+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.
+
+### Wifi does not connect
+If your device does not connect to your Wifi, its mostly causing by special chars or white spaces in your SSID or Passworf of your wifi. Remove them and try again.
+
+(Dont forget to change the CFG_HOLDER => [CFG_HOLDER explained](#cfg_holder-explained) ) 
+
+## WIFI Issues (FW > 5.12.x), ExpressIf Versions
+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](https://github.com/esp8266/Arduino/issues/4235))
+	 - 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](https://github.com/arendst/Sonoff-Tasmota/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](https://github.com/arendst/Sonoff-Tasmota/issues/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 = espressif8266@1.5.0  ; v2.3.0
+    ;platform = espressif8266@1.6.0  ; v2.4.0
+    ;platform = espressif8266@1.7.0  ; 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:
+- [#2689, Web Interface not available](https://github.com/arendst/Sonoff-Tasmota/issues/2689)
+- [#2673, Less wifi sensibility with latest firmware](https://github.com/arendst/Sonoff-Tasmota/issues/2673)
+- [#2611, ](https://github.com/arendst/Sonoff-Tasmota/issues/2611)
+
+
+## Relay clicks/LED flashes at 1 sec interval
+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
+
+## Running out of memory
+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
+
+## Config problems (can cause boot loops, items set in user_config to not appear, etc)
+
+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.
+
+1. hold button1 down for 4 seconds
+2. issue a reset command (``reset 1`` via the web console, ``/cmnd/sonoff/reset 1`` via mqtt)
+3. 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).
+
+### CFG_HOLDER explained
+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.
+
+
+## Update over WebUI not working
+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: 
+- [Functionality vs Firmware size vs OTA](https://github.com/arendst/Sonoff-Tasmota/wiki/Upgrade#functionality-vs-firmware-size-vs-ota)
+- [OtaMagic](https://github.com/arendst/Sonoff-Tasmota/wiki/What%27s-New#otamagic)
+- [#2660](https://github.com/arendst/Sonoff-Tasmota/issues/2660)
+
+
+## Flashing Issues
+
+**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](http://www.ftdichip.com/Drivers/D2XX.htm)
+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
+
+1. Install the VCP drivers for Mac from the FTDI website : http://www.ftdichip.com/Drivers/VCP.htm
+2. After install, reboot (it does not work if you do not reboot).
+3. After reboot, plug the FTDI USB/serial converter. Accept the security alert from MacOS.
+4. Restart the flash process. It works!
+
+Ref.: [#957](https://github.com/arendst/Sonoff-Tasmota/issues/957#issuecomment-338779258)
+
+## Esptool/Flashing 'Timed out waiting for packet header'
+    %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/
+
+## esptool usage
+Clearing the configuration flash area can also solve unbootable systems. Using the latest esptool supported by espressif makes this process "rather" easy.
+
+1. 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<br/> ``pip install pyserial``
+  - Install esptool with command<br/> ``pip install esptool``
+2. 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<br/> ``esptool.py --port COM5 erase_region 0x0F4000 0x008000``
+3. Optional Clear the complete flash with command<br/> ``esptool.py --port COM5 erase_flash``
+4. Optional Load Tasmota into a device with command<br/> ``esptool.py --port COM5 write_flash -fs 1MB -fm dout 0x0 sonoff.bin``
+
+## PlatformIO + esptool
+With the Command Prompt execute:
+1. cd %USERPROFILE%\.platformio\python27\Scripts\
+2. pip install pyserial
+3. pip install esptool
+
+After this you can use the same commands as above:
+1. esptool --port COM5 erase_region 0x0F4000 0x008000
+2. esptool --port COM5 erase_flash
+3. esptool --port COM5 write_flash --flash_mode dout --flash_size 1MB 0x0 firmware.bin
+
+## Device does not respond/freeze for short time (with MQTT on)
+
+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
+
+## Disconnects and Reconnects
+
+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
+
+
+
+
+## Devive keeps restarting ( after changing Config over MQTT )
+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:
+[#2140](https://github.com/arendst/Sonoff-Tasmota/issues/2140)
+[#2658 (comment)](https://github.com/arendst/Sonoff-Tasmota/issues/2658#issuecomment-387112217)
+[#2716](https://github.com/arendst/Sonoff-Tasmota/issues/2716)
+      
+
+
+# Troubleshooting Tools
+## Logs
+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.
+
+### Syslog
+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
+### Web Logs
+These show up on the web console (http://device/cs)
+   
+### Serial Logs
+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
+
+## Crashdumps
+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)
   
 ### Serial Logs