Wifi Wizard Setup Loop

Message

jobst · #1 Post by **jobst** » 19 Mar 2018, 12:32

Hi
I have many Sonoff Basic which happily run ESPEasy R120, no problems at all (they all have 4M) flashing and running.

I thought I try one of the switches with one of the latest builds ESP_Easy_v2.0-20180319_normal_ESP8266_4096.bin to see what is new, what is better and also see whether I can use some of that newer stuff for a couple of my projects, e.g. Weather station private first, than run it as a project in a school.

It flashes, no problem.

Upon reboot I can see the Easy_0 network, I connect to it, it loads the Wifi Setup Wizard.
Upon placing my network details and press connect it presents me with a message Wifi Setup Wizard and "Back to setup" as a blue bar and never gets out of it, placing mt network details into it it returns to the setup.

Flashing it with the older version again I have no problems to get the switch running again.
This cannot be a problem of the SSID/password or not being able to connect at all as it happily connects to the same network with R120.

Any ideas?
Thanks

grovkillen · #2 Post by **grovkillen** » 19 Mar 2018, 13:58

Is it a fresh flash (i.e. not an upgrade from earlier version)?

Vestus · #3 Post by **Vestus** » 20 Mar 2018, 03:28

To add a data point, I'm having similar luck with the 3-19 dev builds on a sonoff basic.

ESP_Easy_mega-20180319_normal_ESP8266_1024.bin works without issue.
Upgrading from that to 3-19-mega-dev-1024 and wifi will never connect. 2.0 dev also won't connect.

jobst · #4 Post by **jobst** » 20 Mar 2018, 03:40

grovkillen wrote: ↑19 Mar 2018, 13:58 Is it a fresh flash (i.e. not an upgrade from earlier version)?

Sorry, I thought the way I wrote it it was clear ... It used to be R120.

Jobst

jobst · #5 Post by **jobst** » 20 Mar 2018, 04:03

Vestus wrote: ↑20 Mar 2018, 03:28 To add a data point, I'm having similar luck with the 3-19 dev builds on a sonoff basic.

ESP_Easy_mega-20180319_normal_ESP8266_1024.bin works without issue.
Upgrading from that to 3-19-mega-dev-1024 and wifi will never connect. 2.0 dev also won't connect.

I will try that release candidate as well tonight (I am @ work ITM) and report back.

BTW, all my sonoff's are 4Mb and got upgraded with this: https://www.ebay.com/itm/282561761378?rmvSB=true.

TD-er · #6 Post by **TD-er** » 20 Mar 2018, 19:39

I made some changes in the WiFi.
The 20180319 build was a bit flaky when using DeepSleep, which is fixed in 20180320.
If there are still issues, please report and if you think it is somewhat reproducable, please open an issue on Github.
You could also test the 20180316 build, setup and then upgrade to the latest build.
If that's working, then I messed up something

Micha_he · #7 Post by **Micha_he** » 20 Mar 2018, 19:50

Seems that the same with 20180320:

Log from the moment, I've try to connect to wifi...

Code: Select all

WD   : Uptime 1 ConnectFailures 0 FreeMem 7592
WIFI : Could not connect to AP!

TD-er · #8 Post by **TD-er** » 20 Mar 2018, 21:07

And with the 0316 build of 4 days ago, from before my WiFi changes?

I'll wipe my testboard and see what's going on here.

Edit:
I just noticed the file you used:
ESP_Easy_v2.0-20180319_normal_ESP8266_4096.bin

That's never going to work on a Sonoff.
Those have 1 MB of flash, not 4 MB.
So you should use the 1024 version.
And if that's not going to work, try the versions for other ESP modules (not ESP8266, but ESP8285)
The 1MB versions also use DIO flash mode.

If you keep having issues with the settings not being saved, as a last resort, try the PUYA version, but only as a last resort, or if you're sure you have a chip with "PUYA" written on top of it.

jobst · #9 Post by **jobst** » 20 Mar 2018, 22:30

TD-er wrote: ↑20 Mar 2018, 21:07 Edit:
I just noticed the file you used:
ESP_Easy_v2.0-20180319_normal_ESP8266_4096.bin
That's never going to work on a Sonoff.
Those have 1 MB of flash, not 4 MB.

I explained in my initial post (and in reply to @Vestus) ALL off my Sonoff are 4MB - the entire point I am lazy ... I prefer to do OTA's.
Just to make sure: I flashed the mega stuff using USB-Serial, this was not OTA.

Vestus · #10 Post by **Vestus** » 20 Mar 2018, 23:30

Confirmed no luck with 3-20 dev.
3-20 normal build connects quickly:

WIFI : WiFi connect attempt took: 2000 ms
EVENT: WiFi#ChangedAccesspoint
EVENT: WiFi#Connected
WIFI : Connected!

I'll try rebuilding the dev image and strip the plugins.

jobst · #11 Post by **jobst** » 21 Mar 2018, 03:24

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 · #12 Post by **jobst** » 21 Mar 2018, 03:39

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 · #13 Post by **Vestus** » 22 Mar 2018, 00:05

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 · #14 Post by **TD-er** » 22 Mar 2018, 00:36

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 · #15 Post by **jobst** » 22 Mar 2018, 00:54

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 · #16 Post by **TD-er** » 22 Mar 2018, 01:10

@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 · #17 Post by **Vestus** » 22 Mar 2018, 01:33

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 · #18 Post by **jobst** » 22 Mar 2018, 02:18

TD-er wrote: ↑22 Mar 2018, 01:10 @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 · #19 Post by **Vestus** » 22 Mar 2018, 14:00

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 · #20 Post by **TD-er** » 22 Mar 2018, 20:02

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

Vestus · #21 Post by **Vestus** » 22 Mar 2018, 22:11

I left it up during the day.

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

jobst · #22 Post by **jobst** » 22 Mar 2018, 23:04

Vestus wrote: ↑22 Mar 2018, 14:00 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 · #23 Post by **Vestus** » 22 Mar 2018, 23:24

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 · #24 Post by **TD-er** » 23 Mar 2018, 11:09

Vestus wrote: ↑22 Mar 2018, 23:24 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 · #25 Post by **Vestus** » 23 Mar 2018, 14:53

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 · #26 Post by **TD-er** » 24 Mar 2018, 01:31

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 · #27 Post by **Vestus** » 24 Mar 2018, 02:45

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 · #28 Post by **jobst** » 25 Mar 2018, 04:12

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 · #29 Post by **TD-er** » 25 Mar 2018, 10:54

jobst wrote: ↑25 Mar 2018, 04:12 [...]

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 · #30 Post by **Vestus** » 25 Mar 2018, 20:18

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 · #31 Post by **TD-er** » 25 Mar 2018, 20:28

Vestus wrote: ↑25 Mar 2018, 20:18 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 · #32 Post by **Vestus** » 25 Mar 2018, 23:11

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 · #33 Post by **jobst** » 26 Mar 2018, 01:15

TD-er wrote: ↑25 Mar 2018, 10:54 [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 · #34 Post by **TD-er** » 26 Mar 2018, 16:23

jobst wrote: ↑26 Mar 2018, 01:15
TD-er wrote: ↑25 Mar 2018, 10:54 [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 · #35 Post by **grovkillen** » 26 Mar 2018, 18:42

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

jobst · #36 Post by **jobst** » 27 Mar 2018, 03:24

TD-er wrote: ↑26 Mar 2018, 16:23 [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 · #37 Post by **TD-er** » 27 Mar 2018, 09:20

jobst wrote: ↑27 Mar 2018, 03:24 [...]

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 · #38 Post by **jobst** » 28 Mar 2018, 03:02

TD-er wrote: ↑27 Mar 2018, 09:20 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 · #39 Post by **dirk_k** » 23 May 2018, 16:53

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);
}

Who is online