HA development with Docker

Development
1

Hi folks. New to HA.

I’m a software engineer and so first step after getting HA running was to fork the repo and run my own fork.

However-- I’m running HA with Docker on my RPi3 and the docs are only about developing on an OS with virtualenv and friends.

Did I miss the docs on developing with Docker? Happy to write some based on my findings.

I found https://github.com/home-assistant/hassio-builder, and am forging ahead with this command:

    docker run --rm --privileged \
            -v ~/.docker:/root/.docker \
            -v /run/docker.sock:/run/docker.sock:rw \
            -v $$(pwd):/data:ro \
            homeassistant/armv7-builder --armv7 -t /data

Is this the right way to go?

2

Home Assistant and Hassio are technically 2? different things. It gets very confising.

Home Assistant can run in a Python venv or Docker
Hassbian is a Home Assistant venv build with scripts and an OS image for Raspberry Pi
Hassio can mean a couple of things.

  • A Docker container Docker installation of Home Assistant & Supervisor that can use Docker container addons.
  • The above. + a custom HassOS Hypervisor in an installable image.

The “right” way depends on where your interests lie. Most of the developers hang out on the Discor chat server, i believe.

3

Thanks @anon34565116

I believe I fit in this category:

  • A Docker container Docker installation of Home Assistant & Supervisor that can use Docker container addons.

I am running the docker image homeassistant/raspberrypi3-homeassistant - if I can figure out how that is built, then I will be able to do the rest. It feels like this should be obvious :smiley:

4

I see a Dockerfile in the source repo here. There are 18 branches though.

5

Interesting post here. I wonder has this guy nailed the options https://www.awesome-ha.com/

6

If you are referring to the installation options. Hassio can either be installed with their own HassOS hypervisor image or directly on Linux. The are both mentioned in the same document but the CPU architecture options for installation are missing. They are buried on a Github page.

7

The confusion is abound. You only have to read the many posts to see that users don’t actually know what they have installed and can’t remember what installation instructions they have followed.

Maybe things will be come clearer in time. Who knows. Which one shall reign supreme :joy:

1 Like
8

Haha @ConcordGE. So true.

@anon34565116 I took your very sensible pointer and tried building a docker image direct from the home-assistant/home-assistant repo… And it made my RPi3 very sad :rofl: I had to power cycle to recover.

The docker build logs hang at 50% of compiling the openalpr project. My guess (from watching htop) is the Pi doesn’t have enough RAM and spends all it’s time swapping and not actually compiling.

Regardless… I’m not really sure why I want an Automatic License Plate Recognition library in my Home Assistant.

9

If you’ve something to offer the development Discord is probably the way to go as suggested by @anon34565116

10

I posted on there earlier and nobody bit. Maybe if I can get a dev build running then I might be able to open a pull request… And the devs will be my friend

11

For anyone arriving via Google… Actually reading the Dockerfile shows you can disable the compile of openalpr easily:

1 Like
12

You’re already on a roll. I can’t see why any of them wouldn’t be interested in what you have to offer.

1 Like
13

Here’s a flawed but mostly working solution:

  1. Clone your fork of https://github.com/home-assistant/home-assistant
  2. Copy your HA config into a subdirectory of the code called config
  3. Use the following docker run command to run the upstream docker image with the local code
docker run --rm -it -v $(pwd)/config:/config -v $(pwd):/usr/src/homeassistant homeassistant/raspberrypi3-homeassistant:0.94.3

However, one should really build a docker image from the local source tree and use that rather than the official 0.94.3 image. (Because the upstream image was built with an older version of the code…)

14

I hope the devs are reading your post :pray:

15

Out of curiosity: why do you want to take that extra step with Docker? If you set up a VM with the venv (like the dev-docs suggest), you can make changes and only have to restart the process to observe their effects. Rebuilding the Docker image with every code change seems to be way too much overhead, especially when hunting bugs. I’d only do that if I really hated myself. :laughing:
By that I don’t want to say that testing if your code keeps working inside Docker isn’t a good thing to do. But to me that’s more like the thing I would do after I got my code working in the venv.

Edit:
It would make sense though if what you mean is editing the sources within the image instead of rebuilding it again and again. Didn’t think of that before.

16

Fully agree. What you would normally do is mount the source into the docker container, so you don’t need to keep rebuilding over and over.

Given that I can’t even build once on my Rpi3 (probably something to do with those 2000 lines of requirements.txt), it’s not even an option!

17

Why develop on a Pi unless you are going to interface with GPIO?
IMO running Docker on a Pi adds unnecessary load to a low power system.