Creating a website to communicate with an embedded device

Question

I'm currently working on a project where I'm trying to control an embedded device through an Internet facing website. The idea is is that a user can go to a website and tell this device to preform some kind of action. An action on the website would be translated into a series of CLI commands and then sent to the device. Communication could potentially go both ways in the future, but right now I'm focusing on server-to-device.

The web server is a LAMP stack using Python (Django) and the device I'm trying to communicate with is a Beagle Board running eLinux. There would be only one device existing at any time communicating to the server.

I have all the functional parts written on the server and device side, but I'm having a bit of trouble figuring out how to write the communication layer. One of my big issues is that the device will be mobile and will be moving locations every few days. So, I can't guarantee a static IP address for the device. My networking programming knowledge is pretty minimal so I don't have that great an idea on where to start.

Does anyone have any ideas/resources on how I can start developing this kind of communication?

Thanks!

Inapt

Answer 1

You can simply register a dynamic host name using a provider like DynDNS and have the device update it's IP on that website so the dynamic hostname always points to the device IP - there are plenty of clients, scripts etc. available for Linux that do just that.

Transitory

+1: Probably simpler than writing something for the device to connect in. Why invent the wheel right? :) – Sosthina

Answer 2

If the server is going to be static, you could always get the device to establish a connection to the server to report it's IP address.

You could write a simple UDP server for the device to listen for incoming communications and then write a client in python for your web server to call.

Sosthina

Answer 3

My normal mode of conduct (certainly as it could have to go through NATs and the like) is to have the device set up a reverse SSH tunnel that just 'calls home': http://www.howtoforge.com/reverse-ssh-tunneling

Mind you, SSH connections break from time to time, so I'd set a heartbeat method on the server, and if the client (Beagle Board) misses a set amount of heartbeats, let it destroy the tunnel & create a new one.

Salter

I'd go for this option because your client device might not have a public IP address on some phone networks. – Byron

Actually, the op said it would be mobile (as in not static) not attached to a modem or mobile phone. Wrikken's answer is a good suggestion though :) – Sosthina

Answer 4

the device will be mobile and will be moving locations every few days. So, I can't guarantee a static IP address for the device.

Your device can be a client of the web site.

Your web site has two interfaces.

1. HTML interface to people.

2. A non-HTML interface to the device. As a client of a web site, the device will need an HTTP client-side library to send a request to the web site. This request will include the device's IP address, plus all the usual malarky buried in an HTTP request. (There are a bunch of standard headers that are sent in a request)

Once the device has made it's initial request, then your web site can save the device's current status and communicate with it through another protocol if you want to do that. (I'm guessing that "I have all the functional parts written on the server and device side" means you have some other protocol for controlling the device, and this protocol isn't based on HTTP.)

It might be simplest in the long run to have the device poll the web site for commands or updates or things. That way the device is a pure web client using only HTTP, and your web site is a pure web server, using only HTTP. Then you don't need your more specialized second protocol. Using only HTTP means you can use SSL to assure a secure communication.

If your device uses HTTP to get commands and updates, you'll need to work out a usable representation for data that can easily be encoded into HTTP requests and responses. Choices include XML, JSON and YAML. You can always invent your own data format; however, you'll probably be happier debugging a standardized format like JSON.

Building these two interfaces in Django is pretty trivial. You'll simply have some URL's which are for people and some which are for your device. You'll have view functions for people that return HTML pages, and view functions for your device that return JSON or XML messages.

Urbannai