Archive for the The downside of Opensource Category

Install node-red Odroid C1

Posted in Linux, ODROID-C1, The downside of Opensource on December 27, 2016 by asteriondaedalus

Again with the raft of various authors with their own twists.

So far so good on odrobian vanilla with:

Install npm with:

sudo apt-get install npm

Install node-red with:

sudo npm install -g node-red

However, a couple of fails and various warnings ensued so stay tuned for the debug.


Go figure, again with the 1,000,000 authors story.

So far we had to fiddle.

Installing npm installs nodejs of a version that node-red is not happy with so won’t install.

I ended up installing nvm to pull latest node.js onto machine.  I then had to use apt-get remove to rip out nodejs/npm installed previously to leave latest node.js along with it’s npm.



Unfortunately I didn’t write the steps down as I was having to slash on the fly to try and work out what was going wrong, why two node were being installed etc.

Having problems with node-red-node-google calendar out??? Same setup works on PC.  The callback provided by node is to localhost.  The odrobian version provides a callback based upon which you have to resolve to the odroid’s ip in /etc/hosts.  The problem, a DNS error is raised at the last step of the “authorise with google” for the API.  The prompt appears, but when you select allow the DNS address error is raised.

ODROID-C1 dropping internet

Posted in Linux, ODROID-C1, The downside of Opensource on December 26, 2016 by asteriondaedalus

I found I was having problems with the ODROID-C1, which I am building up as the node-red, mqtt, Phoenix server for home automation, was loosing internet connection a time after boot.

I am building the machine on top of odrobian vanilla – I am using Debian based Linux on all my boxes by preference – which does leave me out in the cold with some software yes.

The cli command told me the ethernet on board was working so I suspected a problem with IP allocation.  A reboot would fix the problem after all.

I poked around the odrobian docs.

Go figure the installed /etc/network/interfaces file read:

auto lo
iface lo inet loopback

The starting example in the docs read:

auto eth0
iface eth0 inet dhcp

Interwebbything, again, has no useful help in as far as there are 1,000,000 plus pages on iface setup so who knows who actually understands what they are telling people and how many are just gash copies of material from the first place people found it?

So what I ended up doing is the following:

auto lo
iface lo inet loopback
auto eth0
iface eth0 inet dhcp

The reason being one oft copied recommendation is always have the loopback.

I tried the eth0 without the auto in front but ping failed to find the real-world.   You would know if it failed as the ping returns immediately.   If it takes any time it’s because it got out into the real-world and is looking for the target.

The auto  command is telling the etho (and lo for that matter) to start on boot.  Without it you would need to do a manual start from the command line.

So, there appears a problem in the supporting manual for odrobian as it assumes what might be in the /etc/network/interfaces file and is simply wrong.

I checked it out by starting a ping to and then jumped on my bike and went for a half hour spin THEN a medium length walk with the dogs (b4 it rains again).

When I came back, we were still on the Interwebbything.

Looks like that they have just copied material from somewhere without tuning it for the actual distro.

Actually …

Posted in The downside of Opensource on December 14, 2016 by asteriondaedalus

… a good lecture series from a MOOC on Machine Learning is at caltech.

For those who want to do more than just download a canned app onto your curie.

A good tool for working up your understanding of machine learning around NeuralNettyThingies is neuroph.

neuroph includes classes for knn and rbf functions so you can play with the concepts without a curie.

Except someone’s tutorial files are for 2010 version and not the 2015 version.

Tich, tich, tich.

Lies, more lies and statistics

Posted in Rant, Sucky service Providers, The downside of Opensource on December 7, 2016 by asteriondaedalus

So, Intel “confirm” it cannot possibly be the Curie that is causing the problem I am having as they tested their Curie on their computer and it worked.

The problem, either they don’t understand quality control and process statistics or are hoping I don’t.

Indeed, it is the same fallacious, that is flawed, argument you get on user groups where someone’s “help” is the statement “it works for me”.

Can people really be that vague?  I suppose so.

Using that logic, for example, the wheel bearings on my 01 01 Subaru WRX do not need replacing.  Granted the front right bearing is squeaking badly.  There is a suspicion about one of the rear ones.  After all, the car was built in 2001 and has many  many kilometers on the clock.  Still, if there is one other 01 01 Subaru WRX that doesn’t have squeaking bearings, needing replacing, then mine does not either … despite the annoying squeaking.

That in a nutshell is the class of “help” you get on user groups and also what passes for “help” of vendors.

However, Curie vendor no help.  Curie device suppliers no help.  Curie community no help.  Arduino community help in as much as it helped me work out that many people are having the problem and there is no clear cut solution.

So, on balance:

  • Two different computers saw the same problem.
  • Two different Curie devices saw same problem on both computers.
  • Different versions of the Arduino IDE saw the same problem.
  • Failed on all USB 2 ports on both computers.
  • Failed on cables that, using the same cable, on the same USB port, programmed an AVR or other board (verifying cable and USB ports work)
  • Failed on all versions of dfu-util that were downloaded from dfu-util site.
  • Failed on all versions of Curie core tried.
  • Failed on various programmer options in IDE.
  • I had a secret bet with myself it would not allow upload of new firmware, it couldn’t because it wouldn’t upload *ino.bin files.
    • It failed to upload firmware.
    • I won that bet with myself so now I have a crisp new $5 note in my left hand, paid by my right hand.
  • Recompiled the uploader with extra error messages.
  • Oh, and re-installed, disabled, re-enabled drivers as nauseum such that I imagine I etched their random patterns of dribbling useless bits into the substrate of my hard drive.

Bored now, SF Genuino returned to LBE. (thankyou LBE).

DFR CurieNano in bin.  Too hard to negotiate because with all I have had to do that wasn’t enough.

Smacked Down by TTB!

Posted in Rant, RaspingBreathburryDOodlePi, The downside of Opensource on December 1, 2016 by asteriondaedalus

So, no way no how can I get the ttb version of the google calendar going on node-red.

Certainly I cannot get it to connect to my calendar, it just pings me with api errors of type 433.

The success with the PC version of node-red encouraged me to remove the ttb version of google calendar, off the ttb, to add the node-red version to the palette.

The problem that arose is that since the RaspingBreathBurryDOodlePi is “named” the local host callback on the google api account does not work.  Snipping in “thebox:xxxx” story does work either as the hmi widget prompts with an error that the url needs to be .com or .org before it is acceptable.

I am still vague as why the local:xxx callback does not work for the RaspingBreathBurryDOodlePi setup as local:xxxx should mean univer-silly  the *cough* machine the call was made from?  So, something about the named machine perhaps is blocking use of the callback.   Some other url trick is required but that is out of my scope of expertise at the mo.  Might have to do with the DHCP service running on the Pi?

That last story is likely why there is a ttb version of the google calendar ttb, but as usual they just assume it works for everyone and how no problem solving tips for what looks like is common problem.

Certainly I have google api setup properly as the PC gets the calendar events, and as the api is agnostic as to whether it is my PC or my inherited RBDPi.  There is no other guidance from ttb on common problems, especially where setting up the RBDPi running ttb and ttb google calendar.

I did rather find a job for my RBDPi that it should be able to cope with.  I have my 5 ODROID C1 cluster.  I am thinking the the RBDPi should serve the cluster as the DHCP/DNS server.  That is about all I think it can cope with as it is only an earlier version.

LBE 1 – DFR 0

Posted in Rant, The downside of Opensource on November 29, 2016 by asteriondaedalus

Go figure, I grabbed a SF-Genuino 101 to find the same problem with it as the DF-CurieNano.

Research suggests there is no fix for the problem.  It has been fixed for some by swapping from Windows 10 to Windose 7.   Or vice versa for some.  For some that doesn’t fix it.

It has turned up on Linux boxes.

So, it doesn’t appear to relate to the box you’re running it on.

Now interestingly a couple of people, at least, found (where they had two Genuino 101 on hand) one would work and one would not.

S0 that in itself suggests a bad batch of boards or chips.

There was a muttering about bad batches of boards going out July-Aug on some forums but no confirmation from Intel or Arduino.

Oddly though, the Arduino forums have been reporting the same problem.

Now LBE is happily taking my Genuino back.  One private email with a precis of the problem and I am good to return it.  Even if it is, coincidently, my PC and my laptop as the “problem” I can’t use the device.

DF, not so much, stuck me on a public forum and then offered to replace the CurieNano if-and-only-if it displayed errors that it wasn’t, in my case, displaying.  In other words, no return.

Now, what I am banking on is if/when a firmware update comes through.  Assuming it is a firmware problem then the CurieNano should come good right?  That is as long as it doesn’t rely too much on the firmware on it for uploading new firmware … you see the point.

We’ll see I suppose.

Still, quite a tardy story coming from, primarily, Intel.  Despite, that is, all the money they spent on their website to make it pretty.  Still, if no one looks too hard, and nothing is admitted to, it just goes away.  A bit like those episodes with McAfee … what you don’t know?!  You see what I mean.


Posted in Sucky Wucky RaspingBreathBurry, The downside of Opensource on November 27, 2016 by asteriondaedalus

The RaspingBreathBurry my mate gave me, though I appreciate the gesture, I can sense his reason was as it is such a slug.

I FINALLY seem to have 2.4.o of TheThingBox sluggishly wasting bit traffic on my lan.

5 minutes of “busy” gadget spinning and it managed to display the red-node title bar but it did not draw gadgets, or canvas, or properties panel.

I think I will have to press a precious ODROID C1 into service.


What a waste of a Sunday Afternoon!

The Google Calendar that comes out of the box with TheThingBox may be a knobbled version of the node-red-node-google suite.  Go figure then, as the 2.4.0 of TheThingBox includes the 0.15.2 update it has a palate manager.  Yes, you guessed it, as hard as I tried to update the palette with node-red-node-calendar it would not install.

That might have to do with nodes from ttb-node-google-calendar in use.  Who knows.

Certainly you cannot remove a palate if anything off the palate is on a canvas.  So I cleared of the canvas to un-ghost the “remove” button for ttb-node-google-calendar and … yes, you guessed it tens of minutes later the “busy” gadget is still ticking over.  So, I may not be able to clear out the unwanted palate nor add the node-red-node-google palate to the RaspingBreathburry.


So painful.

So, I jumped on the bike sitting on its trainer and span for half an hour while letting the “busy” gadget spin.

Came back … doh!

I found the palette up again and thought someone was finally smiling down on me.

I spent another couple of hours with spinning “busy” gadgets, thinking about how my Grand Father used to fix everything with a 5lb sledge hammer and an angle grinder, and what a lovely gesture of remembering those times with him it would be if I took a 5lb sledge hammer to this useless RaspingBreathBerry.

Eventually, after a reboot or three having tried fruitlessly to either remove or disable the ttb-node-google-calendar and install the node-red-node-google palate, the expected nodes were in the palate.

So, I sheepishly added a calendar object and YES! it was the node-red-node-google calendar.  So I went to register it and … kaput.

Long story short the google api won’t accept  http://thebox.local/google-credentials/auth/callback as the callback.

I assume then that is why the ttb-node-google-calendar nodes were created??? Who knows, they wouldn’t connect, the node-red-node-google nodes wouldn’t connect.  Since there is no real documentation in and around that ttb junk the canned TheThingBox seems to be no help.

So we are back to setting up an ODROID C1.

Before that I will try the red-node I have running on my ODROID-W as I had not upgraded that yet nor have I used the google gadgets on it.  It was handbuilt using node.js, npm etc.   I also was using  emqttd instead of mosquitto so it might as well be a handbuilt system – it actually took far less time to set that up than to try to track down the problems with the RaspingBreathburry.

Certainly after the 5 minutes it took to sort out node-red-node-goggle connection to api and getting my calendar to ping the node-red on my PC, the nuisance in and around TheThingBox approach still needs work – but not from me.