Archive for the RaspingBreathburryDOodlePi 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 Google is Anti-Australia, Google Sucks, ODROID vs RaspingBreathburry, RaspingBreathburryDOodlePi on April 18, 2020 by asteriondaedalus

Clusterised heavon! Except they are blown out of the water by a new option, more modules, more features and cheaper! JESUS! Everyone is now doing it!

Now the Turing Pi is to the Gumstix Stagecoach what the Odroid-W was to the Raspberry Pi. I wonder if the Raspberry Pi community gets the irony of a Raspberry Pi option cheating by copying another open source hardware design. Perhaps the Turing Pi should be pummelled the same way the Odroid-W was?

Now I have been at hardkernel to do a similar thing for years. If you talk about a sodimm DDR2 form factor and a cluster motherboard, people on the hardkernel forum still want 1) tell you why they like other form factors or 2) tell you to look at other offerings (such as those above). Losers!

I would even consider the Turing Pi, even though its under powered with only quad cores with 1G mem each. Really an educational toy. I hope then they have the module LED pointing in a useful direction for running lights. Plenty of USB for AI dongles, but still Raspingdoodleburry based. Still …

However, since I am not a pi fan, mostly because monopoly aspects, I did just order a Pine64 Clusterboard. That will retire my 3 Odroid C1 current on the cluster, well not really, that will open them up for additional robotics projects. SBC based clusters are clumsy and too complicated given clusters based upon compute modules had been introduced by gumstix years ago. Note that the gumstix “stagecoach” design is posted by gumstix so was always ripe for copying.

I note that a Rockchip RK1808 with 3TOP NPU is coming from Pine64 with the same compute module footprint. So there appear to be options of a 64bit 2Gigabyte compute and an AI compute module. Whether I need go wild though is a question, since I have a NVIDIA Jetson Nano and my Parallella. I note that there are USB ports in any event so probably need not burn cluster slots with the AI compute module, just need add USB version.

Since the Clusterboard is half the price of the Turing Pi it has to get my vote given AUS dollar means I need multiply all the costs by 1.5.

The Clusterboard will be a great docker based and or Chapel based toy.

OH … MY … GOD! A cluster of cluster boards. Eat shit hardkernel!

Short cut to static IP on HypriotOS using linux

Posted in Linux, MQTT, node-red, Raspberry Pirate, RaspingBreathburryDOodlePi on December 23, 2019 by asteriondaedalus

So, go try understand the new flash utility for Hypriot OS. Ignore the blog entries as the wacker has no technical writing skills.

Seems you need only read and understand the FAQ. All you need to know is:

>flash --userdata setup.yaml

With setup.yaml based upon one of the examples from the flash samples folder.

First of all you need flash installed on your linux box, since it does not run on windoze.

The flash utility can be installed on Debian 10 with:

>sudo apt-get install -y pv curl python-pip unzip hdparm

>sudo pip install awscli

>curl -LO

>chmod +x flash

>sudo mv flash /usr/local/bin/flash

You can test it with:

>flash --help

OR, you can do what I eventually did, since it took me hours to find you couldn’t set the static IP on a HypriotOS host with the old tricks no more.

So, I set up for flash utility but when I stuck a previously bombed SD card into my Debian 10 box, the SD card of course was readable.

So, here is your short version to set up a static IP with HypriotOS without having to setup cloud-init and all that jazz.

Download a HypriotOS image zip, say:

Unzip the image and burn to sd card using etcher.

If you have the sd card in your Debian 10 machine, open it using graphical file browser. Open and edit the following file using the file browser’s built in editor:


Use the example static.yml file in HypriotOS sample folder and edit up the user-data.yaml file to suit your static IP setup.

Take sd card out of your Debian host and insert into your target RPI.

BOOT FOR THE FIRST TIME and voila! You will find your HypriotOS host on the static IP you set up in the edited user-data.yml file.

Note, the BOOT FOR THE FIRST TIME. That is, download image, edit the config in user-data.yml then BOOT FOR THE FIRST TIME.

Nice accident si?

Message repeats, without the flash utility installed :

  • Insert SD card into USB SD card reader.
  • Insert USB SD card reader into Linux box.
  • Bomb Hypriot onto SD card. Do not remove it. DO NOT BOOT IT!
  • Use text editor on Linux box to edit user-data.yml file on SD card in the USB SD card reader. The file is at the top of file system so easy to find when you open up the SD card in a file browser.
  • Safe the updates to user-data.yml on the SD card.
  • Unmount the USB SD card reader and insert the SD card into your RPI.
  • Now you can boot.
  • You needn’t have used the static IP example but, assuming you did, you now have a HypriotOS box with static IP.

Oh my, O Pi

Posted in Docker, MQTT, node-red, Raspberry Pirate, RaspingBreathburryDOodlePi on December 23, 2019 by asteriondaedalus

Just about had enough of Orange Pi Zeros. My home server stopped serving again.

I tried balenaOS and couldn’t get it up on the network.

I then tried ubuntu server same. I thought I must have plumb forgotten how to set up static addresses.

I relented and went and tried latest armbian, despite the ever presence of that wanker Igor.

Now, funnily armbian faired no better. Yet I would not have gotten that wrong since armbian comes with nmtui which handles the fiddly bit behind the scenes.

Go figure. Found a but in redhat against x86 that had the same behaviour. Not much help but it did provide an idea on how to potentially get the system up. The bug required one boot up without Ethernet attached.

So I tried that and voila! Up comes the OPI on static address. Well I felt sure then a bug in all three operating systems running on OPI right? Of course not.

Yep, you guessed it. The OPI stayed up for a while then went offline again.

I had the 3wire serial in so had an avenue to poke around.

I tried shutting down, pulling Ethernet, powering up and connecting Ethernet once booted. I knew in my heart that would not fix it and it hadn’t. The second boot did not see Ethernet come up.

In fact, while the Ethernet was up, I did manage to get snap installed. Snapped in mosquitto and then most of the way through node-red when the Ethernet dropped out.

So, I started poking through the logs and it kept complaining about a loss of carrier. I note also that without doing anything else the network came back up for a while, then went down again. I am suspecting flaky SOC or board. Much like my first experience with OPI.

So, dumping the OPI Zero server for the house and going for HypriotOS on my RPI 3B+.

Putting that raspingdoodleberry Pi to good use

Posted in Docker, Raspberry Pirate, RaspingBreathburryDOodlePi, The downside of Opensource on December 22, 2019 by asteriondaedalus

So, used Etcher to burn an SD with HypriotOS at:

  • Version 1.11.4
  • hypriotos-rpi-v1.11.4.img
  • Docker 19.03.4
  • kernel 4.19.75
  • Dated 04.11.2019

Booted the RPI 3B+ and added docker-compose via:

  • sudo apt-get update
  • sudo apt-get install -y apt-transport-https
  • echo "deb jessie main" | sudo tee /etc/apt/sources.list.d/hypriot.list
  • sudo apt-key adv --keyserver --recv-keys 37BBEE3F7AD95B3F
  • sudo apt-get update
  • sudo apt-get install docker-compose

Grabbed my favorite MQTT setup, all grown up now, emqx with:

docker pull emqx/emqx:v3.2.7

Thence onto node-red with:

docker pull nodered/node-red

The fiddly bit seems to be to get the MQTT nodes in the node-red to connect to the emqx broker. None of the standard tricks seem to work, such as the default use of –LINK from the node-red guide on using it under docker. Hence, the downloading of docker-compose as I want to see if starting emqx and node-red via compose sorts the problem.

The problem is eclipse-mosquitto nor two or three other MQTT brokers, including emqx never see a connection from the node-red container. I tried openning up ports etc. I opted for emqx since it comes with an admin console so it is the most straight forward way to 1) see that the MQTT broker is up and 2) you have visibility of client connections if/when they are made.

Otherwise I am likely to recommend the MobaXterm as it allows me multiple sessions and session types. I can ssh into the hypriotOS or VNC onto my debian server at the same time.

I also opted for MS Visual Studio Code, since I use is for my PlatformIO dabblings. The remote explorer allows me to edit files on the RPI/OPI/BBB/C.H.I.P/ODRIOD W/ODRIOD C1/Parallella/NVIDIA Jetson Nano.

Bad Broadcom, bad, bad!

Posted in ODROID vs RaspingBreathburry, RaspingBreathburryDOodlePi, Sucky Wucky RaspingBreathBurry on May 20, 2019 by asteriondaedalus
Bad Bad Broadcom

So, with antitrust investigations, including accusations of monopoly practices by Broadcom, does anyone remember ODROID-W?

I do.

The rants in the Raspingdoodleberry Pi community about ODROID cheating, even though RPi comes under Creative Commons were interesting.

The gotcha appeared to be the documentation was Creative Commons (CC), even the design documentation, but building hardware based upon the design documents was not (apparently) acceptable to some.

The notion of opensource hardware appears, in fact, to be PCB level and not schematic level. So, without specific restrictions in place, building a PCB from the supplied schematic is a remix, in tune with the CC offered by the rasping lot.

So, the idea that can remix the schematic design, as you may or may not have had to to come up with ODROID-W, but you can’t build hardware from that schematic to get remixed PCB design is curious? What is the point then of that CC?

The variant of CC applied by The Rasping (is that a better jibe) should have been Non-Commercial, No Derivatives. Since The Rasping did NOT apply that restriction THEN all the bleating by members of The Rasping was unkempt, uncalled for and The Rasping should have culled the conversation and educated its members. In fact, it may draw attention by any investigation into Broadcom, since the banter was likely monopolistic in intent, especially where Broadcom employees joined in the discussion on The Rasping.

All the gaff about using the poor Raspingdoodleberry software developers efforts, when the software was offered opensource! Suck it up Princesses. You only asked for attribution. You got it.

So, is this just monopolising by Raspberry Pi community? How connected is that practice with accusations about Broadcom practices?

The more interesting thing is, apart from potty talk from the Raspingdoodlebury community, there appeared no other action directly on their part. The action on behalf of the Raspingdoodlebury Pi was apparently taken by Broadcom (according to some viewpoints).

Its hard to unpick the Broadcom/Raspberry Pi think.

Interesting, all very interesting.

I wonder how broadly the investigation into Broadcom, and monopoly practices, will look?

Docker Pirate?

Posted in Docker, RaspingBreathburryDOodlePi, thingbox on August 26, 2018 by asteriondaedalus

So, coincidence right?  I joke that the ODROID-W is a Raspberry Pirate right!

So, you can get a docker based Rasbian lite that runs on the RPi 3B+.

And, if you hurry, Udemy has a not bad course on Docker for sub $20.

Not to mention various pdf books around the place on Docker.

The tutorials on Docker website are a must.

And I think I really need to learn Docker for what may be coming up at work, so win win.

Ultimate Insult

Posted in ODROID-W, Raspberry Pirate, RaspingBreathburryDOodlePi on July 16, 2017 by asteriondaedalus

Rasberry Pi community bullies hard kernel to drop ODOID-W through broadcom connection. Now comes out with RaspingBerryDoodlePi Zero W. 

They should be disqualified from using “W” annotation. 

New way to stuff erlang/elixir onto embedded arm

Posted in Elixir, Erlang, Open Source can be professional, Orange Pi, RaspingBreathburryDOodlePi on June 13, 2017 by asteriondaedalus

YES, it is “designed” for RaspingBreathberryDoodlePi BUT worked a treat for OPiZ.

See the following link.


Posted in Rant, RaspingBreathburryDOodlePi on December 2, 2016 by asteriondaedalus

Rest in Pieces you Fracking RaspingBreathBurryDOodlePi (RIPuFRBDPi).

Rest in Pieces.

So, wife’s off at Work Christmas do.

Dogs are walked, fed and washed.

I dragged out a USB keyboard and USB mouse to connect to the RBDPi to at least get Erlang onto it and to install either of RabbitMQ or emqttd – so it could maintain some semblance of dignity by acting as a messaging host.

Go figure.

I had the start-up sequencing streaming over HDMI to my monitor, got to login prompt, no response to keyboard.

So I fired up my Atom box, running 32bit Debian, and sure enough, keyboard was fine.

So, the USB ports on the RBDPi my friend gave me appear to be kaput.

Neither worked.

So, it goes to the awaiting garbage bin along with the CurieNano DFRobot wouldn’t take back on warranty.

What is a real smack in the face, the ODROID C1 I inherited on the same buddy was sitting their taunting me.  I looked, for a fleeting moment, for the micro HDMI cable I have but it’s in here somewhere …


Have you ever seen a mating ball of grass snake?!


… give me a freaking break!

It’s Friday.

Guess I’ll wash the dishes.


Saturday was blown going to a most-of-all-day pub crawl bucks for  a friend.

So Sunday …

Here it is Monday and I finally found that micro-HDMI cable … in a second mating ball of cables in yet another box.