Et Voila!

So, I rebuilt a brand new single relay opensprinklette board. I did notice, as I stripped the original, that the end of the electrolytic was a tad “swollen”, oh dear, oh well.

I had a new batch of 47V TVS, physically smaller than another batch I had previously bought. So, that means I don’t need hack at the boards to fit them. I thought the original problem was that I had was using a lower voltage TVS than I should have been. Only marginally I thought. It didn’t turn out that the slightly lower rated TVS was the problem, though hacking the board to fit the larger and thicker leaded TVS probably helped me fry that board. I likely jumpered lead to the wrong place or inverted something.

No matter. Turns out a clean build, with all the properly rated components, still sees the brownout after a few cycles.

Hmmmmmm.

So, I shorted the shutdown pin to the VIN as recommended.

I then set up a node-red test that turned the relay on/off with a 50% duty cycle with 5 seconds in each state. It has been running now for about an hour without failure. So the quirk is that the Pololu 5V down converter seems more sensitive than the 9V down converter.

I will still need to short the shutdown on the quad board to be sure. I am now ready for final versions of the two boards, with minor tweaks including additional terminal blocks to keep the wiring tidy.

I am in the process of playing with a Kotlin front end for Android to manage the home setup. That is really just a prototype as the home setup will start with a single quad unit. I will build HMI system up as I get a hang of Kotlin development.

Brown outs and all that jazz

So, now having a DSO on the bench, I was looking forward to solving the problem of the brownouts on the openspriklette prototype boards.

I saw the brownouts on the single relay version. I had a sneaking suspicion I might not see the problem on a quad relay version. The reason is simple. The single relay version uses the 24VAC to 5VDC circuit but the Wemos D1 mini does not have power conditioning aboard as sophisticated as the Wemos D1 R2.

The Wemos D1 mini does have an ME6211 regulator to down convert 5VDC to 3.3VDC. The Wemos D1 mini does not have an 9VDC-24VDC input option, which drives the need for more sophistication in the power input stage. That means the Wemos D1 mini is reliant on the power conditioning provided by the off-board power supply.

So, I assembled a quad board. It has the D24V3F9 9VDC out by Pololu. Older tech, but that’s what you get from Australian stores. So, fun story, that quad board works fine. I even attached two solenoids and cycled them on/off simultaneously. No brownouts.

Fun fact though. I had not tied the shutdown to VIN on either design. The specs warn if you don’t you could get strange behaviour. So, I still need retest the single relay board with shutdown tied to VIN. The problem, I did rather hack at it with some component swaps. I did get the bridge pins around the wrong way. There was smoke. No matter, I had three boards made – OSHpark minimum quantity. So, I will build another board and re-verify the behaviour without the shutdown tied to VIN. I will then tie the shutdown to VIN to see if that helps.

Oh! The DSO. Didn’t need it for the quad relay board testing. Will need it once I build up a single relay board.

node-red on docker – problem solved

So, I gave up on my OPI Zero as the house server, because it kept disconnecting. I did then try to buzz out a second OPI Zero, but with the same result.

I had the RPI 3B+ I bought and then got shod of thethingbox, as it didn’t run the node-red out of box so that flows were preserved on reboot.

I decided to go for broke and bomb the RPI 3B+ with HypriotOS.

I then tried out the instructions on node-red site for node-red on docker. Good.

Tried the mosquito MQTT server example. Not so good. The node-red would not connect to the MQTT server. Typed the example it, quadruple checked it. Nothing.

Gave up. Worked out how to install Snap onto HypiotOS.

Why would you I here you say. Well 1) I had the shitz up because I couldn’t get the dockerised node-red talking to the dockerised mosquito broker from the relatively simple instructions and 2) it kinda makes sense that apps like mosquito broker and node-red are saner as Snaps.

So, worked fine as two Snaps of node-red and eclipse-mosquito.

Still bugged me that I couldn’t get the docker versions running.

Also found my RPI 3B+ was dropping off the network. That put paid to the idea I had dodgy OPI Zero boards. That was a harder ask, in any event, since two flaky boards? You had to be plain unlucky.

So, culprit is, in fact, my old Netgear wifi extender. An interent search finds, indeed, that wifi extenders are notorious for dropping off. On top of that, for some reason I could not login to my wifi extender using the usual mywifiext.net. Although, that problem cleared itself after a couple of hours, so who knows what goes on when I am not monitoring the thing. Yeesh!

It was too long a stretch to blame the wifi extender for the docker problems as the web page found the node-red fine, the node-red not connecting to the mosquitto broker was internal to docker, so would not be affected by the wifi extender problems. The wifi extende was up more than it was down so I soldiered on.

So, the wifi extender aside, I did rip out the Snapped apps and retry with the docker examples. In fact, I opted to drop eclipse-mosquito since it did not have an admin channel. I was going to go with my fav, emqttd, but found it had become emqx.

So, pocking around I found that the emqx was up. Same problem, no connection with the node-red container.

The node-red site recommended:

docker run -it --name mybroker eclipse-mosquitto

I beefed that up to be:

docker run -it -p 18083:18083 --name mybroker emqx/emqx:v3.2.7

That gave be the penulimate arm64 version of emqx, running with admin accessible. I found the admin port up and running so …

Turns out the error was in the node-red example at the node-red site. The error starts with:

docker run -it -p 1880:1880 --name mynodered --link mybroker:broker nodered/node-red

What the node-red instructions tell you is to use “broker” in the MQTT node in the node-red flow. Turns out you actually need to use “mybroker” to get the connection. Once I used “mybroker”, I got a connection and all was fine from then on – save for the wifi extender dropping in and out.

Happy Christmas to me!

So, the wife was pestering me to give me hints as to what I wanted for Christmas.

I have a workshop full of stuff. I had recently bought myself a dual adjustable power supply, so what does one really need.

I shrugged my shoulders and said, an oscilloscope I suppose. She said sure, what is that? I explained it, trying to make it sound necessary. It was, sort of, because I am trying to buzz out the problem with the pesky power conditioning on the opensprinklette boards – the solenoid for the sprinkler causes a brown out in the ESP8266 board.

Sure she said.

What I said?

Sure.

So I immediately ordered a Hantek DSO5102P from Aliexpress. It was in an in country warehouse and is now just today, the day before Christmas, wrapped (by me) ready for the Wife to hand it to me tomorrow.

I will need feign surprise.

Short cut to static IP on HypriotOS using linux

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 hypriotos-rpi-v1.10.0.img.zip

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 https://github.com/hypriot/flash/releases/download/2.4.0/flash

>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:

https://github.com/hypriot/image-builder-rpi/releases/download/v1.11.4/hypriotos-rpi-v1.11.4.img.zip

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:

user-data.yaml

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

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

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 https://packagecloud.io/Hypriot/Schatzkiste/debian/ jessie main" | sudo tee /etc/apt/sources.list.d/hypriot.list
• sudo apt-key adv --keyserver keyserver.ubuntu.com --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.

Oh COME ON!

My dopey opiz server now fails 5 mins after startup. Nothing has been changed so likely just dodgey hardware. Going by discussion on the Net nanopi are as dodgey. Is there a decent quality offering in that form factor really.

The Phoenix arises

I got shod of my old Linux laptop as the battery was dead and two keys had fell off. So I did rather buy me a new HP Spectre laptop. That new laptop is now my Windoze box so my old Windoze PC was surplus. I do have to say, I did rather have the shitzup with the PC as I have regretted moving from Windoze 7 to Windoze 10 on that system. Regretted because Microsoft did rather frack up the updates, as we all know.

That old PC did not happily or at all really update since it was moved to Windoz 10.

I am not sure how far behind that piece of crap Windoze was but I did fire it up to lift stuff off it this last weekend and Windoze complained it needed 8 gig of space to download an update and couldn’t find it. Odd since the machine has a 1.5Tbyte hard drive.

The machine was so slow. What with an extra special indexing widget that had to run for an hour on start up, that slowed the machine to a crawl, just so file searching would be super duper fast, because it was always a good idea to NOT index as you went. That plus other choke points meant that I did go and buy me a 2Tbyte USB drive (had to buy one with USB 2.0 of course for use with the ye olde hardware) since dragging the files I wanted to save, into Onedrive, was (as it turned out) not the quickest option.

So, I did not bother trying to save all the things I probably should have, as I was so spiritually raped by just how clagged up the machine was. It was, in effect, terminal.

In the end, I burnt a DVD with Debian Buster and installed that over the top of the Windoze so I would simply not have to deal with Windoze again on that machine.

Now, with Linux aboard, the machine starts in about a minute. Everything appears instant, compared to what it was.

I hear Windoze market share is decreasing.