Oh my Oh Pi revisited

Reminiscing over older posts I did find one where I had got the shitzup with the Orange Pi zero dropping the network connection.

DOH!

We know now that, as it turned out, I was finding the occasional dropping out of the Raspingdoodleburry Pi (or RPi) that I purchased, having reluctantly relented on my position of avoiding monopolies. The RPi then replacing the OPi as the home server. I replaced the OPi ostensibly because I had the shitzup thinking it was the OPi was the problem (given the raft of problems I had initially with a fragged board and then some).

Tick, tick, tick, tick, …. , DING!

I did (accidently) fall into a solution for the RPi disconnecting occasionally from the wifi. The problem being there was a race between the RPi and the Foxtel box for the same IP address. That sorted, that pesky RPi has now been mostly rock solid.

I am comfortable, looking back, the poor old OPi was having the same problem, since it had been previously allocated the home server IP address I had cooked up. I, of course, gave that IP address to the RPi when I set it up.

DOH!

Poor old much maligned OPi zero.

He’s baaa … ack!

My Armbian troll, the moderator on Armbian who banned me from Armbian forum because I pointed out he was off topic and providing “interesting” but unrelated factoids, has popped up on Orange PI forum.  My Armbian troll has tagged my observations about the lack of readiness of Ubuntu CORE 16 and snap generally on Orange Pi Zero.

 

 

 

Don’t use OPiZ Ubuntu CORE or Snap for business critical applications

On the Orange Pi Zero version there appears to be a problem with the Ubuntu CORE update mechanism if there are delays on the lan/internet.

Whenever I try connecting to ubuntu core device at night time southern hemisphere I will often get a snap does not exist message or connection timeout with some message about missing headers. This is likely round trip problem over the internet over distances or server loading.  It get the same behaviour on my PC late at night if I try to connect to github during the week.  It might also be a local server being thrashed at night here by overseas being awake.  Same same.

This morning (saturday morning southern hemisphere and northern hemisphere asleep) I reburnt the Ubuntu CORE 16 Orange Pi Zero onto SD, loaded it, started device, let device go through it’s obligatory first update and it came back up! That is it did not lock into config loop after update came through.  I was able to get mosquitto and node-red snapped in without lan error messages.

This lan connection problem indicates that the update, also prone to having to travel across internet, is sensitive to timeouts and frags the device that is updating.

The only solution, since you cannot avoid the updates, is to set the updates to quiet time in northern hemisphere.  That will NOT guarantee you won’t frag the device – since it would only take a timeout during update to frag it.

The other problem persists, however.  That is the device drops off the LAN.  Although I think this is the reboot after successful update.  It just goes off line way too long and at random times.

As I am after a server up all the time I settled for the latest Armbian Bionic which, coincidently, allows you to install and run snapd daemon required to use snaps.  This does not act as a device the same why CORE does, or at least it does not cycle through random restarts.

I was able to snap mosquitto onto the Armbian Bionic OPiZ.  However, node-red for armhf is in –beta only and that is the node-red that would not start as service on Ubuntu CORE 16.  At least we are back to one and only one problem.  The node-red team are sorting it.  I simply went back to install nodejs, node-red and pm2 as per the hand built way.

I will revisit if node-red snap for armhf is fixed.

Although, I think also I might have to get my head around the role of CORE.  As it is for IOT I likely should not use it for a server per se.  I will investigate snapd onto an Armbian mix, however, as that would suit for a server – I think.

Slowly

So, 4 days ago I reported to node-red group that the –beta snap of node-red did not start as a service on armf version – at least when snapped onto Ubuntu Core 16 running on Orange Pi Zero.

When I started this journey, the following command would not download a snap but it would prompt:

sudo snap install node-red

The prompt would report there is no –stable version and I had to choose between –beta or –edge.

In fact, the snapcraft.io site also confirmed this as it only had a beta or edge version in the drop down for armf.

So I would install node-red with:

sudo snap install --beta node-red

But, as I mentioned, it did not start a node-red editor on :1880.

If I used the following:

snap services

It would report the mosquitto snap I snapped in was indeed running a service.

Et voila! If I typed the following:

sudo snap run node-red

Then node-red would run in foreground.

Not much use since it needed to run as a service.

Starting node-red as a service is easy peasy, if you read the help file, with:

sudo snap start node-red

Except, that raised the error “node-red ain’t got no stinking services to run” which confirmed that the –beta snap for node-red, at least the armf version, had something funky going on.

Curiously, on my freshly built laptop running amd64 version of debian 9 stretch, with snapd installed, the snap of –beta node-red ran as service immediately after install.

That points definitely to something funky going on in the armf Ubuntu Core 16 OPiZ combination.

Then, as likely because of my prompting, node-red community pushed a –stable version of node-red out to snapcraft.io (something like 4 hours ago as I type).   The youngest version, –edge, was 6 months ago.

So node-red didn’t have a –stable for armf!!  Some problem with their build (apparently).

Working with node-red community now to sort this.  Such a good Citizen I am.

 

 

It’s a form of self flaggelation …

… this snap stuff.

What I have worked out so far with orangepi zero, Ubuntu Core 16 and Snap.

Ubuntu Core, because they force updates, is failing to come back after scheduled reboot. Or so it seems.

The serial port responds but the device is not on lan.

All attempts to attach at the IP address reported in the message displayed on the serial port fail.

Hard reset (power off, power on) brings board back up with new IP address but then the cycle repeats. Schedule reboot does not come back up.

Weird but if I use a sudo reboot the device comes back up with IP intact.

So, something about the core auto reboot.

I tried a debian server but snapd would not install. Rasbian apparently is a no go, so maybe they meant arm generally?

Otherwise, moquitto snaps and runs fine. The node-red snap installs but no service starts. No config comes with snap and snap start node-red returns no service available message. The node-red snap will otherwise run in foreground.

Self induced sabbatical from fun

Well, not really.

I had another paper to write to get me to a conference.

In the meantime, the dopey OrangePiZero keeps needing reboot every couple of weeks.  Not sure whether its the node-red, the mqtt server OR the hardware.

Previously, when the website went down, I could login via the serial port – so I suspect the hardware again.

I will likely need to pull an ODROID-C off my cluster to take over the house again.

The orangpizero will at least be a great little brain for robots.

Niggly

I may have some more design work for the opensprinklette node-red implementation.

The nuance is that the google calendar node will happily trigger on event edges but the triggered response seems to be a dump of the calendar event parameters but not the edge that triggered the node.

It might be as simple as another parameter on the configurator to tell it whether it is for sprinklers on or off

The other might be using the before event.

Have two outputs then to act as start and stop.  Feed the stop into a timed node.

Either lapsed or absolute is another question.

Much of this is trying to think in a dataflow rather than an imperative idiom.

I want to think also about ACK from the WeMOS sectors. That might want a watchdog timer.

The lwt from the WeMOS sector will need a response. Although any sector/zone on, while WeMOS is down, falls on deaf ears.  Stil, it needs to be logged and reported.

Back to work

So, at last, now that the OPiZ setup saga is over (fingers crossed) we begin over.

I built a new nodemcu firmware for the WeMOS to include:

• bit
• end user setup
• file
• GPIO
• MQTT
• net
• node
• RTC Time
• SNTP
• timer
• UART
• Wifi

A few coding snippets later and  the WeMOS can catch the mqtt topic running on the OPiZ feed by the node-red on the OPiZ.

So, I can now parcel up the OPiZ as the house server and tidy up the sprinkler system.

I did note that the WeMOS did not come up first time I bombed the firmware.  That was sorted (it seemed) by selection the 4MB Flash option on ESP8266Flasher.  The ESP-12E on the WeMOS has a 4MB flash and I noted that there is a branch of the nodemcu frozen in time now for the 512kB chips – so go with the master branch if you have the WeMOS D1 R2.

I did also manage to break a hoodoo now that nodemcu does away with autoconnect for the MQTT.  The timer callback scheme works a treat.  I can reboot the OPiZ and the WeMOS will reconnect once emqttd is up and running again.  Of course, I have a LWT setup so that the emqttd server will tell the node-red if the WeMOS drops off the channel.

This is getting exciting now.

So far so good

OPiZ is still up.  So I have avoided the hiccup of ethernet dropping out somehow.  I am always queasy when the problem just “disappears” but small mercies right?

The only thing that I noted was that, when the system has dropped its ethernet, I have not had a console connected.  So I have shut down the TeraTerm session, that was watching the memory usage, and left the device running now with the node-red and python test harnesses running.

We may be good now.   I hope I have properly documented the steps I went through.

Winter chill.

So far so good.

OPiZ has run for 12 odd hours with temp reporting, node-red and emqttd up status running on OPiZ, emqttd up status running on PC and PC pinging OPiZ.

I note that, because this is winter, and we snuggle under a couple of doonas during the night, heating in the house is off.

That meant the temp of the OPiZ dropped to 59degreeC from the 62degreeC it peaked at yesterday.

I note also that the memory watch I ran on the OPiZ via TeraTerm was fine.  The free memory was oscillating around the same value that it was around 12 hours ago.

So, who knows, is it a temperature related thing that causes the ethernet to drop its connection?

Odd that there are complaints on the net about heat problems with the OPiZ, the OPi series in fact, but they don’t bother to 1) provide heatsink with the devices 2) tune the device to run slower out of box since that will drive the operating temperature down and because there is no heatsink provided.

Mind you, I have also found 6x6mm Peltier coolers so who know how silly this could get.

Or, I guess, play with a jar of mineral (baby) oil.

The server needs to provide Mission Critical level functions for running the house.  So it stands to reason that either I get this sorted or drop the OPiZ and go back to ODROID-C1.