Multi Arch DSMR Remote Datalogger With Logging
New version of DSMR Remote Datalogger Docker image based on Python 3 Alpine image and supports multiple architectures.
Created Oct 9, 2019 - Last updated: Oct 9, 2019
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.