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
Related
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
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'm currently working on a small project of simply controlling the lights in my apartment. I have a Raspberry Pi setup to control the lights with a 433 Mhz transmitter. I can send on/off commands to the lights using a "send code " command through the command line on the PI. I'm looking to create an Android App to do this for me, and I'm looking for a way to make this happen.
The Raspberry Pi is always connected to the internet, so I was thinking about hosting an Apache Webserver on it, and then somehow sending it commands from the app. Would anyone know how to go about doing this? I have little knowledge about Apache or webservers to begin with, but my basic google searches have pulled up ideas about using http posts.
Would figuring out how to use an HTTP post be the best course of action, or is there an easier way?
There are many options but probably some Python web framework running on your Raspberry PI will do the job (Twisted, Django or many other).
Python is preinstalled in the PI so it could be the easier choice.
Your Android app will then run HTTP requests (using HttpClient or something more elaborated) to the Python web server that will run in response the bash code.
The real problem comes when you will want to secure your end point (via login or whatever secret sent via Https) to be sure you are the only one switching on/off your lights :)
Personally I'd use an SSH library such as jsch to create a simple android app that sends the desired commands to your raspberry pi, on the press of a button. Of course, if you need to learn how to make an android app, have a look here first.
what is the best framework that I should use to make a remote control app for Android. What I want to do is something like Tony Fadel's app for Android and Iphone where you control your house thermostat temperature remotely with a smartphone app.
I was going to use sockets programming, but not sure if that is the best way. If it is then i will use it, but wanted some feedback before i get started.
If I make one android device the server and the other device the client I will still have to manually set the IP address every time I want to connect the client to the server.
I am trying to avoid having to make a web-app and having to make a php website to act as a server for this. Having to keep a server running is too much overhead. would rather make something like two android phones or tablets that can send message to each other over the internet or wifi router without too much setup and effort.
Would appreciate any ideas on this. I can't figure out how the nest thermostat works (http://www.nest.com/) but that is kind of the functionality that I am looking to copy. I wonder if they have to use a centralized server for all of the remote controls. If there is a way to do this peer to peer that would be great. that way all i would need is two Android tablets.
The other examples I can think of is VOIP like skype and google talk. I am sure these don't use a centralized server for voice calls. My needs are much more simple. no voice or video, only sending text messages from one android device to another over the internet. Each android device will probably be using wifi exclusively.
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.