Archive for the MQTT Category

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

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+.

Pegaleg

Posted in ESP8266, MQTT, node-red, OpenSprinklette on November 11, 2018 by asteriondaedalus

So, one file I had fun getting off my laptop was the source for the parser for the google calendar event titles.

The titles, as discussed previously, would be a list of sprinkler group or unit callouts.

I managed to ssh onto the laptop from my desktop to lift anything I wanted before I trashed the laptop with a clean Debian install.

While waiting for the install, I opted to tart up the parser with some sanity.

The problem for the distributed opensprinklette design is that there is no editor per se to police the entries in the google calendar event title. So, if any unwanted text is in the title, the parser running on the node-red server will drop the lot. Harsh I know, but the distributed nature of this entails some trade-offs.

So, I did add some smarts to avoid sending repeated call-outs to a sprinkler. A burst of call-outs will go out once the event title is parsed. The ESP8266 gadgets don’t mind if a single sprinkler is pummelled – it simply results in the time starting from the last received call-out – which won’t be that many milliseconds behind the first.

Still, to opt for a defensive scheme meant testing for a call-out in the return from the scan of the line before adding it to the return. Simples tick!

So, even if the user pummels the title of the event with multiple call-outs to the same sprinkler, the parsed response will only contain a single call-out.

So something like this in the google calendar title:

group1=1;group1=[1];group1=[2,2,2,4,4,4,4,1,1,1,3]

will return the following in the node-red response (prior to fully concatenating into a MQTT topic):
[
"group1/1",
"group1/2",
"group1/4",
"group1/3"
]

Slowly

Posted in MQTT, node-red, Orange Pi, The downside of Opensource, Ubuntu Core 16 on September 6, 2018 by asteriondaedalus

So, 4 days ago I reported to node-red group that the –beta snap of node-red did not start as a service on armf version – at least when snapped onto Ubuntu Core 16 running on Orange Pi Zero.

When I started this journey, the following command would not download a snap but it would prompt:

sudo snap install node-red

The prompt would report there is no –stable version and I had to choose between –beta or –edge.

In fact, the snapcraft.io site also confirmed this as it only had a beta or edge version in the drop down for armf.

So I would install node-red with:

sudo snap install --beta node-red

But, as I mentioned, it did not start a node-red editor on :1880.

If I used the following:

snap services

It would report the mosquitto snap I snapped in was indeed running a service.

Et voila! If I typed the following:

sudo snap run node-red

Then node-red would run in foreground.

Not much use since it needed to run as a service.

Starting node-red as a service is easy peasy, if you read the help file, with:

sudo snap start node-red

Except, that raised the error “node-red ain’t got no stinking services to run” which confirmed that the –beta snap for node-red, at least the armf version, had something funky going on.

Curiously, on my freshly built laptop running amd64 version of debian 9 stretch, with snapd installed, the snap of –beta node-red ran as service immediately after install.

That points definitely to something funky going on in the armf Ubuntu Core 16 OPiZ combination.

Then, as likely because of my prompting, node-red community pushed a –stable version of node-red out to snapcraft.io (something like 4 hours ago as I type).   The youngest version, –edge, was 6 months ago.

So node-red didn’t have a –stable for armf!!  Some problem with their build (apparently).

Working with node-red community now to sort this.  Such a good Citizen I am.

gc

 

 

It’s a form of self flaggelation …

Posted in MQTT, node-red, Orange Pi, The downside of Opensource, thingbox, Ubuntu Core 16 on September 6, 2018 by asteriondaedalus

… this snap stuff.

What I have worked out so far with orangepi zero, Ubuntu Core 16 and Snap.

Ubuntu Core, because they force updates, is failing to come back after scheduled reboot. Or so it seems.

The serial port responds but the device is not on lan.

All attempts to attach at the IP address reported in the message displayed on the serial port fail.

Hard reset (power off, power on) brings board back up with new IP address but then the cycle repeats. Schedule reboot does not come back up.

Weird but if I use a sudo reboot the device comes back up with IP intact.

So, something about the core auto reboot.

I tried a debian server but snapd would not install. Rasbian apparently is a no go, so maybe they meant arm generally?

Otherwise, moquitto snaps and runs fine. The node-red snap installs but no service starts. No config comes with snap and snap start node-red returns no service available message. The node-red snap will otherwise run in foreground.

Snappy!

Posted in MQTT, node-red, thingbox on September 1, 2018 by asteriondaedalus

So, yes.  I have been playing with Snap while doing the Docker course.

I did install Ubuntu Core on the OPi and managed to get Mosquitto snap running.  But the node-red snap keeps failing to connect or install (with time-outs reported).   It is 6 am on Saturday, so is that indicative of northern hemisphere loading on the Net?  Who knows, wife, sister in law and two of there friends just finished their party.  I was woken when the retrobates left.  So, I am dabbling.

The same old story though.

Help is out of date.  I installed Docker version of snapcraft on my linux laptop.  You were supposed to use that if you weren’t using Ubuntu – I prefer Debian.

There wasn’t enough data to get something running on that Dockerized snapcraft.

I then found another help site that pointed out that the Docker version of snapcraft was deprecated.

You can now snap snapcraft into place.

Then found an interesting snap that I subsequently deleted.  It, however, reported an error on start up.  No help on the snap so dumped its arse.

I will perceiver with snapping MQTT and Node-Red onto the OPi.  If that holds its water I might still use the OPi as the house server.

There is, however,  thinger.  There is a RaspingdoodleburryPie image.   I have loaded the snap of the server onto my linux laptop to do a trade-off against Node-Red.

Wait … wait … wait … finally, Node-Red snapped into place on OPi.

So, with Mosquitto running, Node-Red MQTT nodes talking, I have a 5 minute timer to leave the system running to see if it keeps going.

The thing I will need sort, however, is that the snap system will push updates (I could one happening the other day).  So, I will need look into holding off the pushed updates to avoid the updates confounding the testing.  As you’ll recall the initial suspicion was flaky hardware.

Niggly

Posted in Embedded, MQTT, NodeMCU, OpenSprinklette, Orange Pi on August 16, 2017 by asteriondaedalus

I may have some more design work for the opensprinklette node-red implementation.

The nuance is that the google calendar node will happily trigger on event edges but the triggered response seems to be a dump of the calendar event parameters but not the edge that triggered the node.

It might be as simple as another parameter on the configurator to tell it whether it is for sprinklers on or off

The other might be using the before event.

Have two outputs then to act as start and stop.  Feed the stop into a timed node.

Either lapsed or absolute is another question.

Much of this is trying to think in a dataflow rather than an imperative idiom.

I want to think also about ACK from the WeMOS sectors. That might want a watchdog timer.

The lwt from the WeMOS sector will need a response. Although any sector/zone on, while WeMOS is down, falls on deaf ears.  Stil, it needs to be logged and reported.