It has been a very busy week for us here in Spain – what with partying and what-not, so I’ve not had as much time as I would like to develop my JavaScript object skills, however, I’ve managed to get much further with a project I’ve been working on in the background – a little LCD display.
I wanted to simulate a real LCD and you’ll have seen in an earlier blog entry that I managed some JavaScript code to do this. Well, I’ve had all SORTS of unexpected issues, now resolved and I’ll detail here what I’ve done.
So first off, I was having some interaction with other objects on the page – resolved – but an issue that came to light when I got here to Spain – with my little Raspberry Pi that is running this stuff left in England – was that of loading external items – for example, images and fonts. Designing items for Node-Red Dashboard is slightly different to working on an empty web page as you’re basically working inside a DIV – you don’t have the luxury of ONLOAD and HEADERS etc. and I found myself getting annoyed with my web seven-segment font not working when first loaded – i.e. initial text would show up in a default font because of the time it takes to load the web font from England. I could not understand why this would always happen – surely there’s some caching going on? But if you read the comments in previous blogs – that apparently is not the case as the templates in Node-Red Desktop add a timestamp to URL calls which kills the cache. Well, not ALL of it but certainly makes life difficult when trying to load up fonts and images.
Anyway, the first idea that came out of various comments was to URL encode the fonts – and of course, wanting to keep with good practice I put all of that into a separate style sheet. NO! The page has to load the style sheet, so the problem doesn’t go away. The answer lay in having the font inline – now that SOUNDS messy but actually it’s not that big a deal especially if you don’t have wrapping turned on – it’s just a one liner – albeit a very long line. The breakthrough came when I read a suggested link which took me to Fontsquirrel – having initially used this 14-segment font for my LCD only to find that the capital S was a bit naff and the spacing was NOT identical on all characters, I was then quite excited when I found an excellent WOFF file called segment14 here. Mono spaced and with a decent S.
Lovely, but of course this still had the same issue with loading – not a big issue at home but as soon as myself and the source were separated by a plane trip – the loading issue became apparent. Anyway, Joe Lippa and Antonio (Mr Shark) have been feeding me links and it turns out that FontSquirrel can load up the font and return a CSS file with the code all inline (they don’t appear to have 7 or 14 segment fonts so it is as well you can upload fonts you have found – and have them converted) – so no external loading. In the data that came back was a WOFF data block and a WOFF2 data block – I ditched the former as the latter works just fine. I’ve put links to fonts here – I’ve modified them for my own use but you should know I’m not claiming any ownership of the fonts – others have done the excellent work on designing the fonts.
With the font issue resolved I set about making a basic object for a display (which will no doubt mutate – but right now can be dropped into a template in Node-Red to show lines of simulated 7-segment display in a variety of colours. Methods can be invoked to updated the two lines and to change the colours – both background and foreground. I managed my colours by trial and error but you can of course change them and add more.
This, then, is merely the first stage – everything works – you can change colours and text… so much more can be done – choice of how many lines, how many characters, what font size etc. but all of that is easy to add once the basic idea is in place. This is going to be added to my armoury of gauges and shapes available in Node-Red Dashboard – I’m playing with the GITHUB beta right now and it is coming along VERY nicely – now that the actual template width and height can be tweaked.
Anyway, there it is… if you want to play with this – grab the code and paste into a template via the “import clipboard” option (top right – 3 bars)– yes, it’s big because of the font – but very do-able. You can replicate this and make two or more displays but more likely the object and font should be split off into another template if you plan to do that.
Note that in my test inject nodes I am now injecting JSON, not text (see image above and note the {} which means JSON is selected – then I’ve filled in some standard JSON text to adjust two variables) – just as easy but more powerful as you’ll see in the text injectors.
When this information comes into the node it is processed as such…
(function(scope){
scope.$watch(‘msg’, function(msg) {
if ((msg.payload.lcdm1!==undefined)&&(msg.payload.lcdm1!==undefined)) lcd2.update(msg.payload.lcdm1,msg.payload.lcdm2);
if (msg.payload.colour!==undefined) lcd2.updateCol(msg.payload.colour);
});
})(scope);
Right now I don’t allow on or the other line to be processed but only both at once – but that would be easy to change.
If you look into the code there are two methods (functions) of relevance once the object is defined – this.update and this.updateCol – which are merely setting internal variables then calling the update function. The text update function could easily be split into two.
At the very end, the LCD is created, needing only a DIV to work in..
var lcd2 = new myLcd(“newDiv1”);
I called it lcd2 as I also tried putting several on a page to ensure there was no interaction. They need unique names and unique div names and several will co-exist no problem (though it would make sense to have only one copy of the object definition if you want to do the job properly).
See previous blog entries for related info on LCD simulation (alpha blending of the all-segments on character under the actual text).
Specific questions are invited in the comments area (not 2 years later please).
At the risk of banging on some more about js, css, font resource caching + additional HTTP requests for those resources + the problems in this area..there’s an idea that dceejay added on https://github.com/node-red/node-red-dashboard/projects/1 “Allow adding of css / js to header (globally)” that could go some way to solving these issues if it gets taken up.
Potentially even better is “Re-architect framework to allow 3rd party addons/widgets” which is on there too. This one would ideally enable better extension / introduction of custom dashboard nodes rather than having to go down the template node route and having to work around the issues with this.
There is one idea that dceejay did mention to me at one point related to a JS include I was having an issue with which hasn’t been mentioned here yet. He made the suggestion that I add the resource to the /node_modules/node-red-dashboard/dist/dashboard.appcache to prevent the cache busting behaviour I was seeing. I’ve not tried this but I believe the idea is that you no longer need any reference to the resource in a template at all and it’s automatically included into the dashboard page by the manifest.
If you take a look in this file you’ll see it includes images, js, css, fonts and html so it’s effectively wrapping all required dashboard resources up into a single manifest and the nice thing about it is that resources in here get served from the local cache really fast.
Although a potential solution for some use cases, this did feel like a bit of a hacky solution to me because the dashboard.appcache file will get wiped/overwritten whenever node-red-dashboard gets upgraded and I’d hope that the earlier ideas on the “things to do” list will introduce a better solution at some point. That said, it’s another option right now.
So really no great solution – I don’t fancy going back to files that get wiped on update… also if different parts of the UI use different fonts you end up having to pre-load the lot… but we really do need to be able to load up images and fonts reliably BEFORE the Node-Red template code runs and have it stick around.
ah well we agree manually editing dashboard.appcache doesn’t really have serious mileage. I just thought I’d mention that idea to get it on the record here but I guess we’re currently “where we are” inlining stuff directly in a template until someone comes up with a better idea or the platform develops further.
Peter, i remember a previous image in which you added glow on the sides of the lcd screen, simulating the real glow that lcd have when you turn on the backlight… planned feature? 🙂
about injecting json, take a look at this video, lots of other good info on node-red 0.16: https://www.youtube.com/watch?v=qJ4QB7i_0wk
the json extraction via jsonata is cool, too! Without using javascript 😀
http://jsonata.org/
(details from 3:00 of video in my previous comment… you need to pause A LOT to get the info…)
HEY!! That’s good – the CTRL CLICK THING!!! I’ve updated my home system, I’ll update the one here in Spain. Very good.
oh, that i’ve noted when seen in changelog, a month ago… i think i told you on skype, at the time… the other things were less evident… 🙂
p.s.: what about the glow? 🙂
I could put that in – the method is surprisingly simple….. when you define a box etc… you can DRAW the box or you can make a MASK. Having made the mask, you then draw the box with fuzzy edges. You get the shadow on the inside, but because this is now working in a mask, you don’t get the OUTSIDE shadowing… that’s basically all it is. But it isn’t quite correct. usually on an LCD you get a slight shadow but then some glowing at either edge. That didn’t prove QUITE so easy….
I then thought of using images but with the loading issues I’ve had I’m somewhat averse to using more images in templates in Node-Red Desktop until we get some clarity.
I read your latest playing with gauges and now with LCD. All these looks perfect – great job! Wil be these things accessible as node-red components somewhere, please?
Hi there Slavko. Glad you like what I’m doing.
So the answer to your question, for now, is no. I’ve not real interested in supplying end products for people to take. I’m more interested in sharing information as I gain knowledge, which in turn often leads to people writing back in to tell me what I’m doing wrong, hence improving my knowledge so I can do a better job.
You’ll note that many of these articles are updated in the light of new knowledge. Having provided a basic mechanism, I would hope others would find innovative uses for this beyond what I’ve achieved so far.
The LCD for example is absolutely not an end-product and I do not own distribution rights, for example, for the fonts. Anyone using it will want to use what I’ve done (which in turn came partly from my own developing knowledge and partly as a result of great feedback) as a BASE for whatever they plan to develop.
I don’t think it gets too much easier than pasting something into Node-Red but I’d be very surprised if anyone uses this as-is.
Today I will do some more work on this blog entry with a little more detail.. Had I turned that into an end component I’d then be stuck with supporting something that would soon be out of date. I have absolutely no issue with someone else doing this if that’s what they wish.
For me I am trying my best to take the basic components of these ideas, perfect them as far as I can in order to then move on confidently to other aspects. LCDs and gauges are just the beginning.
There are still issues to be resolved. In the gauge for example the little button over the two needles shows up 95% of the time but on a distant connection STILL does not ALWAYS show – and until this week I could not get it through my head why something that is cached would not always, eventually come up and stay put – but if one reader is right about resources in Node-Red dashboard, there seems to be a mechanism that helps PREVENT caching.
We need to understand that perfectly, how it is beneficial and when it isn’t, how to work around it. That will happen not by providing drop in blocks for people but by encouraging them to take my stuff apart and improve it, hopefully returning feedback in here and by email as some folk prefer so that I can effect constant improvement.
I consider much of this stuff to be an evolving work in progress…. well, certainly for me anyway.
Regards
Pete.
Thanks for comprehensive response 😉
I fully understand your idea about (not) publishing foreign work. In my computer life i go throught 8 or 9 programming languages, but JavaScript is not in my list, i know only same its basics, then I ask, because for me this LCD suite of components is horrible complicated 😉
I suggest, if you are planning to use Node-Red, that you gain familiarity with Javascript. I’m a C programmer and it is not THAT different.