Why is Home Assistant so monolithic in so many aspects? Why are default plugins part of the main distribution? There are thousands of plugins included with Home Assistant, and I would bet that any given user wouldn’t be using anywhere near 10% of them. This is why there are so many patch updates after the minor version update, cause somebody forgot to update some random plugin and that requires a full patch version release to fix. I know that plugins are loaded on-demand, so they are not running all the time, but they do significantly bloat installation size as well as updates size. Why not create a separate default plugin registry and then treat all plugins (official and unofficial) the same way and allow downloading them on demand? That might require splitting plugins into two parts, auto-discovery and plugin itself, so that auto-discoveries could be part of the main distribution, but it would still significantly shrink the size of the installation, allow for much more stable core updates, less overall bugs and faster bug fixes after minor version increase (especially if you provide a good interface for creating unit tests for stand-alone plugins).
Same (although very different) issue with front end. WebSockets are streaming updates for absolutely every single component that is registered with Home Assistant, even if you are on the dashboard that only displays one component. That’s why running home assistant front-end on older devices or IoT devices is so painful, they just run out of memory almost instantly and can’t handle such massive amount of information (especially with large installations). Why not allow subscriptions to one of just a few components at a time, to only get updates for those? And optimize front-end code to only subscribe to components on the currently viewing dashboard? Yes that might make switching between dashboards slower, but that can be fixed with cache fast strategy, or having much less often updates for other components in the background, that you could drop on slower devices as progressive enhancement.
Generally speaking (and maybe I’m wrong on this, since I don’t watch HA development closely), it looks like there were a lot of architectural decisions made a long time ago, when HA was small and had small userbase, and they are not questioned or changed now that HA is in very different place.
I had a pleasure to fully experience the bloat today while trying to read through the full changelog of the December release. I collected the following words which constitute 99% of the changelog:
tplink waterleak, Philips Hue, Husqvarna Automower, Smarty, lamarzocco, yale_smart_alarm, HomematicIP Cloud Wind and Rain Sensor, yalexs_ble, watttime, verisure, tomorrowio, recollect_waste, plaato, motioneye, flux_led, crownstone, suez_water, yeelight , Fritz, honeywell, Russound RIO, konnected, hyperion, vizio, onkyo, aemet, Reolink PTZ, emoncms, Habitica, Tesla Fleet, huawei-lte-api, Ecobee, lastfm, netatmo, Switcher Lights, NASweb, Bang & Olufsen, Nord Pool, Lektrico, Tuya CO2 Detector, UniFi Protect, NINA, LinkPlay, QNAP, eq3btsmart, Kostal Inverters, deebot-client, Switchbot, LCN, Weheat, Sky remote, Roborock, acaia, roomba, starline, aussie_broadband, motionblinds_ble, smlight, soundtouch, tolo, hydrawise, KNX, Sonos, Nest, Shelly, HomeConnect, Fitbit, Mill, Hejhome Fingerbot, dynalite, Sensibo, Twente Milieu, Amberelectric, Xiaomi Miio, Mastodon, Nexia, TouchlineSL, fibaro, tibber, HomeWizard Energy, Elgato, tedee, inexogy, ViCare, Autarco, solax, NextDNS, Trafikverket, Rainbird, fyta, Alexa, Stookwijzer, Mealie, Cambridge Audio, ecowitt, Garages Amsterdam, ista EcoTrand, Brother, Atlantic Water Heater, London Underground, Touchline, renault, Swiss public transport, samsungtvws, bimmer_connected, Spotify, PyMetEireann, denonavr, Plugwise, buienradar, PiHole, QBitTorrent
These were 30 minutes of absolutely wasted time. I guess not just me, but any individual user does not use 99% of these. And yet they are part of the “core”. No wonder that this:
- dictates frequent release cycles
- results in HA core container image to be 1.75 GB in size (most of which is not used)
- makes GitHub limit the number of shown items (impossible to scroll further down)
- takes a lot of human time to prepare huge monolithic releases
- certainly results in other issues (like build pipeline limits) that are not immediately visible
As you’ve said, why not treat all integrations like HACS (or something similar)? Integrations that are used by at least 20% of the user base (there are statistics for that on every integration’s doc page) could be considered to be included into the core.
I am pretty sure that the devs are well aware of this and certainly there are thoughts and conversations in place. It is just that it becomes more and more obvious that the current approach doesn’t scale and won’t scale further.