Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

iSpindel losing connectivity when going thru Wifi extender #318

Closed
jmcazaux opened this issue Dec 2, 2019 · 9 comments
Closed

iSpindel losing connectivity when going thru Wifi extender #318

jmcazaux opened this issue Dec 2, 2019 · 9 comments
Labels

Comments

@jmcazaux
Copy link
Contributor

jmcazaux commented Dec 2, 2019

Hi there,

I am facing faradic issues, but while investigating, I noticed that the iSpindle seems to be losing connection when going thru a wireless extender.

Steps to reproduce:

  • start the iSpindle (fully configured) near your Wifi router / AP
  • check that it logs OK to your target (Ubidots, etc.)
  • let it run for a while (in my case, it worked flawlessly for 8 hours at 15s interval)
  • move the iSpindle close to the Wifi extender
  • check that it logs OK to your target (Ubidots, etc.)
    If it does not log to Ubidots, put the Spindel in config. mode (double reset) and save the config again.
    Check that it logs OK to your target (Ubidots, etc.)

What is wrong:

  • at some point, Ubidots (or your target) will stop receiving data.
    In my case it stopped after 20 frames.

Note : my Wifi extender is a Netgear WN3000RP with the same SSID as the main router.

I am happy to help investigating / debugging further.
I do not have experience in platform development, but I have installed the PlatformIO plugin in VSCode and with a bit of guidance I shall be able to have the thing running and logging stuff.

If this is useful, my Spindel was built from this kit.

Hope this helps,
JM

@universam1
Copy link
Owner

Thank you for the detailed problem description.

As I read your are confirming that the iSpindel does work as expected, but there seems to be an issue with the Extender rather.

For any help here it would at least be necessary to attach the logs from the console while in this situation.

@jmcazaux
Copy link
Contributor Author

jmcazaux commented Dec 2, 2019

Roger that @universam1 , I'll try to get the error captured in the console in the next days.

@jmcazaux
Copy link
Contributor Author

jmcazaux commented Dec 3, 2019

As agreed, here what I am consistently getting when trying to connect via my Wifi extender...

A few good frames (just one here), and then it fails on connecting to the Wifi

Final-sleep: 15s; RT: 5515
sl␀lܞ|␀�l�|␂␌␄␄�␌l�␄b|��␂�␓�{�#�␌#��og�lno���␌c␜p��lsd{lp�g�␘␃␄␄�␌l␄��␌␌␌c␄n�|␃l�␄␄�c��gn�␀$��l ␃�␒␓nn␄l`␂␇␃n{���g␌␄c␄�␏d␇s��o␌␌c␄�␇l�bsc␄␄��㌓`␃��g�␃
FW 6.2.0
2.2.2-dev(38a443e)
Worker run!
mounting FS... mounted!
reading config file
parsed config:
{"Name":"iSpindle1","Token":"obscured-token","Sleep":15,"Server":"www.myserver.fr","API":0,"Port":80,"Channel":0,"URI":"/my/url","DB":"ispindel","Username":"","Password":"","Job":"ispindel","Instance":"000","Vfact":191.8,"TS":0,"OWpin":12,"POLY":"0.000407211*tilt^3-0.079249042*tilt^2+5.148448886*tilt-110.591098834","SSID":"my_ssid","PSK":"my_pwd","Offset":[-2666,508,5158,50,-62,6]}
applying offsets: -2666:508:5158
confirming offsets: -2666:508:5158
Boot-Mode: Deep-Sleep Wake

woken from deepsleep, normal mode
Samples:42 min:83.93 max:84.05 time:749
x: -1714 y: 16500 z: -556
Tilt: 84.01
Tacc: 23.09
Volt: 4.21
Temp: 22.44
Gravity: 4.06
After waiting 3002ms, result 3
IP: 192.168.0.92

calling Ubidots
{"tilt":84.0054,"temperature":22.4375,"battery":4.212721,"gravity":4.055411,"interval":15,"RSSI":-63}
Sender: Ubidots posting
POST /api/v1.6/devices/iSpindle1?token=obscured-token HTTP/1.1
Host: things.ubidots.com
User-Agent: ESP8266
Connection: close
Content-Type: application/json
Content-Length: 101

HTTP/1.1 200 OK
Server: nginx
Date: Tue, 03 Dec 2019 19:07:51 GMT
Content-Type: application/json
Transfer-Encoding: chunked
Connection: close
Allow: GET, POST, HEAD, OPTIONS
Vary: Origin, Cookie

d1
{"tilt": [{"status_code": 201}], "temperature": [{"status_code": 201}], "battery": [{"status_code": 201}], "gravity": [{"status_code": 201}], "interval": [{"status_code": 201}], "rssi": [{"status_code": 201}]}
0


Final-sleep: 15s; RT: 6619
sd␀l��|␀�d�<␃␄␄␌�␌d�␄c<��␃�␛�;�c�␄c��g'�doo���␄b␜p��l{lslp�o�␘␂␌␄�␄l␌��␄␄␌c␌g�|␃$�␌␌�b��gg�␀d��l`␃�␛␒gg␄d`␃␇␂gs���o␌␌c␄�␇l␇r��o␄␌b␌�␇l�crc␌␄��㌒`␃��g�␃
FW 6.2.0
2.2.2-dev(38a443e)
Worker run!
mounting FS... mounted!
reading config file
parsed config:
{"Name":"iSpindle1","Token":"obscured-token","Sleep":15,"Server":"www.myserver.fr","API":0,"Port":80,"Channel":0,"URI":"/my/url","DB":"ispindel","Username":"","Password":"","Job":"ispindel","Instance":"000","Vfact":191.8,"TS":0,"OWpin":12,"POLY":"0.000407211*tilt^3-0.079249042*tilt^2+5.148448886*tilt-110.591098834","SSID":"my_ssid","PSK":"my_pwd","Offset":[-2666,508,5158,50,-62,6]}
applying offsets: -2666:508:5158
confirming offsets: -2666:508:5158
Boot-Mode: Deep-Sleep Wake

woken from deepsleep, normal mode
Samples:42 min:83.97 max:84.11 time:747
x: -1682 y: 16496 z: -550
Tilt: 84.06
Tacc: 22.97
Volt: 4.21
Temp: 22.37
Gravity: 4.08
After waiting 5103ms, result 6
Rescue Wifi credentials
failed to connect

Here the full log from saving the configuration to the issue...
https://gist.github.com/jmcazaux/86caa05425e83f5318bfb10482933603

I am happy to try a few changes in the code in it helps.

Best,
JM

@jmcazaux
Copy link
Contributor Author

jmcazaux commented Dec 3, 2019

It is to note that after there was one error, the only way to have the connection established again is to enter config mode and save settings. A simple "restart" or "reset" does not help.

There must be something happening after saving the Wifi config that maybe should happen as well when trying to rescue the connection...
Just thinking out loud (way out of my comfort zone ;) )

@jmcazaux
Copy link
Contributor Author

jmcazaux commented Dec 3, 2019

@universam1 , I played a bit with the code (sorry, could not resist)...

I have modified the code of connectBackupCredentials as follows...

There was just a 100ms delay, now I am waiting for the connection to come back up (at least giving it way more time).

As far as I can say, iy seems to work. From looking at the console, the connection was restored every time it was dropped.

I am going to let it run for 24 hours as is (logging every minute to Ubidots).
I'll submit a PR tomorrow evening if it is still working (assuming you are open to PRs obviously, no harm intended).

Best,
JM

bool connectBackupCredentials()
{
  WiFi.disconnect();
  WiFi.begin(my_ssid.c_str(), my_psk.c_str());
  CONSOLELN(F("Rescued Wifi credentials"));

  CONSOLE(F("   -> waited for "));
  unsigned long startedAt = millis();
  // int connRes = WiFi.waitForConnectResult();
  uint8_t wait = 0;
  while (WiFi.status() == WL_DISCONNECTED)
  {
    delay(200);
    wait++;
    if (wait > 50)
      break;
  }
  auto waited = (millis() - startedAt);
  CONSOLE(waited);
  CONSOLE(F("ms, result "));
  CONSOLELN(WiFi.status());

  if (WiFi.status() == WL_DISCONNECTED)
    return false;
  else
    return true;
}

jmcazaux pushed a commit to jmcazaux/iSpindel that referenced this issue Dec 4, 2019
…sam1#318):

- allows 50x200ms instead of 50x100ms to connect to Wifi on wake up
- when restoring the connection, wait up to 50x200ms that it is actually restored.
@jmcazaux
Copy link
Contributor Author

jmcazaux commented Dec 4, 2019

My code has now run for 24 hours and still logs to Ubidots including from within my fermenting fridge (that was consistently failing before)

@ErikdBr
Copy link
Contributor

ErikdBr commented Dec 15, 2019

I use a TP-Link WA850RE wifi extender.
I have no issues at all.

universam1 pushed a commit that referenced this issue Jan 31, 2020
…#320)

- allows 50x200ms instead of 50x100ms to connect to Wifi on wake up
- when restoring the connection, wait up to 50x200ms that it is actually restored.
@mmanneva
Copy link

mmanneva commented May 3, 2020

I use a TP-LINK wifi extender (don't recall the exact model number), and have been experiencing similar issues as @jmcazaux. I installed a firmware with his fix and at least 8 hours later it seems to be working. Will post again if it didn't resolve the issue.

@stale
Copy link

stale bot commented Jul 2, 2020

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the wontfix label Jul 2, 2020
@stale stale bot closed this as completed Jul 9, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants