Bonjour,
Depuis Le 26/11/2020 nous rencontrons tous le message d’erreur suivant dans Jeedom :
« Erreur de connexion au cloud Tuya : you cannot auth exceed once in 60 seconds »
J’utilise ce plugin exclusivement pour des interrupteurs de Volets avec comme actions dans différents scénarios qui sont Fermeture des Volets au coucher du soleil, Fermeture des Volets lorsque j’active mon alarme, et ouverture des volets quand je désactive mon alarme.
Dans chacun de mes scénarios, j’appelais chacun de mes interrupteurs de volets en simultané et j’avais forcément l’erreur.
En cherchant j’ai trouvé la solution qui pourrait aider pas mal d’entre nous. Ce n’est pas forcement une solution Idéale, mais elle à le mérite de fonctionner, donc je vous la partage :
Dans l’application SmartLife sur mon mobile, j’ai créé des scénarios manuels qui consistent en la fermeture ou l’ouverture des volets que je souhaites ouvrir ou fermer.
Une fois ces Scénarios créés dans le Plugin Smartlife de Jeedom, j’ai relancé une découverte des objets, ce qui m’a créé des équipements de type scene dans le plugin Smartlife.
Dans mes scénarios Jeedom, j’appelle désormais les scénarios Smartlife au lieu d’appeler chacun de mes interrupteurs et cela répond a mon besoin.
J’espère que cela pourra vous aider en attendant que SmartLife débloque peut être la situation.
Il semble que SmartLife ait limité l’appel aux commande depuis une autre biais que leur application officielle à 1 commande maximum toutes les 60 secondes.
bonsoir, oui c’est la raison pour laquelle j’ai posté cette solution de contournement pas terrible en attendant de trouver mieux. Mais si cette info est officielle il va vraiment falloir modifier le plugin afin d’ouvrir les sessions d’une manière différente.
Bonsoir, ce que je comprend c’est que le plugin tente de s’authentifier à chaque commande, alors que la connexion est persistante au moins pendant 60 secondes.
Si je prends par exemple la suite de commande suivantes :
1 - allumer
2 - changer la couleur
3 - régler la luminosité
le plugin à l’air d’agir ainsi
1 - authetification
1b - allumer
2 - authentification
2b - changer la couleur
3 - authentification
3b - régler la luminosité
Alors que ça devrait-être
1 - authentification
2 - changer la couleur
3 - régler la luminosité
…etc
une seule authentification est suffisante car la connexion est déjà établie quand on exécute les autres commande.
en tous cas c’est ce que je comprend dans le message d’erreur.
Si mon hypothèse est bonne, il faudrait ne s’authentifier que si on a dépassé les 60 secondes, sinon en envoi directement la commande à éxécuter.
en testant la commande curl donnée dans la doc du plugin pour tester la connexion à SmartLife, on obtient le retour suivant :
Bad news. Autant effectivement ça fonctionne en envoyant chaque commande dans un seul scénario (quoi que j’ai des problèmes de retour d’état) autant pour allumer 2 prises manuellement successivement on ne peut plus.
Alors dans mon cas personnel, dans un même scénario je fermais 4 volets en synchrone et ça ne m’en fermait qu’un. j’avais l’erreur sur les 3 demandes de fermeture suivantes.
Je suis obligé de dire ce que ce n’est pas vraiment exact.
Dans un scénario, si les différentes action sont exécutées normalement et pas en parallèle, il n’y a pas de problème.
Il ne faut pas cocher le mode parallèle sur chaque action, sinon jeedom crée un nouveau thread et du coup une nouvelle connexion au cloud.
Je vais apporter un correction de fortune pour que les commandes puissent se lancer si une nouvelle connexion se fait mais avec un délai de 60s
La solution est de faire un démon qui conserve la connexion, mais cela implique à revoir complètement le plugin et plusieurs semaines de dev.
Effectivement, cela devient pénible, j’espere vraiment qu’ils vont modifier le plugin, même si cela prend un peu de temps, je ne comprend pas ce changement, tout fonctionnait il y a quelques temps…
J’avoue que je n’ai pas retesté sans l’exécution des commandes en parallèle. Je le testerai demain. L’idée d’exécuter toutes les commandes en parallèle était que quand j’active mon alarme, tous mes volets se ferment en même temps et pas les uns après les autres pour une question de confort.
Personnellement je suis prêt à attendre plusieurs semaines de dev pour que le comportement initial soit de nouveau la. Le principal étant de savoir que tu y travailles et je te souhaites bon courage sur les adaptations que tu devras faire.
Oui je m’en doutais et comme confirmé par sabinus c’est justement ce qu’il ne faut pas faire car ça ouvre plusieurs session et du coup dès la 2eme c’est bloqué.
Ce n’est pas seulement un problème de scénario.
Personnellement, j’ai tous mes interrupteurs sur Tuya/smartlife.
Depuis, je ne peux plus éteindre ou allumer plus de 2 interrupteurs toutes les minutes… Autant dire que le plugin est inutilisable pour moi (j’ai 16 interrupteurs).
Quelqu’un travailles sur une solution ou quelqu’un aurait une alternative à me proposer ?
En attendant j’ai remis mon compte tuya sur google home pour ne plus passer par jeedom, mais j’ai besoin de jeedom pour connaître la consommation électrique de mes interrupteurs.
Merci par avance !
Vous voulez continuer d’utiliser vos périphériques comme avant ?
Même Mieux ?
Alors utilisez le plug in Wifilight V2 et utilisez cette procédure pour retrouver les localkey de chaque périphérique.
L’enjeu ?
Etre indépendant de tuya et travailler en local uniquement !
Testé et approuvé.
Un peu de boulot en perspective, mais le jeu en vaut la chandelle !
J’ai tenté la procédure via le lien que tu as donné. J’ai réussi a récupéré les 5 périphérique connecté à mon compte SmartLife.
Mais lorsque je tente de les configurer avec le plugin Jeedom « WifilightV2 » je rencontre un problème car les équipement n’ont pas d’adresse IP locale seul l’adresse IP publique de mon routeur apparait dans les informations de l’équipement sur l’application « Smartlife » mobile.
Comment doit-on procéder pour parvenir à intégrer ces équipement (dans mon cas un capteur d’ouverture de porte).
De plus le type capteur d’ouverture de porte ne semble pas exister dans le plugin WifilightV2 les commandes créées ne correspondent donc pas du tout.
Etant quasi full Apple, j’avais un peu de mal à trouver un tuto simple pour récupérer les ID/keys de mes devices…
En arrivant sur la page que tu indiques ici, j’étais un peu perplexe… J’avoue que je n’ai pas vraiment compris ce que je faisais, mais il suffit de suivre les indications et j’ai récupéré tout ça avec succès!
Un test rapide avec Wifilight v2 et ça fonctionne parfaitement. Top!
Merci pour ce lien, je pense que je vais pouvoir stopper le plugin Smart Life qui m’est devenu inutile depuis la mise en place de ces limitations récentes sur les authent smart Life.
Après je les comprends, il serait beaucoup plus propre (et efficace) d’utiliser les access_token pendant toute leur durée de vie plutôt que d’en demander un nouveau à chaque appel.
Tes devices ont forcément une adresse IP sur ton réseau local.
Il faudrait même que tu en attribues une fixe à chacun d’entre eux via DHCP pour pouvoir utiliser efficacement le plugin Wifilight v2.
Tu dois pouvoir retrouver (puis fixer) les IPs de tes devices via l’interface de configuration de ton routeur (ta box).
J’ai apporté une correction pour éviter le blocage de l’erreur you cannot auth exceed once in 60 seconds. Cette correction n’est valable qu’en version 4 de Jeedom.
Merci de se référer à la documentation et aux notes de version pour connaître les restrictions du Cloud Tuya.
Merci à Guillaume pour son aide.
