Archive for the OpenSprinklette Category

HA+ESPHome no good for critical systems

Posted in ESPHome, Home Assistant, OpenSprinklette, RaspingBreathburryDOodlePi, The downside of Opensource, The Downside of software development on May 2, 2020 by asteriondaedalus

Ah, actually, I think I have to go away from using ESPHome and homeassistant combination for OpenSprinklette in any event. 

No longer then interested chasing down a bug I was chasing in the HA REST API and using CURL to turn sprinklers on with a POST to switch services. I was planning to use that to be able to write a Kotlin app for an old Android tablet, since 1) I can’t get HA to open on the old version of Chrome on the tablet and 2) the HA app for Android won’t install on my old Android tablet. The bug I found sits cleanly in the REST API of HA since I am only using the examples and the POST does not work for switches or at least switches implemented using ESPHome.

The problem leading me to drop the bug in the REST API is not associated with the REST API but is because my raspingdoodleburry pi has crashed.  But, I found the ESPHome based sprinkler system has 3 of 4 relays on with the Pi crashed and not online. Even worse, as bringing the Pi and therefore HA back online does not automatically reset ESPHome device. Sure, you could set up something on HA start/restart but that does nothing for the span of time the Pi/HA is down and relays on ESPHome device on. Way too fiddly to sort all likely mishap cases. Especially, if the actual cause of the Pi/HA crash and the breakdown of HA/ESPHome communication causing the relays to come on, is unknown. So, even if the Pi/HA came back up by itself (some time after it crashed), there’d still likely be $K dollar water bills in the mail.

Having had a $3k water bill some time back, due to sprinkler system leak, I gauge it makes no sense keeping this combination of HA and ESPHome for a “mission critical” application, since I am not sure when the p p p p p Pi went d d d d down.

The evidence of a HA/ESPHome interaction problem is the relays in this HA/ESPHome version are set up in automations, to come on and turn off in sequence, with a gap in time between off and on, to avoid having to deal with sharing the water pressure. This works fine with HA up and running. So, having 3 of 4 on will be an artefact of Pi+HA crashing and likely some interaction between HA and ESPHome. That is, there are no automations in HA that would set 3 of 4 relays on at the same time and so no two relays should be on at the same based on the design of the automations. The automations have been running on a test rig and come on sunrise and sunset without a problem and the logs did, till the crash of Pi, reflect that expected behaviour.

That likely means the usual ping ponging between two user groups blaming the “other” software and, frankly, not my bag. I want to water my gardens and not solve a problem with use cases not being tested.

Not a problem, I have previously hand written code to run on the WEMOS UNO format board for the sprinkler system. That code is MQTT driven and was designed from scratch for a sprinkler system with ample safe guards. For example it wont turn on water for less than 5 mins, won’t accept more that a 15 minute request and will turn off a sprinkler after 20 minutes. It will allow a new time setting over top the old so if you want a hour of watering you just ping it with 4×15 minute requests every 15 minutes. I have a node-red setup that also will send an sms if a sprinkler node (either a 4x or 1x wemos setup) raises an LWT. I’ve even designed my own boards to support the 24VAC to WEMOS voltage conversion.

I also have a peg based parser to all setting of sprinkler times, across multiple single and quad sprinklers, via titles of google calendar events. Though, I want to decouple from google and try the same over a local mechanism for both principled and practical reasons.

So, I am also looking at how to hook my parser code into other calendar widgets. I am still to look at HA calendar widgetry, if it exists, since automations are fine but the natural thing is to just want to use even just a weekly calendar and not a full year calendar, or so I imagine I think I want to believe. Although, then node-red calendar widgetry or HA calendar widgetry? It will depend upon ease of integration.

In the end, I actually suspected my hand coded sprinkler option was likely the better approach for exactly what the crashing doodle woodle pi and the interaction between HA and ESPHome has revealed. I would even suspect the ESPHome web site, and the HA one to, have caveats and warnings about not using either for mission critical applications. Especially, if its the emergent properties of the integrations that will get you and no one is really going to arbitrate that except for the end users.

Lucky I found this problem on the test bench.


I poked around a bit with this, the problem is a little more insidious.

I thought the server had crashed as I could not log in with MobaXTerm. In fact, I have my server with Ethernet wire connection to a wifi extender and it turned out that the wifi extender has been dropping connection with the ASDL router. A real pain since I bought a new wifi extender BECAUSE I had the same problem with the older wifi extender AND BECAUSE the “help” on the Net suggested there was problems with the older wifi extender.

So, I found that re-connecting the wifi extender to the ASDL router saw an interesting picture. The ESPHome device must have reconnected to the HA server since the switches on the HA HMI, representing the relays in the ESPHome device, had the same state as the device. 1, 2 and 4 on, 3 off.

Not a problem you say. Well, it is since the way the system is set up is that you turn the switch on at HA HMI, and then an automation runs and turns the switch off after 15 minutes.

On top of that, that behaviour was also required when driving the relays by sunrise/sunset since a delayed trigger to turn the switch on, on sunrise/sunset, was used and the trigger to turn the switch off after 15 mins was expected then to trigger on the switch being turned on. Worked a treat while connection between HA and ESPHome device stayed up.

The problem still remained that three relays on ESPHome device were on (1,2,4) and one was off (3). Three switches on HA HMI were on (1,2,4) and one was off (3). HA log reported all switches off. So, there was a disconnect between states internally to HA somewhere.

The automations for all four switches are all triggered on sunrise/sunset. They have delays that set the individual switches on 20 minutes apart. The second set of automations, triggered by individual switches going on, turns the triggered switch off after 15 mins. So, the system works:

  • sunrise->all four switches triggered with delay x mins.
  • 0 mins->switch 1 on trigger switch 1 off automation
  • 15 mins->switch 1 off by switch 1 off automation
  • 20 mins->switch 2 on trigger switch 2 off automation
  • 35 mins->switch 2 off by switch 2 off automation
  • 40 mins->switch 3 on trigger switch 3 off automation
  • 55 mins->switch 3 off by switch 3 off automation
  • 60 mins->switch 4 on trigger switch 3 off automation
  • 75 mins->switch 4 off by switch 4 off automation

Nothing really then to account for why 3 of 4 relays on, why HMI reflected ESPHome device state and then why if relays are on in ESPHome device the associated switch on in HA did not result in a switch off after 15 mins. That is, I have had the ESPHome device powered up and 3 of 4 relays have been on for two days, where they should have off after 15 mins if triggered on by HA. If I manually switch the switches at HA HMI to off today, they are then off at device. I haven’t rebooted device because I want to see if the states coherence is re-established. I assume that states will be coherent again if the automations run tonight and the relays behave properly again. Noting that that won’t redeem the setup for use in a critical applications, since it would take too much energy to understand the interplay and the problem it is actually a state coherency problem in either or both the design of HA or ESPHome or both.

So, no real way to account for 3 off, for example, since all four switches run with exactly the same automation descriptions. You would expect all four on or all four off, not a mixture.


Posted in OpenSprinklette on February 17, 2020 by asteriondaedalus

So, who knows why the Zone 1 sprinkler goes off 4 minutes before sunset? No, I am not asking. I am seriously not going to ask on the Home Assistant “help” as I am not feeling I need wade through any “unhelp”. There is quite obviously a hiccup but for the purposes to which I put this hack, who really cares?

The easiest way around the problem of watering the zones in succession was NOT trying a trickle of triggers. I thought about it and I simply had four triggers on sun events or states that had four different delays before spilling into the action section. As I have timers on the zones, to turn them off automatically after 15 minutes, I simply triggered on sun state, sun state + 20 minutes, sun state + 40 minutes and then sun state + 60 minutes (aka 1 hour).

Good enough for a home setup with four sprinkler zones. Though I will be adding more zones as I go. One idea is to use ball valves instead of the 24VAC valves. That way you can use a solar cell and battery setup and plant them any place you like (away from the mains and the 24VAC powerpack).

So I need design another board. That will be a real version 2.0.


Posted in OpenSprinklette on February 9, 2020 by asteriondaedalus

Still a little dusty from my Dremel work. I say Dremel work, I got a $30 “Dremel” from Aliexpress some time ago (is it or is it not a Dremel?). It says on the case “Made in America” but its bought from China! A little shady then.

It does run on AUS 230VAC.

I cut the foreign plug off and connected an AUS plug. Only problem, it seems to have a preference in the wiring up the active and neutral (would work one way but not the other). The problem being the way it is happy to wire up seems to have the spindle turning the wrong way, so it loosens instead of tightening the chuck. Oh well. If it becomes a problem I guess I will buy a real one from a local supplier. No problem so far.

Keeping the price down on this sucker is hard. I used up all the 100uF caps I got from Aliexpress, the sucker in the photo is $8! The case is, yes, big. The problem, the next size down would just fit the board if I redesign the board. I may do that since the use of the screw posts inboard turned out to be clumsy (might as well solder to board). Not to mention, it interferes with lid of this box, so I will remove screw post and solder to board. The box is $24!

This is fine for my personnel hacks.

Yep, I will have to jump the 24VAC inputs from side terminals to end terminals … clumbsy. So, more thinking through things required in future.

Works a treat with ESPHome on board and hooked into Home Assistant. I have “switches” to manually turn it on/off. You can turn it on and it will water for 15min and turn itself off using an automation. To run all four I am using sunrise and sunset events and simply chaining the watering of zones, so that all four are not on at once.

I will still persist with the node-red version, with my own sprinkler code, as an alternative. As I am still keen to glue the parser I wrote into the node-red and as the means to interpret the google calendar event title.



Posted in OpenSprinklette on February 8, 2020 by asteriondaedalus
Note the common linked to left most post
New version on right

New boards have arrived

Posted in OpenSprinklette on February 2, 2020 by asteriondaedalus

So, I have set up the quad board to be able to wire the relays up and be a little tidier.

The 24VAC comes in the side via two of the three posts. The third post passes up the 24VAC to the commons of all of the relays on the relay board. The four N/O outs of the relays go to the inward 4 posts. They then neatly exit on the 5 posts on the end along with a common. The additional 4 posts on the end are for inputs/outputs, not currently assigned. The breadboarding was added to allow for hardware hacking (including the small matrix near the input posts or are they output posts? Up to you).


Posted in OpenSprinklette on January 4, 2020 by asteriondaedalus

If you are using a module such as the one pictured below, to drive a single sprinkler solenoid, then you will note it will accept 7-30VDC in. So you will need a AC-DC conversion. A bridge and a 1000uF cap will do. If you are wanting something neater then aliexpress comes to the rescue with a kit option.

Final Opensprinklette designs (for now)

Posted in OpenSprinklette on January 3, 2020 by asteriondaedalus

Presenting the quad board. Added additional terminal blocks to help manage the wiring. Added prototyping area to allow for additional hardware hacking, including four terminals for additional I/O. Notice GND, +5V and +3.3V power rails.

Top side of Opensprinklette quad board
Bottom side of Opensprinklette quad board

Presenting the single board. Added additional terminal blocks to help manage the wiring. Brought as many pins out as I dared to a pair of headers (J1 an J2). J2 also has associated solder jumper (on bottom of board) to help with option of V1 or V2 of Wemos mini relay board. The solder jumper on the Opensprinklette V2.1 sets the mode of J2 pin 2.

If you are using a version V1 of the Wemos mini relay board you don’t have options, as D1 drives the relay and you don’t get then to use I2C. Jumper defaults J2 to Pin 1=D2, Pin 2= D3 and Pin 3= D4. You lose D0 in any event since its set aside for V2 of the Wemos D1 mini relay board.

If you are using a version V2 of the Wemos mini relay board you change the jumper on Opensprinklette single to set J2 to Pin 1=D2, Pin 2= D1 and Pin 3= D4 . Effectively you lose D3. You need also to change the relay driver pin on the Wemos D1 mini relay board to D0 (from D1), using the solder jumpers on the Wemos D1 mini relay board.

Top side of Opensprinklette single board
Bottom side of Opensprinklette single board

J1 pinouts


D0 and D3 are not that exciting to lose in either event. D5..D8 gives you access to SPI so you either have SPI if using V1 Wemos mini relay or SPI and I2C if using V2 Wemos mini relay. Not a bad trade off. Not to mention UART is also brought out.

RxTx pinouts

2Tx out
3Rx in

Et Voila!

Posted in OpenSprinklette on December 29, 2019 by asteriondaedalus

So, I rebuilt a brand new single relay opensprinklette board. I did notice, as I stripped the original, that the end of the electrolytic was a tad “swollen”, oh dear, oh well.

I had a new batch of 47V TVS, physically smaller than another batch I had previously bought. So, that means I don’t need hack at the boards to fit them. I thought the original problem was that I had was using a lower voltage TVS than I should have been. Only marginally I thought. It didn’t turn out that the slightly lower rated TVS was the problem, though hacking the board to fit the larger and thicker leaded TVS probably helped me fry that board. I likely jumpered lead to the wrong place or inverted something.

No matter. Turns out a clean build, with all the properly rated components, still sees the brownout after a few cycles.


So, I shorted the shutdown pin to the VIN as recommended.

I then set up a node-red test that turned the relay on/off with a 50% duty cycle with 5 seconds in each state. It has been running now for about an hour without failure. So the quirk is that the Pololu 5V down converter seems more sensitive than the 9V down converter.

I will still need to short the shutdown on the quad board to be sure. I am now ready for final versions of the two boards, with minor tweaks including additional terminal blocks to keep the wiring tidy.

I am in the process of playing with a Kotlin front end for Android to manage the home setup. That is really just a prototype as the home setup will start with a single quad unit. I will build HMI system up as I get a hang of Kotlin development.

Brown outs and all that jazz

Posted in OpenSprinklette on December 28, 2019 by asteriondaedalus

So, now having a DSO on the bench, I was looking forward to solving the problem of the brownouts on the openspriklette prototype boards.

I saw the brownouts on the single relay version. I had a sneaking suspicion I might not see the problem on a quad relay version. The reason is simple. The single relay version uses the 24VAC to 5VDC circuit but the Wemos D1 mini does not have power conditioning aboard as sophisticated as the Wemos D1 R2.

The Wemos D1 mini does have an ME6211 regulator to down convert 5VDC to 3.3VDC. The Wemos D1 mini does not have an 9VDC-24VDC input option, which drives the need for more sophistication in the power input stage. That means the Wemos D1 mini is reliant on the power conditioning provided by the off-board power supply.

So, I assembled a quad board. It has the D24V3F9 9VDC out by Pololu. Older tech, but that’s what you get from Australian stores. So, fun story, that quad board works fine. I even attached two solenoids and cycled them on/off simultaneously. No brownouts.

Fun fact though. I had not tied the shutdown to VIN on either design. The specs warn if you don’t you could get strange behaviour. So, I still need retest the single relay board with shutdown tied to VIN. The problem, I did rather hack at it with some component swaps. I did get the bridge pins around the wrong way. There was smoke. No matter, I had three boards made – OSHpark minimum quantity. So, I will build another board and re-verify the behaviour without the shutdown tied to VIN. I will then tie the shutdown to VIN to see if that helps.

Oh! The DSO. Didn’t need it for the quad relay board testing. Will need it once I build up a single relay board.

Seems good …

Posted in OpenSprinklette on July 27, 2019 by asteriondaedalus

I did a retake on the components required for the 24VAC to xVDC boards, used in opensprinklette, and realized that I had bought 100uF instead of 1000uF electrolytic. Little wonder it wasn’t helping in filtering the spikes caused in hot end because of solenoid activation/deactivation.

So, swapping out the 100uF with a 1000uF fixes the crashing wemos!

Almost. It runs for a while then … wemos fires up, I have a looping test in node read that turns the relay on/off every 5 seconds. The LWT will pop up after the widget goes quiet after a few cycles. I found it would reboot and start again, though would only cycle a few times before crashing. More often than not, I had to pull the powerpack from power board and restart.

Runs a treat otherwise, as long as you don’t turn the relay on. All 24VAC elements appear on the correct side (the other side) of the protection, so its a little perplexing.

3 options. 1) the cap voltage rating needs boosting, 2) the TVS is too tight versus the RMS of the 24VAC input, 3) the circuit I found is a dud.

I am actually waiting on delivery of electrolytics of a higher voltage rating. Jaycar only had 60V caps. The TVS rating was on a batch I got based on an example circuit for OpenSprinkler. It it works for that then surely it should here? In any event, I have a slightly higher rated TVS batch coming.

The design I borrowed appeared to opt for a 40V design target so the cap really should have room. It will likely be the TVS (I am hoping) and then we can move on.

Bigger IS better 😉