Device is offline

[Clem-]

La prise n'est plus accessible : code -20571 / Device is offline La prise est pourtant bien connectée et pilotable via l'application Kasa.

[2019-01-18 09:15:08][DEBUG] : 
Array (     
    [request] => Array (     
        [78] => 10     
        [19913] => 1     
        [42] => 1     
        [13] => 60     
        [10018] => Kasa_Android     
        [64] => 1     
        [10023] => Array         (             
            [0] => Content-Type: application/json             
            [1] => Expect:         )      
        [10015] => {
            "method":"passthrough",
            "params":{
                "deviceId":"80061616905C52E7BC353B4CEBEDB68017A8E9E3",
                "requestData":"{\"system\":{\"set_relay_state\":{\"state\":0}}}"}
        }     
        [10002] => https://wap.tplinkcloud.com/?token=********** )      
    [result] => HTTP/1.1 200 OK Content-Type: application/json;charset=UTF-8 Date: Fri, 18 Jan 2019 08:15:08 GMT Server: Apache-Coyote/1.1 Content-Length: 47 Connection: keep-alive  
        {"error_code":-20571,"msg":"Device is offline"}     
    [errno] => 0 )

[kavod]

Bonjour Clem,

Pourrais-tu envoyer les logs debug complets (qui commencent normalement par "*** DeviceList:" en suivant les instructions de ce chapitre ? Ca me permettra d'en savoir plus sur la configuration de tes équipements.

Enfin, quand tu dis "plus" accessible : tu veux dire que ça fonctionnait avant et que subitement ça ne fonctionne plus ? De façon durable ou ponctuellement ?

Normalement, ce message d'erreur apparaît lorsque la prise n'est plus branchée à l'alimentation (et perdure environ 1min après branchement). Je ne te demanderai pas si c'est le cas ;)

Merci

[Clem-]

Bonjour, Ca fonctionnait hier oui, je viens de tout mettre en place donc je peux pas dire que ça a fonctionné longtemps mais au moins quelques fois oui, avant que cette erreur ne survienne, de façon durable.

Le log complet :

[2019-01-18 09:43:03][DEBUG] : *** DeviceList:
[2019-01-18 09:43:03][DEBUG] : Array (     [request] => Array (     [78] => 10     [19913] => 1     [42] => 1     [13] => 60     [10018] => Kasa_Android     [64] => 1     [10023] => Array         (             [0] => Content-Type: application/json             [1] => Expect:         )      [10015] => {"method":"getDeviceList"}     [10002] => https://wap.tplinkcloud.com/?token=********* )      [result] => HTTP/1.1 200 OK Content-Type: application/json;charset=UTF-8 Date: Fri, 18 Jan 2019 08:43:03 GMT Server: Apache-Coyote/1.1 Content-Length: 510 Connection: keep-alive  {"error_code":0,"result":{"deviceList":[{"fwVer":"1.2.5 Build 180410 Rel.182458","deviceName":"Wi-Fi Smart Plug","status":0,"alias":"Dyson","deviceType":"IOT.SMARTPLUGSWITCH","appServerUrl":"https://eu-wap.tplinkcloud.com","deviceModel":"HS100(FR)","deviceMac":"50C7BF0B15D6","role":0,"isSameRegion":false,"hwId":"16C57BBBEB92C5C539E90D382FA056F4","fwId":"00000000000000000000000000000000","oemId":"FB75069DC194979E3318247757175DD8","deviceId":"80061616905C52E7BC353B4CEBEDB68017A8E9E3","deviceHwVer":"1.0"}]}}     [errno] => 0 )
[2019-01-18 09:43:03][DEBUG] : ***  Device 80061616905C52E7BC353B4CEBEDB68017A8E9E3
[2019-01-18 09:43:05][DEBUG] : Array (     [request] => Array (     [78] => 10     [19913] => 1     [42] => 1     [13] => 60     [10018] => Kasa_Android     [64] => 1     [10023] => Array         (             [0] => Content-Type: application/json             [1] => Expect:         )      [10015] => {"method":"passthrough","params":{"deviceId":"80061616905C52E7BC353B4CEBEDB68017A8E9E3","requestData":"{\"system\":{\"get_sysinfo\":[]}}"}}     [10002] => https://wap.tplinkcloud.com/?token=********* )      [result] => HTTP/1.1 200 OK Content-Type: application/json;charset=UTF-8 Date: Fri, 18 Jan 2019 08:43:04 GMT Server: Apache-Coyote/1.1 Content-Length: 47 Connection: keep-alive  {"error_code":-20571,"msg":"Device is offline"}     [errno] => 0 )

[kavod]

OK. Ca correspond vraiment à la situation où la prise n'arrive plus à communiquer avec le serveur Kasa. Le fait que ça fonctionne avec l'appli Kasa peut s'expliquer par une connexion via le réseau local.

Pour confirmer ça, peux-tu :

• désactiver le wifi de ton téléphone (utilisation uniquement de la 3g/4g)
• tenter d'allumer/éteindre ta prise via l'application Kasa du téléphone et m'indiquer le résultat de ce test.

Merci

[Clem-]

C'est exactement ce que j'ai pensé, j'ai donc partagé ma connexion 4G à mon iPad pour tester l'accès a distance via l'application Kasa, et tout fonctionnait. Je viens de dé/rebrancher la prise, ça refonctionne depuis Jeedom!

J'ai programmé quelques scénarios pour solliciter le plugin dans la journée et je verrai si les logs remontent une nouvelle anomalie.

Merci beaucoup et désolé pour le temps perdu si ce n'était qu'une histoire de redémarrage...

[kavod]

Ce n'est absolument pas du temps perdu puisque la question peut se reposer pour d'autres (et j'aurais au moins ton retour d'expériences). Car mon plus gros soucis dans ce problème, c'est qu'après 2 mois d'utilisations, je ne l'ai pas rencontré avec mon HS110.

Le plugin active un cron toute les 15min pour se mettre à jour. Ca vaut peut-être le coup que je mette une fréquence de mise à jour plus régulière voire paramétrable.

Du coup je laisse le sujet ouvert : n'hésite pas à me tenir informé du comportement que tu constateras. Je vais continuer à faire des recherches sur les forums : j'ai cru comprendre que les utilisateurs de l'Echo d'Amazon rencontraient un soucis équivalent.

[Clem-]

Hello, le problème est malheureusement toujours présent mais de manière ponctuelle.

Exemple des dernières notifications Jeedom :

| 2019-01-21 06:00:22 | kkasa | Erreur exécution de la commande [Off] : Device is offline |
| 2019-01-20 11:45:16 | kkasa | Erreur sur la fonction cron15 du plugin : Request timeout |  
| 2019-01-19 13:30:05 | kkasa | Erreur sur la fonction cron15 du plugin : Device is offline

S'agirait-il d'un problème sur mon réseau wifi ? C'est embêtant car en cas d'erreur de commande, il n'y a pas de file d'attente pour retenter d'envoyer la commande.

[kavod]

Hello,

Je viens de faire un appel à témoins sur le forum jeedom pour avoir d'autres cas comme le tiens qui m'aideraient à comprendre.

Je vais implémenter un système de "retentative" dans la limite du raisonnable : je ne peux me permettre "d'attendre" trop longtemps entre chaque tentative sous peine de voir se dégrader la réactivité du plugin et de dégrader le temps de chargement de certaines pages en cas de soucis (typiquement : la page "santé").

Malheureusement, même si on peut hypothétiquement espérer une résolution du "Request timeout", je n'ai aucun espoir pour le "Device offline". En effet, lors du premier message (Request Timeout), le serveur Kasa "attend" réellement une réponse de la prise (ça se sent sur le temps de réponse beaucoup plus long). Autant, sur le deuxième message (Device offline), le serveur ne prend plus la peine d'interroger la prise et répond immédiatement que le lien est mort.

Ce qu'il faut bien comprendre, c'est que le plugin ne fait que retranscrire ce que le serveur Kasa renvoie (en substance, un message d'erreur). En d'autres terme, ce n'est pas le plugin qui n'arrive pas à se connecter au serveur Kasa, mais le serveur Kasa qui n'arrive pas à se connecter à la prise.

Bref, je tente l'implémentation des "retry" (que je publierai sur la version beta dans un premier temps) et je reste à l'écoute d'autres retours d'expériences.

[kavod]

Voilà, les 3 tentatives en cas d'erreur ont été implémentées sur la branche "develop" et publiée sur le market Jeedom en beta.

J'attend tes retours.

Merci !

[Clem-]

Le problème est toujours présent. Du coup je me demandais quelle était la logique pour piloter/récupérer les infos de la prise ? Est-ce que tout passe par le "cloud TP-Link" ou bien les commandes sont envoyées sur le réseau local ?

Par exemple, le plugin TP-Link Smartplug de Domoticz se connecte à l'API uniquement pour récupérer un Token mais toutes les commandes sont envoyées via des requêtes HTTP sur le réseau local.

[kavod]

J'avais bon espoir que la correction de #20 ait pu arranger les choses... mais non.

C'était effectivement un parti pris de ne me baser que sur le cloud pour des raisons de facilité (les communications sur le réseau local ont une couche d'encryption qui rend les tests un peu compliqués).

Malgré tout, c'est marrant que tu m'en parles maintenant car j'ai passé la soirée à initier ce développement en réseau local. Ca ne va pas être prêt tout de suite... mais je pense que ce sera la prochaine grosse mise à jour.

Par curiosité : peux-tu m'indiquer la force du signal wifi que la prise reçoit ? Tu peux la trouver sur l'appli Kasa (dans les réglages de la prise) ou mieux : j'ai publié ce soir une version sur la branche "develop" (pas encore sur le market) qui donne cette info dans les commandes de l'équipements et que tu peux historiser. Du coup, ça permettrait de voir l'évolution.

[Clem-]

La prise est à -65 dBm.

Les communications sur le réseau local avait l'air d'être assez faciles (simple XOR). Si ça peut aider (et si tu n'est pas déjà tombé dessus...) :

• script Python de base
• plugin Domoticz un peu plus simple

[kavod]

Bien que Python soit mon langage préféré, j'ai arrêté de l'utiliser pour mes développements Jeedom. La gestion des dépendances m'ont posé pas mal de soucis dans le passé. C'est pourquoi je me suis remis à mon ancien amour qu'est le full PHP.

Malgré tout, je suis confiant pour y arriver... je dis simplement que c'est moins aisé ;)

Ton cas me laisse quand même assez perplexe. -65dBm c'est pas loin de ce que j'ai (-61/-62). Je n'arrive vraiment pas à comprendre cette perte de synchro entre ta prise et les serveurs Kasa.

[Peboli]

Bonsoir Brice,

Un petit passage en vitesse pour te signaler que j'ai également des problèmes de time-out avec le plugin. Tu parlais de modifier le cron pour récupérer l'état plus souvent, c'est ce que j'ai fais depuis l'installation du plugin en utilisant le 'cron' à la place du 'cron15'. Par contre je me posais la question de la pertinence de passer par le "cloud TP-Link" ... à par pour la facilité d'intégration des prises dans Jeedom (pas d'adresse IP à gérer) Pourquoi ne pas communiquer directement avec la prise en local ? Je fais de l'impression 3D et il y a un plugin TP-LINK pour Octoprint qui gère la prise en direct, peut-être une source d'info pour trouver la syntaxe des commandes.

[kavod]

Par contre je me posais la question de la pertinence de passer par le "cloud TP-Link" ... à par pour la facilité d'intégration des prises dans Jeedom (pas d'adresse IP à gérer)

Le plugin s'appelle Kkasa... car c'était effectivement son objet d'utiliser "Kasa" (le serveur cloud), d'où son nom. Outre la facilité de gérer l'adresse IP, il y avait aussi la facilité de la communication (requêtes parfois UDP pour le scan, parfois TCP pour le reste... et surtout un contenu de requêtes cryptées).

Ceci étant dit, j'ai effectivement décidé de donner le choix entre le cloud et le réseau local. La v2 de KKPA a été terminée en début de week-end et je suis en ce moment même en train d'adapter le plugin en fonction. Ca ne devrait plus être bien long et je pense sortir la version beta dans la semaine (max week-end prochain). Sur le market, je pousse l'actuelle beta en stable demain soir (sauf retours négatifs d'ici là) afin de commencer à proposer cette v2.

[kavod]

Hello,

La v2 (qui comprend la gestion du mode local) commence à être pas mal utilisable à présent. Elle est disponible sur la branche v2. Je vais être en déplacement pendant 2 semaines, j'ai donc fais le choix de ne pas pousser cette version sur le market (ni en stable, ni en bêta) pendant cette période. Cependant, vous pouvez d'ores et déjà la télécharger depuis le github (branche v2 donc) et me faire vos premiers retours que je traiterai à mon retour.

Merci à vous

[Peboli]

Bonjour Brice,

v2 installée ! Je teste et je te tiens au courant si j'ai des soucis. Par contre comment fais-tu pour récupérer les adresses IP des prises ? Comment faire pour ajouter une prise quand on est en mode local ? Faut-il toujours passer par le cloud au moins une fois pour chaque nouvelle prise, faire une synchro et puis repasser en local ?

Merci pour ton temps passé au développement ;)

Bon déplacement !

[kavod]

Arf, très bonne remarque. En fait il faut utiliser le même bouton "synchroniser avec Kasa". Sauf que dans le cas du mode local, il ne va pas faire de synchro avec Kasa mais faire un scan du réseau local.

Il faut donc que je renomme ce bouton :)

[Peboli]

Ok, mais si je fais une synchro ça me dit qu'aucun équipement joignable n'est trouvé.

J'ai ceci dans le log en debug, il y a toujours une référence vers le cloud, mais l'adresse IP est bien là.

[2019-02-16 11:08:10][DEBUG] : Array ( [conf] => Array ( [base_uri] => https://wap.tplinkcloud.com/ [username] => [password] => [deviceId] => 80061F1E5AF20DF92BCE372E8D2CF19218AE62BC [local_ip] => 192.168.0.24 [local_port] => 9999 ) [token] => [uuid] => [deviceId] => 80061F1E5AF20DF92BCE372E8D2CF19218AE62BC ) [2019-02-16 11:08:10][DEBUG] : Array ( [conf] => Array ( [base_uri] => https://wap.tplinkcloud.com/ [username] => [password] => [deviceId] => 80069EAFA8DEC16E1108A567AF35A8F818AE7F08 [local_ip] => 192.168.0.25 [local_port] => 9999 ) [token] => [uuid] => [deviceId] => 80069EAFA8DEC16E1108A567AF35A8F818AE7F08 ) [2019-02-16 11:09:03][DEBUG] : Processing refresh of 80069EAFA8DEC16E1108A567AF35A8F818AE7F08

J'ai aussi pour une prise les libellés dans la trace en français et pour l'autre prise les libellés en anglais

[2019-02-16 10:49:03][DEBUG] : Processing refresh of 80061F1E5AF20DF92BCE372E8D2CF19218AE62BC [2019-02-16 10:49:03][DEBUG] : set: Etat to 0 [2019-02-16 10:49:03][DEBUG] : set: Force signal to -76 [2019-02-16 10:49:03][DEBUG] : set: Courant to 0.012373 [2019-02-16 10:49:03][DEBUG] : set: Tension to 232.287822 [2019-02-16 10:49:03][DEBUG] : set: Puissance to 0 [2019-02-16 10:49:03][DEBUG] : set: Consommation to 9.28 [2019-02-16 10:50:03][DEBUG] : Processing refresh of 80069EAFA8DEC16E1108A567AF35A8F818AE7F08 [2019-02-16 10:50:03][DEBUG] : set: State to 0 [2019-02-16 10:50:03][DEBUG] : set: Force signal to -74 [2019-02-16 10:50:03][DEBUG] : set: Current to 0.01689 [2019-02-16 10:50:03][DEBUG] : set: Voltage to 231.961984 [2019-02-16 10:50:03][DEBUG] : set: Power to 0 [2019-02-16 10:50:03][DEBUG] : set: Consumption to 0.001

[Peboli]

Pour ce qui est des commandes, pourquoi la page ne correspond pas à la structure habituelle de Jeedom ? A savoir des commandes infos qui peuvent êtres liées à des actions comme ci-dessous.

Ça permet d'utiliser un widget unique pour la commande et l'info, comme ceci au lieu d'avoir une indication d'état et deux commandes pour ON et OFF

C'est juste un 'feature request', je ne sais pas vraiment ce que ça représente comme travail. Mais comme c'est un standard dans Jeedom je me dis que ça ne doit pas être trop compliqué ;)

[kavod]

Hello,

Pour l'aspect "page commandes", j'ai créé l'issue #27. Je t'en reparle dessus.

Pour le message "équipements non joignables" : ce que je vois, c'est que tu as déjà ajouté tes 2 équipements. En utilisant le bouton de synchro, il tente de chercher de nouveaux équipements. Je crois donc comprendre qu'il n'a pas trouvé plus d'équipements que les 2 prises déjà ajoutées. D'où ce message (qu'il faut peut-être que je reformule et que je mette en jaune plutôt qu'en rouge).

La référence au cloud dans les logs est normale... j'ai uniformisé au maximum les fonctions de telle manière ou l'ensemble des informations fait parti de la même configuration. Ce n'est pas pour autant qu'ils sont utilisés.

Enfin la langue des logs : il reprend tout simplement le libellé tel qu'il apparaît dans la page des commandes. La valeur par défaut étant normalement celle de ta langue sur l'interface Jeedom au moment de la création de l'équipement. Bizarrement, je ne vois aucune trace de l'appellation "courant" pour l'intensité (par exemple). Est-il envisageable que tu ais manuellement modifié le nom de la commande dans la page "Commandes" ?

Enfin, d'une façon générale, pourrais-tu ouvrir une "issue" par problème ? N'ai surtout pas peur d'en créer une tripoté de grosse ou faible importance. Ça me permet de mieux m'organiser (surtout si je n'y touche pas pendant 2 semaines).

Merci encore

[Peboli]

Salut,

Je n'ai en effet que deux prises, ceci explique donc cela. Une reformulation serait en effet plus clair pour faire la différence entre les deux cas de figure.

Pour les logs, j'ai effectivement modifiés les libellés de certaines commandes, ce qui correspond bien à ce que j'ai.

Ok, si nouveau problème je crée une nouvelle 'issue'.

Merci !