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.
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.
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.
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 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.
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:
The sheevaplug, a marvel development platform based on a 1.2GHz has risen out of obscurity in recent times as a silent, very low power computer. It’s uses have been stretched way beyond the intended use into cars and even as a full on desktop computer, despite it’s lack of connectivity.
The basic hardware consists of:
Marvell Kirkwood 6281 CPU at 1.2 GHz with 256 KB L2 cache
512 MB RAM
512 MB flash
Gigabit Ethernet
1x USB and 1x SD
mini-USB with serial console and JTAG
The system is fanless and there are no moving parts, so it is silent apart from a strange extremely high pitched ringing sound which is on the edge of being audible.
In this post I’m going to describe what made me choose the sheevaplug, what I have added to default system and why I love the sheevaplug.
Whilst building this site I decided I wanted to put my recent tweets on the main page, which using cURL and php is a pretty simple task, however the twitter API restricts users to 100 requests per hour and if the limit is exceeded subsequent attempts are blocked until the end of the hour. To get around this I searched around for a library to do the work for me and found many but all seemed to provide overly complex functionality.
This lead me to write my own simple library which gets the most recent tweets from a specified account and caches them to a text file on the server and allows the user to place them in a webage as a simply formatted unordered list of links to the posts. The code for the library and an example are shown below. Read more ▼
For a few years now at home we have used the BT (rebadged 2Wire) 1800HG which has provided good service for the whole time but it’s only now I’ve investigated into its workings a bit more closely.
Recently I had cause to be looking through the router web interface and came across a primitive “Speed Meter” monitoring current upload/download speed usage so of course the first thing that occured to me was how can I get at the data so I can build my own more funky version.
After some investigation I found the graph was being generated using a java applet embedded into the page. I then downloaded from /base/web/speedmeter/MeterApplet.class and subsequently decompiled using the java decompiler JAD. This led me to find that the applet was requesting data from /base/web/speedmeter/speedmeter_data which provides an xml file with the current upload and download speeds in in the form:
Parsing this data will require some modification as this is not really valid XML as it has no root node but that is easily rectified. I’m currently working on integrating this with an mqtt system
