Well, 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 - https://youtu.be/mTAPrvB1EeI

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.

When testing Node-Red, the common INJECT node is invaluable. Indeed it is just about the only way to instantly inject information into another node. Here is a typical example.

It doesn’t get any simpler than this. Here I have merely dropped an “Inject” node onto the Node-Red working surface along with a “Debug” node. I’ve made no changes to either of them.  Note that “inject” and “debug” nodes come as standard with Node-Red.

Correctly set up, on the right of the Node-Red screen, you can see (or make available via the top-right three horizontal bars – view – “debug messages”) a debug window and simply by pressing that button-like item to the left of the inject node, you can put a timestamp into the debug window as such:

Simple enough. Note that this says (in red) “msg.payload”.  In homage I guess to MQTT, the inject node outputs a simple object which deals primarily with msg.topic and msg.payload. You can use these for whatever messages you want.  The debug node by default shows only msg.payload but you can of course change this to show the entire message object.

Note that here (image above) we also see a blank topic (because the unmodified inject node has that as empty – you could put “Merry Christmas” in there if you like. Also included is _msgid which is of no interest to us for now unless you have a specific need for a unit number.

In general then,  you can fire out msg.topic and msg.payload from the inject node.  Instead of putting out a timestamp,  you can put out a string (for example “Hello world”) and this is output in msg.payload.

Expanding the INJECT output

For many purposes, we are done – you know know how to output a value into msg.payload and you can easily add msg.topic to that.  An inject node then can directly output data suitable for, say an MQTT node which needs both msg.topic and msg.payload.

For some purposes however, this is not enough.

In the above image, I need to inject one of two messages into a template. Easy enough, “message 1” as string into one injector, “message 2” into another. But what if we have a string of messages for different purposes going into that template?

On way to differentiate them would be to use topic.

if (msg.topic==”needle1”)  { /*use msg.payload to influence  a gauge needle */ }
if (msg.topic==”lcd”) { /* use msg.payload to influence a display */ }

Another way to do this is by putting a function node after the inject node…

msg.needle=msg.payload;

The output of this then, is your message sitting inside msg.needle instead of msg.payload.

Do-able but two things about that. Firstly you still can only output one message at a time and now you have the extra work and additional screen real estate used up for the additional function node. Not very elegant. If that works for you – stop here.

So what if we want a simpler way that may include sending multiple messages out at once.

In the inject.node you can’t change the name of “msg.payload” – but you can change what it outputs – a number, a string etc.. and in this case of particular interest, JSON.

Let’s take an example. Let’s say that by pressing the test button we want to set a needle value to 10 AND we want to send the message “hello” to an LCD display in our gauge.

This LOOKS like you are sending a string of text but look what comes out – when you view the debug payload:

Not a string, but an object  - but how do you make use of this? Simple. In your template – or function or whatever you are firing this message into:

if (msg.payload.needle!==undefined) { /*make use of msg.payload.needle */ }
if (msg.payload.lcd!==undefined) { /* make use of msg.payload.lcd  */ }

This way, directly from a single inject node you can send either one, or several messages at once. The check for undefined means you don’t always have to send all of them.

Hence, for example, in testing my gauge, I can have a number of buttons testing  different parts of the gauge and one of them sending messages to both lines of the internal LCD at once without making a big mess of the screen. In the example below, the bottom two injects each send 2 different commands to the gauge when pressed.

But what about existing objects

Another way to send multiple messages through the injector allows you to make use of existing global objects…

In this example, I happen to have an existing object called “thermostat” – which can be referred to as “context.global.thermostat” though the more modern way to do that is by use of global.get and global.put.

Armed with the above, which contains in this case lots of information about the state of my house… I can send that – either manually or of course in a timed fashion, to the debug node.

A little confusing at first until you notice the three dots at the bottom… which mean “I’m only showing you some of the result. Click on them and..

Far too much information to display here – but I think you get the point – though msg.payload looks restrictive – in fact you can send a whole load of information thanks to the ability of the INJECT node to carry an object in msg.payload.

In this case, if you set DEBUG to look for msg.payload.desired you will indeed see a result of 23.

Can I create an object? Sure:

In this case – the content of the injector is irrelevant. Just drag it onto the screen.  Here we have (for the sake of it) two debug nodes – one is looking for msg.payload.actual and the other is looking for msg.payload.desired.

And here are the contents of that simple function node in the middle.

msg.payload={
desired:25,
actual:23
}
return msg;

Debugging:  Keith Howell wrote in to remind me about node.warn and node.error – two very handy debugging functions. Here’s an example of use…

Again out of sheer laziness I’ve used the inject node on the left straight out of the box as it were. On the right the orange “test” function – again – drag from the left… double-click to open and enter the following:

node.warn("just info, really!");
node.error("ooh errr!");

and the result in the debug area when you press the timestamp button…

Isn’t that handy – the only difference here being the colour – yellow for warning (I’d have used blue but hey ho) and red for error.  Using this instead of a debug node could save a little real estate on the screen in some cases.

Just a few odds and ends… we’ve arrived safely in Spain and I’m not getting quite as much blogging time as I’d like as there are repair jobs to do – but I managed a little item on Node-Red earlier – I’ve had people in here asking for simple-use examples – so that’s the first.

Gauge Progress: I’ve not forgotten my HTML5 Canvas gauge – it’s coming along nicely but along the way I’m hitting minor bottlenecks on image loading – and image pre-loaders are not helping. Most but not all of this came to light when I moved thousands of miles away from home with the attendant delays! I’ll return to this one soon.

Node-Red Menus: Regular readers may recall from earlier blogs that I’ve been griping about the menu in Node-Red being there even if you have only one page. Some may have noticed that a blog reader pointed out a simple CSS solution – well, now there is better – Node-Red master as of now has an option to turn the menu off. I’d give it a day before updating to make sure the latest version had filtered through to updates.

Mint Linux: I wrote a while ago about this – so often these things fall by the wayside – well, I’m still using it – can’t find anything wrong with it on my little black laptop.  It isn’t Windows but for development work – it runs a lot faster on that old hardware than Windows 7 did and everything works right down to my Logitech Bluetooth headphones. Anyone else using this on an Intel-powered laptop?

Raspberry Pi Power backups: You’ll probably know I’ve covered this in the past – various solutions for backing up the little SBCs in the event of power failure. My best solution up to now has been RavPower battery charging units – but not all of them seem to work in the same way. I did find a little LIPO unit that works on one round 3v6 battery but it’s power output would not work for a RPI3 for example (which takes more power than the RPI2. Well, I’ve just discovered and sent off for one of these. It’ll take a few weeks but I’ll let you know how that goes. Anyone bought something similar? How did that go for you?

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).

It’s been a busy week already – I’ve been saving up a load of “Can we write articles for your blog?” emails and this morning I decided to take a look. The sample articles were ATTROCIOUS and now I know why so many articles are bad out there – they are written to order by people who just write stuff. Well, no thanks. I’ve asked the lot of them to remove me from their databases.

In the course of the post coming in I noted a Github notice of a new version of ALEXAPI – now for those of you who don’t live in the USA or America, Amazon Alexa is a box that you can talk to and control your home, play music (theirs, not yours) and generally buy Amazon products without needing to be able to read and write. It’s a wonderful thing. ALEXAPI claims to do the same on a Raspberry Pi or similar.

I have two of the Amazon DOT devices (which are very reasonably priced at £49 as against the full on unit which IMHO is, like the Google unit and others, way OVER priced). Very happy with them. Well, I’d be happier if they had an RJ45 connection instead of just WIFI – but that’s ok.

So what do we do with these? Well, we have shopping lists, we listen to music (on Maureen’s account as she has Prime, I don’t) and we control house heating, lighting etc. All in all they’re part of the family – and the BIRDSONG skill drives our cats NUTS which is a lot of fun.

And so it was that I found this link interesting in the email this morning. With this software, a usb mic and speaker of some kind, not only can you emulate an Alexa on a Raspberry Pi but on all manner of other devices.

Now, I long ago gave up on using a Pi, £32 for the Pi, plus powered speaker, plus decent mic plus case plus power supply comes to WAY over the cost of a ready-built Echo complete with REALLY pretty lights and a microphone array.

But this morning for a moment I was distracted – one could use an Orange Pi Zero which is only a few quid!!!  And off I went and followed the instructions. So – before I start, if you want to play with this – you CAN install this on an Orange Pi Zero (Armbian is good), it DOES work and you CAN completely uninstall if. Been there, done that.

I stuck in my USB audio adaptor, powered speaker, 3.5mm stereo microphone and installed the software. I filled in the details on Amazon which gave me the necessary keys to update the config on the AlexaPi.  I rebooted the Orange Pi Zero and…

Nothing.  As usual, audio settings. I talked to some VERY helpful people on their forums who guided me through changing the settings to the USB audio device. I tested it – audio output – perfect. Audio input – perfect. I thanked them,  rebooted and…

“Hello”…

Well, I nearly fell off my seat. “Alexa, what time is it?” – after quite some delay (this is NOTHING like a DOT which responds almost instantly) the unit came back with the time.  I tried a radio station and LO, it played the radio station. By now I was getting excited… I could put up with the delay.

Sadly, and this is no reflection on the obviously hard work done by the designers, things went downhill from there.

“change accounts” I said, wanting to switch to my wife’s account as she has Amazon music. No other people in the account setup. That could have been just a technicality so I ignored that. remember I know exactly how to use these things as I have two DOTS.

“Set a timer” – turns out the unit does not do lists – most likely API-related.

“Find my devices” – this was the killer. It took some hunting down but it was actually in the UNINSTALL instructions that I found … “AVS API doesn't have a way to connect the devices to Amazon.”

That last one was the killer. That and the mic – the problem is – Amazon put a lot of work into the mics – and they handle speech over background music reasonably well. I can blast my music and shout over the couch “ALEXA – SHUT UP” – and it promptly obeys. Not so the AlexaPi – while playing the radio could I HELL get it to take any notice of me until I turned the music down – and I was only sitting 2ft away.

I uninstalled the lot – and my Orange Pi Zero seems to be as good as new. So if you want something new to play with – or if you have a very limited set of needs – have a play. For me – I’d rather fork out £49 at this point.

It was suggested that one thing this software could to that the real thing can’t – is respond asynchronously – i.e. use it to output speech without a command – that is an annoying omission on the Amazon system – though if you write a special skill you can have it say what you want in reply – but then you have to call the skill and have a secure connection etc. 

But then it occurred to me – I have a Raspberry Pi running the house and HABRIDGE – and it has Node-Red and I already have IVONA speech on it – all I need is a speaker and when the DOT talks to HABRIDGE to fire an MQTT control message to my lighting and heating – it can also send off some speech itself. Don’t know why I didn’t think of that before.

So there it is.

The post AlexaPi and a Warning appeared first on Scargill's Tech Blog.

Programming editors, like music, are a matter of personal taste and I don’t hope to convert anyone here today. I would however like to bring something to your attention which I discovered at the weekend.

I’m a “Notepad++” man. I don’t particularly like the look of NotePad++ but it is fast and flexible and has colour-coding. It’s a Windows only program but has lots of plug-ins. It is my favourite editor. Well, it was.

I’ve recently been toying with other editors such as Atom but invariably I last a matter of hours with new things before finding bugs – which I am very good at, unfortunately. I think the first issue I had with Atom was Javascript refactoring but there were other issues which, all in sent me scampering back to NotePad++

There is of course Visual Studio – and that’s very nice for Windows users if you can handle it being slow as molasses – I can’t. Life is way too short to sit and wait for it to start up.

Then there is Sublime Text 3. I started warming up to that too – but again little niggles I didn’t like.

Until recently I figured I may as well stick with NotePad++ but for a chance trip to see my friend Jonathan. As always when we meet up he has stuff I’m not up to speed with and vice-versa and so it was that in the course of conversation he asked me if I was using Visual Studio Code?

My immediate reaction wasn’t totally positive – thinking it would have something to do with Visual Studio and hence “tarred with the same brush”. Anyway, being Jonathan I could not dismiss this out of hand so I asked him to show me what he was on about.

Well, things have certainly changed at Microsoft, haven’t they! Presumably partly due to Steve Ballmer disappearing off the scene?

Visual Studio Code is an editor – simple as that – a code editor. I’ve been playing with it for hours now and done some major upgrades to one of my nodes with it.  This fast, free (and importantly advert-free) clean multi-panel editor appears to have everything that Notepad++ has – and VERY much more. The first thing I noticed on pulling in my JavaScript code was the really nice colour coding and the dark theme. The second thing – and in all honesty one of the main reasons I’m attracted to this – is the really good Intellisense.  Was it that or the document formatting, turning my spiders web of a program into a very neat job at a button-press.

Or was it the gob-smacking list of extensions? Or the GIT integration, file compare… whatever, I’m a convert.

There are some features you might not believe if you’ve not kept up with Microsoft… extensions for debugging via Chrome (yes, that’s the competitor’s program) or the (untested by me) stunning fact that this editor is also available for the MAC and LINUX !!! What!!???! In my case I’m happy to stick with editing in Windows.

So – free, better than what I’m using now, fast, flexible and supported by Microsoft Why wouldn’t I be impressed. If you give the editor a go (which takes no time at all in Windows), you might be too. Integrates no problem as the primary editor for WinSCP.

Lovely.

The post Editors appeared first on Scargill's Tech Blog.

There’s a mouthful. This short article is about the various kinds of variables used in Node-Red and more importantly how to initialise them and how to view them.

So in Node-Red when you want to use variables – there are three basic types as well as local variables.

So for example – you’ve opened up a FUNCTION block and you want to use some variables. VAR is always a good start.

var fred=1;

A way to get a variable to PERSIST behind that simply function invocation to the next time around, use this;

context.set(“fred”,1);

If you’d like that var to be available to any other function in that flow (or page if you like) - use:

flow.set(“fred”,1);

and if you need a global variable that can be accessed anywhere within Node-Red including other flows  – I use them all the time for things like thermostat objects etc… use global.

global.set(“fred”,1);

Of course you can recall said variables as global.get(“fred”); etc. Don't use the old method (example global.context.fred) - there's a reason the Node-Red guys are steering us in this direction.

This is not meant as a course on programming – you can read all about this on the Node-Red site – just look up variables.

So three useful types of variable.

But there’s a problem. Node-Red runs asynchronously and in my first efforts I would have an INIT tab and initialise my global variables there. Once in a blue moon I would see a non-destructive failure with the logs showing that I’d tried to use a variable before it had been initialised (created, even).  So in a platform where everything is running asynchronously how do you ensure (without checking every single time you use it) that a variable has been initialised…. especially important for globals.

One way which I don’t really like is to ensure that the variable is initialised in the left most tab. as that runs first… ok… kind of….

Well it turns out “there’s a node for that”.  Node-Red-Contrib-Config does that – you can set up a variable – which could be a whole object – an no matter where you put this node – it will run BEFORE the main flows start up – I tested it, it works. My only niggle might be that the VALUE field needs to be expandable – a single line is not much use for large objects.

npm install node-red-contrib-config

So that’s one side of it.

The other side is – would it not be nice if you could have a tab to show you the current status, names and values of all of your global variables – and more. Well, now you can.

This needs a SLIGHT mod to Node-Red so if you’re new you might want to back stuff up.

In the directory you normally (hopefully locally) npm install stuff –

https://www.npmjs.com/package/node-red-contrib-contextbrowser

So the install is:

npm install node-red-contrib-contextbrowser

Stop Node-Red and in (in my case) and make a slight edit

nano /usr/lib/node_modules/node-red/red/runtime/nodes/context.js

This is the function you need to alter - very carefully add one line as I have in bold. That’s it – don’t make any other changes.….and this IS case-sensitive.

function createContext(id,seed) {
var data = seed || {};
var obj = seed || {};
obj.get = function get(key) {
return util.getMessageProperty(data,key);
};
obj.set = function set(key, value) {
util.setMessageProperty(data,key,value);
}
  obj.getKeys = function() { return Object.getOwnPropertyNames(data); }
return obj;
}

If you're something that does not show bold, the line starting "obj.getKeys" is the addition.

(NODE RED GUYS – any chance of making the above standard???)

Start up Node-Red (this works even if you use HTTPS and have password on Node-Red)

And lo – you should have a new tab on the right… click in the editor on a node or function you know has variables initialised…

and then use the refresh in that new tab..

My test..

The contents of that orange function

And..

As you can see, you must select the particular node or function with the mouse first – then hit the little refresh in the contextbrowser tab - you then see above freddy and the value in the tab – along with any others you’ve defined in that node or function. Ok it’s not quite debugging but better than nothing.

Now moving to the Global tab is another matter as I have several globals including some big objects – if they are very big – you might have to hit the little … indicator to expand them.

So for me this is marvellous – I can now set up global vars with the confidence that they will be initialised properly at the start – and I can also get a nice overall view of the globals I’ve used – something I could not easily do before.

If you like this post – please share a link to it by social media, by email with friends or on your website.
More readers means more feedback means more answers for all of us. Thank you!

The post Node-RED Global Flow and Context appeared first on Scargill's Tech Blog.

I should have just entitled this “Raspberry Pi” as it keeps expanding (now covering the rest of the Pi boards – but keep reading).. as you will see, the title is a little restrictive given what we’ve done over the last few days. Friend Antonio over Italy and I (still stuck here in the frozen wastes of the Northeast of England) have been working quietly in the background on making the script compatible with the new Raspberry Pi Zero WiFi (RPiZW) having already managed to get it working on a range of boards and operating systems including RPi2, RPi3, Debian, Xenial, various Orange Pi boards, various FriendlyArm boards, the Odroid C2 and more.

At under a tenner, no-one can claim this tiny WIFI enabled RPiWZ is going to break any records. It is slow. very slow compared to a Raspberry Pi 2 or perhaps an Orange Pi Zero... and at first attempt I nearly gave up after waiting a whole day for my script to run (and fail) - something that can take maybe an hour on more powerful single board computers such as the RPi3 or the Odroid C2 etc.

However, having failed to get the script to run on the official Raspbian distribution for this board, for a variety of reasons, we next tackled DIETPI. Here, this slimmed down operating system comes into it's own and the PI Zero WiFi runs a lot more swiftly than it does with stock Raspbian. Still, by lunchtime yesterday I'd stopped the script due to various errors. By late last night however, with a little manual injection I had everything running on this tiny board - Apache, PHP, Node-Red with all my usual Nodes, MQTT, Sqlite, PhpLiteAdmin, Ha-Bridge, MC and much more, all with no manual intervention (just as well, given the time it takes).

This weekend while I was out shopping for a new milk-frother, our friend Antonio over in Italy was busy working on some last minute amendments to the script which, you'll recall now runs on a range of devices and systems including Xenial and Debian. We’ve now completed the  updates to the script, including the ability to run on the RPiZW.  The sheer size of the RPiZW (or rather lack of it, being exceedingly thin) means you could fit this board, able to control a house, on the back of an LCD display and have the whole thing mounted in a reasonably slim wall-mounting box. The Orange Pi Zero on the other hand has that large Ethernet connector which means a slim case is out of the question.

There is of course competition for this board, the Nanopi Neo Air is actually smaller (different format of course, being square) - and no doubt a lot faster - but like the RPiZW it has no Ethernet. One issue I've had with many boards is that of WIFI reliability. Up to now, the WIFI on the RPiZW is rock-solid - just as well, as it doesn't have hardwired Ethernet capability (well, not without some soldering or a compact-size-defeating USB dongle). The NanoPi on the other hand works well and is way better technically but I'm not 100% happy about the WIFI on the latter. All of this could change of course with future software updates.

Raspberry Pi Zero WiFi: Here’s what I did (total time 4 hours -  VERY little of which I was actually doing anything – well, watching YouTube videos actually):

• I grabbed the file DietPi_v145_RPi-armv6-(Jessie).img
• I used SD Formatter to format a 16GB card then Win32 Disk Imager to blow the image onto the SD card.
• I plugged the card into the RPiZW and powered the board up, plugged into a screen – and with keyboard and mouse connected via a USB hub.
• I started up the Pi – that takes a little while and it eventually wants you to login as root (initial password dietpi).
• As per initial dialogs in DietPi-Config, I set up the WIFI.
• The board went off to do some downloading and came back to the DietPi-Software - I swapped from DropBear to OpenSSH Server and lighttpd to Apache2 - but didn’t install anything else.
• At the end of that I could get into the board remotely using WINSCP and no longer needed the keyboard and mouse.
• I copied the script across to the root directory – ensuring it was in Linux format (Line feeds only) and that it had execute permission.
• It went off and automatically set up a PI user with password “password”. I logged into the board (using WinSCP) as user  pi. I copied the script across again and once again made sure it had execute permissions. I ran the script.
• Several items were downloaded. I waited patiently until the main menu came up. I accepted all defaults but added HA-Bridge.
• I was asked for a user name (user) and password – and an admin name (admin) and password… (you can opt out of that now and leave defaults if you like) and at that point the script – as you’d expect – went off for 4 hours (using a half-decent microSD from Samsung) doing it’s own thing. And yes, watching the WEBMIN setup DOES feel like watching paint dry.
• At the end of all of this – I rebooted the board – and that was the end of that – a perfectly working RPiZW.

Something that has come out of this – is the importance of SD speed… I’ve always known this but NEVER has it been as obvious as it is here with this slower board. 4 hours – recall I mentioned an earlier attempt which failed but also took longer. Well, now I’m using a decent Samsung microSD.

Raspberry Pi Original: Which brings me to the Raspberry Pi – not the 2 or 3 but one of the originals. The script appears to be working perfectly now even on pre-Pi2 boards with full size SD card (Raspberry Pi © 2011.12). Sadly when I was using those I was not aware of the need for the best SD and THIS install took 7.25 hours – if you plan to try one of these – get a decent SD! Still – all working so an otherwise useless Pi is now up and running.

Raspberry Pi Zero: On a whim, I took a copy of the microSD I used on the RPiZW and dropped it into the lowly, cheap and cheerful Raspberry Pi Zero (the one with nothing) – I then took a USB adaptor and plugged it in, with one of those really cheap unbranded WiFi USB blocks at the other end.  I plugged in power, waited, checked for new IP addresses and LO AND BEHOLD that was online too!

Raspberry Pi 2:  I tested the modified script on the Pi2 and as well as being a darn sight faster to install than the units above – it does work well.  I did however notice that the yellow Node-Red GPIO node does not work – possibly something missing in DietPi. However – there’s a great utility called GPIO which gives you full command line access and I’ve now added that as an option to the script. I’ve tried GPIO access including PWM and it all works a treat as Pi user.

cd
git clone git://git.drogon.net/wiringPi
cd ~/wiringPi
./build

The above it what I added… then use GPIO – now, with the –g option, the pins correspond to the actual connector which is nice – so for a nice dim LED on GPIO13

gpio –g mode 13 pwm
gpio –g pwm 13 20

Not tried that on the Zero but I assume it will work as well. If anyone knows why that yellow GPIO node sits at “connecting” do let me know. Remember in all of this we’re using the DIETPI image – NOT original Raspbian – which IMHO is a little heavy handed if you don’t want a graphical interface.

Things are looking up.

And now for something completely different: Meanwhile I thought you might like to see this Raspberry Pi battery backup  (not for good reasons) -   I bought this a couple of weeks ago and it turned up today. 4 brass spacers and it fits onto my Raspberry Pi 3 a treat.

But – pull the power out – and the Pi reboots – who on EARTH dreamed this up!!! They claim 9 hours of backup but no good if power loss causes a reset… worse -  I bought it from Europe at £9.49 and I COULD have bought it from where they probably got it from in the first place at £8.73 and no postage. Oh well. I’m assuming I got a bad one – surely they could not have designed it this way. Anyway, it has a 3800maH battery and it all fits perfectly on the back of a Pi.  On the FRONT of my Pi I have an LCD display and the whole thing was intended to form the backbone of my updated home control in Spain when we go back there in April. A clue to the problem may be that there is a small yellow power indicator on the Pi, suggesting the pack might just be putting out insufficient voltage for the Pi + LCD. So – I tried it with a Raspberry Pi 2 on it’s own – same result. Just thought you’d like to know in case you were thinking of buying one of these. THIS looks GOOD (Thanks Antonio) – any experience of this??  I have some goodies from another company coming in the next couple of weeks which look promising as uninterruptable supplies– more on this soon.

The post Raspberry Pi Zero WiFi appeared first on Scargill's Tech Blog.

Why am I showing you a picture of a cracked-screen phone?

Well because this particular phone is a bust Oukitel K10000, the phone with the world’s longest-lasting battery and an excellent workhorse. My friend Aidan gave me this (rather than chucking it away) some time ago and it has been sitting doing nothing. All that is wrong with it is a cracked (and exceedingly dangerous on the fingers) screen. I’ll bet I’m not the only one with such a phone lying around wasting space.

Well, as of yesterday, it is a Debian server with all my usual stuff going on quietly in the background – with the screen normally off – running freezing cold and hopefully being super reliable.

This is an experiment only – beware – if your phone or tablet dies it is your problem….  oh and your Android phone/tablet needs to be ROOTED. 

Imagine turning your old, dust-covered phone into a sleek, battery backed-up server with unfeasibly long backup time, immunity to any mains spikes, a silent, fast Debian base for all the stuff in my script – which includes Node-Red, Apache/PHP, SQLITE (+ PHPLiteAdmin), MQTT, MC, Ha-Bridge and more!  If you’ve been following this blog you’ll know about the script.

So this article applies to ROOTED Android phones and we’ve only tested around Android 5.0 onwards.  In my case I rooted the phone with KingRoot (note, NOT the one in the PlayStore which is a con – avoid it - but the one at kingroot.net ) – please note that rooting phones is beyond the scope of this article and if you are not confortable with this you should not do it. There are a lot of links out there on the subject and many of them are fraudulent.

There is an APP in the Play Store called Linux Deploy. It is also on GitHub. Beware that this is essentially undocumented unless you are Russian – so please don’t ask how you can use your phone’s GPS or Sound from Debian – not a clue!

You should have a modern-ish WiFi enabled (or hardwired if you like) Android phone or tablet with at least 16GB of internal FLASH (which should give you 10GB working space).   If you only have 8GB that will leave you only 2GB which - really – isn’t enough.

Getting Debian 8 on the phone:  After ensuring your phone/tablet is rooted, Install the App.

In the app, on the top LEFT menu – find  REPOSITORIES and select Debian 8 for ARM.

On the bottom right is a drop down – you should go in there and select INSTALLATION TYPE – directory (OR FILE with a reasonable file size limit – say 5GB – the 2GB default will NOT work). Change the user to “pi” with suitable password in the same menu. TICK for allowing initialisation – and use of SSH server. Also where you see INIT SYSTEM change that to sysv. 

Then TOP RIGHT menu  - INSTALL – that might take some time – top right again CONFIGURE – then bottom menu START – and you should have a working Linux you can get into with for example WINSCP for that “pi” user. The IP address is clearly shown in the App.

I suggest not going further until you are comfortable with the above – took me several attempts because I didn’t follow the above exactly (well, and Antonio and I were learning at the same time).

Running the script: Via WinSCP or similar, put the script into the pi directory – changing permissions as normal - run the script – and ensure PHONE is selected – it isn’t by default. Come back after lunch. The script will no doubt suggest a reboot. Instead, hit the STOP button on the bottom of the phone screen – wait for it complete, hit the START button – wait – and you should now have everything in the script running!

Now – I’m using this to run my script – but I’m thinking you COULD use it to serve files etc. – I’ve not tried this but I’m guessing it would be easy to access an SD card…. and make that a folder…. hmmm.

Anyway, it is now the day after I installed all this – the phone is sitting there “off” and unlike my FriendlyArm board with it’s whirling fan, is sitting silently and freezing cold yet ran the script much faster than any of my SBCs – around 40 minutes.

No guarantees as there just isn’t enough info about Linux Deploy out there (unless you find/translate some) – but it does seem to work well now that we’ve made sufficient alterations to the script to take this particular setup into account. A fun project, to be sure. Now, I know this is a not a fair comparison and tomorrow we might come back and say … no good (for whatever reason).. but at £107 for that particular phone… compare – how much would it costs for a Raspberry Pi 3, uninterruptable power supply able to keep the phone going for something like a couple of days with no power, a high-def touch screen, a solid case for the whole thing.. indeed ,it might be possible to use a cheap tablet…  I was looking on Ebay – 16GB Android tablet – perfectly working except for missing buttons and cracked digitiser – around £10

One thing to note – I’ve turned rsyslog messages off – it was spitting out all sorts of unwanted helpful messages when you changed brilliance on the phone or disconnected the USB etc –REALLY annoying.. If you feel you need logging on -

sudo service rsyslog start

That will stay on until the next stop-start…

Such a shame it isn’t clear how to access some of the peripherals like audio. But who knows – someone reading this article may already have solved such challenges.

Please note: the pretty colours on the right do not come as standard. Click images to see larger versions.

This is really starting to look GOOD!!!!

Revelation: I’ve now taken on-board ideas from others and thanks for that – both people in here and on Google+ – most of the other solutions are longwinded and need other packaged  so up to now Linux Deploy – I’m now installing on my old Nexus 7 2012 UTTERLY SUCCESSFULLY (though not the fastest kid on the block) ( after rooting it with the Nexus toolkit ) - using Linux Deploy (which is completely self-contained and offers full root access – is looking the best). The ONLY thing you can’t do is use the Android peripherals – because of lack of UK info but this morning I figured it all out. 

We’ve also tested this one OnePlus One (model BACON) and a Xiaomi Redmi 3 model IDO). The K10000 has now been up for several days.

Ok, bear with me – you have Node-Red on Linux – and MQTT. So, you run Tasker on the phone (in the Android section) with MQTT – and now you have access to and control of all of the Android facilities that TASKER can handle (i.e. just about the lot) from within the Debian environment. Doddle.. now all I need is some time!!

The post Android Phone as Server appeared first on Scargill's Tech Blog.

This  is the following up the previous Android Phone as Server article. Last update 22/03/2017.

Servers: So having now tried various phones and tablets, it does look like the Linux Deploy App on a rooted Android phone makes for a good Debian installation in order to run software like Apache, SQLITE, MQTT and Node-Red – in some cases surpassing the capabilities of the likes of Raspberry Pi by some way. When I say it looks that way, it is to early to comment on reliability – though my little K10000 monster phone has now been sitting on the bench for several days running this stuff without a hitch.

Resource: The next step then is to add value to this – modern Android phones are awash with features, none of which are currently being used in this setup. With MQTT communication, it seems natural to take all of those sensors and outputs and use them, firing info back and forth in MQTT or similar between Debian (Node-Red for example) and the Android phone (or tablet).

Some time ago when messing with the infamous TASKER  on Android – which can access most phone/tablet features, I noted the Tasker/MQTT plug-in – which means that Tasker can communicate via MQTT. The only problem with this – is that the MQTT app has not been updated since 2015, recent reviews suggest that it packs in after a while and the author does not at first glance appear to be responsive. I’ve written to him and not yet had any answer. This makes me extremely reticent to go down this route. I’m wondering if there are other ways to use Tasker to do the same thing. Remember that for this to be useful, this has to be something that will start up automatically when the phone is on – and also something that will run in the background when the phone is on standby.

So recently, friend Antonio sent me a link to another option – Sensor Node – the link here is to the free version and I splashed out and bought the full one. This seems ideal, instant access to at least sensors (though not controls) via MQTT at a user-selectable rate. Well, it didn’t quite work out that way when I tested it – firstly some of the touted sensor readings for some inexplicable reason are not included in the options for MQTT output -  like battery power and percentage charge – which would be really very good for sensing if the power has been lost and doing something about it – (like backing up any RAM cache to disk).  I’ve written to the author and asked about this – but when I started testing this it got worse, the software would not store my MQTT readings properly and there is no facility that I can see to run this in the background or ensure that readings commence when the phone starts up.

Anyway it turned out that Sensor Node was CRAP – even the paid version-and it turns out that there is an updated MQTT Client add-in for Tasker so I gave THAT a go.

Verdict:  It is looking like TASKER and the MQTT Client plug-in are winners. It did not take long to have Tasker sending BATTERY STATUS back to Debian every time the percentage changed – and in the process I found this link detailing a LOAD of variables you can use. The next thing was to get a Tasker task taking in an MQTT message and SPEAKING it out – that works a treat.  If I could just figure out how to get it to take in serial (see the article on the RFLINK gadget) – I could take in my doorbell presses and have them play bells!!! I do however have the thing taking in MQTT and playing a REALLY nice doorbell.

Update: All of this incidentally while in standby  - I fully charged the K10000 phone and disconnected from the mains. The screen is off and occasionally as well as running Debian and my Node-Red stuff, it acts as a doorbell. THREE days later the battery is around 76% – how many server backup systems manage that!!! We're talking at least a week in the absence of power. I can see a solar project coming on here.

The post Android Phone as Resource appeared first on Scargill's Tech Blog.

A couple of weeks ago I went to stay with my pal Jonathan and he had some Byron doorbell pushes to play with.

This article updated 22/03/2017

He showed me a universal RF 433Mhz receiver board he purchased which could look at the signals from the various kids of 433Mhz standard transmitting units.

This was interesting as I have an Acurite weather station with the most appalling interface which requires a PC to be on constantly in order to remotely access the information.

I don’t know what planet the designers were on – but it was a gift from my wife, solar powered and including rain level, wind speed and direction etc.. a nice job other than the software. It has been sitting outside the wall on my office for months doing nothing.  I thought it might be interesting to get that going.

RFLink

The unit my friend was using was rather expensive but he suggested I try the RFLink software along with a DIY unit comprising an Arduino Mega2560, a little board called an RFLink V1.1.4 (now updated) and an antenna – you see the lot here.

The kit arrived days ago and I put it together with a soldering iron easily enough but had to wait for a Mega board to arrive which it did this week. I downloaded the software – very simply install program for the PC – couple of button presses really – and that was that. I plugged the little RF board into the MEGA, plugged the Mega into my PC and… out of the blue, information from my Acurite board appeared out of no-where, as did  more one-liners from my Byron button presses and even our doorbell. It took no time at all with help from a fellow enthusiast who’s used this stuff before to figure out how to send a signal back to the doorbell to make it work.

All very nice but I needed this into Node-Red.

I took my latest Raspberry Pi using DietPi and after adjusting comms permissions, simply plugged the USB device into the Pi and set up a serial node for both transmit and receive.

From there on it was easy. Far from complete - but thought you might be interested – the combination of the two boards and that software seems to work really well up to now for receiving from 433Mhz sensors and for sending out commands to 433Mhz boards.

I had a slight concern about how long you have to leave the Byron SX35 pushbuttons before pressing again (3 seconds). But I  mentioned this to the author and within an hour he came back with an update which made the delay much more practical.

Valid input instructions from the various sensors is in this link along with the Arduino software download….

http://www.nemcon.nl/blog2/protref

I bought a bog-standard Arduino 2560 (cheap Chinese version)

I bought this board… the RFLink 433 kit – requires a little soldering…

https://www.nodo-shop.nl/en/21-rflink-gateway

10 minute soldering (take note of version numbers – important), 10 minutes max to blow the software. Test the board (56k baud) to ensure when nearby sensors are sending results – they are coming in and then I wrote this test… it isn’t very elegant yet.

My SERIAL node is set to split input on character “\n” so the code has to get rid of return characters as you’ll see in the “replace” line below. Note also that when you send out serial (to actually control something) it should be followed by both “\r\n”.

// So firstly a generic means of getting incoming items into an object

var the433 = {};
msg.payload = msg.payload.replace(/(\r\n|\n|\r)/gm,"");
node.warn(msg.payload);
var parts433 = msg.payload.split(";");

the433.p1 = parts433[0];
the433.p2 = parts433[1];
the433.name = parts433[2];

var a = 3;
while (a < parts433.length) {
    var bits433 = parts433[a].split("=");
    switch (bits433[0]) {
        case "ID": the433.id = bits433[1]; break;
        case "SWITCH": the433.switch = bits433[1]; break;
        case "CMD": the433.cmd = bits433[1]; break;
        case "SET_LEVEL": the433.set_level = parseInt(bits433[1], 10); break;
        case "TEMP": the433.temp = parseInt(bits433[1], 16) / 10; break;
        case "HUM": the433.hum = parseInt(bits433[1], 10); break;
        case "BARO": the433.baro = parseInt(bits433[1], 16); break;
        case "HSTATUS": the433.hstatus = parseInt(bits433[1], 10); break;
        case "BFORECAST": the433.bforecast = parseInt(bits433[1], 10); break;
        case "UV": the433.uv = parseInt(bits433[1], 16); break;
        case "LUX": the433.lux = parseInt(bits433[1], 16); break;
        case "BAT": the433.bat = bits433[1]; break;
        case "RAIN": the433.rain = parseInt(bits433[1], 16) / 10; break;
        case "RAIN": the433.rainrate = parseInt(bits433[1], 16) / 10; break;
        case "WINSP": the433.winsp = parseInt(bits433[1], 16) / 10; break;
        case "AWINSP": the433.awinsp = parseInt(bits433[1], 16) / 10; break;
        case "WINGS": the433.wings = parseInt(bits433[1], 16); break;
        case "WINDIR": the433.windir = parseInt(bits433[1], 10); break;
        case "WINCHL": the433.winchl = parseInt(bits433[1], 16); break;
        case "WINTMP": the433.wintmp = parseInt(bits433[1], 16); break;
        case "CHIME": the433.chime = parseInt(bits433[1], 10); break;
        case "SMOKEALERT": the433.smokealert = bits433[1]; break;
        case "PIR": the433.pir = bits433[1]; break;
        case "CO2": the433.co2 = parseInt(bits433[1], 10); break;
        case "SOUND": the433.sound = parseInt(bits433[1], 10); break;
        case "KWATT": the433.kwatt = parseInt(bits433[1], 16); break;
        case "WATT": the433.watt = parseInt(bits433[1], 16); break;
        case "CURRENT": the433.current = parseInt(bits433[1], 10); break;
        case "CURRENT2": the433.current2 = parseInt(bits433[1], 10); break;
        case "CURRENT3": the433.current3 = parseInt(bits433[1], 10); break;
        case "DIST": the433.dist = parseInt(bits433[1], 10); break;
        case "METER": the433.meter = parseInt(bits433[1], 10); break;
        case "VOLT": the433.volt = parseInt(bits433[1], 10); break;
        case "RGBW": the433.rgbc = parseInt(bits433[1].substring(0, 2), 16);
            the433.rgbw = parseInt(bits433[1].substring(2, 4), 16); break;
    }
    a++;
}

// SO - the above is general... here is my specific setup for temporarily displaying
// the Acurite info
if ((the433.p1 == "20") && (the433.name == "Acurite") && (the433.id == "c826")) {
    if (typeof the433.temp !== 'undefined') temp = the433.temp;
    if (typeof the433.hum !== 'undefined') hum = the433.hum;
    if (typeof the433.bat !== 'undefined') bat = the433.bat;
    if (typeof the433.rain !== 'undefined') rain = the433.rain;
    if (typeof the433.winsp !== 'undefined') winsp = the433.winsp;
    if (typeof the433.windir !== 'undefined') windir = the433.windir;

    node.warn("Temperature: " + temp + "c");
    node.warn("Humidity: " + hum + "%");
    node.warn("Battery: " + bat);
    node.warn("Rain: " + rain + "mm");
    node.warn("Wind Speed: " + winsp + "km/h");
    node.warn("Wind Dir: " + (windir * 22.5) + " degrees");
}

Put that in a Node-Red template – attach a Node-Red serial Node set to take serial input from USB0 at 56k – character /r as a separator and deliver ascii strings…and that – is just the beginning…  note also that the designer of this free software has also added GPIO control both input and output – on several pins (recently expanded so check his docs).

Tests: Right now for my tests  - I have the K10000 phone acting as a server running Debian and running Tasker and the MQTT client Tasker plugin with the same phone running as a resource…. and I can now fire an MQTT message at the latter to get a doorbell message out! Meanwhile a Raspberry Pi is running that RFLink unit and when one of the Byron doorbell pushes is pressed – a message is sent out to the phone to play the doorbell – yes, I know, somewhat over the top – but I’m just experimenting for now… and sure enough – press the button and pretty much in real time the doorbell sound appears.

In the comments below you’ll see reference to an ESP8266 to MQTT Gateway – and this would be ideal as it would be all in one little box – whereas I need to stick something like a Pi on the end to generate a wireless MQTT signal…. so – I grabbed the software and (disregarding several wasted hours due to a duff FTDI) put together one of these – as you’ll see in the photo on the right-  the antenna is due to kind feedback below – and as you can see, it is a precision job (it is accurate however).

Well, I have a 4-way remote control for a cheap Chinese remote and indeed this little system does pick it up and sends a unique number for each key off as MQTT – lovely – however – even with a decent little aerial the unit does not pick up (or recognise) my weather station of any of my BYRON pushbuttons – and the data coming back is crude compared to the RFLink software so at first glance, not impressed.

Costs:  Ok of course the hardware for the little ESP board is DIRT CHEAP compared to what I’ve put together – which in turn is cheap compared to one of these all in one boxes – but you pay your money – I’m sticking with https://www.nodo-shop.nl/en/21-rflink-gateway – at under £20 plus £9 for the aerial plus a Mega2560 (cheap from China) I think it is worth it (no I don’t know the company and no I didn’t get samples etc).

The transceiver they supplied costs  £16.51 on Ebay so the board with connectors and the transceiver really is a good deal.  You can of course use cheaper receivers – but the software writer suggests these might be naff. I’d like to hear back from someone who had had GOOD results just using the Mega board (they’re only a fiver from China) and other boards. There is information here on that subject. RXB6 board seems cheap but don’t buy from the UK as they seem to be a rip here – on guy wants nearly £8 inc postage – China for same board – under £2 all in. I’m kind of stuck for testing one of these as I’m off to Spain in a few weeks and chances are it won’t get to the UK in time for me leaving!! Shame as I’d like to have given one a shot on my spare MEGA board.

Summary: Already the RFLINK setup has made my day by turning my otherwise useless weather station into another working part of my home control – and I’ll soon have buttons all over the place. It also has good range though I think aerial design and positioning could be improved.  I can’t do a range comparison with the ESP project as it only recognises one my my 433Mhz devices and even then gives out a number, no proper ID and name… still – worth keeping an eye on for future developments.

If you like this post – please share a link to it by social media, by email with friends or on your website.
More readers means more feedback means more answers for all of us. Thank you!

The post RFLink and Node-Red appeared first on Scargill's Tech Blog.

This could be one of the shortest reviews I’ve ever done!  The S430 is a low-cost  4.3” capacitive touch-display designed to work with FriendlyArm boards such as the NanoPi S2, M2, M3, the NanoPC T2 and T3 and finally the Smart4418.

When I think of the HASSLE I’ve had getting a cheap(ish) Chinese display to work with my Raspberry Pi 3 (read elsewhere – still not resolved – you have to make changes to the Raspbian system but more importantly alignment no longer seems to work so the touch part is useless and no-one has a solution).. I spend days on this and finally settled for a display with no touch!

But I digress. The S430 offers 480*800 resolution, is bright, clear and has 4 nice recessed mounting holes and a ribbon cable out the back  - none of this HDMI-awkward-connector nonsense as per the above.

And that’s it. I unpackaged the unit, I took a NanoPi M3 which was sitting minding it’s own business serving up Node-Red – I turned it off – plugged in the ribbon cable, turned it on – and immediately, lightning fast text – no drivers, no setup, nothing.  When the board eventually popped up with Debian – everything worked – accurate positioning, sensitive capacitive touch etc.

It really is hard to say much more more – it is good and it does what it “says on the tin”. It is accurate, thin and most importantly, it is cheap.

As you can see, I just happen to have everything set up in portrait mode and it all just works. Being capacitive I’ll have to go find a proper capacitive pen as you can’t just use any old bit of plastic as you would with the resistive displays – on the other hand – no pressure is needed either.

I could see this working a TREAT with Node-Red Dashboard.  Images in here will expand if you click on them.

I’m quite excited as you can tell.

Now to figure out how to get landscape mode…

The post FriendlyArm S430 appeared first on Scargill's Tech Blog.

Today must be my day for easy installs. The FriendlyArm NanoPi M1+ turned up this morning along with spare heatsink and antenna.

So first of all what is it? – this is a small SBC, a development from the Nanopi M1 which I’ve reviewed here before.  So is this worth reading? I would say YES. The M1+ comes complete with 8GB of EMMC which as we’ve seen with other boards makes a significant difference to speed. It can of course handle SD.

The most important features are:

• H3-based (which means there is code out there for the GPIO)
• Mali GPI
• 1GB DDR3 RAM
• 8GB eMMC
• WIFI, Bluetooth (4.0 dual mode)
• Gigabit Ethernet
• 3.5mm Audio jack
• Microphone on board
• IR sensor
• 2 USB-2
• 2 USB Type A
• OTG
• DVP Camera
• Serial Debug port….

As usual 4 serial ports, though one is debug and one will be tied up with Bluetooth – but that still leaves the Pi wanting.

I opened up the box, downloaded the EMMC loader image from the FriendlyArm site onto a 16GB SD and ran it on the hardwired Ethernet connector. A box popped up offering to install one of two operating systems, I picked Debian. Minutes later I turned it off – took out the SD, turned it on and… working complete with LDXE. Size – around 70mm * 65mm.

I don’t remember an easier setup – everything worked including SCP access to both users FA and ROOT. I logged in as root from WinSCP, copied my script across – ran it – it created the Pi user, I logged in as Pi, ran the script and went off for coffee. Exactly 58 minutes later the whole thing was done and dusted with all my favourite software in place.

This time I’d put in a new addition to the script…AHAVI.  Once the script finished I popped into the HOSTS file and the HOSTNAME file and changed the name from “friendlyarm” to “m1plus” and rebooted the board.  Antonio who gave me this mod had assured me that this would now mean local access to the boards by name – which should work but hasn’t in the past.   I went to my browser on the main pc and typed http://m1plus.lan and sure enough – up popped the board. I tested all my main programs – all work.

I’ve not done any speed tests other than the script install which at 58 minutes is not bad…. but the whole thing has a good feeling of speed about it.  This could be my new favourite board. Up to now it has been the M3 boards but the fan noise is getting on my nerves a bit – need to sort that – the M1+ definitely does not need a fan.  I have hardwired Ethernet on one IP, WIFI on another – the WIFI is reporting a good signal WITHOUT an external aerial. I checked the Bluetooth and it immediately found my Bluetooth speakers.

So up to now, all looks good and as we’ve seen the H3 before there should be no horrible surprises anywhere.

I’ll let you know more about speed and reliability as I get into using this little board. Just a shame they’d not put the connector on for their LCDs… but hey – you can’t have everything.

The post Enter the NanoPi M1+ appeared first on Scargill's Tech Blog.

There have been various conversations about Node-Red initialisation of variables recently. Here’s a solution.

So firstly – what’s the problem? Well, because of the asynchronous nature of Node-Red, it seems to be that sometimes you find yourself using a global variable before it has been defined. No lectures on using global variables please. I can see in my own systems, in the log, incidences of uninitialized variables.

My own solution to the issue of non-volatile storage has been to save global variables as a single object, into a file – and restore said on power up (thermostat settings etc.) – you could store them in MQTT, in a database, anywhere – doesn’t matter. The issue is restoring them.

On power up one assumes the left most tab in Node-Red will run first and that is generally true – but where anything asynchronous is happening – like getting a file for example (hint) there could be delays and other code could run using one of your variables before you’ve actually set it up. This usually does NOT result in Node-Red crashing but you can get rubbish results. Of course you can check every time you use a variable if it exists but that can get messy REAL quick.

A conversation started in the Node-Red discussion groups recently – one of many - and I just latched onto an idea and ran with it.  Of course my first few attempts resulted in suicidal feelings as they failed time after time – but just mid- morning it all started to come together.

So, first things first – the Node-Red settings.js (created when Node-Red is installed and could be for example at /home/pi/.node-red/settings.js)  file runs BEFORE Node-Red comes online – so you know that if you initialise stuff in there, it will be set up in time for you to use – but messing with that file from within Node-Red could be dangerous and you could kill the whole installation. It also  defeats the object of having everything in one nice visual interface.

Here’s another way

Within settings.js there is “functionGlobalContext” which sets up any globals you might need for example – fs object for using files. Here is that section (typically) with one line added into settings.js

functionGlobalContext: {

os:require('os'),

moment:require('moment'),

fs:require('fs'),

mySettings:require("/home/pi/redvars.js")

    },

See that last line with “mySettings” -  you can call that what you like.

In (for example) your /home/pi directory, create a simple file called redvars.js (or anything you like really). In there you could put this..

and thanks to Nick O’Leary for the specifics…

module.exports = {

    "fred": 1,

    "brian": 2

}

However, what happens if the redvars.js file is corrupt for any reason – answer? Node-Red crashes.. Here’s a better way. At the VERY START of setting.js add this..

var mySettings;

try {

mySettings = require("/home/pi/redvars.js");

    } catch(err) {

mySettings = {};

    }

So mySettings is either populated or made empty. No crashing. Now you only need to add ONE line to the functionGlobalContext – here it is in my case… yours might be different…

functionGlobalContext: {

os:require('os'),

moment:require('moment'),

fs:require('fs'),

mySettings:mySettings

    },

As you can see, with an additional comma then one line, a foolproof version of mySettings has been added.

Run Node-Red and you will now find that (for example)  global.get(“mySettings.fred”)  returns 1.  SO – now all you have to do is to put what you need in that file redvars.js – and if you need to update them you can do that within Node-Red. 

In my case I have a variable called counter in there.   Every time I update something, I update that counter to 10;   I have a little timer job running that checks that var and if not zero, decrements it – if it is now zero, it updates the file… see how I did that below.

If you look at my original article on this subject – all seemed well, simply stringify the object and save it to disk – and that’s really how I’d like it to be - but my mechanism for RETRIEVING the object on power-up failed miserably because of the async nature of the file read – often resulting in use of the variables before they existed. This way, that won’t happen and all it needs is to stringify the object and add “module exports-“ at the start.

In the unlikely event that the redvars.file is corrupt, on power-up, mySettings will be undefined – easy to check and if necessary overwrite.

So one simple change on initial setup of Node-Red – and from there on you can create or amend non-volatile global variables from within Node-Red.  You could expand on this of course – that is up to you.

The post Node Red Initialisation appeared first on Scargill's Tech Blog.

Evening all, it has been a busy day here at the Scargill’s man-cabin. Yesterday, frequent blog-visitor JAY popped over for a visit and we spend some time discussing new stuff:

First on the list was a new toy Jay just picked up on offer at Maplin – a “SmartSensor Energy Egg” solo pack which comprises a PIR Egg and a mains socket. The two operate on 433Mhz and allow for turning a light on for a predetermined time when someone moves in the room. Simple enough – but At under £8 on offer I guess Jay could not refuse. I have one sitting in front of me now looking for a home in my office. There is a website – energy-egg.com but I advise against it – half of the links go no-where. Anyway – special offer – Maplin.

The gadgets are meant to run stand-alone but of course we had to try it out with the RFLINK 433Mhz setup and sure enough – the RFLINK registers activity in the PIR.

Turning the PIR on and off with the handy button on the top produced this output.

"20;31;Eurodomest;ID=0eec5a;SWITCH=05;CMD=ALLON;"

"20;30;Eurodomest;ID=0eec5a;SWITCH=01;CMD=OFF;"

Strangely the effect was the opposite of what you might expect – the ALLON command turned the light off!! Anyway the upshot being we can easily monitor this device along with others using the RFLINK.  Sadly when we tried to turn this into a COMMAND to turn the light on and off from the RFLINK unit, while we could turn the device ON, the OFF command stubbornly refused to work – but we started sending emails off to Frank Zirrone of RFLink software fame – and he was very helpful – we’ve now send some diagnostics off (this all comes in the software folder for RFLink) and he’s taking a look.

Meanwhile we discovered a potential issue with the playground covered earlier in this blog – the mobile phone as server. I’ve been using TASKER on the phone to pick up MQTT messages from the Debian installation (to in turn play a really nice doorbell sound) – using the MQTTCLIENT Tasker Plug-in App which you might recall replaced it’s somewhat ill-fated predecessor. Well, it seems it is still not out of the woods.

While it works GREAT, if you reboot the phone, while everything else comes up perfectly including Debian itself, Tasker and, well, yes, everything – the MQTT plugin – would you believe does NOT re-connect with the MQTT broker until you open the app.  Now this may be because it is starting before Debian is ready – but you would think that such a program designed to run in the background, would try, try, try again until it got through. We even tried using Tasker to initialise it – no joy.  So until the author comes back, we’re on the hunt for alternatives – and it is possible that TELEGRAM may be it  - except having installed it on my phone (easy) and on my PC (easy) and installed node-red-contrib-chatbot on Node-Red - with a wopping 37 nodes  - I'm now utterly confused. Jay helped me set up a bot and send a message to it - but getting it to arbitrarily send a message... I'm not quite there yet - and what you're supposed to do with all those OTHER nodes....

There is a TELEGRAM app for Android, a plug in for Node-Red and in fact it comes on just about all platforms – this is similar to other messaging apps in that you can send text message back and forth – so the hope is that we can send messages between Node-Red on Debian – and the Android Tasker reliably – more on that later.

Anyone have any experience of using TELEGRAM? I swear this could be the death of me.  A video showing the various nodes in action would be nice!

The post A Fine Sunny Day appeared first on Scargill's Tech Blog.

Looking for help on a couple of items where Google has failed me..

1. Friedland door/window contact twin-pack DC-55.   I have them running – I have RFLINK talking to them – I understand the codes for door opening  and door closing and another for the internal spring being released (anti-theft) – but there is another signal which occurs occasionally – I’m assuming it is something like “battery ok” – but that suggests another “battery not ok” – but I have NO info on this – anyone?

2. On the RFLINK board I have a little whip aerial – it is 70mm high and has the miniature screw fitting for the board at the other end.  What inexpensive, simple antenna would be SIGNIFINANTLY more sensitive without being directional.  From my outside office I can reach just into the house but only just.

3. Grafana and INFLUXDB.  I have upgraded Influx to 1.2 (see the blog entry if interested) but a problem persists – I have a graph showing several temperature lines – inside and outside stuff – nothing extreme.  I have two of them with duff readings in them – one is minus 400 and the other is +6000.  I cannot figure out how to delete readings outside of a range in InfluxDB (on the Pi) and I cannot seem to get WHERE clauses to work in Grafana.   WHERE value < 100 for example just makes the line disappear.   Anyone know the answers?

Pete.

The post Help appeared first on Scargill's Tech Blog.

You may well have read my review of the NanoPi NEO back in August 2016 – a nice little H3 unit available in two versions, 256Meg and 512Meg RAM. Well, the new unit has an H5 64-bit processor and comes with 512MB RAM and although there is only one USB connector – there are three USBs available. Size is 40mm square! The NEO 2, however is more expensive than the original at $15 + post etc.

There are lots of add-ons available for it including WIFI, a TTL-RS232 module (just an FTDI but cheap enough), power dock, prototype board etc etc – you can read about it here so I won’t go into too much detail.

So – nice looking board, I’m not sure why they chose hardwired Ethernet over WIFI – I’d have gone the other way – but there you are. The existing case for the NEO does not fit the new model incidentally.

The board DOES have fast Ethernet which is a plus.

So you can log into the board via the FTDI or by normal micro-USB serial. At this point I headed off to the WIKI to get the operating system image..

One thing that worried me – and I’ve complained about this before – the requirements are:  A NEO2 (obviously), a micro TFT card, a power supply and “a computer running Ubuntu 14.04 64 bit” -  FRIENDLYARM  - YOU MUST BE JOKING! Most of us in the west have Microsoft Windows PCs. I do have one PC running Linux – it is running MINT and I’ve no intention of changing that just for one new board!!!

I was a little disappointed to find that the website has only Ubuntu Core available – unlike the M3 and M1 both of which have excellent DEBIAN images which work straight out of the box. Again – this fascination with Ubuntu – a bit disappointing to those of us who like Debian and have used it on previous boards.

At the time of writing, the ARMBIAN site had only nightly releases available and they refer to WIFI – so not exactly customised to this board which by default does not have WIFI !!

So, despite desire for Debian, I downloaded the Ubuntu Core software from the FriendlyArm WIKI site. The image was a mere 244MB in size so took no time to grab.Well, it would have been very quick but their sharing site is not the fastest in the world. I blew the image file with Win32 Disk Imager as usual and plugged it into the NEO 2 board. From what I could read, this would expand on first use and might take some time.

Power on and both the green and blue lights flashed for a moment then the green went full on – and the blue continued to flash. A quick check with Advanced IP Scanner showed the board sitting at 192.168.0.193.

I opened winSCP as usual and I tried logging in as root with password fa.

No problem – straight in. But I realised when running my normal script that SUDO does not exist on this version of the operating system – so that has now been added to the script so the extra half hour starting again was not entirely wasted.

Having ran the script and that having created a PI user – I went off to log in as user PI – loaded and ran the script again. While all of this was running the processor was running at 53c, so depending on use, the heatsink may not be needed after all.

However – it THEN turned out that Friendlyarm were using 15.10 – which is ANCIENT – so -

sudo apt-get update
sudo apt-get upgrade
sudo apt-get dist-upgrade
sudo apt-get install update-manager-core
sudo do-release-upgrade

All of which went swimmingly well – until – the BOOT area ran out of space.  

So it looks like, as things stand, you can’t upgrade to Ubuntu 16.04 – and as their Ubuntu is currently the only option  - I have no option but to say this isn’t a lot of use until better software comes out or that boot area can be increased on the command line without needing a doctorate. Even EASUS won’t let me resize the larger partition to make space for a bigger BOOT area.

I cannot tell you how many times I have impressed on various companies – you cannot just put out hardware without software support – and Ubuntu 16.04 (if you have to use Ubuntu) is pretty standard stuff.

If and when this situation improves I’ll update the blog entry!

The post NanoPi Neo 2 appeared first on Scargill's Tech Blog.

What a great day. Newcastle has an annual Maker Faire and it is on this weekend – and what a faire it is.

I headed off first thing to get some parking and was pleased to find that Newcastle College had some cheap parking - £4 for the day. I arrived 45 minutes to early, thankfully the security guard was a chatty type who wanted to know what all the fuss was about so we filled in time while waiting for my friend Aidan to turn up.

We got talking about cars as that was his thing and so by the time Aidan turned up in his Tesla, the guy was itching to see it and up to his armpits in questions.

The faire started at 10am and we arrived shortly thereafter – it was CHOCKER full of people.

I’m so pleased this has turned out to be a success over the years – there was a time when “makers” – were treated a little dismissively by the public but today everyone wants to come and see what they are up to.

The first thing we came across was a self-balancing one-wheel vehicle and we had a great time talking to the designer – this is not a production job or commercial in any way, he built it because he wanted to – and it works extremely well. Yes, the pad on the front is for “emergencies”.

Rather than design in a modern way, the panelling was very retro – something my friend Melanie-Jane would love to have seen.

As we walked around we were amazed by the variety of stuff people do – from machines that do knitting, to robot hands,to retro gaming machines. A friend of ours Tony was responsible for a mini-version of the PAC-MAN arcade machine, though it had a flat top and I did remind him that the miserable pub people had this changed to round quickly as people were putting their pints on top of the machine. Well, if you’re going to spend all night playing you need somewhere to put your beer!!

Next off we came across an interesting idea – a bunch of clear tubes maybe 12” diameter and 6ft or more high – with air blowing up them. The public was provided with cups. paper plates, glue and sticky tape and invited to design the gadget likely to reach the top of the tube without falling to bits or coming back down. Aidan could not resist the challenge and so while I manned the phone he proceeded to build a very high-tech device – which actually went in – out the top and continued on for some time – no doubt setting a world record – but then – that’s what I’d expect.

If have to say, if you saw the contraption he built, there was no way this was going to fly – but it did! Flimsy as it was the device went into the tube and headed straight up at tremendous speed and cleared the top of the tube by a long way. I’ll bet the kids who were competing were hopping mad. Afraid you can’t beat a gadget man who is also an experienced, qualified pilot…

Big round of applause and we were off to get some coffee before the next challenge..

Next stop, there were LOTS of tables with things that people had made – LOTS of them – some trivial – a few flashing lights – but not this – a genuine mini-version of the old classic, the PDP-8 computer – all done with wood, loving care and a Raspberry Pi.   I’ve been planning to build an IMSAI for some time but this was just wonderful.

There can be no doubt that modern computers are fantastic – and the computers from mid-last century were toys in comparison – but the difference is – you could SEE and understand what they were doing (well, a relatively small number could – most people don’t know how their TV remote works but they’re probably not reading this blog) – it’s almost worth having one of these just as a piece of furniture – in some ways it reminds me of the bank of flashing lights on “Voyage to the bottom of the Sea” or “The Time Tunnel” and similar. But this is a real, working machine. If you can click the image and scale it up – you’ll see it was made with love.

Open source robot hands, open source 3D printers – what a combination. We met up with an old pal of ours Dave Alan – a fellow who I met at the start of the microcomputer revolution – he has speech running on a 6800 processor WAY before the big boys thought of doing it (funny enough I had the same on a PIC and have an award on the wall to prove it – then along came PC speed and that was the end of that).

We saw and had explained a new 3D Printer – no more than £350 inc. VAT which used a new recycled plastic which does not bend and warp like older materials – and I have to say, some of the parts they built with this were almost production quality – a non-technical person would not know the difference between that and a milled plastic part – VERY impressive – and not even a special heated cover over the thing!!!

Want one (but then I want a router and a laser cutter and….)

Among other delights there was a genuine dinosaur wandering around with his (her?) handler. Very impressive. Oh and you see those drawers on the right – wow – I SO miss the old radio rallies and computer shows where people brought their old junk 0 but better, suppliers brought tons of surplus stuff and sold dead cheap.  And so it was that the bearded fellow on the right – SO missed this – he decided to resurrect the idea – he had many dozens of £1 trays (3 for £2) and the prices were REAL bargains – anyway I think he’s called ABX  http://stores.ebay.co.uk/abx-labs

And that was about it – we talked to loads of people including friend Tony at the Newcastle Maker group – I hope to get to go see them in the autumn when we come back to the UK.  A GREAT day out for all the family, good prices on food – which makes a change as sometimes these things are a rip…

If you you are in the area next year, same time I strongly recommend a visit but of course such events are on all the time, all over the western world really. If nothing else you can guarantee that if you put a bunch of techies together – they’ll be dying to tell you how they made their stuff – and that is what makes these events so special. Well done to everyone involved in organising this.

The post Newcastle Maker Faire appeared first on Scargill's Tech Blog.

If you read the blog about the Maker Faire, I just came back with a bag of goodies and one of them is a microwave movement sensor.

Not the two-board solution I discussed a while ago that never really worked – this is a small, neat single board called an RCWL-0516 and here’s a Chinese link though if you get in touch with the fellow I mentioned at the Faire where I got mine – ABX-LABS (Ebay shop) he might have them. About £1 anyway.

So this board has 5 wires and not a lot of information out there, some of which is in Russian. I did found out enough to know that this unit is oscillating at around 3 Gig and you only need to use 3 of the 5 wires!

The unit will pick up movement up to 7m away and in the right circumstances can see right through wood! No silly comments about being irradiated please.

So I set it up on my bench, the 3 wires of interest are ground (obviously) VIN and VOUT. Stick 5v on VIN (will not work on 3v3) and a LED on VOUT – and you’re done – it works.

Well, that was easy and of course it WAS too easy. I took the board and applied it to one of our ESP8266 boards which have 5v – and took the output to Pin 14 which in the case of my software, is a de-bounced input which can send an automatic MQTT message on change.  Job done – except – it would not work. It seemed over-sensitive but after more careful checking – it really wasn’t taking too much notice of movement – instead triggering fairly regularly ALL ON IT’s OWN!  I tried putting a cap across the power, I tried putting a cap across the output – all to no avail.

In the process of having a gripe with Aidan that we’d been ripped, I put the board on my standalone test to show him it working – and decided to route ground and signal back to the ESP – it worked perfectly – then it twigged -  ESP8266 boards are prone to putting spikes on the power lines when transmitting!  I put a 10r resistor in series with the power and a tiny 330u 6v cap to ground at the Microwave board end – problem solved.

Here’s a really informative blog on the subject but the above is really all you need to know. IF you want to do something clever, the 16 pin logic chip – I stuck a scope on it and pin 12 gives off some interesting analog stuff!

In terms of sensitivity it pretty much works 360 degrees though supposedly it is most sensitive on the component side of the board direct on.

I spend half of my time waving my arms about at the normal room IR sensor to keep lights running – this I think will be MUCH better.

Have fun.

The post Microwave for the Weekend appeared first on Scargill's Tech Blog.

Just bought a new Raspberry Pi 3 with WIFI and Bluetooth?  Using it in a project with serial? Happy?

Well, you might not be so happy when you find out what I just found out.  I had my Node-Red project that has been controlling the house for around 18 months on a Pi2 and I was starting to have issues -  I thought it time to upgrade. So I made a new installation, faithfully copied everything over, plugged in the board… everything was fine.

Except it wasn’t – nothing was coming out of the serial port. Well, it turns out they stole the serial port for the Bluetooth. There is a second port – of a kind – which can be set to work with the GPIO pins 14 and 15…  but Node-Red serial node was NOT having it – I put a scope on the output – nothing.  I followed instructions to use an alternative “serial port” – which appeared and – the Node-Red Serial port input would not recognise it.

Anyway, it isn’t all bad – thanks to Dave at IBM who put me onto this link…

http://raspberrypi.stackexchange.com/questions/45570/how-do-i-make-serial-work-on-the-raspberry-pi3

Ignore most of the content and head to the end – Answer number FIVE.  This got me back up and running with a high speed serial port – but – no Bluetooth of course. I’m assuming I can just stick in a Bluetooth dongle – time will tell.

Essentially assuming an up to date Pi3, the key line is the one where you add

dtoverlay=pi3-miniuart-bt”"

to the /boot/config.txt file.

I’m liking FriendlyArm more and more (I’d like them even MORE if they’d put more RAM in their boards) but at least, for today, I’m up and running.

The post Raspberry Pi 3 Serial appeared first on Scargill's Tech Blog.