In this post I will show the latest in a line of mini examples using html5 and websockets – an example of how future home monitoring dashboards should be created. At present they commonly use a combination of flash dials and JavaScript canvasy bits and pieces to create representations of data obtained via ajax. This has the inherent disadvantage that the browser polls the server rather than the server pushing values to the browser when available. Also there is very little in the way of accessibility as far as canvas and flash are concerned. In this post I will show a simple example of using data via a web socket and displays it via the meter.
While nothing demonstrated here is rocket science it’s something that’s not being focused on enough, developers seem to be getting lost in the shinyness of the canvas and forgetting the built in meter functionality along with it’s inbuilt accessibility. Having said all that it is only displayed by the more bleeding edge browsers and things may pick up as the html spec matures.
UPDATE: I have now isolated the problems to just my particular configuration of apache, ubuntu and mod_python, the setup described here does work without using the standalone web server and using apache…just not on my main system!
Following on from my experiences installing and testing pywebsocket I now move to the main reason why I bothered…to create a bridge to allow a user to view a web page showing a live stream of MQTT messages.
It should be noted that despite making the effort to setup pywebocket with Apache this time I will be using the standalone web/websocket server provided with pywebsocket (standalone.py) as I’m still trying to debug why this code doesn’t work with apache!
Since my initial posts on websockets I’ve moved to pywebsocket, this is a python based project which provides a websocket extension to apache via mod_python. It can also run a standalone web server/websocket server if required.
I made the move from node.js based systems as I was more comfortable developing using python and apache (even though I don’t know much python) and also most of the other systems I wish to integrate work well with python. I also feel that using a python extension to apache is a more sensible solution which is able to work on most webservers without major reconfiguration.
Until recently developing MQTT clients in anything but perl was a little tricky due to a selection of badly documented, restrictively licensed client libraries (in PHP, Java and C). After a lot of hard work on the part of Roger Light (@ralight developer behind the OSS MQTT Broker Mosquitto) there is now another solution available.
An MQTT pubsub client library written in C is now included along with a basic python wrapper. To me this greatly improves the situation as it now means it’s possible to quickly and simply develop real applications or web applications without wrestling with some of the more complex APIs traditionally used. After attempting to get to grips with the IBM ia92 java client library this was a breath of fresh air.
As an initial toe in the water exercise I looked at the included sub.py script (after compiling and installing mosquitto 0.8.2) and wrote the code below so that all messages on the “test” topic display a notification in ubuntu. While only a minor coding exercise this is a potentially useful application when MQTT is being used for monitoring systems.
Note: Recently others have noticed problems with installation of the python libraries, if you have such problems check to ensure that the appropriate files are in /usr/local/lib/python2.6/dist-packages/
This post serves as a update to my previous post: Getting started with Node.js and Web Sockets on Ubuntu 10.04 In which I stated various problems I had encountered. In this post I will explain why most of them occurred. In this post I refer mostly to the server side handshake, the client side processing is a 45 step process which looks pretty nightmarish to me!
After more in depth research I’ve discovered the cause of many the examples I tried in my previous post. On the 6th June 2010 the handshake for the web sockets protocol was changed and broke backwards compatibility with earlier implementations. This means that now you have to ensure the browser version you are using supports the same handshake as server. I suspect due to me not knowing this that many examples failled to work as I sporadically switched between builds of chromium and node.js – to guarantee support you need to use the latest version of Node.js and Chromium/Chrome 6.0.414.0 or above.
I also attempted to use the Arduino websockets library without success which I now find uses an old protocol, it is my intention to attempt to remedy this when I have time.
Having spent the past few hours taking my first steps into the glorious unknown world of web sockets I’ve drawn a few conclusions about web sockets:
The principals are very easy
It is an area of great interest and development
There are seeming 101 different implementations many of which are out of date and broken
So this post I want to document a simple demonstration of the use of web sockets with node.js which works now (August 2010) to serve as simple demonstration to those wanting to dip their toe in the water before going further. Many examples and demos were outdated and failed to run for a variety of reasons, mainly due to node.js being updated and the examples not being changed to reflect this. I did all this on ubuntu but there is no reason why it shouldn’t work on any other Linux system.
Currently a project I’m involved in at work requires a dashboard to show the current status of orders within our automated workflow so for part of this I decided to use the google charts API, then I reliased that Google didn’t offer charts over https.
However the problem is fairly simple to circumvent by caching the graph to a file and then loading the file over https from your own site, indeed an example has already been published here but that example uses functions disabled on many web hosts (including mine) : file_get_contents() and file_put_contents(). These functions can pose a security risk when enabled so I decided to use a similar solution but using cURL which is supported by most hosting providers.
The basic principal of this is to form the URL in the normal way then to save the graph as a file and load it as a normal <img>. In the other example I referred to caching is used, in my application the graph will change so regularly and the number of hits will be low that it’s not worth doing this.
Thanks to some help from @knolleary the arduino pubsub library now works with mosquitto. I have now completed my bandwidth monitor project which I want to document in this post.
I have mentioned in previous posts that I use various scripts and sensors to feed data into the open source MQTT broker mosquitto. Currently all data is posted to pachube, rather than everything being online I decided I wanted some physical feedback. Having made an impulse buy of two vintage Ferranti ammeters using these to display some of my data seemed like obvious answer! The code on the arduino basically just displays a number passed by MQTT on the meter and therefore could be applied to any measurement one cared to choose.
The basic idea of this system is to monitor the current internet speed usage and display it on the ammeter. The system is based around an arduino with ethernet shield which acts as an MQTT client, this subscribes to the downstream bandwidth topic on my MQTT broker, receives the messages and changes the level of a PWM output pin on the arduino which causes the meter to show the appropriate level. The meter displays the current through a resistor which is varied by the PWM signal from the arduino. The reading on the meter corresponds to the current internet speed usage as a percentage of the overall theoretical available bandwidth.
As mentioned in my previous post I use a sheevaplug as a LAMP server and also run the MQTT server Mosquitto. In this post I shall not detail the finer points of MQTT and pub sub messaging, they are well described in this presentation by @andysc if you’re not familiar. I intend to cover the more obscure topic of using PHP to write a simple MQTT client which can both publish and subscribe, getting input from an arduino into PHP and subsequently publishing it to Pachube. Currently I use MQTT to monitor temperature, bandwidth usage and cpu usage however this is set to expand in the future.
PHP and MQTT
Currently the majority of MQTT users seem to use clients written in Perl, which is fine for those over a certain age where Perl is common knowledge, but when standing next to some more recent scripting languages like PHP and python it’s a bit archaic! Conveniently IBM have provided the SAM PHP library which includes the capabilities to send and receive MQTT messages and is quite simple to use both from the CLI or as part of a web application. However it includes support for other IBM protocols which isn’t required for basic MQTT communication so the complicated compilation and installation is not really required here, just the php files, thus the folder can be placed in the same folder as the project using it and included with a standard php include:
Without a doubt TI have produced a cult product in the chronos watch and it seems to be marketed to both get people using their msp430 chips and on a smaller scale produce cool projects with the watch. They have done well in providing the code for the watch and the the included hardware works well (albeit lacking much Linux compatibility). However I feel they’ve been slightly too clever in the hardware design and thus prevented some cool uses of the product. This post comes in response to some views recently posted on hackaday.
A recent hackaday post suggested using the supplied receiver could be modified to be used with an MCU, however this is unlikely unless the MCU acts as a USB host for a CDC device. Also the currently available watches use 868MHz which is a band in which cheap transceivers are not available (or at least that I can find), when the 433Mhz version is released in march interfacing the watch with an MCU may become a trivial task with cheap hardware. Continue reading How the TI ez430 Chronos watch could be better (Updated)…
