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 arenthis . Évalué à 7.
[^] # Re: le rapport avec XMPP ?
Posté par Grunt . Évalué à 10.
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 Octabrain . Évalué à 3.
[^] # Re: le rapport avec XMPP ?
Posté par vg . Évalué à 4.
Par exemple :
<message from="octobrain@linuxfr.org" to="lumiere@appart/chambre">
<lumiere state="off" />
</message>
[^] # Re: le rapport avec XMPP ?
Posté par ribwund . Évalué à 3.
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 vg . Évalué à 3.
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 ribwund . Évalué à 1.
[^] # Re: le rapport avec XMPP ?
Posté par vg . Évalué à 3.
[^] # Re: le rapport avec XMPP ?
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3.
[^] # Re: le rapport avec XMPP ?
Posté par ☂ Tramo . Évalué à 0.
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 vg . Évalué à 2.
Ç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 ☂ Tramo . Évalué à 1.
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 iderrick . Évalué à 1.
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 vg . Évalué à 2.
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 Brioche4012 (site web personnel) . Évalué à 2.
[^] # Re: le rapport avec XMPP ?
Posté par Damien Thébault . Évalué à 3.
[^] # Re: le rapport avec XMPP ?
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 9.
>> 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 thedidouille . Évalué à 3.
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 thedidouille . Évalué à 5.
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 Thomas Pedoussaut . Évalué à 3.
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 benoar . Évalué à 4.
[^] # Re: le rapport avec XMPP ?
Posté par Corentin Chary (site web personnel) . Évalué à 3.
[^] # Re: le rapport avec XMPP ?
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 5.
[^] # Re: le rapport avec XMPP ?
Posté par brazz . Évalué à 1.
[^] # Re: le rapport avec XMPP ?
Posté par Mr Kapouik (site web personnel) . Évalué à 9.
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 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3.
[^] # Re: le rapport avec XMPP ?
Posté par Benoît Sibaud (site web personnel) . Évalué à 8.
[^] # Re: le rapport avec XMPP ?
Posté par Sébastien B. . Évalué à 5.
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 Antoine . Évalué à -3.
[^] # Re: le rapport avec XMPP ?
Posté par iderrick . Évalué à 7.
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 Grunt . Évalué à 5.
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: le rapport avec XMPP ? J'ai trouvé !!
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 2.
[^] # Re: le rapport avec XMPP ? J'ai trouvé !!
Posté par Grunt . Évalué à 2.
(Donc tu as raison, comme la plupart des pinailleurs :P)
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
# The Big Bang Theory
Posté par hsyl20 (site web personnel) . Évalué à 10.
http://www.youtube.com/watch?v=BW9FbjjkKo4
[^] # Re: The Big Bang Theory
Posté par Sphax . Évalué à 6.
[^] # Re: The Big Bang Theory
Posté par cougnafou . Évalué à 4.
Vivement le retour de nos geeks favoris ! En octobre la saison 3 normalement :-)
[^] # Re: The Big Bang Theory
Posté par blackshack . Évalué à 1.
http://www.series-blog.fr/wp-content/uploads/2009/08/bigbang(...)
# Déjà dans le commerce ?
Posté par Mais qui suis-je ? :) . Évalué à 6.
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 ?
[^] # Re: Déjà dans le commerce ?
Posté par PlOp3 . Évalué à 5.
C'est cher ?
Ça m'intéresse pas mal.
[^] # Re: Déjà dans le commerce ?
Posté par ham . Évalué à 5.
http://www.leunig.de
ca peut même rebooter un serveur si il ne ping pas
# OSC : open sound control
Posté par freejeff . Évalué à 1.
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.