Node-Red 1.0 b3 Trials

Node-Red 1.0 Betas

This one is only for Raspberry Pi / Node-Red fans. ALL SORTED - everything works – so this is here merely to help others and maybe to encourage a better setup for I2C, RPI GPIO in Node-Red 1.0 official, serial and SQLITE3? Here’s a thing – don’t even THINK about upgrading without making backups first. For the record at this point at the time of originally writing this, I was running Node-Red 1.00 Beta 3 on a Raspberry Pi 4. Now I'm running Beta 4.

Until recently I thought I was fully up to date with my NodeJS and npm installations. I just happened to be looking at NotEnoughTech videos...

npm –v  produced npm 6.11.3
nodejs produced nodejs 10.16.3

i.e. pretty much up to date or so I thought... (that's what I get for thinking). I am however right now sticking with those versions.

I was until this point of course using Node-Red 0.20.8 – the latest OFFICIAL release at the time of writing… and I was very happy with it… but…

So…

sudo apt-get update
sudo apt-get upgrade

So I followed the instructions at NotEnoughTech…

curl -sL https://deb.nodesource.com/setup_12.x | sudo bash -

At the end of that are instructions for installing the YARN package manager - so I duly followed instructions.

curl -sL https://dl.yarnpkg.com/debian/pubkey.gpg | sudo apt-key add -
echo "deb https://dl.yarnpkg.com/debian/ stable main" | sudo tee /etc/apt/sources.list.d/yarn.list
deb https://dl.yarnpkg.com/debian/ stable main
sudo apt-get update && sudo apt-get install yarn
sudo apt-get install -y nodejs

sudo npm install -g npm@next

sudo npm install -g --unsafe-perm node-red@next

At this point I sensibly stopped Node-Red and started again – no way was it going to work. Setting.js was having none of it - something about i2c... so I tried...

npm rebuild

After a lot of warnings (and I mean a LOT) from the sqlite3 install  -

I tried:

sudo npm install -g --unsafe-perm node-red@next

Nope...

npm install

No good- so I moved into the .node-red directory

npm install

More gripes about vulnerabilities..... and ultimately failure

I made sure node-red-was stopped…  and in the .node-red directory

npm rebuild sqlite3

That took SEVERAL minutes to complete. I started node-red and...

SQLITE3 install FAILED "probably due to a problem with npm

Again in the .node-red directory

npm install serialport
npm install node-red-node-pi-gpio

At this point I was left merely with sqlitedb and sqlite failing
In .node-red/node_modules I wiped sqlite folders (rm -r sqlite  then rm -r sqlite3)

npm rebuild sqlite3

NO problem this time.

Serialport seemed missing but it wasn't stopping anything. Indeed the only thing not fixable seemed to be the dark theme. I commented that section in settings.js

I removed the serialport directory (same technique) from my .node-red/node_modules folder

This time  I tried in the PI folder.

npm rebuild sqlite3
npm install serialport

And everything WORKED - just i2c to go and my favouite dark theme...

Hurray… a check of Node-Red and the dashboard showed all was well.

But no, although everything SEEMED to work and this was an almost up to date installation anyway (a 2 day old clone). I stopped NR and replaced the flow file in Node-Red with the one out of my current working installation. Everything seemed FINE.

See my desk light setup,  a bodge right now as I’m working on replacing one light with another and hence running both..

msg.topic="newred/toesp";
var tmp=msg.payload;
if (msg.payload=="0") msg.payload="{rgbperm:0,0,0,0,128}";
else msg.payload="{rgbperm:0,"+ global.get("deskRed") + "," + global.get("deskGreen") + "," + global.get("deskBlue") + ",120}";
node.send(msg);

msg.payload=tmp;
msg.topic="relay_board/toesp";
if (msg.payload=="0") msg.payload="{rgbperm:15,0,0,0,128}";
else msg.payload="{rgbperm:15,"+ global.get("deskRed") + "," + global.get("deskGreen") + "," + global.get("deskBlue") + ",60}";
node.send(msg);

That first FUNCTION turns 2 ESP12 RGB lighting control boards and hence LED strips on and off – “newred” and “relay_board”.

This second function controls the colours…

global.set("deskRed",parseInt(msg.payload.substring(1,3),16));
global.set("deskGreen",parseInt(msg.payload.substring(3,5),16));
global.set("deskBlue",parseInt(msg.payload.substring(5,7),16));

msg.topic="relay_board/toesp";
msg.payload="{rgbperm:15,"+ global.get("deskRed") + "," + global.get("deskGreen") + "," + global.get("deskBlue") + ",60}";
node.send(msg);
msg.topic="newred/toesp";
msg.payload="{rgbperm:0,"+ global.get("deskRed") + "," + global.get("deskGreen") + "," + global.get("deskBlue") + ",120}";
node.send(msg);

They BOTH feed out to MQTT nodes – and on test I ALSO fed them out to DEBUG nodes.

These work a TREAT and thanks to NR persistence even survive power cycling….

Note that in one function the order as to which board gets  processed FIRST is opposite to that of the other function – not for any good reason.

A strange thing happened.. in Node-Red 1.0b3, both functions worked, both put out 2 results to the debug node….. but in BOTH cases ONLY the SECOND result was processed by the MQTT node even though both results sent out to the DEBUG node. As identical info went to the debug node and MQTT node, I can only surmise for now that somehow Node-Red 1.0s  handling of the MQTT node has changed – I’ve  no idea how this has changed but have reverted back to 0.20.8 for now.

Note that in the upgrade, at no time did any issues appear with the MQTT node…  this is a worry.

AND it gets easier to see the problem – but no easier to fix. Check out my Alexa handling..

tmp8E05

and the code..

global.set("deskRed",msg.rgb[0]);
global.set("deskGreen",msg.rgb[1]);
global.set("deskBlue",msg.rgb[2]);

var tmp=msg.payload;

msg.topic="newred/toesp";
if (msg.payload=="off") msg.payload="{rgbperm:0,0,0,0,128}";
else msg.payload="{rgbperm:0,"+ global.get("deskRed") + "," + global.get("deskGreen") + "," + global.get("deskBlue") + ",120}";
node.send(msg);

msg.payload=tmp;
msg.topic="relay_board/toesp";
if (msg.payload=="off") msg.payload="{rgbperm:15,0,0,0,128}";
else msg.payload="{rgbperm:15,"+ global.get("deskRed") + "," + global.get("deskGreen") + "," + global.get("deskBlue") + ",120}";
node.send(msg);

Turn on/off or change colour- only the second board is working….  but debug indicates both should work…

image

But only relay_board is working… so I’ll swap them around…

image

Colour change or on-off – makes no difference, though both sets of commands are appearing in the debug node, only the second set are being acted upon my MQTT.

And I just tested, splitting the function into two functions, both identical but for which board they are talking to – WORKS.

SO it is the twin node.sends that is the problem – but only for MQTT – not for DEBUG…

I even tried adding THIS to the settings.js file at the start – probably the wrong place…

runtimeSyncDelivery: true;

No effect. It is possible I put this in the wrong place…. someone tell me if I did.

It is now clear thanks to Nick at IBM – that the new async nature of NR 1.0 means that the first message could be reused BEFORE the MQTT node can handle the first one (debug will be a lot faster) – so the answer is to use a new message for the second SEND.

That’s all sorted but ultimately my first attempt at installing the Node-Red BETA3 failed after all that (thank heavens for rpi-clone) and I decided to start from scratch as sqlite3 simply was not having the nodejs and npm updates.

So – one day later and having gotten the async issues out of the way by making sure my flows use separate message objects for each node.send(msg) call.., here goes… but having gone back to Node-Red 0.20.8 as a working base…

sudo npm install -g --unsafe-perm node-red@next

This worked first time, all but for gpio (the IBM guys did warn about this).

So – in the palette manager – I installed node-red-node-pi-gpio

All seemed well apart from my midnight theme (again this was warned about – so I went on to remove it and restart Node-Red).

This time I ensured I picked the right version or the midnight theme (updated October 2019)

cd ~/.node-red
npm install node-red-contrib-theme-midnight-red

and (this time correctly - and updated October 2019) adapted the editorTheme section of my settings.js

editorTheme: {
page: {
        css: "<HOME>/.node-red/node_modules/node-red-contrib-theme-midnight-red/midnight.css"
}
}

All working up to now including SQLITE3, serialport, gpio etc. So I DID have to adjust my flows for the async nature of Nod-Red 1.0B3, but it looks like my other issues were caused mainly by going for a change of NODE versions. 

In the end, that midnight-red theme did not seem to operate properly with NR 1.0 B3 or at least the colours in the debug node were awful, now fixed in the latest version of the theme. You'll see my comments in the Mauricio Bonani's GIThub repository.

Facebooktwitterpinterestlinkedin

27 thoughts on “Node-Red 1.0 b3 Trials

    1. Need to NOT re-use the same mdsg as I was. My LCD displays also have several node.sends in a function using the same msg. I found out tonight before going to the pub that this too was failing. I changed to separate messages – fixed. A better way would be to be able to turn off async on a function by function basis, Don’t think you can do that. OH, the IBM guys are working on a “fix” for this issue – nearly forgot. That might be the “fix” – not sure.

  1. Thanks Pete, I’m about to go the same route (B3) but I’m building a docker container (Linux x86) for it so I can do some testing first. I did this to test the dev version of my nodes. Work pretty well as I can have both on the same machine (ports get remapped on the container). I’d hear no end of complaints from the CFO (my wife) if I broke things. 🙂

    I’ll reread this, seems there are more than a few extras that need to be @next. Not sure if I’m using the same dark theme.

    1. Hi Neil

      The dark theme I used at the end of the day is no good – the degug window is dark as you’d expect but the text is also mostly too dark to use. I tried replacing a couple of css elements and nothing happened. I’m no CSS wiz so that might be me picking the wrong ones or his css file isn’t working. I reluctantly had to go back to the default theme for 1.0 B3. If you know better please do let me know. I really would like to use a dark theme.

  2. Hi Pete, thanks so much for this great tool. I am using it with succes to make an improvised wake-up light for my 2 year old 🙂

    I’ve noticed 2 little things though:

    1) I don’t need to define lat and long for my use case, as my computer clock is correct and I’m not using any geo-location related features. Yet the node continues to show as incorrectly configured as long as I don’t fill in those values, which means I get a warning message on each deploy. I can of course fill them in to avoid this issue, but I don’t feel that should be necessary.

    2) The topic field does not like my message topic “zigbee/${ieeeAddr}”. Everything works fine, but the node shows as incorrectly configured as long as I use that topic, which also causes the warning message on deploy.

    Very minor things as I said, but not having to clear the warning message on every deploy would be a relief. 🙂

    Thanks again!

    1. Thanks for that Steve, it did catch me out. I’m basically a C programmer who has adopted JS mainly because of Node-Red. Indeed I’m not even a programmer in the large-business sense though I have often single handedly written some huge programs in my time….

      During my working career in small businesses (very small businesses harbour the majority of employment I may add) I’ve been programmer, hardware designer and builder, accounts officer and chief bottle-washer, all at the same time and so I don’t think it unreasonable that I might have missed such an issue of asynchronicity – there will be many others out there – I’m glad to see that those of us who not completely steeped in the fine details of Javascript will, after all, continue to be at least considered. If any non-JS programmers are reading this, how do YOU feel about this? “a=b; b= NOT b;” Does it seem reasonable to you that after that second statement, “a” will be screwed? It isn’t intuitive to me. It seems to me that once asssigned, “a” should have a life of it’s own. I’m happy to learn something new but would not be happy to have to re-write lots of code that has worked for years.

      In many languages, objects can be relied on to be independent and I think it is reasonable to think that JS would be the same but clearly it isn’t the case. In terms of an NR roadmap, it is great that Nick has written that they are going to cater for this incorrect assumption but it also seems clear that they WEREN’T going to do that, otherwise, why did they stop the cloning for v 1.0 beta – after re-using the msg object had worked so sucessfully all the way up to 0.20.8?

      I’ve been using Node-Red almost since the beginning (tell me if I’m wrong, what, 4+ years ago?} and done multiple node.sends in a function as a matter of course and it is only now in the 1.0 beta that this broke. I think they’ve now made the right decision (I’m assuming probably incorrectly that this is down to Nick and Dave), I do wish he’d blogged WHEN they’ll revert back to the behaviour we’ve all known to love. Personally I could give two hoots whether that represents “proper” Javascript behaviour. I use JS only because there is no other option within NR.

      The sooner the better for me.

      1. H Pete – I suspect this change will happen very quickly as its that most dangerous of breaking changes to existing flows – the one that doesn’t happen all the time and they are not obviously broken. The way the notice is phrased suggests you were one of the early highlighters of the issue. I take your point about Javascript, I have a similar programming background and it is striking that my C++ reference is A5 and 70 pages whereas the Javascript reference is A4 and 900+ pages – still if it was easy we wouldn’t need to follow you for guidance.

  3. Hello Pete

    having now completely gone over to Buster ran your script ok no problems.

    Copied all my flows etc, set up nginx as per Mr Sharks script (except pear needs “PHP-pear in script. Every thing working checked out and 3 weeks testing. Now tried the script for node-red as here.

    pi@rpi4buster:~ $ node-red-stop

    Stop Node-RED

    Use node-red-start to start Node-RED again

    pi@rpi4buster:~ $ sudo npm install -g –unsafe-perm node-red@next
    npm ERR! arg Argument starts with non-ascii dash, this is probably invalid: [ ‘– unsafe-perm’, ‘node-red@next’ ]
    npm ERR! code EINVALIDTAGNAME
    npm ERR! Invalid tag name “–unsafe-perm”: Tags may not have any characters that encodeURIComponent encodes.
    pi@rpi4buster:/ $ apt-cache policy nodejs
    nodejs:
    Installed: 10.16.3-1nodesource1
    Candidate: 10.16.3-1nodesource1
    Version table:
    *** 10.16.3-1nodesource1 500
    500 https://deb.nodesource.com/node_10.x buster/main armhf Packages
    100 /var/lib/dpkg/status
    10.15.2~dfsg-2+rpi1 500
    500 http://raspbian.raspberrypi.org/raspbian buster/main armhf Packages

    Can any one enlighten me as to why this result???

    regards Brian

  4. Hello Mr Shark

    thanks for quick reply
    I tried again but same result.

    Eventually got nano to open log file in root/.npm

    here result
    0 info it worked if it ends with ok
    1 verbose cli [ ‘/usr/bin/node’,
    1 verbose cli ‘/usr/bin/npm’,
    1 verbose cli ‘install’,
    1 verbose cli ‘-g’,
    1 verbose cli ‘–unsafe-perm’,
    1 verbose cli ‘node-red@next’ ]
    2 info using npm@6.11.2
    3 info using node@v10.16.3
    4 verbose npm-session 1fc416a01c874149
    5 error arg Argument starts with non-ascii dash, this is probably invalid: [ ‘–$
    6 silly install loadCurrentTree
    7 silly install readGlobalPackageData
    8 silly fetchPackageMetaData error for node-red@next install –unsafe-perm node-$
    9 timing stage:rollbackFailedOptional Completed in 75ms
    10 timing stage:runTopLevelLifecycles Completed in 192ms
    11 verbose stack Error: Invalid tag name “–unsafe-perm”: Tags may not have any $
    11 verbose stack at invalidTagName (/usr/lib/node_modules/npm/node_modules/$
    11 verbose stack at fromRegistry (/usr/lib/node_modules/npm/node_modules/np$

    *************
    Log says Index 5 dash non asci = -unsafe copied from blog again and overwrite –unsafe
    ***********

    Run again
    pi@rpi4buster:~ $ sudo npm install -g -unsafe-perm node-red@next
    /usr/bin/node-red -> /usr/lib/node_modules/node-red/red.js
    /usr/bin/node-red-pi -> /usr/lib/node_modules/node-red/bin/node-red-pi
    + node-red@1.0.0-beta.4
    removed 38 packages and updated 15 packages in 29.93s

    That will teach me not to be lazy and just copy printed text.
    I cant see any difference between – and – but their must have been!!

    Once more thanks

    Regards Brian

      1. V1.0 beta 4 is out. Problem solved so it seems. I can’t test on my phone.. as I just realised another potential issue.. on my Android phones and tablets I cannot switch tabs in Node Red. Someone tell me I’m missing something.

  5. hello Pete

    I am running V1.0 beta 4 since yesterday. I thought I had messed up as I can confirm on android 9 I am running node-red ui ok and switching tabs, BUT
    +++++++ I cannot get get node-red flow.
    I get title Node-red on black background with thw red signature for it with a blank screen

    All works on windows 7 as normal

    regards Brian

  6. Hello Pete

    Update just tried on firefox and after a few seconds up came node-red flow. I tried on Chrome again which is my normal on Android NO GO same problem

    On Android 9
    So by firefox works.
    By Chrome does not work

    On windows I use firefox -works
    I ried Chrome on windows – works

    Can you confirm if your problem is similar

    regards Brian

  7. hello Pete
    last update
    since I tried Node-Red Persistence change (see comments) and took it out again

    I no longer get node-red flow on firefox in Android
    just get the label as described before.

    ui still workson both and can change tabs

    On Android 9 flows
    So by firefox does not work.
    By Chrome does not work

    Windows still works with ui and flow on firefox and chrome

    regards Brian

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.