Wifi Wizard Setup Loop

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