Re: [openplacos-dev] ifaces multiples (suite)

Le 12 août 2011 16:02, miaouf kirsh <miaoufkirsh@xxxxxxxxx> a écrit :

oui, en plus j'ai fait ca sur la mesure d'humidité, donc avec compensation de temperature.
je dirais que ca prend environs 7-8ms par link (couche dbus).

sinon je reflechissais a ces histoire d'iface coté client. peut etre le meiux est de les mettres toutes sur un pied d'égalité.

apres tout c'est pas tres grave si l'etat de la regul est pas affiché en meme temps que la valeur du sensor.
en gros on affiche qu'une iface a la fois, et l'user choisi laquelle

Le 12 août 2011 15:51, flagos <flagospub@xxxxxxxxx> a écrit :

Cool sinon la mesure de perfs: 4 centiemes en 1.8 2 centiemes en 1.9.x pour faire une mesure, c'est pas mal !

Enfin c'est cool parce que jusque la on en avait aucune idée.

Le 12 août 2011 15:49, flagos <flagospub@xxxxxxxxx> a écrit :

Tout a fait, comme tu dis, le premier niveau du nom de l'iface nous permet de savoir le type de data qui est renvoye. A priori une data de meme type sur un meme objet, on peut le considerer comme redondant et donc interdit.

Cela dit, si le gonze qui code le composant veut avoir un peu de flexibilité, il peut eventuellement passer un parametre (comme l'unité de temperature) dans la config.

Apres je pense comme toi, s'il s'agit seulement de conversion d'unites, le mieux est de le sortir dans un autre composant dédié.

Le 12 août 2011 15:31, miaouf kirsh <miaoufkirsh@xxxxxxxxx> a écrit :

yop
c'est vraiment pas évident tout ces truc

la possibilité d'avoir plusieur iface avec unheritage equivalent pour les composants est assez séduisante mais c'est vrai que ca amene pas mal de problemes :

indétermination au niveau des link, vu qu'on map des pin et pas des ifaces
mauvaise mutualisation du code. par exemple pour chaque composant de température, j'ai plusieur fois des routines des conversions ( qui peuvent diverger). ou par exemple dans mon dimmer, j'ai une iface switch donc j'ai copié du code du RelayNo etc

donc effectivement on pourrai interdire d'avoir plusieurs ifaces qui on un meme héritage dans une meme pin, histoire de lever des les indetermination.

typiquement, on doit pouvoir definir plusieurs ifaces qui sont incompatible, par exemple un driver doit pouvoir proposer du pwm, du analog ou du digital etc dans un pin, par contre on doit pas pouvoir definir un analog.A et un analog.B parce que si on branche une pin en analog.* , il y a indetermination.

apres ca change pas grand chose coté client, car on doit toujours autoriser le merge des ifaces, mais c'est un autre probleme.

Le 12 août 2011 08:46, flagos <flagospub@xxxxxxxxx> a écrit :

Yop,

Suite a notre discussion hier, j'ai re reflechi au truc. Tu repars sur le cas basique: temperature+regule.

Si la regule est generique (c'est l'interet de la manipe qand meme) donc iface analog et que le sensor de temperature se presente avec 3 ifaces (celcuis, fareinheigth, kelvin), comment savoir dans quelle unité ca va reguler ?

Typiquement on va envoyer 25 sur l'interface analog, mais 25 en celcuis ou en kelvin, ca fait pas la meme chose !

Premiere piste:

Dans l'idée, il faudrait que le sensor herite d'une iface de maniere dynamique au moment du link.. et ca me semble un peu chaud a faire ! En fait, il faut que la regule dise au moment de l'introspect pour sa pin_frontend:

1. Je suis une pin analog
2. J'heriterai de l'iface au moment du link

Seulement voila, moi tu me met une regule en fareinheigth, c'est sympa mais j'en ferai rien. Faut donc que ce soit l'utilisateur qui definisse comment on gere le link au niveau iface, bref le truc un peu penible qu'on voulait tout de meme eviter

Deuxieme piste

A la limite, on pourrait faire une variante de la premiere piste en mode bourrin: si la regule s'en batte de l'iface (cad qu'a l'introspect, on a un truc en mode juste analog), on lui les met toutes (la regule aura donc du celcuis, kelvin et co en entree) et nous selon la requete en frontend de la regule, pif en sortie on link sur l'iface correspondante sur la temperature.

Ca doit bien avoir des merdes quelque part, ca ressemble a une idée foireuse, mais autant ca correspond vraiment a ce qu'on veut faire en realité.

Troisieme piste

La plus probable: on arrete de se faire chier, on met tout le monde en celcuis. On cale un composant qui convertit de °F a °C que le gonze intercalera entre sa regule et la temperature, comme il fera une regule en °F, et l'ambiguite est levee dès la config.

Ou autre solution, le composant de temperature est configurable, et dans sa config, on exprime en quelle unité on veut le voir. Pareil, ambuiguité levée des la config et basta.

Voila, plus j'y reflechis et plus je me dis que la solution 3 est la plus simple pour tout le monde ;-)

--
Tapé depuis mon clavier

--
Tapé depuis mon clavier

--
Tapé depuis mon clavier