esp8266 immediately disconnect from server after establish connection - arduino

I am having a bit of trouble here.
I get my esp-01 to connect to wifi and webservers, but with one website in particular it disconnects right after establish the connection (after type AT+CIPSTART), so i am not having enough time to write another command or post a request.
AT+CIPSTART="TCP","www.franz95.000webhostapp.com",80
CONNECT
OK
CLOSED
I have also try modifying .htaccess setting keep alive connection..
Is there a way to make the connection duration longer before closing it??
Im using a esp-01
AT version:0.21.0.0
SDK version:0.9.5
SPI Flash Size : 4Mbit

Related

BLE: What could cause BLE connection establishment to fail

I am trying to implement a Bluetooth Low Energy Host on a system with SAM E54 with FreeRTOS. The bluetooth stack I am using is Nimble (Mynewt-NimBLE from Apache). I am trying to connect the SAM E54 to a nRF52840 Dongle (driven with nRF Connect Desktop application).
When I set my device as Central (as a 4.x device, with no 5.x capabilities), the device can connect to another device without error.
But when I switch on the 5.x capabilities, (basically by changing a define's value and calling another API function), and try to connect to the same peripheral, it fails 9 out of 10 times, triggering a "connection supervisor timeout" on both the server and the client.
I tried changing the supervisor timeout value, but it won't fix the problems. When a connection is bound to be successful, the central's information is displayed immediately on nRF Connect. When connection establishment is going to fail, I know it right away (before the connection supervisor timeout is triggered) because no information about the central is displayed on nRF Connect.
Once the connection is established, it can stay on for hours, so I don't think this is an RF noise issue.
I know NimBLE is not initially designed for SAM E54 and FreeRTOS, and surely the problem comes from a wrong implementation or configuration of the stack. But right now I feel like I've tested everything, and I don't know where to dig for solutions.
The actual questions are :
To start a connection using 4.x BLE capabilities, some HCI commands packets are sent. Should these packets be any different than the packets sent when I enable the 5.x capabilities ? In both cases, I am connecting to a 4.x device.
What step of the connection establishment process fails when both server & client "think' they are connected, yet don't exchange information?

Problems connecting to nodemcu via johnny-five

I'm really having trouble connecting to my ESP8266. I was working with this setup for long time now and I didn't have to flash my boards. Now after having to use a different wifi i needed to flash the board. After doing the following
Updating to the newest ConfigurableFirmata
Using FirmataBuilder to download fitting firmata
Uploading the Firmata to the ESP8266
I can't connect via Johnny-Five anymore (getting the usual timeout error). I couldn't narrow down what it exaclty is (and I have been trying all day) but these are things that I have noticed (Using ConfigurableFirmata directly as well as using firmatabuilder and StandardWifiFirmata, all with the same behaviour)
an open Hotspot gets created even though I'm in Client Mode
when scanning for ports I do find the Module connected to my Wifi (Serial Monitor in Debug tells me the same too) but no open port is found, even though it's specified in the firmata.
I just can't narrow down the reason. I hope you guys can.
OK,
this was a simple user mistake. But since I lost a whole day searching for the error and I think others might too, I'll share my mistake here.
As I pointed out I created the Firmata as Client (thinking its a client to my Hotspot). But you will have to create it as a server (as you want to connect to the board)
It's as simple as that. If you are on http://firmatabuilder.com/ make sure you choose TCP Server if you want to connect to your board.

ESP8266 takes long time to connect

I am using an ESP8266 for a project which requires the ESP to establish a connection to the Access Point , with as less delay as possible, but as of now it takes a minimum of 4-5 mins for establishing the connection which is too much delay. I have tried to set a static ip, gateway, subnet and DNS by passing them as parameter to WiFi.config() function, still no success. Would someone help me regarding this issue ?
I have seen lengthy delays on ESP8266 WiFi connection if the WiFi is persisting its configuration to the flash memory. Anywhere from a few seconds to a minute or so.
Try to call WiFi.persistent( false ) before you call WiFi.mode() and WiFi.begin().
At the very least, that will help you narrow down the cause of the problem.
Ensure access point frequency is 2.4Ghz (not 5Ghz). This will cause prolonged connection time (never connecting).
"The ESP8266 is not designed for 5 GHz." Source
NodeMCU V1.0 (as pictured) uses an ESP8266's (ESP-12E) chip, Antenna is configured for 2.4 Ghz only.
I think the library <ESP8266WiFi.h> you are using have problems, you can use older versions of it.

specifying connection on ESP8266 with AP and STA modes

I want to try to set up an ESP8266 (using the Arduino IDE) to occasionally connect to a wifi SSID to send telemetry back. I also would really like to be able to have it running a softAP for configuration/settings purposes. (i.e. so if you want to change internal settings in your code, you can connect directly to the device to access a web form to do so)
The problem is, I am not 100% sure how I know which is which when making an outgoing telemetry json query. I want it to go out on the STATION mode connection. Presumably in most cases the AP mode won't be connected, but there may be rare instances where both are connected at the same time. Thus how do I tell the device to specifically use the STA side of things when it needs to send data back over the internet?
I can't even seem to find any specific examples to ask if one or the other is connected. (you can poll WiFi.status() but - which one is it reporting?)
Any help is appreciated

GPS Tracker and GPRS connection over changing GSM (BTS) envioment

I have question what is the best way to implement in GPS Tracker software communication with server. The connection is established with GPRS but I have some question to it.
GPS Tracker has a tendency to switch between Network BTS'es during vehicle movement. How GPRS is designed.
Does during the BTS switch the GPRS session have to be established again?
If no what is better. Creating one long running TCP/IP connection to the server (IP:PORT) and send data over this connection all the time (ONE GPRS SESSION) or maybe Creating TCP/IP connection each time when tracker has something to send and then close the connection (ALL ON ONE GPRS SESSION)? Does switching between BTS destroy my GPRS SESSION and connection that i created during this session?
It would be great is somebody give me some info about this topic and how to approach the best possible design taking into acount behaviour of changing BTS'es, Network Operator, Countries (roaming turned ON). Thanks.
By saying CONNECTION to the server I mean connection that is established during ONE GPRS SESSION. During one GPRS session You can create many connections so my question is about connections over ONE GPRS session and if GPRS SESSION has to be recreated in some scenario, connections over many GPRS SESSIONS (which will be more expensive).
Switching between BTS'es does not destroy connection (well, I don't know too much on this thing, except I've worked with it and I'm sure that sometimes connection is preserved).
My preferred solution would be as follows:
Create a connection if there is something to send, but allow it to be idle for some minutes before closing.
Provide an application-level keepalive protocol to detect hanging connections.
Disconnecting while you've got nothing to send can have interesting implications if (1) it involves shutdown of GPRS session and (2) the provider charges some minimum fee for GPRS sessions, so you can pay for 40kb on open+send 200 bytes+close sequence. The solution above should be a good compromise.

Resources