26/06/2007, 20:32:22
> Effectivement, tu as mentionné les applications les plus employées.
> Mais la Visu ? je n'ai pas compris comment tu fais !
Pour l'instant, je commande le tout via le petit serveur web intégré
a mon routeur wifi.
J'ai des scripts CGI qui appellent des petits programme permettant de
commuter et lire l'état des différents actionneurs, lire les
températures des thermostats, changer leur mode de fonctionnement
etc... Ces petits programmes en ligne de commande ont été écrits sur
la base des exemples fournis avec EIBD.
J'ai également connecté une passerelle ethernet-bluetooth pour pouvoir
consulter cette interface web avec un vieux Palm Tungsten qui me sert
de télécommande de luxe.
Le problème, c'est que ni EIBD ni les petits programmes appelés par
l'interface web ne retiennent l'état actuel d'une requête à l'autre,
ce qui les oblige à chaque fois lire cet état via le bus sur le
participant concerné. Pour la page qui affiche la température et le
mode (confort, standby, nuit ou protection-gel) des thermostats de
chaque pièce, ça devient un peu lourd (2 à 3 seconde chaque fois que
j'affiche la page). D'où mon idée de développer une nouvelle
application et tant qu'a faire lui en demander beaucoup plus que ce
qui n'était possible avant.
> Je ne sais pas si c'est applicable dans ton cas, mais une librairie de
> fonctions est très utile (logic: AND, OR, math: Sin, Cos, Tang etc).
> Ca permet de créer des fonctions de haut niveau, sans chaque fois
> faire un développement spécifique à la demande.
Je n'en ai pas parlé dans mon premier message mais en fait, c'est à la
base de la solution que je compte mettre en oeuvre.
L'idée est de partir d'un fichier de configuration xml décrivant une
série de conditions et d'actions à exécuter lorsque ces conditions se
vérifient. Une condition de base peut être un changement d'état de
l'un des objets de groupe EIB, d'une variable interne, l'expiration
d'un timer, etc... On peut également combiner ces conditions de base
vie les fonctions logiques dont tu parlais. Cela permet déjà pas mal
de chose, des fonctionnalités comme l'alarme ou le simulateur de
présence par exemple peuvent sans trop de problèmes être exprimés via
ce genre de règles.
Les règles seraient donc chargées au démarrage depuis le fichier xml,
il serait ensuite possible d'en ajouter via une interface web et de re-
sauvegarder le tout au format xml de manière à les conserver lors des
redémarrages ou coupures de courant.
Voici un exemple de configuration qui allume la lumière de ma chambre
progressivement entre 6H30 et 7H les jours de semaine, si on est
présent (j'ai un interrupteur près de la porte d'entrée qui me permet
de signaler lorsque la maison n'st pas occupée) et si le réveil est
activé (comme tout bon réveil, faut bien un moyen de le couper)
La condition est évaluée à chaque fois qu'une de ses conditions de
base marquée d'un " trigger='true' " a changé.
<?xml version="1.0" ?>
<config>
<rule id='wakeup_alarm'>
<condition type='and'>
<condition type='eib' trigger='false'>
<object id='presence'>
<value>false</value>
</condition>
<condition type='eib' trigger='false'>
<object id='wakeup_enabled'>
<value>true</value>
</condition>
<condition type='timer' trigger='true'>
<at>30 6 * * 1,2,3,4,5</at>
</condition>
</condition>
<action type='dim-up'>
<id>dim_chambre2</id>
<start>0</start>
<stop>240</stop>
<delay>1800</delay>
</action>
<action type='set'>
<id>chauffage_cuisine</id>
<value>comfort</value>
</action>
</rule>
<objects>
<knxConnection line='1/1' url="ip:192.168.0.10"/>
<object id='presence' gad='1/1/60'>Presence</object>
<object id='dim_chambre2' gad='1/1/45' type='EIS6'>Dimmer
chambre 2</object>
<object id='wakeup_enabled' gad='1/2/1'
persistent='true'>Réveil activé</object>
</objects>
</config>
> Exemple: un parser web, cela m'a permis d'afficher les prévisions
> météo sur 12 jours, en faisant des extracts d'un site web météo.
> Autre exemple: la fonction "total" me permet de voir le nombre de
> lampes allumées
>
> Toutes mes félicitations.
> Mais la Visu ? je n'ai pas compris comment tu fais !
Pour l'instant, je commande le tout via le petit serveur web intégré
a mon routeur wifi.
J'ai des scripts CGI qui appellent des petits programme permettant de
commuter et lire l'état des différents actionneurs, lire les
températures des thermostats, changer leur mode de fonctionnement
etc... Ces petits programmes en ligne de commande ont été écrits sur
la base des exemples fournis avec EIBD.
J'ai également connecté une passerelle ethernet-bluetooth pour pouvoir
consulter cette interface web avec un vieux Palm Tungsten qui me sert
de télécommande de luxe.
Le problème, c'est que ni EIBD ni les petits programmes appelés par
l'interface web ne retiennent l'état actuel d'une requête à l'autre,
ce qui les oblige à chaque fois lire cet état via le bus sur le
participant concerné. Pour la page qui affiche la température et le
mode (confort, standby, nuit ou protection-gel) des thermostats de
chaque pièce, ça devient un peu lourd (2 à 3 seconde chaque fois que
j'affiche la page). D'où mon idée de développer une nouvelle
application et tant qu'a faire lui en demander beaucoup plus que ce
qui n'était possible avant.
> Je ne sais pas si c'est applicable dans ton cas, mais une librairie de
> fonctions est très utile (logic: AND, OR, math: Sin, Cos, Tang etc).
> Ca permet de créer des fonctions de haut niveau, sans chaque fois
> faire un développement spécifique à la demande.
Je n'en ai pas parlé dans mon premier message mais en fait, c'est à la
base de la solution que je compte mettre en oeuvre.
L'idée est de partir d'un fichier de configuration xml décrivant une
série de conditions et d'actions à exécuter lorsque ces conditions se
vérifient. Une condition de base peut être un changement d'état de
l'un des objets de groupe EIB, d'une variable interne, l'expiration
d'un timer, etc... On peut également combiner ces conditions de base
vie les fonctions logiques dont tu parlais. Cela permet déjà pas mal
de chose, des fonctionnalités comme l'alarme ou le simulateur de
présence par exemple peuvent sans trop de problèmes être exprimés via
ce genre de règles.
Les règles seraient donc chargées au démarrage depuis le fichier xml,
il serait ensuite possible d'en ajouter via une interface web et de re-
sauvegarder le tout au format xml de manière à les conserver lors des
redémarrages ou coupures de courant.
Voici un exemple de configuration qui allume la lumière de ma chambre
progressivement entre 6H30 et 7H les jours de semaine, si on est
présent (j'ai un interrupteur près de la porte d'entrée qui me permet
de signaler lorsque la maison n'st pas occupée) et si le réveil est
activé (comme tout bon réveil, faut bien un moyen de le couper)
La condition est évaluée à chaque fois qu'une de ses conditions de
base marquée d'un " trigger='true' " a changé.
<?xml version="1.0" ?>
<config>
<rule id='wakeup_alarm'>
<condition type='and'>
<condition type='eib' trigger='false'>
<object id='presence'>
<value>false</value>
</condition>
<condition type='eib' trigger='false'>
<object id='wakeup_enabled'>
<value>true</value>
</condition>
<condition type='timer' trigger='true'>
<at>30 6 * * 1,2,3,4,5</at>
</condition>
</condition>
<action type='dim-up'>
<id>dim_chambre2</id>
<start>0</start>
<stop>240</stop>
<delay>1800</delay>
</action>
<action type='set'>
<id>chauffage_cuisine</id>
<value>comfort</value>
</action>
</rule>
<objects>
<knxConnection line='1/1' url="ip:192.168.0.10"/>
<object id='presence' gad='1/1/60'>Presence</object>
<object id='dim_chambre2' gad='1/1/45' type='EIS6'>Dimmer
chambre 2</object>
<object id='wakeup_enabled' gad='1/2/1'
persistent='true'>Réveil activé</object>
</objects>
</config>
> Exemple: un parser web, cela m'a permis d'afficher les prévisions
> météo sur 12 jours, en faisant des extracts d'un site web météo.
> Autre exemple: la fonction "total" me permet de voir le nombre de
> lampes allumées
>
> Toutes mes félicitations.