Backend / K3s
This part describes my setup and selfhosting Home Assistant and other services by using a containerized approach in Kubernetes. I also describe my setup of hass-lovelace-screenshotter.
Container, Kubernetes, Gitops
Docker and Plugins
Most of my services are hosted on the NUC, I’ve been talking about in previous parts. Recently I switched from a Docker based setup (using docker-compose) to a Kubernetes based setup using K3s. Of course you can always host the official Raspberry Pi Home Assistant software or use any other way to host. On a Docker based setup you will host just the core component whereas on the recommended Raspberry Pi setup some scripts manage all this for you and those scripts will also pull and run Docker images when you decide to use a (official) plugin. HACS still can be installed on your selfhosted container setup, but the official plugin store is not available. So you need to decide in the beginning which way you’re going for: ease of use with less control or selfhosted with a lot more to do. Because I am really into selfhosting the choice was quite easy for me.
Kubernetes and GitOps
Kubernetes heavily relies on declaration of resources which it manages. So in a way you are saying what you want and Kubernetes realizes it for you. Those declarative resources are often created by users in YAML. Some time ago a concept called GitOps emerged, which in a nutshell stores those resource files in a git repository and some software compares the current state of resources in the Kubernetes cluster to the resources in the git repository. If it detects changes it notifies (or applies) automatically to maintain a Kubernetes cluster in the state which is defined in the Git repository.
I am using ArgoCD as my GitOps tool to handle the state of my cluster. For this reason I am able to open source the repository I’m already using to setup my NUC to the public, so you can get an extensive look at my entire setup. The repository can be found here. Please note that I’m using helm-sops in ArgoCD to handle secrets and passwords. I may create a blog post on this topic in the near future.
Hass-Lovelace-Screenshotter
I’ve already described the tool shortly in this guide. This tool just saves a Home Assistant lovelace view as an image. To render JPG images instead of PNG images and keep them TrueColor instead of grayscale (because they won’t work with the Inkplate, see part 2) I created a fork containing the necessary changes. If you’re running container images you can pull my image:
ghcr.io/itobey/hass-lovelace-kindle-screensaver/hass-lovelace-kindle-screensaver:main
The original creator of this tool offered configuration by setting environment variables. Depending on the way you’re hosting the tool this approach is different. As described in the previous paragraph I’m using Kubernetes, so my deployment manifest contains a part with all the environment variables. The entire manifest is available in my repository here. In any case of defining the environment variables, some are important to set.
... env: - name: TZ value: Europe/Berlin - name: HA_BASE_URL value: http://home-assistant.home-assistant:8123 - name: HA_SCREENSHOT_URL value: /lovelace-dashboard/eink?kiosk - name: HA_ACCESS_TOKEN value: "{{ .Values.HA_ACCESS_TOKEN}}" - name: RENDERING_SCREEN_HEIGHT value: "825" - name: RENDERING_SCREEN_WIDTH value: "1200" - name: RENDERING_DELAY value: "5000" - name: LANGUAGE value: de - name: CRON_JOB value: "*/20 * * * *" - name: OUTPUT_PATH value: /output/output.jpg # for Grafana iframes - name: UNSAFE_IGNORE_CERTIFICATE_ERRORS value: "true" ...
HA_SCREENSHOT_URL has the appended ?kiosk to get a fullscreen view. If you do not append this, you will get your navigation menu items on the screenshot. To have this working, install Kiosk mode, see part 5 in this guide.
HA_ACESS_TOKEN needs to be created in Home Assistant. Open your profile (bottom left of the menu) and scroll down to the end. You want to create the token here. Take a note, you cannot display it again and need to create a new one, should you forget it.
RENDERING_SCREEN_HEIGHT and RENDERING_SCREEN_WIDTH are set to the resolution of the Inkplate 10.
RENDERING_DELAY is included to wait for 5 seconds before saving a screenshot. This is necessary, because the iframes take a few seconds to load up. Without this delay these components may be missing on the dashboard screenshot.
CRON_JOB defines to wait 20 minutes between taking screenshots. This can be adjusted by using a cron expression.
OUTPUT_PATH saves the image to a specific folder under a specific filename. This is important as this folder is mounted as well in the Nginx server which just publishes the output.jpg (see part 4 for details).
UNSAFE_IGNORE_CERTIFICATE_ERRORS lets you ignore certificate errors. This is important for me, because I equipped Home Assistant with a longliving selfsigned certificate to have it running over HTTPS and not get the “untrusted” message in my browser (see my blog post on how to do this). However the screenshot tool does not trust this certificate and I would have to install my certificate inside the container. This is just way more comfortable and not really an security issue, because everything is running on premise.
Closing remarks
Well, that’s all. You have reached the end of my guide. I hope it was helpful and interesting to you. If you have any questions regarding anything of this, just drop me a comment or message me directly on Github or Reddit (@it-obey).
Hans
Interesting
Anonymous
Thank you for sharing this excellent write up of creating an e-ink smart home kiosk. I particularly enjoyed the architecture diagram.