Impossible de faire fonctionner Jeelink après MAJ 4.2.7

Hello
Alors je ne sais pas si c’est le même problème que moi mais la maj 4.2 a rompu toutes mes liaisons Jeelink :frowning: et j’en ai plus de 200… Au départ après maj COre puis plugin Jeelink (car la maj jeelink avant core échoue), j’ai eu des rafales d’erreur JeeEvent « vous n’etes pas autorisé… »
Il s’avère que faut mettre non pas la clé API Core du Jeedom cible dans la config sur le Jeedom source mais la clé API du plugin Jeelink sur le Jeedom cible.
Mais ensuite cela ne fonctionne toujours pas car dans la config des équipements de type jeelink du jeedom cible la clé API présente est celle du Core du jeedom source. Bon sur un équipement je viens de changer et mettre là aussi la clé API du Jeedom source cette fois et Enregistrer => ben l’actualisation des valuers est toujours ko.
Donc la je ne comprends plus rien.

Je m’auto réponds : bon je pense que j’ai compris ce qui c’était passé :

  • avec la maj 4.2 j’ai compris qu’on devait donner la clef API des plugin Jeelink et pas l’API « principale »
  • en changeant les clés API, je pensais que les équipements Jeelink sur les cibles se mettraient à jour mais en fait ils n’ont pas été modifiés et pour chaque Jeelink j’ai eu un nouvel équipement créé (donc j’ai tout en double) avec la nouvelle clé API
  • si je vais voir les équipements créés avec la nouvelle clé API ils semblent bien etre actualisés avec la bonne valeur mais évidemment dans mes scénarios ou design ils ne sont pas affichés et j’ai donc que ceux d’avant qui ne « bougent » plus

En reprenant le change log de la 4.2 on voit en effet l’info de clés : https://doc.jeedom.com/fr_FR/plugins/communication/jeelink/changelog mais bon pas pour la version du 26.01 mais celle de octobre (j’ai juste regardé celle du 26.01 :frowning: ).

La doc indique aussi de remettre la bonne clé API du jeedom source dans chaque équipement Jeedom cible sauf que dans mon cas cela ne fonctionne pas, l’équipement ne se remet pas à jour : si je reprneds mon équipement Jeelink sur mon jeedom cible et que je lui mets la bonne clef API du plugin Jeelink sur ma source puis Sauvegarder ben ca reste à la mauvaise valeur :frowning:

Je n’utilise pas mais tes Jeedom sont bien en 4.2.7 des 2 côtés ?

Oui c’est en basculant mes 4 jeedom ce soir de 4.1.28 à 4.2.7 que j’ai eu tout qui est parti en désynchro.
Je pense qu’à la base le souci vient du fait que meme en remettant dans mes équipements sur le jeedom cible la bonne clé API de la source cela ne fonctionne pas (meme après correction aussi coté source et resauvegarde des affectations)…

En revanche ca m’a recréé des doublons.

état avant migration :

  • équipt1 avec clé API Core Jeedom source
    Jeedom source avec une cible avec la cle API Core

migration

  • je migre tout en 4.2 => rafale d’erreur « non autorisé »
  • je mets les bonnes cles API de part et d’autres ie dans le jeedom source la clef API du plugin jeelink du jeedom cible + save et save aussi dans l’onglet affectation => la ca m’a créé un equip1 « remote » avec les bonnes cles API mais l’ancien equip1 est ko
  • si dans l’ancien equipt1 je mets la nouvelle cle et détruit equipt1 remote ben ca marche pas

La doc dit :

J’ai des erreurs : Vous n'êtes pas autorisé à effectuer cette action

Assurez-vous que les clés API Jeedom Link soient bien renseignées :

  • La clé API Jeedom Link du Jeedom source sur chaque équipement Jeelink du Jeedom cible.
  • La clé API Jeedom Link du Jeedom cible sur la page de configuration des Jeedoms cibles du Jeedom source.

Hello.

Dans mon cas la mise à jour des clés API dans la définition des Jeedom cible sur chacun de mes 3 jeedom source résout bien le prb de message d’erreur.

Le souci que j’ai ensuite c’est que je n’ai aucun retour d’état côté Jeedom source. En effet je suis alors allé voir si la clef API avait été modifié dans les équipements jeelink de ma cible après avoir fini la sauvegarde de la config cible coté Jeedom source mais ce n’était pas le cas. En modifiant unitairement un équipement Jeelink sur la cible et en mettant la clé API du plugin Jeelink de ma source, cela reste ko :frowning: et en revanche la sauvegarde de la nouvelle clé API sur mon jeedom source a généré la création de nouveaux equipements avec eux la bonne clé API directement et qui sont synchronisés sauf que ce sont de nouveaux équipements.

Je ne sais pas s’il faut faire une autre action sur les jeedoms source et cible (plutot cible je pense) pour que les modifs de clé soient prises en compte. reboot ? relance d’une tache du plugin jeelink ? autre ?

soit je n’ai pas fait la modification dans l’ordre, soit les modifications sont bonnes mais pas prises en compte coté jeedom cible et il faudrait que je relance qque chose. Ce qui d’entrée me surprend c’est la création directe de nouveaux équipements sans maj des anciens.

Après j’ai toujours la solution de détruire l’ancien équipement et d’utiliser le nouveau créé en double mais cela oblige à modifier design, scenario etc qui utilise chaque équipement. Et je dois avoir pas loin de 100 jeelink. Bon il y a bien une explication mais la comme cela je ne la vois pas

Au cas où, j’ai aussi tenté de regénérer de nouvelles clés API sur chaque jeedom source et cible => la « taille » de la clé a d’ailleurs doublée en caractères en gros mais cela a eu le même effet : recréation de nouveaux équipements (en triple du coup :frowning: ) et aucune maj des anciens, de même que ko de synchro si maj unitaire de la nouvelle clé longue sur un des anciens équipements jeelink sur le jeedom cible.

Pour les clés API c’est normal et annoncé

Oui j’avais bien lu et vu tout cela. Encore une fois mon souci ne semble pas (ou ne plus) être au niveau des clés API définies que j’ai du coup passé de 32 à 64 et bien resaisies de part et d’autre mais dans l’impossibilité de remettre correctement le retour d’état sur mes anciens équipements jeelink sur le jeedom cible.

Là je viens de retester sur un volet : après modif de la clef API de l’équipement sur le jeedom cible je peux lancer des actions comme fermer, arreter mais le retour d’état est ko : aucune commande info ne se met à jour côté cible alors que sur la source la commande lancée depuis le jeedom cible a bien lancé l’action et l’équipement source possède bien le bon état. C’est pour cela que je me dis qu’il y a pt être un truc à relancer ou simplement rebooter cible ou source. Ou encore refaire une sauvegarde coté cible après avoir changé la clef API coté équipement sur la cible, etc…

PS : sinon les qques évols que j’ai vu en 4.2 sont bien sympa:) logs, bandeau sauvegarde ok qui disparaît tout sel avec une chouette animation etc… Dommage que mes jeelink me gachent un peu le plaisir car la 4.2 apparaît comme ttes les evols apporter de très belles choses

Vu que tu fais la modif alors que ecla communique, je tenterai de couper la communication sur le source.
Mettre a jour les cibles avec la clé API adéquate

Et ensuite mettre le source a jour
Pour couper la comm, retirer toutes les clés API coté source

On parle bien de la clé API Jeecom Link (de 32 caractères) à chaque fois et non de celle du core qu’on soit d’accord ?

Si tu as un doute n’hésites pas à la renouveler en cliquant sur les 2 flèches circulaires.

Oui je parle bien de celles ci. Avant 4.2 en revanche j’avais mis les API « Core » ou global du jeedom d’ou mes erreurs à la migration (titre du topic) résolues dès lors que j’ai correctement renseigné les clés API plugin Jeelink coté source.

je peux tenter la manip indiquée par @anon53349806 pour forcer la maj de l’ancien équipement jeelink :

  1. jeedom source (gérant mes volets) : suppression de la clé API de ma cible (interruption de comm)
  2. jeedom cible : mise à jour de plusieurs de mes équipements jeelink anciens avec la nouvelle clé
  3. jeedom source : remettre la clé sur la config jeedom link (rétablissement de la comm)

Pour moi il n’y a plus d’erreur de clé car les commandes actions refonctionnent mais c’est la remontée des états qui est en échec sur le jeedom cible.

Bon pas évident de faire des manips en plein télétravail :slight_smile: toutefois je pense réussir à m’en sortir sans devoir supprimer / retirer les clés API. J’ai tenté déjà de rebooter ma smart qui contient tous les jeelink vers les sources. Aucun effet. En revanche pour que cela redevienne ok côté retour d’état, après avoir remis un à un les clés dans chaque Jeelink cible, il faut détruire tous les doublons d’équipements recréés par Jeelink à la 1ère maj des clés API sur le jeedom source puis retourner sur le jeedom source et refaire Save.

En gros si je devais donner un conseil ce serait dans l’ordre :

  1. migration Core 4.2 + plugin jeelink
  2. sur le jeedom cible : aller mettre la clé API du plugin Jeelink du jeedom source dans TOUS les équipements existants
  3. jeedom source : modifier la clé API des cibles avec la clé du plugin Jeelink du jeedom cible et faire Save

Dans ce cas la je ne pense pas que Jeelink va recréer un équipement avec la clé API car il existe déjà. Dans mon cas, j’ai d’abord changé coté jeedom source et cela m’a créé des doublons vers lesquels le retour d’état se faisait.

Brej je pense pouvoir échapper au re référencement de tous mes équipements jeelink et donc assez facilement pouvoir tout retrouver au bémol de devoir aller unitairement mettre chaque équipement jeelink à jour (comme dit j’en ai beaucoup mais cela doit fonctionner une fois qu’on a la bonne manip) !

Edit du soir : bon j’ai pris environ 1h30 pour tout remettre d’équerre. Au cas où je confirme que mes premiers tests étaient bien faussés par la présence des équipements en doublons qui recevaient les retours d’état. En étant très méthodique avec à coté un fichier contenant les 4 clés API que je devais manipuler, j’ai mis à jour équipement par équipement et détruit les 2 ou 3 équipements clonés inutile. Suite à tout cela c’est rentré dans l’ordre. Il aura juste fallu comprendre d’où çà venait. Il me parait donc important pour ceux qui seraient concernées de commencer par la maj des équipements un à un comme je l’ai mis plus haut, car sinon on est vraiment pollué par les doublonnage d’équipements. Je vais maintenant m’attaquer au cas des URL jeeApi car j’ai cru voir que j’allais devoir aussi changer les clés. En scrutant les logs pour comprendre, j’ai en tout cas vu les supers évolutions sur ces logs, c’est super !

3 « J'aime »

Bonjour je suis dans le même cas message comme quoi je n’ai pas l’autorisation je vais vérité si I les clees sont ok

Je te trouve franchement détendu, merci de ton calme.

Ici, 2h37 du matin, plus de températures, donc plus de chauffage dans certaines pièces, et 14kW qui tournent en boucle depuis 12h ce matin, à la mise à jour. Le PETIT détail à peine noté dans le changelog.

Le soucis c’est que j’ai pas que ça à foutre. J’aurai pas le temps de me taper mes 100 équipement avec leurs 100 copies avant samedi.

Donc je fait quoi ? Je me pèle le cul jusqu’à samedi, ou je laisse tourner 80€ de chauffage par jour jusqu’à samedi ?! AU TOP \o/. Et va falloir faire pareil avec JeeLink ??!! Et d’autres ? Sans déconner, ça me motive presque à laisser tomber Jeedom définitivement, c’est pas possible de faire des conneries pareil. Sauf que pareil : J’AI PAS QUE CA A FOUTRE.

Edit: Ou je me calme deux secondes, je roolback sur ProxMox et je me recouche -_-’ sorry !

2 « J'aime »

Oui à cette heure ci c’est le plus rapide :wink:

Bonjour moi j’ai bien modifié les clées et toujours pareil acces non autorisé

Hello
Je n’ai eu aucun dysfonctionnement de mon côté car mes 3 jeedom sources fonctionnent en autonomie sur les domaines vitaux ouvrants chauffage et sécurité. L’agrégation sur le jeedom cible via jeelink sert de visualisation et de supervision globale. Mais j’ai volontairement cherché à avoir des sous domaines isolés étanches pour ce type de cas ou un pb matériel. Au pire un seul domaine est défaillant.

Pour ce qui est de la mise à jour et lorsque c’est une version majeure le mieux est toujours de patienter un peu et d’aller jeter un œil à la fois aux informations de version et aux posts ici avant de se lancer et choisir un moment sans stress :grin: pour le cas où des manipulations sont à faire. En 5 ans de jeedom j’ai quasi jamais vu de pb majeur pour ma part.

Certes en hiver on aime peu planter le chauffage. Lors de la mise en buster de mon rpi3 de chauffage j’avais attendu la période de fin de chauffage.

Enfin ne pas oublier que ici on voit les retours de ceux avec un souci dont cette fois-ci j’ai fait partie. Toutefois pour d’autres cela s’est peut être bien passé y compris pour jeelink.

Bref bon courage et j’espère que mes messages aideront ceux qui n’ont pas encore migré, c’est pour cela que je les ai mis en essayant de donner la méthode qui m’apparaît la moins perturbante et en indiquant le coût. Et dans mon cas j’y ai passé 1h30 car j’ai 120 jeelinks. Avec une dizaine c’est l’affaire de 15mn.

2 « J'aime »

Pareil pour moi, problème d’autorisation. J’ai simplement fait « Sauvegarder » des 2 côtés et j’ai des doublons d’équipements qui sont apparu (et qui fonctionne du coup). Mais faut que je migre tout maintenant :confused:

Hello. Quand tu dis « migre tout », tu veux bien dire supprimer les doublons et remettre la bonne clé API dans chacun des « anciens » équipements ? il ne faut pas détruire les anciens et utiliser les doublons qui fonctionnent, c’est inutile et très contraignant. Comme dit ci dessus, dans mon cas, mes anciens équipements ont repris la main dès lors que j’avais supprimé les doublons et bien mis la bonne clé dans les anciens.

Comme dit ici Impossible de faire fonctionner Jeelink après MAJ 4.2.7 - #12 par Ds5 même si a priori trop tard te concernant, je penserai qu’en changeant les clés API d’abord dans les équipements sur la cible puis ensuite en faisant save coté source, ca évite le traitement de doublons (mais je ne peux pas le vérifier désormais)

Accessoirement c’est expliqué dans le bon ordre dans la FAQ de la documentation du plugin…

1 « J'aime »