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!

Advertisements

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.

Finally! But …

Posted in 3D Printing on January 25, 2019 by asteriondaedalus

Looks good right! Nope. Its not a parallax trick, that downwards slope appearing of top edges at front is shrinkage. The obviously failed bits shrunk away from the plate. The large printing stayed stuck to the plate but shrunk back into the plate.

In fact …

Posted in 3D Printing on January 12, 2019 by asteriondaedalus

No need to bother my sister with requests for prints over 140mm cubic.

I worked out my printer is big enough to print the parts for a delta printer.

Up to 1m high if’n you want to, or you’re game … I am game.

Not bad for second print

Posted in 3D Printing on January 5, 2019 by asteriondaedalus

This is the elbow from a Niryo robotic arm. I seem to be stuck though, since I got the flashforge finder, since it only prints up to 140mm cubic. Still, I can get most parts built and farm out the larger parts to my sister. I will need work on a larger 3d printer once I have mastered the art. I wish I had one of these years (even decades) ago when I did Industrial Design at University.

Now I have done it

Posted in Uncategorized on January 2, 2019 by asteriondaedalus

What a lemon

Posted in Rant on November 30, 2018 by asteriondaedalus

Samsung J5 Pro.

Had it a couple of months.

Had a thick Gorilla glass added.

Had a thick carbon fibre case.

Dropped a few 10s of centimeters to land flat on screen.  So actually buffeted by both rim of case and protected by G-G.

Even with the reduced jarring the LCD failed.  Phone is kaput.

In fact no visible physical damage externally.  Just a bleeding LCD internally.

I took it back to Optus store, too bad it is “physical” damage.  They recommended going to Samsung store.  I went to Samsung store and the young guy shrugged.  He, the Samsung rep, recommended that he would not recommend the J-series phones to anyone.

The phone cost $300.  I would cost most of that to repair.

It is a $300 dollar disposable phone.

Now there is talk in Australia about the need to bring in Lemon Laws for cars.

Why stop there.  Stop telcos selling lemons as phones. 

As an Engineer I have to say that I was disgusted with how little kinetic energy was required to frag the phone.