The following problem was reported on the IOTstack Discord channel:
Today I rebuild my IOTstack from scratch using the Pibuild process and after restoring my nodered flows I noticed that my serials and GPIO are not connecting anymore.
I don't use node-red-node-pi-gpiod myself but I have been able to reproduce the problem.
One of the main advantages of running services in Docker containers is the relative ease of reverting to the last-known-good container.
One of the biggest problems with reverting to the last-known-good container arises if you don't already know the tag of the image you want to revert to. Sometimes it can be a bit tricky to figure it out. You usually need to go to the container's "tags" page on DockerHub, sort through the update history for your architecture, pick the appropriate tag, edit your compose file to specify that tag, and then, in the words of the old Knight in the third Indiana Jones movie, hope that you have "chosen wisely".
Your chances of choosing wisely are inversely proportional to the amount of panic you're feeling after you realise a key container isn't working and reverting is your best strategy. Panic is the enemy of clear thinking and reasoning.
There is, however, another way. The method described here means you retain the last-known-
A question on Discord described a situation where a new (empty) database had been created. That database contained data acquired since the rebuild but had no historical data prior to the rebuild. However, the person did have a "portable" backup of the older data and wanted to know if it was possible to merge the backup with the live data?
The answer is "yes". Merging measurements will solve this particular problem.
I tried to build a new installation using PiBuilder. I am a Windows user and connect with a terminal emulator (Putty) to the Pi. So far I was not successful. I tried to follow the description. But Windows only mounts the boot partition. The rest of the SD card is not visible to the OS. So I struggle with the step of configuring PiBuilder and also the many steps just to connect to a Pi using SSH.
macOS is the same as Windows - it can only mount the boot partition. That's why I put all the files on the boot partition. It's the easiest way of getting everything onto the Pi.
Sometimes it seems like the first (and sometimes only) advice you get offered for almost any problem with a Raspberry Pi is "check your power supply". You think something like:
"hey, I'm using an official power supply sold as being matched with my Pi so how can there be any problem?"
You look up the specs then stick a controlled load across your supply and confirm that it can deliver the required number of Watts.
Yet your problems persist…
Updated 2022-05-19
On March 12 2022 I noticed a post on Discord by Ukkopahis saying:
As a general principle, I'm not in favour of override files. I think they muddy the waters. I think you're much better off editing docker-compose.yml directly.
That said…
When you use IOTstack to manage Docker containers, you have access to two override mechanisms:
compose-override.yml file. This mechanism is peculiar to IOTstack and is implemented by the so-called "new" menu on the master branch.docker-compose.override.yml file. This mechanism is part of docker-compose.
On macOS, Time Machine pretty much just works. You delete or mutilate a file. Then you realise you want to get back to the older version so you: