Some may be wondering if I’ve gone off on holiday, as I normally post here on an almost daily basis. Well, if you regularly read the comments sections you’ll see I’ve been heavily involved in answering questions, but more importantly I’ve taken one step back and two steps forward on this gauge thing. Read on.
But firstly – WIN SOMETHING! You’ve probably heard me talk about my pal Peter Oakes in Canada – he has an excellent YouTube Channel in which he talks about IOT – well, he’s just launched a competition and the prizes look pretty damned impressive indeed. Take a quick looks over here – you might want to participate…. https://www.hackster.io/contests/IOT2020
Thanks: Before going any further, I’d like to take this opportunity to thank some people in there without naming names – for several donations received this week – you have no idea how this helps motivation, knowing that your work is appreciated. Thank you, guys!
The Gauge: Now - regular visitors will know I’ve been doing a lot of work on Node-Red-Dashboard-compatible widgets recently as I really do think this is the way forward for mobile access to DIY home control systems and also for desktop and wall access via touch displays - but one thing that has bothered me up to now was the clumsiness of some of my coding – global variables all over the place, a lot of opportunity for interference from one node to another etc. Everything just works but the perfectionist in me wants to “do the job properly”.
So earlier this week I took a step back, seeing what “proper programmers” had done with turning these widgets into “objects”, with clean interfacing to the outside world. Well, trust me, it isn’t that easy. I asked around as to how I might encapsulate my Javascript into an object, exposing only those bits that needed to be exposed. No-one I know well enough to ask for help, could help in this particular instance! So, I took a step back, grabbed some coffee and thanks to my friend Google, I’m pleased to say I’m getting somewhere.
Shortly you will see my gauge once again featured in these pages but the way it is done and bits you’ll need to look at have been dramatically changed as has the chance of unwanted interaction – and the overhead has been substantially reduced due to a series of insights which have followed each other – and some of them I’m sure some others have missed. Read on.
So first off, I made a gauge with pretty colours – you’ll see it elsewhere in this blog. It works – why take it any further?
Well, the gauge features nice, smoothly moving needles and other bits. What’s wrong with that? Every time the needle is updated in the existing design, the entire gauge has to be re-drawn. This is not uncommon but just felt wrong to me. To tackle this I had to understand LAYERS. It turns out that if you make the position of CANVASSES absolute, you can put one on top of another (you also need to understand zIndex but that’s easy). If you can do that, then you can draw the gauge backdrop including the text and pretty-coloured segments once only on the bottom layer and only then clear and update the top layer, say, 50 times a second with needle updates etc. That saves some calculating.
But now I needed two CANVAS items which looks a little odd when setting up so I worked out how to create both, totally in Javascript. That led to another problem, in Node-Red you can’t just put your CANVAS elements in the top left corner of the page BODY – it won’t work. I then reasoned that both CANVASSES could sit inside a DIV on top of each others – and indeed they can. So now all that is needed in HTML is to define a DIV and the Javascript will do the rest.
That still left me with a mass of messy Javascript - and the thought of explaining what was and what was not relevant to end users in the blog here was keeping me awake. That’s when I started looking into this whole object encapsulation thing. 2 days ago that was a distant world, something for the future. Today, I wonder why I waited so long to take the effort to learn. I had to learn some new tricks in the process – however, when you eventually see the new gauge, setting it up will be as easy as this.
var gauge1= new petesGauge;
gauge1.init({
container: "myDiv",
});
gauge1.value1(90);
Define a gauge, point it to a DIV at which point it appears magically – and then dynamically set a value which will slowly change in front of your eyes. No other information exposed to the outside world, no need to do anything other than set up an empty DIV and add a link to the Javascript compressed library.
Part of the magic here is in the encapsulation I’ve learned to handle – but also of course there are many defaults. In the top section you’ll be able to override defaults and turns things on and off if you want – and in the bottom section there will be several settable items – the value of two gauge needles, the value of set points, visibility of LEDs etc. All easy to use options.
I’m on the right path – I understand what I’m doing but I’ve only so much time to code this up.
If anyone fancies themselves a whiz at JS Objects, I’ve fathomed out how to get and set global vars in the object with simple methods – no problem but can i hell interact externally with internal vars – happy to have a chat with anyone interested in enlightening me.
jsFiddle helped me get this far but the best tool for the job IMHO apart from lack of formatting – is CodePen – you can make code changes dynamically and see changes in real time – what a difference this makes. Oh and I realised the one thing missing from my LCD display (not shown above) is the overspill of side lighting typically seen on real LCD displays. That’s coming soon.
New Toys: I’ve also discovered (thanks to MrShark) Atom this week which promises to be a great editor both in Windows and on my little SBCs. My MINT installation, apart from falling to bits visually after a “sleep” operation, continues to function well on the laptop and I’ve received some nice new DIN rail brackets from China which can screw onto the back of a perspex sheet for mounting boards and supplies. More on all of this later. Incidentally for those wondering, my testbed wireless Orange Pi Zero and twin NanoPi M3 units are still sitting on the bench, still working perfectly despite disconnecting the WIFI several times deliberately.
Desktop Touch Controller: And on another subject, how is my Desktop Pi Touch Controller doing? For some time 
now I’ve had a 5” touch screen attached to a Raspberry Pi 2, using Node-Red Dashboard as a simple controller for my office – to turn lights on and off and keep an eye on temperatures etc. Works a treat using Chromium in “kiosk mode” – but two things have annoyed me – one being that menu from Node-Red Dashboard – the second being the ability of the browser to fail occasionally due to connection issues and put up a stupid message instead of trying to reconnect. Well, I may have cracked both of these as for the last few days the little unit has been sitting there rock-solidly doing it’s job.
The annoying Node-Red-Dashboard unwanted menu problem (well I only have one page on this unit – why do I want a menu) was solved simply by a reader who wrote in to suggest this added to the style.
#toolbar {display:none;}
Yes, that’s it – simple as that. Gone – space retrieved.
The second came from here. http://www.labs.bristolmuseums.org.uk/running-google-chrome-in-kiosk-mode-tips-tricks-and-workarounds/
So I have a couple of templates on the page – one at the top with my CSS and some useful Javascript – the second at the bottom.
I’ve added this to the top
<body onClick=”location.reload()”>
and this to the bottom.
<script type=”text/javascript”> $(function() { setTimeout(function () { if($(“#VisitorStoriesHelpText”).length>0){ $(‘body’).attr(“onClick”,””) } }, 1 * 1 * 1000);}); </script>
And yes, I know that body code is really not appropriate in a Node-Red template – but guess what… it seems to work. I’ve not had an issue with the display for days now. May be a fluke of course – but fingers crossed.
