Hello, j’ai l’occasion d’installer un Jeedom de test sur un rpi4B et avant de me lancer je voudrais avoir votre avis sur certaines interrogations :
j’utilise sur mon atlas de prod des modules connectés en ZigBee, zwave, Ethernet et en bluetooth. Je suppose donc que pour être parfaitement représentatif de ma prod, mon Jeedom de test devrait aussi avoir des capacités dans ces 4 techno, notamment des contrôleurs ZigBee et zwave, pour pouvoir faire tourner leurs plugins correspondants ?
cela signifie donc avoir aussi des modules dédiés aux tests puisqu’ils ne peuvent être reliés qu’à un seul Jeedom ?
je suppose que je peux aussi faire l’impasse sur les deux points précédents, mais je n’éliminerai donc pas des bugs possibles liés à ces plugins/modules et/ou leur compatibilité avec le reste ?
est-ce que le fait d’avoir 2 machines différentes pour faire tourner jeedom (atlas vs. rpi) peut aussi causer un problème, par rapport à la restauration des sauvegardes quand je veux appliquer ma prod sur ma test ?
j’ai déjà lu qu’il était déconseillé de faire tourner autre chose que jeedom sur une machine, mais j’aimerais quand-même vachement pouvoir utiliser mon rpi pour autre chose, surtout que par définition une machine de test ne tourne pas en permanence. Est-ce envisageable techniquement ?
En fait tout dépend ce que tu veux tester au final.
Si tu veux avoir une « vraie » test, alors oui tu dois avoir tout en double, un controleur zwave de test avec des modules de test …
Bref rarement à la portée de toutes les bourses et dans les faits rarement utile.
Tu peux te dire que tu veux te contenter de la partie « gestion des scénarios et des automatisations » en test et ne pas avoir de test pour les équipements physiques ou les couches basses.
Tout dépend où tu veux positionner le curseur.
Cf ma réponse précédente : si tu veux que ce soit du « vrai » test oui.
Après il me semble que depuis que beaucoup de plugins sont passés sur MQTT, tu peux abonner ton jeedom de test à ton jeedom de prod histoire de ne pas avoir à gérer l’aspect périphériques.
Normalement non, après il faut faire attention qu’ells aient bien 2 noms distincts et 2 clés d’install distinctes pour qu’elles soient bien identifiées comme 2 machines distinctes.
Techniquement oui ça marche, c’est juste que jeedom peut « s’imposer » et casser autre chose qui tournerait sur ta machine. Par exemple une installation de dépendances ou de fichiers de conf d’Apache pourraient se faire directement et impacter autre chose qui est présent sur la machine.
En bref et un peu caricatural : il ne faut juste pas venir pleurnicher si jamais après une maj de jeedom un script custom dans un coin ne marche plus
Merci pour cette réponse détaillée, c’est bien la logique que j’avais en tête, plus ma test sera identique à la prod plus ce sera utile. Je pense surtout m’en servir avant les grosses migrations, par exemple j’ai testé debian 12 sur mon atlas et ça plante. Les tests sur scenario/automatisation cele serait du bonus, et c’est pas forcément là que je galère. @lperenna tu parles d’installer une vm sur le rpi ? J’y connais rien mais j’avais cru comprendre que c’était effectivement le plus robuste pour séparer les systèmes.
Une vm tu peux en faire une avec virtuabox sur un PC, ou avoir une machine dédiée, installer proxmox et y faire tourner plusieurs VM, bref il y a plusieurs possibilités.
En gros ce que veux te dire @lperenna c’est que si c’est pour faire du test ponctuel (donc pas laisser la machine allumée 24h/24) tu pourrais avoir une VM de jeedom sur ton propre PC.
Je ne sais pas si on peut installer promox ou virtualbox sur un rpi… Mais docker oui de là, tu peux tout à fait installer Jeedom dans un container docker, puis tes autres services dans des containers séparés et isolés. C’est très stable j’ai même eu mon jeedom de prod pendant un temps avant d’avoir une luna.
Il y a une réponse toute simple, les Raspberry Pi savent fonctionner sur des cartes MicroSD ou même des clés USB, SSD…
Il est donc tout a fait possible et simple, de basculer d’une carte MicroSD à une autre pour tester tel ou tel projet différent de Jeedom.
Je confirme que ma prod tourne sur docker depuis le début, sur mon NAS synology.
C’est ultra stable et nécessite un peu moins de ressource qu’une VM, et n’apporte aucune limitation (à ma connaissance)
Info : contrairement au Z-Wave, en Zigbee toutes les informations du réseau sont contenus dans le plugin.
Donc si tu restaures une sauvegarde sur ta box de test et que tu déplaces la clef / contrôleur de ta box vers celle de test,
ou si tu as 2 clefs (identique → c’est certain, différentes → je ne sais pas quelles différences sont tolérées ou non) + en arrêtant la box principale ou seulement le plugin sur cette dernière => tu te retrouves avec tout ton réseau zigbee sur ta box de test.
Avis perso : quand il y a des grosses mise à jour de MQTT, d’un firmware d’une clef, du core Jeedom, je trouve pratique d’avoir une box de test qui est la plus représentative de la principale : mêmes contrôleurs / plugin / quelque scénarios.
Pour ne pas avoir un truc en double chez toi, tu peux aussi avoir un autre système bien plus simple (avec quelques appareils seulement) pour un autre usage que ton principal et sur lequel tu aurais un problème de distance.
Exemple : abris jardin, garage, portail → cela fait qu’en cas de panne seul un mini bout est en carafe et non toute la maison.
Perso j’ai fais cela dans mon conteneur et… chez ma sœur (qui se fiche totalement d’avoir une alarme ou lumières automatiques, un temps inopérant. Son point de vue étant « si tu t’en occupait pas de toute façon je n’aurais rien, tout le temps… »)
Ps : sauf si tu as déjà ton Pi, pour faire moins onéreux, il y a parfois des SmartBox sur LBC, comme celle-ci à 70, mais ça doit pouvoir se négocier…
Prendre une EMMC neuve et ça suffira amplement https://www.leboncoin.fr/ad/ordinateurs/3129434869
Merci à tous pour vos réponses !
J’ai regardé un peu docker et même si ça a l’air super je pense que c’est un peu trop velu pour moi pour démarrer. Mais je le garde en tête pour plus tard quand je me serai fait la main. L’idée de changer de carte sd me paraît plus à portée de main même si ça veut dire que les systèmes tournent pas en même temps. Je m’autorise la possibilité de mettre en pause le premier système quand je veux faire des tests sur Jeedom par exemple.
Pour le moment j’ai pour idée d’installer un pihole et/ou un serveur multimédia type Plex, donc rien qui n’est critique si il est out quelques temps.
Côté ZigBee malheureusement la clé est intégrée à l’Atlas donc je ne pense pas pouvoir avoir exactement la même sur mon rpi.
, je veux rester sur mon rpi moi