Il serait intéressant de voir ce que retourne l’analyseur d’évènement de Phoscon.
Pour cela aller dans le menu Gateway/Help/API Information
Menu Gateway/Help/Api Information
Puis sélectionner uniquement le slights et dans le menu déroulant l’équipement concerné
Ensuite sélectionner l’onglet events et analyser ce qui se passe quand tu fais des ON/OFF avec ta prise sot directement sur ta prise soit depuis des télécommandes soit depuis Jeedom.
En effet les commandes ON/OFF info comme action semblent correctement configurées sous Deconz.
Tu peux même en parallèle tenter de changer le type de la commande info Etat 01 avec les combinaisons suivantes : NumériqueLumière BinaireCapteur. NumériqueCapteur
On ne sait jamais peut être que le bug se situe ici.
On dirait que la programmation de la commande « Etat 01 » dans jeedom, ne va pas lire la bonne info dans les données brutes.
Car lorsque je la teste a partir des commandes jeedom, j’ai toujours un retour vide. Ni 1, ou 0, Ni On ou Off, que la prise soit allumée ou éteinte.
Je pense que si la commande lit le bon etat, le widget du dashboard qui switche entre on et off se mettra à jour…
Donc la commande info n’est pas du tout rafraichie et ne l’a même jamais été depuis la création de l’équipement.
Je te propose de supprimer la commande Etat 01 et de la recréer manuellement càd en renseignant les quelques champs Nom, Type, Logical ID à la main après avoir ajouté une commande.
Simplement dans la page commandes de ton équipement tu cliques sur le - en bout de ligne pour supprimer la commande Etat 01 puis tu sauvegardes.
Ensuite tu cliques sur + Commandes et là tu saisis les champs ad hoc , commande action, nom, logical ID , type , … et n’oublie pas de sauvegarder une fois cela fait.
Relance ensuite le démon Deconz et teste
Les infos brutes, c’est quel format ? Ca ressemble a du JSON un peu, mais je ne comprends pas comment ma commande « Etat » est censée récupérer ce « false » avec 01:state::on
à la limite avec un 6:state:on ca me paraitrait plus logique :)
{
"6": {
"etag": "6890ca05e9fb04778fe81cb978e8450c",
"hascolor": false,
"lastannounced": null,
"lastseen": "2022-01-19T12:22Z",
"manufacturername": "LUMI",
"modelid": "lumi.plug.maeu01",
"name": "Smart plug - Sapin",
"state": {
"alert": "none",
"on": ***false***,
"reachable": true
},
"swversion": "09-10-2019",
"type": "Smart plug",
"uniqueid": "04:cf:8c:df:3c:82:13:9f-01"
},
Non l’interpréteur deconz ne fonctionne pas comme cela.
Il se sert du unique ID (raccourci) comme racine de la commande et ensuite parcourt l’arborescence des champs séparés par un . jusqu’à l’attribut final qu’il sépare du reste par ::
Ces commandes sont ensuite transmises via ligne série (c’est là qu’intervient le protocole propriétaire) vers le dongle qui les transforme en trames zigbee et les émet.
Dans le sens réception c’est le chemin inverse qui se fait.
Pourquoi 01 et pas 9f-01 alors ?
Quand tu parles de ligne série, tu ne parles pas de port série sur le RPI ? car en installant la clé conbee2, il etait marqué de desactiver la connexion serie dans raspi-config, ce que j’ai fait
L’interpréteur ne prend que le dernier champ de l’unique ID donc ici 01 ou 01-0b04 ou 15-000c selon les end points de ton équipement.
L’ambiguïté apparente de ne pas prendre la totalité de l’unique ID est levée grâce à l’unicité des champs qui suivent dans la commande.
La ligne série est l’USB dans le cas qui nous concerne.
ok donc ca n’avait rien a voir.
Du coup, je seche, je ne vois pas ce qui se passe avec ces prises qui fonctionnaient bien…
On dirait que toutes les infos récupérées ne fonctionnent pas (etat de l’interrupteur, consommation, …) alors que les commandes fonctionnent
En tous cas le PB est bien localisé du coté Jeedom puisque les données dans Phoscon sont OK. Tu peux même le vérifier pour les capteurs de puissance sous Phoscon si tu le veux.
Peux être le websocket qui ne fonctionne plus comme il devrait entre deconz et deCONZ (Phoscon) ?
