System integration manifest

[pvizeli]

Motivation

Hass.io is a system they set up anything automated for users. So user can use anything and the setup is done by Hass.io

With split out integration from Core (I like that and it's the correct movement), all system like Hass.io and Docker have now a problem. Otherwise, we have now the possibility to solve #103

Issue

We have now the problem, that we can't ship all integration on an image. If we ship the image with all built tools (and that is also not possible, because we don't know all the requirements to build all the library), the image grows intensive and we end up in a bigger issue as #103 have now. We don't ship the built tools anymore with Hass.io because they are bigger as all integration at once. Also, some library takes hours to build it on a RPi.

Solution 1

We integrate Mozilla IoT protocol, Things. They faced all issue like this because of every component setup anythings self, as own program or i.e. as a docker container.

Solution 2

We create from all library wheels. We can also provide a ready to use system with CI that custom components can build the needed wheels. The problem is, not all can ship with a wheel. We need some times also install an additional system apk/tools. That ends up that we need 2 sources: wheels and apk/pkg.

We work currently and an auto-build system for alpine wheels to take down the builds for nearly real-time releases. This system is also a test to look at how we can move things out and later in. But it reflects now how a manifest need seems like that a system like Hass.io can install the component.

Manifest

Above is an example of manifest options that are the minimum.

draft:

{
   "alpine_wheels": "url/default: wheels.hass.io",
   "alpine_repository": "url",
   "alpine_apks": ["package"]
   ...
}

Interface Portable

The setup of a component will be more complex because Home Assistant needs setup all requirements. For wheels, it's a simple addition to pip install argument. For APK it need face to system.

There is none real Hass.io specific stuff but on a system, with windows or osx it could not working and end up in manual instruction what need setup. I don't like that because it's not portable and the question is, what should be done with a Home Assistant and what is the problem of an integrator.

Interface Specific

The system they run Home Assistant (i.e., Hass.io / Hasbian) need to set up a supervisor they have an interface where can set up the system specific stuff for Home Assistant. On start, Home Assistant can call that interface to become things setup.

Comments

We have 2 Solution.

Solution 1, with Things integration, is not realistic because we don't have the time to add this because we should focus us to Home Assistant userfriendly facing.

Solution 2, offload the problem over an interface to the system or Home Assistant need to learn how they can set up things on the local Operator system.

I think a soft migration is possible, but a backend like this need grow with the core system. In fact of that, we need to start soon to implement a solution that it can grow with core requirements. Maybe we should group the manifest options above inside Hass.io group and allow integrators to handle single components on Hass.io or not.

Udev

I think a manifest need also allows to add USB device ID and that allows Home Assistant to discovery the correct component they can handle such device.

Hass.io

The manifest should allow the define an add-on that is required to run such a component.

[awarecan]

I am assuming all discussion is base on #202

I would like to see a Core Docker Image, a Core + Essential, a Core + Essential + Popular, a Full image, and a Full + Extra image.

User can select one base on their usage. User can install/upgrade integration to any location user choose to, such as config folder or other mountable media.

Each integration can declare which image it should be included in.

Definition of each image

• Core: HA core, the minimal bootable HA
• Essential: All built-in entity components, such as light, switch, some Basic Integration, such as frontend, http, mqtt, zha, zwave, etc
• Popular: Some popular brand, such as Hue, Nest, etc
• Full: Almost everything
• Extra: Some integration needs extra setup.

[DubhAd]

@awarecan What would the purpose of Core be? I can see that many people would download it, and then be annoyed that almost nothing worked.

[awarecan]

Core will have separate release cycle.

[balloob]

So let's keep this issue on topic, which is how do we get integrations installable in Docker, without shipping the build tools. We can open a new topic for different docker images.

I think solution 2 is the best approach, and I think that it should be a system specific key, which we just allow any validation, that way other host types can add different support too (think hassbian, docker). So we can have a host: { hassio: {} } section in manifest.json. alpine_repository should also be a list.

{
  // …
  "host": {
    "hassio": {
      "wheel_server": string,
      "alpine_repository": string[],
      "alpine_apk": string[],
    }
  }
  // …
}