Wifi Wizard Setup Loop

[jobst]

No luck for me, whatever "things" I use:

- Release mega-20180320
- Release mega-20180319
- Release v2.0-20180319
- used linux and esptool.py with various files: dev,test,normal
- used windows and flashtool.exe using various bin files: dev,test,normal

It never gets passed "the loop".

As soon as I flash the device using "ESPEasy_R120_4096.bin" I have no problems - however in that case I use Linux and esptool.py as I can specify the mode of "DOUT".

[jobst]

Is there a way to debug this .. i.e. use minicom to connect to /dev/ttyUSB0 to have some output during boot or connection to WIFI?

At least that way I can be of some help ....

[Vestus]

I have no idea if there's build options for dev, but the console gave me little.

I'm very unfamiliar with the ESPE ecosystem, but the fact that DEV builds fail but 'Normal' builds don't indicate something is awry in either the Dev merge or plugins.

I'm trying to strip, but unfortunately ATOM/PIO crapped itself and VS Code refuses to properly link a dev PIO build for me. (no plugins are evident)

Sublime with PIO is next.

PS. 21 has no change.

WIFI : Connecting ddwrt-iot attempt #1
WIFI : Connecting ddwrt-iot attempt #2
WD : Uptime 1 ConnectFailures 0 FreeMem 15272
WIFI : Connecting ddwrt-iot attempt #3

[TD-er]

After some debug session on the Github it appeared the timeout was a bit too short.
I've now set it to 10 seconds.

If that's still not enough, please report.

[jobst]

I had some luck.
After many attempts to get any of the later releases to work (2.XXX and mega.XXX) I used the mega-20180316 and it is indeed running:

Code: Select all

Firmware
 Build	20100 - Mega (core 2_3_0)
 GIT version	mega-20180316
 Plugins	48 [Normal]
 Build Md5	f1c9d0659ee99bd5a61f63cffccb1d9
 Md5 check	passed.
 Build time	Mar 16 2018 03:02:59

I also thought that I am too far away from the WIFI router (R7000 night hawk) whilst programming, so I sat beside it with my laptop and the Sonoff basic attached to a Windows 10 with a Prolific USB-Serial. Did not make any difference no matter what Release version I used and/or dev/normal/test. I even tried the 1024 DOUT version that is part of the distributions although my board has 4MB - but then I have 2 Sonoff Basic running a EspEasy R120 in a metal shed in an electrical cupboard about 30m away from the WIFI router and they do not miss a beat running the outside shed lights and garden lights.

The only way I could get it to work is using my Linux desktop, an Arduino compatible USB-Serial (this one https://www.jaycar.com.au/arduino-compa ... e/p/XC4464) and the following command line (note the DOUT) and the normal mega distro from the 16th.

Code: Select all

esptool.py --port /dev/ttyUSB0 write_flash -fm dout -fs 4MB 0x0  ESP_Easy_mega-20180316_normal_ESP8266_4096.bin

Also the desktop is in our Study which is in the far corner of our home behind a few rather thick walls - so it seems the location/distance does not matter (WIFI is a R7000 night hawk).

Here is some info about the flash

Code: Select all

Storage
  Flash Chip ID	Vendor: 0xEF Device: 0x4016 
  Flash Chip Real Size:	4096 kB
  Flash IDE Size:	4096 kB
  Flash IDE speed:	40 MHz
  Flash IDE mode:	DOUT
  Flash Writes	17 daily / 17 boot
  Sketch Size	599 kB (2472 kB free)

Now I tried the mega-20180316 on my windows laptop AND my linux desktop - it works using the linux machine. Considering I had problems getting the R120 installed on my Sonoff basic using the "flash.cmd" provided in that release verion using my Windows laptop (I asked questions about this on the espeasy forum) I can say that there is a relationship between the way it's flashed and the utility being used as I only was able to flash AND get it running using the linux laptop with mode DOUT.

I am not sure whether in the latest release the Windows FlashESP8266.exe uses DOUT - I do not know.

Conclusion from my observation when using a Linux desktop and esptool.py I can get (and only those two) R120 and mega-20180316 to work.

[TD-er]

@jobst
Is that more about flashing issues or about the WiFi issues?

I think I nailed the problem now, for the initial setup it is set to 20 seconds, since then the accesspoint feature is still active, which may cause some delays in initial connection.

[Vestus]

If the delay is 10 sec, and this is a dev-build-only issue for stock sonoff chips, something's up with the dev builds.
Stock 'normal' builds will connect within 2000ms, so 20sec doesn't address whatever the root cause is.

( Float me an instrumented build and I'll post the console output. My AP is about 10 feet away. )

If you just want to address timing, 20 may be enough, but you'll likely get into situations/APs where it isn't. I'd suggest a progressive timeout like:

timeout_sec = 20 + 2*attempts.
Maybe MIN(300, 10+10*failures) to cap it at 300s.

On a positive note, my dev build did finally connect, but subsequently disconnected?

WD : Uptime 64 ConnectFailures 0 FreeMem 12992
WIFI : Connecting ddwrt-iot attempt #54
WIFI : Connecting ddwrt-iot attempt #55
WD : Uptime 65 ConnectFailures 0 FreeMem 12552
WIFI : WiFi connect attempt took: 13999 ms
EVENT: WiFi#Connected
WIFI : Connected! IP: 192.168.2.236 (ESP_Easy_0) AP: ddwrt-iot AP BSSID: 7A:8A:20:87:4D:BF
WIFI : AP Mode disabled
WD : Uptime 65 ConnectFailures 0 FreeMem 14936
WD : Uptime 66 ConnectFailures 0 FreeMem 14936
WD : Uptime 66 ConnectFailures 0 FreeMem 14936
WIFI : Connecting ddwrt-iot attempt #0
WD : Uptime 67 ConnectFailures 0 FreeMem 15376
WIFI : Connecting ddwrt-iot attempt #1
WIFI : Connecting ddwrt-iot attempt #2
WD : Uptime 67 ConnectFailures 0 FreeMem 15376

[jobst]

@jobst
Is that more about flashing issues or about the WiFi issues?

I think I nailed the problem now, for the initial setup it is set to 20 seconds, since then the accesspoint feature is still active, which may cause some delays in initial connection.

IMHO it's both. I cannot get it to flash on a Windows box at all but also there is a connection problem ...

Even with the mega-20180316 it took me three attempts to connect - it first went to the loop but then it connected.

Very important, though: As soon as I get the initial connection to work all problems are gone - it will always connect after a boot straight away - even behind a metal shed wall in a wooden electrical cabinet in it's plastic cover with the WIFI router about 40 meters away (I should really measure this!).

[Vestus]

40m is impressive!

At 10 feet, mine connects and disconnects randomly.

: Connecting ddwrt-iot attempt #45
WIFI : Connecting ddwrt-iot attempt #46
WD : Uptime 826 ConnectFailures 0 FreeMem 12992
WIFI : Connecting ddwrt-iot attempt #47
WIFI : Connecting ddwrt-iot attempt #48
WIFI : WiFi connect attempt took: 5999 ms
EVENT: WiFi#Connected
WIFI : Connected! IP: 192.168.2.236 (ESP_Easy_0) AP: ddwrt-iot AP BSSID: 7A:8A:20:87:4D:BF
WIFI : AP Mode disabled
WD : Uptime 827 ConnectFailures 0 FreeMem 15376
WIFI : Connecting ddwrt-iot attempt #0
WIFI : Connecting ddwrt-iot attempt #1
WIFI : Connecting ddwrt-iot attempt #2
WD : Uptime 827 ConnectFailures 0 FreeMem 15376
WIFI : Connecting ddwrt-iot attempt #3
WIFI : Connecting ddwrt-iot attempt #4
WD : Uptime 828 ConnectFailures 0 FreeMem 15376
WIFI : Connecting ddwrt-iot attempt #5
WIFI : Connecting ddwrt-iot attempt #6
WIFI : AP Mode enabled
WIFI : Connecting ddwrt-iot attempt #7
WD : Uptime 828 ConnectFailures 0 FreeMem 12992
WIFI : Connecting ddwrt-iot attempt #8
WIFI : Connecting ddwrt-iot attempt #9
WD : Uptime 829 ConnectFailures 0 FreeMem 12992
WIFI : Connecting ddwrt-iot attempt #10
WIFI : Connecting ddwrt-iot attempt #11
WD : Uptime 829 ConnectFailures 0 FreeMem 12992
WIFI : Connecting ddwrt-iot attempt #12
WIFI : Connecting ddwrt-iot attempt #13
WD : Uptime 830 ConnectFailures 0 FreeMem 12992
WIFI : Connecting ddwrt-iot attempt #14
WIFI : WiFi connect attempt took: 13000 ms
EVENT: WiFi#Connected
WIFI : Connected! IP: 192.168.2.236 (ESP_Easy_0) AP: ddwrt-iot AP BSSID: 7A:8A:20:87:4D:BF
WIFI : AP Mode disabled
WD : Uptime 830 ConnectFailures 0 FreeMem 14936
WD : Uptime 831 ConnectFailures 0 FreeMem 14936
WD : Uptime 831 ConnectFailures 0 FreeMem 14936
WIFI : Connecting ddwrt-iot attempt #0
WIFI : Connecting ddwrt-iot attempt #1
WIFI : Connecting ddwrt-iot attempt #2
WD : Uptime 832 ConnectFailures 0 FreeMem 15376
WIFI : Connecting ddwrt-iot attempt #3
WIFI : Connecting ddwrt-iot attempt #4

[TD-er]

It is very strange that reconnects take so long and so many attempts.

[Vestus]

I left it up during the day.

The longest consecutive string of uptime messages I see in the log is about 10 minutes.

[jobst]

At 10 feet, mine connects and disconnects randomly.
[snip]

3m? There is something else going on ... the sonoffs are much better than that!

Not sure how good your knowledge is about WIFI, also not sure what your router is - mine is R7000 running latest ddwrt, these two combined really help network performance and iron out issues.

Also I have an Android phone, so I have a few WIFI/Network checking apps, e.g. "Wifi Analyzer", "Fing" and "Ping & Net". Those 3 combined help me to find issues. The Wifi Analyzer's "Channel Graph" is bloody awesome - you can immediately spot problems, i.e. too many networks sharing 1 channel ... It also helps to see how good the signal is close to a device - for example I hold my phone close to the antenna of a device I want to check with the channel graph visible and look at the channel graphs Signal Strength in DB ... I discovered some black spots and interferences.

Also it sometime helps (if you have multiple antennas on your router) to have 1 antenna pointing up, one vertical and one pointing down - it made a huge difference in reading stuff with our phones ...

[Vestus]

I hate to point this out again, but the Normal build works perfectly fine for me. It's just the Dev image out of the official tarball.

Here's a new wrinkle..

I just rebuilt the 3-21 dev image locally and it's stable. Connected in 4000ms.

I'll leave it up to make sure it's stable and reflash with the official in a couple hours.

Edit: RSSI is -48 dB

[TD-er]

I hate to point this out again, but the Normal build works perfectly fine for me. It's just the Dev image out of the official tarball.

Here's a new wrinkle..

I just rebuilt the 3-21 dev image locally and it's stable. Connected in 4000ms.

I'll leave it up to make sure it's stable and reflash with the official in a couple hours.

Edit: RSSI is -48 dB

So the pre-built version differs in stability between the "dev" and "normal" builds?
I will test here with the dev also just to see what's wrong here.

And due to some miscommunications between me and someone with stability issues, I made it even worse
Let's hope there will be a stable version with the next build and I will definitely test the dev version here on my boards.

[Vestus]

I've only been working with this package for a week, so much of the cycle/infrastructure is foreign to me too. The original poster may have a different problem than I found, but it seemed too similar to warrant a new thread.

One other possible factor is toolchain. I'm building with PIO rev 3.5.2.

(I don't see any notes or buildlogs in the posted bundles that mention toolchain revisions.)

[TD-er]

Could you try to build this version I made today: https://github.com/letscontrolit/ESPEasy/pull/1165
It's quite a different approach to getting WiFi connected and I hope it is way more stable, since in principle it is simpler.

[Vestus]

Looks positive -

WIFI : DHCP IP: 192.168.2.236 (ESP-Easy-0) GW: 192.168.2.1 SN: 255.255.255.0 duration: 1571 ms
EVENT: WiFi#Connected
WD : Uptime 1 ConnectFailures 0 FreeMem 13856
WD : Uptime 1 ConnectFailures 0 FreeMem 13856
WD : Uptime 2 ConnectFailures 0 FreeMem 13856

edit: 20 minutes and no hiccups. Restarted, no hiccups. I'll update in the morning.

Looks positive -

WIFI : DHCP IP: 192.168.2.236 (ESP-Easy-0) GW: 192.168.2.1 SN: 255.255.255.0 duration: 1571 ms
EVENT: WiFi#Connected
WD : Uptime 1 ConnectFailures 0 FreeMem 13856
WD : Uptime 1 ConnectFailures 0 FreeMem 13856
WD : Uptime 2 ConnectFailures 0 FreeMem 13856

edit: 20 minutes and no hiccups. Restarted, no hiccups. I'll update in the morning.

followup:
WD : Uptime 556 ConnectFailures 0 FreeMem 13688
WD : Uptime 556 ConnectFailures 0 FreeMem 13688

Looks stable.

[jobst]

I figured something else.

Due to the usage of SPIFFS and storing the data (including the wifi credentials and/or previous ipaddress) there are some inconsistencies when re-flashing and NOT having minicom/putty open to see the output during boot.

On a number of occasions I was waiting for the configuration web interface to pop up after a flash so I could give my SSID/key but it did not show up - until I started realising it was already connected to the WIFI. On other times the web interface does pop up to query the SSID/key - but I have not figured out when/why this happens (I have not read the code).

Now when I re-flash I open a ssh to the DHCPD server to see whether an ip address is queried, I also check via minicom/putty the output of the serial interface.

There should be a consistent way after reflash - or maybe there is and I do not get it?

[TD-er]

[...]

There should be a consistent way after reflash - or maybe there is and I do not get it?

Simply stated:
If there are valid WiFi credentials, it will try to connect to the accesspoint.
If no valid credentials, or a number of retries failed, it will start an accesspoint itself.

N.B. this can also happen during normal use, for example when the configured accesspoint is unreachable long enough for the number of retries exceeded.

If a connection can be made, the internal accesspoint will be disabled after 30 or 60 seconds (not sure).

[Vestus]

Your async change conveniently gets me closer to starting on a different project.

In short, I need the AP hotspot configurable to be on permanently, and pre-patch that looked like a total rewrite of wifi.ino.

My goal is to detect if a configured mac attaches to the AP and trigger an event. This would give us the option to use those $2 Amazon Dash buttons as a trigger/button (without requiring arp filters and firewalls).
After locking the AP up (or configuring a default state instead of the fallback-to-ap mode), it wouldn't take much to bind a callback to station connect event as described here -
https://bbs.espressif.com/viewtopic.php?t=1927#p11376. There it would check for matches in a list and throw an event if found.

If it can run as an AP, we shouldn't need another AP to run an ESP based sensor setup.

Beyond buttons, permanent AP support could also be useful for wifi isolated areas like a detached garage or barn.

[TD-er]

Your async change conveniently gets me closer to starting on a different project.

In short, I need the AP hotspot configurable to be on permanently, and pre-patch that looked like a total rewrite of wifi.ino. [...]

Well it doesn't have to be a complete rewrite of the Wifi.ino, since almost all is already present.
It would probably take about 30 lines of code to achieve it (50 in my coding style )

There are already WiFi events for this:

Code: Select all

WiFiEventHandler  onSoftAPModeStationConnected (std::function< void(const WiFiEventSoftAPModeStationConnected &)>)
WiFiEventHandler  onSoftAPModeStationDisconnected (std::function< void(const WiFiEventSoftAPModeStationDisconnected &)>)

Thing is that the performance and responsiveness seems to be affected when both accesspoint and "station mode" are active.
It is also possible to use some kind of mesh structure, which is way more flexible, but I haven't found time yet to test it.

[Vestus]

The rewrite was more to keep it from performing the STA/AP fallback cycle.

Thing is that the performance and responsiveness seems to be affected when both accesspoint and "station mode" are active.

That sounds like an 'off-by-default' feature with a warning label, buried under the 'Advanced' tab.

Realistic modes would be a choice of AP-only/AP+STA/STA+fallback. It would be nice if fallback timeout was configurable too.

For my project, I'd like to replace a $70+ system with a $7 setup (https://www.amazon.com/Collector-Remote ... ef=sr_1_37, https://www.amazon.com/s/ref=nb_sb_noss ... words=ivac), and I know others would love anything simpler than the current Dash arp hack method.

Once AP can be configured as permanent, it'd take a minuscule plugin to scrape a list of macs for a match. A mask option may also be a good stretch goal.

Let me know if I can help.

PS. Nice work on the async patch.

[jobst]

[snip]
N.B. this can also happen during normal use, for example when the configured accesspoint is unreachable long enough for the number of retries exceeded.
If a connection can be made, the internal accesspoint will be disabled after 30 or 60 seconds (not sure).

I get that ... What I was writing about are inconsistencies ... Sometimes after flashes it asks me for the SSID, sometimes it does not.
That is confusing.

BTW my AP never goes down - it is that stable.

Jobst

[TD-er]

[snip]
N.B. this can also happen during normal use, for example when the configured accesspoint is unreachable long enough for the number of retries exceeded.
If a connection can be made, the internal accesspoint will be disabled after 30 or 60 seconds (not sure).

I get that ... What I was writing about are inconsistencies ... Sometimes after flashes it asks me for the SSID, sometimes it does not.
That is confusing.

BTW my AP never goes down - it is that stable.

Jobst

Some accesspoints have a (hard) limit on the number of connected devices. Could it be you're hitting some kind of limit like 32 simultaneous connected devices?
Then even valid settings will not lead to a connection and thus it will enter the accesspoint/setup mode.

[grovkillen]

My old APs had a 6 unit limit, just to add to the discussion.

[jobst]

[snip]
Some accesspoints have a (hard) limit on the number of connected devices. Could it be you're hitting some kind of limit like 32 simultaneous connected devices?
Then even valid settings will not lead to a connection and thus it will enter the accesspoint/setup mode.

I have a Netgear Nighthawk R7000 with DDWRT running, there is a connection limit of default 128, currently connected are 9 devices on wl0 and 3 on wl1.
Most of my network is connected via cat5e (all gaming devices,tv,pvr,half of sonoS etc) only the laptops, mobile phones, some sonos and sonoffs are connected via WIFI.
Also Sonos has it's own network.

I do not think I am htting a bottle neck there.

[TD-er]

[...]

I do not think I am htting a bottle neck there.

Sounds reasonable
Did you experience strange wifi-related issues like these since the last 2 updates?
Last weekend I changed the wifi to be completely event based. This means it will react almost immediately on changes like connect, disconnect and "GotIP".
Also the disconnect reason is now visible in the info page. One of the many possible disconnect reasons is about the available free slots.

[jobst]

Did you experience strange wifi-related issues like these since the last 2 updates?

I stopped using the latest builds after the 20180320 as the 20180316 worked for me (as it was suggested to use).

I am getting a bunch of new sonoffs, also I need to flash two other sonoffs (also putting some extra pins,wires,resistors onto those) that have R120 on them.
I will do this on the weekend, I will report back - also I will be watching the serial console output too this time whether it connects straight away.
Also I will log into the WIFI AP via ssh and put a trace onto the sonoff traffic ... that might help me.

[dirk_k]

i upgrade one of my sonoff-basic devices these year. (don't know the date or version)
i get wifi problems since upgrade.
device lost WLAN and built i'ts own. Thats as expected.
But if my WLAN is back the device don't go back to my WLAN and it#s own WLAN keeps active for days/weeks/or.. .

I have to drive to the device these days to reboot it and check version and log.
Is a problem like this known or fixed these Year?

If we can provide a Wishlist for WiFi tuning ...
An option to disable the build in AP is a great security feature, but i would prefer a configurable timeframe after rebooting the device, where the AP Mode is allowed if my WLAN fails.

my Code example within WIFI.INO with hard-coded timeout (slightly outdated)
//********************************************************************************
// Configure network and connect to Wifi SSID and SSID2
//********************************************************************************
boolean WifiConnect(byte connectAttempts)
...
addLog(LOG_LEVEL_ERROR, F("WIFI : Could not connect to AP!"));

//everything failed, activate AP mode (will deactivate automaticly after a while if its connected again)

// MARKER: if uptime > 5 min deny autom. AP mode
if ( (wdcounter / 2) > 5 )
{
addLog(LOG_LEVEL_INFO, F("myWiFi: Uptime > 5 Min - AP-Mode disabled"));
WifiAPMode(false);
NC_Count = 0;
}
else
{
WifiAPMode(true);
}

return(false);
}