Category Archives: jquery

A Deep Learning Weekend

Gauge by Peter ScargillWell, this has been an interesting journey (a deep learning WEEK more like it) as I’ve been working on making my own widgets for Node-Red. I thought I’d share some of the things I’ve picked up. Experienced JavaScript object users please look away now. Those not interested in JavaScript look away now.

Note: The original video for this is out of date as I have learned more – the new video has some extra code, too – here it is -

C Programmer: As a life-long C programmer, I came into JavaScript with some trepidation. Like alternative universes, JavaScript may look similar to C – but it is not the same – and that led to all manner of silly mistakes over time. However as I see a tiny light at the end of the tunnel, I have to say, it was worth the effort. Despite being a client-side interpreted language, it really is great fun to use.

The gauge: Well, as long as you keep it simple that is. When designing my first attempt at a gauge for Node-Red, I realised that a typical gauge operation goes like this:

Some features such as the background are typically set in an init function once only (and as such it would be better if the user is not involved in this. Other features such as needle positions are set dynamically and will change during operation.

This is generally handled one of two ways – either by setting a value and then calling an update function, or by running something in the background which checks for value changes so all you have to do is change a variable. On many of the gauges you’ll see flashing lights and smooth movement of gauge needles – that implies something running constantly or at least checking for changes and running when change is needed.

Concerns: This worries me as there can be quite some overhead in updating an entire gauge, umpteen times a second. So I decided that what was needed was a layering system as you might find in Photoshop – such that I could lay down the basic design and background of a gauge once only then dynamically clear and write to a top layer whenever changes are required. Such changes might include the state of a flashing light – or a needle not being where you want it, requiring successive incremental updates until the needle or needles do get to be where you want.

I then started thinking about variables and functions (methods). Did I want to update variables such as the needle pointer directly (direct variable manipulation) – or did I want to manipulate the input value before passing it through (that needs  a method/function).

That led me to create, as you will have seen earlier, a large blob of JavaScript for my gauge, including initial setup – then a timer-driven function to update the gauge regularly. That was stage one.

HTML5 Canvas: In the process I discovered (by looking at what others had done) that HTML5 Canvas (which really is easy once you get past the initial learning curve) Is a great choice. What did not come so easily was the realisation that the canvasses themselves are indeed transparent and you can layer one directly on top of another – just like Gimp or Photoshop layers. That led me to split the job into two – the overall backdrop which remains fixed throughout operation – and the top layer with my LEDs, needles and set points on it.

Adding a bunch of variables to this for setup and defaults brought me out into a sweat as I struggled to imagine how two or more gauges would interact. And THAT led me onto objects – something I’d never really touched in JavaScript before  – specifically to wrap up my entire code into a definition – which meant I could then simply create instances for EACH gauge without worrying about all those variables interacting. That was the point I last few days in deep learning.

Having wrapped everything up in a bulletproof package I was then faced with the question of how to access required functions and data externally. The obvious way (and the one I’ve adopted) is a series of callable functions for example:  mygauge1.needle1(50);

In the process I had to learn how to hide functions within the definition and make functions accessible externally. That was easy enough.

Here is a simple example – the assumption is that you have a jQuery link (to update a div) and a DIV called “fred”

1.  function myobj(){
2.  this.v1=5;
3.  init=function(passThis) { setInterval(every25ms, 25,passThis); }
4.  this.doubleit=function(r) { this.v1=r*2; }
5.  every25ms=function (passThis) { $("#fred").html(passThis.v1); }
6.  init(this);
7.  }

8.  brian=new myobj;
9.  //brian.doubleit(12);
10. //brian.v1=7;

There is a lot to this – and I’ll be using the word “this” a lot – so for clarify I’ll use italics for the special meaning of this.  It may look strange at first but if you follow me it soon won’t.

Definition: So the point of this was to create a test object definition – an object that would simply put a value in a DIV (I know, slightly overkill but I was trying to prove a point).  We start off with the definition in line 1.

Take a look at the code above – there is a lot in here despite their being only 9 lines. I figured any more and people might run away.

Firstly on line 1,  we define a type of object. A “myobj” type.  I’m not making anything here – just defining it (ends in line 7).

On line 2 – we define an externally available variable – v1. “this” makes it accessible externally (try removing “this”).

In line 3, we are defining  a function called init.  When the instance is created on line 8, init will be called internally (by line 6) and will start off a timer which will run every 25ms and which will call an internal function called “every25ms” (line 5), passing this to it. Do not get hung up on this yet.

Line 4 defines a function (again made available externally by “this” and called “doubleit”,  will double whatever is passed to it.

The  “every25ms”  function on line 5 which is to be called every 25ms by init… simply prints out the local variable.

Line 6 calls init (which is NOT accessible externally) when the instance is created in line 8 - to initialise the instance and start off the timer – this saves running an init externally.  From line 8 onwards,  the function “every25ms” is called every 25ms to put the value of this.v1 onto the DIV.

You’ll see “5” appear in your DIV if you test this somewhere – that’s the initial value. Note "passThis" – (arbitrary name). Because the function init is private - I don't prefix it with "this" – when it sets the interval timer it has pass to the timer function the outer “this”… - so I pass "this" in the init call.  This is new as a result of feedback in here suggesting a private “init” function that was no accessible externally. In the original version I used this.init() - and passing this worked. Removing that resulted in the timer callback function using the wrong "this".  Trace it through and it makes sense. The callback function needs to know about the outer "this".

Line 8 is where things start to happen. At that point, the instance (brian) is created and the timer starts all on it’s own -  thanks to the internal init function.

So far so good. How do I now interact with that variable v1? I wanted the choice of updating a variable or calling a function. The two commented lines are two ways to do this – their operation should be self-explanatory.

Line 9 simply won’t interact with local functions inside the definition and we don’t want them to – we want interaction with specific functions in each instance of the object – like “brian” for example. And that’s where “this” comes in. Add “this” to a variable name or a function name – and it becomes accessible to the outside world. For example you CANNOT do brian.init() or worse, brian.every25ms() and that’s a good thing!

Scope: So using this technique allowed me to keep all variables and functions private and only “expose” those I needed. LOVELY.  If I only wanted to use function and not expose any variables – I would not use for example “this” as a prefix to v1.

These ideas then form the basis of my current gauge. I can built a massive machine with lots of variables and functions inside and have no worries about interactions with other gauges because I’m only “exposing” stuff I want…. and gauge1.v1 has nothing to do with gauge2.v1

Of course I’m assuming that was as clear as mud -  but if you are interested, go have a play in this CodePen where I’ve left the code. See the number that comes up in the working area – try un-commenting those functions (methods) in lines 9 and 10. See what happens if you replace passThis.v1 with this.v1 or just v1.  See what happens if you remove references to this altogether. CodePen is great as changes run immediately and safely.

Merely experimenting with the code in that CodePen should do what it did for me – clear a massive amount of mental fog.

Simply creating v1 – and removing this and passThis in referring to v1 – leads to disaster – v1 is accessible externally on it’s own –so kiss goodbye to multiple instances.  But the same code using “var v1” leads to a save internal v1 NOT accessible as “brian.v1”. Your choice.

My new gauge object is coming along nicely – and a minimal installation involves little more than a link and a couple of lines of code – stunning how these simple ideas change the whole game.


The Ongoing Knob

jQuery KnobI refer you to this article if you’re new in here - – we’ve been having a lively discussion and lots of exciting new possibilities coming out of a chance discovery of the JQUERY KNOB and what is now our ability to integrate that with Node-Red. The purpose of this is to increase the usability of the web-based Node-Red Dashboard by introducing new and useful controls.

I won’t go through the history here – it’s all in that blog entry which you should read first before getting into discussion here.

So now we can create a touch/mouse-driven knob for Node-Red Dashboard, in a template – and we can replicate as many of these as we like in a tab. Many thanks to those who helped get this off the ground.

But once the novelty wears off, we find that we need more work on this for some scenarios. The knob can be coloured and it’s shape and size can be changed but what about that value in the middle. Early attempts at adding a “%” sign or similar failed miserably – until I actually started looking at the docs for the knob – at which point some things became clear.

I can think of two immediate modifications to the basic knob which come in as useful – the first is the addition of a percentage or degrees character – the second is slightly more complicated. I want to use the knob to show a time in hours and minutes and to let me alter that – worse I want the time to increment in 15 minute intervals – giving me back a value in minutes while SHOWING HH:MM -  so - how to do that:

It turns out to be surprisingly easy if you’ll bear with me.

So firstly the easy one – setting limits and steps can all be done in the input definition.

<input  id="jqueryknob{{$id}}"

        value="{{msg.payload ?  msg.payload : 0}}"

If you refer back to the original article – the input definition is in there and I’ve simply lifted that and added 3 more lines – so now we can have any start and any end values and a step – in my case the number of minutes in the day. So how do we get from THAT to the display above right.

It turns out there is an extra bit we can shove into the code… a snippet from the original blog follows with something new – two examples here.

$("#jqueryknob" + scope.$id).knob({
    'format': function (value) {
        return value + ‘%’;
    change : function (value) {
    release : function (value) {

The above adds a percentage sign to the display WITHOUT affecting the actual output from our template – you could of course add any other symbol. The example below though looking more complex is just formatting to give me my HH:MM format – again without affecting the output of the template which in this case is in minutes.


$("#jqueryknob" + scope.$id).knob({
   'format': function (value) {
        return ("0" + (Math.floor( value / 60))).slice(-2) + ":" + ("0" + (value % 60)).slice(-2);
    change : function (value) {
    release : function (value) {

So that one addition above allows you to control what you see in the text of the knob without affecting the actual value.

I suspect there is far more to be gained from further examination of this widget. ANGULAR also has a knob - and that has some nice features including subtitles. Perhaps we can look at this one sometime!

For now here is the latest update of the actual code used in my test knob – set the template to 6*6. I’ve removed a line that wasn’t doing anything and changed msg.payload to msg so in future we might add more stuff in there (thanks Dave).

Don’t forget to create a template with the CSS in it – and make sure your template tickbox settings are like this.


Template tick-box settings 




I wrote a while ago about using web sockets as against something like NETIO for controlling the home – most folk liked the article but I think part of it was a little complicated – and at the time I’d not really thought it out to make it as simple as possible.

So, this morning I started again and now I have a decent and easy way to make control interfaces from the mobile phone – to ESP boards. I won’t go into MQTT in detail here – I’ll assume you have an MQTT interface of some description on your WIFI boards – if you need more info on that, look elsewhere on the blog.

jquery mobile themesI’ll also assume you have node-red running somewhere. In my case I have a Raspberry Pi2 sitting in a corner with battery backup, running node-red, MQTT and Apache web server.

So – in order to make a half-decent looking phone interface, I decided to go for jQuery Mobile – it is cheap, easy to run and there is a theme generator.

I went along to and made myself a set of THEMES – that is some CSS. You can’t get any easier – you just drag the colours onto the various items – save the ZIP file – and then refer to the THEMES folder in your web page.

Here’s what I did – you might want less colours, more colours, different colours etc.… you  can change all aspects of the jQuery Mobile interface which is basically a bunch of items that work well on mobile phones and tablets. Click on these images for larger versions.

So – what’s needed then is a web page…. that shows a series of buttons (jQuery Mobile), a means to send off button presses to Node-Red (web sockets) and some means of then controlling things (MQTT).

In my case I put the web page and dependencies in a folder within /var/www on my Raspberry Pi (could be anywhere – a Windows PC, whatever).  I can access these pages externally and hence there is a password on the folder – that is done in my case with an.htaccess file but you might have other ideas.

The page should begin with a header for accessing jQuery, jQuery Mobile and the themes etc.…  I figured as the phone has to have an Internet connection to work anyway, there was no point in filling up the Pi with libraries other than my custom theme..

        <meta name="viewport" content="width=device-width, initial-scale=1">
        <title>Simple Controller</title>
        <link rel="stylesheet" href="themes/" />
        <link rel="stylesheet" href="" />
        <script src=""></script>
        <script src=""></script>
        <link rel="stylesheet" href="themes/petes.min.css" />

phoneAnd so above, in the HEAD section of the web page (which I simply edit with NodePad++) links to the local theme and remote jquery. That local stuff all comes in the zip file from the themeroller site – well it does if you make the title when saving “petes” – you might want to call it something else.

Here’s my test page which works equally well on a mobile phone as in a web browser  - I’ve checked this out in Chrome and Edge and on my Android 5 phone – identical results.

As you can see I’ve gone for gross, using matching colours (more or less) for the colour controls I’m actually firing off.

The only difference between the buttons is a simple addition of data-theme="g" or whatever letter – if you look at the theme image at the top, as you add more themes, they start off as “a” then “b” etc. We’ll see this code later.

Rather than put a ton of code in here – here’s a snippet with the entire page.

You’ll see the header information followed by some setup for web sockets.

The basis of my controller as you’ll know if you’ve read Home Control 2015 in this blog, is to send MQTT data to my ESP8266 boards, so for example to control the RGB output on GPIO0 of a board called RED1,  I’ll send the following…. the topic would be red1/toesp and the payload would be for example {rgb:0,255,0,0,70,1}

The above means – send a message to board red1 and tell it to fire out a WS2812b signal on GPIO0 to turn 70 LEDs on fully bright red.

I wanted the web page to be as simple a possible – adding to a button something like….


And that is exactly what I’ve done. But firstly the mechanics of the Node-Red web sockets interface.

In Node-Red, I have this:


Simpler than it looks, I’ve dropped in a WS input module (standard node-red node unit) and out – and connected them together.

the input listens to “/myapp2”  - could be /fred  or anything you like to call it.  Yes folks that is ALL there is to the setup – but…. assuming my web page connects to this – I need to do something with incoming data (in this blog I’m ignoring firing data back to the page but that is also easy – I referred to that in the last blog – the point of web sockets of course is that this is a continuous connection between the web page – and node-red web socket control.

So what I need is an incoming MQTT message and topic – and that needs firing out to MQTT to control things. The only bit of code here is in “process commands” – this is a function module (drag and drop) and this is what I put in it.

var jsondata=JSON.parse(msg.payload);

if (jsondata.topic)
    return msg;

Simple enough – any incoming information is assumed to be in json format and is “parsed” (built in function) so that I can extract a payload and a topic to simply fire off to MQTT and on to my boards.

As I’m always going to need “/toesp” on the end of the topic – I add it in here rather than needlessly replicate it in the web page.

The web page itself needs to fire out something like (in this case)….


The inner braces are for my boards…

So – my board ends up with:

topic:  red1/toesp

payload: {rgb:0,255,0,0,70,1}

I wanted to keep the actual buttons as simple as possible so there is a function in the web page to glue the topic and payload together.

function send(topic,payload)

and so all we need now is the connection between the web page and node-red web socket interface (simple as they’re both on the same server) hence if you look at the web page you’ll see a definition for wsUriC which is then used in wsConnect() which is called on page load. This makes the connection.

ws.send() sends a string to Node-Red and my function ensures the string is in the right format.

A typical button looks like this..

                        <div class="ui-block-a" ><input data-theme="a" type="button" value="red" onClick='send("red1","rgb:0,255,0,0,70,1")'></div>

Note the very simple onClick function call to send a command off to a particular board…. and if you study the web page example, putting aside the formatting commands for jQuery Mobile (which you can learn all about here  - there is WAY more than just buttons available to you - but I’ll leave that to the reader to explore (or not).

So I press a button on the phone – and the light comes on or changes colour or whatever. There is no feedback – that would be covered by a call-back function in the page and jQuery to alter the shape or colour of elements accordingly – really quite easy once you get started. I thought of putting that in here but I’ve probably given you enough to think about as it is.

Hope you find this useful. When the connection is working incidentally you get a little TICK at the top of the page – or a little cross if not.



p.s.  If you’re wondering what all this cave reference is about – head over to

Coming up soon: I hope to review the inexpensive NEXION touch display (one is on it’s way) to make a nice wall-mounted thermostatic control – which will talk via serial to an ESP-01 which in turn will control a relay and have a DHT-22 chip for temperature sensing – and Node-Red for background timing control – and of course I will have phone-based monitoring and over-ride based on code very similar to what you see here.