Il est supporté nativement celui la.
Il fait partie de la vielle génération, avec une procédure spéciale pour l’inclusion, a base de double inclusion, je me souviens plus si il faut effacer l’entrée batterie entre les 2.
Le support par DDF est impossible, les DDF ne supportent pas les volets roulants Tuya.
Je vais tenter en supprimant la batterie, faut il juste supprimer l’équipement dans jeedom ?
Pour faire le point :
-
J’ai supprimé l’équipement batterie, j’ai essayer d’inclure le module > c’est à nouveau la batterie qui remonte. > je relance l’inclusion et je retente sans supprimer la batterie > rien de remonte.
-
J’ai supprimé l’équipement et le noeud Réseau Deconz, je passe en inclusion > la batterie remonte > Je relance l’inclusion > rien ne remonte en plus.
-
J’ai supprimé l’équipement et le noeud Réseau Deconz, je passe en inclusion > la batterie remonte > je supprime la batterie > je relance l’inclusion > la batterie remonte > je relance l’inclusion > rien de remonte de plus.
Je m’arrache les cheveux avec ce moteur de store, voici les informations que j’ai sur le noeud de la batterie :
Questions que je me pose :
[1] Est-ce que le fuseau horaire entre phoscon et jeedom pourrait poser problème ?
La conf sous jeedom :
La conf sous Phoscon :
[2] Comment checker ce qu’il se passe durant la seconde inclusion ?
[3] Est-il possible de créer un équipement et toutes les commandes avec les informations du noeud de la batterie ?
[4] Est-ce mon plugin RFX Com ou WifiLight V2 peut être source de problème avec Deconz ?
Bon dimanche à vous tous.
Je crois que j’avance doucement, j’ai installé Deconz sous Win et j’ai branché la clé dessus pour faire du debug lors de l’inclusion :
Est-ce que cela peut aider d’avantage ?
10:40:04:748 Daylight now: goldenHour1, status: 160, daylight: 1, dark: 0
10:40:14:756 Daylight now: goldenHour1, status: 160, daylight: 1, dark: 0
10:40:20:783 send permit join, duration: 59
10:40:24:750 Daylight now: goldenHour1, status: 160, daylight: 1, dark: 0
10:40:34:744 Daylight now: goldenHour1, status: 160, daylight: 1, dark: 0
10:40:40:787 sql exec SELECT conf FROM zbconf ORDER BY rowid desc limit 1
10:40:41:519 0x60EFABFFFED2738A 0x4C9F nwk changed to 0x76CF
10:40:41:527 APS-DATA.indication from child 0x76CF
10:40:41:527 DeviceAnnce of SensorNode: 0x60EFABFFFED2738A [1]
10:40:41:527 don't create binding for attribute reporting of sensor Battery 2
10:40:41:527 skip check bindings for client clusters (no group)
10:40:41:527 nwk address changed 0x4C9F -> 0x76CF [2]
10:40:41:527 device announce 0x60EFABFFFED2738A (0x76CF) mac capabilities 0x80
10:40:41:528 set fast probe address to 0x60EFABFFFED2738A (0x76CF)
10:40:41:528 FP indication 0x0000 / 0x0013 (0x60EFABFFFED2738A / 0x76CF)
10:40:41:528 ... (0x60EFABFFFED2738A / 0x76CF)
10:40:41:528 device announce 0x60EFABFFFED2738A (0x76CF) mac capabilities 0x80
10:40:41:528 DEV Tick.Join: event/device.anounce
10:40:41:528 DEV Tick: fast poll 0x60EFABFFFED2738A, mac capabilities: 0x80
10:40:41:528 don't create binding for attribute reporting of sensor Battery 2
10:40:41:528 skip check bindings for client clusters (no group)
10:40:41:528 don't create binding for attribute reporting of sensor Battery 2
10:40:41:528 MAC poll fastEnddeviceProbe() 0x60EFABFFFED2738A
10:40:41:528 [1] get node descriptor for 0x60efabfffed2738a
10:40:41:528 ZDP get node descriptor for 0x76CF
10:40:41:528 skip check bindings for client clusters (no group)
10:40:41:620 don't create binding for attribute reporting of sensor Battery 2
10:40:41:620 MAC poll fastEnddeviceProbe() 0x60EFABFFFED2738A
10:40:41:620 wait response fastEnddeviceProbe() 0x60EFABFFFED2738A, elapsed 91 ms
10:40:41:621 skip check bindings for client clusters (no group)
10:40:41:628 don't create binding for attribute reporting of sensor Battery 2
10:40:41:628 MAC poll fastEnddeviceProbe() 0x60EFABFFFED2738A
10:40:41:628 wait response fastEnddeviceProbe() 0x60EFABFFFED2738A, elapsed 99 ms
10:40:41:628 skip check bindings for client clusters (no group)
10:40:41:629 don't create binding for attribute reporting of sensor Battery 2
10:40:41:629 MAC poll fastEnddeviceProbe() 0x60EFABFFFED2738A
10:40:41:629 wait response fastEnddeviceProbe() 0x60EFABFFFED2738A, elapsed 100 ms
10:40:41:629 skip check bindings for client clusters (no group)
10:40:41:637 APS-DATA.indication from child 0x76CF
10:40:41:637 DB pushZdpDescriptorDb()
10:40:41:638 FP indication 0x0000 / 0x8002 (0x60EFABFFFED2738A / 0x76CF)
10:40:41:638 ... (0x60EFABFFFED2738A / 0x76CF)
10:40:41:638 ZDP indication search sensors 0x60EFABFFFED2738A (0x76CF) cluster 0x8002
10:40:41:638 ZDP indication search sensors 0x60EFABFFFED2738A (0x76CF) clear timeout on cluster 0x8002
10:40:41:643 [2] get active endpoints for 0x60efabfffed2738a
10:40:41:643 ZDP get active endpoints for 0x76CF
10:40:41:774 don't create binding for attribute reporting of sensor Battery 2
en terme de noeud du coup, je ne vois que ça :
Je viens du coup de lancer un read simple descriptor dans Deconz Win, et voici ce que j’ai obtenu :
Dans DDF edit voici ce que j’ai du coup :
{
"schema": "devcap1.schema.json",
"manufacturername": "_TZE200_zah67ekd",
"modelid": "TS0601",
"product": "TS0601",
"sleeper": false,
"status": "Draft",
"subdevices": [
{
"type": "$TYPE_BATTERY_SENSOR",
"restapi": "/sensors",
"uuid": [
"$address.ext",
"0x01",
"0xef00"
],
"fingerprint": {
"profile": "0x0104",
"device": "0x0051",
"endpoint": "0x01",
"in": [
"0x0000",
"0xEF00"
]
},
"items": [
{
"name": "attr/id"
},
{
"name": "attr/lastannounced"
},
{
"name": "attr/lastseen"
},
{
"name": "attr/manufacturername"
},
{
"name": "attr/mode",
"description": "Operational mode.",
"default": 1
},
{
"name": "attr/modelid"
},
{
"name": "attr/name"
},
{
"name": "attr/swversion"
},
{
"name": "attr/type"
},
{
"name": "attr/uniqueid"
},
{
"name": "config/on"
},
{
"name": "config/reachable"
},
{
"name": "state/battery",
"description": "The current device battery level in range 0–100 %.",
"refresh.interval": 3600
},
{
"name": "state/lastupdated"
}
]
}
]
}
Je n’ai plus la procédure en tête, pour faire simple, ton appareil ne peux pas être vu en mode volet roulant, car c’est un plug et sur batterie au point de vue zigbee.
Donc il doit d’abord être vu en temps que batterie, puis a la seconde inclusion, deconz le reconnait car il l’a deja dans la base (en temps que batterie), donc au moment du scan des volets roulant il re utilise cette info pour le reconnaitre.
J’ai voulu te trouver les logs affiché, mais je crois qu’ils les ont viré depuis (ça date ce truc).
Un truc a faire, tu vires tout, tu utilises le GUI pour récuperer toutes les attributs du cluster « basic » 0x0000, et une fois que deconz connait toutes les infos, tu remets phoscon en permit join, et tu relances une lectures des attributs du même cluster ou une lectures des « descriptors », avec le clic doit sur le node. Ca va forcer une inclusion.
Si ca marche pas, tu peux laisser tomber.
Pour infos
et ect, c’est une scan de capteur, donc tu pourras avoir la batterie mais pas le volet.
Mais sélectionner capteur ou lumière ne change rien coté" deconz
1 « J'aime »
J’ai tenté mais rien n’y fait, je n’ai pas plus d’élément. Je vais renvoyer mon moteur et voir pour un autre ou une autre techno 
J’ai réussi à obtenir ceci après plusieurs dizaines de minutes…
J’ai remis la clé sur jeedom me disant c’est bon c’est réglé… Mais non…
Je vois bien le modèle et la marque du moteur sous jeedom :
Mais pas comme sous deconz win comme un smart plug…
Une idée ?
Même quand l’appareil est reconnu, il n y a pas de changement sur deconz. Deconz affiche la réalité, c’est un firmware de plug, la modification est uniquement dans l’API.
Il te faut cliquer sut le cluster « Basic », pour afficher les attributs et essayer la seconde manip.
Et un appareil peut être sous deconz (dans le réseau zigbee), mais pas dans leur API (non reconnu).
J’ai phoscon qui m’a répondu ceci :
- Remove your device using deconz
- Select Basic Cluster « 0x0000 »
- Ask for attributes, at least Manufacture name / Model ID.
- When value are filled, set Phoscon in permit join
- Return on deconz, right clic on node, use Request 1 7 8 (it’s keyboard shortcut)
- With luck it will trigger the inclusion.
Je vais tenté demain
@Yves19 @HugoVal11
Ca y est cela fonctionne, voici la démarche complète à suivre :
Procéder à un backup de votre conbee2 sous phoscon (JEEDOM) avant de procéder au cas où !
Connecter la clé CONBEE 2 à un pc, et utiliser PHOSCON sous windows et bien activer la fenêtre supplémentaire comme ci-dessous :
Activer le debug view et cocher les debugs suivants :
Appairer le moteur avec l’application (Control > Pairing)
Dans le debug view vous devriez avoir ces lignes a répétition :
Ouvrir l’arborescence de la batterie trouvée et double cliquer sur basic 0x0000 :
Faire un Read dans la fenêtre Cluster Info jusqu’à avoir le nom du fabricant et le modele ID :
Relancer un Enable permit join dans l’onglet Control :
Clic-droit sur le module et faire successivement les fonction 1 puis 7 puis 8 :
(Attention, il se peut qu’il faille relance le permit join, veillez à ce qu’il ne soit pas terminé)
Normalement vous n’avez plus les lignes de debug en « don’t create binding »
Aller dans Phoscon App (en haut à droite) pour contrôler que le module est devenu un blind :
Sauvegarde la conf de Phoscon App sur Windows l’exporter (fichier *.dat):
Reconnecter la clé à JEEDOM et relancer le demon de DECONZ pour être sûr que la clé est bien démarrée :
Aller sur Phoscon via l’icone du plugin DECONZ :
Charger la config exportée précédemment, la passerelle redémarre :
Relancer le demon du plugin DECONZ
Retourner sur Phoscon App via l’icone pour controler que le module est bien dans les Blinds :
IMPORTANT : Remettre une passerelle avec les même données sans clé API, Sauvegarder et redémarrer le demon :
Aller dans Phoscon App via l’icone du plugin DECONZ et remettre le bon TimeZone :
IMPORTANT : refaire l’auth App entre Jeedom et Phoscon pour récuperer la clé API sinon vous aurez une erreur Auth Utilisateur à la synchro :
Dans les équipements de Deconz, supprimez tout puis synchronisez (ne pas oublier dans la fenetre (Groupe et binding) :
Le module est désormais intégré et reconnu, rendez le visible en cochant visible, MAIS IL FAUT MODIFIER UN PARAMETRE :
Le store est remonté sous le nom Batterie, mais possède bien les commandes nécessaires et le retour d’état, modifiez la valeur max du paramètre position à 100 au lieu de 255 :
Super.
Pour ceux qui ont accès en VNC à leur box domotique on peut aussi directement faire le job sans passer par win10. Ceci évite de faire les étapes de sauvegarde puis restauration de la base de données et du dongle Conbee tjrs un peu risquées lorsqu’il y a bcp de modules.
Comme l’application deconz est installée de base sur la box domotique ont peut y accéder via VNC simplement après avoir arrêté le démon du plug in Deconz.
Pour la fin du process, pas besoin de tout supprimer avant de resynchroniser sous Deconz; uniquement les modules qui auraient préalablement mal appairés. Ceci évitera de perdre certains réglages qui auraient été faits sous Deconz pour les modules non concernés .
1 « J'aime »
Lol, mais quelle usine, en tout cas content que tu t en soit sortis, moi j’aurais pas essayé autant de truc.
ça m’a bien gavé, mais j’avais pas envie de renvoyer le moteur 
. Persévérance 
Ce sujet a été automatiquement fermé après 24 heures suivant le dernier commentaire. Aucune réponse n’est permise dorénavant.