@Reno Je te répond à ton message ici !
Il faut que ce soit le plus clé en main possible, fonctionnant par défaut sans que l’utilisateur ait à comprendre ce qui se passe sous le capot.
Ce que je vois :
- Lorsque l’utilisateur veut configurer le service zigbee2mqtt (et uniquement à ce moment là), le service automatiquement lance les bons containers, sans que l’utilisateur n’ait quoi que ce soit à renseigner ni comprendre. Un onglet « avancés » peut permettre à l’utilisateur expérimenter de mettre les mains dans le cambouis si vraiment c’est utile. Si ce n’est pas utile, inutile de l’afficher. Une petite phrase d’explication sur ce qui se passe peut-être utile, sans non plus noyer le débutant.
- Attention à bien vérifier qu’il s’agit d’une installation sous Docker, sinon il faut fallback à la solution actuelle
- Tu peux utiliser la librarie dockerode qu’on utilise déjà dans Gladys 4
- Attention à ne pas interférer avec le service MQTT. A mon avis, vu le poids que ça pèse un container mqtt (ça pèse rien), il faudrait mieux lancer un container mqtt dédié à zigbee2mqtt, sinon tu risque de te heurter à des problèmes de flow dur à comprendre pour l’utilisateur (exemple: je lance zigbee2mqtt, puis je configure MQTT avec un MQTT externe pour utiliser Owntracks par exemple => zigbee2mqtt cassé??) Ce serait cool que ces deux services ne soient pas dépendant.
- Attention à bien supprimer le container zigbee2mqtt + mqtt si l’utilisateur ne veut plus utiliser le service
- Attention à bien gérer les différentes architectures: les images doivent être différente selon si l’utilisateur est sous un système ARM (Rasp) ou x86 (Synology, serveur maison, ou machine de développement)
Qu’en penses-tu ?