What a lemon

Posted in Rant on November 30, 2018 by asteriondaedalus

Samsung J5 Pro.

Had it a couple of months.

Had a thick Gorilla glass added.

Had a thick carbon fibre case.

Dropped a few 10s of centimeters to land flat on screen.  So actually buffeted by both rim of case and protected by G-G.

Even with the reduced jarring the LCD failed.  Phone is kaput.

In fact no visible physical damage externally.  Just a bleeding LCD internally.

I took it back to Optus store, too bad it is “physical” damage.  They recommended going to Samsung store.  I went to Samsung store and the young guy shrugged.  He, the Samsung rep, recommended that he would not recommend the J-series phones to anyone.

The phone cost $300.  I would cost most of that to repair.

It is a $300 dollar disposable phone.

Now there is talk in Australia about the need to bring in Lemon Laws for cars.

Why stop there.  Stop telcos selling lemons as phones. 

As an Engineer I have to say that I was disgusted with how little kinetic energy was required to frag the phone.



Posted in ESP8266, MQTT, node-red, OpenSprinklette on November 11, 2018 by asteriondaedalus

So, one file I had fun getting off my laptop was the source for the parser for the google calendar event titles.

The titles, as discussed previously, would be a list of sprinkler group or unit callouts.

I managed to ssh onto the laptop from my desktop to lift anything I wanted before I trashed the laptop with a clean Debian install.

While waiting for the install, I opted to tart up the parser with some sanity.

The problem for the distributed opensprinklette design is that there is no editor per se to police the entries in the google calendar event title. So, if any unwanted text is in the title, the parser running on the node-red server will drop the lot. Harsh I know, but the distributed nature of this entails some trade-offs.

So, I did add some smarts to avoid sending repeated call-outs to a sprinkler. A burst of call-outs will go out once the event title is parsed. The ESP8266 gadgets don’t mind if a single sprinkler is pummelled – it simply results in the time starting from the last received call-out – which won’t be that many milliseconds behind the first.

Still, to opt for a defensive scheme meant testing for a call-out in the return from the scan of the line before adding it to the return. Simples tick!

So, even if the user pummels the title of the event with multiple call-outs to the same sprinkler, the parsed response will only contain a single call-out.

So something like this in the google calendar title:


will return the following in the node-red response (prior to fully concatenating into a MQTT topic):


Posted in Rant, The downside of Opensource on November 11, 2018 by asteriondaedalus

So, found I couldn’t run tensorflow on my laptop as the older i5 I am running is missing an instruction extension to support vectorisations.

I thought then to try to get cuda toolkit up so I could use pyCuda or Cuda accelerated pyTorch.

I got the nvidia driver installed for the GeForce GT 420M my laptop was running. Tricky since I am running Debian 9 Stretch and nvidia is anti-Debian.

Tried unsuccessfully to get pyCuda to talk to cuda toolkit.

There is no official support for the kit on Debian so I had to rely upon vain attempts by others.

I eventually found a good blurb on the problem, but my machine started blurting out app crash reports from the desktop. They kept coming through as often as I closed them. I decided to reboot.


Laptop came up without desktop running.

A little poking round and I worked out that sddm was not running and would not run. So, no sddm, no x-windows, no desktop. Kulprit appeared to be the nvidia supplied driver for the 420M.

I tried uninstalling the nvidia driver but the driver uninstall defaults to not recovering your x-windows setup. Unfortunately, I must have twitched on the enter key so nvidia uninstall wiped itself clean, except for the x-windows config.

I poked around and found one config file that needed to have nvidia changed to nouveau BUT there was no information on the extent of mods to files required to manually backout of the nvidia driver callouts in the x-windows.

I was stuck with no desktop.

I also found I was now also sans wifi and likely few other things so I elected to rebuild the laptop (again). That is the standard approach to dealing with linux is it not. If only that was not such a drag.

Not parsed it after all

Posted in Javascript, OpenSprinklette on October 24, 2018 by asteriondaedalus

Play on words.

Now I have a reliable OPiZ server and a drawer full of quad and single EPS8266 relay setups I am moving full steam on opensprinklette again. That and I have burnt out writing papers for journals.

I finished the parser for the opensprinklette using pegjs.

As mentioned in much older posts the idea is to set sprinkler zones by adding the zone call-outs in the title for a google calendar event. When the event fires, it pings the node-red thingywhatzit and packages MQTT topics to fire relays on distributed IOT boards.

I settled on calling the quad relay boards groups rather than sectors. I am adding call-outs to single relay boards and calling them units. So, the call-outs would look something like this test string of call-outs:

group1=1;unit=9; unit = 2; group 3 = 4; unit 3;unit1; group2=[1,2]; group 3 = [3]; group4=[];group 1=[1,2,3,4]; group 2 = all

Note something important. The call-outs only turn the sprinklers on. The duration of the calendar event sets the time the sprinklers are on. Durations have a watchdog of 1hr 5min just in case server connection is broken. If you want more than 1hr watering, set two consecutive calendar events.

Don’t sweat it as there will be MQTT topics to turn on/off individual relays, groups/units, global (all groups/units). This parser is only for interpreting calendar events. I am in work fiddling with google assistant as well so calling out to google will turn sprinklers on/off outside of calendar events.

I have allowed units 0-9 and groups 1-4 (that’s 4 time quad relay on Uno shield). Actual zones per group is therefore 1-4. If’n you want more groups or units you hack into code and change numbers. The parser would need a little more work if you opted for multiple digits in your numbers. You can, of course, only have 4 relays on a quad relay board 😉

I used =;, since they don’t need shift.

I added a lazy unit definition. Just in case you forget the = when setting a unit relay on. That is, either of unit=x or unitx is legal.

A missing = will be an error in a group call.

Originally, if you wanted more than one relay fired on a quad board you would use groupx=y for each rely. You can still do that but I added the groupx=[a,b,c,d] option as well. That is you can list as many of the four relays as you like. A quirkly, I didn’t fuss with limiting the number of entries in the group array. As long as entries are between 1..4 inclusive then you simply pump out as many call-outs in the list.

Yes the you can either use groupx=y or groupx=[y] for single relay activations – smooth.

The parser generator handled groupx=[] nicely. An empty group array in the input results in no output but also no exception. It is effectively ignored.

Oh? You want what? Okay. It was simple enough to add groupx=all.

As per previous ancient posts, there will be a conversion of group or unit id to a chipid on the ESP8266 boards.

Since the calendar event will turn relays on, it hardly matters if you make multiple calls to the same relay. All call-outs go through in milliseconds, there is pulsing of relay and therefore no pulsing of waterline.

Any errors in the call-out line at all will abort and a debug message will be generated. Best that gets to node-red debug console, emailed to you so you get a prompt, or if you have an old android phone, as I have, use an SMS server to ping your phone. Most all of that is vanilla node-red.

Opensprinklette Single!

Posted in Embedded, ESP8266, Hardware, OpenSprinklette on October 15, 2018 by asteriondaedalus


So, found some info on the board.

Where I thought there was dual throw relay, it’s even better since the second set of terminals are a optocoupler. So, that would be grand for either of a rain gauge input, the audio trigger for dog barking, the flow rate sensor et cetera.

It is otherwise an WeMOS ESP-8266.

What is crazy is that the board thinks of everything and has bidirectional zeners on power and optical inputs so its really for light-industrial applications. That is, includes Transient Voltage Suppressors.

AND! One of the terminals is a regulated 5V output! Just exactly enough for the sound level detection for the dog barking.

Loving it!


Posted in Rant on October 13, 2018 by asteriondaedalus

So, if it turns out that 60,000 Microsoft patents have gone opensource (whatever that means), I am expecting my Samsung phones, and anything else that incurred a licence cost, to cost less et cetera et cetera.

Cynically, that sort of boon does not get to the back to the users.  The vendors will absorb it as profit.

The question no-one is asking is how many other relevant patents does Microsoft still have?

What, indeed, have they kept up their sleeves?

True they have given up billions in licence fees but they have as likely milked those licences dry.

How many patents covered technology that is still seen to be integral to where software is going?

How many patents were really due for lapsing?

Do I still need pay a licence for XORing pixels for when my cursor passes across my screen?


It’s finally happening!

Posted in OpenSprinklette on October 1, 2018 by asteriondaedalus

So, I have been running around in circles, trying to get a red-node server running on an OPiZ. The OPiZ would, however, keep spitting it’s LAN connection after a week or so.

I almost went back to waste one of my ODROID C1 on the task.

I even bought a Raspingdoodleberry Pi 3B+ to run thingybox. That was a laugh. The thingbox crowd didn’t have a 3B+ distro at first, then released a dockerised version of the thingbox that runs on the 3B+. That dockerised version of the thingbox, however, does not save config settings, does not save node-red flows between restarts and otherwise needs you to break into the docker image to install flow dependencies. All without any documentation or help.

The OPiZ had an older version of armbian on it. I had given up fiddling getting mosquitto built on it so I built the MQTT server using eqttd on top of erlang.

So suspects on the OPiZ were hardware (again), the armbian or purhaps either of the MQTT or node-red servers running on it. If I had to pick the original problem I would pick the older version of armbian which was likely still under test at the time.

Frustrated with the failure of the Raspingdoodleberry Pi I gave the OPiZ another shot.

With the latest armbian bionic, snap installed, mosquitto MQTT server via snap, and hand build node-red it has now been up a month.

The node-red snap image is in beta but while it snaps in place, it does not start a service so you need hand start it.

So, I hand built node-red again (since I am such a hand at it ;).

In any event, I got platformio up on my Debian laptop, sorted talking to NodeMCU 0.9 and WeMOS D1 R2 boards. I then coded up a opensprinklette arduino based version for a single relay/sprinkler. The reason I started with a single relay version is the there are a range of single relay options using ESP8266 including:

WeMOS D1 mini and shield

ESP-01 and relay board

All In One

I have a dozen WeMOS D1 mini and relays but I did splurge and get four of the “All In One”. The trick with the watering system is that they use 24VAC. So, a simple regulator and you can pump the 24VAC into the “All In One” to be the solenoid controller for a single irrigation solenoid.

I also got myself a couple to three solenoids and bits enough to build a manifold.