Wifi Wizard Setup Loop

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