openHAB
openHAB est l’un des plus anciens projets de la domotique auto-hébergée, et ça se voit dans les deux sens. Il possède l’une des plus grandes bibliothèques d’intégrations parmi les hubs open source, et une courbe d’apprentissage plus raide que presque tout ce qu’on couvre sur ce site. Là où Home Assistant est une application Python pensée pour un démarrage rapide, openhab est un framework Java bâti sur OSGi, la même architecture de runtime modulaire utilisée dans les middlewares d’entreprise. C’est une vraie alternative à Home Assistant, pas une brique complémentaire comme Zigbee2MQTT ou Mosquitto, mais un hub complet qu’on choisit à la place d’un autre.
Ce qui distingue openHAB
Le dépôt principal d’openhab se décrit lui-même sans détour : « openHAB Core n’est pas un produit en soi, mais un framework pour construire des solutions par-dessus. » Ce framework est repris par la distribution openHAB, qui regroupe le runtime avec un ensemble d’add-ons par défaut pour donner quelque chose d’installable et d’exécutable directement. L’architecture est modulaire par conception. Les bindings (le terme d’openHAB pour les intégrations), les composants d’interface et les modules d’automatisation sont tous des bundles OSGi séparés, chargés dans le système en cours d’exécution, ce qui est puissant pour l’extensibilité mais ajoute une vraie charge conceptuelle par rapport au modèle d’intégration Python, plus monolithique, de Home Assistant.
Les bindings : l’écosystème d’intégrations
openHAB appelle ses intégrations des « bindings », et le catalogue est vaste : protocoles de hubs commerciaux, KNX et Modbus pour la domotique filaire, Zigbee et Z-Wave, lecteurs multimédia, services météo, et bien plus. Beaucoup de ces bindings précèdent leurs équivalents Home Assistant de plusieurs années, un effet direct de l’histoire plus longue d’openhab. Le revers de la médaille, c’est que la configuration d’un binding sous openHAB expose souvent plus de détails bruts du protocole que les intégrations de Home Assistant, ce qui est soit un atout soit une corvée selon le niveau de contrôle que vous recherchez.
Installer openHAB
L’image Docker officielle (openhab/openhab) est le chemin le plus portable, avec openHABian, une image d’installation pensée pour le Raspberry Pi, comme alternative plus guidée si vous tournez sur un Pi et préférez éviter de gérer Docker vous-même. Dans les deux cas, la configuration au premier lancement demande de choisir une interface (l’ancienne Basic UI, la nouvelle Main UI, ou les deux) et guide l’installation des bindings depuis le magasin d’add-ons intégré. Il n’existe pas d’équivalent à l’assistant d’accueil unique de Home Assistant qui détecte automatiquement les appareils sur votre réseau.
Accès distant : myopenHAB.org
Contrairement à Home Assistant, qui repose sur un abonnement payant Nabu Casa Home Assistant Cloud ou sur un reverse proxy configuré à la main pour un accès distant sécurisé, openhab propose depuis longtemps myopenHAB.org, un service relais gratuit et géré par la communauté qui permet d’atteindre votre instance locale depuis l’extérieur de votre réseau sans redirection de port. Ça ne rivalisera pas avec un VPN dédié ou un reverse proxy en performance, mais c’est une vraie différence dans la façon dont les deux projets abordent le même problème.
Pourquoi on le classe en Avancé, pas en Moyen
Trois choses poussent openHAB vers la difficulté Avancé plutôt que Moyen sur ce site. Le modèle en bundles OSGi fait que dépanner un add-on cassé implique souvent de comprendre quel bundle n’a pas réussi à se résoudre, pas juste de lire un message d’erreur classique. L’ancien moteur de règles utilisait un DSL proche du Java ; openhab a depuis ajouté un créateur de règles en interface graphique plus du scripting JavaScript et Python, ce qui réduit cet écart sans complètement l’effacer. Et l’empreinte en ressources est nettement plus lourde que celle de Home Assistant sur un matériel équivalent, puisque vous faites tourner une machine virtuelle Java complète et un conteneur OSGi plutôt qu’un simple processus Python. Rien de tout ça ne fait d’openHAB un mauvais choix. Ça en fait un choix réfléchi, généralement fait par des gens qui connaissent déjà les limites de Home Assistant et qui viennent de les atteindre.
openHAB face à Home Assistant et Domoticz
C’est l’une des comparaisons les plus fréquentes en domotique auto-hébergée, et il n’y a pas de réponse universellement correcte. Home Assistant gagne sur la rapidité de mise en place, le nombre d’intégrations et les applications mobiles natives. openhab gagne sur la profondeur des bindings au niveau protocole et la stabilité de l’API sur le long terme. Le projet a la réputation de ne pas casser la rétrocompatibilité aussi agressivement que le rythme de sorties rapide de Home Assistant le fait parfois. Domoticz, une troisième option plus légère, échange la profondeur des deux plateformes contre une empreinte réduite et une interface plus simple, et revient souvent dans les mêmes recherches sans être un concurrent sérieux pour la plupart des nouvelles installations auto-hébergées aujourd’hui.
Licence
openHAB Core est publié sous licence Eclipse Public License 2.0 (EPL-2.0), confirmée directement dans le fichier LICENSE du dépôt GitHub openhab/openhab-core. C’est la même famille de licence que Mosquitto, bon à savoir si vous auditez les licences d’une pile combinant les deux. L’EPL-2.0 est une licence à copyleft faible, moins restrictive que la GPL mais avec plus de conditions que MIT ou Apache-2.0.
Si vous hésitez entre openHAB et Home Assistant comme hub, ou si vous vous demandez où un outil comme Node-RED trouve sa place à côté de l’un ou l’autre, notre décryptage de la pile domotique auto-hébergée répond aux deux questions.
- Documentation officielle : openhab.org/docs
- Code source : github.com/openhab/openhab-core