Zigbee2mqtt: Add support for hassio addon

[ciotlosm]

I think this addon is great and deserves to be integrated into homeassistant easier by becoming a hassio addon.

I'm willing to help (first time doing addons) but instead of trying to copy your repo and hack it to make it work, I thought it's best to ask :)

I have already tried to make it a local addon by reusing some of the work you've been doing but so far haven't succeeded.

Things I've noticed so far:

1. Your Dockerfile uses ADD . which adds a lot more files than required inside docker. I think would be best to create a new folder with just the required files (data, lib and the js in root) and name it app or so, to avoid the moving of files around
2. You should use COPY from outside for start.sh instead of RUN cp inside, looks cleaner

Doing an addon with your config should be fairly straight forward by using a config similar to:

{
    "name": "zigbee2mqtt",
    "version": "1",
    "slug": "zigbee2mqtt",
    "description": "zigbee2mqtt addon",
    "url": "https://github.com/Koenkk/zigbee2mqtt",
    "startup": "before",
    "boot": "auto",
    "devices": ["/dev/ttyACM0:/dev/ttyACM0:rwm"],
    "options": {
      "mqtt_host": "mqtt://localhost"
    },
    "schema": {
      "mqtt_host": "str"
    }
  }

Note: I will keep trying to start it as local addon to see if I encounter other blockers.

Examples of addon repos: https://github.com/hassio-addons/addon-homebridge

[Koenkk]

1. This can indeed be improved.
2. The /app/data is overwritten by a volume during run time, therefore the default configuration.yaml needs to be copied so that there is always a configuration.yaml

[ciotlosm]

Is it possible to split the repo into multiple smaller ones? That way ADD could be used from remote repo.
Also that way you don't run into "relative path" problem for Dockerfile when adding files inside.

I understood now the problem with configuration.yaml, but I think there is a better way around it. Some alternatives:

• For "production" you don't need to modify the configuration once it's packed, just make sure the build system corrects it before it get packed
• For "development" you could have the complete app folder as a volume, and avoid ADD or COPY of stuff inside

This would help with the home assistant addon.

I will try tonight to build an armhf container with the code that I can start with docker on resinos. I If you get the separation done we can merge the two and get you an addon repo with automatic build, just like you have for your current docker containers.

[Koenkk]

First I want to get clear how the configuration.yaml will be edited when running as a hass.io addon. Can this directly be edited from the home assistant UI?

[Koenkk]

And why do we need another armhf container? Can't the current koenkk/zigbee2mqtt:armv7hf run on hass.io?

[ciotlosm]

Well, the current armv7hf doesn't build inside hassio on resinos. It throws errors on build. I tested it using "local addon" development.

The yaml file can't be edited directly in hass.io (you can using configurator addon for yaml, but not recommended), but there is a different route for addons.

In hass.io you get config.json that also has options and a schema on how to validate options. This then on runtime (as you want to be able to shift settings on each restart of addon) can be pushed inside configration.yaml, or you could switch to environment variables.

[Koenkk]

config.js to configuration.yaml seems to be a better option. In this way we can also support setting friendly_names/retain options for devices. https://developers.home-assistant.io/docs/en/hassio_addon_config.html#options-schema.

It seems that hass uses alpine as a base image, perhaps it would be nicer to switch all zigbee2mqtt images to alpine. Things will only get more complicated if more docker image variants have to be supported.

[ciotlosm]

That's not actually the accurate way Hass.io works. I'm far from an expert but I think the way it works is:

You have your Dockerfile, config.json and other files relevant in your "addon" repo.

1. At install time, the container is downloaded (if not built) and the config.json file copied in a versioned location
2. At start time, the input from the interface (defaults to config.json data) is being written to options.json file

So every time you change something in the interface, that is being loaded and saved back to options.json whish is based on config.json default + schema.

Usually addons in their run.sh which is their entry point use jq to parse options.json and populate either environment variables or other files that the container will use.

The container will automatically use /data as volume so you can load and save files there. I think options.json also sits in /data

[ciotlosm]

Hass.io uses resinos as base at the moment but I know pvizeli is building a brand new one from scratch using buildroot. I think it's best just to check what is the source of the core addons and use that in the same way. It might be that they actually use alpine, as that has a very low footprint.

[Koenkk]

I've setup an initial repository which should be able to run zigbee2mqtt as a hassio addon: https://github.com/Koenkk/zigbee2mqtt-hassio-addon

[ciotlosm]

I will try it tonight and get back with feedback. I will do merge requests to that repo with features once I get it working.

[danielwelch]

I've been following this great project tangentially and saw this issue yesterday, so decided to start on an add-on for Hass.io. I've started a repo here. I hope to have it building locally today. I see you've started one as well, so feel free to use anything from here in that repo of course. Just thought I'd post it here.

First I want to get clear how the configuration.yaml will be edited when running as a hass.io addon. Can this directly be edited from the home assistant UI?

My approach to this was to expose the options from configuration.yaml in the Hass.io frontend to the user via config.json, and use a short python script to write these values to configuration.yaml, keeping it in its place. If changes are made, the add-on needs to be restarted and the changes will be reflected in that file.

[ciotlosm]

@danielwelch I've also started to modify that repo based on tests here: https://github.com/Koenkk/zigbee2mqtt-hassio-addon/pull/1 and added a few comments on what is missing. Happy to merge with yours. Going to check how far along yours is.

[Koenkk]

If you want, I can give you both access to the repo.

[danielwelch]

@ciotlosm sounds good. Looking through your PR, it looks like there's a few issues that my version handles (mqtt_host; exposing permit_join) and others that still need work (data persistence, for which we could mount the /share dir; the zigbee-shepherd bug you mention). I haven't ever run into the "latest" version bug you're mentioning with my distribution/versioning approach.

I was wondering the same thing about devices in config.json. I can make this configurable at the level of zigbee2mqtt's configuration.yaml file, but not sure how to approach this in config.json.

[ciotlosm]

@danielwelch we can close this issue, and I can close my PR and we can work on your repo until it's a more stable version. Happy to test with devices and document things as you seem to be far ahead on knowledge on addons 🥇

For people reading this issue, go to https://github.com/danielwelch/hassio-zigbee2mqtt

@Koenkk I think it's ok if we use @danielwelch repo for now until we have a usable version.

[danielwelch]

@ciotlosm Sounds good. If you'd like to get started with building locally, you can clone the repo and move the zigbee2mqtt subdirectory into your Hass.io /addons directory. Just be sure to remove the image line from config.json to ensure the addon builds locally when you install it. No promises that it builds just yet, as I haven't been home to test it on my instance today.

[ciotlosm]

@danielwelch we can always use the work that @Koenkk
did here: https://github.com/Koenkk/zigbee2mqtt/tree/dev/docker

With his repo and my modifications from the PR I was able to build remotely with the issues that were mentioned on the PR. I think should be easy to start it. I will give it a go and come back with issues on your repo. I've already documented what you mentioned above in issues so we have them on the radar.