Let’s talk a bit about home automation and safety.
You can go a long way in the process of automating your home without ever introducing any features that might conceivably endanger property or lives. Typically the worst thing that goes wrong with an automation to control a light is you wake up at the wrong hour or pay a little extra on your electric bill.
Lights, fans and shutters probably account for the majority of devices that the novice home automation enthusiast is interested in controlling, at least in the beginning. Turn the corner and include garage door openers, door locks and even environmental controls and you’ve crossed a fine line, perhaps without much consideration, where a failed automation could have impact beyond a simple inconvenience. A garage door that opens every morning when it’s time to leave for work sounds like a great idea until you forget to disable it while gone for a vacation.
Giving a little thought to a “worst case scenario” with every new project is a wise bit of advice. In fact, asking the question at every step along the way of automating some cool new house feature might be an even better mindset. Whether using “routines” in the Alexa app, or something sophisticated like NodeRed, you should consider every separate action as possibly the last thing that happens before the network fails or a random device reboots.
When I thought to bring an irrigation project into my home automation realm, that ever-present worst-case thinking had me picturing gardens full of muddy water and high utility bills. A valve turns on and fails to turn back off… It’s probably not life-threatening, but falls solidly into the category of endangering property. We spend not just money but time and energy making our back yard “just so” and too much water in the wrong place could do real damage.
Looking at the birdbath in the picture with a copper tube and an irrigation valve in the background might not make the average person start thinking about mechanical and electrical failure modes, WiFi reception and network security, but given that there are many components in play that could be the weak link in the chain plus a career that has shown me just how accurate Murphy’s law can be, you can bet I’m visualizing a block diagram and poking at the various parts.
Some things come out of the box with a certain degree of “fail-safe” built right in: The electro-mechanical valve in the picture defaults to “off”. Lose power or break the wires that lead to the valve and, given that you agree it’s better to have no water flowing than an unstoppable continuous supply of water, the manufacturer had your back when it chose that default.
Next in line up from the valve is the relay device that is controlling the valve. I chose to build my system from simple components rather than buy a dedicated sprinkler controller, mainly because I had ideas like my automatic clean and fill system for the bird bath shown. I spent zero time researching any off-the-shelf irrigation solutions, figuring a 15 second time setting for a zone is probably outside of their intended set of use-cases. Besides that, if I have leftover relays I might use them for lighting or other possible features around the back yard.
The current implementation is using a 4 channel relay from sonoff.
In considering how this might fail I’m reasonably open to giving the benefit of the doubt to the hardware and software that runs this device as a unit. I typically scrutinize the parts of a system where I have chosen the physical connections or the logical interactions. Some thought about individual component failures like a stuck relay might be in order, too, but for now I’ll be questioning my own design choices.
The same level of integrity extends to the software I flashed on the sonoff device, Tasmota, a free open-source project that enables a lot more flexibility and options than the Sonoff branded firmware that comes with the device. I’ve used Tasmota enough to give it the benefit of the doubt as well, up to a point. Like anyone who has ventured into any sort of home automation that involves wireless protocols of any sort, I’ve seen network-induced failures where unintended consequences occur.
It’s beyond the scope of this discussion to explain just how hard it is for any given piece of software to just do the right thing in face of adverse conditions like a network failure. It’s no surprise to me at all that Alexa won’t turn my lights on a little later than I scheduled a routine if the network is down for the minute when the routine is supposed to run.
So I’ll consider the same sort of scenario when I work on automating the sprinklers and the bird bath clean/fill cycle: What happens if device A sends the ON command to device B and then then network fails before the OFF command can be sent? When the network recovers, is the OFF command automatically re-sent? Is an undefined overage on the cycle time permissible? Would I be around to observe and resolve the situation?
In my case, an obvious choice for scheduling the irrigation controls might be Home Assistant, as that is what I have controlling lights and other home automation devices. So we’ll consider that to be device “A” in the paragraph above. Device “B” is the Sonoff switch. In between there are wired and wireless network components, probably a total of 3 or 4. Only one “hop” in the network is over WiFi, but given it goes all the way from one side of the house to the outdoor location where the Sonoff relay resides, it’s not guaranteed to stay up 100% of the time.
These thoughts sent me searching for ways to build in a fail-safe mechanism to insure that any given zone turned off in a timely manner. The birdbath part of the project led me to a really simple solution. Since I’d never want to program both an “ON” and “OFF” time, but rather control the duration of how long the nozzle blasts on the cleaning cycle, I set out to learn about the options Tasmota might present for a timed pulse rather than discrete ON/OFF events.
Well, while I was looking at the “rules” features within Tasmota and asking questions on a Facebook group about some of those options, my attention was directed to another Tasmota feature, called PulseTime. Without attaching a sound to that word to capture the feeling of revelation that it brought on, I might just settle for: Voila!
PulseTime allows me to associate with each relay that Tasmota controls, a given duration to stay on, regardless of how the state switches to “ON” in the first place. There’s no distinction between a local “ON” timer, the physical button, the web UI or an MQTT event from Home Assistant. There’s no “OFF” communication needed, ever. It makes sense both for the bird bath and for the various garden zones, that each one will have a desired time for the valve to stay on. It’s fail-safe.
Now, if I choose to use the simple built-in schedules provided by Tasmota, the system is completely standalone, but networked so I can monitor and interact as desired. Later, if I want to integrate more exhaustive automatic controls, like skipping a watering cycle if my rain sensor on the roof exceeds a half an inch over the last 48 hours, the sky’s the limit. The distributed control with “ON” coming over MQTT but the time limit under local control is a perfect balance between flexibility and fail-safe defaults.
It will mean I’ll need a 3-d printed case, a separate 5V power supply and another go at flashing Tasmota, but given the results so far, I’m betting it’ll be worthwhile.
I should mention it works well to scare off squirrels and grackles too. Here are some videos on facebook: https://www.facebook.com/groups/smarterhomeclub/permalink/645746079233782/
SmarterHome.club is the website for our Facebook community, The Smarter Home Club – which is an umbrella for all kinds of smart home technologies – home automation, security, custom electronics, weather stations, alternative energy, you name it. DIY focused.
If you’re interested in joining the Smarter Home Club’s Facebook group, please follow this link: