> oui petite precision, la methode get_iface, elle rajoute juste
> "org.openplacos", elle va pas chercher plus loin
>
> Le 18 avril 2012 16:03, miaouf kirsh <
miaoufkirsh@xxxxxxxxx> a écrit :
>
>> en gros, on a bien codé le merge, mais on redirige mal la requête :
>> si on a deux pin mergée, on redirigeait toujours la requête sur la
>> première, c'est le [0] dans
>>
>> @binding[pin_sender_name_][0]
>>
>> par contre pour les iface, on a pas l'héritage
>> par exemple on fait un call sur /home/température sur l'iface
>> analog.sensor.temperature.celcuis
>> on va chercher la pin qui est branché dessus , dans notre cas c'est
>> /lm335/temperature
>> et on va appeller l'iface qui a le meme nom :
>> analog.sensor.temperature.celcuis
>> donc si les deux ifaces matches pas exactement, ca va merder.
>>
>> c'est pas tres dur a faire, mais faut le faire.
>>
>> Le 18 avril 2012 15:50, flagos <
flagospub@xxxxxxxxx> a écrit :
>>
>>> Coool un beau composant bien compliqué, c'est chouette !
>>>
>>> Petite question:
>>> Quand je vois le commit:
>>>
>>>
https://github.com/openplacos/openplacos/commit/976e747299da4e583307206ae66f44253797ea09
>>> j'ai l'impression que l'heritage a bien été codé puisque tu appelles
>>> l'interface du binding qui inclut le nom de l'interface d'en face...
>>> C'est suffisant en terme d'heritage no ?
>>>
>>> Le 18 avril 2012 14:30, miaouf kirsh <
miaoufkirsh@xxxxxxxxx> a écrit :
>>> > Re,
>>> > juste pour résumer ce que j'ai fait hier :
>>> > j'ai codé un composant de régulation :
>>> >
>>> >
https://github.com/openplacos/openplacos/commit/9442249ea9502f86ffb53d5ebbaedad591c3c3d7
>>> >
>>> > j'ai repris le code de Regulation.rb qu'on avais au niveau du server
>>> > dans la
>>> > 0.3
>>> >
>>> > il y a 3 type de régulation codé
>>> >
>>> > bool : allume un effecteur quand la valeur > seuil+hysteresis , et
>>> > inversement
>>> > invbool : eteind un effecteur quand la valeur > seuil+hysteresis , et
>>> > inversement
>>> > pwm : (nom a retravailler) ajuste une valeur du dimmer en fonction de
>>> > la
>>> > valeur du sensor.
>>> >
>>> > le type de régulation est choisis en passant un parametre lors du
>>> > lancement,
>>> > ce qui implique un introspect différent en fonction du type.
>>> >
>>> > petit patch pour suporter ca :
>>> >
>>> >
https://github.com/openplacos/openplacos/commit/a70572833b14a6dd9988029e4f90d7108084e8a7
>>> >
>>> > on a une pin en entrée avec plusieurs ifaces en fonction du type de la
>>> > régul, c'est ifaces sont mergé avec celle de /home/temperature.
>>> >
>>> > du coup petit patch pour que le call soit bien redirigé vers le bon
>>> > composant :
>>> >
>>> >
https://github.com/openplacos/openplacos/commit/976e747299da4e583307206ae66f44253797ea09
>>> >
>>> > enfin, j'ai ajouter le support du nom des ifaces a la libclient :
>>> >
>>> >
https://github.com/openplacos/openplacos/commit/201673af02d70ef254094e2a6097674c26e5fbb0
>>> >
>>> > Enfin, vu qu'on a pas implementer l'heritage au niveau des iface, ce
>>> > composant ne peut se brancher que sur une iface
>>> > analog.sensor.temperature.celcuis
>>> >
>>> > voila
>>> >
>>> > Le 16 avril 2012 13:18, miaouf kirsh <
miaoufkirsh@xxxxxxxxx> a écrit :
>>> >
>>> >>
>>> >>
>>> >> Le 16 avril 2012 11:23, flagos <
flagospub@xxxxxxxxx> a écrit :
>>> >>
>>> >>> (je reponds par le biais de la maillist)
>>> >>>
>>> >>> typiquement si je veut faire une régule qui a une output pin avec une
>>> >>> iface "analog.sensor", va elle pouvoir se brancher sur une iface
>>> >>> "analog.sensor.temperature.celcuis" ?
>>> >>>
>>> >>> Je sais meme pas si on vérifie quelque chose actuellement.. Après si
>>> >>> question était de savoir si c'était ce qu'on avait décidé de faier:
>>> >>> oui c'est bien ca.
>>> >>>
>>> >>
>>> >> Effectivement j'ai maté un peu le code et il me semble qu'on ne fait
>>> >> aucune vérification.
>>> >> En gros si on met un Wire entre 2 pin qui n'on pas la même iface, ca
>>> >> crashera au call et pas a l'init.
>>> >> il faut qu'on fixe ca, je rajoute dans la todo list.
>>> >>
>>> >> Après ce qu'on avais également dit c'est cette histoire d'héritage.
>>> >> En gros ya aucune incompatibilité entre une iface en analog.sensor et
>>> >> une
>>> >> analog.sensor.temperature donc on devrai pouvoir les connecter
>>> >> ensemble
>>> >>
>>> >>>
>>> >>> et si on a plusieurs ifaces qui satisfont le truc (dans un des
>>> >>> dernier
>>> >>> mail on parlais les interdire les héritage similaires.)
>>> >>>
>>> >>> Je n'y avais pas pensé. Premier arrivé, premier servi ?
>>> >>
>>> >>
>>> >>
>>> >> Pas evident, ya aucun moyen de savoir pour le composant (et donc pour
>>> >> le
>>> >> user) laquelle est connecté.
>>> >>
>>> >> par exemple pour la température on a 3 ifaces:
>>> >>
>>> >> analog.sensor.temperature.celcuis
>>> >> analog.sensor.temperature.farenheit
>>> >> analog.sensor.temperature.kelvin
>>> >>
>>> >> Si on branche une régul générique dessus, dont l'output pin demande
>>> >> une
>>> >> iface analog.sensor.*, ca joue quand meme de savoir sur laquelle on se
>>> >> branche. passé un moment on avais evoqué la possibilité de spécifié
>>> >> l'iface
>>> >> dans le ficher de config (au niveau des Wires) pour lever
>>> >> l’indétermination.
>>> >>>
>>> >>>
>>> >>> enfin dernier truc, au niveau de la regul, on a une valeur set/unset
>>> >>> a
>>> >>> regler, mais egalement des parametres genre seuil etc.
>>> >>> tu pense que c'est mieux de faire une iface genre
>>> >>> "digital.regul.switch" avec des parametre a passer dans le hash
>>> >>> d'option
>>> >>> ou de caller une iface par param a regler ? genre
>>> >>> "digital.regul.switch" pour le set/unset, "analog.regul.threshold"
>>> >>> pour le seuil, et "analog.regul.hysteresis" pour l'hystéresi.
>>> >>> moi je pense pour une iface par //
>>> >>> ca permet d’être extensible (genre un param a régler en plus sera
>>> >>> toujours affiché par les client)
>>> >>>
>>> >>> Je suis pour également. Ca permettrait par exemple d'avoir le
>>> >>> threeshold en commun sur tous les composants de type regul (pid et
>>> >>> hysteresis par exemple) et de pouvoir coder des composants qui
>>> >>> pourraient s'appuyer sur cette interface , un machin qui ferait du
>>> >>> controle automatique de regul, une sorte de regul de regul par
>>> >>> exemple.
>>> >>>
>>> >>
>>> >> Ca marche
>>> >>
>>> >>>
>>> >>>
>>> >>>
>>> >>> Le 16 avril 2012 10:48, miaouf kirsh <
miaoufkirsh@xxxxxxxxx> a écrit
>>> >>> :
>>> >>> > Salut
>>> >>> > Hier je pensais a un truc a propos des régule. Je me rappelle plus
>>> >>> > si
>>> >>> > on a
>>> >>> > codé cette histoire d'héritage pour les ifaces au niveau du server.
>>> >>> > typiquement si je veut faire une régule qui a une output pin avec
>>> >>> > une
>>> >>> > iface
>>> >>> > "analog.sensor", va elle pouvoir se brancher sur une iface
>>> >>> > "analog.sensor.temperature.celcuis" ?
>>> >>> > et si on a plusieurs ifaces qui satisfont le truc (dans un des
>>> >>> > dernier
>>> >>> > mail
>>> >>> > on parlais les interdire les héritage similaires.)
>>> >>> >
>>> >>> > enfin dernier truc, au niveau de la regul, on a une valeur
>>> >>> > set/unset a
>>> >>> > regler, mais egalement des parametres genre seuil etc.
>>> >>> > tu pense que c'est mieux de faire une iface genre
>>> >>> > "digital.regul.switch"
>>> >>> > avec des parametre a passer dans le hash d'option
>>> >>> > ou de caller une iface par param a regler ? genre
>>> >>> > "digital.regul.switch"
>>> >>> > pour le set/unset, "analog.regul.threshold" pour le seuil, et
>>> >>> > "analog.regul.hysteresis" pour l'hystéresi.
>>> >>> > moi je pense pour une iface par //
>>> >>> > ca permet d’être extensible (genre un param a régler en plus sera
>>> >>> > toujours
>>> >>> > affiché par les client)
>>> >>> >
>>> >>> > que pense tu de tout ca (j'ai plus la mémoire tres fraiche la
>>> >>> > dessus)
>>> >>> >
>>> >>>
>>> >>>
>>> >>>
>>> >>> --
>>> >>> Tapé depuis mon clavier
>>> >>>
>>> >>>
>>> >>
>>> >
>>>
>>>
>>>
>>> --
>>> Tapé depuis mon clavier
>>>
>>>
>>
>
--
Tapé depuis mon clavier