J’ai relu la documentation et je ne trouve pas de réponse à mon intérogration.
J’ai renommé 2 de mes prises wifi directement sur smartlife. J’ai voulu mettre à jour les noms également sur wifilight et mon virtuel qui est utilisé pour piloter ma prise.
Depuis que j’ai réalisé ce renommage, les 2 prises répondent soient pas du tout ou de manière aléatoire.
J’ai bien vérifié sur le site Tuya Dev Platform, le deviceID et la local_key n’a pas changé. Et l’adresse IP est tjs identique, pourquoi ce changement de fonctionnement ?
Il me semblait avoir lu dans la doc que si un périphérique avait le même devId il ne le recréait pas en lançant le mode « inclusion » (même si le nom était un peu différent, hors je ne constate pas ce comportement) ?
Idem j’ai rajouté une nouvelle prise, des fois le On et Off fonctionne sans soucis et d’autres fois, il faut cliquer 4 ou 5 fois pour que cela fonctionne alors que depuis smartlife c’est instantané et à chaque fois…
Merci
PS : je n’ai pas touché au sous-type qui est resté sur « personnalisé »
Citation :
Depuis que j’ai réalisé ce renommage, les 2 prises répondent soient pas du tout ou de manière aléatoire.
Il n’y a probablement pas de cause à effet, soit ça arrivait avant soit un évènement concomitant est survenu
Citation :
J’ai bien vérifié sur le site Tuya Dev Platform, le deviceID et la local_key n’a pas changé. Et l’adresse IP est tjs identique, pourquoi ce changement de fonctionnement ?
Le changement de localkey aurait bloqué toute communication, le deviceID ne change jamais
Citation : Il me semblait avoir lu dans la doc que si un périphérique avait le même deviceID il ne le recréait pas en lançant le mode « inclusion » (même si le nom était un peu différent, hors je ne constate pas ce comportement) ?
Quel comportement est constaté ? une duplication d’un périphérique avec le même deviceID ?
Citation : Idem j’ai rajouté une nouvelle prise, des fois le On et Off fonctionne sans soucis et d’autres fois, il faut cliquer 4 ou 5 fois pour que cela fonctionne alors que depuis smartlife c’est instantané et à chaque fois…
Donc ce n’est pas le renommage mais quelque chose qui est survenu sur la communication périphérique/jeedom
Merci pour tes réponses, j’essai de comprendre mais très franchement je sèche voici des erreurs dans les logs sur une prise par exemple :
2026-05-10 16:42:40] DEBUG Send to 192.168.0.220 ver:3.3 sti:1< crypt sok Con OK
[2026-05-10 16:42:53] DEBUG Send to 192.168.0.220 ver:3.3 sti:1< crypt sok Con OK
[2026-05-10 16:43:06] DEBUG Send to 192.168.0.220 ver:3.3 sti:1< crypt sok Con OK
[2026-05-10 16:43:19] DEBUG Send to 192.168.0.220 ver:3.3 sti:1< crypt sok Con OK
[2026-05-10 19:05:10] DEBUG Send to 192.168.0.220 ver:3.5 sti:1< crypt sok ConOK rec l:0 error:Connection reset by peer
[2026-05-10 19:05:43] DEBUG Send to 192.168.0.220 ver:3.5 sti:1< crypt sok ConOK rec l:0 error:Connection reset by peer
[2026-05-10 19:06:15] DEBUG Send to 192.168.0.220 ver:3.5 sti:1< crypt sok ConOK rec l:0 error:Connection reset by peer
[2026-05-10 19:06:35] DEBUG Send to 192.168.0.220 ver:3.5 sti:1< crypt sok ConOK rec l:0 error:Connection reset by peer
[2026-05-10 19:07:08] DEBUG Send to 192.168.0.220 ver:3.5 sti:1< crypt sok ConOK rec l:0 error:Connection reset by peer
[2026-05-10 19:07:40] DEBUG Send to 192.168.0.220 ver:3.5 sti:1< crypt sok ConOK rec l:0 error:Connection reset by peer
[2026-05-10 19:08:12] DEBUG Send to 192.168.0.220 ver:3.5 sti:1< crypt sok ConOK rec l:0 no response
[2026-05-10 19:08:44] DEBUG Send to 192.168.0.220 ver:3.5 sti:1< crypt sok ConOK rec l:0 error:Connection reset by peer
Quel comportement est constaté ? une duplication d’un périphérique avec le même deviceID ?
Ce que j’ai constaté à chaque fois est que si j’ai nom différent entre smartlife et dans wifilight, il va créer l’objet, je pensais qu’il se basait uniquement sur le DeviceID pour ne pas recréer l’objet si déjà présent. (du coup je supprime à chaque fois le périphérique dupliqué)
Exemple ici de ma nouvelle prise qui fonctionne puis ne fonctionne plus d’un coup (et cela fonctionne à tous les coups sur smartlife, donc pas de soucis sur le réseau wifi) : et dans Santé la prise est rouge alors que cela ping bien
[2026-05-10 19:07:30] DEBUG Send to 192.168.0.224 ver:3.5 sti:1< crypt sok Con OK
[2026-05-10 19:07:43] DEBUG Send to 192.168.0.224 ver:3.5 sti:1< crypt sok Con OK
[2026-05-10 19:07:56] DEBUG Send to 192.168.0.224 ver:3.5 sti:1< crypt sok Con OK
[2026-05-10 19:08:07] DEBUG Send to 192.168.0.224 ver:3.5 sti:< 64dec crypt sok Con OK
[2026-05-10 19:08:09] DEBUG Send to 192.168.0.224 ver:3.5 sti:1< crypt sok Con OK
[2026-05-10 19:08:22] DEBUG Send to 192.168.0.224 ver:3.5 sti:1< crypt sok Con OK
[2026-05-10 19:08:35] DEBUG Send to 192.168.0.224 ver:3.5 sti:1< crypt sok Con OK
[2026-05-10 19:08:48] DEBUG Send to 192.168.0.224 ver:3.5 sti:1< crypt sok Con OK
[2026-05-10 19:09:01] DEBUG Send to 192.168.0.224 ver:3.5 sti:1< crypt sok Con OK
[2026-05-10 19:09:14] DEBUG Send to 192.168.0.224 ver:3.5 sti:1< crypt sok Con OK
[2026-05-10 19:09:27] DEBUG Send to 192.168.0.224 ver:3.5 sti:1< crypt sok Con OK
[2026-05-10 19:09:40] DEBUG Send to 192.168.0.224 ver:3.5 sti:1< crypt sok Con OK
[2026-05-10 19:09:53] DEBUG Send to 192.168.0.224 ver:3.5 sti:1< crypt sok Con OK
[2026-05-10 19:10:06] DEBUG Send to 192.168.0.224 ver:3.5 sti:1< crypt sok Con OK
[2026-05-10 19:10:20] DEBUG Send to 192.168.0.224 ver:3.5 sti:1< crypt sok Con OK
[2026-05-10 19:10:33] DEBUG Send to 192.168.0.224 ver:3.5 sti:1< crypt sok Con OK
[2026-05-10 19:10:46] DEBUG Send to 192.168.0.224 ver:3.5 sti:1< crypt sok Con OK
[2026-05-10 19:11:56] DEBUG Create ip:192.168.0.224 / 3.4-3.5 Create socket_connect failed: Operation already in progress
[2026-05-10 19:13:40] DEBUG Create ip:192.168.0.224 / 3.4-3.5 Create socket_connect failed: Operation already in progress
[2026-05-10 19:14:12] DEBUG Create ip:192.168.0.224 / 3.4-3.5 Create socket_connect failed: Operation already in progress
[2026-05-10 19:14:44] DEBUG Create ip:192.168.0.224 / 3.4-3.5 Create socket_connect failed: Operation already in progress
[2026-05-10 19:15:16] DEBUG Create ip:192.168.0.224 / 3.4-3.5 Create socket_connect failed: Operation already in progress
[2026-05-10 19:15:48] DEBUG Create ip:192.168.0.224 / 3.4-3.5 Create socket_connect failed: Operation already in progress
[2026-05-10 19:16:20] DEBUG Create ip:192.168.0.224 / 3.4-3.5 Create socket_connect failed: Operation already in progress
[2026-05-10 19:16:52] DEBUG Create ip:192.168.0.224 / 3.4-3.5 Create socket_connect failed: Operation already in progress
[2026-05-10 19:17:24] DEBUG Send to 192.168.0.224 ver:3.5 sti:1< crypt sok ConOK rec l:102 crypt ret: 1d1fcedfa37698af
[2026-05-10 19:17:24] DEBUG Send to 192.168.0.224 ver:3.5 sti:1< crypt sok ConOK rec l:0 no response
[2026-05-10 19:17:24] DEBUG Send to 192.168.0.224 ver:3.5 sti:1< crypt sok Con OK
[2026-05-10 19:17:24] DEBUG Send to 192.168.0.224 ver:3.5 sti:1< crypt sok Con OK
[2026-05-10 19:17:37] DEBUG Send to 192.168.0.224 ver:3.5 sti:1< crypt sok Con OK
[2026-05-10 19:17:50] DEBUG Send to 192.168.0.224 ver:3.5 sti:1< crypt sok Con OK
[2026-05-10 19:18:03] DEBUG Send to 192.168.0.224 ver:3.5 sti:1< crypt sok Con OK
[2026-05-10 19:18:16] DEBUG Send to 192.168.0.224 ver:3.5 sti:1< crypt sok Con OK
[2026-05-10 19:18:26] DEBUG Send to 192.168.0.224 ver:3.5 sti:< 64dec crypt sok Con OK
[2026-05-10 19:18:26] DEBUG Send to 192.168.0.224 ver:3.5 sti:< 64dec crypt sok Con OK
[2026-05-10 19:18:28] DEBUG Send to 192.168.0.224 ver:3.5 sti:< 64dec crypt sok Con OK
[2026-05-10 19:18:28] DEBUG Send to 192.168.0.224 ver:3.5 sti:< 64dec crypt sok Con OK
[2026-05-10 19:18:29] DEBUG Send to 192.168.0.224 ver:3.5 sti:1< crypt sok Con OK
Le nom du périphérique du cloud Tuya n’est pris que lors de la création d’un périphérique dans le plugin et seulement pour un nouveau deviceId non présent dans le plugin. Je viens de tester, pour créer un nouveau périphérique, le seul moyen est qu’un périphérique de même deviceId dans le plugin n’existe pas. Ou dans l’autre sens et comme la doc le précise : si un périphérique de même deviceId se trouve dans le plugin et dans le cloud Tuya, il ne sera pas recréé.
Mes prises après avoir laissé un temps (y a t’il un délais de mise à jour avec le cloud …) semblent refonctionner normalement, pour l’instant je ne touche plus
Le nom du périphérique du cloud Tuya n’est pris que lors de la création d’un périphérique dans le plugin et seulement pour un nouveau deviceId non présent dans le plugin. Je viens de tester, pour créer un nouveau périphérique, le seul moyen est qu’un périphérique de même deviceId dans le plugin n’existe pas. Ou dans l’autre sens et comme la doc le précise : si un périphérique de même deviceId se trouve dans le plugin et dans le cloud Tuya, il ne sera pas recréé.
J’ai refais le test, j’ai 6 anciennes prise connectées Tuya. Lorsque je lance l’inclusion il en remonte 3. Celles-ci sont déjà présentes juste le nom qui est un peu différent mais avec le même DeviceId (et localkey) que celles déjà présentes.
