This project started out of researching how to play sound from spotify or rhythmbox from my laptop running ubuntu 11.10 through my hifi. Initially I set out to see if an airport express would work using raop and pulseaudio but it seems that support for the new 802.11 version is flakey so I didn’t wish to invest £80 in a device that might not work. During my research I found that DLNA supported streaming, DLNA is a protocol commonly used for sharing media files with devices such as networked dvd players, internet tvs and consoles like the ps3 so I explored further.
DLNA is supported in Ubuntu (and other modern linux distros) by Rygel, part of the Gnome project. Rygel provides a DLNA server which also has the capability to capture a pulseaudio sink (an input or output stream) and stream it to a DLNA enabled device.
Below are the steps I took to enable me to stream audio from my computer to my Sony BDP-S370, they should be applicable to any similar device: Read more ▼
I’ve been excitedly awaiting some of the new features found in PHP 5.4, in particular array notation and file upload progress monitoring so I decided to try and install PHP 5.4 on Ubuntu. Fortunately there is a repository of prebuilt packages for Ubuntu 11.04 (Natty Narwhal) at http://apt.damz.org/
I recommend using a VM so you don’t mess up any stable PHP install – I only tested this on Ubuntu 11.04 as that’s what was recommended and I already had a VM with it installed.
Installation
Installation is a very simple matter of adding the gpg key:
For a good while I’ve been meaning to get around to backing up my data properly. I’ve always had an external hard disk on which I backed up my important data periodically but that only covers the most basic of situations. If my house burnt down, or more likely somebody broke into my house,even just a power surge, I could conceivably loose both my real copy and the backup. From this I decided the only sensible way was to explore an offsite backup solution to use in addition to local backups. I’ve also been spurred on after buying an SSD and being unconvinced about their reliability. Indeed since starting to write this post my new SSD was recalled by corsair…
In this post I’ll describe what I backup and the online services and software I used.
My previous example Node.js, MQTT and Websockets showed the use of a websocket to broadcast messages from a subscribed MQTT topic, however the topic was hard coded and the messages broadcast to all who connected. The example below uses the same client side script to connect but allows the MQTT topic to be specified in the URL and only broadcasts to the individual client. Now to subscribe to a topic “test” the websocket address would be ws://<ip>/test. Read more ▼
For a while I’ve been looking at how to bridge the MQTT protocol and websockets to make it easier to build web applications using data broadcast in MQTT streams. In the past I used python and mod_pywebsocket along with mosquitto python libraries however this was cumbersome and difficult to install. Here I present a simple solution using node.js to interact with mosquitto MQTT clients. Node.js lends itself to working well with messaging systems like MQTT and websockets due to its event driven nature. I’m also in love with node.js at the moment!
This is much simpler than previous attempts and I put the initial test together in less than ten minutes.
Prerequisites
Obviously you’ll need to have node.js and mosquitto installed and also the node library node-websocket-server (which can easily be installed using npm). All my work was tested under ubuntu but there is no reason why it wouldn’t work on OSX or even cygwin. To test you’ll need a websocket compatible browser such as recent versions of chrome.
System Structure
mosquitto_pub and mosquitto_sub are command line MQTT clients supplied with the mosquitto MQTT broker, here mosquitto_sub will be called using node.js as child processes, events are generated on output from the process. The data is then captured and broadcast over a websocket. In this case a simple jquery page is used to display the broadcast messages but in a real application there would be more client side processing to make a useful application.
Just over a year when the chromiumOS code was first released I spent a while compiling it and experimenting and posted my opinions
I made a few basic points:
Little wifi hardware support
Requires a DHCP network
Quick boot time (~10s)
It’s just like Google chrome and nothing else
A few weeks ago @popey mentioned on twitter he was compiling it and this inspired me to have another go with it. In this post I intend to see if things have moved on.
UPDATE: I have now isolated the problems to 64 bit linux, 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.
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.
