1

I have a Raspberry PI that is tightly coupled with a device that I want to control.

The desired setup I want to have would look something like this:

  1. The physical device with interactive hardware controls on the device (speaker, mic, buttons)
  2. A Raspberry PI coupled to the device

  3. On the PI:

    1. A daemon app that reacts to changes from the hardware
    2. A Webinterface that shows the current state of the device and allows to configure the device

  4. The system should somehow be able to update itself with new software when it becomes available (apg-get or some other mechnism).

For the Webinterface I am going to use a rails app, which is not a problem as such. What is not clear to me is the event-driven software that is talking to the hardware through gpio. Firstly, I would prefer to do this using ruby, so that I don't have a big technology gap when developing the solution.

  1. How can I ensure that both apps start up and run in the background when the raspberry PI starts
  2. How do I notify the webapp of an event (e.g. a button was pressed).
  3. I wonder if it makes sense that the two pieces of software have a shared database to communicate.
  4. How to best setup some auto-update-mechanism for both pieces of software without requiring the user to take any actions.
Besi
  • 22,579
  • 24
  • 131
  • 223

1 Answers1

2

Apps

This will be dependent on the operating system

If you install a lightweight version of Linux, you might be able to create some runtime applications or something. I've never done anything like this; but I know from Windows you can create startup programs -- likewise, you should be able to do something similar in Linux

BTW you wouldn't "run" the Rails app - you'll fire up the server to capture any requests. You'd basically run your app locally in "production" mode - allowing you to send requests, either through localhost, or setup a pseudo domain in the HOSTS file of your box

--

Web App

The web app itself is RESTful, meaning (I believe), it will only act upon having requests sent to it. Because this works over the HTTP protocol, it essentially means you'll need some sort of (web) service to send requests to the web app:

Representational state transfer (REST) is a way to create, read, update or delete information on a server using simple HTTP calls

Although I've never done this myself, I would use the ruby app on your PI to send HTTP requests to your Rails app. This will certainly add a level of complexity, but will ensure you an interface the two types of data-transfer

The difference you have is Rails / any other web app will only act on request. "Native" applications will run as long as the operating system is operating; meaning you can "listen" for updates from the hardware etc.

What I would do is split the functionality:

  1. Hardware input > send to service
  2. Service > sends to Rails
  3. Rails > sends response to service
  4. Service > processes response

This may seem inefficient, but I think it's the best way to capture local-based input from your hardware. You'll have to use a localhost rails app, running with something like nginx or some other efficient server

--

Database

it would only make sense if they shared the data. You should remember that a database is different than a datatable. A database stores many tables, and is generally meant for a single purpose; whilst a datatable stores a single type of data.

From what you've written, I would recommend using two databases running on the same db server. This will give you the ability to create as many tables as you want for these databases - giving you scope to add as many different pieces of data you wish to each. Sharing data can be done using an API or a web service

--

Updating

Rails app will not need to be "updated" - you'll just need to deploy a fresh version. The beauty of Internet-centric software :)

In terms of your Rasberry-PI "on-board" software update - I don't have much experience with this, so can only recommend

Community
  • 1
  • 1
Richard Peck
  • 76,116
  • 9
  • 93
  • 147