Today I've released version 1.0.0 of the DSMR Remote Datalogger Docker images. The most notable changes in this release are multi-arch support and making it possible to access logs.
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-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
arm64 you can just grab the
v1 tag and Docker will do its magic.
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
- 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.