Archive for the OpenSprinklette Category

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.

lm2596-psu-01-a-450x450

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.

 

DOH! DOH! DOH! and FRACK!

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:

cred

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

And voila!

cred3

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.

It’s getting REAL!

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

20160712_183121

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 …

20160617_083246

… 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.