I discovered a post that concerned controlling the Raspberry Pi’s GPIO via a browser. This idea of controlling my Raspberry Pi (RPi), and the things its networked with, via an internet browser is at the heart of what I would like to do with the assortment of Arduino and Xbee devices I’m assembling. To explore how best to do this, I’m considering using WebIOPi, which is a web application used to control your RPi’s GPIO. I believe it could be useful as a test tool, but more importantly, I suspect that I could learn how to engineer my application by studying its design.
When installing WebIOPi on my RPi, I followed the installation instructions for the Apache version. I choose this version since I’ll be using the Apache web server for other features as my project evolves. Note that there is a small error on the instructions if you use a symbolic link to the webiopi directory. Create this link using
sudo ln -s /home/pi/webiopi /var/www/webiopi
Immediately after installation, you can test to see if you can render a web page. Assuming that your Raspberry Pi is connected to your network and its named
raspberrypi, you can open a browser to
http://raspberrypi/webiopi/ with your network PC. It might work but your likely to get a error, something like “…Could not reliably determine the server’s fully qualified domain name…” and the solution is to give your web server a name.
To do this, create this Apache config file:
sudo vi /etc/apache2/conf.d/fqdn
ServerName raspberrypi into this file and restart Apache using
sudo /etc/init.d/apache2 restart
Installing GPIO Utilities
While checking on the status of of the Python based GPIO package on the RPI using the command
dpkg -l | grep gpio, I concluded that the Occidentalis distribution I’m using doesn’t have any Python libraries for GPIO.
Picking up some tips from Raspberry Pi E-mail Notifier Using LEDs. I determined that I need to install several python packages first. I did this via
sudo apt-get install python
sudo apt-get install python-dev
sudo apt-get install python-pip
With this done, now its time to install the required Python libraries but first, update the Python distribution by running
sudo easy_install -U distribute
Finally you can install the Raspberry Pi GPIO (General Purpose Input/Ouput) library:
sudo pip install RPi.GPIO
What did I find
WebIOPi supports binary GPIOs, in both input and output. That is, you can set a GPIO output pin high/low via a browser pick. Also, you can see the state of a GPIO pin. Equally important to me is that WebIOPi auto-refreshes, via WebAPI, REST, JSON and AJAX I assume. Therefore, when the GPIO pins change state, the browser automatically is updated with the new status. And this happens for all browsers displaying WebIOPi. You can demonstrate this by opening two browsers pointing at WebIOPi. Action performed in one browser will also appear in the other.
I used this code to generate some random activity on the GPIO pins and test WebIOPi.
#!/usr/bin/env python import RPi.GPIO as GPIO, time BLINK_FREQ = 3 # refresh GPIO pins every 3 seconds GPIO.setmode(GPIO.BCM) GPIO.setup(0, GPIO.OUT) GPIO.setup(1, GPIO.OUT) GPIO.setup(4, GPIO.OUT) GPIO.setup(17, GPIO.OUT) GPIO.setup(21, GPIO.OUT) GPIO.setup(22, GPIO.OUT) GPIO.setup(10, GPIO.OUT) GPIO.setup(9, GPIO.OUT) GPIO.setup(11, GPIO.OUT) GPIO.setup(18, GPIO.OUT) GPIO.setup(23, GPIO.OUT) GPIO.setup(24, GPIO.OUT) GPIO.setup(25, GPIO.OUT) GPIO.setup(8, GPIO.OUT) GPIO.setup(7, GPIO.OUT) i = 0 while True: if i == 0: GPIO.output(0, True) GPIO.output(1, False) GPIO.output(4, False) GPIO.output(17, True) i = i + 1 elif i == 2: GPIO.output(0, False) GPIO.output(1, True) GPIO.output(4, True) GPIO.output(17, False) i = i + 1 elif i == 1: GPIO.output(7, False) GPIO.output(8, True) GPIO.output(25, True) GPIO.output(23, False) i = i + 1 elif i == 3: GPIO.output(7, True) GPIO.output(8, False) GPIO.output(25, False) GPIO.output(23, True) i = i + 1 elif i == 4: GPIO.output(21, True) GPIO.output(22, False) GPIO.output(10, False) GPIO.output(9, True) GPIO.output(11, True) GPIO.output(18, True) i = i + 1 elif i == 5: GPIO.output(21, False) GPIO.output(22, True) GPIO.output(10, True) GPIO.output(9, False) GPIO.output(11, False) GPIO.output(18, False) i = i + 1 else: i = 0 time.sleep(BLINK_FREQ)
The use of a Web page to control the RPi seems useful enough but what if the target environment for launching control messages is a cell phone? Maybe a phone app would be a better approach. Check out the post Raspberry Pi + iPhone: Control a RPi with an iPhone in 2 Minutes.
As stated in an earlier post, I plan to run my Raspberry Pi (RPi) as an attached device to my homes LAN and use my MS Windows PC to access the RPi. The RPi will use my PC for display output and key board / mouse as input. With the X Window System on the RPi, I can transmit an entire RPi desktop if I wish (using LXDE and it would look and feel much like VNC). I find this cumbersome since now your dealing with two desktop environments: MS Windows desktop and X Window System based desktop all one display.
There is an alternative way. One of the cool things about the X architecture is that it can use MS Windows as your window manager (at least with the tools like Cygwin/X, Xming, and MI/X) but the application within the window frame can be the RPi based X Window System application. Now you have a single desktop (MS Windows) but your running RPi application within a MS Windows window. And with this configuration, you can run both Linux programs within a standard terminal window and graphic X Window System applications in another window.
For me this is clearly the way to go. It will allow me to hop on my PC, and with a double-click on a desktop icon, get me to a password prompt on the RPi. Enter the password, and I can immediately run both command line and X graphics application on the RPi, along side MS Windows applications, all concurrently on a single desktop.
How I did this, along with some background information, is provide below.
X Window System
The X Window System (commonly referred to as X Windows or just X or X11) is a software system and network protocol that provides a basis for graphical user interfaces (GUIs) and rich input device capability for networked computers.
X uses a client/server model, but appears backwards when you first learn of X. In X, it’s the server that runs on the local machine (the PC), providing its services to the display based on requests from client programs that may be running remotely (the RPi). Within a X Window System, a client can also run locally. The server also manages the input devices (your keyboard and mouse), and it manages the display of colors and fonts on the screen, all based on requests from a client.
One of the most significant features of X is that it was specifically designed to work across a network. The client and the server communicate via the X Protocol, a network protocol that can run locally or across a network. Regardless of whether a client program is local or remote, it communicates with the server through the X Protocol.
X Window System Components
A X Window System consist of several components which work together. They are:
- X Server – manages the display, based on requests from the window manager.
- Window Manager – is an application that is itself an X client, with responsibility for managing the appearance and placement of the windows on the screen. The window manager takes care of the appearance and placement of the windows; it doesn’t determine what goes on inside.
- Windows – are the X clients, typically providing user functionality. Windows are fully in control of the application but their placement, geometry etc. are controlled by the window manager.
- Display Manager – runs as a program that allows the starting of a session on an X server from the same local or remote computer A display manager presents the user with a login screen which prompts for a username and password. A session starts when the user successfully enters a valid combination of username and password.
- When the display manager runs on the user’s computer, it starts the X server before presenting the user the login screen, optionally repeating when the user logs out.
- When the display manager runs on a remote computer, it acts like a telnet server, requesting username and password and starting a remote session.
- Desktop Environment – go further than a window manager in providing an integrated graphical environment where all applications and windows have a common look and feel. The desktop environments also include session management, for saving and restoring your work sessions.
In the spirit of user-friendliness and security, the desktop and display manager hides much of the X Window System and its’ subtleties. If you want to really explore X (and light its load on the RPi), it’s helpful to run with just a window manager for a while (even if you plan to go back to the desktop). That is what I plan to do.
Cygwin’s X Server and Window Manager
Before you can run a X client, you need to start the X server. You can run the X server in two ways: it will automatically start if your Linux is configured with a X Display Manager (XDM), and if not, at the Linux command line you can start X manually. It is the latter that I want to do on my PC / RPi combination (and the way my RPi distribution Occidentalis is pre-configured). Also, in my configuration, I’ll be using the Cygwin X server on the PC, and no server will be running on the RPi, only X clients.
Now there are some important capabilities within the Cygwin X server. Cygwin/X can work with its window managers in several different ways.
- Internal window manager – The internal window manager creates a MS Windows window for each top-level X window. This window manage is “internal” to the Cygwin X server.
- External local window managers – These local window managers must be installed on Cygwin and runs on the PC (e.g. twm, mwm, fvwm2, openbox, aewm++, WindowMaker).
- Remote window managers – This would be a situation where the window manager is on the RPi and would connect via a remote sessions using XDMCP (X Display Manager Control Protocol).
I plan to keep things simple and use the Cygwin internal window manage.
XWin is the X Server for the X Window System on the Cygwin environment running on Microsoft Windows. It can operate in three different modes:
- Single Window – This is the default mode. Each X screen appears as a single MS Windows window and all X windows are contained within this window. (In X terminology, the MS Windows window contains the root window for the screen.)
- Multi-Window – In this mode XWin uses its own integrated window manager in order to handle the top-level X windows, in such a way that they appear as normal MS Windows windows.
- Rootless – In this mode the X server works in a window containing the whole screen but this root window (traditionally covered with an X hatch pattern) is hidden from view, so only top-level X windows are seen.
To get a better idea on what the different modes can provide you from a user experience perspective, check out some Cygwin/X screen shots. Again, my objectives are to keep things simple and clean, so I will be using the multi-window mode.
To operate Cygwin/X in multi-window mode you use the command
startxwin (You use
startx for window mode.
startxwin is a specialized version of
startx with a few differences appropriate to running in multi-window mode, rather than windowed mode). The
startxwin program has a resource file called
.startxwinrc. You can create a
~/.startxwinrc script to start client programs, such as mintty or xterm. An example
.startxwinrc file is:
mintty --position 100,100 --size 80,50
mintty --position 150,150 --size 80,50
mintty --position 600,500 --size 80,25 --exec ssh -X firstname.lastname@example.org
This will open up two xterm windows for your in the left hand corner of the screen and a thrid xterm window in the center of the screen. This third screen is automatically logging in to the RPi as user pi and will wait four you to enter the password.
Also make sure that you export your
DISPLAY for the X server on your PC. You can do this by placing the following in your
# environment variables required by X Window System
Not much needs to be done to the RPi to prepare for the X applications. You may wish to launch some X Window System application upon logging in. You can do this by adding the X applications to your .bash_profile. For example, add the following line to launch the LXDE file manager:
# execute X Window System programs
Starting and Stopping the Cygwin X Server
The environments are now set. Time to start the X Server. The easiest way for starting Cygwin/X is using the “XWin Server” shortcut under “Cygwin-X” on the Start Menu or on the MS Windows desktop. You could also type
startxwin on the Cygwin command line.
As to stopping the X Server, for the window mode I’m working in (multi-window), stopping Cygwin/X can be done by Selecting the “Exit…” option from the notification area icon menu.
How Does It Look
So given the configuration discussed above, your get a nice clean display with MS Windows, Cygwin, RPi command line, and RPi X Window application running in a single windows management environment. Picture provided below:
You thought the Raspberry Pi was a simple little hardware hackers computer …. but its running like a big dog now!
Much of what is provided here was lifted from the following sources: