Archive for the OpenSprinklette Category

Prototype boards on the way

Posted in OpenSprinklette on June 17, 2019 by asteriondaedalus

The problem for powering the modules, used for opensprinklette, is that the sprinkler solenoids are driven by 24VAC.

So, I have found a circuit idea to sort that, added a few twists and now I have three prototypes:

  1. A basic board with TVS, bridge, electrolytic cap and Pololu Step-Down Voltage Regulator. I am using Pololu four pin step-down modules and the idea is you use a 3.3V, 5V or 9V depending on how you power up your board. (Yep, after buzzing out the prototypes I will correct TVT to TVS 🙂 )
  2. An Arduino UNO shield, with the 24VAC to 9VDC to drive the VIN pin on the UNO headers.
  3. A Wemos D1 Mini shield to with the 24VAC to 5VDC to drive the 5V pin on the headers.

I will buzz the boards out once they turn up. I will get the software into github for the Wemos boards. I am still testing the node-red scheduling stuff as I am trying to get a scheduling option up that doesn’t need to connect to a google calendar as well.

I have also come across and home-assistant so I will also look at that option.

In the meantime, I am doing a kotlin and kotlin + android course to get up to speed to write an android app to work with the system as well.


Too easy!

Posted in OpenSprinklette on February 10, 2019 by asteriondaedalus

So, over a vodka and coke I did hack up the code to allow for auto config of group gadgets.

Works a treat.

Basic process is boot/reboot home server. That starts the node-red with global data empty.

Then turn on opensprinklette gadget one at a time. Either lwt or herald will log the meta-data for the gadget into the global array. The idea you set the group or unit ID (1..4 or 0..9 respectively) by turning on the gadget to associate the gadget with its location.

In the global space in node-red there is then 4 group var and 10 unit var. Sure, could have used arrays but saved on string concat or parsing since the term “group1” is, for example, used in the title of google calendar event for example. Saves on index bounds checks etc. Given the design decision was to allow 4 groups (4×4 relays) and then 10 units (10×1 relay) it was a trade-off.

The user then turns on gadgets around the yard or paddock to associate a location with a gadget. User does not have to know the chip id of the gadget per se. For example, if you want group1 to be the quad relay gadget managing the four solenoids controlling water to your back yard, then you turn that quad unit on first, before any other quad unit, after server boot/reboot. And so on. Think of it as a method of loci. That is, user associates the group or unit with a location.

I will slowly add a HMI so that location can have a description field, though that will be added by node-red. The gadgets will never have any idea of their physical location.

While the server stays up, the gadgets can go online/offline without losing their loci. They only lose that if the server goes down.

To test this, I programmed two WEMOS D1 R2 (UNO style) with quad relay version of code.

I was able to power up gadgets and then see both boards as group1 and group2, respectively, in the order that they were powered up.

If I held down reset (to fake a brown out) the lwt, for each gadget, was generated by the MQTT server. The online status of the gadget was then set to offline as expected.

Once I let reset go on the gadget, the gadget re-started and the online status of the gadget was reset to online. This is accomplished because the herald topic is published on successful start up. The herald is an object that looks like this:

gadgetType: 2
gadgetId: 12678832
online: 1

If it helps, the “online:” flag is 0 when lwt generates the same object. I simply re-assign either the herald or lwt object for the gadget to the global array entry for the gadget in the node-red global space.

The problem, for the moment, is if the server goes down then up. Unless you power off then on the gadgets, after the servers comes back up, they will not be registered when server comes back up.

If you reboot the server, a sound-off topic, at the server, to all connected gadgets will help pick up and register all gadgets BUT they will register in order of message received by node. The MQTT server controls the order (I guess) of topics out to subscribers. That means, for the moment, they will not be in assigned by loci.

So, I need a bit of work on the problem of server brown out. Likely, it is simply using the filing option for context. I need to add an un-register function in that case. There will be a time when a gadget dies permanently and needs to be removed from the register.

Yes, it would otherwise be bad form to manage the global gadget data that way. Since I am also looking at distributing the gadget meta-data, there is still a design effect to get through.

For now the config mechanism allow me to now move to glue the calendar code and sprinkler driving code together for the first time.

Down hill run now.

And my vodka and coke has evaporated!

To bed!

Almost there!

Posted in OpenSprinklette on February 10, 2019 by asteriondaedalus

Opensprinklette closer.

Been a long haul with some distractions drawing me away.

The ESP8266 code is done. Tested on WEMOS Uno clone, with DIYMORE quad relay board; WEMOS D1 Mini with single relay shield; and that more industrial single relay ESP8266 with single optical protected input.

I am working on a way to configure the clients into the node-red flow by simply turning them on in the order you want to assign them to either groups (quads) or units (single relay).

There is a quirk with the lwt side, since it’s 50/50 that a lwt comes through before the client pumps out a herald message (here is for the plebs in the audience).

I catch this since lwt is essentially offline message and herald online message, so I have both lwt ahd herald pumping out a JSON record of type (group/unit), ID (esp8266 chip id), and offline (lwt) or online (herald) flag. That way the gadget gets registered on power up either as offline or online. The herald comes through lickity split after the lwt so once up it is fine.

There will be two nodes that you hook lwt and herald messages from mqtt into. That will setup config in global context. One node is for units and the other for groups. This is inline with node-red design rules BUT also makes sense because you might only have either quads or units in a minimal setup.

The parser function, for decoding titles of google calendar events, into sprinkler activations, is well and truly tested. I still need to pull apart the duration of the calendar event to provide a millisecond value for the duration. Once that last parsing job is sorted I will be in a position to test and then deploy into the node-red community. The esp8266 code will be in github.

I will likely hold off for a couple of months while I thrash the system on my home sprinkler system. To catch any other quirks.

Once that main work is closed off, I am planning to work on code for control by android phones. Principally using the node-red hmi widgets. One thing though is I will look at a lightweight distributed key:value store to pass gadget meta-data around.

I don’t wan’t necessarily to drive everything from the home server. I have an evil plan to use RAFT for the fun of it, and as there is bugger all metadata to manage (so the metadata sits in two arrays, 4 entries for quads and 10 for units). Even RAFT might be overkill but I want to get my head around it in any event.


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.