Bonjour
Y a t’il qq part une description de la table « eqLogic » decrivant comment un plugin peut l’utiliser ?
En particulier pour les champs « configuration » & « status », que doit ou peut faire le plugin avec ca ?
Le but de la question est de comprendre ou stocker des infos spécifiques au plugin pour chaque équipement.
Merci
Salut,
Tu ne dois (peux) pas utiliser la table eqlogic directement mais tu dois utiliser les méthodes de la class eqLogic setConfiguration() et getConfiguration() par exemple pour la config
Plus d’info ici notamment: API Documentation
@Mips
Oui bien sur c’est deja ce qu’on fait mais y a t’il des recommendations quant aux infos qu’on y met ?
Jeedom aussi l’utilise et comment etre sur de pas tomber sur un champ qu’il va utiliser ?
D’autre part je ne comprends pas trop comment utiliser « configuration » vs « status ».
Tu peux m’eclairer ?
Merci
Je n’ai jamais vu de recommandations officielles, je dirais que:
; exemple: niveau de batterie, lastcommunication etcbatteryStatus()
, effectivement il faut éviter les collisions mais je n’ai jamais vu de règle explicite ni implicite (dans les plugins officiels par exemple); quelques idées:
pluginid::myKey, assez fréquent globalement et déjà vu cela quelques fois dans jeedomconfig_pluginid et dans ce niveau on fait ce qu’on veut puisqu’à priori le core n’ira pas créé une config avec ce nom.J’espère qu’il n’y a pas de risque de collision, car moi j’utilise des configurations très générique: « type » « product » … sans aucun préfixe / suffixe 
Concernant 1 plugin et 1 objet EqLogic, je pense qu’il y a effectivement en interne un préfixe pluginID::eqLogiqID::key mais c’est transparent, pas à nous de le gérer en principe…
Il ne faut pas storer d’info dans la table eqlogic. Met les en configuration de ton plugin ou dans une table propre à ton plugin. Et gère bien le nettoyage à la désinstalle du plugin !
Oui c’est ce que j’ai déjà dit ici non?
Eqlogic set configuration c’est la table eqlogic. Si tout les plugins stockent ça la ca finira par exploser avec une string trop longue pour la db.
Toutes les config d’équipements vont la dedans, c’est à ca que ca sert 
D’équipement oui pas de plugin
Resalut tous.
Je vois que j’ai mis le doigt sur qqch qui apparait ne pas etre si clair.
Je sais que plusieurs plugins (dont Abeille, ou Zigate) utilisent cette table eqLogic via les commandes set & getConfigutation().
Du coup quel est le message officiel Jeedom ? On peut ? On ne doit pas ? Et si on ne doit pas y a t’il un exemple/template d’utilisation de sa propre table ?
Il me semble qu’un minimum de « doc/recommandations » pour les developpeurs plugins permettrait de clarifier les choses pour tous et du coup d’améliorer la stabilité de l’ensemble non ?
Qu’en pensez vous ?
Je pense que la confusion est uniquement parce que @kiboost a compris que tu voulais stocker des infos de config du plugin et pas de tes équipements alors que moi j’ai interprété que c’était bien la config des équipements dont tu parlais
Donc en principe
Salut,
Encore une fois je ne vois pas en quoi la documentation Jeedom devrait répondre à cette question ?
Il s’agit juste de bon sens en fait
Ok parfait alors.
Merci pour tes recommendations @Mips
Salut @Salvialf
Je ne vais pas me battre avec toi. Ca n’est pas la premiere fois que tu me rentres dedans. T’es clairement anti doc.
Bref le bon sens pour moi serait que l’interface entre 2 mondes (Jeedom d’un coté, les plugins de l’autre) soit le mieux definie possible pour eviter des effets de board malheureux lies à l’interpretation de chacun. Ca peut souvent se resumer en peu de lignes ou diagrammes, ca sert de reference et ca supprime des tas de questions.
« Va fouiller dans le code pour savoir » ne donnerait qu’une partie de la reponse.
On a 2 visions differentes et j’en reste la.
Effectivement nous n’avons pas la même vision car à mon sens la documentation Jeedom n’a pas vocation à donner des cours de développement.
Lorsque tu dev un plugin Jeedom, tu as un plugin et des équipements. Chacun ayant ses entrées en BDD il semble logique de remplir les colonnes correspondantes
La notion de « bon sens » est quelque chose d’assez relatif, et puis en effet un débutant n’aura pas ce bon sens qui vient avec l’expérience… Donc, oui la doc mérite d’être aussi claire que possible, et lorsqu’une question est posée sur le forum c’est judicieux de l’ajouter quelque part, par exemple dans la doc 
J’ai fait un topic (public dans la section publique du forum parce que j’estime qu’il ne devrait pas y avoir ce genre de section privée pour ce qui est programmation d’un soft open source) et je remet le lien:
ça m’embête que mon topic soit fermé, serait-il possible de le re-ouvrir car j’ai parfois envie d’y rajouter de l’info ?
En effet je me suis un peu perdu, je pensais plus a un plugin qui a besoin de stocker des infos sur tous les équipements, y compris des eqlogic qui ne sont pas du plugin en question.
Pourquoi ne pas faire un PR sur la doc pour rajouter l’information que tu voudrais voir alors plutot que de le faire dans un topic de community?
@Mips
Je vois en fouillant le core que setStatus() est utilisé pour par ex mettre à jour ‹ lastCommunication ›.
Mais quand je regarde ma DB status est toujours ‹ null ›.
Tu saurais me dire si ce status est parfois reellement enregistré dans la DB ou il reste en cache ?