Archive for the Orange Pi Category


Posted in C.H.I.P., Linux, Orange Pi on July 22, 2017 by asteriondaedalus

So, here it is Sunday.

Morning coffee in hand while I wake up.

Dogs still asleep but will be doing backflips once they hear me getting their leads out for the Sunday bush walk.

OPiZ still up, node-red console full of reports of reboot every 5 odd minutes.

Since it has been in this reboot cycle since Friday night I am happy enough the nodejs, node-red, npm combo is not the contributing factor to the ethernet and usb stopping.

After the walk I will … well I will have a nap.  But after the nap I will … well I will build another C.H.I.P. with shairpoint-sync for the second sound bar.

Later tonight I might have another go at the emqttd install on the OPiZ.

I am still not sure how that might induce the dropping  of devices, but it in hindsight there is a conspicuous connection since the problems seemed to start once I had installed and was running the emqttd – that observation holds over the at least a dozen times I re-burnt then setup a distro for the OPiZ.

Curious, because these are the exact same steps to set up a Raspingdoodleburry Pi or ODROID-W with the same combo of app – neither with any problems with devices dropping.

Setting up node-red yet again

Posted in Linux, Orange Pi on July 20, 2017 by asteriondaedalus

Are you still with me? I wouldn’t be, it’s been such a pain. Because network manager appears flaky somehow.

On the distro the /etc/network/interfaces file told you directly to use network manager and nmtui. This intimated that you couldn’t edit up the interfaces file.

I got no joy when I edited the interfaces file, while trying to get around the flakiness that appeared to be incurred, but that could because network manager was the default service – and was not reading the file??

Now, on the distro, it looks like you can use nmtui/nmcli optionally but, of course, we have seen the network connection collapse.

Now I didn’t look to see if at some point /etc/resolv.conf was set by network manager to some flaky value and therefore breaking the connection.

Now we have that up our sleeves as we try try yet again again.

Yes, I have an alcoholic beverage on hand.

So distro installed and static IP setup.

First step, install node-red.

I will leave the system running until Sunday before I try installing emqttd as I want to give it a good burn in to make sure there isn’t something in the node-red install breaking the ethernet.

To stress the distro I set up a cyclic reboot in node-red with the following:


I just set an interval of 5 minutes on the injector.  The debug node will scribble the timestamp on the debug console when the interval lapses.  At the same time the OPiZ is rebooted.

Not a sausage?

Posted in Linux, Orange Pi on July 20, 2017 by asteriondaedalus

So, I reburnt the SD with the distro.

I gave up on nmcli/nmtui and I went back to the good ole /etc/network/interfaces edit, or at least I created:


Set the contents to:

auto eth0
allow-hotplug eth0
iface eth0 inet static
dns-nameservers …

When I set up I now happily get:

root@OrangePizero:~# ip addr show
2: eth0: mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether f6:78:ae:aa:0a:d8 brd ff:ff:ff:ff:ff:ff
inet brd scope global eth0
inet6 fe80::f478:aeff:feaa:ad8/64 scope link
valid_lft forever preferred_lft forever

So, board seems to setup the eth0 as I want it to.

However, my network simply does not see the board.

I have a bag of short ethernet jumpers from aliexpress … hmmmm … nope.  I swap a few out so unless they have sent me a dozen dud ethernet cables it isn’t the ethernet cable.

So, it looks like the problem might have been that I had the following

auto eth0
allow-hotplug eth0
iface eth0 inet static

I commented out the hotplug line, rebooted then voila!  My OPiZ was “seen” on my local lan again.

But …

… still can’t get out to the world???

Well, apt-get doesn’t resolve.  A ping to fails.  A ping to succeeds ???

root@OrangePizero:~# route -n
Kernel IP routing table

Destination Gateway Genmask Flags Metric Ref Use Iface UG 0 0 0 eth0 UG 1024 0 0 eth0 U 0 0 0 eth0

So, why am I not getting out?

root@OrangePizero:~# ifconfig eth0
eth0 Link encap:Ethernet HWaddr f6:78:ae:aa:0a:d8
inet addr: Bcast: Mask:
inet6 addr: fe80::f478:aeff:feaa:ad8/64 Scope:Link
RX packets:1559 errors:0 dropped:172 overruns:0 frame:0
TX packets:489 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:246564 (240.7 KiB) TX bytes:37710 (36.8 KiB)

So, I note I can ping from my PC and I can ping the OPiZ from my PC.

I can ping my PC from my OPiZ.

Ah ha.


is set to:

#the following is set by network manager

So, that won’t work on my network given the ISP router provides two nameserver addresses before you would bother with the free nameservers. Not to mention my gateway is and so the dns requests were getting nowhere.

So I manually set up resolve.conf to two name servers given by my ISP and the two free ones (to be sure, to be sure).

Happily now pinging

I have run apt-get update again.

Ready to start all over again … again.

All this as the node-red was running fine but the network went kaput on the OPiZ somewhere in the middle of the emqttd install.

I can’t put my finger on when during the emqttd install, but there were all the problems with wget and then I did twiddle with certificates. However, why on earth would that blow away my network configuration???

No useful hypothesis as yet so I will check regularly during the emqttd install steps if see if/when the connection breaks.

I also installed a watchdog node into node-red and set up a 10 minute timer to reboot the OPiZ to stress it.  If it is up on Sunday after all those reboots we can likely discount the node-red and I guess the npm as the culprits.

github is not southern hemisphere friendly

Posted in Orange Pi, Sucky service Providers, The downside of Opensource on July 8, 2017 by asteriondaedalus

So, as I mentioned last night.  As usual, if you are up late and fiddling with access to code from git you will likely get either unresolved host github, or the new thing which is a problem with certificates which is as likely to do with a timing thing and then again to do with host resolution.

This morning I ran make again and it breezed passed the point it got stuck on last night.

It’s the same time-of-day related behaviour I have seen when running git from my PC.

And now for emqttd …

Posted in Linux, MQTT, Orange Pi on July 8, 2017 by asteriondaedalus

… again.

So, we buzzed out how to install emqttd on a OPiZ that was fragged by insertion of an expansion board so it, for some crazy reason, would not boot from debian server distro but would, but with clapped out device behaviour, using debian server distro.

Now we are back, with a new OPiZ board, no I said NO expansion board, and we have gone back to debian server distro.

So, some subtleties between the two distros. distro must have had build tools installed as git and make were already on board.  The other quirk is wget on orangepi will report unknown certificates when using wget.   That aside, we are up againt and the distro seems happy as long as expansion board has never been inserted into the main board.

So for emqttd you will need git and build-essentials so please install with:

  1. apt-get git build-essentials

Now we need erlang:

  1. wget
  2. dpkg -i erlang-solutions_1.0_all.deb
  3. rm erlang-solutions_1.0_all.deb
  4. apt-get update
  5. apt-get install erlang erlang-dev

Now previously we have had elixir on the end of line 6 but the emqttd build (to follow) is a bad citizen and builds elixir again over the top so no point cluttering the system.

Now we go downhill again.

So, I downloaded emqttd with:

git clone
cd emq-relx && make

But, when I ran make I started getting those rotten messages that hinted that the ethernet was down – couldn’t resolve inet addresses.

I ran route and I seemed to have a connection.  I did, however, loose connection from the browser to the red-node despite pm2 show telling me node-red was running??

When I took a peek at my wifi extender settings the OPiZ IP was no longer reported.

I rebooted, node-red was there again, route seemed to show things were fine BUT my wifi extender settings were still not showing the OPiZ IP.

git was flaky too.  I started getting certificate errors??  The error was:

server certificate verification failed. 
CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none

So, there are ways to fix this but not any explanations of what caused it.  This is a fresh distro, with a fresh install of git, so I haven’t played around with config.

There was some chatter about certificates being time sensitive so problems with NTP??

So I am wondering if this is what I have seen with git before, not southern hemisphere friendly – after all here I am after midnight.

I did do something naughty.

I found you could turn certificates off for git.

So I did, emqttd then did start but clapped out not long after.

Each time “can’t resolve host github”

I pinged successfully so I know that I am on the net.  I can’t, as usual, connect to github.

So, I was at a loss.

Given my background in embedded systems and testing I had to do what I normally did.

That is, nothing was too silly.

Go figure, I had been bugged by a difference between the previous fiddling and now that was really subliminal.

I had come across a syntactic sugar for netmask, for example a netmask of would crop up at the end of your host IP as /24 but for some reason the netmask set by nmtui when using distro was /32.

Now I am not saying that that was what the problem was but changing the /32 to /24 in the static IP seems to have sorted the “missing” IP address of the OPiZ on my extender config window.


Nope, the following morning I am not seeing the OPiZ on the networking but it is happily connected to the internet???  Although, I am still having problems with host resolution of github and having to run make multiple times.


It hasn’t helped with the github “missing” but re-running make, as it did last time, seems to muddle through – which again suggests a problem with the load on the github servers dropping connections.

It doesn’t seem to happen here in the day time.

Starting afresh

Posted in Linux, Orange Pi on July 6, 2017 by asteriondaedalus

Throw out OrangePi Zero board that was fragged when expansion board was inserted.

Full story.

Take brand spanking new Orange Pi Zero from wrapper.

Set up 3-pin serial.

Use 2amp power supply.

Burn orange pi debian server distro from site (not the distro from the site) onto SD card using Etcher (so it reports SD verified).

Then login and:

  1. setup static IP with nmtui
  2. reboot so that static IP takes
  3. apt-get update

So far so good.  The apt-get call is also a check you are on the net, or before using apt-get you could use:


Next, I went to download the nodejs binaries as before but got an authentication error message.

So I thought, what the hell, just use apt-get install.

Nope, as before the install aborted so likely this has not got an Orange Pi Zero “flavour” set up.

Back to the binary download.

wget baulked but I recall there is a way to set up the authentication to allow the file to be picked up by wget.


Raises an unknown certificate error.

But the trick (if you trust the site and you don’t care to fiddle with certificates) is:

wget --no-check-certificate https:...

So we continue with:

  1. wget –no-check-certificate
  2. tar -xf node-v6.11.0-linux-armv7l.tar.xz –directory /usr/local –strip-components 1
  3. node -v
  4. npm -v
  5. npm cache clean
  6. npm install -g –unsafe-perm node-red
  7. node-red

So again check by browsing in from your PC to the OrangePi Zero at whatever static IP you set up.

  1. ^C
  2. npm install -g pm2
  3. whereis node-red
    node-red: /usr/local/bin/node-red
  4. pm2 start /usr/local/bin/node-red –node-args=”–max-old-space-size=128″ — -v
  5. pm2 save
  6. pm2 startup
  7. export PM2_HOME=”/root/.pm2″ 
  8. reboot 

So again check by browsing in from your PC to the OrangePi Zero at whatever static IP you set up.

Next time we’ll build emqttd (again *groan*)

As an aside, when I changed the hostname using nmtui I discovered that /etc/hosts wasn’t changed.

No biggy but I only found it through the failed attempts to get nodejs to install via apt-get.

This occurred because you need to register the location of the nodejs package using curl.

The error curl was raising being “host house not resolved”.

That in itself gives you interesting insight into how curl works but also a reminder that the hostname is set in various places (very clumbsy) and nmtui doesn’t bother dealing with that – so you have to remember to chase down wherever the hostname for your host is set on that host.

The other aside, since I had setup my PC now with a static IP I added it to /etc/hosts on the OPiZ just in case I ever go to add something that would lean on that.


Posted in Armbian, Linux, Orange Pi on July 6, 2017 by asteriondaedalus

So, now with 3 pin serial and I have changed power supply (just in case that was the problem).

I have a 2amp USB powerpack from my Samsung phone so that factors out power since problems persist even with the fragged board running on the new powerpack.

The thing is with the 3-pin serial in I can see what I worked out weeks ago.  The system-load-modules.service wasn’t starting on the fragged board.

It doesn’t start out of the box with a fresh burnt Armbian – either 5.25 or 5.30.  I only noticed this after the fragging so until I try this on one of the new boards who knows whether this is triggered by the fragging.

I had seen that earlier in my investigations but it never started and I could, for a time, set static IP etc.

I note using nmtui ‘Wired connection 1’ I get the error:

Could not activate connection ... connection not available on device eth0

So, there is something with the ethernet chip?


I swapped in one of the new boards and same problem – system-load-modules was not starting and nmtui was not saving eth0 config or it was being dropped because you could not get a connection to the device.

So it is definitely something with the Armbian distro since it is on both fragged board and the new board (that has not had an expansion card inserted).

I will burn 5.30 onto SD again and boot fresh again to see again whether system-load-modules comes up on the new board.

Er …

No wait, what I will try is burning the SD with the distro.

Recall fragged board won’t boot at all post insertion of expansion card – and hence the assumption the orange pi zero had been fragged.


New board boots with distro, old board does not boot with the exact same SD card – yes burnt with Etcher.

Case closed.

The orangepi zero was fragged by the expansion board.

That was my initial hypothesis.

All the other problems are the Armbian distro.

Pity I am not welcome on their forum to help sort this.


So, original OrangePi Zero is in bin.

Two new boards on hand.

I will re-build one of the new boards with node-red and emqttd to be the house automation server and then get back to sorting the house automation and finish rebuilding the cluster with the recovered ODROID-C1 and new parallella.