13/04/2010, 13:45:10
Bonjour,
Le support de mysql directement dans linknx fonctionne mais je ne
l'inclus pas dans les binaires que je compile car cela obligerait tous
ceux qui veulent l'utiliser à installer mysql. Je l'ai tenté dans le
passé et j'ai reçu en retour pas mal de problèmes et
d'incompatibilités donc j'ai laissé tomber. On en a déjà discuté ici:
http://groups.google.com/group/domotique...94a2d048fd
J'aimerais trouver une autre solution qui n'imposerait pas de
dépendances à des librairies extérieures, voir même qui ne serait pas
spécifique à MySQL.
Pourquoi pas à base de script (php, perl, python, ... peu importe. Le
tout est de décider ce que le script doit recevoir de la part de
linknx.
Et c'est là que ça se complique. Certains diront sans aucune
hésitation "les adresses de groupe et les valeurs", mais j'y vois 2
inconvénients. Premièrement, les adresses de groupe sont des concepts
relatifs aux couches inférieures du protocole KNX (couche de liaison
je pense). L'interface avec la couche applicative se fait via des
objets de communications, pas des adresses de groupe. Et dans
certains cas, la valeur reçue sur une adresse de groupe prise
séparément n'a aucun sens, seul la combinaison des informations reçues
sur plusieures addresses de groupe qui à du sens (adresse de commande,
adresse de status feedback, adresses de commandes globales du style
"all off")
La seconde raison, qui est un peu une conséquence de la première,
c'est qu'au moment où linknx décode la valeur binaire, il ne sais déjà
plus par quelle adresse de groupe elle est arrivée, il sait juste à
quel objet de communication elle est associée.
Donc linknx pourrait fournir pour chaque "événement" l'ID de l'objet
concerné et la nouvelle valeur. Mais que doit il se passer si une
valeur est reçue sur le bus et que l'objet dans linknx a déjà cette
même valeur? L'événement doit il être transmis au script de logging ou
pas? A première vue, je pense que dans le cas d'objet "stateless" il
devrait être transmis mais pas dans le cas des objets normaux.
Un autre aspect est de savoir si on veut recevoir les eévénements pour
tous les objets ou seulement pour certains objets (sélectionnables par
config).
Jean-François
On 13 avr, 14:22, kraven <ohl.christo...@gmail.com> wrote:
> > Bof, une idée comme çà, rien de bien précis en fait, si ce n'est que
> > si tu veux faire un diagramme de l'évolution des températures dans le
> > temps, c'est mieux d'avoir une échelle linéaire, non ?
>
> Effectivement, mais je pensais pondre un petit algorithme pas trop
> compliqué pour justement que ce soit linéaire à l'affichage.
>
> > @kraven>Peux-tu partager ton script
>
> > Nan ! je le garde pour moi tout seul :-)
>
> > (en fait, je n'ai pas de script :-)) c'est une fonction inclus dans
> > l'usine à gaz)
>
> J'hésite de plus en plus à investir dans cette usine à gaz pour ne
> plus avoir à bidouiller ce genre de fonction mais j'attendai la sortie
> de Lifedomus pour comparer et me décider.
--
To unsubscribe, reply using "remove me" as the subject.
Le support de mysql directement dans linknx fonctionne mais je ne
l'inclus pas dans les binaires que je compile car cela obligerait tous
ceux qui veulent l'utiliser à installer mysql. Je l'ai tenté dans le
passé et j'ai reçu en retour pas mal de problèmes et
d'incompatibilités donc j'ai laissé tomber. On en a déjà discuté ici:
http://groups.google.com/group/domotique...94a2d048fd
J'aimerais trouver une autre solution qui n'imposerait pas de
dépendances à des librairies extérieures, voir même qui ne serait pas
spécifique à MySQL.
Pourquoi pas à base de script (php, perl, python, ... peu importe. Le
tout est de décider ce que le script doit recevoir de la part de
linknx.
Et c'est là que ça se complique. Certains diront sans aucune
hésitation "les adresses de groupe et les valeurs", mais j'y vois 2
inconvénients. Premièrement, les adresses de groupe sont des concepts
relatifs aux couches inférieures du protocole KNX (couche de liaison
je pense). L'interface avec la couche applicative se fait via des
objets de communications, pas des adresses de groupe. Et dans
certains cas, la valeur reçue sur une adresse de groupe prise
séparément n'a aucun sens, seul la combinaison des informations reçues
sur plusieures addresses de groupe qui à du sens (adresse de commande,
adresse de status feedback, adresses de commandes globales du style
"all off")
La seconde raison, qui est un peu une conséquence de la première,
c'est qu'au moment où linknx décode la valeur binaire, il ne sais déjà
plus par quelle adresse de groupe elle est arrivée, il sait juste à
quel objet de communication elle est associée.
Donc linknx pourrait fournir pour chaque "événement" l'ID de l'objet
concerné et la nouvelle valeur. Mais que doit il se passer si une
valeur est reçue sur le bus et que l'objet dans linknx a déjà cette
même valeur? L'événement doit il être transmis au script de logging ou
pas? A première vue, je pense que dans le cas d'objet "stateless" il
devrait être transmis mais pas dans le cas des objets normaux.
Un autre aspect est de savoir si on veut recevoir les eévénements pour
tous les objets ou seulement pour certains objets (sélectionnables par
config).
Jean-François
On 13 avr, 14:22, kraven <ohl.christo...@gmail.com> wrote:
> > Bof, une idée comme çà, rien de bien précis en fait, si ce n'est que
> > si tu veux faire un diagramme de l'évolution des températures dans le
> > temps, c'est mieux d'avoir une échelle linéaire, non ?
>
> Effectivement, mais je pensais pondre un petit algorithme pas trop
> compliqué pour justement que ce soit linéaire à l'affichage.
>
> > @kraven>Peux-tu partager ton script
>
> > Nan ! je le garde pour moi tout seul :-)
>
> > (en fait, je n'ai pas de script :-)) c'est une fonction inclus dans
> > l'usine à gaz)
>
> J'hésite de plus en plus à investir dans cette usine à gaz pour ne
> plus avoir à bidouiller ce genre de fonction mais j'attendai la sortie
> de Lifedomus pour comparer et me décider.
--
To unsubscribe, reply using "remove me" as the subject.