Il y a peut être eu une coupure réseau au moment de l’événement, mais après cet événement, tous les équipements tuya fonctionnent bien excepté les 2 inter double. Dans la suite des log, le plugin reçoit bien l’état de tous les équipement tuya a part ces 2. Ces inters répondent pourtant au ping, il sont commandable par l’appli tuya et ils fonctionnent à nouveau sur jeedom dés je fais un reset du plugin. Je ne vois donc pas vraiment quoi regarder coté équipement réseau.
Dans la suite des logs LOG2 pb inter 300320.txt (32,7 Ko) , on voit lors de la recherche des devices qu’ils ont tous un socket update, et update devices,sauf les 2 qui ne fonctionnent pas juste aprés. Est-ce que c’est un signe du probleme ? 1 min aprés, tous les devices recoivent le retour d’etat sauf les 2 qui posent probleme.
Perso, lorsque ça s’est produit chez moi, je suis parti aussi sur l’hypothèse de coupures réseau (vu que je coupais le routeur à répétition). Je suppose que l’inter ne se reconnecte pas automatiquement (ou pas correctement) passé un certain délai contrairement aux autres appareils.
A noter que c’est chez moi le seul interrupteur qui n’utilise pas de neutre pour fonctionner.
Depuis la fin de mes travaux, je n’ai plus de soucis.
J’ai aussi l’impression que le problème vient de la reconnexion après une coupure réseau. Seulement ça n’est probablement pas l’inter qui ne relance pas sa communication, mais le plugin. L’état et la commande de l’inter fonctionnent en effet a partir de l’appli tuya, alors que ca ne fonctionne plus avec jeedom.
Si il n’y a pas moyen de corriger ce bug, il faudrait au moins le détecter et relancer manuellement le plugin. Je vais regarder si l’état « connected » change quand le problème arrive. Par contre, comment on peut relancer le plugin à partir d’un scénario ?
oui on peut relancer.
mais si ça fonctionne avec certaines prises
dans un bloc code :
message::add(‹ Scénario ›, 'wifilLightV2 HS ');
wifiLightV2::deamon_start();
Pour moi, le pb ne peut pas être le même, car l’inter répond correctement avec l’application tuya. Le contact est perdu uniquement avec le plugin.
@bernardfr.caron quand je regarde les logs « Event » je constate que toutes les minutes apparaissent les 2 lignes suivantes pour chaque devices :
[2020-04-10 13:49:41][INFO] : Evènement sur la commande [Maison][Inter 2 Canal 2][Etat] valeur : 0
[2020-04-10 13:49:41][INFO] : Evènement sur la commande [Maison][Inter 2 Canal 2][Connecté] valeur : -1 (répétition)
Or quand le contact est perdu avec 1 device, ces lignes n’apparaissent plus pour ce device.
Afin de reboot de deamon au bon moment, penses-tu qu’il serait possible de « superviser » cette perte de log ?
Oui, de plus, je ne crois pas à un pb réseau sur les devices, car depuis que j’ai installé un jeedom dédié, le pb n’apparait plus que 1 fois par semaine comparé à plusieurs fois par jour auparavant.
J’ai réussi a capturer les log debug lorsque le problème arrive, et Bernard a dit que c’est un problème réseau.
C’est possible mais ça ne change pas grande chose. Le problème est temporaire , et après tous les équipements devraient repartir. Dans mon cas, j’ai 10 équipement, et un seul pose souvent problème. le réseau wifi fonctionne lui toujours correctement sans que je redémarre le routeur (je suis d’ailleurs passé du wifi freebox a un routeur séparé et ça ne change rien)
j’ai essayé de faire un scenario basé sur l’etat « connected » de l’inter mais ça ne marche pas. L’état « connected » reste a -1 alors qu’il n’y a plus de retour d’état dans les log depuis des heures. Cet état connected a donc aussi un bug.
J’ai tout essayé mais je ne vois plus aucune solution pour contourner ce bug. Si il n’est pas possible de le corriger, il faudrait au moins gérer le retour d’état pour passer connected à autre chose que -1 sur un timeout. Dans ce cas, on pourrait redémarrer le plugin
@bernardfr.caron, penses-tu que ce soit possible, ou mieux y-a-t-il une chance que tu arrives à corriger ce bug ?
si tu relances le plugin est ce que cela refonctionne ?
Bonjour @bernardfr.caron
oui, avec @patch nous avons les mêmes symptômes. Après reboot du plugin, tout refonctionne.
Oui, je confirme, ca fonctionne aprés reset du plugin.
Voici un log du problème (je l’ai capturé une seule fois, je ne sais pas si c’est toujours pareil):LOG pb inter 300320.txt (41,6 Ko)
On voit que tous les devices ont une erreur ‹ Connection reset by peer n°:104 ›
Tous les devices se reconnectent par la suite mais le 192.168.1.58 (interrupteur triple) ne reçoit plus de retour d’état et ne réagit plus si on lui envoi des commandes. Sur le plugin, cet équipement est a connected = -1. Si on utilise l’appli tuya, cet interrupteur fonctionne normalement. Si on reset le plugin, cet interrupteur fonctionne aussi normalement.
ok alors je vais pouvoir regarder
car jusqu’ici les retours étaient que le redémarrage n’arrangeait rien.
vous êtes en V3 ou V4 ?
V4 pour moi
Ok
je vais privilégier des tests en beta
Il faudra donc utiliser la beta quand je te le dirais.
Pour cela il faut accepter les plugin beta.
V4 pour moi aussi, et pas de probleme pour installer une beta
C’est variable entre 1 fois par jour et une fois par semaine. Comme il apparait sur des interrupteurs, je ne m’en rend compte que le soir. En plus, le plugin redémarre aussi automatiquement pour le problème de memoire, et ca corrige alors notre problème sans qu’on s’en aperçoive.
Quand le plugin perd contact avec un device il tente de se reconnecter au plus tard 1 min après. Visiblement pour certains devices ça pose problème.
J’ai augmenté la tentative de reconnexion jusque 5 min sur la version beta.
Faire vos tests habituels et dites moi si vos devices arrivent à se reconnecter.
→ il faudra procéder par essai/erreur en augmentant progressivement ce temps.
Si ça fonctionne mal pour les devices qui n’avaient pas de souci : logs et revenir en stable.
J’ai installé la beta, y a plus qu’a attendre …