Je viens d’ugrader ma machine de test (màj via le backup de l’exploit’.
En farfouillant je me suis aperçu que le tag #IP# AINSI que l’onglet réseau du paramétrage donnait l’adresse de la machine d’exploit et non celle de la machine de test (même réseau).
Chaque machine à un « Nom de votre Jeedom » différent.
Par acquis de conscience j’ai laissé brancher, mais au bout d’une journée c’est toujours pareil.
Sur le market, dans « mes box », je ne vois que l’exploit’.
Je me suis rapidement bricolé un outils pour récupérer l’IP via l’OS, car lui connait la bonne
Je suppose que le backup à « embarqué », l’IP de la machine d’origine mais je ne vois ni comment ni où
EDIT 1 : Dans la foulée, comment procédez vous avec vos machine de tests ? Backup de l’exploit’ ?
Hello
Il faut aussi relancer la recherche des mises à jour après le chargement de la clé d’installation (pas api) C’est ça qui déclenche la synchronisation des données
La je viens de cloner totalement ma machine d’exploit’ (via ovf) pour être sur d’avoir une plateforme à jour, mai on peut voir sur ce printscreen :
Que jeedom connait bien la véritable IP physique 192.168.2.19 MAIS à aussi une adresse qu’il précise comme pas fiable (via le bandeau d’explication) qui est 132.168.2.196 qui correspond à la machine d’origine.
Jusque là c’est ok, peut être du à des contraintes market qui sont sans conséquence.
Le VRAI problème est que le tag #IP# ne POINTE PAS sur l’adresse REELLE DANS CE CAS LA mais sur l’adresse fantome de l’adresse d’origine.
Je te laisse imaginer les conséquences éventuelles dans un programmes qui donnerais cette adresse de réponse erronée …
C’est d’ailleurs comme ça que je m’en suis aperçu, j’ai une condition de lancement qui est « si IP machine != IP exploitation » alors …
Et j’en arrive comme ça tout doucement à une question subsidiaire :
Quelqu’un connait il une fonction core pour DESACTIVER et ou ACTIVER les plugins (stopper les daemon, je sais) mais pour désactiver un plugin j’ai eu beau chercher (mal) je n’ai pas trouvé
L’adresse que tu indique en face de http c’est une donnée que TU fournis à jeedom, au même titre que le nom de domaine juste en dessous… Jeedom n’a pas la prétention de te dire si c’est bon ou pas… La valeur est peut-être remplie la première fois sous certaines conditions (à confirmer)
Quant à la liste des interfaces réseau tout en bas, là c’est effectivement l’extraction des données système (donc c’est meilleur) mais il peut y avoir plusieurs cartes réseau et donc autant d’adresses associées. Pareil là jeedom n’est pas en mesure de trouver tout seul la bonne.
C’est pas un problème. C’est de la configuration non dynamique. Donc à toi de corriger.
Par ailleurs non seulement on change pas d’ip de sa vm tous les jours et en plus des plugins comme scan-ip permettent de surveiller ce genre de trucs
Pour répondre au problème d’adresse dynamique, heureusement jeedom sait résoudre le problème, il est facile de trouver l’interface réseau / IP utilisées REELLEMENT, c’est un vieux problème qu’on eu quelques plugins et auquel j’ai répondu sur l’ancien forum il y a longtemps. J’utilise d’ailleurs de nouveau ce procédé depuis que je me suis aperçu que le tag #IP# pouvait ne pas être fiable.
Donc Jeedom connait EVIDEMMENT la véritable adresse (d’ailleurs le dans du market lui est différent sur les deux machines.
Je réitère donc ma question, pourquoi le #IP# ne la fournis pas, je pense que cela demanderais à contrôler la chose sans remettre en question jeedom !!!
De manière générale, comment fais tu toi même pour avoir des machines de tests en image de l’exploit’ (ou autres) sans te prendre la tête à chaque mise à jour ??? C’est le problème sur lequel je suis actuellement d’où ma demande aussi d’une fonction core pour désactiver les plugins (rien de pire que deux machines qui envoi des ordres contradictoire à broadlink ou un plugin wifi ou netatmo )
PS : tu pourras essayer çes quelques lignes (pas du tout optimisée mais qui doivent fonctionner :
$tagIP = mg::getTag('#IP#');
preg_match ("#^(([\d]{1,4}.){3}..).{1,4}$#sU", $tagIP, $match);
$masqueIP = $match[1];
$requete = shell_exec("ip -4 -o addr show | grep '$masqueIP'");
preg_match ("#\d+:\s+([a-z]+[0-9]+)\s.+#sU", $requete, $matche);
$interfaceReseau = $matche[1];
$result = shell_exec("ip addr show $interfaceReseau");
preg_match ("#$interfaceReseau.*inet.(([0-9]{1,3}.){4})\/#sU", $result, $match);
$IP = $match[1];
mg::message('', "************* IP REELLE : $IP vs TAG IP : $tagIP");
En fait, je pense que c’est pas la meilleure solution de passer par l’ip pour essayer d’identifier les machines (et j’ai pas de solution idéale en plus):
l’ip est en partie dépendante de l’infra réseau (changement box wifi par exemple)
la mac, c’est pas plus facile => avec une VM, une mac ça se change aussi
la clé d’installation jeedom est contenu dans le backup (c’est ma préférence)
Une partie de la question, c’est de savoir s’il faut rafraichir ou non la valeur de #IP#, à mon avis, c’est pas nécessaire, si on a besoin de connaitre l’adresse réelle autant passer par les primitives de jeedom qui le propose, plutôt que d’exploiter les infos de config ou de se créer un script shell.
Les fonctions network->getInterfaceIp() network->getInterfaceMac() network->getInterfaces() ont été remplacées par network->getInterfacesInfo()
Là on moins on sera cohérent avec ce que jeedom connait/découvre…
Quant à la méthode « clone » de machine pour un env de test… Perso j’ai abandonné le truc :
Sauf à avoir TOUT en double (y compris les clés/capteurs), il y a pas moyen de faire les tests jusqu’au bout
Si besoin, je remonte un env dédié, je teste et j’importe (ou je refais)
Si besoin de modifs simples => snapshot et tests… La domotique c’est du confort et donc je peux me permettre tout casser sans conséquences importantes. Retour arrière en quelques secondes si besoin
Je peux remonter mon infra à partir de 0 en moins d’1h, un restauration/
Le problème c’est que tu as construit tout un ecosystème ultra complexe autour de jeedom… et ça rends le tout difficilement gérable au quotidien.
Moi, je veux pas d’un truc monolithique chez moi, mais à base de briques techniques (FW, proxy, webhosting, broker mqtt, grafana, …). Jeedom est un brique (mutlifonctions on est d’accord). Et changer/remplacer une brique ça limite les impacts avec le reste
Merci pour ta réponse, je vais pécher maintenant l’adresse IP dans la BdD au lieu du #IP#, ce n’est pas très grave, sauf peut être pour le user lambda pour qui est fait le tag. En attendant merci d’avoir attirer mon attention sur getInterfacesInfo() !!!
Attention ce n’est pas une bonne idée de désactiver un plugin juste en changeant cette config (et plus généralement par code personnalisé)
si le plugin gérait des cron ou listener par exemple ils ne seront pas désactivés ou inversement réactivé lors de l’activation…
si il existe un core et une interface pour gérer ca ce n’est pas pour rien, après on va voir encore des plaintes que « ca ne fonctionne pas »…
Au minimum faut utiliser les fonctions du core, il y a 100 lignes de code pour activer ou désactiver un plugin…
Merci @Mips, c’est ce que je cherchais et ne t’inquiète pas je fais ça uniquement pour dupliquer une machine en machine de test de manière « propre… » donc pas de plainte hormis cette incohérence de #IP# non conforme à l’adresse « internalAddr » de la BdD de jeedom.
