> 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