Archive for the ESP8266 Category

Small steps

Posted in Embedded, ESP8266, IOT, MQTT, node-red, NodeMCU, OpenSprinklette, WEMOS D1 R2 on August 7, 2017 by asteriondaedalus

I have roughed a node-red config node and it’s visible counterpart.  I decided to call wemos nodes “sectors” – since the usual rort is to call a single channel on an irrigation controller, controlling a single solenoid, a zone.

I have set up for 4 sectors each using a WeMOS D1R2 with a quad relay shield.  That provides up to 16 zones (4 per WeMOS).

You need to mod the relay shield with a couple of pullup resisters.  This is to get around a design shortfall on the WeMOD D1R2.

I am using a protoshield in between the WeMOS and the relay shield to allow for fidgeting with design changes. I added a four position dip to set the zone id BUT I dropped that in favour of the config node concept.

That gives me back 4 pins for GPIO. The problem is the out and out lie that the WeMOS is a Uno form factor. The ESP8266 has to cheat by using the same GPIO pins across a couple of Arduino socket pins.

I will add the rain gauge input later.

The idea is an input line such as the following as the title of the google calendar event:

sector1=1,sector3=4,sector2=0,sector3=1

The line above shows you some of the input features I will aim for, being:

  • You don’t need to nominate all four sectors or even all four individual zones of a sector.
  • You can order the sectors in any order.
  • The zones per sector are number 0..4 with 0 being the global all on/off id for all 4 zones on the addressed sector.

I did think about using JSON as input but the problem is that if you have two tokens the same then the object construction takes the later value in the line for the key.  Oh well.

For this to work you attach two google calendar event sniffers, one to flag the start of an event and one to flag the end.  Both feed into the opensprinklette-configurator to decode the events into MQTT calls to the 4 WeMOS D1 R2.

Of note, the configurator maps between chipid() and sector# (and back again) so planning the sprinkling can be in people-talk (relatively speaking).  At least you don’t have to remember which WeMOS chipid() was allocated to what sector.

Of course, there are quirks to do with the distributed system.  There will be a watchdog on the WeMOS to automatically turn off the water to a zone after 45min.  To plan out longer watering you will need back to back calendar events (shorter than 45min to avoid the watchdog).  If that is offensive please send money to help me pay the water bill of a runaway commercial setup ($3,000 in fact).

The other option I guess is send the duration to the WeMOS node and let it do the countdown.

I will play with a couple of timing approaches to see what is most robust – given you could have the ISP gateway drop out, the node-red crash, the emqttd crash, the OPiZ drop of the network.  Not to mention, google calendar hickups – I occasionally get a baulk around credentials lapsing that somehow comes good again.  Oh and of course, the WeMOS could also behave badly.

All in all needs a good bashing to help weed out nuisances.

Advertisements

Back to work

Posted in ESP8266, Lua, MQTT, node-red, OpenSprinklette, Orange Pi, WEMOS D1 R2 on August 5, 2017 by asteriondaedalus

So, at last, now that the OPiZ setup saga is over (fingers crossed) we begin over.

I built a new nodemcu firmware for the WeMOS to include:

  • bit
  • end user setup
  • file
  • GPIO
  • MQTT
  • net
  • node
  • RTC Time
  • SNTP
  • timer
  • UART
  • Wifi

A few coding snippets later and  the WeMOS can catch the mqtt topic running on the OPiZ feed by the node-red on the OPiZ.

wemos

So, I can now parcel up the OPiZ as the house server and tidy up the sprinkler system.

I did note that the WeMOS did not come up first time I bombed the firmware.  That was sorted (it seemed) by selection the 4MB Flash option on ESP8266Flasher.  The ESP-12E on the WeMOS has a 4MB flash and I noted that there is a branch of the nodemcu frozen in time now for the 512kB chips – so go with the master branch if you have the WeMOS D1 R2.

I did also manage to break a hoodoo now that nodemcu does away with autoconnect for the MQTT.  The timer callback scheme works a treat.  I can reboot the OPiZ and the WeMOS will reconnect once emqttd is up and running again.  Of course, I have a LWT setup so that the emqttd server will tell the node-red if the WeMOS drops off the channel.

This is getting exciting now.

Okay, so I have changed my mind …

Posted in Arduino, ESP8266, Open Source can be professional on June 17, 2017 by asteriondaedalus

… it was fun for a while but …

So, dabbling in Lua on the ESP8266 was interesting.

The event driven stuff is clever.

However, the whole thing stinks because you cannot use the REPL cycle to take advantage of the scripting environment and the superior debugging opportunity that affords.

Especially around the niggly aspects of event processing and state problems inherent therein.

So, now the Arduino has the ESP8266, but especially since it now has a mqtt library, and mostly because we are only reading GPIO ports or setting bits on/off, I relent.

If you want to knock up a simple IoT gadget quickly, then Arduino plus ESP8266 are gold.

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

Ah ha! Digital rain gauge spare parts!

Posted in ESP8266, MQTT, NodeMCU, Wifi on December 17, 2016 by asteriondaedalus
rain-gauge

Rock it to me baby!

So, get this, for US$15 you can get a rain gauge that does naught but yep, still yep and yep, then maybe nope.

That is, the cover has a funnel and water drips in and cycles the rocker!

 

simple

Simple tich?!

 

That likely needs nothing more than one of the ESP littlins …

esp8266

… to chirp tich/toch onto a mqtt topic.

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