-
Notifications
You must be signed in to change notification settings - Fork 4.7k
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
Comments
Pls read the header in user_config_override.h
There is something about a CFG_HOLDER..... |
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! |
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? |
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. |
Apologies, I failed to mention that I had also changed the fallback to WiFi
manager, and thus expected that behaviour.
…On Wed, 6 Jun 2018, 14:19 andrethomas, ***@***.***> wrote:
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.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#2914 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAJwi726WIfg5kRQTJe8hn6uO-BcJPfPks5t58jsgaJpZM4UbA8x>
.
|
I just did a test 1 - Changed my user_config.h as follows 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 After connecting to the AP created by the ESP8266 I was presented with this page 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. |
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! |
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! |
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 |
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 |
Perfect, many thanks ascillato! |
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?
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!
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
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)
The text was updated successfully, but these errors were encountered: