Journal Jour, nuit, jour, nuit, jour...

Posté par  .
Étiquettes : aucune
10
4
sept.
2009
Une équipe de joyeux lurons s'est livrée à une petite expérimentation dans le domaine de la domotique. L'originalité de cette expérience tient en quatre mots: Extensible Messaging and Presence Protocol que nous connaissons plus simplement sous l'acronyme XMPP.

En effet, à partir d'un simple smartphone (ici un gphone), ils ont réussi à piloter l'allumage et l'extinction d'une bête lampe de bureau reliée à un ordinateur.

Le montage logique est simplissime:

- deux clients XMPP sur le smartphone et le portable (strophe et XIFF)
- un serveur XMPP (OpenFire)

D'un point de vue purement technique, rien de bien compliqué par contre côté XMPP, c'est une nouvelle preuve de ses exceptionnelles qualités en dehors du monde de la messagerie instantanée.

Le caractère (quasi) temps réel du protocole lui ouvre les portes de nouveaux horizons dont, comme le prouve cette expérience, le monde de la domotique.

A noter qu'il y aura certainement une suite à cette expérimentation.

Le lien: http://blog.intuitymedialab.eu/

  • # le rapport avec XMPP ?

    Posté par  . Évalué à 7.

    Hum, au risque de dire des choses bêtes et/ou naïves, je ne vois pas trop le rapport avec XMPP ici. Toute la difficulté semble être dans la carte (et son pilote) qui gère l'alimentation électrique de la lampe, non ?

    • [^] # Re: le rapport avec XMPP ?

      Posté par  . Évalué à 10.

      L'avantage avec XMPP, c'est que ça existe déjà: y'a déjà des serveurs et des clients.

      C'est bien plus simple d'envisager une application à grande échelle quand il suffit de dire "jour", "nuit", "porte", "café", "four" à une ressource XMMP, qu'en proposant de faire du telnet sur le port 18497.

      Autrement dit, XMPP permet de parler entre plusieurs clients connectés au même compte, et cette possibilité est encore peu exploitée alors qu'elle ouvre des perspectives formidables.

      La difficulté (somme toute relative avec un port parallèle, hélas en voie de disparition) de conception de la partie électronique et puissance étant, dans tout les cas, identique.

      THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

      • [^] # Re: le rapport avec XMPP ?

        Posté par  . Évalué à 3.

        Mais passer par un mécanisme général de message (le message texte qu'envoie n'importe quel client de chat jabber), genre "<message>lumière(chambre)</message>" (disclaimer, je ne connais pas jabber, c'est un exemple de ce que je suppose qu'il est) fait perdre du sens par rapport à un vrai sous-protocole de jabber, genre '<lumiere piece="chambre" />'.

        • [^] # Re: le rapport avec XMPP ?

          Posté par  . Évalué à 4.

          Rien n'empêche de faire un sous protocole dans des balises <message /> ou <iq /> du moment que c'est du XML (la grande différence entre les deux, c'est que <iq /> requiert une réponse du client).
          Par exemple :
          <message from="octobrain@linuxfr.org" to="lumiere@appart/chambre">
          <lumiere state="off" />
          </message>

          • [^] # Re: le rapport avec XMPP ?

            Posté par  . Évalué à 3.

            Pourquoi faire ça dans XMPP ? C'est fondamentalement client/serveur comme protocol non ?

            Du coup une jolie interface REST (http://en.wikipedia.org/wiki/Representational_State_Transfer ), c'est aussi simple. Et contrairement à xmpp, c'est utilisable avec la bibliothèque standard de python (urllib2 et ses copains), ou même scriptable facilement en console avec netcat/curl/wget.

            • [^] # Re: le rapport avec XMPP ?

              Posté par  . Évalué à 3.

              Ici la communication est client<->client, et XMPP a de gros avantages avantages, d'abord le coté bidirectionnel (une lampe pourras t'indiquer si est grillée), et tu n'as pas besoin de configurer ton firewall pour laisser passer les requêtes,
              Il vaut mieux voir XMPP comme un réseau au dessus de TCP qui s'assure de l'identité de ton correspondant et du format des données qu'il envoie (avec d'autres fonctionnalités utile comme la possibilité d'indiquer à un autre client tout les services qu'on supporte).
              Et il est assez facile d'écrire un petit client XMPP à l'aide d'un parser XML.

              J'aime beaucoup REST sur HTTP, c'est élégant et propre, les requêtes sont facilement 'cachable', etc, mais il sert surtout à accéder à des données sur un serveur et sur l'initiative du client.

              • [^] # Re: le rapport avec XMPP ?

                Posté par  . Évalué à 1.

                Sauf que niveau complexité c'est pas pareil. Il doit y avoir 10000 fois plus de gens qui savent causer en http que des gens qui savent causer en xmpp...

                • [^] # Re: le rapport avec XMPP ?

                  Posté par  . Évalué à 3.

                  Oui, c'est certain, mais il y a des fonctionnalités que HTTP ne propose pas ou alors en faisant des trucs moches, genre les chats en HTTP qui font des requêtes toutes les 3 secondes (Il y a bien BOSH mais ca reste un peu moche quand même : http://en.wikipedia.org/wiki/BOSH ). Pour du monitoring par exemple, XMPP est vraiment idéal.

                  • [^] # Re: le rapport avec XMPP ?

                    Posté par  (site web personnel) . Évalué à 3.

                    Et puis c'est ergonomique. Pas besoin de développer encore une autre interface différente des autres, mal intégrée au bureau des gens : on déclare des commandes ad-hoc, et l'utilisateur les utilise depuis son logiciel de MI.

                  • [^] # Re: le rapport avec XMPP ?

                    Posté par  . Évalué à 0.

                    Tu ne sembles avoir qu'une connaissance superficielle de ce que permet HTTP : les réponses avec un Content-Type de la famille des multipart/* répondent justement à cette problématique, et depuis bientôt 15 ans !
                    Voir par exemple http://en.wikipedia.org/wiki/Comet_%28programming%29#XMLHttp(...)
                    Je ne sais pas si BOSH s'appuie sur cette solution, mais dans ce cas, je ne vois pas trop ce qu'elle a de moche.

                    • [^] # Re: le rapport avec XMPP ?

                      Posté par  . Évalué à 2.

                      C'est ce que fait BOSH, et c'est moche parce que tu dois tout de même renvoyer une requête au serveur à chaque fois que tu reçois quelques chose. Une nouvelle requête ça veut parfois dire une nouvelle connexion, mais aussi une nouvelle vérification de l'identité du client.
                      Ça rajoute pas mal de complexité aussi bien au niveau serveur que client uniquement pour faire un lien bidirectionnel et revenir à ce que propose déjà TCP. Rajouter deux couches (HTTP + Comet) pour revenir aux même fonctionnalités qu'une couche inférieur (forcément plus rapide) c'est pas vraiment sexy.

                      • [^] # Re: le rapport avec XMPP ?

                        Posté par  . Évalué à 1.

                        tu dois tout de même renvoyer une requête au serveur à chaque fois que tu reçois quelques chose

                        Ah non, pas du tout ! Le principe du multipart, c'est justement de permettre au serveur d'envoyer plusieurs fragments de réponse au client pour la même requête, de façon asynchrone (c'est aussi utilisé, par exemple, pour rafraîchir l'image tirée d'une webcam en accédant juste au fichier JPEG).
                        Le comportement que tu décris est celui du Ajax with long polling.

                        Ça rajoute pas mal de complexité aussi bien au niveau serveur que client

                        Certes, mais les serveurs d'applications web récents fournissent des API dédiées, et un client XMPP en JavaScript, ça ne doit pas être trivial non plus ;-)

                        Rajouter deux couches (HTTP + Comet) pour revenir aux même fonctionnalités qu'une couche inférieur (forcément plus rapide)

                        Concrètement, il y a quand même une subtilité :
                        - ça passe les NAT sans aucun effort,
                        - ça utilise le proxy HTTP quand le firewall ne laisse rien passer,
                        - c'est bien pris en charge par les navigateurs web.
                        Dans un monde idéal, ça n'aurait pas d'importance, mais le monde est ce qu'il est : difficile de se passer de HTTP.

              • [^] # Re: le rapport avec XMPP ?

                Posté par  . Évalué à 1.

                client<->client, c'est un raccourci pour dire client<->serveur<->client ? J'ai bon ?

                Il faut bien un serveur quelque part de toute façon : soit il est chez toi et il faut configurer un firewall, soit il est ailleurs, et tu dépends d'un inconnu. Pour allumer une lampe, ça peut passer, pour gérer son alarme, c'est déjà moyen.

                Après avoir parcouru la RFC3920, ça me parait pas évident à faire correctement, un client XMPP. Et si c'est pour faire un truc dégueux, autant envoyer des octets en UDP, non ?

                • [^] # Re: le rapport avec XMPP ?

                  Posté par  . Évalué à 2.

                  Oui ça passe par un serveur, qui peut être le tien, mais rarement celui d'un 'inconnu', quand tu t'inscrit sur un serveur XMPP, que tu as choisis, tu lui fait confiance (il est possible de faire du chiffrement client<->client ou d'établir une connexion directe mais tu perd une grande partie des avantages de XMPP dans ce cas).

                  Tu peux faire un client minimal assez facilement, avec une authentification simple et en oubliant les plus fonctionnalités avancées (mais c'est largement suffisant dans la plupart des cas, tout en respectant les normes), sinon tu passe par une bibliothèque qui s'occupera du reste.

                  Envoyer des octets en UDP t'oblige à réinventer la roue pour l'authentification, le parsing et l'extensibilité, c'est comme ça que tu te retrouve avec des dizaines de RFCs, d'incompatibilités entre clients, de vulnérabilités, etc. Je préfère être pragmatique et utiliser un protocole un peu plus lourd mais qui ne posera pas tout ces problèmes.

      • [^] # Re: le rapport avec XMPP ?

        Posté par  (site web personnel) . Évalué à 9.

        >> D'un point de vue purement technique, rien de bien compliqué par contre côté XMPP, c'est une nouvelle preuve de ses exceptionnelles qualités en dehors du monde de la messagerie instantanée.

        >> L'avantage avec XMPP, c'est que ça existe déjà: y'a déjà des serveurs et des clients.

        Ouais.
        Je vais encore faire le vieux grincheux qui se fait pas trop plusser, mais avec un octet envoyé UDP, sans protocole, j'allume ou j'éteint 8 lampes. Exceptionnelles qualités : au moins 8 fois mieux qu'XMPP !

        C'est pas parcequ'un protocole permet de faire quelque chose, qu'il faut
        1/ le faire
        2/ dire que c'est bien

        Je pense que la morale de leur expérience c'est "qu'est-ce qu'on a bien rigolé ! Demain, on tentera de faire un chauffage central dans l'immeuble avec des vieux PC qui recompilent QT en boucle".

        Si ce qu'ils ont fait te faire croire qu'XMPP est bien, alors c'est que tu est bien influençable (car XMPP *est* bien, mais pas du tout pour ça).


        PS : Tiens, demain, je vais coder un serveur ECHO en XMPP avec python avec des fonctions anonymes, pour vous montrer comment c'est l'avenir !

        PPS : Un peu de sens critique, ça ne fait de mal à personne. Au contraire.

        • [^] # Re: le rapport avec XMPP ?

          Posté par  . Évalué à 3.

          Tu as raison mais :
          1/ je sais pas si tu peux envoyer un packet UDP depuis un tel portable,
          2/ si tu peux, alors tu dois faire une application cliente spécifique, avec la solution proposée, pas besoin, t'as déjà les clients dispo,
          3/ il faut gérer des erreurs, les réponses du style "l'ampoule de la lampe de chevet est morte", compréhensible,
          4/ Le fait de baser l'interface sur des phrases ayant une sémantique simple, c'est
          (a) plus conviviale (moins brouillon qu'un interface avec des bouton on/off),
          (b) plus souple (tu peux ajouter des commandes régulièrement, du style "éteindre les lampes de la cuisine", sans avoir à recoder/reconfigurer le client)
          (c) je sais plus ..

          Donc c'est pas con et très prometteur.

          • [^] # Re: le rapport avec XMPP ?

            Posté par  . Évalué à 5.

            oui, ça y est, le petit (c) :

            Tu ne peux pas contacter un ordinateur sur ton réseau domotique depuis l'exterieur, il faut que l'ordinateur soit connecté à un serveur externe, par lequel tu passes. Et à faire, c'est plus chiant d'un coup, surtout que des hébergeurs utilisant XMPP, il y en a plein.

            Donc c'est bien, merci pour ce bon journal, et ne soyez pas aigri, on est vendredi.

            • [^] # Re: le rapport avec XMPP ?

              Posté par  . Évalué à 3.

              Pourquoi pas ?
              Toutes mes machines a la maison ont une IP publique. Tiens là je te poste depuis 2001:770:19b:19:214:22ff:feac:c201

              • [^] # Re: le rapport avec XMPP ?

                Posté par  . Évalué à 4.

                Malheureusement pas encore, puisque linuxfr n'a pas de connectivité IPv6 ...

          • [^] # Re: le rapport avec XMPP ?

            Posté par  (site web personnel) . Évalué à 3.

            Notes que les mêmes arguments marchent avec HTTP, (POP|IMAP)/SMTP, etc...

            • [^] # Re: le rapport avec XMPP ?

              Posté par  (site web personnel) . Évalué à 5.

              XMPP a un mécanisme de commandes ad-hoc. Fini les bots que l'on commande en leur écrivant des codes, ils peuvent déclarer leurs commandes et ça peut se faire avec une interface adaptée depuis un client Jabber.

          • [^] # Re: le rapport avec XMPP ?

            Posté par  . Évalué à 1.

            OUI, ça me rappelle une grande entreprise dont le responsable télécom ne jurait que par la messagerie (c'est surtout ce qu'il connaissait), il avait fait monter une usine à gaz de saucissonnage/reconstitution de fichiers pour les faire transporter par X500 (oui, ça aussi on peut faire ! ) alors qu'un bête FTP... Evidemment le rendement de l'ensemble était plus proche de la machine à vapeur que d'un moteur turbo!

        • [^] # Re: le rapport avec XMPP ?

          Posté par  (site web personnel) . Évalué à 9.

          Non mais tu ne peux pas comprendre comme c'est prometteur d'avoir un processeur ARM alimenté 24/7 pour réussir a faire tourner un client xmmp et traduire ses appel la ou un simple pic (voir même plus simple) peut recevoir un signal, le traiter et renvoyer un code erreur très facilement. En plus en 8 Octet on doit pouvoir gérer l'ensemble de la maison avec une marge suffisamment large pour le futur.

          Mais bon cette solution est moins geek car tu n'as pas de serveur xmmp lourd à installer et a maintenir, ta machine à café n'a pas d'adresse IPv6 et le client qui effectivement n'existe pas est vraiment trop simpliste pour coder la gestion des messages.

          En plus ces fameux clients qui existent déjà : ils n'ont pas d'interface prévu pour contrôler une maison mais pour discuter avec les copains (Madame Michou ne va pas taper : light(room)=off) et surtout il n'existe aucun client adapté pour éteindre une lampe en sortie. Il faudra surtout recoder toute l'interface qui va transformer le message en signal électrique par dessus une libxmmp déjà existante et forcement trop complète par rapport a l'usage.

          PS : Bien évidemment ceci ne s'applique pas a un écran incrusté dans un frigo permettant d'afficher des recettes de cuisine, contrôler le contenu du frigo et faire ses courses en ligne car on dépasse de loin le cadre de la lampe qui s'allume et s'éteint et dans ce cas xmmp ne serait potentiellement pas la meilleurs solution non plus.
          Et puis n'oubliez pas que les constructeur de matériel domotique qui ont pondu des normes n'y connaissent rien pour s'embêter avec des protocoles dédier complètement obsolète ...

          Le vrai problème de la domotique aujourd'hui est que les interfaces de contrôle sont propriétaire Windows only.

          • [^] # Re: le rapport avec XMPP ?

            Posté par  (site web personnel) . Évalué à 3.

            Les fameux clients qui existent déjà, ils ont une interface pour envoyer des commandes ad-hoc à des services Jabber. Par exemple, pour un service PyMSNt, on peut demander des statistiques sur les clients, en cliquant, si on est avec un client graphique. En plus il y a une découverte des services.

          • [^] # Re: le rapport avec XMPP ?

            Posté par  (site web personnel) . Évalué à 8.

            Ouais mais avec la présence dans XMPP, tu peux savoir sur ton écran incrusté dans le frigo si la lumière est allumée dedans ou pas. Et sinon tu peux aller dans le salon MUC pour discuter avec le congélateur et le microonde du dîner à préparer.

        • [^] # Re: le rapport avec XMPP ?

          Posté par  . Évalué à 5.

          Dans XMPP, il y a eXtensible. Ton truc, c'est bien beau, mais si tu rajoute deux lampes ? Ah bah faut chambouler tout ton protocol. Après ça, tu veux, controler l'état de tes lampes en les questionnant. Faut chambouler tout ton protocol. Puis tu veux gérer d'autres appareils dans ta maison. Faut chambouler tout ton protocol.
          Si tu avais choisi XMPP depuis le début, ça ne t'aurais posé aucun problèmes, mais là, tu te retrouve avec un protocol infame, rapiecé de tous les cotés, et non compréhensible directement par un Homme.
          On peut comprendre ce choix si l'on doit contrôler une ampoule à l'autre bout du monde avec une connexion où tu paies à l'octet transporté, mais là c'est du local, qu'est ce que ça peut faire d'avoir des messages de quelques centaines d'octets ?

          • [^] # Re: le rapport avec XMPP ?

            Posté par  . Évalué à -3.

            Et le protocol eXtensible, il prévoit la correction orthographique aussi ?

          • [^] # Re: le rapport avec XMPP ?

            Posté par  . Évalué à 7.

            Bien sûr, et avec un raisonnement comme ça, on se retrouve à utiliser DBUS pour parler aux diverses cartes de contrôle, elles-même abstraites avec Hal et ses fichiers de configuration en XML..

            Parce que, d'accord, on peut utiliser son smartphone pour commander sa lampe mais imaginez que le serveur en question soit non seulement un serveur de lampe de chevet mais aussi un serveur de machine à café ? Et qu'on veut que l'allumage de la lampe déclenche la machine à café...

    • [^] # Re: le rapport avec XMPP ? J'ai trouvé !!

      Posté par  . Évalué à 5.

      Le rapport entre XMPP et l'allumage d'une ampoule est super simple, en fait: le symbole qui permet de reconnaitre XMPP dans la plupart des clients multiprotocoles est soit le logo de XMPP, soit.. une ampoule. :)

      THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

  • # The Big Bang Theory

    Posté par  (site web personnel) . Évalué à 10.

    Ça rappelle un peu la scène de The Big Bang Theory :
    http://www.youtube.com/watch?v=BW9FbjjkKo4

  • # Déjà dans le commerce ?

    Posté par  . Évalué à 6.

    C'est quoi la différence avec les multi-prise controllé par IP que l'on trouve dans le commerce ?
    Oui on peut acheter une multi-prise avec un port ethernet qu'il suffit de brancher sur le réseaux pour la rendre controlable via une interface web, interface web qui accepte wget ,
    Ce qui permet par exemple de scripter le processus de démarage d'une machine un peu complexe. (Allumer l'ordinateur embarqué de controle, puis allumer le monitoring, puis allumer le moteur)

    C'est cool, c'est controlable par XMPP mais bon fondamentalement il y a pas une grande différence entre un appareil controlé par XMPP et un autre par http ?
    Qu'est ce qui m'empeche d'avoir un client XMPP qui convertit un message de type
    MONITORING ON
    en
    /script/power/monitoring.sh on

    Bref j'ai l'impression qu'on parle de truc déjà utiliser tous les jours non ?

  • # OSC : open sound control

    Posté par  . Évalué à 1.

    Sinon il existe : http://opensoundcontrol.org/

    C'est un protocole de communication initialement dédié au matériel musical et qui a été employé comme une couche très performante sur le make controller kit

    http://www.makingthings.com/documentation/tutorial/osc/overv(...)

    Le lien suivant présente comment configurer un port série

    http://www.makingthings.com/ref/firmware/html/group___serial(...)

    je trouve cela très simple (comparé à termios ...)

    il est possible de communiquer en UDP/IP et en USB en utilisant ce protocole sur cette carte.

    Il est déjà possible de faire bien plus qu'allumer une lampe.

    En quoi XMPP est il intéressant comparer à ça ?

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.