Hi guys,
I am working on particle photon to establish a local TCP socket connection with my laptop. So I can send back and forth some data between the two devices.
Referring through softAP documentations, I decided to put my photon in listening mode, connect my laptop to that AP and use a TCP server-client socket connection. Simple!
But, my client(laptop) is acknowledging it got connected to 192.168.0.1:80 server successfully, although I am unable to send data from photon(server) to laptop!
SoftAP HTTP/HTML example is working fine. (Assuming it is only utilizing the facility to give wifi credentials, which the listening mode is restricted to.?)
Is this TCP issue due to any specific restriction on photon?
@iotbang, in answer to your question, DeviceOS has enough TCP capabilities to work as you wish.
To assist, with the issue
I am unable to send data from photon(server) to laptop!
you will will need to the architecture of the application running on the laptop (TCP Client).
For the TCP server to communicate back to the TCP Client, the socket will need to be open ie the TCP client establishes a connection to the TCP server and keeps the socket open so that the TCP server can send back data.
If I do the reverse, ie., connecting photon as a client to the server running in Laptop everything is okay. The vice versa also.
I was trying a different approach. No common router! Just Photon and PC, like wifi direct.
For that, I tried to connect the laptop to listening Photon(Photon as hotspot). In this local network, I was able to give wifi credentials through port 80 of photon(using softAP http).
Simultaneously I tried running a TCP server in my particle firmware, at a different port. The result was failure. Nothing was going on.
If I make it port 80 and run a server in the photon
(server IP will be given gateway IP eg., xxx.xxx.x.1, the photon IP visible in ip scanners): TCPServer server = TCPServer(80);
My client running in laptop was atleast acknowledging a connection with server. But nothing else, no further transfer happening.
So I assume eventhough the system thread is enabled SYSTEM_THREAD(ENABLE);
there are some restriction in wifi listening mode.
In the early days I did also try something similar but didnāt succeed and got some Particle statements that it should work but others that it wonāt so I just gave up on that
@ScruffR Ok. I think softAP HTTP is not going to work out for my case.
My use case is to get all the sensor data by wireless to my terminal, this will be a backup if my internet is down(just in case).
Right now I have to connect my photon via USB, then get all the data by accessing serial port.
My current workaround is getting IP through mac id, get the local IP, then establish a TCP connection. It is working out. But the current approach we are discussing will avoid a third part router/hotspot. I can do transfer like WiFi direct.
Finding any resolution through the softAP method.?
... what do you mean by your internet going down.
If your ISP is not reachable your local WiFi would still be available, wouldn't it?
And even if not, you could still use your mobile hotspot (smart phone) as a secondary WAP for your Photon.
Yes, I can provide internet through a secondary method. But to access it through local network or wifi-direct mode is the more prior use case. A more convenient standalone device.
@iotbang, am with @ScruffR on this, we can say that what you are trying to achieve is going to be difficult (and doesnāt make senseā¦),
The usual case is most sites have a WiFi router, which is used as the gateway for your intranet comms, ie with or without access to the internet/Particle.
So, the āworkaroundā is to use the Particle devices as designed - ie supply a WiFi Access Point.
This is the easiest solution as it would work with your normal code running as is and no need for SoftAP at all.
Local WiFi connection (WiFi.ready()) does by no means require internet access (or cloud for that matter - Particle.connected()).
Your code just needs to be resilient against loss of internet connection (e.g. via SYSTEM_THREAD(ENABLED) or SYSTEM_MODE(MANUAL) - I'd go with the former)
Referring to one of our thread regarding Hostname, I came down to the solution using a common Access Point(ie., router).
There my constraint was the difficulty to find router allocated IP for the particle, from the client(pc) side. Ultimately a solution came out out after some try. Thanks, @ScruffR and @UMD for helping to narrow my scope to one of the solutions.
I thought to give a try again for wifi listening mode and make Photon as an AP. From our discussions here, it seems impossible prima facie, or maybe not at all possible.
Still, a question exists with me, whether these restrictions(or something else) were intended by particle or it came automatically inside the premises of protocol in which particle designed the Photon.? Something like that.?
If you are refering to the perceived inaccessibility of TCP/UDP communication while in SoftAP mode, that's not an intended restriction.
SoftAP wasn't really a from-the-start feature and was added later but then without the ability to run user code at all.
Only after some call for that feature and the introduction of SYSTEM_THREAD() it became possible to have both run along side, but no special care was taken to ensure TCP/UDP functionality alongside SoftAP mode as the latter is (IIRC) just instrumentalised from the Broadcom/Cypress WICED fundament which obviously was not created for that "edge case".
Iāll throw in my two bitsā¦
I have a couple protons sending to publish/subscribe. I also send data via Bluetooth via hc-05/06 pair to a local Arduino lcd display module. This way I have a āglance-atā info display.
Also, isnāt this what the argon - nesting system is aimed at?
