Archive for September, 2018

Setting up platformio and arduino IDE with ttyUSB0 on Debian 9

Posted in IOT, Linux, NodeMCU on September 27, 2018 by asteriondaedalus


Troubles with my 64bit Debian 9 Stretch and trying to setup for ESP8266 and ESP32 development.

This is a freshly built laptop so the USB ports had not been opened before.

I could not “see” ttyUSB0!  So I assume it might be drivers (it was for my Windoze PC).

I feel lucky to have found anything on setting up my usb serial port to see my NodeMCU 0.9 because of just how much junk is on internet about the zillions of ways of fracking your USB port.

I did find out the drivers I had to install, a great video on how to do that, and stopped short of doing that because 1) the instruction was to move stuff under the kernel devices directory (it turned out I had two kernel directories so thought better of that) and 2) when I looked under the kernel directories I found the driver already installed.

So, a little more poking around and I found I needed to add my standard user to related groups:

dialout – full and direct access to serial ports. Members of this group can reconfigure the modem, dial anywhere, etc.

sudo usermod -a -G dialout user

plugdev – allows members to mount (only with the options nodev and nosuid, for security reasons) and umount removable devices through pmount.

sudo usermod -a -G plugdev user

That is what I need as the serial port now displays in Arduino IDE. However, I did opt for also installing platformio into the MS Visual Studio Code (rather than into Atom).

I am in so much trouble …

Posted in Chapel, Everything old is new again, Hardware on September 20, 2018 by asteriondaedalus

I was poised to look into a few more ODROID or NANOPI as an extension of my cluster, then a 2U Dell PowerEdge 2950 with dual 3GHz CPU with 8Gb memory is at action, with only two hours to go, no bids so I went with $15.

So that would be 2×4 Core for 8 all up.

Good enough for a Chapel box.

Not sure how I will hide it from the wife.

So, hopefully someone will decide to outbid me.


In the last half hour of the auction, two others made a run.  One an auto bid and one manual.   I worked out that the auto bid had fizzled, they had set their max to $50 just as I had.

So, I sat poised to make a last bid as the auction was about to close – assuming that the manual bidder might be assuming both auto bids had fizzled and weren’t being tracked or that the manual bid would be fumbled in the last few seconds of the web based auction.

Tension was high.

My bid was in the browser waiting for that last button click.

The clock ticking down.

With 10 seconds to go, enough time to get the bid in but to befuddle someone trying to get a counter bid in before close, I … I … I … chickened out.

Fair the well  2U Dell PowerEdge 2950 with dual 3GHz CPU with 8Gb memory, fair the well.  I hope you went to a nice home.



He’s baaa … ack!

Posted in Orange Pi, The downside of Opensource, Ubuntu Core 16 on September 9, 2018 by asteriondaedalus

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

Posted in Orange Pi, Ubuntu Core 16 on September 8, 2018 by asteriondaedalus

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.

Fracking wanking open source user groups

Posted in The downside of Opensource, Ubuntu Core 16 on September 7, 2018 by asteriondaedalus

Well not really open source. It’s Ubuntu.

Ubuntu that commercial Debian front trying to steal back money having jumped on the “software should be free” band wagon.

So why are they operating like open source with dopey “user” forums?

Costs nothing right!  Worth as much.

Same old same old.

No “help”.  No bug reporting.  Everything must be  “question”.

My questions are not answered.  My questions earn, or not, “reputation”.  But they are not answered.

Over 100,000 unanswered questions on Ubuntu forums alone.

Many with “reputation” because they are, what? interesting?   But not answered.

My questions: Why is Ubuntu handing out images of CORE 16 that go into tight useless config prompt loops after first forced update?  Why am I having to go through this inane user group crap to “help” them sort their frackup?

Its as much as what I have seen in virus checkers when they frack up.

The user forums obfuscate the threat to the vendor reputation because the vendor has users in set-two mode, turning on one another for “reputation”, so you cannot gauge the impact to the community of the frack up.

So.  As usual if I answer my own questions the answers are immediately denounced as not answers.  They are not answers, of course, as to the literal niggly technical reason that the Ubuntu CORE 16 is fragged in the Orange Pi Zero distro.   That is, whether a flag was or wasn’t set just so.

The answer, however, is that the distro was released without proper testing.  That flag, you wankers, was supposed to be just so.

Ubuntu Core 16 on Orange Pi Zero: minus 1 billion reputation points.


Posted in MQTT, node-red, Orange Pi, The downside of Opensource, Ubuntu Core 16 on September 6, 2018 by asteriondaedalus

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 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 (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 …

Posted in MQTT, node-red, Orange Pi, The downside of Opensource, thingbox, Ubuntu Core 16 on September 6, 2018 by asteriondaedalus

… 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.

Ahhhhhhhhhhhhh … no.

Posted in The downside of Opensource, The Downside of software development, thingbox on September 2, 2018 by asteriondaedalus

So. I put Ubuntu Core onto OPi Zero.

I snapped in Mosquitto and Node-Red.

Mosquitto is installed as a service, Node-Red is not.

I started Node-Red, set a graph up to send a timestamp every 5 minutes to debug via MQTT.

Left it all night.

In the morning the server was disconnected.  I did expect this if there was a snap update pushed through.

I did discover you cannot turn off updates … which many people are having concerns about.  Since the system could updated and reboot in the middle of something crucial.

The problem, I was expecting to log back in and simply restart Node-Red by TerraTerm console.

Not a sausage.

The serial port was still responding and putting out the IP address of the board.

I could ping the IP address but I could not log in.

I ended up having to pull the power to force a full reboot.

Not very useful.

Not even sure where to start.  Is this a problem with Ubuntu Core and Snap, a problem with the installed snaps, or are we back to the suspicions about the OPi Zero hardware?


Posted in MQTT, node-red, thingbox on September 1, 2018 by asteriondaedalus

So, yes.  I have been playing with Snap while doing the Docker course.

I did install Ubuntu Core on the OPi and managed to get Mosquitto snap running.  But the node-red snap keeps failing to connect or install (with time-outs reported).   It is 6 am on Saturday, so is that indicative of northern hemisphere loading on the Net?  Who knows, wife, sister in law and two of there friends just finished their party.  I was woken when the retrobates left.  So, I am dabbling.

The same old story though.

Help is out of date.  I installed Docker version of snapcraft on my linux laptop.  You were supposed to use that if you weren’t using Ubuntu – I prefer Debian.

There wasn’t enough data to get something running on that Dockerized snapcraft.

I then found another help site that pointed out that the Docker version of snapcraft was deprecated.

You can now snap snapcraft into place.

Then found an interesting snap that I subsequently deleted.  It, however, reported an error on start up.  No help on the snap so dumped its arse.

I will perceiver with snapping MQTT and Node-Red onto the OPi.  If that holds its water I might still use the OPi as the house server.

There is, however,  thinger.  There is a RaspingdoodleburryPie image.   I have loaded the snap of the server onto my linux laptop to do a trade-off against Node-Red.

Wait … wait … wait … finally, Node-Red snapped into place on OPi.

So, with Mosquitto running, Node-Red MQTT nodes talking, I have a 5 minute timer to leave the system running to see if it keeps going.

The thing I will need sort, however, is that the snap system will push updates (I could one happening the other day).  So, I will need look into holding off the pushed updates to avoid the updates confounding the testing.  As you’ll recall the initial suspicion was flaky hardware.