Archive for the OpenSprinklette Category


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):


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!

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.



Posted in Embedded, MQTT, NodeMCU, OpenSprinklette, Orange Pi on August 16, 2017 by asteriondaedalus

I may have some more design work for the opensprinklette node-red implementation.

The nuance is that the google calendar node will happily trigger on event edges but the triggered response seems to be a dump of the calendar event parameters but not the edge that triggered the node.

It might be as simple as another parameter on the configurator to tell it whether it is for sprinklers on or off

The other might be using the before event.

Have two outputs then to act as start and stop.  Feed the stop into a timed node.

Either lapsed or absolute is another question.

Much of this is trying to think in a dataflow rather than an imperative idiom.

I want to think also about ACK from the WeMOS sectors. That might want a watchdog timer.

The lwt from the WeMOS sector will need a response. Although any sector/zone on, while WeMOS is down, falls on deaf ears.  Stil, it needs to be logged and reported.

Ta da!

Posted in Javascript, node-red, OpenSprinklette on August 12, 2017 by asteriondaedalus

Ah ha!

I had some trouble importing my pegjs parser function into the node console until I worked out node and/or javascript treats directories as “/” whereas windows uses “\”.

So finally the import is simply:

var parser=require('./parser.js');

I also hand modified the parse function signature which is now:

function peg$parse(input,zones, options) {};

I worked out that zones needed to go ahead of options as calling “parse(input,,zones)” wasn’t a popular choice with the javascript.

The input variable “zones” will come from the configuration node. ¬†That way the parser will take the configuration object [{sector1:chipid()}] and return the mqtt topic fragment “chipid()/zone[0..4]”.

So, the modified parser tested using node console shows it working:

final zone parser test

Now all is needed is the use the zone “grammered” string in the google event title and snip it out, when the event starts/stops. ¬†This is achieved with msg.payload.title¬†as the first parameter in the call made by the node reacting to the calendar event.

The array returned can either be iterated over using a for-loop OR be returned by a node-red function to be treated as a stream of messages (aka msg).

I have a sneaking suspicion that, in fact (and having read the code and how it uses “options”), I [could|should] have injected the zones via options.

Something to play with I think, as it doesn’t seem clean to hand mod the parser code.


Posted in Javascript, node-red, OpenSprinklette on August 10, 2017 by asteriondaedalus


A parcel turned up with RaspingbreathburryDoodlePi heatsink kits.

They are the recommended source for a heatsink for the OPiZ.

Although I can certainly find the same on Aliexpress, I bought locally to get them within a week instead of 10 weeks.

Still, gotta say brrrrrrrrrrrrrr, freezy!

At least 5degreeC cooler running with heat sink.

Still not convinced that was source of ethernet dropouts on my new board.   No problems for a couple of weeks now so I will put concerns aside.

I did notice 15mmx15mmx5mm 5V fans on Aliexpress though.  Tempting.

Still tempted at getting a small peltier cooling gadget to go the whole hog – mostly for the fun of it.

But, at the moment, I am focusing on finishing the opensprinklette configurator node for in node-red.   I have a basic configurator to map sectors to WeMOS chipid(), now I will integrate the pegjs defined parser.