The Web Server component of the E.O.T. will probably be the most complicated, so I started with it. A Github repo has also been created that will hold the panel and the Teensy control code too.
The soft plan at the moment will be to write a number / status value to a file via the Teensy; which will be written in C. Implementing the rest of the stack in C is madness considering we have no need to keep everything embedded.
This means that we’ll need a file watcher connected to a web app for the panel interface (which, with v1.0 will be a soft panel). I know of a decent watcher in Ruby and a couple in Python, and considering I hate Ruby and Fenchurch already has Python (somewhat) installed; it seemed like a good starting point. Python also has a decent http server stack so that’s a plus; but:
with Python… I could argue that this could all be done in Haskell too, but no-one likes and Evangelist.
So next step: I don’t want to have to refresh the page on an update of the E.O.T. (i.e. a modification in the status file), nor do I want to poll the server with a tonne of ajax queries every 30 seconds or so. Although the update doesn’t really need to come through as a push notification, it’s also useless if coffee is called and no notification arrives for 15 minutes…
(Very, very) long story short; I’ve implemented the communication system using Web Sockets. They’re compaitible with most browsers (maybe not if you use IE, but also: if you use IE I don’t care about notifying you of anything anyway) as long as it’s a relatively recent build (Chrome though: you’re good almost as far back as the dark ages).
Tornado is a great Socket server capable asynchronous (threaded) processes. This is quite helpful for us here because our file watcher will need to run in a separate thread. If any of you have worked with async before you’ll know it’s a nightmare if you don’t have things set up right: race conditions, deadlocks etc. etc. It also handles many unique clients - so we can all have the panel open on each of our machines. With the web sockets always open (but not polling), we will have push notifications from the E.O.T. without any overhead on Fenchurch or our local machines.
Once the server is initialised, a callback to Watchdog is added, which watches status.eot: the file written via the teensy, for modifications. If the file has changed (the E.O.T. position has been changed), that value will be instantly read and pushed through the open web sockets to each attached client.
A small amount of debugging has also been implemented (see the on_message member of the WebSocketHandler class below), which is currently accessible via the panel; although it’ll most likely be removed in the future.
Clients are currently identified by uuid, but in the future this can be changed to something more personal, a mac address, something like that. It depends on how much capability we want to put into the panel and if any decent ideas are thought up along the way. One thing that I’ve left out presently is a broadcast update of each client’s acceptance message. I’ve done this because it may be a good way in the future to indicate who is coming to coffee or something.
The only other thing of note is that I’ve implemented a graceful shutdown so Jared (or any other sudoer) can call a kill -2 on the server to halt it if it’s being an ass. It will call shutdown routines for the watcher and allow any further socket communication to cease (with a maximum waiting time of 5 seconds) before ultimately killing itself.
The code for v0.5 is posted below with enough comments to get you by. Most of those reading this will be familiar enough with Matlab to be able to ‘read’ the Python syntax.