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.
In my previous post Sheevaplug – An ideal home server I described why I loved the sheevaplug, now in this post I’m going to discuss why I now have fallen out of love with it. The main reason is shown in the following photo:
For the past six months I’ve been using the unit for 24/7 IRC using irssi, running an MQTT server and broadcasting to pachube, along with allowing me to ssh tunnel into a secure internet connection when using public wifi. So far so good. However during the middle of last week I noticed my pachube feeds had frozen, I tried to ssh into the device and that failed so being at work at the time I was miffed and couldn’t wait to go home to find out what was wrong.
At the Ubuntu Developers Summit this week one of the major announcements so far is Ubuntu Unity, a new lightweight GUI. The aim being to take the best features from instant on type Linux systems while still providing a fully featured system, this type of system being ideal for netbooks and appliance type computing. This GUI will form the basis of a currently OEM only distro; ubuntu light designed for instant boot appliance or netbook computers.
Despite only being in its infancy there is already a ppa available to install unity on ubuntu 10.04 so I decided to try it on my eeepc 901 on which I currently use vanilla ubuntu 10.04 as I don’t get on with the current Ubuntu Netbook Remix interface. One of the things that I’ve never quite got right is fitting everything on my 9″ netbook screen so I had high hopes that this new interface with vertical dock might do better in this respect.
In this post I’ll quickly detail how to install it and then quickly look at it’s features and shortcomings, I won’t repeat everything which has already been written regarding what plans are for the future.
In response to a comment below from solecreator.com I feel I should clarify that the site is in beta and issues are still being resolved. Personally I don’t feel this excuses the problems described although it does go some way towards explaining them.
To my mind using a BETA product as a public release for an ecommerce system is reckless and that paying customers should not be used as guinea pigs, if you know something isn’t right (indicated by it being labelled beta) then you should wait till it is before releasing, clearly our opinions differ.
I do however appreciate the time take to respond to my opinions. The original review:
Having an interest in cool websites, shoes and making things, a website that enables you to design a pair of shoes online and have them arrive at your door sounded a very appealing idea. If only the reality of solecreator was that good.
Online Experience
On arriving at solecreator you are met with a largely flash based website which I feel is acceptable for a site that’s going to have this level of interactivity, the initial process involves choosing your sex, size and model of shoe from a selection of named and unnamed brands including Converse and Vans. On completion of basic shoe selection you can decide if you want a quick tutorial, I opted not to use this and didn’t regret the choice. Now the main designer page is reached (shown below).
The designer emulates a generic image editor and is logically laid out with appropriate tool tips to explain the essentials.
I started out by trying to place one of my photos, which took three attempts to upload the image, the application freezing on previous attempts. The system also does not recognise uppercase file extensions so will not allow the upload of images with a .JPG extension on an operating system which uses case sensitive filenames (like osx/linux etc). Alarm bells also started ringing when the optimal image size was given as 50kB 200px x 200px which seemed to my mind very low for an (apparently) high quality print application.
