Non prise en compte des commandes OnOff sur module switch wifi tuya Aubess aliExpress avec phase et neutre

Bonjour à tous
Je tourne en rond deouis quelques jours sur l’intégration de module switch OnOff wifi marque Aubess(aliexpress).
info de base:
J’ai suivi le tuto( tres bien fait :+1: )pour intégrer des modules sous tuya via un compte tuyaIOT
Résultat
Une prise secteur avec remonté conso tout est OK
2 modules switch LN KO
Le transfert des paramètres des 3 devices a été fait par remontée automatique du compte tuya IOT.
Les @IP étaient toutes initialement à 0.0.0.0
J’ai donc retrouver les @ip en cherchant l@Mac des devices et saisi manuellement.
Pour les 2 switch le paramètre « connecté » bagotte entre -1 (connecté) et -3. Aucune commande OnOff n’est reconnue et le parametre etat ne bouge pas.
A noter que les 3 devices fonctionnent parfaitement sur l’appli tuya dont je me déconnecte pour les essais.
Extrait du log WifilightV2_tuya

[2022-12-23 18:42:30][DEBUG] : >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Search for Tuya/Yeelight devices - V1.95 <<<<<<<<<<<<<<<<<<<<<<<<<<<<<
[2022-12-23 18:42:30][DEBUG] : ** tuyaPrise01 - TuyaCustom_V2 @192.168.1.94 - cha:1 **
[2022-12-23 18:42:30][DEBUG] :       New device OK
[2022-12-23 18:42:30][DEBUG] : ** tuyaPrise02 - TuyaCustom_V2 @192.168.1.92 - cha:1 **
[2022-12-23 18:42:30][DEBUG] :      No connected device
[2022-12-23 18:42:30][DEBUG] : ** tuyaPriseEM01 - TuyaCustom_V2 @192.168.1.84 - cha:1 **
[2022-12-23 18:42:30][DEBUG] :      OK
[2022-12-23 18:42:30][DEBUG] : >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>       End       <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
[2022-12-23 18:42:30][DEBUG] : << Update state of: tuyaPrise01 @192.168.1.94
[2022-12-23 18:42:30][DEBUG] :     

Par ailleurs j’ai fait la manip vu dans le forum genre
ping -c 2 192.168.94
Le retour est ok avec 0% de perte sur les 2 trames.
pour info lors du test le 92 n’était pas connecté au secteur.
Pour le 84 tout va bien.
Lorsque le 92 est branché sur secteur on a le même comportement que le 94.
Une idée?
Merci d’avance de votre aide.

Les Aubess sont probablement purement cloud donc non compatibles.

Éventuellement modifier la version mais peu probable.

merci pour la réponse.
La prise avec monitoring watt est également de la marque Aubess et fonctionne parfaitement ce qui permet encore un peu d’espoir.
De quelle version parle t on?
Les trames de commande et leur syntaxe parviennent t’elle du cloud lors du transfert ou sont elle pré programmé dans le plugin?

je ne sais pas de quelle version il s’agissait. Je suis donc passé en tuya smart life version compatible V4 pour voir.
J’ai désormais un log qui me semble plus sympa bien que je ne commande toujours rien.

[2022-12-23 22:00:56]DEBUG : ** tuyaPriseEM01 - TuyaCustom_V2 @192.168.1.84 - cha:1 **
[2022-12-23 22:00:56]DEBUG :      OK
[2022-12-23 22:00:56]DEBUG : ** tuyaPrise01 - TuyaCustom_V3 @192.168.1.94 - cha:1 **
[2022-12-23 22:00:56]DEBUG :      OK
[2022-12-23 22:00:56]DEBUG : >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>       End       <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

visiblement une réponse du module 94 existe mais que je ne sais pas interpréter.
Une idée?

Bien , pour ceux qui seraient dans la même situation la solution que j’ai trouvée est la suivante sans savoir si c’est la meilleure mais elle a le gros intérêt de fonctionner.
Passer en V4 (pas sur que ce soit obligatoire) je retesterai sur les autres modules.
Ajouter un On/Off
Changer le DPS des boutons et de l’état par 1 et mettre paramètre à true ou false suivant le bouton. (pas 0 ou 1)
A+

finalement faut passer en V4 :partying_face:

OK
bizarre que le plugin n’ai pas trouvé tout cela tout seul
afin de vraiment aider les autres, peux tu :

  • m’assurer que les dépendances du plugin sont OK
  • dans ce cas, il faudrait refaire une inclusion via le cloud u périphérique qui pose souci. Pour cela, changer son devId en mettant@ la fin. effacer le log _inc, faire l’inclusion, le plugin retrouvera ce périphérique, me donner le log _inc. effacer le nouveau, enlever @ de l’ancien.
  • Ensuite, en utilisant ce qui est écrit ici :
    https://bcaro.github.io/wifilightV2-doc/fr_FR/#tocAnchor-1-45-1
    paragraphe : participer à l’amélioration de cette partie
    me donner le fichier de config du cloud Tuya :

Ok je regarderai ca à l’occasion.
Les dépendances étaient bien sur ok.
A+

Au fait comment souhaites tu recevoir les info, dans ce fil de discussion?

En général c’est par la poste mais pour les fêtes @bernardfr.caron accepte de répondre sur ce fil de discussion
Plus sérieusement, Il faudrait enlever solution à votre post afin que celui-ci ne soit pas fermé :wink:

Mise en place d’un@ sur devid onglet équipement du module concerné.
image

Effacement du log ok
inclusion à partir de l’icone
image
message reçu en fin d’inclusion « Aucun nouveau périphérique Tuya trouvé »
Log inc

Pas de nouvel équipement créé sur Mes Equipements Wifi il n’y a donc rien à effacer.
Pas sur que ce soit le résultat que tu attendais pour cette partie.
Il semble que la modif devid ne soit pas suffisante pour permettre de créer un nouvel équipement.
Peut être vaut il mieux supprimer carrément l’équipement?
Dis moi.

le @ était à mettre sur la localkey.
Mais il y a dès le début une erreur arp-scan due aux dépendances KO
Peux tu réinstaller les dépendances et me donner les logs qui vont avec je crois que c’est avec _package mais tu devrais trouver
Ensuite, si KO on va les installer à la main :

me faire copie d’écran si KO

Tu as une atlas ou une config DIY ?

ok j’avais bien vu qu’il y avait un écart entre ce qui se nomme devId dans le template de saisie equipement et ce qui s’appelle devId dans le log. Du coup j’avais essayé @ sur devId puis sur localkey puis sur les 2 puis je me suis dit si ca se trouve il y a une troncature sur le nb de caractère de la chaine donc j’avais carrément modifié la dernière lettre du champ…
Conf DIY OrangePI3 LTS fonctionnant sur l’emmc. connecté en ethernet sur réseau 192.x.1.xx ( il existe un deuxième réseau en 192.x.2.xx mais la domotique et les modules sont sur le premier) Le wifi de opi est actif et possède sa propre @ différente de l’@ ethernet mais sur le même réseau.
Dongle RFP1000 et ConbeeII
image
Relance dépendance faite
log
wifilightV2_update.txt (2,9 Ko)
Il y a effectivement des trucs qui n’ont l’air nominaux.
Pour le reste je regarderai plus tard.
Pour être sur de l’intérêt de continuer. Pour ma part j’ai une séquence de mise en oeuvre fonctionnelle (grace à ta proposition de chgt de version)
Nouvelle séquence faite sur un autre module ce matin.
.Intégration auto
.renseignement de IP + passage en V4 sauvegarde fonctionnt ko
.suppression de l’équipement
.integration auto
.Le plugin visiblement trouve l’équipement le met direct en V4 et avec son IP et fonctionne (mémo des paramètres de la 1ere intégration?) du coup pas besoin d’ajouter de bouton comme j’avais fait la première fois.
Donc de mon point de vue le sujet est clos (pour l’instant peut être)
A contrario si le cas de figure t’intéresse je veux bien continuer mais je ne souhaite pas mettre toutes ces data perso sur ce forum, peut on faire ça autrement si tu souhaites continuer?
A+

oui, le souci était les dépendances. Tu dis l’avoir fait mais peut être qu’après tu as fait une MAJ système. Dans ce cas et c’est mon expérience, jeedom pense que les dépendances sont OK alors qu’elles ne le sont pas. Par exemple si je fais une fresh instal d’un jeedom + récup de sauvegarde, les dépendances sont OK et récentes alors qu’elles ne sont pas présentes. Il faut refaire la manip par exemple pour moi sur zwave, mysencor (et c’est compliqué) openvpn et wifilightV2.
Je pense d’ailleurs que c’est un vrai souci Jeedom.

Ce sujet a été automatiquement fermé après 24 heures suivant le dernier commentaire. Aucune réponse n’est permise dorénavant.