Archive for November, 2016

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.


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

So, I ripped out node-red from my PC and re-installed.  I then re-added node-red-node-google.

Now the behaviour of google nodes in the PC variant was different to the google nodes on TheThingBox.  When I went to the properties of the PC variation I got the following:


So it turns out you clip the redirect URI into the google api credentials info:cred2

And voila!


Two events from google calendar, one at start of event and the other at the end.  So good enough to turn sprinklers on and off.  Yes, I just set up a calendar on google called “sprinkler” – too easy.

Doesn’t help, though, getting the RaspingBreathBurry going.  But may mean I need build node-red onto the RaspingBreathBurry and avoid TheThingBox install.  The problem is either they “adjusted” it for TheThingBox as an app OR it’s broken.  Either way, if I can’t connect readily to the google calendar then too much code need be written.

Now, spread out over internet is the problem of which api to enable.  The guidance says “Directions API” which doesn’t make sense for Calender events.  All forms of dribbling all over the place.    Turns out you want to enable Calendar and Google+.  Not even sure that you really need Google+ for calendar things but it is enabled.

Niggly I know but courtesy would be to just list the api required and the steps to boot.   This “you are stupid if you can’t work things out” bullshit of opensource flies in the face of application of learning theory from educational science.   I guess it is also a passive form of bullying by anti-social gimps.


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

So, apart from TheThingBox install woes on the RaspingBreathBurry (now I just have lotsa cupsa tea while waiting for booting) I find trying to connect to Google Calendar ain’t happening without pain.

Apart from the failures to connect to the Calendar on my gmail account – until the fourth attempt at rebooting the sluggish RaspingBreathBurry.

I find xxx:443 errors popping up on the display/debug panel.

Most notably on occasion I get the dreaded “lost connection with server” from the node-red HMI (meaning yes I have to reboot the RaspingBreathBurry).

There was a scratching on the google node-red guide about enabling a Directions API (which was funny because I was wanting to use Calendar, there is a Calendar API but no direction to enable the Calendar API).  Moreover, that guide wasn’t obviously for TheThingBox setup.  I set the enable on the Directions API in any event.  Didn’t help.  I didn’t think it was intuitive it would help and I have to note it wasn’t apparent how to set up the connection between TheThingBox and the enabled API (unless it goes through your google account??) .  No matter, it didn’t, as  I mentioned, help.

There is some scuttlebutt about firewall settings, nothing clear cut.

I have now deleted my “project” at google to disable the API to try to get back to the original set of problems (as usual the problem shifted as I fiddled).

Fun fact, I tried installing the Google nodes on my PC to get around the RaspingBreathBurry (and assuming there was some problem with the RaspingBreathBurry) but when I added node-red-node-google using npm onto my PC it didn’t work.  It installed fine but when I dragged a google node onto the canvas it was glued in that sport, would not open the property editor on double click, and I couldn’t delete it.  So the node-red-node-google running on PC was not a means to work through the problems with connecting to the Calendar.


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

So how much does a MiP robot cost?

Why I ask is my wife finally got us a dining table, huge thing too.

It was bought on auction for about 1/4 of its RRP.

She jokingly said “we need a robot to run up and down the table with the salt and pepper”.

So, I thought hack a MiP.  It would be a good start.

KMart have them for $99.

LittleBirdElectronics has them for … $194.04 dollars!?

I know KMart has more buying power but why would you even think to go up against them and to sell the same item for twice the prices?

Looks like this “open source”  and “maker” friendly group may be over pricing some of their offerings.

Might just be the XMas push.

The price seems to flip between the two across a lot of suppliers.


Winding down

Posted in Open Source can be professional, Python RULES! on November 22, 2016 by asteriondaedalus


Now this is what I am talking about.

See Claus for SLAM videos using Python whohoooo!

Get yourself some ipython so you can get access to the web based notebook.

Easy enough to embed Claus in the notebook page and then doodle learning SLAM in Python in ipython notebooks because you can.

The fallacy that is open source hardware

Posted in Anti-Maker Sentiment, The downside of Opensource on November 12, 2016 by asteriondaedalus

I think, in truth, the idea of open source hardware is a dud.

It is unfathomable that, somehow, the idea that while designs are “free” it makes sense as a business model.  Someone has to pay for the hardware.

Coupled with the art-house thinking of open source generally then all sense of consumer rights and vendor obligations are now defunct.

My run in with DFRobotics is an example.

The margins a manufacturer generally makes on a manufactured product need to trade-off quality control with the matter of fact reality of returns of faulty products.

The quality control strives to reduce the number of returns, but will incur a cost of product discarded before boxing – hopefully to reduce the count of product faulty on opening the box.

With regards to returns, there is in fact a formula that one can use to add to the cost of  a product the impact of returns under warranty – somewhat cynically then having the poor sap buying the right of return.

Still, the upshot there should be included in the price you pay the cost of the quality control and the cost also of the warranty provision – to catch the items the quality control misses.

You don’t have to be a mental giant then to work out if you don’t do the quality control you might need to put a higher premium on the warranty provision.  Moreover, if you add the premium for the warranty provision, with no intent of paying on that premium, you are then unethically but conveniently milking the buyers.  This is especially a boon if you are not spending on design and just copying, soldering chips onto boards with no checking.

Coupled with the technical distance from design, copying rather than innovating, assembling bits shy of the whole what are you then delivering?

Not a device!

It’s not just that it doesn’t work.

It’s that having borrowed the concept, the design, soldered the bits, there is no culpability for the Device as a functioning thing.

It is just bits soldered with no intent on it functioning as that is an risk I am supposed to accept.

This is a accepted belief in the “Community” I take it because it is a “Community”.

So consider this.

DFRobot, who sold me a dud CurieNano, sell a Genuino 101 for AUD$63.  SparkFun sell the same Genuino 101 for AUD$46.

Is the inference that the DFRobot version is 137% better in quality?

Is in indicative of no quality control and the expected cost of returns (to be milked by not accepting returns)?

If the “phantom” quality control and warranty were factored out of the DFRobot Genuino 101 would it, or indeed should it, cost $46?

If your Genuino 101 from DFRobot were potentially to be a dud would you buy from DFRobot or from SparkFun?  Would you buy from you sense of community or simply risk based on the chance that the open source hardware need not work, it is cheap after all so it’s your risk.

You need still wonder how the open source hardware story will end.

China copiers take the market off the good intentioned designers.

Raspberry Pi “community” shames copiers despite CC licensing of hardware (and apparently interferes with chip supply to copiers a la Odroid-W).

Chips assembled onto boards but “devices” not guaranteed operating when delivered with risk placed on the heads of the buyer who wants it cheap.