Remote UI
- Ken Bannister
[ The Web UI was completed in October 2013. This page archives the design work for the project. ]
We wish to provide a realistic standalone border router implementation for an OpenWSN wireless network, in addition to the current PC-based all-in-one router and visualization software implementation. This goal involves segmenting OpenVisualizer software so that the core runs on a device with reduced resources, typically a headless embedded Linux unit. As a first step toward that goal, this page describes refactoring the user interface to provide a display external to the border router. The diagram below illustrates this architecture.
UI Implementations
We can imagine several different implementations for a remote user interface, as listed below.
- Web UI – Provide a new, web-based interface
- Remote GUI – Reuse the existing Tkinter UI
- Remote CLI – Reuse the existing command line interface
All of these options provide value for OpenWSN as a toolkit, by allowing a developer to select the most appropriate for a given deployment. In addition, we must continue to support the use of a local GUI or CLI. The local interfaces have developed independently, but now we need to build more structure into the UI and around the relationship between the UI and the OpenVisualizer application. The diagram below shows the structure and relationships.
| Component | Description |
|---|---|
| OpenVisualizerApp | Defines a common model for the application, independent of the particular UI. For example, defines the selected mote for mote status reports. Derive from OpenVIsualizerGui_app. |
| OpenVisualizer UI | Conceptually, an interface from the application to a UI. The class itself may have little functionality. Most importantly, this interface is realized by the Web UI, local GUI and local CLI. |
| Web UI | An application web server. This UI may assume several forms remotely, but it always includes the ability to download UI-independent messages, like a JSON-based structure for the event count, or the selected mote's status information. See the Messaging section below for details. Furthermore, mote status information must be sent from server to client frequently. This style of interaction is well supported by a WebSockets-based push from the server. In addition, the Web UI must provide HTML, CSS and JavaScript for the Browser-based remote UI. There are several options for implementation of a web UI. See the Web Framework section below. |
| Local GUI | The present Tkinter-based OpenVisualizerGui, refactored to support OpenVisualizerApp, which is based on the existing OpenVisualizerGui_app. |
| Local CLI | The present OpenVisualizerCli, refactored to support OpenVisualizerApp. For implementation, use of the cmd2 module provides missing functionality, including output redirection, command history, and scripting. This module can replace, or provide a new basis for, the OpenCli library of functions. |
| Browser | A modern web browser, which supports WebSockets. |
| Remote GUI and Remote CLI | Shares UI definitions with Local counterpart. The fundamental difference lies with how content is retrieved, over the TCP connection remotely, or in-process locally. These UIs have particular value when OpenVisualizer runs in a daemonized mode, without standard I/O streams. |
Future Server Implementation
It is possible that a border router will operate behind a firewall, and will not be accessible by a remote UI outside the firewall. In this case we can imagine one more realization of a remote UI – via an always-on, available server. This solution may be implemented as a variation on the Web UI component, where the border router acts as a WebSocket client rather than a server. So the router would send content messages, like mote status updates, to the web server, which then would present them to a browser-based client. We consider this implementation as future work due to the infrastructure and complexity involved.
Web Framework
The Web UI must provide a web server and websockets. Below are interesting implementations. Also see the WebSocket Notes page for more background
See the Web UI Implementation page to test it during development or just watch progress.
Web Framework and Pages
Our requirements are simple, but a framework and page templates will improve productivity and maintenance. Implementations:
- Bottle – Includes its own templates or can use others. Includes a simple web server based on standard library wsgiref. Supports WSGI capable servers.
- web.py – Includes templates. Proposed in Issue SW-1. Includes a simple web server based on Colin Stewart's wsgiServer. Supports WSGI capable servers.
Web Server
We may start simply, with the test/development server in the web framework. This may be sufficient, since we expect only one or a few web clients. Or we may need to migrate the server to something more capable. Implementations:
- CherryPy – Also includes a web framework without built-in templates, but supports others. Explicitly supported by Bottle.
- gevent – A networking library that includes a couple of web server applications. Depends on libev and greenlet. Explicitly supported by Bottle.
WebSockets
- ws4py – Supports use of wsgiref, CherryPy, and gevent.
- gevent-websocket – Supports gevent
JSON Messaging
JSON provides a convenient and widely accepted mechanism for implementation of the structured messages we must pass between the application and a remote UI.
Messages include:
| Message | Description |
|---|---|
| mote-inventory | An array of the connected motes. Requested just after establishing the connection to the application. |
| mote-status | An object with the elements of a Mote Status report. These reports may be pushed to the remote UI at some defined rate. |
| event-count | An object with the current count of each event, which also may be pushed to the remote UI. |
