Archive for December, 2016

Who knows why?

Posted in Google API blues, Linux on December 28, 2016 by asteriondaedalus

So a raw install of node-red on PC, an install of node-red-node-google, a google calendar api account, a bit of fiddling and half an hour tops and node-red was reporting google calendar events.

So an hour of attempting different install mechanisms for node-red (to get anything to work) – plagued somewhat by bits that reported deprecation and a couple of kaputs – the same google calendar api account from previous step, two days of failure to get the google calendar out to register with the api.   I lowered myself to go onto stackexchange, got an “Answer” which I cannot correct because I don’t have kudos, a hostile dill who’s Answer I have torn down.

He felt I needed to update the hosts file on my PC so that the browser on PC could resolve the callback to the local odroid server.  Sounded reasonable but that is in itself a likely hint of failure.  Upshot is I had both the odroid’s hosts and the PC hosts files set to the domain name the google calendar config wanted and indeed instructed but not a sausage.  That is the uri request for api permission failed.

So, I looked around for ways to set up a DNS server (assuming that’s what it took) on the local lan.  By golly 1,000,000 sites with 1,000,001 ways of doing it.  I groaned.

Had an idea though.

I had a look at the advanced settings for my ISP router.  Yes, it had DHCP reservations and DDNS options.

I reserved a fixed IP address on the lan for the mac address of the odroid ethernet card.

I created an account at no-IP for DDNS and set up the ISP router to point at it.

I did not delete the hosts entries for the domain name for the odroid off either odroid or PC.

I restarted everything and went to configure the google calendar out gadget BUT the uri request it generated used the domain name generated by google.html in the node module and this was still not resolved.

I had previously tried editing out the domain name in the uri and editing it the raw ip address of the odroid.

Previously this did not work and the request failed.

I even tried that after updating the PC hosts file.  Didn’t help.

Who knows why but now, with the DDNS running on the ISP router, it turns out the hand edited uri (with raw IP address substituted for domain name in the generated uri) worked!

Now I appear to have the node-red on the odroid receiving events (start and stop) from the google calendar.

Very messy.

Advertisements

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.

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.

Voila!

c1red

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 node-red.example.com 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 github.com 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.

Parallel versus Concurrent

Posted in Parallel Talk, Sensing on December 26, 2016 by asteriondaedalus

So, I fell upon Chapel, a parallel programming language.  It makes sense for things that Erlang and Elixir are not good for – like image processing.

It isn’t Google’s,  it’s actually Cray’s.

So fun facts:

  1. When working in Canada I came across a coffee mug in a second hand store that was from Cray.
  2. You can Cram a replica of a Cray into an FPGA.

Now I have Erlang up and running on my ODRIOD-C1 home server.  I will get Elixir and Phoenix running as the wife will likely want something less geeky than node-red for her interface to the home automation.

In the meantime, for fun, Chapel is at this very moment compiling on the OD-C1.  Why not, quad core.  Apparently, for non-Cray etc. monsters, you simply need a  UDP module compiled, a lot of fiddling, and you can have two or more nodes (Locales) running.

In any event, the parallel helloworld found me four cores on me OD-C1.

hello-chapel

Black Magic

There was a configuration script to run but other than that I did not have to tell it how many cores, so some smarts buried does the job.  Otherwise the code to run the print on all four cores is a straight forward as:

config const numTasks = here.maxTaskPar;
coforall tid in 0..#numTasks do
   writeln("Hello, world! (from task " + tid + " of " + numTasks + ")");

There is also an image processing tutorial using Chapel.

There are even lecture notes around.

Zippity do dah, zippity ZAPPP!

Posted in Hardware, Sensing, The after market on December 25, 2016 by asteriondaedalus

Looking at OpenSprinkler circuit, the use of SCR to control the solenoids appears to require the addition of TVS diodes a plenty.

That would be a design decision.

As OpenSprinklette is using relays to drive the 24VAC solenoids we need not apply protection there.

Nuisance factor though is that trying to source non-SMD bidirectional channeled TVS, for the rain gauge input, not so much fun.

For the prototype at least, without any SMD pads on the prototype shield, we are happier with DO-15 or similar package types for the protoboard’s pad spacings.

Luckily though AliExpress came to the rescue.   I have ordered a packet 100 x 36V 1500W bidirectional TVS for US$11.   Now the original design calls for 48V but the markings on the devices suggested unidirectional and the text supporting them did not mention bidirectional.  So, just in case I have ordered 10 x 39V 1500W for US2.80.  That’s the problem with AliExpress and working with penny market vendors therein.  You take what you can get.

So rain gauge and TVS on the way.  I finally decided the shield I am designing will have an input for a rain gauge for those you want a minimal four sector.  The idea of a rain gauge with an ESP8266 has not gone away though.  Where we are using the mqtt and node-red we can build up as we please – over time.

 

Small steps

Posted in OpenSprinklette on December 24, 2016 by asteriondaedalus

Going from hints provided, I added 1.2kohm pull-up resisters to 3.3v on a breadboard shield that currently sits between the Wemos D1 R2 and what appears to be a clone of the Seeeduino Relay Shield V2.

The pullups need to go on D3 and D4 (GPIO0 and GPIO2) of the Wemos board.

As expected on power up the two relays on those boards, on D3 and D4 (GPIO0 and GPIO2), will be have the NORMALLY OPEN contacts driven closed so on initialisation you will need to ensure all four GPIO are forced LOW to drive the relays to OPEN.

To ensure this happens, you will need to force all four GPIO to OUTPUT mode and then set them LOW.

The two inner led  for D3 and D4 (GPIO0 and GPIO2) on the relay board lit on power-up as expected.  One (GPIO0 or D3) flickers on power-up of board likely as it is party to the startup mode of the board.  Settles on after flickering off then on as part of the start-up.  Indexing as per previous blog rant (2,3,4,5).

I can vouch for ESPStudio connecting to the Wemos with the two pull-ups in place.  As I have been able to run short snippets to flip state of relays.

May be best to flash with board unattached for moment.

Now given the circuit design of the D1 mini relay shield and the seeeduino (or clone) are similar, hopefully we are safe to continue.

 

Xmas sales!

Posted in C.H.I.P. on December 20, 2016 by asteriondaedalus

Wow, a shield for your Arduino with Wifi and Airplay and Audio, down from AUS$159 to AUS$99 for Xmas!

Or just ask Mike Brady for Airplay on your US$9 C.H.I.P.!

No, not that “Mike Brady“.

Wow! An ESP-13 shield down from AUS$34.95!  Or a WEMOS D1 R2 for US$6.  US4.60 if you buy 5 at a time, and you get AUS$3.14 change from the price of the ESP-13.