12/03/2011, 22:21:52
Salut,
A terme, cela devrait être possible. Pour l'instant, en réception il
permet juste de déclencher une "rule" lorsque le message reçu contient
une chaine de caractère prédéfinie. Ca marche très bien par exemple
avec un récepteur IRtrans qui envoie sur un port UDP des messages
texte contenant les identifiants des touches de télécommandes.
Mis à part le fait que les modules téléinfo communiquent à 1200 bauds
et que dans linknx j'ai actuellement mis la limite inférieure à 2400,
juste parce que je me disais qu'en dessous ca n'avait aucun intérêt.
Je corrigerai ça pour la prochaine version.
Donc, mis à part ce petit détail, il devrait déjà être possible de
faire des choses basiques comme commuter qqch selon le tarif, mais pas
encore de récupérer des données comme la consommation instantanée.
Pour récupérer des données, j'imagine qu'il faudrait un système de
matching basé sur un motif définis (par ex. des expressions
régulières) et la possibilité de sélectionner des parties de messages
et de les copier dans des objets de linknx. Pas une mince affaire,
quoi...
Jean-François
On 12 mar, 19:43, Jupin Yannick <yann...@magikdo.com> wrote:
> 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 <jef2...@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
>
>
A terme, cela devrait être possible. Pour l'instant, en réception il
permet juste de déclencher une "rule" lorsque le message reçu contient
une chaine de caractère prédéfinie. Ca marche très bien par exemple
avec un récepteur IRtrans qui envoie sur un port UDP des messages
texte contenant les identifiants des touches de télécommandes.
Mis à part le fait que les modules téléinfo communiquent à 1200 bauds
et que dans linknx j'ai actuellement mis la limite inférieure à 2400,
juste parce que je me disais qu'en dessous ca n'avait aucun intérêt.
Je corrigerai ça pour la prochaine version.
Donc, mis à part ce petit détail, il devrait déjà être possible de
faire des choses basiques comme commuter qqch selon le tarif, mais pas
encore de récupérer des données comme la consommation instantanée.
Pour récupérer des données, j'imagine qu'il faudrait un système de
matching basé sur un motif définis (par ex. des expressions
régulières) et la possibilité de sélectionner des parties de messages
et de les copier dans des objets de linknx. Pas une mince affaire,
quoi...
Jean-François
On 12 mar, 19:43, Jupin Yannick <yann...@magikdo.com> wrote:
> 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 <jef2...@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
>
>