Installer Jeedom sur un Raspberry Pi, une Debian nue ou un hôte Proxmox, ce n’est pas seulement une affaire de scripts et de lignes de commande. Le choix de la plateforme conditionne directement la stabilité, la sécurité et la capacité d’évolution du serveur domotique.
Entre une box compacte sur Raspberry Pi avec SSD, une VM Debian bien tenue sur un mini-PC et une architecture virtualisée plus ambitieuse sous Proxmox, les compromis ne sont pas les mêmes. L’enjeu consiste à bâtir une base qui démarre tous les matins sans surprise, tout en restant assez souple pour accueillir demain du Zigbee, du Z-Wave, du Modbus ou un bridge vers Matter.
Sur le terrain, beaucoup d’installations Jeedom démarrent sur carte SD, puis migrent dans l’urgence après une corruption de système. L’idée de ce guide Jeedom est de faire l’inverse : partir directement sur une architecture propre, voire industrialisable, avec un SSD, une installation Debian à jour et, quand c’est pertinent, une couche de virtualisation Proxmox pour séparer les rôles.
Une maison connectée qui pilote des volets, du chauffage et une alarme mérite une approche proche de celle d’un petit serveur d’atelier, pas d’un gadget bricolé le dimanche soir.
En bref
- Raspberry Pi + SSD reste la combinaison la plus simple pour installer Jeedom à la maison, à condition de bannir les cartes SD pour la production.
- Installation Debian en VM ou sur mini-PC offre plus de marge CPU/RAM pour les gros scénarios, l’historisation poussée et les plugins gourmands.
- Proxmox permet de cloisonner Jeedom, la base de données, un broker MQTT et d’autres services domotiques, avec snapshots et sauvegardes centralisées.
- Le cœur du sujet reste toujours le même : mesurer la charge, sécuriser les accès, automatiser les sauvegardes et surveiller la santé du serveur domotique.
- Les choix matériels et logiciels doivent être cohérents avec les usages : une installation pour un appartement de 60 m² n’a pas les mêmes besoins qu’un site multi-bâtiments.
Installer Jeedom sur Raspberry Pi et SSD : base robuste pour un serveur domotique maison
Sur un projet domestique, associer Raspberry Pi et SSD pour installer Jeedom présente un bon équilibre entre coût, consommation et fiabilité. Le point clé n’est pas la puissance brute, mais la capacité de l’ensemble à encaisser des écritures régulières (logs, historiques, backups) sans rendre l’âme au bout de quelques mois.
Une carte SD finit presque toujours par lâcher. Un SSD mSATA ou SATA en USB 3 supporte bien mieux ces contraintes, même avec un usage 24/7.
La majorité des utilisateurs peuvent se contenter d’un Raspberry Pi 4 avec 2 Go de RAM. Au-delà, les gains restent limités pour un usage standard : quelques dizaines de plugins, une base d’historique raisonnable, des scénarios d’éclairage et de chauffage, un peu de Zigbee et de Z-Wave. Ce qui change réellement la donne, c’est le choix du boîtier et du refroidissement. Un boîtier passif bien conçu, avec dissipateurs sur CPU et contrôleur USB, réduit la température et donc les risques de throttling et de plantage en pleine vague de chaleur.
Pour l’installation Raspberry Pi, la méthode la plus propre consiste à graver directement Raspberry Pi OS Lite sur le SSD avec Raspberry Pi Imager. Le programme accepte une image personnalisée Debian 11 ou 12, ce qui permet de rester compatible avec le support officiel Jeedom tout en profitant d’un système minimal. En pratique, Debian 12 passe bien pour Jeedom, même si certains plugins tardent parfois à rattraper le retard. Mieux vaut le savoir avant de s’appuyer sur un module exotique non maintenu.
Raspberry Pi Imager propose désormais d’activer SSH et de définir un utilisateur dès la gravure. C’est utile, car l’accès SSH n’est plus activé d’office. En paramétrant dès cette étape le nom d’hôte, les identifiants et l’activation du service SSH, on évite le petit jeu du clavier/écran à brancher sur le Pi. Une fois le SSD raccordé au Raspberry Pi, le premier démarrage se fait alors directement dessus, sans carte microSD intermédiaire.
Un cas représentatif : une famille qui équipe un pavillon de périphériques Zigbee pour l’éclairage, de têtes thermostatiques et de quelques capteurs d’ouverture, en s’appuyant sur un serveur domotique Jeedom. Un Raspberry Pi 4B, un SSD mSATA de 250 Go et un boîtier avec refroidissement passif suffisent largement. Pour le réseau, une IP fixe attribuée depuis la box évite les mauvaises surprises avec les redirections de ports et les accès distants. Une fois l’installation stabilisée, la sauvegarde quotidienne exportée vers un NAS ou un cloud limite l’impact du moindre incident.
Cette combinaison reste la porte d’entrée la plus accessible pour installer Jeedom, mais les exigences montent vite dès que l’on empile les plugins, notamment pour du Zigbee avancé, des passerelles radio ou des systèmes multi-pièces. C’est à ce moment que les réglages finement dosés sur Debian et le noyau prennent tout leur sens.
Installation Debian et optimisation système pour une instance Jeedom durable
Que ce soit sur un Raspberry Pi ou sur un petit PC x86, l’installation Debian pose la fondation du futur serveur domotique. Les développeurs de Jeedom conseillent encore Debian 11, compatible et largement éprouvée. Debian 12 fonctionne tout aussi bien en pratique, à condition de vérifier plugin par plugin. Quand un plugin critique n’est pas testé sur cette version, installer Jeedom sur un environnement de test ou une VM jetable avant la bascule définitive évite les week-ends passés à rétrograder des paquets.
Après l’installation minimale, quelques réglages gagnent à être appliqués systématiquement. Une mise à jour complète par un simple sudo apt update && sudo apt full-upgrade -y permet de démarrer avec un noyau à jour et des correctifs de sécurité récents. Sur Raspberry Pi OS Lite, un passage dans raspi-config pour ajuster le fuseau horaire, le pays Wi-Fi et l’option d’extension de système de fichiers sécurise les bases. Un oubli de fuseau horaire paraît anodin, mais il fausse les historiques, les triggers de scénarios et les corrélations d’événements.
Sur les installations Jeedom avec beaucoup de logs et de plugins verbeux, le paramétrage du swap et de systemd-journald fait la différence. Passer le swap à 2 Go via /etc/dphys-swapfile donne de la marge lors des pics de charge, par exemple pendant une mise à jour globale de plugins. En parallèle, limiter la taille du journal système avec des directives comme SystemMaxUse=200M et MaxRetentionSec=1w réduit la pression sur le stockage. Sans cela, certains systèmes se retrouvent vite saturés par des logs inutiles.
Sur un Raspberry Pi dédié à la domotique, couper le Wi-Fi et le Bluetooth quand ils ne servent pas est loin d’être un luxe. Une simple modification du fichier /boot/firmware/config.txt avec les overlays dtoverlay=disable-wifi et dtoverlay=disable-bt diminue le bruit radio et les services inutiles. Moins de services actifs, c’est moins de surface d’attaque et un diagnostic plus simple si un jour une liaison Z-Wave ou Zigbee se comporte étrangement.
Une fois la couche système verrouillée, installer Jeedom revient à lancer le script officiel depuis le compte root. La séquence classique wget du script, chmod puis exécution installe le cœur, les dépendances PHP, le serveur web et la base de données. Sur une machine x86, le processus est rapide. Sur un Raspberry Pi, il peut prendre un peu plus de temps, mais le résultat reste similaire. Certains administrateurs préfèrent isoler MariaDB sur une autre machine ou un conteneur, mais pour un usage domestique standard, l’installation tout-en-un s’en sort très bien.
Une fois Jeedom démarré, l’accès via l’IP locale, puis via un DNS ou une URL de type freeboxos, permet de vérifier que tout tient la route. Un tableau de bord de santé tout vert, un accès administrateur sécurisé par un mot de passe robuste et une première sauvegarde stockée hors du serveur marquent une étape claire. Pour ceux qui souhaitent aller un cran plus loin dans la domotique, avec des équipements Xiaomi, du Zigbee varié ou des scénarios fins, une visite sur des ressources comme cette présentation de l’écosystème Xiaomi Zigbee donne des idées et des configurations reproductibles.
Cette démarche structurée sur Debian prépare le terrain pour deux suites possibles : un simple durcissement HTTPS et quelques optimisations, ou un déploiement plus ambitieux avec virtualisation et segmentation des services. C’est là que Proxmox entre en scène.
Déployer Jeedom sous Proxmox : virtualisation, snapshots et séparation des rôles
Utiliser Proxmox pour héberger Jeedom peut sembler excessif pour un appartement, mais devient très pertinent dès qu’un mini-serveur est déjà présent pour d’autres usages. Une fois l’hyperviseur en place, créer une VM Debian pour Jeedom ne coûte presque plus rien en temps, tout en permettant des snapshots avant chaque grosse mise à jour. En cas de problème de plugin ou de script, un rollback en quelques minutes remplace les longues restaurations manuelles.
Dans une maison équipée d’un mini-PC x86, certains choisissent une architecture où Proxmox héberge plusieurs VM : une Debian pour Jeedom, une autre pour un serveur de bases de données ou de graphes (InfluxDB, Grafana), et éventuellement un conteneur LXC pour un broker MQTT. Cette séparation des services simplifie les diagnostics et évite qu’un composant gourmand en ressources ne fasse chanceler tout le serveur domotique. C’est aussi un bon moyen de préparer un futur ajout d’autres plateformes comme Home Assistant ou Node-RED.
Créer la VM pour installer Jeedom dans Proxmox reste assez direct : Debian 11 ou 12, 2 ou 4 Go de RAM selon la charge prévue, un disque virtuel d’au moins 32 Go et une carte réseau bridgée sur le LAN. L’agent Proxmox peut être installé dans la VM pour remonter l’IP, gérer l’extinction propre et améliorer les sauvegardes. Les dongles USB (Z-Wave, Zigbee, EnOcean) sont ensuite passés à la VM via le passthrough USB, ce qui impose parfois des essais pour trouver le bon port ou un hub USB 2.0 stable.
Le point qui pose encore souvent question concerne la persistance des clés radio. Certains dongles Z-Wave Gen5 par exemple se comportent mal sur des ports USB 3 d’un hôte, alors qu’ils fonctionnent très bien une fois placés sur un petit hub USB 2. Un test simple consiste à démarrer la VM, vérifier si le périphérique apparaît dans /dev/tty* et, si ce n’est pas le cas, changer de port ou de hub avant de se lancer dans des reconfigurations inutiles.
Sur Proxmox, les fonctions de sauvegarde intégrée, de réplication et de stockage ZFS ou Ceph ne sont peut-être pas exploitées à fond dans un foyer, mais même une simple sauvegarde programmée de la VM Jeedom vers un disque externe donne un confort net. Avant une mise à jour majeure de Jeedom, un snapshot rapide sert de filet de sécurité. Les échecs de migration, qui se traduisent chez certains par des nuits blanches à restaurer des fichiers, se gèrent ici par quelques clics.
Proxmox ouvre aussi la porte à des architectures plus hybrides. Un exemple typique : une VM Jeedom pour la logique de scénarios, une VM dédiée aux traitements plus lourds (analyse de consommation, corrélation de données météo, reporting) et un conteneur pour des API. Ce découpage peut paraître sophistiqué, mais sur un mini-serveur en rack déjà présent pour d’autres usages (NAS, vidéosurveillance), il optimise l’existant. Dans ce contexte, Jeedom devient un élément d’un ensemble plus large, et non plus un service isolé sur un petit boîtier.
L’autre bénéfice de Proxmox tient au fait que l’on peut facilement tester une nouvelle version de Jeedom ou de Debian dans une VM clonée avant de migrer la production. Cette habitude, largement répandue dans l’IT, manque encore dans la domotique. Pourtant, elle évite nombre de déconvenues quand un plugin critique change de comportement ou qu’une nouvelle Debian modifie des chemins système.
Sécuriser, sauvegarder et maintenir Jeedom sur Raspberry Pi, Debian et Proxmox
Une fois Jeedom opérationnel, le vrai sujet démarre : la vie quotidienne du serveur domotique. Un système domotique qui contrôle des ouvrants, des alarmes ou du chauffage doit être considéré comme un mini-SI, pas comme un simple gadget. La stratégie de sauvegarde est le premier pilier. Sur Raspberry Pi comme sur Debian en VM, Jeedom propose nativement des backups compressés. Les exporter régulièrement vers un NAS, un stockage cloud ou une autre machine limite l’impact de tout incident matériel ou erreur de manipulation.
Mettre en place des sauvegardes hebdomadaires automatiques est un bon point de départ, mais certains environnements en méritent plus : par exemple un backup quotidien de la configuration Jeedom et un snapshot hebdomadaire de la VM si Proxmox est en jeu. Tester au moins une fois la restauration sur une installation parallèle rassure tout le monde. Une sauvegarde non testée est, en pratique, une sauvegarde douteuse.
Côté sécurité, trois actions ont un impact immédiat. D’abord, changer les identifiants par défaut admin/admin et imposer des mots de passe solides pour tous les comptes disposant d’un accès distant. Ensuite, forcer le HTTPS avec un certificat TLS, généré par Certbot par exemple, en s’appuyant sur un nom de domaine ou un sous-domaine fourni par la box Internet. Enfin, limiter au maximum l’exposition directe du port de Jeedom vers l’extérieur en préférant un VPN ou un reverse proxy avec filtrage.
Certains utilisateurs vont plus loin en ajoutant une authentification à double facteur sur les comptes critiques ou en restreignant les accès administrateur à certaines IP. D’autres préfèrent séparer physiquement les segments réseau : réseau domotique, réseau multimédia, réseau invité. L’important est de ne pas laisser un serveur domotique direct sur Internet sans filet, avec des identifiants faibles et des services inutiles actifs.
La surveillance de la santé du système mérite aussi un peu d’investissement. L’onglet « santé » de Jeedom donne une première vision : charge CPU, espace disque, état des plugins. Certains complètent avec des sondes externes ou des exports vers Grafana. Une fois la tendance connue (charge moyenne, pic en soirée, etc.), dimensionner les ressources devient plus factuel. Cela permet de décider sereinement s’il est temps de passer d’un Raspberry Pi à un mini-PC ou de séparer la base de données sur une autre machine.
Pour ceux qui veulent explorer d’autres briques open source compatibles Jeedom ou comparer avec d’autres approches, des ressources comme ce panorama de la domotique open source offrent un bon complément. L’idée n’est pas de changer de plateforme tous les six mois, mais de comprendre comment certaines communautés gèrent sécurité, mises à jour et intégration d’objets connectés variés.
La fréquence de mise à jour reste un sujet sensible. Mettre à jour Jeedom et ses plugins trop rarement expose à des failles corrigées depuis longtemps. Mettre à jour trop souvent, sans filet, augmente le risque de régression. La bonne pratique consiste à se fixer un rythme, par exemple mensuel, couplé à une sauvegarde systématique juste avant. En cas de problème, le retour arrière est alors une simple formalité.
Comparatif pratique : Raspberry Pi, Debian sur mini-PC ou Proxmox pour Jeedom
Entre Raspberry Pi, Debian sur machine dédiée et Jeedom sous Proxmox, les choix ne se font pas sur la seule base de la puissance. Ils dépendent de la taille du logement, du nombre d’objets connectés, du niveau de tolérance à la coupure et de l’appétence pour l’administration système. Pour clarifier les compromis, le tableau ci-dessous synthétise quelques scénarios typiques rencontrés chez des particuliers et des petites structures.
| Scénario | Plateforme recommandée | Points forts | Limites |
|---|---|---|---|
| Appartement avec 30 à 50 périphériques (Zigbee, Wi-Fi) | Raspberry Pi 4 + SSD | Coût faible, conso électrique minimale, installation simple | Moins de marge pour des traitements lourds, dépend d’un seul boîtier |
| Maison avec chauffage piloté, volets, alarme, 80 à 120 périphériques | Mini-PC x86 + Debian | Plus de CPU/RAM, SSD interne fiable, meilleure évolutivité | Installation un peu plus technique, consommation légèrement supérieure |
| Domicile équipé d’un serveur déjà présent (NAS, VM diverses) | Proxmox + VM Debian pour Jeedom | Snapshots, sauvegardes centralisées, isolation des services | Administration Proxmox à maîtriser, gestion des dongles USB |
| Petite entreprise avec locaux instrumentés (capteurs, accès, énergie) | Serveur rack + Proxmox + plusieurs VM | Haute disponibilité possible, segmentation fine des rôles | Compétences système nécessaires, budget matériel plus élevé |
Un point souvent oublié concerne la diversité des objets connectés. Plus l’écosystème est hétérogène (Zigbee, Z-Wave, Modbus, MQTT, Wi-Fi), plus l’architecture doit être pensée en conséquence. Un Logitech ou un kit Tydom ne se gèrent pas comme une simple ampoule Wi-Fi. D’ailleurs, des pages comme ces exemples d’objets connectés aident à cartographier le terrain avant de se lancer à l’aveugle.
Pour un Raspberry Pi, la vigilance se porte sur le stockage (SD bannie en production, SSD privilégié), la gestion thermique et le nombre de dongles USB. Au-delà de deux ou trois clés radio, la stabilité peut se dégrader si l’alimentation n’est pas dimensionnée ou si l’on cumule des hubs non alimentés. Sur un mini-PC, ces limites reculent, mais la discipline sur les sauvegardes reste tout aussi importante. Un PC qui héberge Jeedom, un serveur de fichiers et un hyperviseur léger sans plan de reprise ne vaut pas mieux qu’un Raspberry non sauvegardé.
Sur Proxmox, le risque principal tient moins au matériel qu’à une mauvaise gestion des ressources : trop de VM gourmandes, pas assez de RAM, pas de monitoring. Jeedom n’est pas très lourd, mais combiné à d’autres services, il peut déclencher un swap massif si la mémoire est mal allouée. Une règle prudente consiste à laisser une marge de 20 à 30 % de RAM libre sur l’hôte pour absorber les pics temporaires.
Certains lecteurs hésitent entre tout mettre sur un Raspberry Pi ou investir directement dans un mini-PC d’occasion. Pour un foyer qui prévoit dès le départ l’ajout de caméras, d’un enregistreur vidéo, de scénarios multi-pièces complexes et d’une collecte de données météo ou de consommation détaillée, le mini-PC ou Proxmox se justifient. Pour une domotique plus modeste centrée sur l’éclairage et quelques volets, le Pi reste très convenable, surtout avec SSD et Debian ajustée.
En domotique, l’essentiel n’est pas d’avoir la plateforme la plus puissante, mais celle qui correspond à la réalité des usages et que l’on saura maintenir dans la durée. Installer Jeedom sur Raspberry Pi, Debian ou Proxmox revient en fin de compte à choisir un outil, pas une religion. Le bon choix est celui qui garde la maison confortable, prévisible et mesurable, sans exiger des nuits blanches à chaque évolution.
Quelle version de Debian choisir pour installer Jeedom aujourd’hui ?
Pour une nouvelle installation Jeedom, Debian 11 reste la valeur sûre, particulièrement si des plugins historiques sont utilisés. Debian 12 fonctionne bien dans la plupart des cas, mais il est prudent de vérifier la compatibilité des plugins critiques avant de basculer en production, ou de tester sur une VM ou un Raspberry Pi de test.
Faut-il encore utiliser une carte SD pour Jeedom sur Raspberry Pi ?
Une carte SD peut suffire pour des tests et des maquettes, mais pour un serveur domotique en production, il est recommandé d’installer le système sur un SSD. Les écritures fréquentes de logs, d’historiques et de sauvegardes raccourcissent fortement la durée de vie d’une carte SD, alors qu’un SSD encaisse bien mieux ces cycles.
Proxmox est-il utile pour une petite installation domestique ?
Proxmox apporte un intérêt dès qu’un serveur tourne déjà en continu à la maison ou que l’on souhaite isoler Jeedom des autres services. Pour un simple appartement avec un Raspberry Pi dédié, Proxmox n’est pas indispensable. En revanche, pour un mini-serveur qui héberge plusieurs services, les snapshots, sauvegardes centralisées et VMs séparées deviennent rapidement très utiles.
Comment sécuriser l’accès distant à Jeedom ?
La bonne pratique consiste à activer le HTTPS avec un certificat TLS, puis à limiter au maximum l’exposition directe sur Internet. Un VPN ou un reverse proxy sécurisé offrent une protection supplémentaire. Les identifiants par défaut doivent être changés immédiatement, et il est recommandé d’utiliser des mots de passe robustes et, si possible, une double authentification pour les comptes administrateurs.
À quelle fréquence mettre à jour Jeedom et ses plugins ?
Un rythme de mise à jour mensuel, avec une sauvegarde systématique juste avant, constitue un bon compromis entre sécurité et stabilité. Mettre à jour trop rarement expose à des vulnérabilités non corrigées, alors qu’une mise à jour permanente sans plan de retour arrière augmente le risque de régressions. Avec Proxmox, un snapshot de la VM avant chaque gros changement simplifie beaucoup la gestion des incidents.