I have a device with no screen + a microcontroller + a wifi module.
So far so good but basically I'd like to setup my device so it can connect to a wifi network, so I made an app to do that.
The strategy is:
put the device in wifi AP mode with a custom ssid like "Device XXXX"
connect to this ssid "Device XXXX"
Ask the user for its home wifi credentials
send the credentials to the device (for example using http) -> POST http://x.x.x.x/wifi_creds "Home" "homepassword"
poll the device to check whether it could connect to the "Home" network -> GET http://x.x.x.x/conn_status
Once it's connected, stop the AP mode -> POST http://x.x.x.x/wifi_ap_mode 0
This works pretty well, but it requires the user to manually connect to the "Device XXXX" ssid.
And actually on Android I can make things even easier by connecting automatically to this ssid, but I need to find the ssid first.
So my idea was to scan all the ssids and to connect to the first one that matches the pattern /^Device [0-9a-zA-Z]{4}/ (like Device 1234).
However this doesn't look like a good way to find a hotspot, and there might be a better way.
Also, I don't want to give it a default name as it could conflict with another ssid.
Is there another way to find my device (or my device ssid) without this trick?
I know that Google home is able to connect to a Chromecast allowing you to configure it while the Chromecast is in AP mode with a ssid that looks like "Chromecast XXXX" (when the bluetooth is disabled), and I'm not sure how they do it
*I've assumed (perhaps wrongly) that your headless device is Android based. If it is Android and has Bluetooth, specifically Bluetooth Low Energy and is above Android 5.0:
You could get the device to act as a Bluetooth beacon which constantly broadcasts it's SSID.
So your app first scans for Bluetooth beacons - the beacon payload could be any arbitrary data - perhaps some known hard coded GUID to be sure you're talking to the correct Bluetooth beacon and also embed the SSID.
Now go and scan for the SSID and connect to it.
See this library for details on how to do this.
I believe you can even configure a kind of 'geofence' so that as soon as you come into range of the beacon your app wakes up and does the pairing.
Related
I have an Android watch that can be in one of the following:
1a. standalone - connected to a WiFi network directly;
1b. standalone - connected via a cellular link (if SIM present, unlocked, etc.);
2. bluetooth connected to a phone and using the phone's connection (WiFi/cellular);
It can also be that both the watch and the phone have a SIM (though this is less important).
On the watch I run a standalone app (no counterpart app/service on the phone) and I need to find the 'end' connection type I have when tethering. Namely, using the watch only, I need to know if I am tethering via a WiFi or via a cellular connection.
Or, in other words, when tethering, I need to know if the phone (to which the watch is connected via bluetooth) sends my data further using WiFi or a cellular connection.
I did look around for a solution but what I found only allows identifying the type of connection the watch has, e.g. WiFi, cellular or bluetooth.
Is this even possible? Thanks in advance for your help!
I want to work with Wifi connection via Android Devices (for example I want to send a command with my device to home router via Internet and my router send this command to a wifi module) when I refer to Developer Android APIs, I see a section that named "Wi-Fi Peer-to-Peer". what differences exist between wifi (working android devices with access point like home router) and "Wi-Fi Peer-to-Peer". Is "Wi-Fi Peer-to-Peer" same wifi Direct ? why Google didnt discusses about simple wifi ? please help.
WiFi P2P (Peer-to-Peer) and WiFi Direct are both the same thing.
There are two main differences between "normal" WiFi and WiFi P2P (from the developer's point of view):
A WiFi p2p connection (something you establish from code) is a direct connection between two devices. You can understand it as a sort of temporary (created for the time of the connection) "normal" WiFi network created for the purpose of communicating those two devices. A "normal" WiFi connection basically translates to a situation when a device is connected to a broadcasted (by some device - e.g. home access point, or a smartphone) WiFi network. This all basically means that to send data between two devices using WiFi P2P, those devices DO NOT have to be connected to the same WiFi network (as long as those devices know how to connect to each other using wifi p2p). Unfortunatelly good news with WiFi P2P end right here, because:
Designing a WiFi P2P connection based system is extremely difficult if you want to make it at least reasonably robust. This is mostly due to the lack of documentation on that subject (in Android Dev), and due to Android's WiFi p2p unpredictability (I know what I'm talking about - I was recently desigining such system).
You're wrong saying that Google didn't discuss "simple" WiFi. You just need to remember that connecting to "simple" WiFi is just not that complicated, so they didnt have to do a guide like they did for WiFi P2P. All information considering "normal" WiFi are there (at Android Developer), its just spread over many classes.
Tell me what you think is not discussed?
Also you should try to describe the exact thing your application needs to do (with WiFi), so I can maybe give you a hint whether you should try your luck with WiFi P2P or not.
I am a little confused on how to build this android app. Here's how it should work. I have a list of paired bluetooth devices. Lets say paired devices are:
1. A bluetooth head set.
2. A mobile phone.
And my app should automatically connect only to my headset when ever it comes in range.
Thats the basic functionality. I have been doing some research on bluetooth technology and its implementation. I came across the bluetooth chat application, when I started using the application I realized that both phones should have the app on it in order to connect and exchange messages. I tried connecting to my headset but it doesnt connect. And also when I removed the bluetooth chat app from one of my device and tried to connect it from a device which had bluetooth chat app, the devices couldnt connect.
If you have already worked on bluetooth this might look very simple. But how can I connect to a bluetooth device from my app when ever its in range even if the other device doesnt have my app.
Thanks.
This will be a 2 sections answer:
-To connect to a Bluetooth Headset, check my answer on here
-To Always connect to that device, you can save device address to memory then create a service with BroadCastReciever that listens for Bluetooth Connectivity. and check which device gets connected and compare it address to the one save in memory once its finds it connected call ibth.connect(device). ibth is inside the above link.
Since I don't have an Android 4.0 device I haven't been able to test this myself. Also I wonder if connecting device A (a smartphone) to device B (a wifi direct capable device) using Wifi direct would mean that device A would assume it is provided with internet from device B (tethering?). I am trying to make an application for device A that would communicate with a device B that does NOT provide internet, thus it would be interesting to know if such a scenario would lead to device A losing internet connectivity for the duration of the connection. Is the situation different depending on if device A is connected to internet through an AP or through 3G/4G?
Perhaps using Bluetooth would be a solution, but in my case security is an issue, and it seems to me that Wifi direct provides stronger security (WPA2).
Any info would be helpful!
/S
On Android, Wi-Fi Direct doesn't interfere with your connection to the Internet (Wi-Fi or 3G/4G). A problem may be that once your turn on the Wi-Fi (to enable Wi-Fi Direct, your phone will try to connect to one of the saved available networks and will disable your 3G connection. That is because Android (by default) doesn't support dual connection (via both Wi-Fi and 3G/4G), but there is some applications around that claim that they can provide such functionality.
Can someone explain a couple of very simple concepts to me - I'm interested in mobile devices running android and how they are identified over networks. Some scenarios:
Device is connected over WiFi - presumably the device has a standard IP address as with any host and can communicate with any other android host over TCP/IP (assuming it knows the participating device's IP?
Device is connected over bluetooth - how are devices identified in this case?
Device is connected over mobile operator's network - this is the one I'm interested in and confused by - is there anyway for two or more devices to discover each other and communicate via the mobile operator's network? How does a device communicate with a backend server in this scenario? In other words, how do apps and devices communicate when not connected to a WiFi network?
Thanks for any advice..
I'm only sure about the bluetooth thing, so i only answer this part:
The Bluetooth interface on your device has an MAC adresse. So while communicationg over Bluetooth you can assume that this MAC adresse is a unique identifier for a specific device. You can also reach other devices by establishing a connection over this MAC adress- However, to get this mac adress in the first place, you have to know it from somwhere, or you have to search for other bluetooth devices in the reachabla area before.
WiFi and 3g both attach the [mobile] device to the internet so it can make internet connections. 3G assigns a publicly addressable IP to the device, so one could, presumably open a server socket and listen for connections. The client would have to know the mobile IP, which may change quite frequently.
Bluetooth is more geared toward close-proximity. Devices in the vicinity can be connected to, after you have paired with them, which requires the cooperation of both devices which are to communicate.
If the goal is to produce an application which connects to nearby devices, I can think of the following ideas:
3g: all devices running the client register their position with a central database server. If the server detects that two clients are in close proximity, let them know so they can connect through the internet or through the server
WiFi: you could use the same idea as 3g, or use broadcast/multicast packets to broadcast your presence. Other apps can listen for those broadcasts and discover which other devices are near.
Bluetooth: A little trickier, as a device must be placed into discoverable mode in order for others to "see it". Discoverable mode is a temporary state and only lasts about 30 seconds (at a time).