Smart Home Dashboard

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).

2 Comments

  1. Anonymous

    Thank you for sharing this excellent write up of creating an e-ink smart home kiosk. I particularly enjoyed the architecture diagram.

Leave a Reply

Your email address will not be published. Required fields are marked *