¶ Overview
This project is intended to realise a proof of concept of a smart home mirror, used to drive a home automation system based on OpenHAB 3.
The hardware is based on the famous Magic Mirror C4 by Waveshare.
¶ Technology used
- Yocto and Openembedded projects: these are used to create a Linux distribution to drive the hardware
- KAS: a wrapper for Yocto to streamline the build process of Linux distributions.
- Flutter Embedded: this is used to create a launcher app to which the system should boot and from which all other features and functions are managed
- RAUC or Mender: a framework used to provide OTA updates to the board as soon as it reaches production grade
- Openhab: a project used as the core of home automation
- Containerization: some main components will be running in their own containerized environments on top of the Yocto build.
- Gitlab: source code management tool, CI/CD and agile project management tool to drive the development
¶ Hardware used
I am using an Ubuntu 22.02 machine (64bit) with 12 cores for building the Yocto image. The more core/threads you have on your machine, the faster the builds will be. Gitlab, Minio S3 and Wikijs are running locally on the same machine in dockerized mode and behind a reverse proxy. The setup of the CI/CD registry and how the generated builds are deployed to Minio for storage, is out of the scope of this document.
For developing the Flutter App, any machine should serve. I am using a Macbook air M2 with 16GB of RAM for that purpose.
¶ Development Tools used
- Visual Studio Code: used as
- Editor for Yocto / KAS configuration files
- Development tool for flutter applications
- Eclipse Studio: used mainly to modify the OpenHAB project to fit our specific needs.
¶ Workflow
Milestone 1 is a preparation milestone during which the Gitlab projects have been setup and a basic build for the target have been provided.
As of Milestone 2, a Gitlab workflow has been enacted to ensure all code changes are carefully review and selected before finding their path to production code. The workflow is described with the following steps:
- a developer with Developer role in Gitlab clones the project locally for local development (master branch)
- they creates a topic branch locally from the default master branch
- they include all the necessary changes and run all the required tests locally
- once work is completed, the topic branch will get pushed to Gitlab and a Merge Request is being generated
- only a Maintainer can review the Merge Request and allow it to get integrated or not
- once the changes have been merged to the default branch, the topic branch can be deleted
- the developer has to make sure to pull latest change from the default master branch
- repeat steps 2 to 7 for future implementations
¶ Release strategy:
Releases are mainly tags on the production branch. Once the software on the master branch has enough new features to be released, a merge request should be generated to push latest changes to production branch. If all tests have been concluded successfully, the
¶ Architecture
¶ System partitions
The CM4 module being used has the following specifications (SKU: CM4104008) :
| RAM | 4GB |
| eMMC | 8GB |
| Wireless | Yes (WiFi + BT) |
Using the following Mender's variables in the Yocto build:
MENDER_BOOT_PART_SIZE_MB = "128"
MENDER_STORAGE_TOTAL_SIZE_MB = "7456"
MENDER_DATA_PART_SIZE_MB = "4800"
the system ended up with the following partition table:
| Mount device | Size | Format | Description |
| /dev/mmcblk0 | 134 MB | FAT | Bootloader, config files, cmdline.txt and DTBs |
| /dev/mmcblk1 | 1309 MB | ext4 | Partition A: used for Mender updates |
| /dev/mmcblk2 | 1309 MB | ext4 | Partition B: used for Mender updates |
| /dev/mmcblk3 | 5042 MB | ext4 | Partition used for persistent storage |
¶ Planning
¶ Milestone 1: Bring-up
- Basic Yocto build that boots into a shell. It should include all required drivers for display, touch and sound.
- Setup CI/CD in Gitlab for build auto generation
¶ Milestone 2: Update with USB
- Check whether to use RAUC or MENDER
- Setup update from USB stick
¶ Milestone 3: OTA
- Setup OTA update
- Setup update tool interface to manage updates
- Use Gitlab CI/CD to push images to cloud server
- Configure target to auto-check for newer images and run updates
¶ Milestone 4: Containerization
- Check whether to use Docker or LXC on target
- Setup containerized environment
- Setup inter-networking
¶ Milestone n:
- Bring OpenHAB on target
- Write a minimal App with Flutter to control a switch (On/Off)
¶ Setup and Development
¶ Yocto/ Kas
Kas is a wrapper provided by Siemens to streamline Yocto builds. We are going to use the “kas-container" variant mainly to build our image:
- Install Kas to a directory using the following command:
git clone https://github.com/siemens/kas.git - Add the directory to your path permanently following this guide. You might need to restart you PC for the changes to take place
- Now create a directory where all the builds should take place. The directory should contain:
- a
.config.yamlfile used by Kas to define the build system. More to that later on. - a cache directory to store the downloads and sstate directories used by Yocto. This allows for faster builds for consecutive runs.
- a directory for each Yocto layer you plan to include in your build. An example would be
- a
- Now let's create our own layer to define the build distro, machine and image to generate (TBD)
¶ Yocto cheat sheet
|
Command/Variable |
Description |
Purpose |
| bitbake example-image -e | grep “^DISTRO_FEATURES” | Shows what features are getting baked in within the image. | Used to optimize image size and to remove unnecessary stuff |
| bitbake-layers show-recipes recipe-name | Shows in which meta-layer the recipe is to be found | Used when looking to add a new recipe to the distro |
| PACKAGES =+ | Defines the packages that a recipe (.bb) provides | Used to identify support packages/tools for a certain package. Tools that can be installed with it |
| bitbake example-image -c listtasks | Lists all the tasks in their sequence that will be run when baking an image or a recipe | Identify the order in which tasks are run. |
| du -d 1 -h | Used at the target prompt to identify which directories are occupying space the most. | Used for space optimization |
| oe-pkgdata-util find-path “path-to-artifact-on-target” | Used to identify which recipe is producing the artifact on rootfs. | Used mainly to remove unwanted artifacts. Use IMAGE_INSTALL:remove |
¶ Yocto - commonly used directories
| Path | Location | Purpose |
| ../poky/meta/files/common-licenses/ | Build directory | Includes all the licenses used in Poky and that can be included in custom projects |
| ../build/tmp//workraspberrypi4_64_magic-poky-linux/magic-mirror-image/1.0-r0/rootfs/ | Build directory | rootfs directory and all the artifacts in it |
¶ Updating from USB (Standalone deployment)
Mender offers the possibility to update the target device locally without connecting to a Mender deployment server. This functionality is useful when the target is not accessible online and needs updating for some reason or another. This is documented in detail on Mender's website: https://docs.mender.io/artifact-creation/standalone-deployment
The steps to carry out the offline update are as follows:
- modify the target Yocto build by adding some changes to (adding a recipe)
- copy the generated .mender file to a USB flash drive (best formatted with FAT32)
- attach the USB flash drive to target
- with the
dmesgorfdisk -lcommands in order to check the available storage devices on your system and the file system they are using - create a mount point for your USB device with the following command:
mkdir /media/usb-flash - mount the USB storage device to the mount point that was just created:
mount /dev/sda1 /media/usb-flash - standalone deployment requires that the Mender client on the target be disabled before applying the update. This can be done with the following command:
systemctl stop mender-client - ensure that mender-client has been stopped correctly with:
systemctl status mender-client. This should return a statusinactivefor the service. - now the update can be applied with:
mender install /media/usb-flash/MENDER-DELTA-FILENAME.mender - The update will take some time to carry on. You should see a progress update displayed.
- Once the update is done, a reboot is necessary if some rootfs base files have been changed. Restart the system using
reboot - log in again with SSH and check if the package that was added to the Yocto build is now present on the rootfs
- if everything is ok, you can commit the changes so that mender knows that the update is permanent. This can be achieved with
mender commit - should you revert to the build that was present earlier, use
mender rollback
¶ Testing
¶ Milestone 1: Bring-up
| Index | Test name | Test description | Test results | Pass |
| 1 | Basic boot with display enabled |
|
Target boots successfully. This can be confirmed with LED activity and serial output on the display | √ |
| 2 | SSH connectivity |
|
Target boots successfully. SSH client asks to accept fingerprint for first time. Use can use bash commands over SSH. | √ |
| 3 | Internet connectivity |
|
|
√ |
| 4 | Touch |
|
Multiple coordinates and touch events are shown in the prompt successfully. | √ |
| 5 | Sound input |
|
Voice can be recorded and played back successfully | √ |
| 6 | Sound output |
|
Some randomly generated sound can be played and heard | √ |
¶ Milestone 2: Update with USB
| Index | Test name | Test description | Test results | Pass |
| 1 | Partition layout |
|
Output:
|
√ |
| 2 | Update from USB |
|
tree can run successfully and list the underlying directories and files, as expected | √ |
| 3 | Release Naming |
|
|
√ |
| √ | ||||
| √ | ||||
| √ |
¶ Milestone 3: OTA
- Setup OTA update
- Setup update tool interface to manage updates
- Use Gitlab CI/CD to push images to cloud server
- Configure target to auto-check for newer images and run updates
¶ Milestone 4: Containerization
- Check whether to use Docker or LXC on target
- Setup containerized environment
- Setup inter-networking
¶ Milestone n:
- Bring OpenHAB on target
- Write a minimal App with Flutter to control a switch (On/Off)