Archive for July, 2016

Erlang on C.H.I.P.

Posted in Embedded, Erlang on July 30, 2016 by asteriondaedalus

Well, with github and down (for some dangblasted reason) I tried building Erlang on one of my C.H.I.P. from instructions here (for RaspbreathyPiklette).


Sorta stuck after that as … github is down.  Git can’t find it, ping can’t browser can’t.  The site reports up and running but still can’t connect.


Everything old is new again…

Posted in Doodling on July 28, 2016 by asteriondaedalus

I just downloaded a free book from O’Rielly press: Free ebook: Object-Oriented vs. Functional Programming.

Sad really.

Consider my first programming language (gag I’m 57 in a couple of weeks so let’s be gentle and say 30 years ago) was LISP.

I did like LISP.

So much I build a LISP interpreter in FORTH.

I did like FORTH.

So, why the hard sell on functional languages?

To me, they were always gold.

OO is a funny thing.  Functional thinking, so called, is an Anti-Pattern.  Of course, that’s only true when constructing programs in OO.  However, OO always did too good a job at obfuscating the functionality – to its detriment.  Go figure, the JVM was eventually fitted with journalling to ostensibly provide a functional look at what was going on in your application, that is people felt it necessary to provide a tool to reverse engineer the running application – scary.


History eh?!

I was speaking to a younger (like me ex) software engineer.  I would mention things like the “Software Crisis” – he would have a blank look on his face.


Another blank look.

Smalltalk, remember wasn’t going to catch on because it is byte code interpreted on a virtual machine.

Up the horsepower and viola!  Java byte coded virtual machine a winner! For a while, as it made never get over J2EE.

So, Erland and Elixir are gold I tell you.  Best of both worlds.  Running on a virtual machine and functional.

That’s it.

That’s my rant over.




Posted in Networking on July 25, 2016 by asteriondaedalus

So, bombed a C.H.I.P. with shairport-sync.  This is a neat Airplay client app.

Only problem is my old house seems to throttle back the wifi throughput with its double brick walls.

Pumping the music through the wifi router in the lounge (from my PC on my desk in my hobby room) the audio at the desk was choppy and honestly useless.

I tried bombing a second C.H.I.P. but got the same result.

So, as I had a wifi extender on my desk I connected PC and C.H.I.P. to that and voila!

Mostly good, though it did kaput and loose sync after half a dozen songs.  It took a restart of the shairport-sync and a couple of attempts at iTunes to reconnect everything up.

So, I downloaded the NETGEAR Wifi Analytics app to do a quick survey.  Not really much difference in bps but I wasn’t even getting peak performance a metre from the wifi router.

As the Wife insisted on no cables from Foxtel to television in the lounge a wifi extender is in use so I half suspect some interference (perhaps).  Not to mention we cannot have the router in view, as that is “ugly”, so there may be other structural interferences.

In truth though, more or less the same performance as the android app experiments using kodi on my phone.  Same difference, choppy.

I might need a good wifi extender in the ceiling to pump wifi at a high enough rate to TBD speakers in ceiling.


How boring!

Posted in Doodling on July 23, 2016 by asteriondaedalus

My 5 C.H.I.P. have turned up.  I got a HDMI board as I will be for working Elixir port but the other 4 are destined for piping Airplay around the house.  I will need get four more later for shed, gazebo, pool area and Madam’s bathroom.

There is already a Airplay client install for the C.H.I.P. so a slow poke through first one to work out the process and then the other three will be a snap.

Just need to mull over speakers.

It’s getting REAL!

Posted in ESP8266, Lua, MQTT, node-red, OpenSprinklette, Wifi on July 12, 2016 by asteriondaedalus


So the four-4-US$12 flow sensors have turned up.  The minimum measurable flow rate appears to be 1 litre a minute.  To put this in perspective Bob Hawke (ex Australian Prime Minister) sculled a yard glass (1.4 litre) of beer in a record (for the time) 12 seconds.

In comparison irrigation “emitters” tend to be in the ranges of:

  • 2,0 liters/hour – 1/2 gallon per hour
  • 4,0 liters/hour – 1 gallon per hour
  • 8,0 liters/hour – 2 gallons per hour

Now this will be per emitter so you will need around 8 times 8,0 liters/hour “emitter” in a line to get a 1 liter/minute flow by napkin scribbles.  A whopping 30! 2,0 liters/hour “emitter” will be needed to get a 1 litre/minute flow in a line.  Note, there may well be more than enough “emitter” to turn the paddle but that will depend upon the individual installations.

Not really a problem as the intention was to use this as a leak detector as the rate will be driven up but the leak, especially if your dog has dug up and chewed through a hidden hose, as evidenced by …


… mind you that one didn’t need a leak detector to find.

These sensors are advertised as low precision in any event so really not a problem.  So this won’t be of use to meter your water usage.

I am playing with the idea of higher precision flow sensors – to set time-versus-budget constraints  – but I will roll that in as a separate option as such a flow meter can likely go on the input rather than output lines, and as we are using MQTT the high precision flow-sensor can also be separate unit to the valve controller/line flow sensor.

All the signal integration will occur in the main host.

Connecting NodeMCU to a NTP server

Posted in Embedded, Lua, NodeMCU on July 4, 2016 by asteriondaedalus

Ignore the IP suggested in example.

Search google for “NTP server”.

Being Australian I am using one from the pool listed at:

Code therefore becomes:


   print('setting time to:', sec, usec, "from: " .. server)
   rtctime.set(sec, usec)
   sec, usec = rtctime.get()
   print('time set to: ', sec, usec)


The difference between times that you will see, when running this gem, is in and around 7 milliseconds which is the cost from function calls is all.

The idea would be to use a timer, set to max time and auto mode to run this occasionally to keep the time on the node synced with your local world.  That is:

tmr.register(6, 6870947, tmr.ALARM_AUTO, sntp.sync(...)) -- see above code

You might like to set a flag if the sync fails, or publish a mqtt alarm, or something more useful as the print will be lost on the world since we are deploying nodes in the real-world sans terminals.  Although consider loss of sync might also be loss of wifi access and so likely loss of communications with your mqtt server – so devilishly complicated this will all be.