This one is only for Raspberry Pi / Node-Red fans. SORTED – so this is here to help others and maybe to encourage a better setup for I2C, serial and SQLITE3?
Until today I thought I was fully up to date with NodeJS and npm. 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.
I am of course using Node-Red 0.20.8 – the latest OFFICIAL release… and 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 that 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, it’s 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 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 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 image]()
But only relay_board is working… so I’ll swap them around…
![image 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.
![Share on Facebook Facebook]()
![Pin it with Pinterest pinterest]()
![Share on Linkedin linkedin]()
The post Node-Red 1.0 b3 Woes appeared first on Scargill's Tech Blog.