The Real Raspberry Pi

I’ve been using the likes of FriendlyArm boards and similar for so long now, struggling at first with GPIO and I2c and as regular readers will know, finally pretty much mastering it due to hard research and more importantly, the works of people you’ll find links to in other articles in here….. that I’ve pretty much ignored the actual Raspberry Pi for some time.

Until this week when my friend Jonathan sent me a Raspberry Pi 3 to check, as he’s been having trouble with “the script” and I could not help as my RPI2 installations worked just fine.

Anyway, the RPI3 turned up yesterday and I ran “the script” and it all went perfectly – as it happens he’d resolved his issues in the time it took to get the board from the UK to sunny Spain.

Anyway, last night, as I had a working installation on a Pi3 of Node-Red etc, I thought I’d have a play. I noted I install raspi-io on the “real pi” along with “node-red-contrib-gpio”.  it is so long since I set these up (they only install on “real” pi boards) I had no idea why I left them in as the Pi has it’s own basic GPIO facilities. Anyway I thought I’d give them a go.

Well, of course that killed Node-Red didn’t it.  Incidentally most of us start and stop Node-Red with “node-red-start” and “node-red-stop”… but when testing stuff it REALLY is better to start Node-Red manually (i.e. after stopping with node-red-stop – just run “node-red” as pi user) as you can then watch the messages in a terminal and see WHY it stops when it does (which is very rarely and with good cause in my experience).

Well, it stopped as soon as I tried to use the yellow node-red-contrib-gpio node. I noted in the terminal that this was a tiring “permissions” issue. Re-starting Node-Red did no good at all, I had to actually delete the latest flows file in the .node-red directory to start from fresh – so a note – always back up flows files before experimenting with anything that messes with hardware!!!

Anyway, I contacted the author who replied that in the small print it DOES say you have to run this as root.  Now – someone tell me if I’m wrong, but are we not encouraged NOT to run Node-Red as ROOT!!!!! So what’s the point??? Am I missing something here?

Bear in mind that in “the script” for non-Pi machines – I generally use a new GPIO node Links below) that thanks to changes suggested by the author and implemented in the script by fellow contributor Antonio, this permissions inconvenience is completely bypassed – I’m wondering why this is not the case with that node!!! Again – we’re told NOT to use ROOT in general and the Node-Red guys also recommend it runs as user pi.

Anyway, I put that to one side unless we get some resolution from knowledgeable PI users… and decided I’d try some I2c using the latest I2c stuff I’ve again incorporated into the script.

I’m used to using the Orange-Pi/Nano-Pi modified GPIO utility and so first things first I thought I’d use that to check to see if I’d wired up my i2c peripheral board correctly as gpio is built into the “real” pi.

gpio i2cd

“gpio: Unable to find i2cdetect command: No such file or directory”

What? You must be joking… but this is a genuine Pi and the original GPIO utility for heaven’s sake!!!  It turns out there’s a bug in the genuine version of WiringPi  which will be “fixed in the next release”.

It is worth noting that though the post in the forum above is correct, it neglects to mention the all important act of going into wiringPi directory and running “sudo ./build” followed by a reboot.

So that will have caught a few people out! Hope you’re reading this!

So after the reboot, I ran “gpio i2cd” and sure enough I’d wired SDA and SCL the wrong way with my little peripheral, I reversed the two wires and it now showed up at location 9.  Hurdle one out of the way.

But would recent modifications to the script let me do I2c on the “real” pi?


Yes, without modification, I2c works – using Node-Red as Pi user – now why can’t other stuff work the same way!!! (oh, incidentally, in Raspi-Config you need to ensure that i2c is enabled for this – but then similar action applies to most boards – it’s a one-off trivial action).

So – I’ll wipe the Johnny5 and yellow gpio items from my script – but first – has anyone figured out a way around this root stuff for that gpio contrib node – in the way that we’ve found a way around this for non-Pi boards? There really is no point in installing these nodes if they don’t work for PI users.

As “the script” now has mods to allow GPIO/I2C access for Pi user, I wondered if the new GPIO nodes I use would work – they are based on “ONOFF” and are installed by default when running the script.  Sure enough – though the node does not mention Raspberry Pi, by using “other” and simply referring to the Pi BCM numbers – I could turn pins on and off at will. 

This node set does not yet support PWM, but then like other boards, the Pi only supports “real” PWM on one pin so hardly worth getting excited about.  It appears that the GPIO support I now use is faster than the stuff that comes with the genuine Pi anyway…   and my little Nano peripheral gives you 6 genuine PWM outputs anyway (you could always modify that code for the larger chip and get LOADS of PWM) and for lighting does a better job (soft fade for RGB etc). Here’s a little board we found recently which would make a nice peripheral but cost-wise no-where near as good value as the Nano.

I wrote this blog entry as I was discovering the issues and working solutions –  worthwhile I think…

and on the subject of Node-Red and checking the logs – Antonio just pointed out a little script he wrote – which when run shows a nice colour-coded version of the Node-Red logs and “tails” it – so you can see new events in a terminal, in colour, regardless of whether Node-Red is started manually or automatically..

colour logs


8 thoughts on “The Real Raspberry Pi

  1. Peter,

    If you “will wipe the Johnny5 and yellow gpio items from my script”, have you found any other way to control I2C OLED or Rotary Encoder? Already spent a week, at least got blinking Led with J5 (unfortunately with root user) but not much success with other stuff.

    1. should on other too, but at the moment it’s the only version available… dietpi still relies on jessie or xenial… the problematic boards could be the ones with arm64 arch…

  2. please test this simple but effective node-red setup backup script and suggest improvements…
    it will create a folder structure as follows in your home folder, and you can run it before doing “heavy” or problematic updates… it’s safe, it does not affect any system file, just creates copies… can be scheduled or even triggered by an exec node… i put there only the files/folders we actually use or alter someway, not everything we include in script (example, no apache backup as our setup is pretty static and can be easy remade using the script)…


Comments are closed.