I am doing a home automation project on which I control lights and relays connected to a raspberry pi from my phone(Android) using Python over a LAN connection. I have had success in my first version using a flask Webserver(Pi) and requests and kivy on my phone.
However, for my second version I wanted a more two way communication protocol, as at the moment the only way to get data from the pi to the phone is through the response to the request. One of the goal in the second version is to allow more automation and other devices to switch, therefore I want my phone to be notified on state changes. One way of doing it is simply to regularly checking for changes, but I was wondering if I could instead program the pi to notify me on state changes. This would be more akin to a host-host network than Host-Client.
The only way I can think of doing it at the moment is to have a Webserver on my phone and the pi.
Thank you for your help.
Another possibility would be using MQTT instead. It's a lightweight publish-subscribe protocol, designed with small devices in mind.
It also runs on the TCP/IP layer, but when used on devices with power constraints or with bandwidth limitations, it tends to be a better option than a traditional webservice.
You could add as many subscribers as you need to have the two way communication feature.
Here's a basic example of it: https://medium.com/#gaikwadchetan93/android-real-time-communication-using-mqtt-9ea42551475d
Related
I need some help in terms of choosing a design option for my problem.
I currently managed to implement a RaspberryPi acting as a Server and my local machine to act as the client. This client send JSON-Data to the Server which processes these. Everything is working as expected and I am using TCP-Sockets for the communication.
My problem:
The next step of my project will be, that I will use instead of a PC an Android-Device as client. What I want to achieve is, to send data to the server on the go. What I mean by that is, I do not want to restrict the server to be in a special network neither the client. What can be expected, is that server and client are next to each other, like in the range of a bluetooth connection. My question is, is there a relatively simple way to implement this communication? Is TCP a possible solution for this (even working in mobile networks?) or do I need to use Bluetooth, or is the way to go, to create some kind of network the client/server connects to and communicate here?
Sorry for propably stupid questions, but I am new to all this network stuff.
EDIT:
Since there were no respones, maybe I can do a more precise question. Is there a proper way to scan a network for a device name?
The only way I currently can imagine is to do a bruteforce like check on every IP-Address and resolve the names?
I first tried to let the Pi host an ad-hoc network, but it seems that non-rooted android smartphones do not have the possibility to access ad-hoc networks.
Therefore I made the Pi acting as an access point.
The communication now is very simple realized by a tcp server-client system.
I am trying to do some wacky home automation which will require me to send a signal from my Android phone to my Pi 3 in order to execute a script to control a motor using the GPIO pins.
The only part I'm stumped on is the best way to connect the Android and Pi.
I've read so many different things and it's all overwhelming, the amount of differing answers I've seen.
So far I'm leaning towards using Jsch in my app to ssh into the Pi and execute the command, but I have been told this is silly.
Can anybody explain to me why this is a bad idea and explain to me a better one? Ideally the phone app would be able to connect over both local network and other networks.
Nothing is wrong with SSH, but people typically use web servers on the Pi plus HTTP requests on the Android side. Or you can run your own protocol via a raw socket connection.
SSH commands might be more secure if you use SSH keys.
Otherwise, you'd be exposing your commands to anyone snooping on your internet traffic, and random people will be controlling your devices
Either way, if you want access both internal and external to home, you can do more research to see if you can "port forward" your router
The advantage of using HTTP for this sort of thing is that it potentially creates its own user interface. What I mean by this is that, if the interface on the Pi is a Web server, then you have a way to provide an HTML/JavaScript interface to your Android device, and thus avoid the need to create an Android app at all -- the user just needs a browser. The whole user interface is managed from the Pi.
I've used this approach for motor control on the Pi a fair bit. On the Pi I use a C program that embeds the libmicrohttpd webserver engine. The program can serve out ordinary HTML pages to create the user interface on the browser, or respond to particular HTTP GET requests that result from the user clicking buttons or manipulating sliders or whatever. You can do some really sophisticated stuff by sending JavaScript functions that make their HTTP requests outside the normal HTTP request/response flow, so you can (for example) have a browser display that updates dynamically (e.g., display sensor values from the Pi).
Moreover, it's easy-ish to provide some kind of security using SSL and HTTP authentication. I prefer C, but there are webserver libraries for Python that work on the Pi as well.
To my way of thinking, the only time it's worth considering something more complex than this is when you need a user interface on Android that can't be implemented in HTML/JavaScript.
I'm sure there are many different ways to do what you want. I prefer to do most of the work on the Pi, because I find writing Android apps deeply unrewarding. On the other hand, if you like developing for Android and have plenty of experience doing so, the approach you suggested -- sending commands to the Pi over SSH -- could work perfectly well. It would just mean doing most of the work in Android.
Yes, ssh is silly solution. I suggest to develop rest api webservice, host it on your PI and invoke it from your Android app
I'm building a multi-OS mirroring system which I would like to implement using a hybrid client-server and p2p communication method (at least that's the best way I have of describing it).
My issue is that at some point I have a central server (appengine, so there are limitations to what I could do because of time and networking capability constraints) that would need to get a message to a host of different devices which are not necessarily running the same OS (Windows, Android, iOS, Linux, etc...).
Android and iOS (or any other mobile platform) are the main problems it looks like I will be having on 2 levels.
1 - They are both limited by battery power (more so than a laptop and desktops shouldn't have that issue at all), so whichever method I use needs to take that into account.
2 - NAT (harder because the user has relatively less control over their firewall than on a network that they are running). My central server will maintain a table of which device has what IP address, but from what I understand if there is NAT or a firewall it won't be able to get to it if the port was not forwarded.
Since I will be writing a specific client for each OS I prefer a solution that is more universal. I have been leaning towards writing an extremely simple HTTP server that sits on each client and takes requests (which appengine is able to send) and treats them as messages that alert the client to perform an action (either with the server or another client). However, I run into the issue of NAT/firewall. For instance if appengine needs to send a message to AndroidDevice1 it would grab its IP address from a table and make a request to it. However this doesn't work if the ports aren't forwarded correctly, and if the user is on 3g/4g the firewall is controlled by the data provider.
Because of this, I started thinking about using Android C2DM but I want a solution I could implement across platforms.
The only other method I could think of is to just have the client poll the server for messages. This has the battery and network consumption issue though.
Would there be any other way to implement this, and if not, which one of the above methods are best in terms of balancing usability, power and data consumption and user input (the less the user has to do to get the client set up (ie port forwarding, etc...) the better)? Please note that I do not intend for this to become a discussion/flame war but a logical presentation of facts.
Thanks in advance!
You can create a persistent TCP connection from the device to the server and then communicate over this open connection. This would be a very simple connection with keepalive packets for the most part.
In theory this would consume some battery through the radio, but in practice I have experienced that the battery is not affected much at all. Key is to keep the communication over this line to a minimum.
If AppEngine does not allow this approach, you can run your own socket server and then communicate between this server and the appengine server using REST. A socket server I have used is Apache MINA and had no issues with scalability.
Another problem you will have with this approach or any other approach is that on iOS (afaik) you cannot keep a tcp socket open when the App goes into background. The only thing to communicate with the iOS device is Apple Push Notification Service
I would prefer rather than having HTTP Connection you should create TCP/IP tunnel and make communication fast and reliable. I have one Chat application which runs perfact for me using TCP/IP. If you use this you will have same logic for multiple platforms. Only thing you need to write is different code for iOS and android.
Hi all I was wondering what options do we have to exchange data between two different android devices?
For example, User-A and User-B both installs my app. I would like User-A to send data (possibly just a simple message or user-A's location info) to User-B.
The functionality I would need is similar to the functionality that WhatsApp has. However unlike WhatsApp, I do not have a server and I was wondering if we could do data exchange between two different android devices without a server?
I was thinking we build it atop SMS or something.
Options for exchanging information between devices are the following:
Bluetooth - this would be between two devices in the near vicinity
TCP/UDP IP connection - this would be using TCP to open a socket directly to another server socket. That could be hosted on the phone or a shared server. There are pros and cons to both.
The pros of bluetooth would be no need for a central server. The big downside is this means you can only exchange data between two people standing within 20 meter range. The other downside is you have to pair the devices which not everyone finds easiest.
You can use TCP/IP connections to exchange data just like any client-server program you write on a traditional computer. This could be used no matter if your phone is using 3G/4G/WIFI/EDGE or future radio protocols. The problem is the IP address of the phone might not be globally reachable. The IP address of the phone might be a non-routable like a private IP. They might be behind a firewall or NAT address.
This is where a central server is probably needed to either exchange IP addresses for users, or serve as a common location for clients behind infrastructure that could block. This is where protocols like SWIFT come in handy for jumping firewalls. Even with things like P2P you still run into these types of issues with non-accessible devices, and tricks like this have to be used to crawl around them. Unfortunately, that means you probably need a central server even with the P2P model.
Without an external server to keep a list of all connected clients, you would need to implement communication in a P2P fashion. Depending on the needs of your app, you could have the user type in the IP address/email/phone number of the other user they want to exchange data with.
If you wish to use a server approach, you can sign up for Google's App Engine which has good Eclipse integration as well as a plugin to easily interface with an Android app. This would give you an infrastructure option without initially (or maybe never depending on how high you scale) having to put down any money.
Google gave a good IO talk showing an example of a web app that can easily communicate with an Android app. You could extend this to do what you are looking to do.
I'm currently working on an android project and I am trying to find the best way to go about setting up communication between two android phones.
One android phone will be docked on a mobile platform e.g. an R/C car. I want this phone to receive simple control signals ("forward", "backward", "left", "right", "gotoCoordinate") sent from another android phone. I also want the docked phone to be able to return status signals.
Preferably I want the communication to happen via GPRS. I'm aware of the difficulties concerning P2P-communications and I'm currently looking into "Android Cloud To Device Messaging." (http://code.google.com/android/c2dm/index.html)
I'd like to hear about your experience with Android C2DM (glad to hear about delay from transmit to receive) and your thoughts on utilizing it in my project. I'd appreciate other suggestions on how to go about this. I'm expecting to have to deal with relatively high latency using this method, but of course preferably lowest possible.
C2DM makes no guarantee about the "delivery or order" of the messages, and it is limited in the number of messages you can send (a high limit, but still a limit). It's not really for low-latency stuff like controlling an RC car. It's better for non-realtime events.
http://code.google.com/android/c2dm/
For lower latency stuff using GPRS you can setup a third party server on your own and have both phones communicate through it. I've done that for several Android apps using straight up TCP sockets and it works reasonably well (and it would be even faster/better if you went UDP). Using GPRS may still have too much latency, depending on your needs, but it's a tradeoff (it's very convenient, almost always there, other methods are not).
The ideal way to do this would be to combine whatever is available and fallback gracefully, and test the latency once connected to make sure the network is up to par, or bail out. For example, use the local WiFi network if it's available. That is to say, have both devices "register" with a third party server as they startup, then if they're both on the same WiFi just have them communicate directly (run a server on or both, and clients on one or both, get information about discovery and such from the registration). If they are not on WiFi then fall back to GPRS, but realize there will be more latency, of course. Finally, once any method has been established send some test messages to check latency.
I know this isn't really an "answer," it's more of a stream of consciousness about this, but it wouldn't fit in a comment, and I thought it might help ;).
(Full disclosure: I've worked on Android apps that connect multiple mobile devices and multiple TVs, some over GPRS, some Wifi, some directly. I work for a company (MOVL) that makes a platform for stuff like that, it's more focused on mobile-TV-mobile, but it supports mobile-mobile also. In all it's not too hard to do yourself with regular networking, the tricky part is getting the latency down and picking the correct method for each device.)