Bonjour,
J’utilise le plugin Jeelink pour remonter des équipements de deux esclaves vers un maitre. Ils sont tous au même niveau d’OS, de Jeedom (4.3.17) et de plugin (2022-01-31). Un équipement refuse absolument de remonter alors que tous les autres ne posent aucun problème.
Aucun message d’erreur dans les logs. La seul élément d’explication que j’ai pu trouver est qu’il existe déjà un équipement Jeelink ayant le même ID.
Certains ont-ils rencontré le même problème ? Si oui comment l’ont-ils résolu ?
Merci pour vos retours
Hello,
Regarde ce topic que j’avais créé à l’époque :
Il y un bug, que j’ai signalé au moins 10x, j’ai abandonné l’idée qu’il soit corrigé un jour ^^
Peut être que tu es dans le même cas.
Merci pour ton retour rapide.
La vérification en base montre que les paramètres sont tous identiques et que l’object_id est bien à « null »
Une autre piste ?
Et quand tu vas sur le Jeedom de destination, sur le module en question, tout ce qui est clé API, ID, IP, c’est correct ?
Non le module en question ne remonte pas alors que 4 autres du même jeedom source ne posent pas de problème. Le problème semble être au niveau de cet équipement
En BDD, tu vois une différence avec les autres sur la source (normalement c’est son eqlogic) :
SELECT * FROM jeelink_master;
Et sur la destination, tu le vois en BDD (il est peut etre créé même si pas affiché) :
SELECT * FROM cmd WHERE eqType = « jeelink » AND logicalId LIKE « %remote% »;
EDIT : plutot cette commande : SELECT * FROM eqLogic WHERE eqType_name=« jeelink »;
Sur la source, je retrouve bien ma cible et dans la colonne configuration les équipements que je veux faire remonter vers ma cible notamment: {« eqLogic »:"#eqLogic17#"}.
Sur la cible, impossible de retrouver cet équipement. Mais j’ai trouve un ayant une autre source (ce qui est normal ) avec le même eqLogicId. D’où ma question est-ce que deux équipements ayant des sources différentes mais le même eqLogicId peuvent remonter dans la même cible ?
Pour moi l’eqLogic sur la source et la destination n’ont rien à voir. Sur la destination, il va créer le sien, sinon, ça fonctionnerait jamais.
Du coup, il reste le problème de clé API ou un truc du genre 
Je comprends. Mais s’il y avait un pb de apikey ou autres les autres équipement issus de la même source ne remonteraient pas. 
Je confirme mon hypothèse sur l’eqLogicID.
Sur la source, j’ai dupliqué l’équipement qui a donc un eqLogicID différent (sans rien changer d’autre).
Et là, l’équipement remonte sans aucun pb.
Bonjour,
Oui mais attention il faut absolument que les clef api soit différente pour les esclaves. La clef de recherche c’est remote::eqLogic_id::apikey
Au passage lors de ce genre de soucis ne pas hésiter a mettre des logs car l’information est dedans…
Effectivement les deux instances Jeedom source ont la même Apikey, alors qu’elles ont été installées à des mois de différence. Le fruit du hasard ?
Quelles seraient les logs pertinentes à joindre car celle de jeelink est désespérément vide même en mode debug ?
1 « J'aime »
Celle de jeelink lors d’une synchronisation côté master et cible en debug. Mais la plus besoin tu as la même clef api c’est ça le soucis.
1 « J'aime »
Ce sujet a été automatiquement fermé après 24 heures suivant le dernier commentaire. Aucune réponse n’est permise dorénavant.