Bonjour a tous,
j’ai une installation Jeedom sur freebox Delta avec des équipements Tuya (WIFI et Zigbee). Pour faire le pilotage des modules, je passe par #wifilightV2. Les actions et états sont bien remontées mais aléatoirement j’ai régulièrement des temps de latences des commandes de quasi 5 secondes que je n’arrive pas a expliquer.
Auriez vous des idées svp ?
forcément un souci réseau
ou un souci de la config jeedom avec une charge importante.
en complément, quand je fais les commandes depuis l’application Smartlife je n’ai aucun temps de latence.
Photo de l’état de santé de mon systéme
donc pas un problème réseau entre le périphérique et le routeur.Pour le reste le diag est toujours valable.
Merci, maintenant a voir comment faire pour le modifier sur une freebox delta
fais toi aider par un spécialiste et vérifier que c’est un souci sur delta car sur atlas ce n’est pas le cas
Bonjour, je rencontre le même soucis de latence sur tous mes appareils Tuya : platines volets et prises.
Plus que de la latence, parfois certains ne s’actionnent pas.
Rien a bougé côté réseau et Jeedom, juste installé la derniere version du plugin.
Les appareils répondent parfaitement sans latence depuis l’appli Tuya.
C’est assez ennuyeux de retrouver ses volets ouverts au petit matin ou de rentrer chez soi et de voir qu’ils sont restés fermés toute la journée 
Si vous avez une idée… Merci 
Les réponses sont ci-dessus.
Le plugin affiche ou exécute immédiatement ce qu’i reçoit.
Il y a un palliatif avec la répétition des commandes dans la config de l’équipement.
Bonjour,
« Les réponses sont ci-dessus. » : c’est à dire : « forcément un souci réseau
ou un souci de la config jeedom avec une charge importante. » ??
Je précise à nouveau que rien n’a bougé dans mon Jeedom ni dans mon réseau, juste la mise à jour du plugin.
J’ai ce soucis de latence qu’avec les devices Tuya et non Sonoff.
On dirait que les commandes ne sont exécutées que par cycle toutes les 5-6 secondes.
La répétition des commandes n’y fait rien.
Dommage avant ça répondait du tac au tac.
Merci de votre aide.
1 « J'aime »
manip à faire :
désactiver tous les périphériques wifilightV2 sauf celui à tester qui doit être un actionneur avec ON/OFF
ouvrier 3 onglets :
logs wifilightV2_cmd
logs wifilightV2_Tuya
commandes du périphérique à tester
effacer les 2 logs ci-dessus
faire 2 ou 4 on/off à la suite
poster ici les 2 logs chacun entourés par la balise </> pour obtenir ceci :
[2023-04-27 06:38:23][DEBUG] : Receive from:192.168.1.135 cmd:7 - Empty response
[2023-04-27 06:38:24][DEBUG] : Receive from:192.168.1.135 cmd:8 - {"dps":{"1":true},"type":"query","t":1682570303} type|query t|1682570303 1|1 - Read Json OK
[2023-04-27 06:38:24][DEBUG] : Update devices @192.168.1.135 channel:1
[2023-04-27 06:38:24][DEBUG] : Dps1|switch_1_GET:1
[2023-04-27 06:38:24][DEBUG] : Receive from Jeedom to Send cmd to device @192.168.1.135 channel:1
[2023-04-27 06:38:24][DEBUG] : No state to update
[2023-04-27 06:38:24][DEBUG] : Receive from:192.168.1.135 cmd:7 - Empty response
[2023-04-27 06:38:24][DEBUG] : Receive from:192.168.1.135 cmd:8 - {"dps":{"1":true},"type":"query","t":1682570303} type|query t|1682570303 1|1 - Read Json OK
[2023-04-27 06:38:24][DEBUG] : Update devices @192.168.1.135 channel:1
[2023-04-27 06:38:24][DEBUG] : Dps1|switch_1_GET:1
[2023-04-27 06:38:25][DEBUG] : Receive from Jeedom to Send cmd to device @192.168.1.135 channel:1
[2023-04-27 06:38:25][DEBUG] : No state to update
[2023-04-27 06:38:25][DEBUG] : Receive from:192.168.1.135 cmd:7 - Empty response
[2023-04-27 06:38:25][DEBUG] : Receive from:192.168.1.135 cmd:8 - {"dps":{"1":true},"type":"query","t":1682570304} type|query t|1682570304 1|1 - Read Json OK
[2023-04-27 06:38:25][DEBUG] : Update devices @192.168.1.135 channel:1
[2023-04-27 06:38:25][DEBUG] : Dps1|switch_1_GET:1
Bonsoir,
Je constate moi aussi ce phénomène (je ne sais pas trop depuis quand).
Il s’agit de prises que j’ai configurées il y a plusieurs années en mode manuel. J’utilisais surtout le plugin ces derniers temps pour récupérer leur état dans un dashboard, donc je ne m’en étais pas rendu compte jusqu’à présent.
J’ai remarqué qu’elles sont toutes de type « Tuya Smart Life fw 3.3 obsolète ».
Si j’essaie de les passer en « Tuya Smart Life fw 3.3 », elles ne répondent plus. Je suis obligé de revenir au type « obsolète » pour pouvoir les contrôler.
Je ferai la manip décrite pour obtenir un log d’exemple quand j’aurai un peu de temps.
Bonjour,
J’ai peut-être une piste intéressante.
J’ai 14 prises/interrupteurs gérés par le plugin. En voulant produire les logs demandés, j’ai désactivé 13 de ces prises. Et là, je me suis rendu compte que celle que j’avais conservée active pour les tests se mettait de nouveau à réagir instantanément à mes commandes ON ou OFF.
J’ai donc continué mes tests en réactivant 1 à 1 mes autres prises, et au bout de 4 ou 5 réactivations, j’ai de nouveau constaté les latences sur ma prise de référence.
Je n’ai finalement conservé que 3 prises actives, et je me suis rendu compte que j’avais systématiquement une latence si je tentais d’allumer ma prise « Sapin » alors que le log _tuya était en train d’afficher les lignes « << Update »
[2023-05-14 14:47:43]DEBUG : << Update state 2 of: Lumière bureau @192.168.1.13 class:Tuya_SW_V2
[2023-05-14 14:47:44]DEBUG : << Update state 2 of: Lumière piano @192.168.1.12 class:Tuya_SW_V2
[2023-05-14 14:47:45]DEBUG : << Update state 2 of: Sapin @192.168.1.20 class:Tuya_SW_V2
[2023-05-14 14:47:46]DEBUG : Receive from:192.168.1.13 cmd:a - {"dps":{"1":false,"11":0}} 1| 11|0 - Read Json OK
[2023-05-14 14:47:46]DEBUG : Update device @192.168.1.13 Monocanal:1
[2023-05-14 14:47:46]DEBUG : - On:0
[2023-05-14 14:47:46]DEBUG : Receive from:192.168.1.13 cmd:12 - Empty response
[2023-05-14 14:47:46]DEBUG : Receive from:192.168.1.12 cmd:a - {"dps":{"1":false,"11":0}} 1| 11|0 - Read Json OK
[2023-05-14 14:47:46]DEBUG : Update device @192.168.1.12 Monocanal:1
[2023-05-14 14:47:46]DEBUG : - On:0
[2023-05-14 14:47:46]DEBUG : Receive from:192.168.1.12 cmd:12 - Empty response
[2023-05-14 14:47:46]DEBUG : Receive from:192.168.1.20 cmd:a - {"devId":"xxxx","dps":{"1":false,"11":0}} devId|xxxx 1| 11|0 - Read Json OK
[2023-05-14 14:47:46]DEBUG : Update device @192.168.1.20 Monocanal:1
[2023-05-14 14:47:46]DEBUG : - On:0
[2023-05-14 14:47:46]DEBUG : Receive from Jeedom to Send cmd to device @192.168.1.20 channel:1
[2023-05-14 14:47:46]DEBUG : No state to update
[2023-05-14 14:47:46]DEBUG : Receive from:192.168.1.20 cmd:7 - Empty response
[2023-05-14 14:47:46]DEBUG : Receive from:192.168.1.20 cmd:8 - {"devId":"xxxx","dps":{"1":true,"11":0},"t":1684068464} devId|xxxx t|1684068464 1|1 11|0 - Read Json OK
[2023-05-14 14:47:46]DEBUG : Update device @192.168.1.20 Monocanal:1
[2023-05-14 14:47:46]DEBUG : - On:1
Dans mon scénario de test, j’ai donc essayé d’allumer la prise « Sapin » dès l’apparition de la première ligne « << Update » du log, que je regardais en temps réel. Elle ne s’est allumée qu’à 14:47:46, soit après les 3 lignes « << Update » qui durent 1 seconde chacune. J’imagine donc ce qu’il peut se produire si j’active les 14 objets…
Si j’essaie d’allumer la prise avant ou après l’affichage des lignes « << Update », elle réagit instantanément.
Voici le log _cmd correspondant au scenario testé
[2023-05-14 14:47:44]DEBUG : Send Cmd:[7b][22][67][77][49][64][22][3a][22][62][66][66][66][33][66][33][33][63][65][64][62][38][32][35][35][31][37][7a][71][31][63][22][2c][22][64][65][76][49][64][22][3a][22][62][66][66][66][33][66][33][33][63][65][64][62][38][32][35][35][31][37][7a][71][31][63][22][7d] to 192.168.1.13 ver:3.3 sti:1< crypt msgtos: 0 0 55 aa 0 0 0 0 0 0 0 a 0 0 0 58 9a 13 5a c 92 12 37 9c de 43 21 24 83 90 4c d 24 d0 34 54 12 f 2f f8 8b 67 e6 24 60 2b 37 b1 e5 48 9d d7 56 b8 22 a7 41 c7 a2 5e fc ff f3 2 8c 77 b2 17 44 b5 66 6b 8d 18 42 fc e3 4a 39 50 be 40 7b a6 a3 c2 40 7 b7 f b8 27 de 5b 7a 31 e7 7c 86 f1 0 0 aa 55 sok Con OK
[2023-05-14 14:47:44]DEBUG : Send Cmd:[7b][22][64][70][49][64][22][3a][5b][5d][7d] to 192.168.1.13 ver:3.3 sti:1< crypt msgtos: 0 0 55 aa 0 0 0 0 0 0 0 12 0 0 0 18 66 92 8e af 41 51 9d 1e 83 e7 9b 33 1c 6 e 89 d9 5c c7 28 0 0 aa 55 sok Con OK
[2023-05-14 14:47:44]DEBUG : Send Cmd:[7b][22][74][22][3a][22][31][36][38][34][30][36][38][34][36][34][22][2c][22][64][65][76][49][64][22][3a][22][38][38][35][30][32][34][33][34][64][63][34][66][32][32][35][61][38][34][30][33][22][2c][22][64][70][73][22][3a][7b][22][31][22][3a][74][72][75][65][2c][22][32][22][3a][30][7d][2c][22][75][69][64][22][3a][22][22][7d] to 127.0.0.1 - channel:1 - crypt 64enc sok con - Try:127.0.0.1 6900 Con OK
[2023-05-14 14:47:45]DEBUG : Send Cmd:[7b][22][67][77][49][64][22][3a][22][62][66][65][32][65][63][34][33][39][66][37][32][30][35][38][34][31][31][61][37][34][6c][22][2c][22][64][65][76][49][64][22][3a][22][62][66][65][32][65][63][34][33][39][66][37][32][30][35][38][34][31][31][61][37][34][6c][22][7d] to 192.168.1.12 ver:3.3 sti:1< crypt msgtos: 0 0 55 aa 0 0 0 0 0 0 0 a 0 0 0 58 b5 96 e0 6b 5b 64 ab 35 dd 5e 3b a0 2c e9 4e 6c 7 bb 27 4d fa 8f e5 8a 5d c2 3d ce 7f a6 6a 25 9 aa 7c d2 fe 62 cb f8 60 97 95 f4 78 1b 4e 5c 1f 9f bb 1e bb 90 d9 6e f3 54 e4 90 38 45 52 f6 b4 b5 98 70 ad ae a1 d0 71 ae 1b 46 4f 99 6f e2 b1 b5 4c c6 0 0 aa 55 sok Con OK
[2023-05-14 14:47:45]DEBUG : Send Cmd:[7b][22][64][70][49][64][22][3a][5b][5d][7d] to 192.168.1.12 ver:3.3 sti:1< crypt msgtos: 0 0 55 aa 0 0 0 0 0 0 0 12 0 0 0 18 5b b0 52 7f 64 5f d7 6e 51 a6 23 bf ee 21 da 9b ae b4 7 c6 0 0 aa 55 sok Con OK
[2023-05-14 14:47:46]DEBUG : Send Cmd:[7b][22][67][77][49][64][22][3a][22][38][38][35][30][32][34][33][34][64][63][34][66][32][32][35][61][38][34][30][33][22][2c][22][64][65][76][49][64][22][3a][22][38][38][35][30][32][34][33][34][64][63][34][66][32][32][35][61][38][34][30][33][22][7d] to 192.168.1.20 ver:3.3 sti:1< crypt msgtos: 0 0 55 aa 0 0 0 0 0 0 0 a 0 0 0 48 e7 9b 29 8a 40 44 90 cc f 13 82 db e 7f 12 16 ee c7 90 14 1e 44 a2 5b e1 8e 67 c8 c 41 ef 59 c5 a3 8a 22 74 ad 8e 36 5b 28 5e 56 dd a6 86 ae aa c8 d2 da 48 1e 48 22 f4 d6 1a 74 14 53 e7 eb dd d3 a7 12 0 0 aa 55 sok Con OK
[2023-05-14 14:47:46]DEBUG : Send Cmd:[7b][22][64][70][49][64][22][3a][5b][5d][7d] to 192.168.1.20 ver:3.3 sti:1< crypt msgtos: 0 0 55 aa 0 0 0 0 0 0 0 12 0 0 0 18 24 46 be f0 ba b4 9a f1 8e 1d 83 a1 52 10 c4 c5 e9 b5 95 64 0 0 aa 55 sok Con OK
[2023-05-14 14:47:46]DEBUG : 3.3 decode
[2023-05-14 14:47:46]DEBUG : 3.3 decode
[2023-05-14 14:47:46]DEBUG : 3.3 decode
[2023-05-14 14:47:46]DEBUG : 3.3 decode
[2023-05-14 14:47:46]DEBUG : 3.3 decode
[2023-05-14 14:47:46]DEBUG : Send Cmd:[41][41][42][56][71][67][41][41][41][41][41][41][41][41][41][48][41][41][41][41][64][7a][4d][75][4d][77][41][41][41][41][41][41][41][41][41][41][41][41][41][41][41][48][75][62][6c][31][56][4d][47][65][46][7a][6a][6b][4d][4e][36][48][53][59][75][31][4f][74][70][68][38][46][63][41][4d][37][64][51][6b][45][58][54][33][4f][38][71][78][6c][37][73][7a][61][6d][42][41][57][4b][30][31][6b][30][71][44][75][78][33][79][44][57][41][6b][64][61][46][5a][77][66][61][6f][79][58][55][67][43][47][55][6f][53][4c][71][6c][4e][2f][68][33][63][6c][6f][35][76][70][55][48][49][79][42][5a][4e][6f][69][53][69][79][65][6a][37][46][68][4f][34][38][59][53][63][6a][2f][2b][50][34][71][35][4b][79][4d][75][31][48][6e][6b][41][41][4b][70][56] to 192.168.1.20 ver:3.3 sti:< 64dec msgtos: 0 0 55 aa 0 0 0 0 0 0 0 7 0 0 0 77 33 2e 33 0 0 0 0 0 0 0 0 0 0 0 0 7b 9b 97 55 4c 19 e1 73 8e 43 d e8 74 98 bb 53 ad a6 1f 5 70 3 3b 75 9 4 5d 3d ce f2 ac 65 ee cc da 98 10 16 2b 4d 64 d2 a0 ee c7 7c 83 58 9 1d 68 56 70 7d aa 32 5d 48 2 19 4a 12 2e a9 4d fe 1d dc 96 8e 6f a5 41 c8 c8 16 4d a2 24 a2 c9 e8 fb 16 13 b8 f1 84 9c 8f ff 8f e2 ae 4a c8 cb b5 1e 79 0 0 aa 55 sok Con OK
[2023-05-14 14:47:46]DEBUG : 3.3 decode
[2023-05-14 14:47:46]DEBUG : 3.3 decode
J’ai ensuite réactivé mes 14 prises, et le log est constamment en cours de " << Update". Dès qu’une série de 14 lignes est passée, ma commande est prise en compte, et une nouvelle série de 14 lignes démarre, après seulement 1 seconde entre les 2 séries.
Donc si j’exécute une commande en fin de série, je n’attends que 1 ou 2 secondes. Si j’exécute en début de série, j’en ai pour 14 secondes.
Cordialement,
Philippe
Désactiver : interrogation de l’état
Activer : pas de MAJ forcée de l’état
sauf pour les prises avec conso qui sont utilisées.
J’ai seulement 2 prises avec conso. En appliquant ce changement sur les autres, ça règle le pb me concernant.
Merci