Dans la vie, il faut choisir ses combats et ses priorités, c’est tout.
Comme indiqué, le ratio emerdement vs gain est trop faible pour justifier cette énergie.
Toi tu fais ca du matin au soir, tu aimes les Lego, pas tout le monde.
J’aime la domotique mais j’ai pas envie d’en être esclave.
Respecte le choix des autres.
J’ai aucun problème avec ton choix, que tu veuilles passer ton temps à faire autre chose, c’est très bien Mais ça me dérange juste de laisser passer des choses qu’on pourrait prendre pour des vérités… Si certains veulent eux, apprendre ça serait dommage qu’ils n’en profitent pas
Bonjour,
Pour vous.
Et on le respecte. Il existe plusieurs solutions pour héberger jeedom chacune avec des avantages et inconvénients et une chose est certaine: il n’y a pas une solution qui est largement mieux que les autres, cela dépend du contexte.
Je vous dirais de faire de même 
Ps: pour jeedom je suis sous vm, je préfère.
Pour d’autres services sous docker donc je mange à tous les râteliers 
1 « J'aime »
Hello,
J’ai démarré Jeedom en l’utilisant avec Docker pendant 2 ans je dirais.
Je n’ai jamais eu de soucis. Enfin, j’ai dû à un moment faire une petite modification pour que cela continue de fonctionner (suite à un changement concernant l’installation des paquets il me semble). J’ai même fait un tuto pour indiquer comment utiliser les DNS Jeedom avec un Docker en mode host.
Les ressources utilisées n’ont effectivement rien à voir. C’est le jour et la nuit par rapport à une VM sur un NAS Synology.
Néanmoins, si on ne l’utilise pas avec les best pratices, d’un point de vue sécurité, ce n’est pas top (voir les articles évoquant la sécurité des conteneurs).
Ensuite, je rejoins @naboleo si ses différentes propos. Il résume bien la chose.
Bon, avec un NAS Syno pas super super performant et sans autre machine à disposition, Docker est une bonne alternative car cela fonctionne et consomme peu de ressources.
Néanmoins, je pense que si on a le choix (d’un point de vu matériel à disposition), le choix le plus judicieux pour Jeedom est la VM (par rapport à l’utilisation principale des conteneurs).
Sans compter que cela évite que l’équipe Jeedom se défile si vous avez un souci (ex : je ne pouvais joindre mon docker avec un nom d’hôte, uniquement via son IP… On m’a répondu que c’était parce que c’était Docker… Au final, c’était dû à l’IP v6 que j’ai dû désactiver sur la box).
J’ai également utiliser Docker car je voulais avoir tout sur le NAS et ne pas multiplier les machines.
Mais après recul, je pense que la fonction de NAS doit rester NAS.
J’ai d’ailleurs eu un autre souci : mon Docker Synology buguait… Je ne pouvais plus créer de conteneurs. Toutes les nouveaux conteneurs plantaient au démarrage. Le support Syno, qui rejetais la faute au paquet Docker a juste trouvé à me dire de désinstaller le paquet et d’en installer une ancienne pour voir.
J’ai finalement migré sur un Odroid-C4.
Mais encore une fois, Docker (que j’utilise toujours), suivant les besoins, c’est très bien.
D’ailleurs Home Assistant utilise des conteneurs pour fonctionner.
1 « J'aime »
Merci pour ce retour intéressant d’utilisateur Syno.
Pour ma part, j’ai voulu également utiliser VMM sur mon Synology.
Notamment à cause des images obsolètes ou du mode HOST obligatoire.
Mais quand j’ai vu les ressources utilisées par VMM 
,
Internet regorge de tuto Docker. Mais j’ai toujours l’impression que ce qui les rédige s’adressent à eux mêmes 
J’ai cherché, exploré, décortiqué comment configurer Docker avec notamment son réseau macvlan
Alors que je n’avais aucune compétence sur le sujet 
Du coup, je suis revenu avec Jeedom en Docker et mon CPU et ma RAM sont au vert
et si mes tuto peuvent aider à d’autres … 
1 « J'aime »
On est d’accord qu’avec le Syno (sauf si on a une superbe bête de courses), les ressources sont loin d’être infinies. Et là, Docker est à privilégier je pense.
J’ai une VM sur le Syno… Je l’allume juste le temps de mes tests.
Par contre, ce qui me gênait également à l’utilisation de Jeedom sur le NAS, c’est que ce dernier était tout le temps sollicité.
On entendait que les disques travaillaient. Au vu du prix des HDD Red, j’ai préféré séparer mon Jeedom du NAS.
Pour ma part, j’ai abandonné jeedom sur Synology en production. Je garde une VM pour les tests.
Au depart j’etais sous Chroot; avec la disparition du paquet, je me suis tourné vers docker.
La aussi, avec les restrictions synology, les mises à jours, cela peut devenir un probleme dans le temps.
On a pu constaté que si Jadhal arrête la diffusion des drivers USB, qu’est ce qui va se passer avec cette solution? DSM7…
Puis sous VMM sur syno, idem, ports USB qui plantent et reboot obligatoire du syno car les clés ne sont plus reconnues; limitation à 4 ports USB… Pas fiable tout cela même apres X années sur Jeedom embarqué sur syno.
Aujourd’hui, je fait tourner jeedom sur Odroid N2. Tous mes problèmes ont disparus. En cas de reboot du Nas pour mise à jours, la domotique reste en place.
A chacun son choix.
Stef.
1 « J'aime »
Je préfère la souplesse de la VM sur Syno.
Mon NAS me sert également de NVR pour mes 4 cameras, l’utiliser en plus pour faire ce traitement ne prends pas bcp de ressource.
Le fait d’avoir tout dans une même machine, d’éviter de consommer du courant en plus pour faire la même chose, me convient très bien.
J’ai jamais eu de plantage USB, pas de reboot obligatoire, je ne sais pas pk tu dis ca (j’ai 1an 1/2 de recul)
Jamais entendu parler de limitation USB par contre, c’est une légende ? ou elle existe réellement ?
Je suppose qu’elle s’applique sur RasbPI et Odroid N2 ?
Je dis ce que j’ai pu constater sur un ds716 et 718 et cela pendant 2 voir 3 ans… Qu’il arrive que le port USB est déconnecté de la VM et que même le nas ne la detecte plus. Le seul moyen un reboot complet du nas. Que cela soit branché en direct ou sur HUB USB alimenté.
Regarde dans les parametres de ta VM à combien tu es limité de ports. Tu peux ajouter que 4 ports. Si tu en veux plus, synology propose une licence.
Tout es la:
Licence Pro de Virtual Machine Manager | Synology Inc.
La limitation est liée a VMM et rien d’autre.
La consommation d’un odroid N2 (5w en charge) face a une domotique qui ne gère plus la maison, le calcul est vite fait!
Mon choix a été de quitter cette solution qui n’est pas stable chez moi. Si elle l’est chez toi, pas de problème. J’ai juste fait mon retour d’expérience.
Stef.
Bonjour a tous
Bonjour @Stef74 ! Savoyard ? 
Ou rien a voir le 74 ?
Pour ma part voici mon retour d’experience. Je suis en parallele coté pro dans le telco et le cloud, hosting, datacenter… Petite experience donc de la virtu ESX, vSphere and cie
J’utilise depuis 1 an VMM sur un syno DS918+ avec cash et ram supplémentaire. Je suis utilisateur de syno en perso + pro depuis plus de 10 ans.
J’ai 2 VM, jeedom + motioneye avec 3 cams a date.
Donc oui les VM ça consomme de la ressources mais c’est plutôt l’OS de la VM qui la consomme quand jeedom en a besoin ce qui induit forcément un peu de latence mais quasi invisible sur ma config. Il est certain que ces processeurs et configs de NAS ne sont pas idéales pour des VM encore que tout depend de l’utilisation qui est en faite. Comme son nom l’indique un NAS est plutot orienté stockage a la base. L’usage en a été un peu détourné et les possibilités décuplées en terme de fonctionnalités ces dernieres années.
Un NUC intel par exemple est bien plus performant qu’un NAS. Il suffit juste de lui mettre un hyperviseur pour se retrouver avec une belle config pour des VM (mais sans le systeme de stockage multi disques). Si on lui adjoint un stockage isci nas syno, on est vraiment bien…
Oui c’est sur qu’on gagne en ressource en docker car il n’y a pas d’OS mais tout depend des applocations. Ce sont directement les ressources hotes qui sont utilisées.
Perso j’utilise docker pour des toutes petites application web type bitwarden ou autre ou il n y a pas besoin de modif systeme permanente. C’est impec pour ce genre de truc et bien plus simple a gerer que d’utiliser le serveur web du syno tout a fait capable de gerer ça ou que de deployer une VM pour une toute petite application.
Pour le cas de jeedom, on ne peut pas dire que ca soit une toute petite appli bien que pure web. En effet on a de nombreuses taches de fond, des mises a jour de dependances touchant au fichier systeme régulièrement, des mises a jour régulières, des installations de plugin dependantes du systeme,… Ce qui m’oriente naturellement vers une VM pour jeedom beaucoup plus souple a gerer qu’un docker contrairement a une simple appli ou simple serveur web sans intelligence lourde.
Oui ca consomme plus de ressources en VMM mais quel gain de temps pournle coup pour les upgrades, les dependances,…
En revanche comme dit par @Stef74 j ai aussi parfois des déco des ports USB virtuels mais c’est rare et facile a gerer quand ca arrive. Chez moi pas besoin de redemarrer le NAS, juste la VM ou rebooter le hub.
L’USB n’est de toute façon pas un protocole industriel. Il est fragile à la virtualisation et au hub meme si on est d’accord que ca ne devrait pas etre le cas…
Maintenant si on a du temps pour bidouiller docker et refaire des MAJ pourquoi pas docker mais ca sera bien plus geek qu’une VM…
Pour ma part, la solution ideale mais qui n’existe pas : avoir un dongle ethernet zwave, zigbee, rfxcom et blea en ethernet direct. Dommage que personne n’y ait pensé a virer cet USB. Ca reglerait tous les problèmes.
2 « J'aime »
Salut, pas faux, avec un interface réseau à consommer, on s’emmerderait moins la vie avec l’USB
Bonjour,
Je découvre cette discussion qui m’intéresse beaucoup.
J’ai installé Jeedom en docker sur mon Syno en suivant un tuto il y a un peu plus d’un an maintenant (il n’y avait pas encore la V4 en docker à l’époque).
Il s’agit d’une installation en mode host pour avoir accès aux dongles USB, je ne sais pas vraiment ce que ça signifie, mais ça fonctionne très bien. Aucun soucis avec les dongles USB (Bluetooth UD100-G03, RFXplayer et MyHome), à l’exception parfois d’une mauvaise affectation des ports pour les 2 dernières en cas de redémarrage. Aucun pb pour le BT avec BLEA mais pour les 2 autres c’est aléatoire dirais-je, dès fois il faut aller remettre le bon port dans le plugin (je ne me suis pas penché dessus plus que ça pour l’instant, je ne redémarre quasiment jamais).
J’ai accès en https depuis l’extérieur avec le dns de mon Nas.
Aucun problème non plus pour les mises à jour des plugins et du core SAUF pour le passage en V4…
Et là, après lecture, je comprends qu’il serait préférable de passer sur une VM…
J’étais (et suis encore !) plutôt super content de cette installation en docker, et je n’y vois toujours aujourd’hui aucun inconvénient majeur mais j’appréhende la galère qui m’attends à mettre en place la VM et installer correctement tout ce qui faut dessus.
J’irais chercher un tuto pour me faire une idée plus précise et comment migrer, mais ça me rappelle la fois où j’ai bien galère pour faire une antenne BLEA sur un Orange Pi.
Je tenterai bien un docker en mode host en V4 non ? (je vais me faire lincher 
!)
C’était juste un partage d’expérience 
Hello.
C’est pas le mode host/bridge/macvlan qui determine le fait d’avoir accès ou non aux devices usb. La preuve ici il y a au moins 2 cas qui fonctionnent dont le tien. Le mode va déterminer le fonctionnement du réseau et sa visibilité/accessibilité par rapport au reste du monde :
- Host : host et container partagent une même ip unique
- Bridge = container à une ip dans son propre vlan et ne sait que passer par le host pour communiquer avec l’extérieur.
- macvlan = host et container disposent chacun d’une ip individuelle dans le vlan du host
Dans ton cas, passer sur une vm risque de consommer un peu plus de ressources. À ta place je ferai un nouveau container v4. Une fois fonctionnel, restauration backup, bascule des clés et arrêt de l’ancien.
Avec un docker-compose j’irai même jusqu’à ne changer que l’image, et garder le même container mais pas sûr que ce soit applicable au syno.
1 « J'aime »
Sans changer de container tu peux essayer de mettre à jour le container en téléchargent à nouveau l’image (si la v4 est la même ressource).
Par contre pour les depndances, je ne sais pas comment ca va fonctionner…
Backup bien avant sur ton NAS jeedom ailleurs que dans le container…
Pour ma part je ne comprends tjs pas comment les dependances du container peuvent être gérées proprement et persistantes pour jeedom.
Pour l’affectation des ports USB, même probleme avec des VM syno. Je pense que c’est plutôt un problème du syno lui même
C’est justement pour cela que Docker ne répond pas a l’architecture de Jeedom, alors certes ca « dépanne » mais c’est pas conforme a l’usage initiale de docker.
C’est comme un CD rom réinscriptible ! l’utiliser comme disque dur c’est un « concept » mais ca ne veut pas dire que ca ne fonctionne pas, jusque que ce n’est pas fait pour.
Oui je suis en phase avec toi !
Certains le font marcher, bien à priori, mais ça demande tout un tas de customisation du docker.
Pas fait pour ça à la base.
Mais qu’est ce que cela peut bien faire si c’est pas cf. à l’usage initiale de Docker.
Du moment que cela fonctionne parfaitement et que les ressources CPU et RAM sont au vert
C’est vrai que c’est pas forcément une priorité… mais si on peut faire en sorte de respecter les standards, c’est mieux 
Pour la facilité d’installation (aujourd’hui, faut bien avouer, installer une image docker jeedom c’est le chemin de croix), aussi pour maintenir plus facilement nos scripts Dockerfile / docker-compose & co, ça sera toujours plus simple si on a suivi les « normes » de développement Docker.
Moi perso je n’utilise jeedom sous docker que pour du test / développement, et sans plugin USB pour le moment, c’est le cas d’usage optimal. Je me suis fait une image perso sans la BDD pour commencer mais j’envisage d’aller plus loin dans la séparation des containers:
- 1 container BDD
- 1 container reverse proxy (nginx ou traffic)
- 1 container jeedom sans apache avec seulement le cron donc.
- 1 container mosquito MQTT pour les plugins compatibles
C’est déjà un bon début Ensuite il faudra séparer les « gros » plugins ceux avec cron ou démon dans leur propre container s’ils ne peuvent pas utiliser MQTT. Les plugins non invasif, sans cron ni démon sont intégré dans le container jeedom sans problème, faut pas non plus couper les cheveux en 4.
Bref, pour moi Docker actuellement je l’utilise juste à titre de développement.
2 « J'aime »
Là je ne comprend pas, un plugin a besoin de l’intégralité du core de jeedom pour tourner donc comment veux-tu mettre uniquement un plugin dans un container?