Archive for February, 2019

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.