Archive for the OpenSprinklette Category

Wow, that turned out to be simple

Posted in Embedded, node-red, OpenSprinklette, Orange Pi, The downside of Opensource on June 13, 2017 by asteriondaedalus

So voila!


This doesn’t look like much but it made my teeth grate for the longest time.

The problem was setting up node-red on the OPiZ (and indeed the ODROID-C1) I could not use the google calendar as planned, for setting sprinklers on/off, because the embedded machine’s IP would not resolve to the domain name “”.

Turns out I had the right idea, I just set the IP address incorrectly in my hosts file on my PC.

The problem was fixed by setting the c:\Windows\System32\Drivers\etc\hosts on my PC with the correct IP address of the OPiZ (I noted I had shrapnel there from the ODROID-C1 attempts and realised I had a 178 in place of 168 in the IP preamble).

The figure above shows now browsing from the PC into the OPiZ which is running node-red.

What you are seeing is a response from a google calendar I set up (to ping the node-red server when an event start occurred).   My heart stopped a little when the google api exception popped up (though that itself told me we were talking).  The start event I set came through regardless (so it must have resolve the lists in the background in any event).  The strange problem being that there is a time sync problem between what my computer says is the time and the calendar.  I can get events from calendar two minutes early according to my computer.  Likely source is whatever “clock” google calendar is running to (it reports the correct time from perspective of the calendar).  Something to track down.

Not the best solution, setting up a hosts files on every machine in the house is doable but there has to be a smarter way?

Now I have to muddle through the emqtt install again.  The problem there ended up none of the examples for starting the emqtt as a service worked for the armbian distro.

It never rains …

Posted in OpenSprinklette on April 22, 2017 by asteriondaedalus

… and I have just got back to my web-based sprinkler to find, with writing papers for conferences and work deadlines, my google api tokens were dodgy.   The reasons are clearly explained in the api documents.

So I deleted the credentials and created a new set.  All working fine again.


I can get the json response from the calendar on the debug window.

I put a json function in to turn it into a jsp object.  The output should be stringified and displayed in the debug panel but nothing appears.

I have two separate flows, one for start of the event and one for the end.  If I put a json function on the start, neither of the start or end events are displayed.

What’s worse, taking out the json function and going back to a straight through flow also no longer works.

Not getting the token expiration warning so it isn’t that problem anymore.

To get it going again, with the json function included, I needed to stop and then restart the node-red server.

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.


Short cuts

Posted in ESP8266, MQTT, NodeMCU, OpenSprinklette on December 18, 2016 by asteriondaedalus

The chappy doing OpenSprinkler gave me the best idea yet for the 24VAC to 5VDC to power the OpenSprinklette stack (Wemos D1 R2, fiddly bits including VAC2VDC and pullups, relay board).

Rather involves using a LM2596S-5.

I have in my bits drawers 10 LM2596S-ADJ based modules that go for US$2 a pop in packs of 10 so I will start with that for the prototype.


For the VAC2VDC the secret is to add a 3A diode (cathode to +ve volts input) of the PSU board.  It then likely passes for the circuit at the OpenSprinklette blog.

In fact, if you solder the pullups onto the two naughty GPIO pins you need to, either on WEMOS D1 R2 or the relay board, you could get by without an intermediate board.  There is still the conditioning circuits for the flow meters, but again, since we are using mqtt there is the option of a separate system for that.  I think we are already convinced that the rain gauge can twerp to an mqtt topic for example.  Although, there may be traction in a shield board for people who want no more than four zones and one unit – at least with the rain gauge input and 24VAC to 5VDC … oh and those pesky pullups.

Note we still need do something like string all the relay commons together now don’t we.

I guess the more interesting thing going on with the rain input of the OpenSprinkler is the use of a surge protection across the rain gauge input that has a Transient Voltage Suppression diode.  The selected value appears to be 48V which seems a lot but the gadget is used for ESD threats to the board (aka lightning – not strike likely but nearby EM field, up to a point).

This is actually necessary especially when there is  likely a long “antenna” from the rain gauge to the unit.

Might be less need if an ESP8266 is connected at the gauge and the solar panel and charger (we’ll need a battery to run at night time) are similarly “close by”.  Already solved in any event.  

Hmmm.  Lightning detection

Almost there

Posted in ESP8266, OpenSprinklette, Wifi on December 17, 2016 by asteriondaedalus

I got a prototype shield today to sit between my WEMOS D1 R2 and the quad relay board to work on my OpenSprinklette design.  I will get a PCB made once I debug the design.  It will need a 24VAC to 5VDC on it to power the WEMOS and the relay board.  The 24VAC will come from the wall plug from the old sprinkler system.

Not to mention a couple of pesky pullup resistors and an input for flow meters, though that will take some thought, and of cause ports.  So the flow meters might sit on a WEMOS mini as an afterthought.  Still brainstorming that aspect.

I am still setting up one of my ODROID-C1 to be the mqtt and red-node server.

I will buzz out the system with my PC install of red-node in any event – for the moment at least.

I decided I will add a dip switch to allow for 15 modules.  I will keep one for a broadcast so all on/off.  Most people can get by with 1 or two modules in any event.  So yes, module ID will be 1..15.  Software will sort the zone to module story – of course.

The use of google calendar will mean using NTP protocol isn’t as important but it might serve as a network alive function.  I will need think about response to network down.  All relays open circuit is good general response.

Still, I think we need a watchdog to catch other issues, like the google calendar connection down, so maybe a timer that shuts the zone off after 45min and then calendar events can be set at 1/2 hour increments.  You just set two 30min back to back to get an hour.

I am also playing with options for zones.  The broadcast to all zone can be the calendar entry without title.  Otherwise, a comma delimited set of zone numbers in the title of the calendar entry can be used to set individual zones on/off.

The various weather gadgets are great for prediction but I will need look at moisture and rain sensors.  I found you can get shields for the D1 mini that are lipo battery chargers so I am thinking of a set up with solar power for on house and gazebo roofs for reporting rain and then same in garden for moisture.

Though, the moisture ones would need to be dog proof.  Hmmm.  Bury them, but would the wifi reach the surface?

It occurred …

Posted in Embedded, Erlang, ODROID is wonderful, OpenSprinklette on December 5, 2016 by asteriondaedalus

… that after all the fluffing around with TTB on the inherited RaspingBreathBurryDOodlePi, I did rather prefer my mix I built originally on one of my ODROID-W.

Still, now I have got the additional ODROID-C1 it makes more sense for use as the house automation server.

The reason is that there is a UPS module that I can get from HardKernel that will help with survival requirements (given the blackouts we occasionally get in sleepy little Adelaide).

I do rather like the 7″ touch display you can get for the C1 as well.  Although, that isn’t strictly necessary since we will browse into the node-red running on it.



Posted in OpenSprinklette, Rant, Sucky Wucky RaspingBreathBurry, The downside of Opensource on November 27, 2016 by asteriondaedalus

So, I ripped out node-red from my PC and re-installed.  I then re-added node-red-node-google.

Now the behaviour of google nodes in the PC variant was different to the google nodes on TheThingBox.  When I went to the properties of the PC variation I got the following:


So it turns out you clip the redirect URI into the google api credentials info:cred2

And voila!


Two events from google calendar, one at start of event and the other at the end.  So good enough to turn sprinklers on and off.  Yes, I just set up a calendar on google called “sprinkler” – too easy.

Doesn’t help, though, getting the RaspingBreathBurry going.  But may mean I need build node-red onto the RaspingBreathBurry and avoid TheThingBox install.  The problem is either they “adjusted” it for TheThingBox as an app OR it’s broken.  Either way, if I can’t connect readily to the google calendar then too much code need be written.

Now, spread out over internet is the problem of which api to enable.  The guidance says “Directions API” which doesn’t make sense for Calender events.  All forms of dribbling all over the place.    Turns out you want to enable Calendar and Google+.  Not even sure that you really need Google+ for calendar things but it is enabled.

Niggly I know but courtesy would be to just list the api required and the steps to boot.   This “you are stupid if you can’t work things out” bullshit of opensource flies in the face of application of learning theory from educational science.   I guess it is also a passive form of bullying by anti-social gimps.