The following is a guest blog post from Alan Alberghini, who graciously opted to share IOOOTA's journey in adopting Mender.

"I work for an Italian company named IOOOTA SRL whose focus is on IoT devices and, more specifically, we’re currently working on implementing a multi-protocol smarthome gateway/hub solution and all that goes with it:

  • smartphone companion app
  • remote connectivity services
  • data storage, management and analytics

Even in the preliminary design stages, we knew we needed a way to perform remote upgrades as safely as possible as soon as our gateways reached our customers homes.

Although we already heard of Mender back then, we could not afford it for the following reasons:

  • the initial adoption cost was high because nobody in our team nor the hardware manufacturer team knew of it beforehand or had past experiences with it, so we would’ve needed additional time to study it and to ensure that it could work in our scenario;
  • we were in a rush to ship an initial batch of units really soon;
  • the need to transfer the entire root filesystem on every update seemed too much of a cost at the time

Our partners proposed another approach based on an in-house product they developed over the years which could manage remote upgrades with an A/B root partitioning scheme (like Mender) as base of our remote upgrade procedure. The upgrade procedure would:

  1. poll a remote server to know if an update needed to be done;
  2. download a list of packages that would need an update;
  3. save the current root partition state to the inactive root partition;
  4. reboot the system on the freshly copied root partition;
  5. perform the update, by downloading and installing the listed packages;
  6. perform additional checks to ensure the system upgraded successfully;
  7. mark the upgrade as done and prefer the new partition to the old one on next reboot;
  8. rollback if any of the previous steps failed;

Needless to say, the solution on their part was strictly proprietary software and needed some tweaking and further integrations on our part before being in a satisfying condition for our needs.

We then chose to change hardware manufacturing partners and platform for various reasons, while still maintaining a GNU/Linux system base for our software on the gateway boards.

As the previous upgrade solution was no longer available, we tried proposing Mender again with our current hardware partners, who agreed to help us in integrating it on our systems after our initial tests with a proprietary cloud-based solution suggested by them were not satisfying.

The major struggle we had in adopting Mender was that, as we’re working on a non-Yocto based system, we had to infer information for the required uboot changes from the documentation and Yocto recipes available, but thanks to our hardware partners efforts and in the entire Mender codebase being opensource, we managed to do it.

I personally had some trouble in building and packaging the Mender client from source (I’m not really experienced in building Go software), but then found valuable information in the Mender Google Groups list and succeeded.

The server part went smoother and, by leveraging the mender-integration repository and documentation, I was able to integrate it on our already existing web server infrastructure after a bit of configuration tweaking.

We’re now already delivering units based on the new hardware platform and are now also able to monitor the installations via the Mender UI and know in the blink of an eye the status of every unit, which is a thing we could only dream of with the previous solution."

Alan Alberghini

Next post Previous post

ECH2020 is supported by the European Commission under Horizon 2020 research and innovation programme. Read more