search

KiwiHC16 / Abeille

Abeille pour Jeedom (Gateway ZiGate)
GNU Affero General Public License v3.0
60 stars 52 forks source link

Création des commandes / EP erroné #1940

Closed mickadam29 closed 2 years ago

mickadam29 commented 3 years ago

@tcharp38 @KiwiHC16

Lors de la création d'un équipement dont j'utilise le firware de PTVO, la commande Name a été créée sur le EP02 au lieu de EP01 J'ai donc des messages du type "L'objet existe dans Abeille mais la commande 0000-01-0005" Donc mon objet envoie bien son nom sur "0000-01-0005" mais dans Abeille qui a été créée pour Name était "0000-02-0005" Dans l'écran ci-dessous j'ai remplacé hier, manuellement, 0000-02-0005 par 0000-01-0005 et aujourd'hui la commande Name fonctionne correctement. Pour les autres commandes, pas de soucis, ça doit porter sur le EP02. (Programmation du firmware). Les autres objets, programmés selon la même méthode, n'ont pas cette anomalie. Les commandes sont bien créées avec 0000-01-0005

image

Sur mon env de dev (master), j'ai inclus dans le json de mon objet DIY la commande NOM *

image

Et la commande NOM.json a visiblement un paramètre.

image

Je me pose la question du bien fondé de ce paramètre si la commande nom est toujours 0000-01-0005. A moins qu'il puisse y avoir un nom pour chaque EP ? Mais cela correspond à l'objet, donc un seul doit exister, non ?

tcharp38 commented 3 years ago

Bien vu. Ma comprehension depuis le debug sur Hue c'est que c est effectivement un pb. Je ne vois pas creer un JSON par EP. Il y en a deja trop et c'est de + en + difficile de suivre ce que chaque JSON fait. Je reflechis à changer la syntaxe du JSON pour permettre de "parametrer" chaque commande

Exemple au lieu de "includeX": "setReportTemperature"

un truc du style "includeX": { "cmd": "configureReporting", "args":"#EP#=02" }

Ca permettrait de reduire le nombre de commandes en se basant juste sur qq generiques, d'ajouter une certaine flexibilité mais surtout de customizer PAR EQUIPEMENT. Ca me semble un peu + facile à suivre que le systeme actuel. C'est la reflexion du moment.

Des commentaires ?

mickadam29 commented 3 years ago

Je mentionne des commandes dont l'EP est invariable. Je comprends évidemment de mettre des variables partout où cela est nécessaire. Je pense que l'idée c'est pouvoir créer des commandes identiques sur de multiples EP d'un même objet. Pour avoir des modèle DIY avec des multiples I/O, j'ai dû créer autant de template json que d'entrées/sorties car les json contiennent le numéro en dur au lieu de #EP#. Du style getEtatEP01.json getEtatEp02.json etc... Alors que je m'attends à avoir plus simplement un seul getEtat#EP# avec la variable #EP#. Mais je pense qu'il faut coder pas mal pour arriver à ça. En conservant le principe du device.json, si non ne sait pas le nombre de #EP# à inclure ça risque d'être difficile. Mon idée du json, c'est : j'ai des input/output. donc je mettrai dedans "include:input.json" "include:output.json" qq soit leur nombre. Et lors de l'interrogation de l'objet au moment de l'inclusion, je crée autant de commandes "0006-#EP#-0000" que nécessaire. En fonction du retour de l'interrogation des clusters. Mais ça c'est l'idéal. Je ne sais pas ce que cela implique en terme de DEV

mickadam29 commented 3 years ago

Pour le sujet, j'ai créé un nouvel objet en faisant la commande "Get Infos from NE". La commande nom est bien positionnée sur 0000-01-0005. Mais je ne sais pas si cela a été créé par relecture du json ou duplicata de l'objet interrogé. (objet corrigé 0000-02-0005 -> 0000-01-0005)

image

tcharp38 commented 3 years ago

Ca me semble etrange que tu aies autant de "EP" ?! Tu as regardé un peu parmis les Eq du commerce comment ils se comportent ?

Quoi qu'il en soit côté JSON il y a beaucoup à faire. Comme tu dis, l'idéal serait que la plupart des commandes soient crées de maniere automatique (l'idée de mon assistant en cours). Mais c'est du + long terme.

En attendant ma suggestion donnerait un truc du style "commands": { "includeX": { "name": "getEtat", "args": "#EP#=01"}, "includeX+1": { "name": "getEtat", "args": "#EP#=02"}, "includeX+2": { "name": "getEtat", "args": "#EP#=03"}, "includeX+3": { "name": "getEtat", "args": "#EP#=04"}, } Seul le JSON de l'equipement serait touché.

Ca reste à murir dans tous les cas pour rendre le support de tout nouvel eq + facile/clair et surtout maintenable. Il ne faut plus qu'on arrive à des cas ou on introduit une regression sur d'autres eq parce que le JSON n'est pas "generique".

mickadam29 commented 3 years ago

Mes DIY sont justement nécessaires parce que j'ai pas trouvé d'appareil du commerce qui gèrent par exemple plusieurs entrées. La "puce" Zigbee utilisée est capable d'en gérer 16 depuis le dernier firwmare, donc 16 EP et donc il faudrait 16 include getEtatxx.json selon la méthode actuelle. Ou j'ai mal implémenté mes json. Je viens de voir que le Get Infos a bien relu le json pour me créer l'objet. En effet, dans diy-mains-default.json, le nom donné pour le EP02 est bien "Digital Input 2" alors que l'objet dupliqué a "Présence Secteur" (renommé par mes soins après création) Là-aussi, dans les évolutions possible, il faudrait pouvoir mettre le libellé de la commande. Par exemple: "include2": "etatEp02in" "Présence Secteur"

Dans le "etatEP02in" j'ai : name qui est codé en dur. Il faudrait une variable. Tu t'étonnes du nombre EP ? Comme tu le vois, dans les json faits pour mes DIY, j'ai repris ce qui fonctionnait et donc c'est inscrit en dur "0006-02-0000". Il faudrait "0006-#EP#-0000". Comme ça un seul serait nécessaire. Mais comment faire pour que l'inclusion crée 7 commandes dans l'objet ?

Si tu le souhaites on peut en parler sur slack et je peux te faire des tests en rapport avec mes DIY qui ont 7 et 8 EP à gérer. Et pour chaque EP je crois que j'ai un getEtat, un reportEtat, un Bind aussi (pas certain de l'avoir fait) donc ça fait des json complexes. Voir à la fin

image

image

{ "7-digital-input": { "nameJeedom": "7-digital-input", "timeout": "60", "Categorie": { "automatism": "1" }, "configuration": { "uniqId": "20210216_1938", "icone": "7-digital-input", "mainEP": "01" }, "Commandes": { "include100": "nom", "include2": "etatEp02in", "include2 1": "getEtatEp02", "include3": "etatEp03in", "include3 1": "getEtatEp03", "include4": "etatEp04in", "include4 1": "getEtatEp04", "include5": "etatEp05in", "include5 1": "getEtatEp05", "include6": "etatEp06in", "include6 1": "getEtatEp06", "include7": "etatEp07in", "include7 1": "getEtatEp07", "include8": "etatEp08in", "include8 1": "getEtatEp08" } } }

tcharp38 commented 3 years ago

Je vais + loin dans la reflexion du JSON. Au lieu d'"include X" je mets le nom de la commande finale Jeedom. Encore mieux.

"commands": { "getEtat01": { "use": "getEtat", "args": "#EP#=01"}, "etat01": { "use": "etat", "args": "#EP#=01"}, "getEtat02": { "use": "getEtat", "args": "#EP#=02"}, "etat02": { "use": "etat", "args": "#EP#=01"}, "getEtat03": { "use": "getEtat", "args": "#EP#=03"}, "etat03": { "use": "etat", "args": "#EP#=01"}, "getEtat04": { "use": "getEtat", "args": "#EP#=04"}, "etat04": { "use": "etat", "args": "#EP#=01"}, }

Tu vois dans mon idée... 1 seul fichier JSON modifié, celui qui est spécifique à l'equipement. getEtat.json & etat.json sont generiques et devraient etre stables pour toujours.

KiwiHC16 commented 3 years ago

Bien vu. Ma comprehension depuis le debug sur Hue c'est que c est effectivement un pb. Je ne vois pas creer un JSON par EP. Il y en a deja trop et c'est de + en + difficile de suivre ce que chaque JSON fait. Je reflechis à changer la syntaxe du JSON pour permettre de "parametrer" chaque commande

Exemple au lieu de "includeX": "setReportTemperature"

un truc du style "includeX": { "cmd": "configureReporting", "args":"#EP#=02" }

Ca permettrait de reduire le nombre de commandes en se basant juste sur qq generiques, d'ajouter une certaine flexibilité mais surtout de customizer PAR EQUIPEMENT. Ca me semble un peu + facile à suivre que le systeme actuel. C'est la reflexion du moment.

Des commentaires ?

Tu mets un JSON directement dans l objet. Cela ne réduira pas la complexité ca ne fera que la déplacer.

Plusieurs commentaires:

KiwiHC16 commented 3 years ago

Pour la creation auto il doit exister un bout de code qui fait ca sur la base du code récupéré dans le "Simple Description". Mias cela ne fonctionnait pas super alors laissé de coté. En gros cela fonctionnait de la façon suivante: Si je récupère le nom, j utilise le json associé. Si je ne connais pas ce nom, je récupère le type d'équipement dans Simple Desc et je prends le JSON associé.

Mais je ne sais pas si ce bout de code est toujours utilisé.

tcharp38 commented 3 years ago

Tu mets un JSON directement dans l objet. Cela ne réduira pas la complexité ca ne fera que la déplacer.

Je ne sais pas à quoi tu fais allusion. Je parle du JSON de l'objet, par ex devices/SLM002/SLM002.json c'est le point d'entrée et la description specifique de l'equipement comme tu l'as créé. Je ne pense qu'a changer sa syntaxe de la partie "Commandes" => "commands"

Plusieurs commentaires:

  • dans les JSON il y a un melange entre les infos purement zigbee et les infos Jeedom. Peut être pourrions nous les séparer pour limiter les configurations.

Tout à fait, et normaliser histoire de pouvoir faire le lien rapide avec la spec cluster zigbee

  • Dans JSON il y a deux EP: un #EP# et un mainEP ou un truc dans le genre. Il faudrait certainement revoir ce point. Ca traine depuis le debut.

Oui c'est clair. Je ne comprends pas moi meme cette notion de "main".

  • Pour moi il peut y avoir un nom par EP. Pour identifier un equipement j ai toujours pris le nom de l EP le plus petit.
  • Le coût de créer 16 JSON avec des copy/paste pour un equipement DIY est sans commune mesure avec un truc automatique (tests, regressions,....). Mon avis perso, faites les JSON à la main et gardez votre temps pour les autres sujets. La raison des JSON et justement la diversité des situations et le codage impossible tellement il existe de situation.

Tout à fait en ligne. Dans ma tete j'ai pas l'intention de basculer tout sur un nouveau modele. Toujours progressif. Et le JSON reste la base. Les modes "auto" c'est pour plus tard.

  • Pensez que lors de l inclusion il est toujours très difficile d avoir toutes les infos de l equipement en l interrogeant d'ou la creation des JSON pour pouvoir créer l objet en ayant que son identifiant(nom).

En ligne

  • J ai plutôt en tete de faire un bout de code pour essayer d'auto générer des JSON sur la base des infos qu'Abeille parvient à récupérer des modules en les interrogeant et proposer le JSON à l utilisateur (ou dev).

En ligne et c 'est pas incompatible avec un JSON completement fait main comme aujourd hui.

  • Les JSON sont aussi le fruits de investigations et tests. C est bien plus robuste que n importe quel code.

Sauf... quand on se met à modifier un JSON lui meme utilisé par plusieurs EQ. Ex: setReportTemperature. Le EP est codé en dur donc pas bon, pas generique ou trop specifique.

J'espere que ca te donnera une meilleure idée de ce qui me trotte en tete

tcharp38 commented 3 years ago

Je te propose de faire un essai de mon côte sur la base Sonoff SNZB02 et je te montre un exemple concret et en service.

tcharp38 commented 3 years ago

@mickadam29 210708-BETA-1 a essayer. Voir en exemple "sen_ill.mgl01"

J'ai mis en place une nouvelle syntaxe dans le JSON equipement qui permet d etre plus flexible et du coup reduire le nombre de fichiers commande

C'est assez simple à comprendre et ca doit repondre à ta problematique.

"Commandes": {
  "include1": "SW",
  "include2": "nom",
  "include4": "luminositeXiaomi",
  "include7": "Xiaomi-ff01",

  "BindToZigate-Illuminance": { "use":"bindToZigate", "params":"EP=01&CLUSTID=0400", "execAtCreation":"Yes" },
  "SetReport-Illuminance": { "use":"setReport", "params":"EP=01&CLUSTID=0400&ATTRID=0000&ATTRTYPE=21", "execAtCreation":"Yes" },

  "BindToZigate-Power": { "use":"bindToZigate", "params":"EP=01&CLUSTID=0001", "execAtCreation":"Yes" },
  "SetReport-Battery": { "use":"setReport", "params":"EP=01&CLUSTID=0001&ATTRID=0020&ATTRTYPE=20", "execAtCreation":"Yes" },
  "include0001-3": "Battery-Volt2Percent-3",
  "include0001-4": "Batterie-Pourcent-Ikea"
}
tcharp38 commented 2 years ago

@mickadam29 Il y a eu beaucoup de mises à jour depuis. Qu'en est il de ce sujet pour toi ?

mickadam29 commented 2 years ago

Salut

Tu peux fermer si tu veux. J’ai mis de côté mes devs DIY J’ai passé ma prod en 3.1E ça m’a planté qqs équipements. Donc priorité à la remise en prod pour moi en ZiGate+ 3.2 OPDM Puis maj de ma ZiGate V1 en 3.1E OPDM et erase PDM. Je vais refaire un tour sur le forum pour reprendre les tickets que j’aurai pu ouvrir

Le 2 déc. 2021 à 16:11, Tcharp38 @.***> a écrit :

 @mickadam29 Il y a eu beaucoup de mises à jour depuis. Qu'en est il de ce sujet pour toi ?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android.

tcharp38 commented 2 years ago

Bon je ferme car sans toi je ne peux rien faire sur le sujet mais n'hesite pas à réouvrir si besoin.