Propped up!

Posted in 3D Printing, Hardware, Robotics on May 31, 2020 by asteriondaedalus

So I bought me 6 of these 50mm EDF some time ago. Should have waited, of course, since I really needed 2×3 each of CW and CCW units for my blimp project (based on a pool toy LOL).

The problem then how do I sort out the need for contra rotation to try to balance torque forces?

3D printing fans was the solution!

The bottom left fan is the original. The two on the right tests. The original code for the fans was provided by someone else. Note I did have to modify the code a little, since the source code had some design features that were not needed and also I had to add a disc with hole for the hub attached to the motor. You can see one test with a blade broken off? That was interesting, there appears to be a print phenomenon when the hug wall is too thin and the print does not weld the blades to the hub. Increase the hub thickness and the problem corrects itself.

To get CW and CWW I could run the OpenSCAD software twice BUT you can also mirror the STL file in the Flashforge software.

The problem might be that to be truly reversible, the thread on the hub for the nut should be in the opposite twist, since you always want your rotations tightening the nut. The fit of the printed hub is, however, quite snug and a dab of epoxy would aid and abet the retaining of the nut I suspect.

I was going to start with drive motors in the same config as for the SAAB Double Eagle. These appear aligned so there centre lines meet aft somewheres. For cruising rather than for fine manoeuvring per se. They make a lot of sense, since the lever arm with respect to the CoG is increased from where it would be, if the motors were lined up on the main axes. This then amplifies the turning force of the thrusters, so they can steer with greater effect. Or so I surmise. I haven’t found a paper explaining the configuration … yet.

So, I will use 10mm OD carbon fibre tube to build a frame to attach to Nemo (ROFLMAO) and here is the stl.

The Expendables

Posted in Rant on May 5, 2020 by asteriondaedalus


Little wonder Trump can ignore COVID 19.

As of 6 May 2020, only a poofteenth of the American population has died.


Which is why the Australian statistics are as likely not to engender danger.

An yet that’s 50 times higher in the US and since US are likely to carry the run onward and upwards.

If it helps, the rate of deaths in America, if they stay at 3,000 a day up to once everyone has been given the vaccine, if it ever arrives, means the population won’t have dropped from 331,002,651 to 330,002,651 solely from COVID 19. Hard to catch that. You’ll note the irony in the world’s best advertisers, it would have helped if it were 331,002,651 to 330,002,650 right … well not really. You know a bit like the difference between $100.00 and $99.00.

Though the starting count would really be ‭330,942,651‬ since we need take out deaths by flu, with COVID 19 really is isn’t Mr Trump; although that starting count might be ‭330,902,651‬ if taking gun deaths in America into account, but that is by 2017 numbers since it’s harder to get a single count because the US avoids including suicides in the count any more (they don’t count) but you might as well expect suicides and murder to increase as a side effect of COVID 19, that is suicides are to gun deaths what unemployment number shuffling is to the US economy; but the starting count is closer to ‭330,864,651‬ because of car accidents, which are perversely overlaid with gun deaths, since there will as likely be gun play at the scene of a car accident in America; but of course heart attacks of the worl’ds most obese population means we start at ‭330,217,651‬, although not all of those will be due to obesity, some might be at the fright received from gun play, but also because obesity is a factor in COVID 19 deaths; and we could go on.

So we can sort of creep up towards 1% of the population before counting COVID 19.

Barely a scratch.

So, still 0.02% since we did so much rounding in the calculations.

A poofteenth.

Corona Virus Cure Found!

Posted in Rant on May 4, 2020 by asteriondaedalus

Satire is the cure but who can say.  BUT, if laughing at Chinese humour makes me a Communist, then so is Jimmy Kimmel.

China and America drag the rest of us into World War III (WW3)

Posted in Rant on May 2, 2020 by asteriondaedalus

Not just me right?


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.

WHO can SUE?

Posted in Rant on April 20, 2020 by asteriondaedalus

Can the US really sue China? Since the ensuing deaths in the US are also directly attributable to the late response by Donald Trump? That would be an interesting question, since places in Europe especially are in a better place but are as exposed by borders as states in the US. So plenty of evidence the slow US response snowballed the effect.

The successes in Australia and New Zealand notwithstanding, but are still about the success of early early responses given essentially the same information coming out of China. Might moderate what the US can claim, Australia would have a disproportionately greater claim than the US. US certainly had same information as Australia, probably better if Trump was believed, since he would opt to claim his secret services are world best, as he has his medical options.

Now if the death toll in US exceeds that in China that is self evident US has not responded appropriately, oh … that is the case. Yes, China has questions to answer. It might all hinge on whether it is true that this is from a Chinese lab and not a natural transmission.

How would you pick apart the culpability really? Any legal cases in America should be against both Chinese and the American governments really!

If Trump opens up the US and a second wave goes through, then who is culpable? When is the point at which the epidemic is endemic? That is important since the problem for flu is its endemic nature.

The other interesting aspect is Trump’s persistent comparison of COVID19 with the flu. As of writing 40K deaths by COVID 19 in US.Turns out in the US flu is not reportable so they only estimate deaths at between 24K and 62K, that is thousands of deaths. Comparible with the reportable deaths by guns, at around 16K. We already note the flu deaths seem to plague the lower economic groups and immigrants, especially from South America, so are really a social cleansing mechanism.

Or perhaps Americans should sue America for flu deaths and gun deaths? They certainly cannot blame China there. Maybe the US don’t have the moral ground given the demographics of flu deaths in the US. The normalised deviance of flu being what it is.

The Chinese counter argument in court will be evidence US was too late in responding, despite Trump claiming US has worlds best medical system, no concerns for squashing regular internal flu epidemics and certainly no concerns around self inflicted problem with gun deaths. Hard for US to argue an extraordinary outrage, save for the self interest aspect.

And here we go again …

Posted in ESPHome, Home Assistant, The downside of Opensource on April 19, 2020 by asteriondaedalus

Just bracing myself for a torrent of UNHELP on homeassistant user group.

The problem, well there is a couple of problems.

Problem 1. I found the charger for my old Acer A500 android tablet so that is being set up in kitchen as web search, YouTube and Netflix gadget for cooking assistance. That means, apparently, I cannot use it for homeassistant client since a) Chrome version on A500 is too old and b) the homeassistant android app is not compatible with the version of Android running on the A500 and therefore c) see Problem 2.

Problem 2. I need to ask questions on the homeassistant user group.

Problem 3. I need to sort why the rest API works fine in all examples provided on homeassistant web site EXCEPT! for the POST that is to set the sprinklers on. When I use the POST it complains their is a non-JSON problem with the data despite the token, IP address, device id all work fine with other API calls and so that means see Problem 2.

I was able to play with the API by installing curl onto my widoze 10 laptop and then GETing and POSTing to my raspingdoodleburry pi home server running homeassistant under hypriot/docker.

Why all the bother? I will likely write a Kotlin app, for my old A500, with n buttons and POST calls to sprinkler zones to the ESP Home device via HA since HA has been set up with default sprinkler times (so you just turn the sprinkler on).

I can go to a fallback and send MQTT messages if I must, but at the moment the preference is to try to use the API. Generating a POST message in Kotlin is straight forward. The fun bit might be reading back states to make sure the sprinklers are up (so ghosting or not the buttons) and changing button colour or toggling the button on Android device by following the switch state, so as to provide an indication of ACK from device.