Life Domus : un projet domotique KNX prometteur !

Life Domus

Je discute par eMail avec Gilles depuis quelques temps à propos de son projet Life Domus. Il m’a transmis un certain nombre d’éléments afin de me rendre compte de l’étendue du travail réalisé et des possibilités de son système.

Ne trouvant pas son compte dans ExDomus, Gilles a tout simplement créé sa propre interface de contrôle KNX sous Windows et Linux. Cette interface permet également de gérer ses médias à la manière de Windows Media Center : films, musique, photos, live TV (ce dernier service étant en étude de faisabilité pour l’instant). Life Domus y ajoute bien entendu la possibilité de la diffusion multiroom. Tout passe par le réseau, aussi bien le contrôle que la diffusion dans chaque pièce.

Life Domus a été créé par Gilles pour sa maison. Aujourd’hui, le système n’est donc pas transposable tel quel. Techniquement, pas mal de choses sont à configurer en dur. Cependant, une évolution du système est prévue, mais pour les intégrateurs uniquement. Le particulier ne pourra pas acquérir Life Domus directement. Ainsi, les intégrateurs auront le support auprès de Gilles pour la mise en place et les mises à jour de Life Domus.

Life Domus

Ce qui saute immédiatement aux yeux, c’est évidemment la partie graphique très aboutie, avec une véritable constance entre les écrans, ce qui améliore forcément l’ergonomie ! Et si la technique suit, ce dont je ne doute pas, alors le système Life Domus a cet atout indispensable qui peut faire la différence.

Je vous tiendrai au courant des évolutions de Life Domus. Notre position d’intégrateur utilisant, entre autre, Windows Media Center et KNX fait que nous nous intéressons fortement au travail de Gilles.

Le blog Life Domus

11 commentaires

  1. Installateur Crestron et AMX, je dois avouer que c’est le premier produit de type Media Center qui retient mon attention.

    La notion même de produit hautement configurable passe par une installation par des intégrateurs, ce qui rejoint la politique d’AMX et de Crestron.

    Le problème de tous les logiciels préconfigurés, c’est que, quels que soient le génie de leurs concepteurs, on est peu ou prou cantonné aux scénarios qu’ils ont prévues.

    J’espère que ce très beau logiciel disposera d’un langage de script évolué pour s’adapter à toutes les situations.

    A+
    Vincent

  2. Bonjour,

    C’est surement un produit interessant mais quand tu cites que “Tout passe par le réseau, aussi bien le contrôle que la diffusion dans chaque pièce”
    Cela veut dire quoi exactement ? controler KNX par le réseau, je vois trés bien comment cela peut fonctionner, mais la multi diffusion par le réseau, cela sous entend quoi ?
    Merci
    Thierry

  3. Bonsoir,

    J’ai distingué 3 cas :

    a) KNX-WHD : on reste dans le monde KNX pure. Donc rien de spéciale, le logiciel envoie des ordres vers le module ou la source à déclencher

    b) 1 serveur, n PCs clients : le serveur/NAS/etc… stockent les données multimedia. Principe classique de partage de fichier. Ensuite, chaque PC, dédié à une pièce, formule une requête au serveur pour lancer une musique ou un film soit en local, soit vers un autre PC cible. Le serveur déclenche sur le bon client la requête.
    Ainsi on peut quitter la cuisine et lancer un film depuis la cuisine dans le salon.

    c) 1 serveur, 8 Ecrans : la vidéo est envoyé sur l’écran souhaité (limite de 8 écrans = windows). Le souci provient que si l’on lit plusieurs fichiers multimédia simultanément, l’image sera bien gérée mais le son sera mixé et cacophonique.
    D’où l’idée pour limité le nombre de PC de piloter une carte son multiroom interne (cela commence à pointer le nez).
    Souci : existe-t-il des API qui permettent de piloter les sorties. J’ai formulée une demande au fabriquant, j’ai pas encore de réponse. Mais j’ai bon espoir.

    Gilles

  4. Gilles,

    Concernant le point c, pourquoi ne pas utiliser des set-top boxes types AminNet Amino 110 ?

    C’est très sympa, pas trop cher et la qualité est pas mal.

    Ca demande un réseau capable de streamer pas mal de choses.

    Concernant les cartes son, il est possible d’en installer plusieurs, après, ca dépend du logiciel de lecture de vidéo, certains permettent de réorienter le flux vers telle ou telle carte son.

    L’idéal étant Linux et sa couche ALSA, j’ai une bonne expérience avec des M-Audio Revo 7.1 reconverties en 8 canaux mono indépendant grace à un fichier alsa.conf qui va bien.

    Encore une fois, y’aura-t’il à terme un langage de script ? C’est très lourd à mettre en place, je sais. Mais c’est ce qui fait a force des solutions Crestron/AMX.

    A+
    Vincent

  5. Bonsoir,

    Je ne me suis pas encore penché sur le langage script mais l’idée à terme serait d’en avoir un non propriétaire : je m’explique.

    Je migre actuellement la totalité des données, services, serveurs de requêtes, et couche KNX dans une base MySQL. L’objectif est que chaque service soit indépendant et en cas d’interaction sur la base, que les serveurs de requêtes prennent le relai pour traiter la modification et la transmettre aux clients.

    Du coup, les déclencheurs, les fonctions logiques, etc… deviennent également des services en soit que les serveurs de requêtes pourront traiter en flux entrant.

    Force de cela : comme la base est libre en lecture/écriture, l’utilisateur peut utiliser n’importe quel langage pour écrire du code qui scrute la base et si des valeurs combinées deviennent déclencheuses d’un traitement, ce script écrit alors une requête dans la queue du serveur de requêtes qui la traite comme requête externe.

    Bien évidemment, il faut connaitre un langage de programmation : java, dotnet, etc… qui peut en odbc se connecter à la base pour lire les données souhaitées… et écrire les requêtes souhaitées.

    Exemple de stockage des données KNX courant :
    ———————————————
    Adresse Valeur
    0/0/1 17/08/2008
    0/0/3 1

    — Script externe mode algo —
    Connexion DB;
    Si GetValue(0/0/1) = “17/08/2008” AND
    GetValue(0/0/3) = “1” Alors
    SetValue(0/1/2) = 1 ; SetValue(0/1/3) = 0 ;
    Fin Si
    Fin connexion DB;
    — Fin script —-

    Exemple de requête
    ——————
    id tech Computer Qui Adresse Nouvelle valeur Quand
    12547 SRV01 Salon 0/1/2 1 22:22:14
    12548 SRV01 Salon 0/1/3 0 22:22:15

    Ceci fonctionne déjà ainsi pour le mode R/W avec le programme LifeDomus.
    Ensuite, pour éviter les connexions DB, je créerai les services WEB SOAP sous IIs 7 qui permette de lire (XML, ou valeur directe) une valeur et écrire une requête de maj d’une adresse.

    Pensez-vous que cela puisse être une bonne voie et ainsi répondre aux plus grand nombre ? Je voudrai éviter d’écrire une syntaxe : d’autre l’on fait mieux que moi, et VB scripts par exemple pourrait suffir à faire de bien nombreuses combinaisons.

    Si je fais fausse route, n’hésitez pas à me critiquer (pareil si j’ai pas été clair – c’est plus facile dans la tête que sur le papier parfois).

    Gilles

  6. En fait, je n’ai à peu près rien compris à ce que vous racontez :P, mais c’est sans doute de ma faute. J’ai notamment du mal à comprendre vos requètes et même comment on peut s’appuyer sur un SGBD pour déclencher des actions… Mais j’ai des lacunes et j’en suis conscient !

    Voici comment fonctionnent les automates avec lesquels je travaille (Crestron / AMX) :

    Ils fonctionnent en mode évènementiel, et font correspondre des entrées et des sorties.

    En gros, l’automate reçoit une donnée en entrée (contact, appui sur un bouton, trame RS232, trame IP d’un client/serveur, réception IR, etc), traite ces données d’entrée en fonction de son programme, et agit en conséquence sur ses sorties (RS232, IP, IR, relayage, etc…)

    La partie la plus complexe est celle qui consiste à traiter les données.

    Le fait est que les deux langages sont des langages évènementiels : les deux systèmes AMX et Crestron disposent d’un event mananger qui mache le travail du programmeur. En gros, inutile de programmer des boucles, des scrutations, l’OS de l’automate scrute les entrées en permanence et agit en conséquence (un peu comme du VB).

    Ce qui me gène dans la solution proposée (polling permanent d’une base de données, si j’ai bien compris), c’est qu’il faut pouvoir régler l’intervalle de temps entre deux requètes sans charger la base de données outre mesure mais en permettant toutefois une réponse quasi instantanée du système…

    La plupart du temps, une base de donnée n’est pas nécessaire, les données sensibles peuvent être stockées dans la mémoire non volatile de l’automate ou dans un fichier texte sur son disque, sauvegardable via FTP, ce qui évite la maintenance d’un SGBD (suffisant pour des volumes de donnée peu importants, comme des consignes de température pièce par pièce ou des scénariis de gradation lumière). L’intéret de la base de donnée devient évident dans le cas de volume de données important (catalogue multimédia, etc).

    Voilà mon avis, mais je n’ai pas bien compris vos explication, donc je me trompe peut-être sur vos explications.

    A+ et bon courage,
    Vincent

  7. Bonsoir Vincent,

    Le module coupleur que j’utilise embarque un mini-OS à l’écoute des trames qui passent et en cas de modification avérée déclenche un EVENT récupéré par le programmeur.

    Lorsque l’on a un seul PC et un seul module, on ne fait pas de pooling base, puisque l’on ne fait qu’utiliser directement les données mémorisées dans le mini-OS.

    Si l’on résonne multi PC, cela devient plus délicat pour dégager un solution. On a que peu possibilités (que je connaisse) :

    a) soit au met un coupleur par PC, et donc on a pas de souci particulier (mais là : augmentation du coup à l’achat des coupleurs)

    b) soit on limite les coupleurs à un seul, et là on entre dans ‘comment communiquer aux autres PCs qui n’ont pas le coupleur les valeurs changées ? ‘

    J’ai développé 3 versions pour l’instant, mais aucune ne me satisfait vraiment :
    a) Installation Oracle et utilisation des PIPE nommés
    On créé entre le PC qui a le coupleur (le serveur KNX) des canaux de commmunications bidirectionnels (équivaut à 2 pipes en Oracle) dédiés à chaque client. En cas de détection d’une modification, le serveur communique dans les pipes de tous les clients la nouvelle valeur et chaque clients la dépile dès sa réception.
    Problème : gérer la stabilité en cas d’éventuel problème réseaux (rupture des pipes et relance automatique, timeout…), s’affranchir de la licence Oracle en cas de diffusion, lourdeur d’Oracle pour juste utiliser les pipes et quelques tables de paramètres

    b) utilisation de socket IP : cela fonctionne globalement comme le pipe, mais sans Oracle (très schématique). Le souci est de redévelopper les couches sockets (serveur et clients sockets, ou de s’affranchir d’ocx parfois très onéreux dès lors qu’on les veut professionnels et stables)

    c) la base mySQL avec pooling : la solution la moins pire POUR L’INSTANT, la moins coûteuse aussi : on travaille à maximum la 1/2 seconde de réaction entre l’action et la réaction.
    Cette solution permet de devenir ouvert à n’importe quel programmeur désireux de se mettre en attente d’une donnée avec sa… propre interface. Cette solution me permet aussi de modifier très facilement Life Domus, pour utiliser Life Domus au bureau ou via des bornes Wifi gratuite avec son PC portable : en effet, ‘LifeDomus.Exe /web’ ne fera plus des requêtes SQL sur la table mais demandera au service Web SAOP sous IIs de lui communiquer les valeurs.

    Les sockets (qui utilisent des ports dédiés) ne passent par exemple par les firewall de certaines entreprises : Life Domus le pourra puisqu’il s’appuiera sur du HTTP ou du HTTPS qui est bien moins filtré en entreprise ou sur des bornes Wifi publiques (sans compter les configurations des routeurs perso et firewall perso qui bloquent les ports).

    Désolé pour mes explications confuses d’hier soir, c’est pas toujours évidement de synthétiser… J’ai épuisé mes capsules de café (-:).

    J’ai trouvé vous remarques très enrichissantes et si une autre solution de communication pouvait se dégager, je suis prêt à essayer sa mise en oeuvre…

    Gilles

  8. Bonsoir Gilles,

    Je comprends mieux.

    Quelle interface EIB/KNX utilisez vous ? Comment se branche-t’elle sur le PC ? J’en connais plusieurs et j’en ai utilisé une avec succès : de marque Elka, la KNX Gateway, ou plutôt sa version rebadgée par Crestron CG-EIB. Elle s’interface en RS232 ou 485. Avantage, elle se programme et permet de filtrer les adresses de groupe pertinentes pour l’applicatif considéré. Le prix est élevé, de l’ordre de 1000 euros. Vity propose une interface EIB/Lan qui semble bien fonctionner, le prix est similaire il me semble.

    Le problème, si j’ai bien compris, c’est de pouvoir transmettre les informations de la première interface à toutes les machines du réseau. Pourquoi ne pas envisager un brodcast UDP ? Pour l’application distante, un serveur Web fait l’affaire.

    Il est vrai que tous ces problèmes sont gommés par l’architecture d’un automate Crestron ou AMX, la transmission de données entre différents controleurs se fait de manière transparente pour le programmeur. Avantage des OS temps réels embarqués, on ne perçoit pas de latence.

    Sinon, on peut envisager une structure différente. Ce qui coûte cher, c’est l’interface bidirectionnelle EIB. Le controle de ce qui se passe sur le bus peut se faire avec une interface passive à 3 francs 6 sous dont on trouve les schémas sur le net. Avantage, il n’y a pas besoin de broadcaster sur le lan ce qui se passe sur l’EIB, chacun des serveurs écoutant directement le bus de manière passive. Par contre, le controle se fera automatiquement via la machine disposant de l’interface bi-directionnelle.

    A+
    Vincent

  9. Bonjour,

    Je ne connais pas votre système en détail mais à en lire votre description, je pencherais vers la solution de l’architecture 3 tiers, avec un serveur d’application pour gérer la communication entre le serveur de base de données et les postes clients. Reste à voir le protocole de communication à utiliser, il y a effectivement soap mais aussi corba qui est peut être plus performant dans le cas de requêtes multiples et volumineuses.
    C’est à étudier. 🙂

    Thierry

  10. Life Domus + Linux : Migration envisagée pour le serveur…

    Bonsoir,

    Est-ce que Linux pour la partie Service KNX serait un bon choix.
    Le serveur DB MySQL semble se décliner sur cette plateforme.

    http://dev.mysql.com/doc/refman/5.0/en/linux-rpm.html

    Ensuite il reste à choisir la version de Linux :

    http://www.linux.com/

    Il y en a pas mal, donc quitte à faire des tests, autant partir sur une plateforme qui serait celle majoritairement souhaitée (j’attends vos retours d’expérience sur la version).

    Ensuite, il me reste à développer la partie Serveur KNX. Deux options :
    – j’installe le kit de développement adéquate (je vais me rapprocher de la firme qui gère le coupleur)
    – je mandate la firme du coupleur pour écrite à ISO-fonctionnalité l’équivalent très simple du service KNX Windows

    Sous toute réserve technique sur ce coupleur précis dans le monde Linux, sachant que la firme en question a des produits compatibles Linux, donc au pire, il va me falloir modifier le coupleur pour cet environnement ci.

    Qu’en pensez-vous ?
    Sous toute réserve de mes compétences Linux (5 ans que j’ai plus touché).
    G.A.

Laissez un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *