Refus Jeelink

Plugins Communication
,
62

Fait :wink:

1 « J'aime »
63

Bonjour,
Merci pour le retour, j’ai corrigé dans le core (le plugin ne devrait pas dupliquer les fonctions du core)

1 « J'aime »
64

Bonjour,

Effectivement en rajoutant cette ligne de code, le Jeedom source devient joignable . les infos remontent bien dans le cible, mais les actions du cible vers le source ne fonctionnent pas. tout du moins dans mon cas.

merci

65

Hello, attention je vient de m’apercevoir que dans le cible , depuis la modification apporté dans la nouvelle béta, la désignation du paramètre spécifique ne correspond plus.
bien mettre la clé api de Jeelink source !

image
image920×400 23.3 KB

66

Bonjour,

Je viens de vérifier et j’ai la bonne clé API.

67

As-tu une erreur du style « Vous n’êtes pas autorisé à effectuer cette action » dans les log « JeeEvent » du Jeedom source, lorsque tu essai de piloter un équipement de part le Jeedom cible ?

68

Hélas, je n’ai rien nulle part, même dans les logs, aucune trace de mon action

69

Donc la requête doit passer, vérifie quand même que l’équipement du source ne change pas d’état réellement lorsque tu le commande par le cible, et que ce ne soit pas le retour d’état vers le cible qui ne soit pas actualisé. J’ai déjà eu ce cas de figure.

70

j’ai bien vérifié. le source ne change pas d’état.

71

Même chose pour moi. La clé api ne correspond plus (ou pas). Pas de transmission des commandes et retour d’etat.
Des messages d’erreur « vous n’êtes pas autorisé à effectuer cette action, IP : IP du jeelink source »

72

N’hésitez pas à faire une resave des équipements dans le source.

73

J’ai aussi detecté une chose, mais je ne maîtrise pas le fonctionnement. @Loic, lors de la création d’équipement les infos sont bien créé sur le cible et l’etat est bien mise à jour sur le cible avec la bonne apikey, mais lorsque c’est le listener qui déclenche l’action c’est une vieille apikey qui est envoyés, je me demande si il y pas un truc ou la fonction va d’abord chercher en cache lapikey ?
J’ai aussi fait un essai en mettant le backround à 1 dans le listener, et sa a pour effet d’envoyer la bonne apikey, si sa peu t’orienter.

74

Qu’entends-tu pas backround à 1 du listener?

75

C’était plus un message destiné à Loic, qui je pense va comprendre, mais pour explication lorsque tu enregistre un équipement à transmette au jeedom cible dans le source , celui-ci va créer des listener (pour suivre l’état de ce fameux équipement) et dans les options de ce listener tu as backround:0 et en modifiant le code backround:1 je me suis aperçu que c’était la bonne api key qui était envoyé alors que backround:0 envoie mon ancienne apiKey qui n’est plus d’actualité.

76

Je sais pas trop la peut être redémarrer jeedom

77

Sa peut-être une solution j’ai pas encore été au bout de la recherche, étant donné qu’actuellement Jeelink marche parfaitement chez moi. A temps perdu j’essaierai un regen de clé et un reboot pour confirmer. Mais juste pour info j’ai cru voir dans les class que la méthode de demande api key dans jeedom.class renvoie sur la class config qui elle vérifie si la clé api est en cache, je ne m’avance pas trop sur le sujet car je maîtrise pas mais est ce que lors d’un regen de clé api le cache est mis à jour ?

78

Oui bien sûr la class config invalide le cache et la prochaine demande est refaite à la base de données

79

Pour info, voici les manipulations que j’ai effectué :

Ancienne Api Jeelink source : O88W8v83E6NUxGeXB3lfahYfI0j8…

  • Régénération de la clé API Jeelink source

Nouvel Api Jeelink source : cpIgtdiR73jwd6XA8D9…

  • mise a jour de cette nouvelle clé sur les équipements Jeelink cible :

  • clic [On] sur un équipement Jeedom cible → l’equipement réagit bien sur le source
    Mais le retour d’état ne se fait pas.

  • clic [Off] sur un équipement Jeedom source → listener → pas de changement d’état sur le cible.
    Log api sur le cible
    Demande sur l'api http venant de : 192.168.1.27 => {"apikey":"..ApiJeelinkCible","plugin":"jeelink","type":"event","remote_cmd_id":"83709","remote_cmd_value":"0","remote_apikey":"O88W8v83E6NUxGeXB3lfahYfI0j8.."}
    on voit bien que le remote_apikey, est l’ancienne clé.

  • Re-save des affectations (sans modif) dans le jeelink source.
    Log api sur le cible
    Demande sur l'api http venant de : 192.168.1.27 => {"apikey":"..ApiJeelinkCible","plugin":"jeelink","type":"event","remote_cmd_id":"83709","remote_cmd_value":"1","remote_apikey":"cpIgtdiR73jwd6XA8D9..."}
    l’état se met bien a jour sur le cible.
    On voit bien au re-save que c’est bien la nouvelle remote_apikey qui est envoyé.
    J’ai tenté un vidage de cache, rien y fait.

  • Reboot du jeedom source, tout rentre dans l’ordre.

80

J’ai fait l’erreur en faisant la modification de la présentation
l’info bulle etait bonne mais pas le texte

1 « J'aime »
81

En tous cas ça marche très bien maintenant avec les maj récentes

1 « J'aime »