Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Initial flash does not connect to Wifi, or start an AP #2914

Closed
3 tasks done
RoganDawes opened this issue Jun 5, 2018 · 13 comments
Closed
3 tasks done

Initial flash does not connect to Wifi, or start an AP #2914

RoganDawes opened this issue Jun 5, 2018 · 13 comments

Comments

@RoganDawes
Copy link

RoganDawes commented Jun 5, 2018

Describe the bug

I am trying to install Tasmota on an H801 light controller. Flashing the latest sonoff.bin resulted in a slow reboot loop, with no output. After struggling to get it to change using "module 20" as documented on the wiki, I pulled the source, and built my own with module H801 selected in sonoff/user_config.h. Now, being able to see the log output, I could see it failing to connect to AP1 two or three times (noting that it didn't seem to actually have any SSID defined for AP1), falling back to WPSConfig "for 3 minutes", and then rebooting at 42 seconds, due to the reset being triggered (cause 2). I'm not sure if this means that the H801 has a GPIO connected to its own reset pin, and it's being accidentally activated?

00:00:00 Project sonoff Sonoff (Topic sonoff, Fallback DVES_9D9841, GroupTopic sonoffs) Version 6.0.0a-2_3_0
00:00:00 WIF: Connecting to AP1  in mode 11N as sonoff-6209...
00:00:11 WIF: Connect failed with AP timeout
00:00:11 WIF: Connecting to AP1  in mode 11N as sonoff-6209...
00:00:22 WIF: Connect failed with AP timeout
00:00:22 WIF: WPSConfig active for 3 minutes
00:00:42 APP: Restarting

 ets Jan  8 2013,rst cause:2, boot mode:(3,6)

load 0x4010f000, len 1384, room 16 
tail 8
chksum 0x2d
csum 0x2d
v3fff3940
~ld
00:00:00 Project sonoff Sonoff (Topic sonoff, Fallback DVES_9D9841, GroupTopic sonoffs) Version 6.0.0a-2_3_0
00:00:00 WIF: Connecting to AP1  in mode 11N as sonoff-6209...

So, I tried entering my own SSID and passphrase in sonoff/user_config_override.h, and setting the build flag in platformio.ini. I verified that the override was being used by grepping for my passphrase and SSID in firmware.bin, and the file matched. However, the serial output didn't change after I flashed that firmware, it did not see the SSID at all. The only way I could get the firmware to actually connect to the network was to edit support.ino and replace WiFi.begin(Settings.sta_ssid[Settings.sta_active], Settings.sta_pwd[Settings.sta_active]); with my own SSID and passphrase.

Also, make sure these boxes are checked [x] before submitting your issue - Thank you!

  • Searched the problem in issues and in the wiki
  • Hardware used : H801
  • Provide the output of command status 0 :

16:03:39 MQT: stat/garage_lights/RESULT = {"Time":"2018-06-05T16:03:39","Uptime":"0T00:00:50","Vcc":2.984,"POWER":"OFF","Dimmer":10,"Color":"1919191919","HSBColor":"0,0,10","Channel":[10,10,10,10,10],"CT":500,"Scheme":0,"Fade":"OFF","Speed":1,"LedTable":"OFF","Wifi":{"AP":1,"SSId":"Dawes","RSSI":48,"APMac":"F0:9F:C2:31:B1:57"}}

To Reproduce
Steps to reproduce the behavior:
Flash the latest sonoff.bin (v5.14.0) firmware from the releases onto an H801 board. Connect the UART, observe as described above.

Expected behavior

  • When configuring the preferred SSID via either user_config.h or user_config_override.h, that SSID and passphrase should actually be used.

Screenshots
If applicable, add screenshots to help explain your problem.

Additional context
Add any other context about the problem here.

(Please, remember to close the issue when the problem has been addressed)

@arendst
Copy link
Owner

arendst commented Jun 5, 2018

Pls read the header in user_config_override.h

/*****************************************************************************************************\
 * USAGE:
 *   To modify the stock configuration without changing the user_config.h file:
 *   (1) copy this file to "user_config_override.h" (It will be ignored by Git)
 *   (2) define your own settings below
 *   (3) for platformio:
 *         define USE_CONFIG_OVERRIDE as a build flags.
 *         ie1 : export PLATFORMIO_BUILD_FLAGS='-DUSE_CONFIG_OVERRIDE'
 *         ie2 : enable in file platformio.ini ;build_flags = -Wl,-Tesp8266.flash.1m0.ld -DUSE_CONFIG_OVERRIDE
 *       for Arduino IDE:
 *         enable define USE_CONFIG_OVERRIDE in user_config.h
 ******************************************************************************************************
 * ATTENTION:
 *   - Changes to SECTION1 PARAMETER defines will only override flash settings if you change define CFG_HOLDER.
 *   - Expect compiler warnings when no ifdef/undef/endif sequence is used.
 *   - You still need to update user_config.h for major define USE_MQTT_TLS.
 *   - All parameters can be persistent changed online using commands via MQTT, WebConsole or Serial.
\*****************************************************************************************************/

There is something about a CFG_HOLDER.....

@andrethomas
Copy link
Contributor

The default behaviour is to go to WIFI_WPSCONFIG as configured by default in user_config.h - This is not the same as the ESP8266 going into AP mode... for this to happen in the way you expected you would need to change #define WIFI_CONFIG_TOOL to WIFI_MANAGER - Then it would have the result you originally anticipated that when failing to connect to your wlan it would put the ESP8266 into AP mode so that you may connect directly to it.

It's just as easy to configure the STA_SSID1 and STA_PASS1 definitions in user_config.h or use the configuration override as described by arenst

So not a bug I don't think - WPSCONFIG is useful if your wireless router supports it!

@RoganDawes
Copy link
Author

From my reading of the user_config.h, CFG_HOLDER only applies if there are already settings in flash to override. In my case, I was flashing onto a clean (esptool erase_flash) H801 board.

As a result, I expected default settings in the binary to apply. I'll certainly try modifying CFG_HOLDER to see if that triggers proper use of the defined settings. Any guidance on what to change CFG_HOLDER to? Or just anything that is not 4617?

@andrethomas
Copy link
Contributor

Sure, I understand, but the default binary would have reverted to WPSCONFIG as it did according to your original logs - my point was you expected WIFI_MANAGER behaviour but WPSCONFIG behaviour was seen in your log output as it should be.

@RoganDawes
Copy link
Author

RoganDawes commented Jun 6, 2018 via email

@andrethomas
Copy link
Contributor

You initially uploaded the prebuilt binary which created the default configuration that put the WPSCONFIG in place. To update that you would need to compile and upload with this set to overwrite the originally created configuration that was put there when you flashed the first precompiled binary

image

@andrethomas
Copy link
Contributor

I just did a test

1 - Changed my user_config.h as follows

image

2 - Flashed the binary OTA and after reboot the original config persisted and it reconnected to the wifi network using the previous settings.

3 - To force it to reset to the settings I configured in step 1 above I did a reset configuration on the ESP8266 via the Tasmota web config interface.

3 - The device reset the configuration and what I configured in Step 1 above was written to the configuration and the device then appeared as a wifi AP from Windows as follows

image

After connecting to the AP created by the ESP8266 I was presented with this page

image

I then configured my Wireless AP name and password/key and clicked Save

The device rebooted and reconnected to my wifi and I just had to do all the other configuration for the pins etc as I had them before and the device is now back to normal operation.

I think its important to note that config changes made to user_config.h would only apply if the device is reset via its configuration reset functionality.... I suppose if you flash via serial things may be different but I'm not sure how it could be.

@andrethomas
Copy link
Contributor

And just like that I'm back to normal operation :)

image

@reloxx13
Copy link
Contributor

reloxx13 commented Jun 6, 2018

its written in the troubleshooting page, its written in the user_config.h and you still want a note...

at least CLOSE this "issue" yourself!

@RoganDawes
Copy link
Author

Thanks for the detailed assistance, @andrethomas and @arendst. I thought I had completely erased the flash prior to flashing the modified firmware, but apparently had skipped that step at least once. I am able to replicate your results after completely erasing the flash, and configuring my wifi in user_config.h, and flashing the resultant firmware.bin.

I will note, however, that all this started because I could not interact with the module by blindly typing "module 20" on the uart as described, after flashing the released sonoff.bin.

Nonetheless, I am happy to close this issue at this point. Thanks for a great tool!

@SteponasZ
Copy link

SteponasZ commented Feb 26, 2020

Hi, guys,

I'm trying to learn source code and playing with different settings. I'd changed wifi settings, mqtt setings and some more in my_user_config.h but leave CFG HOLDER as is. Flashed and so on. everything works, fine. After changed CFG HOLDER from 4617 to 4618. The same result, everything is fine. So. I'm also would like connect to RoganDawes guestion : Any guidance on what to change CFG_HOLDER to? Or just anything that is not 4617? Remark is not clear. Any number? Why it works if not change anything? My tasmota version is 8.1.0.9

@ascillato
Copy link
Contributor

ascillato commented Feb 27, 2020

CFG HOLDER is the value that Tasmota checks against flash. If in your flash that value is not the same as in the firmware, Tasmota interprets that as a new flash and perform a flash erase and save all settings as firmware default. If the CFG HOLDER of the flash is the same as in the firmware, Tasmota will read the settings from flash. So, there is no need to change that unless you want to trigger a full settings erase.

Anyway, you can do that reset by command reset 1 in the Tasmota console.

@SteponasZ
Copy link

Perfect, many thanks ascillato!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants