Category Archives: Raspberry Pi

A Node-Red Websockets Web Page

Updated 26/04/2015

I’ve been after this ever since I discovered Node-Red.. and right up until this yesterday I was tearing my hair out – having settled for NETIO as my interface of choice and constantly being annoyed by the slow pace of progress with this interface.

So what is this all about? At the end of this, if you don’t know how already, you should be able to put together your own mobile friendly web page which will talk to Node-Red and from there to and from whatever other gadgets you wish.

So what is involved?

Well, you need Node-Red to listen to incoming websocket requests and to be able to respond… that and a web-browser for now is ALL you need. You do NOT need (though you could use) the whole web server structure).  In my case, Node-Red on a Raspberry Pi – that’s it.  The PURPOSE for me at least is to control stuff by MQTT but I’ll not cover that here as I’ve talked about it elsewhere and that too can be handled with ease in Node-Red.

So in my case this is running on my Raspberry Pi locally but it doesn’t have to be – that’s just what I’m using for testing. What you see here above are three standard node-red nodes.. a websocket input – a function (DIY info) node and a websocket output.

Aside from giving them meaningful (or otherwise) names the only thing you need on the websocket bits is the URL. Any URL within reason staring with /.  I used /myapp but something more meaningful would be better. This is NOT the address of your web page – this is the address of the websocket connection. Read on.

Simple WSWhen you hover over the Websocket input  in Node-Red editor,  there’s a mention in the INFO box about killing msg._session in the flow. That meant nothing to me until one of my readers set me straight.. but it’s very simple in the example above, any information coming in from say a browser will be sent back out (second block market “ws out” to th same browser.

That’s it. Anything coming in to the websocket input node goes out of the websocket output node to the same browser but not another browser looking at the same page.

node-red websocketsThis version however with the function in the middle with nothing more than…

return msg;

The information above kills the session info needed to lock down a given session so that in this scenario one browser may send a button press causing an action – and that will also be sent to any other browser looking in… as you can imagine a one-to-one chat window becomes… trivial.

So all we need now is a web page that will connect to this websocket  – one which can send information to Node Red and also receive information.

I wanted a simple test web page to have a field that I could fill in – and a submit button that would send information to the websocket without all that refresh stuff and which would return the information to the page. Clearly one can to things with that info as it passes through the middle orange function block if present (passed in msg.payload).

It is very convenient to have everything in Node-Red and it is perfectly sensible to have it serve up the web page AS WELL as handling web sockets….

node red sockets and web page

Note the addition of the bottom three boxes (see above, “kill session is not necessary unless you want to broadcast any changes to all browsers looking in – but you may want to use that block for something else – like handling traffic passing through from the web page and back to it).

For the web page itself, these are http, template and http response blocks respectively. The left most simply needs a URL – I’ve called it /testing  and a useful name – the rightmost needs nothing but a useful name.. the middle block contains a bog-standard webpage of your design – and within that the websocket connection.

Pretty basic but that’s the idea. No need to even construct a web page – the html and js can all sit in the block marked “html+js”.

My internal address is, unlike a normal web page, the pages you serve in here are on port 1880 by default so the internal address for this page would be


But herein lies the rub.. what if you want folders (css, images etc) – where would you put them?   I chose instead as I already had Apache web server running on the Pi to put my PAGE there instead. There is also the point that basic page security is easy to implement on Apache.

So – there are examples out there of a simple web page, there are other examples of mobile web pages – and even more of simplifying normal Javascript using JQuery (which is wonderful) and I guess all I’ve done here is merge all of this into a useable if trivial page for the purposes of demonstration. I could have complicated things by requiring loads of libraries, filling it up with images etc but I wanted to keep is simple and as you have to be online for this to work I figured I’d simply link to the popular CDNs.

So – I wanted a responsive design that would work well on the mobile phone and look nice, be expandable with ease – and that comes from the combination of JQuery and  JQuery mobile. In total we’re looking at no more than 4 lines of includes at the top of the web page to achieve all that.

As the web page and socket are on the same machine that simplifies the address link for the websocket – and so what you see in the code generates this page on first use. You are seeing this screenshot from a Google web browser but the phone image looks pretty similar without all that Google guff at the top.

web page[4]

Remember this is just for demonstration but I think you’ll agree it is quite clean. So what you’re looking at is default information in a web page. The page is connected to the websocket – just just does that – and it reconnects if you stop the socket for any reason and restart it. IT has a field that says “!empty!” – nothing special – just default text. .. and 0 – again just default text.  Notice the input box, the slider and the button.  I’ll put something in the input box and move the slider – which is just a test pretending I’m injecting temperature info. I decided for the purpose of this test to keep the traffic down and have the slider not return anything until you hi the button.

Test page view 2

and when I hit the Update button –

test page image 3

As you can see the info I sent out has gone through the websocket connection (and hence you can do something with it…. I made the individual form items into a JSON string (simple – see the code) and sent it off – it came back in – I used JSON.parse function to split them apart and JQUERY to dump the values back into the page.

There are of course a million ways to do this – mine is just one – but it looks nice and is very responsive. My thanks to the various bits of code, to the people who wrote the JQUERY libraries and the help I’ve had from the Node-Red guys for helping me get this far.

At this point of course, expansion is so easy… the code can be tested in an html visual editor – or just a local web page and NotePad++ and developed ad-infinitum. For sliders, buttons and a whole lot more – take a look at jQuery Mobile – the flip-switches look good too.

Colours? Try the jQuery Mobile theme site



I’ve not quite figured out how to add the colours in given that everything is running in a box…. but that’ll come soon enough.

Here is the code. By the time you read this it will likely have morphed into something altogether more elaborate so I figured I’d put it in here before I get carried away. I’ve deliberately expanded the vertical spacing to chop this into blocks for you. Go through it slowly – it really isn’t that hard. The links below show the latest JQuery Google CDNs but if you don’t like Google there are many others.


<title>Simple Display</title>
<meta name=”viewport” content=”width=device-width, initial-scale=1″>
<link rel=”stylesheet” href=””>
<script src=””></script>
<script src=””></script>

<script type=”text/javascript”>

var server = window.location.hostname;
var topics = {};
var wsUriC = “ws://”+server+”:1880/myapp”;
var ws;
function wsConnectC() {
ws = new WebSocket(wsUriC);
ws.onmessage = function(msg) {
var line = “”;
var fromPage=JSON.parse(;
if (fromPage.part1!=””) $(“#part1”).html(fromPage.part1); else $(“#part1”).html(“!Empty!”);
ws.onopen = function() {
ws.onclose = function() {
$(“#status”).html(“not connected”);
function sendMessage(){
// send message back to page in simple JSON format
// example {“part1”:”Hello”,”part2”:”50”}
var toPage='{“part1”:”‘+$(“#txtMsg_1″).val()+'”,”part2″:”‘+$(“#slider_1″).val()+'”,”part3″:”3″}’;
} // end sendMessage


<body onload=”wsConnectC();” onunload=”ws.disconnect;”>
<div data-role=”page” id=”one”>
<div data-role=”header”>
<h1>Websockets Test Page</h1>
<div role=”main” class=”ui-content”>
<h1>Temperature Display</h1>
<div id=”status”>status unknown</div>
<input id=”txtMsg_1″ />
<div id=”part1″>!Empty!</div>
<div id=”part2″>0</div>
<label for=”slider_1″>Input slider:</label>
<input type=”range” id=”slider_1″ value=”60″ min=”0″ max=”100″  />
<input type=”button” value=”Update” onClick=”sendMessage()” />


See next blog item– Websockets Web Page part 2


The Raspberry Pi SD Wear Issue

Raspberry PiReading around the web it is easy to see that SD memory and lifespan are very poorly understood. There are conflicting explanations of lifespan, there are solutions which don’t work because someone didn’t actually test them before writing up … what a mess.

So here’s the deal. SD memory (the type you put in the PI to boot up) has limited write time – SO DOES USB MEMORY.

How long the microSD in your new Raspberry Pi2 will last is anyone’s guess and depends on “disk” activity, i.e. the number of WRITES (the number of READS is irrelevant).

So how to maximise this. It would seem that you CANNOT offload the whole thing to a hard drive.. but you can have the Pi boot up from the microSD – and then do everything ELSE on the hard drive. You cannot power the hard drive off the USB on the Pi as it does not provide enough juice – so you’d need a powered USB hub. This article looks good – I only got as far as transferring files externally so don’t ask me questions on it – but this seems to be one of the better explanations for using an external file storage.

Another way to improve the life of the SD and one that makes sense to me is a RAMDRIVE. That is instead of allowing the Pi to write constantly to log files on your Pi, have it read all log files into RAM at power up – write to the RAM and then on (intentional) power down, write back to the SD. RAM of course, you can write to forever without issue.

This kind of implies reliable power and I suggest you hunt out an uninterruptable supply – you can sometimes use those little phone charger supplies but I have found that some work, some don’t. The easy way, after backing up your Pi, is to try any one you have lying around. Plug power into the supply, plug the supply into the Pi. Watch the Pi on screen and test the keyboard or mouse. Repeatedly remove and reconnect the power to the supply – if the Pi works without any issue throughout this – then you’re probably onto a winner. I have 2 of them that work, 2 of them that don’t.

Ok, so there is a package called Ramlog which does the job of ensuring the logs are only written at power down. I followed two sets of instructions both of which failed part way through because the writer hadn’t actually tested what he was writing down, missing off a SUDO (super-user-do) command or similar. This explanation worked for me.

It would seem that SOME SD memory has something called “wear-levelling” in which the write use of blocks of memory in the chip are evened out so that continuously writing to one block ACTUALLY doesn’t happen as the wear is “spread” – sadly trying to find out how well this works and with which manufacturer’s chips it works – is something akin to dabbling in witchcraft. There is just so much rot out there so personally I’m not counting on it.

Oh and how do you tell if you’re reducing the number of writes – less or no flashing lights on your Pi.

I hope that helps. I’m coming to the conclusion that for long term use an external drive might be a good idea but I think I’ll wait a while until someone comes up with a package or batch file to make this nice and easy – meanwhile Ramlog seems like a good compromise.

About the only thing I did notice is that my SD usage according to WEBMIN before I installed Ramdisk was 3.5GB and after it was 7.10GFB but that’s clearly rubbish – it would be interesting to see it anyone else gets any “special effects”.


Slimmer Raspberry Pi 2

In the process this week of producing a new new Raspberry Pi2 with just the stuff I needed on it I thought I’d have a go at removing unnecessary programs from the Pi – that is the ones that come with it – after all the Debian installation from the NOOBS package is designed to please all.

I have not and never did have a use for the Wlfram engine but I had no idea how much room I’d save – was it even worth removing?


Between Wolfram-engine, minecraft-pi, scratch and sonic-pi I just saved 584 Mb. Now if you’re using an 8GB microSD that is a significant chunk! I’m using a 16GB but I’m still happy to gain that chunk back.


Bringing the Pi into the PC world

So you have your sparkly new Raspberry Pi and the first thing you need to do is remotely access it from the PC… and so you install TIGHTVNC… and put that on the PC and they talk to each other and…. no clipboard…

This link got me out of a jam. Now I can use either TightVNC or UltraVNC on my Windows PC, talk to the Pi and copy and paste.. Indeed thanks to ”Input Director” on the PC, I can copy and paste between a number of PCs and the Pi. Now that’s civilised.

If only I could get Filezilla on the PC to let me change FTP permissions on the Pi that would be even more civilised.