WTH - Why are brand icons a cloud dependency?

Archive Month of "What the heck?!" (2020)
1

The fact that the brand icons are hosted on a different server has a few issues:

  • It breaks offline use
  • It breaks due to heuristics in privacy-focussed add-ons such as Privacy Badger
  • It’s an external dependency
  • It enables the collection of anonymous usage statistics with no way to opt-out

I’d propose to either include all icons in each HA install or provide another frontend: option which allows the user to specify a custom icon server base URL.

Edit: Rephrased the issue since including all icons in the main HA install isn’t feasible in the long run.

2

Or preferably just download and store locally the ones used.

5 Likes
3

That seems to still have most of the listed issues.

4
  • It breaks offline use - Fixed
  • It breaks due to heuristics in privacy-focussed add-ons such as Privacy Badger - probably fixed. It seems to dislike the path “brands”.
  • It’s an external dependency - fixed
  • It enables the collection of anonymous usage statistics with no way to opt-out - still possible if you are that paranoid.

One out of three ain’t “most”.

5

The brands repo is almost 300 MB currently, and will only get significantly larger over time. Especially now that custom_component authors are putting stuff up there too.

That is (one of) the reasons they’re not included in the install.

1 Like
6

When an integration is installed, is its logo cached locally (for display in Configuration > Integrations) or is it always retrieved from the central repository?

7

@tom_l Okay, I am probably misunderstanding your proposal because I don’t see how “download” and “offline use” go along.

@SeanM It is a bit of a different WTH but I think it is quite odd that custom_component icons must go to the official repo, that kinda defeats the purpose of a custom component.

@123 It is in principle always retrieved, but with some caching (edit: the caching setup is documented).

8

Once they are downloaded you can use them offline. Same way you are required to connect after first install or for updates.

1 Like
9

It might make sense to proxy and cache them on the HA instance, but that seems like more writes to SD cards so I’m not sure how viable it is.

10

In that case, I’d say that the custom base_url would be the correct approach for this issue.

That eliminates the need for the cloud connectivity, without bloating the HA Install.

I’ve edited the original post to reflect that

1 Like
11

Those writes should be few compared to all the PyPI packages that are installed for each integration.

1 Like
12

I don’t use them currently, but in skimming the forum I came across this thread and was surprised to find that brand icons introduce a cloud dependency.

I’d say a good proportion of HA users came here to get away from proprietary systems which require users to depend on some vendor’s cloud services. Granted, this isn’t a vendor in the traditional sense, but the same principles apply.

I can’t imagine why the needed icons couldn’t be loaded once and stored locally.

5 Likes
13

Since there’s nothing really happening here and it does feel like my contributions aren’t overly welcomed on github either, I’m now using this custom dockerfile to build my home assistant container:

Disclaimer
If you decide to replicate this and experience issues, please do not complain to the devs etc etc.
This is unsupported. Your own risk. May break in the future. Whatever

FROM homeassistant/home-assistant:0.117.4
RUN apk add gzip
RUN for i in $(find /usr/local/lib/python3.8/site-packages/hass_frontend/ -iname "*.js.gz"); do zcat $i | sed 's/https:\/\/brands.home-assistant.io/\/local\/brands/g' > "$i.copy"; gzip "$i.copy"; mv "$i.copy.gz" "$i" ; done
RUN for i in $(find /usr/local/lib/python3.8/site-packages/hass_frontend/ -iname "*.js"); do cat $i | sed 's/https:\/\/brands.home-assistant.io/\/local\/brands/g' > "$i.copy"; mv "$i.copy" "$i" ; done

With this, the frontend fetches its icons from /local/brands/ which works very well.
I just added a brands folder to my config/www directory and filled it with the latest build of the brands icons repo

These can be generated by running

git clone https://github.com/home-assistant/brands
cd brands
./scripts/build.sh

and will appear in the build folder.

It would be even nicer if the dockerfile could take care of that, but since I’m mapping my config directory into the container, this may lead to issues.

Overall, I’m very sad that I’m repeatedly forced to work around things instead of fixing them at the root. Especially since this works amazingly well. It didn’t even require me to add a custom component which provides another HTTP Endpoint for the brand icons.

I do of course agree that it makes sense for some deployments (e.g. raspberry pis) to not bloat the docker image too much.
Not having the option to self-host it though… well

6 Likes