Questions / input: Wireless Irrigation valves? Any 'rain makers' made one?

Setup, Configuration and Use Beginners
1

I was looking for a better category for this post… this was the closest I could come up with.

I am looking for ideas from someone who may have faced a similar problem, and how they solved it.

…

I build relative dumb controllers for my home or more so property automation; based on some Arduino board and or ESP8266 if wired is not possible… the controllers do what they have to do, but the interfaces, or config is done via openHAB v1.

[edit] My self-inflicted constraint, or shal I say my architecture prescribes that anything is solved with Arduinos, ESPs, wired, WiFi, MQTT.[/edit]

I have a bunch of domestic irrigation controllers, which dies one after the others; hence, I need to build a reliable replacement.

So, a few days ago I started thinking…
Basics: 15 irrigation valves spread over 5 acres.
Not keen on putting wires between controller and valves (wireless it is).
The watering program is simply sequential… OH, triggers one valve after the other via MQTT messages; benefits, the pump stays on until all 15 are done.

The problem is not building something; but figuring out how to control the valves.
No wires means, wireless, but also battery powered.
The ESP chews up at least 70mA in WL mode. Pretty useless approach waiting for one signal to go on and another to off, once per 24h.
Yes, I will have a solar panel charging the LiPo inside; still, the best thing is to put the ESP to sleep.

Once I work with sleep mode, the problem is a different one: direct control.
The thing is a asleep when I send a valve ON command.

:star_struck: Hmm, just had an idea. Use my OH timer to trigger the first valve via MQTT. When the first valve comes on, it gets the message to switch on, plus a time for how long to switch on. Then uses this value to run for X minutes; sends an OFF command back to OH, which then trigers the next valve, and so forth, until all 15 are done. Duration does not play a role.

However, one down side. Because the valves mostly like come on after 0-max sleep time, the pump may have switched off and thus may start up to 15 times per day – aiding its quick demise.

What would you do?
Let’s brainstorm…
Thanks!

2

You have 2 problems here.
Range
Power

WiFi will never cover 5 acres
Power can be solved. If timing is not critical. Wake up the valve every 5 mins or so and query the state (or more ie: on for x mins…) in OH.

3

Thanks… 5 acres as a square has a side length of 140m (466ft). Plonk a WiFi access point in the middle and. No point is further than 100m (diagonal is 197m.
Let’s assume for argument sake that WiFi reach will not be the issue. :smiley:

I did some further thinking…
… and figured, I could use two different sleep times, by measuring the solar panel voltage, and determining when it is dark, and then sleep for 10 hours.

4

Sounds good to me.
Good luck and let us know.
Write up a solution/tutorial when you get it working

5

Do you know MySensors ?

They make a library that manages transport on simple arduinos with a 433Mhz radio.

You might be interested in them for two reasons : it could be a lower power communication system (they have gateways for MQTT) by replacing the Wifi; and they routinely optimise their devices consumption. We are talking years on a few AA batteries. You might want to check out their forum/wiki for power saving/sleep advice.

6

Thank you; will have a look…

I just edited my original post with:
[edit] My self-inflicted constraint, or shall I say my architecture prescribes that anything is solved with Arduinos, ESPs, wired, WiFi, MQTT.[/edit]

I am not keen to introduce more technology options; I thought long about it, and so far, everything I have built could be built with this architecture.
Yes, sometimes an overkill; but, I have a library which does the basic, Arduino, Ethernet, MQTT thing.
It also allows me to work with a minimal set of components.

7

Are you using a firmware like ESPEasy or writing your own code? I’m just curious. I’m about to scrap my RFM69HW Arduinos for ESP8266s and have only just begun looking at how to set up the ESP.

Here is a thought that might make it work with the sleeps.

In my mind, you have two problems with any wireless but even more so with devices that control something as impactful as irrigation. I assume you are on a well but you still don’t want a valve to be stuck ON unbeknownst to you. For me, if a sprinkler zone were stuck on for a day it could be nearly financially ruinous (we have some of the most expensive water in the world where I live).

  1. Feedback - you need confirmation that the irrigation is ON or OFF
  2. Timely control - being able to cut the flow as soon as possible when necessary

Unfortunately, there is no way to do both of the above in a battery efficient manner. So we need to come up with a compromise between responsiveness and feedback and battery usage.

So let’s say you implement the night-time detection and put the ESP to sleep when it is dark. Though it occurs to me you could just send a message with dawn and dusk times to the ESPs and let it reset it’s internal clocks (it won’t be super easy but if they publish a heartbeat with battery remaining and up time your OH can calculate the offset on the uptime to go to sleep and when to wake up the wifi). Anyway, after that let’s have it wake up every 10 minutes.

When it wakes up it will pull down any messages and process those and send the heartbeat message and if it were to turn on the irrigation send a confirmation that the water has been turned on. I’d recommend keeping the wifi on whenever the irrigation is running so you can immediately turn it off. But if you do not, know that it won’t be until the next wake up period that the off command will be received and processed.

So the big compromise is the addition of some additional messages that need to be exchanged when the ESP does wake up, keeping the wifi on while the water is running to maintain something closer to positive control of the irrigation, and turning the irrigation on can take up to 10 minutes. And despite this, I would still recommend that instead of sending a simple ON message you send how long the valve should remain on as part of the message so even if it loses wifi or something else goes wrong the water will be turned off (unless the valve or ESP itself dies for some reason).

On the OH side, use the off message from the ESP to trigger the next ESP, though it can take up to ten minutes for that valve to turn on too. But the positive commands coming back from devices is what will let you control the transition from one zone to the next rather than timers running in OH.

You will have to think hard about all the edge cases and error cases and how you want to handle those.

1 Like
8

Isn’t it funny… we are thinking alike. :smiley:
As it always goes, once you write down your situation and then reflect on it, or in my case, sleep a night over it, and all these ideas, constraints, and solution pop in .

You are spot on! As usual grasp the problem and see the issues. Love it! :slight_smile:

My notes after posting were:
OH / MQTT send number to valve, which is interpreted as minutes being ON.
Valve stays on and sends heart beat like tank / hub / pump.
OH can send ‘dark’ message for valve to go to (nigh/extended) sleep.

My main focus yesterday was on battery technology, and charge controllers.
I have decided to go for LiFePO4, e.g. 26650, 3300mAh, mainly for their discharge characteristics. I am also quite familiar with, due to my 20kWh battery I run on the property.
The circuitry is not clear yet.

_MG_0328_00
_MG_0328_00.jpg800×533 546 KB

I am doing a proof-of-concept, and started (as you know) with the simple, yet effective, timer/valve loop rule. Tick; OH can control it.
Next, hardware. I pulled a trial set-up I did last August, then got stuck with ESP rebooting, because I forgot that I needed a capable power source; then figured consumption too big for a battery set-up; now working on solar, MPPT, LDO regulator, and the rest of the circuit.

I have no experience with the ESP yet, hence, can’t tell how I will use it; e.g. program itself to do WiFi MQTT, or use an Arduino to do it all and use the ESP as WiFi only.
When I sorted the 3.3V issue on the ESP, and had an AmpMeter in the line, I noticed spikes up to 200mA, and a runaway up to 400mAh, with the lots of heat – and later reading an article (now looking for it again); here it is: https://www.ondrovo.com/a/20170205-esp-self-destruct/ … something I observed when the ESP/Nano combo was running MQTT, but never so it when it was running as a webserver; eg. http://192.168.1.222/H for high L for low, ON | OFF control.
My suspicion is it has to do with the MQTT library, running the loop to keep it connected; no idea!
(This current runaway happened despite using a lab power supply with ample oomph)… or it could be because of using a lab power supply – a battery or lesser source would not be able to supply that current, drop the voltage, most likely to a point where the ESP reboots anyway, thus solving its own current problem.

The next step is to figure out sleep cycle management and measuring power requirements, then do the circuit.

But, yes, your “edge” cases are very valid, and I am aware about these “what if”… even realised that the current Pope controllers would have the issue: what if the battery dies, it could not switch off its latched valve.

My remedy for this is; have a flow sensor at the pump. There is a pressure (expansion) tank in the system, meaning the pump will run after all valves are closed to build up the pressure, but then does not come on afterwards. It will do two things, I actually get to understand which line uses how much water, (which can be recorded, to eventually detect anomalies, like clogged sprinklers), and (of course) if the pump is running (when it shouldn’t).

While I have a bore pump; it feeds a tank; from which the irrigation pumps draw.
The tank is only allowed to replenish during excess solar capacity (after the battery is charged or after 11:30). This image will make sense to you:

image
image.jpg509×767 84.9 KB

As always; thanks for your constructive feedback!

[edit] More on ESP powering:



1 Like
9

Just a quick note: after spending four intensive days on researching the hardware side of things, I have terminated the hardware development for this particular project. Main reason: time. I have two pump stations; one has valves directly attached to it; since there is power, a mains-powered Arduino will do the controlling. The other has valves all over the place, but my decision is to relocate the valves to the pump station (spend the time there), rather than solve this once off problem.

My point: while I would have selected a LiFePO4 cell for powering the solar-battery-operated controller, no ‘transferable’ insights came out of it. – Meaning nothing useful I can share.