Skip to main content

Multi Arch Dsmr Remote Datalogger With Logging

·2 mins

The old Docker image only worked on a Raspberry Pi and was built on a specific Raspberry Pi Python image. This new release is based on the more generic and official Python 3 Alpine image. Also, I’ve figured out how to build images for multiple architectures without building a single image on each platform.

Access to log files #

In the previous image in some cases, an error was printed to the output, but that is not a reliable way to see the things that went wrong. So I’ve added proper logging in the client and all logs will be written to /etc/dsmr_logs in the container. Mapping a directory on your host to this folder ( -v /path/on/host:/etc/dsmr_logs ) will allow you to view those log files to find possible problems with reading your smart meter or when pushing a telegram to your DSMR Reader instance.

Building multi-arch images #

By using the official Python image in combination with buildx, it is now very easy for me to support multiple platforms. Buildx automatically creates an image manifest containing the selected architectures. This means that I don’t have to tag an image for each version/architecture combination (for example latest-armv6 or latest-amd64 ) but that there is just one tag ( latest ) for each architecture and that Docker automatically grabs the correct image. So, as long as the architecture of your host is 386, amd64, arm/v6, armv7 or arm64 you can just grab the latest or v1 tag and Docker will do its magic.

Versioning #

I’ve also introduced Semver-style versioning with the 1.0.0 release. This will ensure that with each release you know what kind of release it is. In a nutshell, given a version number vMAJOR.MINOR.PATCH:

  • MAJOR will increase when there are incompatible changes,
  • MINOR will increase when functionality is added in a backward-compatible manner, and
  • PATCH will increase when making backward-compatible bug fixes.

When releasing a new version, I’ll create three new Docker images:

  • latest - Containing the most recent version, even if the version is a major release (and thus can break your container/implementation).
  • v1 - Containing all non-breaking minor and patch releases.
  • v1.0.0 - A specific release image. Won’t be updated when a new version is released.