: (
i do not understand why it is sooo complicated to do this.
probably lots of people would be happy to have server on the same phone as the app.
currently even a project with bluetooth widget needs access to internet or local wifi… this kind a contradicts the advantage of bluetooth.
ok, it seems that i will get a semi-broken windows phone in the weekend. then i will do some further research regarding this topic.
Not just complicated, but impractical. The App is not designed or required to be in constant communication with the server, but the hardware (MCU) should be.
Running the server on your phone just introduces battery drain and service charges while trying to keep this theoretical on-phone-server in constant communication with any hardware.
Viewed as a sudo equation: APP ↔ (SERVER ↔ HARDWARE)
The server-hardware link takes priority over the server-app as the App is the intermittent control and feedback of the primary server-hardware link (hardware doing the work with the server storing the data for later app linkup).
The bluetooth option is probably more of a “because it can” connection option… not meant as a potentially globetrotting link to your automated home.
yeah, if i think better, for general blynk use you’re reasoning is right!
actually, i have a special case, and this is why it seemed better to have app + server on the same device (phone).
long explanation:
i use the system on a bike. the blynk app is a kind of a dashboard, for obtaining real time info and to control an automatic shifting system. so, as long as the hw on the bike runs, it has the phone + app + server too.
and because i ride the bike also on “remote” locations around our city, where there is no relaible 3g/4g and wifi of course, i have to find a way to use without internet, to keep the system runing.
this is why i have to find the lightest / smallest / most compact setup as possible. and because a standard smartphone (from the hw pov, at least) should be capable to handle the server task, i tought if i could run the server on the same phone with the app it would be the best solution.
For that type of portability, then running both Server and Client on something like a battery powered RPi, set to also act as an access point for the phone connection, might work.
Points of concern would be:
Can an RPi be set as an access point while offering a suitable IP for the Phone to connect to? Something I have never looked into.
How does the client and server communicate to each other in this case (both on same RPi)… is there an internal method of client/server link that isn’t obvious (i.e. programming the client for 127.0.0.x or something??)… question for the Blynk guys perhaps.
Yes, no problem
Like mentioned in the docs. Via the regular IP numbers, or even USB-Serial scripts. Function-wise it doesn’t matter, because the two processes (hardware and server) are separate things.
I was actually working toward this dual use device (client server) but for use with normal router… And had thought about, just not asked about, this issue… I guess this is as good a time as ever 
So basicly in @wanek case where the RPI acts as hotspot passing out IPs (DHCP or static) to phone and client? But client is technically on the same device, thus same IP as server., but separate process… no conflict there? I never did get heavily into the networking IT stuff, mostly PC builds and servicing.
The Pi wouldn’t give itself an address of course. That has to be set static, but yes, it provides the phone with and IP.
I went the other way, started building PC’s and now heavy into networking, lol.
So say the RPi used 192.168.1.1 as host, and hands out 192.168.1.2 to the phone… does one program the client for the host address then? - how would the server distinguish the client from itself?? That just seems wrong to my poor head 
Guess I better get cracking on my RPi server install - It is currently running client (wiringPi based) and linked to my main Local Server on a netbook.
In your Raspi script you will connect to 192.168.1.1 a.k.a. the Server. The server software is a completely different thing from the client software.
Oh I got that… it is just that both (processes) are on the same hardware, the same MAC and same IP… But hey, if the server can figure it out, then I don’t need to 
Oh, my, goodness… I just thought about “how do I set the port on the client and server - what with it all being on the same self IP administrating device???” That’s it… I am calling it a night 
To keep it a bit clear:
Each process which uses networking can bind to any given IP address, but only on a UNIQUE port per IP.
E.g. Blynk server is running on IP interface 192.168.1.1 on port 8441, 8442 and 8443 (in reality more, but ok).
Now, if you want to setup a connection to the server from the same server, there will be a TCP connection from a random port (usually 40k+) to the listening port, 8442 (hardware non-ssl I think). Because each TCP connection has to be unique from a port perspective, it’s possible to open a new connection to 8442 if the originating port is different.
The process initiating the connection to the server has no listening ports, it justs initiaties a connection.
If you are still unclear I’m happy to make it into a little drawing, that may clarify things 
I see you have been reading some of my past crayon comments
Diagrams always help… feel free to do so if you wish, but not critical.
Meanwhile I think I get some of what you are refering too, intuitively if not intellectually. And I will install server onto my RPi, along with it’s existing client (currently linked to external server) so I can better visualize concept with action. But I also need to figure out how to turn it into an AP. The only WiFi USB adapters I have date back many, many, years ago.
Thanks for taking the time.
Be aware not all Wifi USB adapters work with Linux! Do check the used chipset against the Linux compatibility list 
Yah, that was my concern…
However, now that I think about it, since I have no need for a complete self contained setup, I will probably just leave it plugged into my router. The internal Blynk Server <-> Client link should still work the same way, with the RPi IP handed out from external source instead of yet another internal process.
great explanation, and i also would appreciate a diagram drawing!
thank you for your patience. i’m also not very educated in networking stuff, just the basic level.
looking forward to see too that diagram 
I’m afraid my personal life is taking precedence right now (divorce…), but you guys still gonna get that diagram from me, just not now