TUTO PARFAIT pour récupérer les localkey :
1 « J'aime »
TUTO parfait avec Android :
Pour iOS :
je procède avec un ordinateur Linux en installant npm et tuya-client. Ca se trouve sur le web
bonjour à tous, j’ai le même problème. pour info ayant une Amazon echo dot, j’ai tenté les actions sur un groupe d’interrupteurs pour volets roulants mais seul le premier d’entre eux se ferme et pas les autres.
Je me vois mal mettre dans mes scénario une tempo de 1 minutes entre chaque fermeture de volet.
Espérons que la solution soit trouvée rapidement.
Je découvre cette incompatibilité.
Pour l’instant, y compris pour les tuya/zigbee il n’y a pas d’incompatibilité FW / wifilightV2. Mais ça peut toujours venir malheureusement.
Pour ceux qui ont tenté avec wifilightv2 il faut forcément passer par la phase d’association ou on peu passer cette étape car déjà associé ?
En réponse à balabap: Chez moi ca fonctionne bien avec Alexa.
Même soucis. J’avais commencé à passer sur des prises Philips hue. Au moins elles fonctionnent en local. Certe c’est plus cher que des prises wifi mais cela reste quand même abordable.
Cette histoire me conforte dans mon changement : vive le cloudless.
Hello. Tout pareil chez moi, seule la première action fonctionne, après il faut attendre 60sec pour faire une nouvelle action.
@sabinus52 as tu prévu une évolution sur le plugin ? Merci 
il faut associer le périphérique à l’appli mobile.
Le plus difficile et de trouver la localkey mais le forum aide beaucoup.
oui en utilisant nox sur pc et en récupérant le fichier json capturé on obtient tous les localkey. Ca marche nickel a présent j’ai tout reprogrammé sur wifilightv2 mes volets et les 15 fonctionnent à nouveau ! qu’ils aillent en enfer avec leur cloud !
Perso je ne comprends pas …
J’utilise Nox sur mon PC
TuyaSmart V 3.11
HttpCanary (PacketCapture ne fonctionne pas dès qu’il lance le VPN ça bloque)
Je récupère bien les localkey Device Id
mais cela ne fonctionne pas ;-(
je dois bugguer quelque part mais je trouve pas ou 
passe sur la fil wifilightV2, tu auras plus d’aide
mais il faut que tu détaille ton problème
→ le périphérique ?
→ sa config
→ quelles infos ont été prises ?
→ des logs ?
Je vais faire ça.
Je bute pour de bon la
le plugin ne permet pas un basculement rapide en mode urgence.
commencer par ce qu’il y a de plus facile et de plus urgent
c’est pour piloter quoi ? pourrais tu nous dire ce que tu pilotes d’appareil tuya. Il faut bien choisir le bon profil correspondant à la bonne version sur le plugin wifilight. Ensuite, il faut s’assurer que ton ip soit bien fixe pour le matériel donné et je conseille également d’envoyer 3 fois le message a 1ms d’intervalle.
J’ai des interrupteurs simples tuya
2 bandes LEDs
Et 5/6 plug.
Toutes les ips sont fixes
Apres avoir bien vérifié tes profils sur le plugin configure le nombre d’envoi de commande a 3 et le délai a 1ms. Je reste toujours pour ma part en groupe 0 (je ne fais pas de link) et en commande minimale.
Ensuite je vérifie et récupere le deviceid directement depuis l’application car sur le mode raw de httpcanary c’est le bronx et je me perdais. Et ensuite le localkey lui se retrouve facilement en correspondance avec le name du périphérique
Soit c’est un pb de correspondance de deviceid /localkey / ip soit une version de profil qui colle pas ?
J’ai également pour ma part désactivé le profil Smarthome meme si je ne pense pas qu’il y ait de cause a effet.
en complément pour ma part ce sont des interrupteurs volets 3 positions et seul le type Tuya Smart/Jinvoo/efamilycloud compatible V2 fonctionne j’ai ensuite placé le sous type sur du Curtain 1 Mod 2
Bonjour,
Je vois que cela existe beaucoup de monde !
Effectivement, depuis quelques jours, cette erreur « you cannot auth exceed once in 60 seconds » est apparue suite à une nouvelle restriction du Cloud Tuya.
Je comprends que cette erreur est peut être gênante pour la plupart d’entre vous, mais elle reste non bloquante.
Personnellement, je ne suis pas encore tombé sur cette erreur dans mon Jeedom.
La session reste ouverte pendant tout le processus. Mais si Jeedom ouvre un nouveau thread, alors çà va ouvrir une nouvelle connexion et du coup on a l’erreur.
Pour info, ceci est vérifié dans un scénario la session est bien conservée pendant tout le scénario : on veut lancer plusieurs commandes sur différents objets Tuya, il n’y a pas le problème.
Pour contourner ce problème, il faudrait, dans ce cas, revoir entièrement le développement du plugin. Et cette mise à jour ne sera pas disponible avant plusieurs semaines.
Il faut être conscient que dépendre d’un Cloud chinois peut engendrer des problèmes et d’autres peuvent survenir par la suite. C’est la règle du jeu. C’est pour cela qu’il est préférable que tout soit gérer localement comme avec le plugin WifiLightv2, mais pareil rien ne garantit que cela va fonctionner éternellement.
Arête moi si je me trompe mais c’est vrai si tout est lancé en parallèle, pour ma part je lance mes devices les uns après les autres. Du coup cette session ne semble pas conservée.