Bonjour à tous,
Je teste actuellement la cle conbeeII + plugin deconz pour voir si je transfert des choses de RFP1000 433mHerz vers zigbee avec les avantages de retours d’info et de maillage que vous connaissez.
Pour l’instant instal cle ok plugin ok + 2 modules switch avec neutre ok
Mais je me casse les dents depuis plusieurs jours sur l’intégration de 2 modules sans neutre.
Pas vu de cas similaire dans le forum ni dans la doc.
Config de test: le module sans neutre est équipé d’un lampe LED pour fermer le circuit et donc alimenter le module. Le module possède un switch de commutation d’état + appairage quand maintien > 7sec. Le module clignote bien mais s’éteint rapidement comme si l’appairage était ok.
Les tests faits
Cle sur box jeedom
Test 1: multiple essais d’intégration « mode inclusion » sous plugin deconz avec la même méthode que pour les modules LN → ko
Test 2: tentatives d’intégration sous Phoscon / Firefox par @ipJeedom:8484 → ko
Clé sur PC
Test 3: intégration ok sous deconz windows mais après plusieurs tentatives. Il a notamment fallu que je créé un DDF type « On/Off light » manuellement sous deconz.
Test 4: passage sous Phoscon par l’appli deconz (a noter port 8080) tant que l’intégration n’était pas ok sous deconz, pas de possibilité d’intégrer les équipement sous phoscon. A contrarion dès que l’intégration a été faite sous deconz, phoscon reconnaissait l’équipement.
Retour sur jeedom
Test 5: reteste d’intégration . on ne sait jamais sur un malentendu… → ko
Test 6: Création d’un équipement dans le plugIn manuellement avec @ mac récupérée du test 2 -->ko
Config: Jeedom DIY 4.3.12
OrangePI3 LTS Jeedom sur emmc
Instal deconz en local
cle RFP1000 + ConbeeII sur rallonge 50cm éloignée
info complémentaire
lors de l’envoi de commande a partir du module créé manuellement on voit un probleme sur le log
Erreur exécution de la commande [Essai][ZigL01][Off 01] : Erreur lors de la requete : 192.168.1.xx:8484/api/2FF____935C/lights//state(PUT), data : {« off »:« 0 »} erreur : 3 => resource, /lights/state, not available
Sur une commande ok il y a une valeur après lights/ la il n’y en a pas. Il s’agirait d’un ID pour le type light. Les 2 qui fonctionnent sont à 1 et 2 comme dans deconz sous window. Si c’est bien le cas il faudrait qu’il y ait 3.
Il s’agit de modules achetés sur AliExpress. Marque Girier
J’avais pris cette « Marque » car les modules Girier avec neutre se sont bien intégrés et sont fonctionnels.
Cf INCLUSION relais zigbee GIRIER
Les girier LN qui fonctionnent bien sont répertoriés Ref: TS0001 Fab: Tuya par contre les L n’y sont pas. Sous deconz Windows ils ont la ref TS0011 ce sont des EndDevice devant fonctionner sous tuya également.
Chez tuya le modol id ne veut rien dire (la marque, le descriptif, et la désignation non plus), il doit y avoir 40/50 appareils différents avec le model id TS0011.
Il faut chercher le manufacture name.
Si tu as pu créer un DDF c’est parfait. par contre tu as quelle version de deconz (ou plutôt combien ?), la headess ou la desktop ? Ou tu as fais tes manip sur un PC ?
Il faut que le DDF soit dans le répertoire « devices » de deconz sur la machine jeedom. Et re-inclure l’appareil si il n’est pas deja dans l’API.
Deconz est l’application, l’API est un plugin de deconz, phoscon n’est qu’une application comme jeedom.
Un appareil peut être dans deconz ais non reconnu dans l’API et donc non visible dans phoscon/jeedom.
dans le DDF on a
Name: On/Off light 3 (Pour info les 2 autres modules ok sont On/Off light 1 et 2.ces noms ont été créés par deconz)
Manufacturer: _TZ3000_ji4araar
Model identifier: TS0011
Type: End device
Le Deconz utilisé pour vérifier le fonctionnement (test3) est une version windows lancée sur un PC avec la cle sur un port USB de ce PC. Sur cette version les TS0011 se sont intégrés directement en activant « pairing » sur deconz mais avaient initialement un DDF vide. En regardant le DDF des TS0001 (ok et qui ont ponctionnés sans autre manip sur PC et dans Jeedom) j’ai vu qu’il avait un type On/Off Lights et j’ai donc éditer par deconz le fichier DDF des TS0011 en mettant ce type. Ce qui a permis de les faire fonctionner. Pour cette config le fichier DDF s’est créé sur le PC.
Pour le deconz mis en place sur l’OPI3 par l’intermédiaire du bouton du plugin acheté récemment, je n’ai pas d’accès direct à une version par le plugin. Le log d’install de décembre ne semble pas donner d’info sur ce point ou je ne sais pas y trouver l’info.
S’agit il bien de ce répertoire?
Si oui dois je créer un folder spécifique genre « Girier » ou autre et mettre le json dessous? ou directement sous devices?
Dois je en conclure que si le fichier DDF est dispo dans devices l’inclusion sera ok?
J’essayerai ça dès que tu me donnes le feu vert sur ma compréhension de la mise en place du fichier DDF (emplacement et structure).
Merci d’avance
Perdu ^^
Ça c’est c’est un répertoire de jeedom, c’est le répertoire du plugin deconz mais de jeedom, il te faut aller dans le répertoire de deconz Deconz : création d'un DDF
Une fois le DDF en place (vérifier le status « Gold ») il te suffit re re-inclure l’appareil, ça va utiliser le DDF pour reconnaitre l’appareil.
La version de deconz n’a pas d’importance si ce n’est qu’il vaut mieux éviter les versions 2.19, mais la c’est trop tard, on fera avec.
Tu peux le mettre en vrac dans un des 2 répertoire « devices » sinon tu peux créer un répertoire Girier, pas de problemes. A chaque redémarrage deconz scan tout le contenu.
Séquence faite:
1/Copie par FileZilla du fichier DDF (ts0011.json) créé par deconz windows sur PC et qui fonctionne sur PC vers le répertoire qui va bien (mieux) et que j’aurais jamais trouvé seul).
2/désactivation puis réactivation du plugin JeedomDeconz
3/relance demon plugin JeedomDeconz
4/lancement inclusion + switch pairing 5 s du module -->KO
Revérification des préalables… Zut Draft à la place de Gold…
Modif relance de la séquence et pis ça fonctionne
Intégration du 2eme TS0011 … pas d’apparition de page équipement…je jette un oeil sur réseau deconz/noeud il y a un nouvel équipement yes. une petite synchro et tout est ok.
Merci HugoVal11 TipTop les infos.
Sujet clos! En plus je vois que d’autres ont également bénéficié de tes connaissances
Ceci dit l’intégration auto sur PC mais pas par le plugin Jeedom m’intrigue. Une histoire de versions?
Bon cerise sur le gâteau qq sait il ou on peut mettre des images équipements plus parlantes pour remplacer l’image par défaut? je sais ça sert à rien mais c’est mon coté esthète …
Finalement on oublie la cerise car j’ai un pb plus utile à régler avec ces modules.
Lorsqu’ils sont connectés tout est ok désormais au niveau commandes OnOff par contre lorsque je les débranche le statut reachable reste ok sans limite de temps. La fiabilité du retour de status en prend donc un coup.
Ci dessous screenshot du réseau lorsque tous les équipement sont débranchés depuis 1 heure.
Les modules LN sont bien NOK paramètre accessible mais pas les L.
Une désactivation/relance du plugIn n’y change rien. Comme si ce paramètre était dans le dur et non pas un paramètre variable. De plus toujours débranché les commandes OnOff font modifier l’état comme si la liaison était ok et pas de message genre:
« Erreur exécution de la commande [Essai][ZigLN01][On 01] : Erreur lors de la requete : 192.168.1.xx:8484/api/2FFxxx935C/lights/1/state(PUT), data : {« on »:true} erreur : 202 => resource, /lights/1/state, is not modifiable. Device is not reachable »
Ci joint le fichier DDF
Je suis revenu sur la config PC et deconz window pour voir.
Lorsque les modules L sont débranchés j’ai un retour de commande timeout mais le lien graphique reste présent. Le petit point de couleur de liaison devient rouge donc conforme à une liaison ko
Une idée de recherche?
Oui.
Je viens de relire le DDF il n’y a pas la partie bind/report.
Je pense que pour les routeur c’est ça que surveille deconz pour savoir si un appareil est toujours la ou pas.
Je suis pas sur car normalement sans ça, tu ne devrais pas avoir de retour du tout, c’est peut etre invisible car l’appareil n’a pas de commande manuelle.
Rajoutes cette partie en fin de DDF, pour la syntaxe tu peux comparer avec un DDF complet, sinon passes moi le tien (au format texte), je te le compléterais.
Le format ci dessus te va?
J’ai remis ce fichier sous devices du OPI3, désactivé/activé le plugin relance demon.
Le status reachable reste toujours à true que l’équipement soit branché ou débranché.
Par contre le log deconz montre qu’il est bavard lorsqu’il est branché, id 4 . Les lignes qui se répétent toutes les <1sec n’apparaisent plus lorsque débranché.
Ben c’est pas mieux …
Il spamme la même requête alors qu’il n’est sensé le faire que quand il y a quelque chose de nouveau, et la c’est la même requête.
Et en plus ça reste bloque sur reachable = true alors que tu dis avoir débranché l’appareil, deconz devrait bien voir que les requêtes n’aboutissent plus … Tu as essayes de changer son état quand il est débranché ?
Aujourd’hui clean du bazar et redémarrage à zéro.
J’ai refait le parcours « propre » sous Deconz PC.
Suppression de tous les fichiers *.json.
Reset usine des modules L par deconz
Suppression des nodes dans deconz.
Extinction de tout Relance toujours sur PC.
+Visionnage de ça: https://www.youtube.com/watch?v=rgTQpOVg8w0
pour faire une intégration initiale « propre »
Constat.
Les modules LN « Aubess » s’intègrent finger in the nose. Le fichier DDF initial qui se charge tout seul n’a aucune partie binding/report. Le fonctionnement est nominal en toutes circonstances.
Les modules L « inconnu » s’intègrent mais leur fichier DDF initial s’arrête avant la partie « type ».
A noté que juste avec ça les commandes On/Off fonctionnent déjà mais le lien graphique ne s’établit pas et l’Appli phoscon ne les affichent pas.
Par l’éditeur de DDF deconz je rajoute le type « On/Off lights » par glisser/laché donc propre.
Le Lien graphique apparait mais reste désormais visible quelque soit l’alimentation du module. Par contre le paramètre reachable passe bien à false quand débranché. D’ailleurs l’appli Phoscon détecte bien le reachable false aussi. Donc dans cet environnement c’est pas clean mais fonctionnellement acceptable.
Je fais un hotload du DDF avant de retourner à Jeedom + sauvegarde du fichier DDF sur PC + copie par fileZilla vers l’emplacement secret de OPI3.
Retour à Jeedom/Deconz.
Suppression des modules L.
Réactivation du plugin + demon
Intégration des modules L ok apparaissant avec une synchro.
Fonctionnement comme on a vu…
Résumé
En l’état ces modules sont pas complétement clean sous deconzPC mais fonctionnels avec retour de connexion correct.
Par contre avec la même conf DDF sous JeedomDeconz là c’est ok fonctionnel + retour d’état On/Off quand manuellement enclenché depuis le module. Par contre inutilisable de mon point de vue car pas d’info de connexion ko quand débranché, l’etat On/Off change à chaque commande (comme sur du 433Mhz). Et surtout le niveau de message charge l’OPI inutilement Ce point est rédhibitoire.
Je vais essayer encore ce que tu proposes… J’ai également demandé au vendeur s’il avait un DDF.
Oui ça me renvoi un joli « exécution réalisé avec succès » comme du 433Mhz. Le Plugin Deconz est berné par qq chose qui lui fait croire que tout va bien. Ce qui est étrange puisque sous PC le paramètre "reachable se rafraichi bien.
Sinon utilises tu des modules Zigbee sans neutre qui fonctionnent?
J’ai un interrupteur sans neutre.
Mais je vois pas pourquoi il y a une différence de fonctionnement entre le PC et jeedom, surtout que le « reachable » fonctionne sur le PC.
C’est la même version de deconz ?
Une différence de réglage dans deconz ? tu as essayé en activant ou pas le « source routing » ?
Je vais lacher l’affaire pour l’instant avec ce module. Trop de temps déjà passé.
J’essayerai peut être une install de deconz manuelle comme le préconise Yves19 dans un de ses post.
Peux tu me passer les ref de ton module si il fonctionne bien?
Merci pour ton support
TipTop les infos. 
