Closed apastuszak closed 6 years ago
Held the button down for 40 seconds to completely reset Tasmota, Rebooted and now I am not able to see a wifi network at all to connect to. I pressed the button 4 times to start up wifi_manager. Light starts to blink. No wifi network I can connect to.
Pressee button 3 times to put it in Smart Config. Used ESP8266 Smart Config. Keeps failing. Not sure how to bring this thing back to life without taking it apart and using a USB to serial adapter.
Every update is a nightmare :D I'm experiencing just the same with both of my Basics. One was working correctly just after the update but failed a few minutes later. Unluckily, in that time I thought updating my second Basic seems to be safe...
So, now both Basics are "running" 6.1.0, but both are in that loop you're mentioning. They neither connected to the existing wifi, nor they are reachable after a reset...
Miration Path correct? You have to care for that!
Was coming from 5.14., so I don't think the migration path is the issue, or am I wrong?
I was on 5.14.
My 5,13 to 5.14 upgrade caused the same issue and I need to flash over serial.
Well, when 40 seconds button pressing reset doesnt help, there is just one way left -> Clean reflashing. To be sure everything is erased do a erase with esptool first. I did a upgrade from 5.14 to 6.1.0a (self compiled) with no problem and it is rock solid
I also had issues with one of my 20 devices. The one with the problem was based on core 2.4.1. May be that could make a difference !?
@chriskmn I never had a version with v.2.4.0 or 2.4.1 i tried, that was reliable. I always got minor or major problems with every version (starting from Tasmota v.5.0.x). For me only (is and was) V.2.3.0 is rock solid!!
So, if 2.4.x is problematic, why is the precompiled binary not based in 2.3.0 :( It would help unexperienced users, like me, very much. For me every update is pain, since chances are very high that afterwards the Basics are broken - like it is the case now for both of mine.
Thanks Jason, I‘ll stay with 2.3.0 also now.
@maciboy the precompiled version 6.x are based on core 2.3.0 This is a result of experiences users made.
@maciboy: Until now I never had issues with the basics. My problem occured on a 4ch pro. May be there are other factors on the basic. Are they switched on while you are updating ? I know that the ESP8266 are very sensitive on supply power. A microwave could make trouble or even a bad AC adaptor somewhere on the powerline.....
Used ESPtool to erase flash. Flashed the pre-compiled binary from the Github. Came up on it's own network. I connected and configured for my wifi. Rebooted the device. It did NOT connect to my wifi, but instead came up on it's own network under the new hostname I gave it. Connected. Reconfigured Wifi, even though it looked right. Device restarted and did not connect to my wifi and now will not go into Wifi Manager mode.
Now it's just blinking for about a minute, then goes solid, then the device seems to reboot and start blinking again.
@apastuszak Thats exactlly what I‘m experiencing as well. No chance for a connection to the exisiting wifi. They just span up their own wifi, with the given hostname. Connecting to that wifi is nearly impossible, just worked once out of a dozen of tries.
@Jason2866 Then it seems that neither the core version, nor the migration path is the issue...
@maciboy I'll putting 5.14 back on it and just leaving it alone for now. Can I ask what kind of router you're using and what kind of firmware is on it?
That‘s how it looked on my router. The Sonoff connected to the wifi but 20 seconds later, it got disconnected. This pattern is repeated after every reboot.
Because of this, I resetted both using the 40s button press.
Once I was able to connect to the established wifi, entered the credentials, but it did not help.
My router is a FritzBox 7490, firmware is 6.93
@maciboy Does your router do both 2.4 Ghz and 5 Ghz and are both of these networks named the same?
Yes, 2.4 and 5 GHz have the same name
That's the same configuration I have. I wonder if that may be the issue here. Just strange that 6.1.0 minimal works without any issues.
just disable 5ghz and test it, but yep, 5ghz can make problems if both have the same name.
Esp is a 2.4Ghz only device. I use 2.4 Ghz and 5 Ghz at the same time on my Accesspoints (Lancom and Bintec-elmeg). No problem. SSID is the same for all just different channels @reloxx13 How should a frequency (5 Ghz) that the ESP isnt capable make problems? Or is this problem Fritzbox related?
Just reverted to 5.14.0 using ESPtool and all my problems are now gone. Wifi works great.
@reloxx13 If I do that, I will have two teenage boys scream at me that their Xboxes suddenly stopped working.
Did you try this:
In the user_config.h, find the option CFG_Holder and change from #define CFG_HOLDER 4617 to #define CFG_HOLDER 4618. Result: it works flawlessly as it should. connects instant to the wifi, no more problems.
???
5.14.0 has another format of that constant. So may be that somehow messes up the config
5.14.0: #define CFG_HOLDER 0x20161209
What does that setting do? Why isn't it the default in the pre-compiled binary?
On Tue, Jul 10, 2018 at 2:17 PM Chris notifications@github.com wrote:
Did you try this:
In the user_config.h, find the option CFG_Holder and change from #define CFG_HOLDER 4617 to #define CFG_HOLDER 4618. Result: it works flawlessly as it should. connects instant to the wifi, no more problems.
???
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/arendst/Sonoff-Tasmota/issues/3177#issuecomment-403918363, or mute the thread https://github.com/notifications/unsubscribe-auth/ADPlXpdoaUjnz5TqHoqK20EP2SyRv5H-ks5uFO_TgaJpZM4VJUOc .
@chriskmn changing cfg_holder deletes every stored setting in the device to defaults in user_config.h. Overflashing with unchanged cfg_holder keeps stored settings in device. So in your case bad settings where stored in device and reused...
But shouldn‘t the 40sec reset do the same and set back all values to default?
@maciboy yes holding button for 40 sec. should reset device to defaults (user_config.h)
@Jason2866: yes, that‘s how I understood it as well. So if you flash a new FW without changing cfg holder, that FW uses the stored config from device.
If it is changed (like from 5.14.0 to 6.1.0) FW uses NOT the config from the device ?! And if there is a mistake in the config of the binaries there might be issues with connecting after flashing.....
@chriskmn Function of CFG_HOLDER is not changed by design in latest version. If behaviour really changed it is a bug
Question might be how people migrate there user_config.h from version to version. Just copy-paste might lead to issues. I am always changing the newer config line by line in comparism with the old config - very cautiously.
user_config_override
I used ESPtool to erase flash and then to flash 6.1.0. That still gave issues. Should not an ESPTools Erase Flash not have done the same as the CFG_HOLDER setting?
On Tue, Jul 10, 2018 at 3:03 PM reloxx13 notifications@github.com wrote:
user_config_override
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/arendst/Sonoff-Tasmota/issues/3177#issuecomment-403931781, or mute the thread https://github.com/notifications/unsubscribe-auth/ADPlXkMF7IgfqXHPCOSVJxEX0kgEZOmZks5uFPqegaJpZM4VJUOc .
What happens if you tell the FW to use flash config - but you deleted it ? ;)
So if flash is empty you MUST change cfg-holder.
Or am I wrong on this?
I think that‘s the reason why you should erease only sketch when flashing:
@apastuszak Erasing flash with Esptool is the secure way to wipe out the whole flash. With this 100% nothing is left: esptool --port COM5 --baud 115200 erase_flash
@chriskmn Dont use Arduino core 2.4.1 or 2.4.0 if you have wifi issues. This 2 versions are known to make problems Your Arduino Hardcopy suggest that you use it. I dont use Arduino IDE anymore, it is not a good tool for bigger projects like Tasmota. Using Platformio or VSC is so much simplier and hassle free. Well preconfigured platformio.ini from @arendst in project included and you dont have to do any setting things
@Jason2866: it was just a copy from the wiki. I am back on 2.3.0. but thanks for the advice. I was also looking on platformio.
@Jason2866 That's what I did before I installed 6.1.0. Still had Wifi issues.
@apastuszak: if you did not change cfg-holder you have a corrupted configuration.
So, I connected one of the Basics to my Pi (https://github.com/arendst/Sonoff-Tasmota/wiki/Flash-Sonoff-using-Raspberry-Pi)
Thats how the output looks: `00:00:00 Project sonoff Sonoff (Topic sonoff, Fallback DVES_4F743F, GroupTopic sonoffs) Version 6.1.0-2_3_0 00:00:00 WIF: Connecting to AP1 xxxx in mode 11N as sonoff-5183... 00:00:25 WIF: Connect failed with AP timeout 00:00:26 WIF: Connecting to AP1 xxxx in mode 11N as sonoff-5183... 00:00:50 WIF: Connect failed with AP timeout 00:00:50 WIF: WPSConfig active for 3 minutes 00:01:11 APP: Restarting
ets Jan 8 2013,rst cause:4, boot mode:(3,6)
wdt reset load 0x4010f000, len 1384, room 16 tail 8 chksum 0x2d csum 0x2d v3fff3888 ~ld
00:00:00 Project sonoff Sonoff (Topic sonoff, Fallback DVES_4F743F, GroupTopic sonoffs) Version 6.1.0-2_3_0 00:00:00 WIF: Connecting to AP1 xxxx in mode 11N as sonoff-5183... 00:00:25 WIF: Connect failed with AP timeout 00:00:26 WIF: Connecting to AP1 xxxx in mode 11N as sonoff-5183... `
In my router I can see, as shown yesterday, that the Sonoff connects for around 20 seconds...
(Also strange that it says 3 minutes in WPSConfig, but reboots after not even 2 minutes)
@chriskmn Even if I used esptool to erase_flash, I'm still going to have a corrupt configuration? How is that possible?
@apastuszak We will see now, I just erase-flashed the Basic and will flash 6.1.0 now. I'm curious if it will work or if I end up like you did
@maciboy while in the serial interface and still waiting for your ap execute the following commands:
seriallog 3
status 0
and provide the output here pls.
It's alive with 6.1.0 👍 (after 2x flash erase to make sure it is really erased :D)
If I backup my config from 5.1.4, can I restore the same config on 6.1.0?
That's at least what the 'Migration path' wiki says ;)
If you already have problems with your config I would say forget a restore and re-config after uploading 6.1.0.
Moving from a higher version back to a lower version will corrupt the config so that is probably what you did already...
@arendst So, do you think that's the issue? The config is working in 5.1.4, but is corrupt? So when I upgrade, it goes FUBAR?
I'll compile 6.1.0 with CFG_HOLDER set to erase config and do an OTA. I assume sonoff_minimal doesn't read the config and that's why it's working?
Minimal still reads the config but it doesn't update the config.
Most released versions will shuffle the config around a bit to accommodate new functionality. The minimal version does not do this shuffle as it doesn't update the config.
For background info look in file settings.ino at the bottom where you see all changes to be made when moving up from previous versions to the latest.
@arendst Now I connected the second Basic, which also didn't made the update from 5.14 to 6.1 successfully.
Here is the output you asked for:
seriallog 3 00:02:44 CMD: seriallog 3 00:02:44 SRC: Serial 00:02:44 RSL: Group 0, Index 1, Command SERIALLOG, Data 3 00:02:44 RSL: stat/sonoff/RESULT = {"SerialLog":"3 (Active 3)"} status 0 00:02:54 CMD: status 0 00:02:54 SRC: Serial 00:02:54 RSL: Group 0, Index 1, Command STATUS, Data 0 00:02:54 RSL: stat/sonoff/STATUS = {"Status":{"Module":1,"FriendlyName":["Sonoff"],"Topic":"sonoff","ButtonTopic":"0","Power":0,"PowerOnState":3,"LedState":1,"SaveData":1,"SaveState":1,"ButtonRetain":0,"PowerRetain":0}} 00:02:54 RSL: stat/sonoff/STATUS1 = {"StatusPRM":{"Baudrate":115200,"GroupTopic":"sonoffs","OtaUrl":"http://sonoff.maddox.co.uk/tasmota/sonoff.bin","RestartReason":"Software/System restart","Uptime":"0T00:02:53","StartupUTC":"","Sleep":0,"BootCount":30,"SaveCount":43,"SaveAddress":"F9000"}} 00:02:54 RSL: stat/sonoff/STATUS2 = {"StatusFWR":{"Version":"6.1.0","BuildDateTime":"2018-07-06T21:01:47","Boot":31,"Core":"2_30","SDK":"1.5.3(aec24ac9)"}} 00:02:54 RSL: stat/sonoff/STATUS3 = {"StatusLOG":{"SerialLog":3,"WebLog":2,"SysLog":0,"LogHost":"","LogPort":514,"SSId":["ZuHauseLan",""],"TelePeriod":300,"SetOption":["00008009","55818000"]}} 00:02:54 RSL: stat/sonoff/STATUS4 = {"StatusMEM":{"ProgramSize":535,"Free":468,"Heap":18,"ProgramFlashSize":1024,"FlashSize":1024,"FlashMode":3,"Features":["00000809","0FDAE794","0C000000","23B6179E","00000000"]}} 00:02:54 RSL: stat/sonoff/STATUS5 = {"StatusNET":{"Hostname":"sonoff-1172","IPAddress":"0.0.0.0","Gateway":"192.168.2.254","Subnetmask":"255.255.255.0","DNSServer":"192.168.2.27","Mac":"2C:3A:E8:4F:A4:94","Webserver":2,"WifiConfig":2}} 00:02:54 RSL: stat/sonoff/STATUS6 = {"StatusMQT":{"MqttHost":"","MqttPort":1883,"MqttClientMask":"DVES%06X","MqttClient":"DVES_4FA494","MqttUser":"DVES_USER","MqttType":1,"MAX_PACKET_SIZE":1000,"KEEPALIVE":15}} 00:02:54 RSL: stat/sonoff/STATUS7 = {"StatusTIM":{"UTC":"Thu Jan 01 00:02:54 1970","Local":"Thu Jan 01 00:02:54 1970","StartDST":"Thu Jan 01 00:00:00 1970","EndDST":"Thu Jan 01 00:00:00 1970","Timezone":1,"Sunrise":"07:43","Sunset":"16:03"}} 00:02:54 RSL: stat/sonoff/STATUS10 = {"StatusSNS":{"Time":"1970-01-01T00:02:54"}} 00:02:54 RSL: stat/sonoff/STATUS11 = {"StatusSTS":{"Time":"1970-01-01T00:02:54","Uptime":"0T00:02:53","Vcc":3.103,"POWER":"OFF","Wifi":{"AP":1,"SSId":"ZuHauseLan","RSSI":100,"APMac":"FF:FF:FF:FF:FF:FF"}}}
Just did an OTA upgrade 6.1.0. Flashing Sonoff-minimal.bin worked just fine. But when I upgraded to Sonoff.bin after that, I am getting a flashing green light. When I go into my wifi settings, I see that WIFI_MANAGER has kicked in and the Sonoff has it's own network up and running, but I am unable to connect to this network. and reconfigure the device.