j’ai récemment fait l’acquisition de capteurs d’ouverture.
il s’agit de capteurs wifi basse conso, qui se déconnectent du réseau entre les utilisations.
toute la partie préalable sur Tuya IoT Platform est bien faite (ils sont visible et je vois bien leurs etats)
l’inclusion auto dans jeedom ne fonctionne pas, j’ai donc créé un capteur manuellement et c’est la que ca se complique …
j’ai imposé une adresse IP, j’ai creé une commande « info » avec le bon dps (1 dans mon cas).
lorsque j’ouvre mes portes je vois bien (via wireshark) les paquets partir de mon capteur partir en UDP
mais rien n’est n’est récupéré dans Wifilightv2 :
[2023-11-04 10:32:46]DEBUG : >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Search for Tuya/Yeelight devices - V1.95 <<<<<<<<<<<<<<<<<<<<<<<<<<<<<
[2023-11-04 10:32:46]DEBUG : ** doorsensor - TuyaCustom_V2 @192.168.1.59 - cha:1 **
[2023-11-04 10:32:46]DEBUG : Connection impossible. Err=115 : Operation now in progress
[2023-11-04 10:32:46]DEBUG : >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> End <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
[2023-11-04 10:33:17]DEBUG : >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Search for Tuya/Yeelight devices - V1.95 <<<<<<<<<<<<<<<<<<<<<<<<<<<<<
[2023-11-04 10:33:17]DEBUG : ** doorsensor - TuyaCustom_V2 @192.168.1.59 - cha:1 **
[2023-11-04 10:33:17]DEBUG : Connection impossible. Err=115 : Operation now in progress
[2023-11-04 10:33:17]DEBUG : >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> End <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
les rares fois ou je récupère des choses dans Wifilightv2 c’est quand je fais plusieurs ouvertures/fermeture de porte à la suite pour garder le capteur actif sur le réseau.
merci pour votre retour. j’ai biensur lu assidument la doc avant de poser ma question, mais re-faisons le ensemble :
## 18.1) Inclusion des périphériques Tuya depuis le cloud
Suivre d’abord ce tuto et aller dans l’onglet “Overview” pour récupérer les deux paramètres : Access ID et Access Secret. Fiftard : Fait
Tuya change souvent son interface, il faut adapter le tuto
La durée du plan gratuit est limitée, il faut chercher et trouver pour le renouveler Fiftard : ce n’est pas le probleme
Dans la configuration du plugin, renseigner ces 2 paramètres dans la partie Tuya et sauvegarder. Ensuite, sélectionner : Tuya Passer en inclusion. Les périphériques sont créés automatiquement. Fiftard : Fait, sans résultat
### Notes and limitations
les périphériques Wifi et donc non Zigbee qui sont sur pile sont purement cloud (capteurs de fermeture, de porte, de température par exemple) seront intégrés mais le plugin ne pourra pas y accéder Fiftard : c’est manifestement mon cas mais l’intégration ne se fait pas
si l’adresse IP est à 0.0.0.0 c’est que Jeedom n’a pas accès au périphérique, c’est probablement la configuration réseau à reconsidérer. Noter que l’adresse IP 0.0.0.0 est aussi affectée aux périphériques de firmware <3.3. et aux périphériques non compatibles. Afin de tester cette accessibilité, voir ici, si le périphérique ne l’est pas, c’est qu’il n’est pas compatible ou qu’une configuration réseau empêche le dialogue entre lui et la box Jeedom. Fiftard : ping -c 2 192.168.1.59 ne donne rien
certaines passerelles Tuya/Zigbee ne sont pas compatibles, se renseigner sur le forum Jeedom. Fiftard : pas mon cas
les périphériques avec des informations codées (partie actionneur des alarmes en général) ne sont pas gérés Fiftard : pas mon cas
les périphériques ayant des informations non standard (peut éventuellement être résolu avec un bloc code dans un scénario) ne sont pas gérés Fiftard : pas mon cas
le plugin ne décode pas les commandes complexes et met alors dans paramètres l’information brute provenant du cloud Tuya Fiftard : pas mon cas
le cloud Tuya peut ne pas fournir toutes les commandes du périphérique, voir ici pour essayer de résoudre le problème Fiftard : pas mon cas
les périphériques multicanaux (multiprises, interrupteurs multiples) inclus par le plugin via le cloud Tuya sont regroupés dans le même périphérique Fiftard : pas mon cas
si un périphérique de même devId existe déjà, l’inclusion ne se fera pas. Fiftard : pas mon cas
les couleurs suivant les 3 formats connus sont créées ainsi que les commandes saturation et intensité liées Fiftard : pas mon cas
la suppression d’une commande créée par le plugin via le cloud Tuya ne peut plus être recréée Fiftard : pas mon cas
le min et le max d’une valeur numérique sont remontés depuis le cloud. Selon les besoins, modifier les paramètres #slider# et #value# ainsi que le min et max Jeedom. Cette partie est à améliorer avec les retours des utilisateurs. Fiftard : pas mon cas
### Astuces
si l’adresse IP n’a pas été trouvée parce que le périphérique n’est pas connecté, lui donner l’adresse : 0.0.0.0 , le connecter et relancer la procédure d’inclusion. Fiftard : j’ai essayé mais sans résultat
si la localkey d’un périphérique a changé, modifier le devId ou le nodeId du périphérique (en mettant par exemple @ à la fin), refaire l’inclusion et recopier le devId ou le nodeId et la nouvelle localkey dans l’ancien périphérique. Enfin, supprimer le périphérique créé par inclusion. Fiftard : pas mon cas
si la procédure automatique dysfonctionne ou si des commandes ne sont pas fournies par le cloud Tuya, passer en mode apprentissage du périphérique et agir uniquement sur les boutons de l’appli Tuya Smartlife en correspondance. Si d’autres boutons sont utilisés, le plugin créera des doublons des commandes créées via le cloud Tuya. Mais attention, cette documentation est très technique et réservée à un public averti, ne l’utilisez pas en mode panique alors que vous n’avez pas les connaissances pour comprendre son contenu. Fiftard : j’arrive bien generer des requet vers le capteur depuis le cloud tuya
de manière générale, les commandes peuvent être créées manuellement ou en mode apprentissage Fiftard : OK
c’est pour ces raisons que je me suis orienté vers une intégration manuelle (qui fonctionne mal) dois-je en conclure que mon produit n’est pas compatible ? ou ai-je loupé une étape de la doc ?
Non, je souhaite juste comprendre pourquoi le plugin y a accès parfois mais pas à chaque requête. En effet avec la bonne commande et le bon dps, je récupère bien l’état de mon capteur via le plugin. Mais seulement en cas de burst de messages, pas pour les requête unitaires.
J’ai eu le même comportement sur un détecteur d’inondation. Voici ce que je pense qu’il se passe (sans certitude). Le plugin wifilightV2 interroge l’équipement toute les X secondes. Si l’appareil n’est pas connecté au WIFI à ce moment là, l’appareil ne répond pas et on ignore dès lors son état. Pour économiser l’énergie, les capteurs ne se connectent que très peu souvent. Il arrive donc que, suite à un événement, le capteur se connecte au Wifi, envoie son état et puis se déconnecte juste après. Cela dure parfois quelques secondes. Si le plugin n’a pas eu la chance d’interroger le capteur juste à ce moment là, il n’aura pas l’état.