12/03/2011, 19:43:21
Une mine d' or d informations a harder au chaud !!!
Concernant io port çela permettrais t'il de lire une interface teleinfo sur un com ?
Le 12 mars 2011 à 17:50, jef2000 <jef2000@ouaye.net> a écrit :
>>> * Do not execute stateless rules at init (problem with object conditions
>>> because EIBD connection not yet established)
>>
>> Ca c'est la condition "if-true", non ?
> "if-true" existait déjà dans la release précedente, mais j'avais
> décidé (je ne sais plus trop pourquoi) d'évaluer la condition et de
> forcer l'exécution de la liste d'actions correspondante juste après la
> création de la règle. Mais comme ça pose d'autres soucis, j'ai décidé
> de ne plus le faire
>
>>> * Add condition to compare 2 objects (requires complete refactoring of
>>> Object and ObjectValue classes)
>> Pas compris...
> Pour l'instant, il existe une condition pour comparer la valeur d'un
> objet à une constante mais pas pour comparer 2 valeurs d'objets entre
> elles. Donc je l'ai ajoutée.
> Ca ressemble à :
> <condition type="object-compare" id="temp_salon"
> id2="consigne_temp_salon" op="lt" />
>
>>> * Fix for exportXML with Object-Conditions without value (michael111)
>> Pas compris...
> Par exemple, si tu utilise une condition sur un objet sans spécifier
> la valeur:
> <condition type="object" id="ecl_couloir" trigger="true" />
> La condition sera évaluée à chaque fois que l'objet est mis à jour
> mais le résultat est toujours "true". Et donc ça permet avec un action-
> list "if-true" d'exécuter cette dernière à chaque mise à jour de la
> valeur. Si l'objet possède en plus le flag "s", il sera mis à jour
> même si la valeur ne change pas. Donc si tu as un poussoir qui envoie
> uniquement un ON sur une adresse de groupe quand on appui dessus, tu
> utilises un objet avec le flag "s", une condition comme ci-dessus et
> un action-list de type "if-true" et les actions seront exécutées Ã
> chaque pression du poussoir.
>
>>> * Add "repeat" action that repeats a list of actions periodically a
>>> specified number of times
>> Un exemple ?
> Pour transformer ta maison en stroboscope pendant 20 secondes:
> <action type="repeat" period="200ms" count="100">
> <action type="toggle-value" id="ecl-salon" />
> <action type="toggle-value" id="ecl-couloir" />
> <action type="toggle-value" id="ecl-chambre" />
> <action type="toggle-value" id="ecl-cuisine" />
> </action>
>
>>> * Add "cancel" action to cancel all ongoing actions of a rule
>> Un exemple ?
> <action type="cancel" rule-id="strobo" />
> Permet par exemple de stopper le stroboscope ci-dessus (supposant que
> l'id dans le tag "rule" du stroboscope est "strobo").
> Ca permet également d'annuler des actions qui ont été lancées mais pas
> encore exécutées à cause de leur paramètre delay="..."
>
>>> * Add "send-read-request" action that will force sending of a read
>>> request on the bus
>> Pas compris...
> Si un appareil n'est pas configuré pour envoyer périodiquement la
> valeur d'un objet, il n'était pas possible a linknx d'envoyer l'ordre
> de lecture sur le bus (comme on pourrait le faire avec la commande
> groupread de eibd). Maintenant c'est possible.
> <action type="send-read-request" id="valeur_compteur_gaz" />
>
>>> * Add attribute read="true" for listener address which is used to send
>>> read request on the bus
>> Pas compris...
> Si tu utilise le paramètre init="request" dans la définition d'un
> objet, linknx envoie une requète de lecture sur le bus dès la première
> tentative d'accès à la valeur de l'objet. La requète de lecture
> utilise l'adresse de groupe principale de l'objet. Donc si tu définis
> un objet et que tu ajoute l'adresse du retour d'état comme "listener",
> l'initialisation utilise l'adresse principale et pas celle du retour
> d'état, qui pourtant pourrait donner une info plus fiable. Donc j'ai
> ajouté un paramètre read="true" dans le listener pour forcer les
> requètes de lecture à utiliser cette adresse plutôt que l'adresse
> principale.
>
>
>>> * Initial schedule for timers with at and *during* fixed (michael111)
>> Pas compris...
> C'est juste un bugfix
>
>>> * Support for serial IO port
>> Un exemple ?
> Dans la section <services>, ajoute:
> <ioports>
> <ioport id="test-serial" type="serial" dev="/dev/ttyS0" speed="9600"
> framing="8N1"/>
> </ioports>
> Puis tu peux l'utiliser comme n'importe quel io-port. Exemple:
> <action type="ioport-tx" ioport="test-serial" data="Hello world!" />
> Ou si tu veux envoyer des données binaires:
> <action type="ioport-tx" ioport="test-serial" data="FF302D22A5"
> hex="true" />
>
>>> * Allow multiple messages in receive buffer (Mike Pieper)
>> Pas compris...
> Si tu utilises une application qui envoie directement des commandes
> XML sur le port 1028 de linknx, maintenant tu peux envoyer plusieurs
> commandes en une seule opération. Avant, on ne pouvait envoyer qu'une
> seule requète à la fois.
>
>>> * Add command to Register/Unregister all objects for notification (Mike
>>> Pieper)
>> Pas compris...
> Ca aussi c'est pour les applications qui utilisent directement
> l'interface XML. Elles peuvent demander à linknx de leur envoyer un
> message chaque fois qu'un objet change de valeur. Ca pourrait par
> exemple être utilisé par un script qui sauvegarde des infos dans une
> base de données, comme ça on évite toute les complications liées au
> support de mysql directement dans linknx.
>
>>> * Better command-line parameter error reporting (Mike Pieper)
>> Pas compris...
> Par exemple, si tu utilises la commande linknx -c house.xml (avec un
> espace de trop après le -c, l'erreur rapportée était "unexpected
> parameter", maintenant il renseigne au moins quel paramètre est
> inattendu.
>
>>> * Fixes the XML for a notification message (Mike Pieper)
>> Pas compris...
> Juste un bug dans l'XML généré dans les notification dont on a déjÃ
> parlé plus haut.
>
> Jean-François
Concernant io port çela permettrais t'il de lire une interface teleinfo sur un com ?
Le 12 mars 2011 à 17:50, jef2000 <jef2000@ouaye.net> a écrit :
>>> * Do not execute stateless rules at init (problem with object conditions
>>> because EIBD connection not yet established)
>>
>> Ca c'est la condition "if-true", non ?
> "if-true" existait déjà dans la release précedente, mais j'avais
> décidé (je ne sais plus trop pourquoi) d'évaluer la condition et de
> forcer l'exécution de la liste d'actions correspondante juste après la
> création de la règle. Mais comme ça pose d'autres soucis, j'ai décidé
> de ne plus le faire
>
>>> * Add condition to compare 2 objects (requires complete refactoring of
>>> Object and ObjectValue classes)
>> Pas compris...
> Pour l'instant, il existe une condition pour comparer la valeur d'un
> objet à une constante mais pas pour comparer 2 valeurs d'objets entre
> elles. Donc je l'ai ajoutée.
> Ca ressemble à :
> <condition type="object-compare" id="temp_salon"
> id2="consigne_temp_salon" op="lt" />
>
>>> * Fix for exportXML with Object-Conditions without value (michael111)
>> Pas compris...
> Par exemple, si tu utilise une condition sur un objet sans spécifier
> la valeur:
> <condition type="object" id="ecl_couloir" trigger="true" />
> La condition sera évaluée à chaque fois que l'objet est mis à jour
> mais le résultat est toujours "true". Et donc ça permet avec un action-
> list "if-true" d'exécuter cette dernière à chaque mise à jour de la
> valeur. Si l'objet possède en plus le flag "s", il sera mis à jour
> même si la valeur ne change pas. Donc si tu as un poussoir qui envoie
> uniquement un ON sur une adresse de groupe quand on appui dessus, tu
> utilises un objet avec le flag "s", une condition comme ci-dessus et
> un action-list de type "if-true" et les actions seront exécutées Ã
> chaque pression du poussoir.
>
>>> * Add "repeat" action that repeats a list of actions periodically a
>>> specified number of times
>> Un exemple ?
> Pour transformer ta maison en stroboscope pendant 20 secondes:
> <action type="repeat" period="200ms" count="100">
> <action type="toggle-value" id="ecl-salon" />
> <action type="toggle-value" id="ecl-couloir" />
> <action type="toggle-value" id="ecl-chambre" />
> <action type="toggle-value" id="ecl-cuisine" />
> </action>
>
>>> * Add "cancel" action to cancel all ongoing actions of a rule
>> Un exemple ?
> <action type="cancel" rule-id="strobo" />
> Permet par exemple de stopper le stroboscope ci-dessus (supposant que
> l'id dans le tag "rule" du stroboscope est "strobo").
> Ca permet également d'annuler des actions qui ont été lancées mais pas
> encore exécutées à cause de leur paramètre delay="..."
>
>>> * Add "send-read-request" action that will force sending of a read
>>> request on the bus
>> Pas compris...
> Si un appareil n'est pas configuré pour envoyer périodiquement la
> valeur d'un objet, il n'était pas possible a linknx d'envoyer l'ordre
> de lecture sur le bus (comme on pourrait le faire avec la commande
> groupread de eibd). Maintenant c'est possible.
> <action type="send-read-request" id="valeur_compteur_gaz" />
>
>>> * Add attribute read="true" for listener address which is used to send
>>> read request on the bus
>> Pas compris...
> Si tu utilise le paramètre init="request" dans la définition d'un
> objet, linknx envoie une requète de lecture sur le bus dès la première
> tentative d'accès à la valeur de l'objet. La requète de lecture
> utilise l'adresse de groupe principale de l'objet. Donc si tu définis
> un objet et que tu ajoute l'adresse du retour d'état comme "listener",
> l'initialisation utilise l'adresse principale et pas celle du retour
> d'état, qui pourtant pourrait donner une info plus fiable. Donc j'ai
> ajouté un paramètre read="true" dans le listener pour forcer les
> requètes de lecture à utiliser cette adresse plutôt que l'adresse
> principale.
>
>
>>> * Initial schedule for timers with at and *during* fixed (michael111)
>> Pas compris...
> C'est juste un bugfix
>
>>> * Support for serial IO port
>> Un exemple ?
> Dans la section <services>, ajoute:
> <ioports>
> <ioport id="test-serial" type="serial" dev="/dev/ttyS0" speed="9600"
> framing="8N1"/>
> </ioports>
> Puis tu peux l'utiliser comme n'importe quel io-port. Exemple:
> <action type="ioport-tx" ioport="test-serial" data="Hello world!" />
> Ou si tu veux envoyer des données binaires:
> <action type="ioport-tx" ioport="test-serial" data="FF302D22A5"
> hex="true" />
>
>>> * Allow multiple messages in receive buffer (Mike Pieper)
>> Pas compris...
> Si tu utilises une application qui envoie directement des commandes
> XML sur le port 1028 de linknx, maintenant tu peux envoyer plusieurs
> commandes en une seule opération. Avant, on ne pouvait envoyer qu'une
> seule requète à la fois.
>
>>> * Add command to Register/Unregister all objects for notification (Mike
>>> Pieper)
>> Pas compris...
> Ca aussi c'est pour les applications qui utilisent directement
> l'interface XML. Elles peuvent demander à linknx de leur envoyer un
> message chaque fois qu'un objet change de valeur. Ca pourrait par
> exemple être utilisé par un script qui sauvegarde des infos dans une
> base de données, comme ça on évite toute les complications liées au
> support de mysql directement dans linknx.
>
>>> * Better command-line parameter error reporting (Mike Pieper)
>> Pas compris...
> Par exemple, si tu utilises la commande linknx -c house.xml (avec un
> espace de trop après le -c, l'erreur rapportée était "unexpected
> parameter", maintenant il renseigne au moins quel paramètre est
> inattendu.
>
>>> * Fixes the XML for a notification message (Mike Pieper)
>> Pas compris...
> Juste un bug dans l'XML généré dans les notification dont on a déjÃ
> parlé plus haut.
>
> Jean-François