Archive for the OpenSprinklette Category

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 😉

So far, not so good

Posted in OpenSprinklette on July 14, 2019 by asteriondaedalus

All testing good until I wire in a solenoid.

When you go to turn on solenoid, the wemos crashes.

I think I designed in a whoops, since the TVS protects from spikes on power from other solenoids, but not the one the wemos is controlling (I managed to have it on the wrong side of the TVS.

So far, so good.

Posted in OpenSprinklette on July 13, 2019 by asteriondaedalus

So. I will need to redesign, as I used too big a cap template. Otherwise, it seems to power the board fine. I will need bomb opensprinklette onto the wemos for some testing.

Out of shot is the 1 AMP 24VAC power pack.

Missing is still the single relay shield, to be plugged into the Wemos D1 mini.

The redesign will shrink the 24VAC – 5VDC section.

And now, it’s on!

Posted in OpenSprinklette on July 13, 2019 by asteriondaedalus

The prototype opensprinklette boards are here! So, the final sprint to pull everything together.

Prototype boards on the way

Posted in OpenSprinklette on June 17, 2019 by asteriondaedalus

The problem for powering the modules, used for opensprinklette, is that the sprinkler solenoids are driven by 24VAC.

So, I have found a circuit idea to sort that, added a few twists and now I have three prototypes:

  1. A basic board with TVS, bridge, electrolytic cap and Pololu Step-Down Voltage Regulator. I am using Pololu four pin step-down modules and the idea is you use a 3.3V, 5V or 9V depending on how you power up your board. (Yep, after buzzing out the prototypes I will correct TVT to TVS 🙂 )
  2. An Arduino UNO shield, with the 24VAC to 9VDC to drive the VIN pin on the UNO headers.
  3. A Wemos D1 Mini shield to with the 24VAC to 5VDC to drive the 5V pin on the headers.

I will buzz the boards out once they turn up. I will get the software into github for the Wemos boards. I am still testing the node-red scheduling stuff as I am trying to get a scheduling option up that doesn’t need to connect to a google calendar as well.

I have also come across hass.io and home-assistant so I will also look at that option.

In the meantime, I am doing a kotlin and kotlin + android course to get up to speed to write an android app to work with the system as well.

Too easy!

Posted in OpenSprinklette on February 10, 2019 by asteriondaedalus

So, over a vodka and coke I did hack up the code to allow for auto config of group gadgets.

Works a treat.

Basic process is boot/reboot home server. That starts the node-red with global data empty.

Then turn on opensprinklette gadget one at a time. Either lwt or herald will log the meta-data for the gadget into the global array. The idea you set the group or unit ID (1..4 or 0..9 respectively) by turning on the gadget to associate the gadget with its location.

In the global space in node-red there is then 4 group var and 10 unit var. Sure, could have used arrays but saved on string concat or parsing since the term “group1” is, for example, used in the title of google calendar event for example. Saves on index bounds checks etc. Given the design decision was to allow 4 groups (4×4 relays) and then 10 units (10×1 relay) it was a trade-off.

The user then turns on gadgets around the yard or paddock to associate a location with a gadget. User does not have to know the chip id of the gadget per se. For example, if you want group1 to be the quad relay gadget managing the four solenoids controlling water to your back yard, then you turn that quad unit on first, before any other quad unit, after server boot/reboot. And so on. Think of it as a method of loci. That is, user associates the group or unit with a location.

I will slowly add a HMI so that location can have a description field, though that will be added by node-red. The gadgets will never have any idea of their physical location.

While the server stays up, the gadgets can go online/offline without losing their loci. They only lose that if the server goes down.

To test this, I programmed two WEMOS D1 R2 (UNO style) with quad relay version of code.

I was able to power up gadgets and then see both boards as group1 and group2, respectively, in the order that they were powered up.

If I held down reset (to fake a brown out) the lwt, for each gadget, was generated by the MQTT server. The online status of the gadget was then set to offline as expected.

Once I let reset go on the gadget, the gadget re-started and the online status of the gadget was reset to online. This is accomplished because the herald topic is published on successful start up. The herald is an object that looks like this:

{
gadgetType: 2
gadgetId: 12678832
online: 1
}

If it helps, the “online:” flag is 0 when lwt generates the same object. I simply re-assign either the herald or lwt object for the gadget to the global array entry for the gadget in the node-red global space.

The problem, for the moment, is if the server goes down then up. Unless you power off then on the gadgets, after the servers comes back up, they will not be registered when server comes back up.

If you reboot the server, a sound-off topic, at the server, to all connected gadgets will help pick up and register all gadgets BUT they will register in order of message received by node. The MQTT server controls the order (I guess) of topics out to subscribers. That means, for the moment, they will not be in assigned by loci.

So, I need a bit of work on the problem of server brown out. Likely, it is simply using the filing option for context. I need to add an un-register function in that case. There will be a time when a gadget dies permanently and needs to be removed from the register.

Yes, it would otherwise be bad form to manage the global gadget data that way. Since I am also looking at distributing the gadget meta-data, there is still a design effect to get through.

For now the config mechanism allow me to now move to glue the calendar code and sprinkler driving code together for the first time.

Down hill run now.

And my vodka and coke has evaporated!

To bed!

Almost there!

Posted in OpenSprinklette on February 10, 2019 by asteriondaedalus

Opensprinklette closer.

Been a long haul with some distractions drawing me away.

The ESP8266 code is done. Tested on WEMOS Uno clone, with DIYMORE quad relay board; WEMOS D1 Mini with single relay shield; and that more industrial single relay ESP8266 with single optical protected input.

I am working on a way to configure the clients into the node-red flow by simply turning them on in the order you want to assign them to either groups (quads) or units (single relay).

There is a quirk with the lwt side, since it’s 50/50 that a lwt comes through before the client pumps out a herald message (here is for the plebs in the audience).

I catch this since lwt is essentially offline message and herald online message, so I have both lwt ahd herald pumping out a JSON record of type (group/unit), ID (esp8266 chip id), and offline (lwt) or online (herald) flag. That way the gadget gets registered on power up either as offline or online. The herald comes through lickity split after the lwt so once up it is fine.

There will be two nodes that you hook lwt and herald messages from mqtt into. That will setup config in global context. One node is for units and the other for groups. This is inline with node-red design rules BUT also makes sense because you might only have either quads or units in a minimal setup.

The parser function, for decoding titles of google calendar events, into sprinkler activations, is well and truly tested. I still need to pull apart the duration of the calendar event to provide a millisecond value for the duration. Once that last parsing job is sorted I will be in a position to test and then deploy into the node-red community. The esp8266 code will be in github.

I will likely hold off for a couple of months while I thrash the system on my home sprinkler system. To catch any other quirks.

Once that main work is closed off, I am planning to work on code for control by android phones. Principally using the node-red hmi widgets. One thing though is I will look at a lightweight distributed key:value store to pass gadget meta-data around.

I don’t wan’t necessarily to drive everything from the home server. I have an evil plan to use RAFT for the fun of it, and as there is bugger all metadata to manage (so the metadata sits in two arrays, 4 entries for quads and 10 for units). Even RAFT might be overkill but I want to get my head around it in any event.