Topics

Problem connecting to wemos d1 mini pro with android devices


schinos@...
 

Hi all,

First of all i would like to thank Howard and all for this fantastic project!

I have been putting together the MaxPCB2 project with the 3.16 source code and i am facing a weird issue concerning, basically, the connection of android devices to the wifi.
I have a wemos d1 mini pro (v1.1) set up as Access Point only as i want it to be ready for outdoor usage.
Windows seem to connect normally to the wifi ssid and access the internal website with no issues or packet loss but two android devices i have, do not connect.
The problem shows up as connecting and disconnecting rapidly until the phones give up and connect to my main home ssid.
Some times they do connect but stay in the "Obtaining IP Address" for a while until they time out and finally connect to my main home ssid.
Some fewer times, only counted on my one hand, they do connect to the OnStep ssid, after several attempts, they do get ip address but the connection is extremely sluggish with either the internal web server through a mobile browser or with the OnStep App. On these very rare occasions the wifi connection is dropped automatically after a while.

Things i have tried so far and didn't help:
Rebooted several times mobile phones and OnStep.
Used various board firmware versions.
Used static IP Address on the Android devices.
Check if there is any other wifi broadcasting on the same channel.
Changed SSID and/or password just in case there is any long shot incompatibility.
Forced wemos to use only IEEE 802.11 B or IEEE 802.11 G just to see if there is any difference.
Tried null password.
Tried no channel selection.
Tried open/shared ssid mode.
Inserted a dnsserver in the code to respond to all dns requests and redirect them to the intenal web server.
Performed All Flash Content erase on every upload.
Used the "WiFi.disconnect();" after "if (accessPointEnabled && !stationEnabled) {" that Howard proposed on an other thread.
Reset Network settings on the mobile devices.
Have used the internal ceramic antenna and then switch to the external.
Tried various physical distances between the antenna and the mobile devices.
Tried with DEBUG_ON and disconnected from MaxPCB2.


The weird thing is that if i disconnect wemos from MaxPCB2 and use any tutorial code for wemos d1 mini that i have found online, the mobile phones connect normally to the broadcasted ssid with no perceived connection problem.
The above implies that this is not a incompatibility issue with the board itself.
The phones have Android 9 with all the latest updates installed.

The versions of software that i currently use: Arduino IDE 1.8.12 and esp8266 v 2.4.2

So i would appreciate very much your help as i have spent countless hours on this.

Thank you in advance
Konstantinos


Howard Dutton
 
Edited


Try this code (for Access Point only, wondering about the order of operations setting up the WiFi stack.)  If it doesn't work remove the disconnect statements and try again.  Then rearrange the order of the remaining and try again.

TryAgain:
  if (accessPointEnabled && !stationEnabled) {
    WiFi.disconnect();
    WiFi.softAPdisconnect(true);
    WiFi.mode(WIFI_AP);

    WiFi.softAPConfig(wifi_ap_ip, wifi_ap_gw, wifi_ap_sn);
    WiFi.softAP(wifi_ap_ssid, wifi_ap_pwd, wifi_ap_ch);
  } else


schinos@...
 

Hi Howard,
Thank you very much for your promt response.
I tried your suggestions but unfortunately non worked. They all produced the same behavior.
I also tried changing the board from "LOLIN(WEMOS) D1 R2 & mini" to "LOLIN(WEMOS) D1 mini Pro" or "LOLIN(WEMOS) D1 mini lite" or even "Wemos D1 R1" with no success,
I tried changing the "Flash size" options for each of the above and the outcome was more or less the same.
One thing i noticed was this:
On every attempt after uploading the sketch i made the phones forget the ONSTEP wifi, and tried to connect by entering the passphrase again which concluded in the known outcome.
On some occasions that i had forgotten to delete the wifi, the phones responded as if the passphrase was not correct, either prompting to reenter the passphrase or just say "authentication error".
so it tried hard coding the password (just in case there was some weird flash issue) with this "WiFi.softAP(wifi_ap_ssid,"password", wifi_ap_ch);" but it did not work either.
On some even more rare occasions in which at least one of the phones moved in the "obtaining ip address" state, it would stay there for a while and then it would "loose" the ONSTEP wifi from the list for a while. During this time and until the ONSTEP wifi would reappear in the list the led on the Wemos would stay still.

Thank you in advance
Konstantinos


Howard Dutton
 

Download the latest master.

Use the ESP8266 libraries 2.4.2 or 2.7.2 in the board manager.

OnStep:  In its Config.h change no baud rate settings but configure for your device.  Then flash it.

WiFi Addon:  In its Config.h change no settings at all.  Then flash it into the WeMos D1 Mini.  Use the "LOLIN Wemos D1 and Mini" selection.  Change only the setting so it wipes all flash memory on upload.

Connect everything together.

Report on the WeMos D1 Mini blue led.  Does it flash and eventually turn solid blue?


Howard Dutton
 

On Mon, Jul 13, 2020 at 03:36 PM, Howard Dutton wrote:
WiFi Addon:  In its Config.h change no settings at all.  Then flash it into the WeMos D1 Mini.  Use the "LOLIN Wemos D1 and Mini" selection.  Change only the setting so it wipes all flash memory on upload.
Like this:


schinos@...
 

Howard thank you for your immediate response!

I would like to clarify a little more on the matter: once i power up the MaxPCB, the blue led of wemos starts blinking and continues for about 30 - 40 seconds before it turns solid blue and stays that way throughout the whole operation until i power it off. I have never experience it to turn off or start blinking without me doing a restart or reset by button. This behavior has not changed even though i have configured the baud rate on both ONSTEP and WIFI to 115200.
I will try what you suggested and report back.
I noted on the screenshot you attached that for Programmer you have "AVR ISP" but i have (as a default value) "AVRISP mkII".
Would that play any role in general or more specifically on this matter?

Thank you again very much for your support, effort and time!

Konstantinos


Howard Dutton
 

On Tue, Jul 14, 2020 at 02:39 AM, <schinos@...> wrote:
I noted on the screenshot you attached that for Programmer you have "AVR ISP" but i have (as a default value) "AVRISP mkII".
A setting that is not used in this case.  Doesn't matter.


Howard Dutton
 

On Tue, Jul 14, 2020 at 02:39 AM, <schinos@...> wrote:
I will try what you suggested and report back.
I see you trying a bunch of things to solve a problem that you alone, AFAIK, have encountered.  This works for many users on many devices, the play store says my App is active on 1281 devices presently and I bet > 50% use WiFi.

The idea here is to start at the beginning.  Reset/clear everything.  OnStep and the phone you are trying to connect to.  Additionally, the master branch WiFi has new code that streamlines the connection process that some users trip over so you will be using new code.  Which is a good thing and a bad thing since release-3.16 is tried and true, just connecting can be a bit clumsy (you have to not automatically connect and wait for OnStep to come up beforehand.)


schinos@...
 

Hi Howard,

I basically believe that also, that is that i have done something "unique" exactly because no one else has had this problem so far.
I hope that is not something stupid enough to say we have thrown so many hours to the garbage.
Those are the reasons why i have tried all the above.
To the matter now: i have downloaded the latest master and changed in the ONSTEP config all setting relevant to my setup but not baud rates. In the wifi config nothing was changed. All flashed successfully and the esp8266 board firmware was left to 2.4.2
Flashing blue led for 35 - 42 seconds (average).
First attempt to connect with the mobile device accepted the passphrase but stuck on "Obtaining IP Address" were after a while it just dropped trying and connected to me home ssid. The rest hand triggered retries to connect to the wifi went form "Connecting" to "Saved" again and again.
The second mobile device never even moved form the passphrase screen saying "could not connect to network" but on the wifi list it said "Authentication error occurred". I tried powering off and on again Maxpcb2 but same results.

Then downloaded firmware 2.7.2 and reflashed the wemos board.
More or less the same time flashing blue until solid.
None of the mobile device accepted the passphrase. The first mobile device reappeared the passphrase screen after i entered it for the first time. Consecutive MaxPCB power off and on did not change the behavior.

Is there a way to get extended wifi debug info from the wemos just in case something stands out and points to the problem?

Thank you very much
Konstantinos


Tong
 

The same thing happened with Huawei P30PRO. I have another phone that can connect normally


schinos@...
 

Hi Tong,

Have you managed to make the Huawei connect? What version of Android was it using when you tried that? I am asking because i see that it ships with 9 but is upgradable to 10.
My devices, a Xioami red mi 7 and a Samsung J7 (2017) both use 9.
Long shot, i know and probably if something like this exited it would have shown up a lot more.

Thanks anyway


Howard Dutton
 

On Wed, Jul 15, 2020 at 06:15 AM, <schinos@...> wrote:
upgradable to 10
Lots of my Android App users are on 10.  I'm on 10.


Howard Dutton
 
Edited

Last night I flashed an WeMos D1 Mini to look at another issue...

Master branch WiFi using 2.4.2, it didn't work (testing of that was on 2.7.2.)  I reverted to the design in release-3.16 and all was well.

The master branch has two changes, simple re-ordering of calls it uses to initialize WiFi:
  • First was to get the ESP32 "working"... and it only ever kind of sort of worked for me. 
  • Second was a recent change to get an iPad2 working where a user was having trouble.

I'm getting to the point where I don't like either change and may very well revert to the original design.
Hopefully with disconnect calls early in the boot so users don't get to join the AP before they should.


Howard Dutton
 

So for now I'd test with release-3.16's WiFi Addon (using 2.4.2 or 2.7.2) and make sure you wait another 30 seconds (less should be ok but lets be sure) past when the blue light on the WeMos is steady on to connect.


Tong
 

The HUAWEI P30pro Android 10 problem has not been solved. P30pro can normally connect to Onstep and obtain the IP address. When opening Sky Safari and Onste app, it is reported that the connection failure cannot obtain the IP address.Another HUAWEI Honor 8 Android 8.0 made 4 years ago can be used normally.Same problem with P30pro Onstep and TeenAstro.


Howard Dutton
 

On Wed, Jul 15, 2020 at 09:56 AM, Howard Dutton wrote:
I'm getting to the point where I don't like either change and may very well revert to the original design.
Hopefully with disconnect calls early in the boot so users don't get to join the AP before they should.
The master branch has been reverted to the WiFi initialization order as used with release-3.16 (and 2.22 I'm pretty sure.)  It seems to be the most trouble free overall.

I also added the early disconnect at startup since I feel there are some troubles and confusion caused by connecting to the WiFi before it's really ready.
With the prior design the WiFi/SSID comes up immediately and looks good when powered on but the ESP hasn't connected to OnStep yet and the WiFi mode will still be re-configured later.  When it does that re-configuration anything that's connected remains connected but stops working.

Now at boot it turns the AP mode off/disconnects so there is nothing to connect to until it's ready.  So, with this change as soon as you see the OnStep SSID it's good to connect to.  As for the ESP libraries it's 2.7.2 with possible fixes but not well tested/proven vs. the tried and true version 2.4.2 take your pick.  Other versions exist but these are the two most trusted ones as far as I'm concerned.


Drew 🔭📷🚴‍♂️
 

On Fri, Jul 17, 2020 at 10:17 AM, Howard Dutton wrote:
The master branch has been reverted to the WiFi initialization
All of this is under WiFi 1.14.b? Do we need a patch level increase?


Howard Dutton
 

I've been running the WiFi Addon using ESP8266 version 2.7.2 for a while now and the noticed that the IP command channels would stop functioning after being connected for about 24 hours.  First time it happened I switched to using the persistent command channel which was still working.  It failed too the next day.  Cycled the power and tried again..  failed again the next day.

I switched the Arduino IDE "lwIP Variant" to "Higher Bandwidth (no features)" and it's been stable for the last week so guessing that took care of the issue.