Domotique – Interopérabilité – M2M – API – Socket IP …

Domotique - Interopérabilité - M2M - API - Socket IP ...

Introduction

Cet article est destiné à éclaircir les connaissances des débutants en matière de connectivité domotique. Les éléments de langage en domotique sont très variés en raison du périmètre d’application de ce domaine. Le spectre technique de la domotique s’étendant de l’électricité à l’informatique en passant par d’autres connaissances spécifiques, il existe donc une marche difficile à franchir pour le novice en la matière. Cet article s’inscrit donc dans une démarche didactique, afin de répondre à la nécessité de démocratiser la discipline. Il est impératif d’accompagner les débutants dans leurs premiers pas, au risque de perdre des volontaires adeptes des concepts domotiques qui n’ont pas forcément les bagages techniques utiles.

Contexte socio-économique et technique

Les termes Domotique 2.0, Smart-home, Maison connectée, Maison intelligente, IOT (Internet of things), SmartGrid sont des concepts marketing pour définir des segments de marché, mais ils ne correspondent en rien aux évolutions technologiques de ce domaine. Tous ces concepts essayent de définir un avenir à la domotique. Tous s’appuient sur les technologies de l’information et de la communication (TIC) qui sont dans la plupart des cas des protocoles standards connus depuis longtemps. La démocratisation de la domotique est à mon sens mal maîtrisée en raison de tous ces termes qui amène de la confusion pour l’utilisateur final. Le relookage marketing habituel n’a pas trop d’importance pour les technophiles mais permet d’accrocher les cibles potentielles du marché de la domotique. Les professionnels du marketing ont vu les indicateurs du marché évolués, et se sont dit qu’il était opportun de donner un nom à ce segment pour paraître plus innovant, et donc plus accrocheur. Les informaticiens ont il y a 3 ou 4 ans subit le même phénomène avec le « Nuage » (Cloud). Encore une supercherie marketing redéfinissant les services « SAAS » ou « ASP ». Ceci étant dit, même si mal compris par l’utilisateur final, le terme Cloud est aujourd’hui dans toutes les bouches, ce qui ne fut pas le cas d’ASP ou SAAS. Tout le monde en parle et personne comprend.

Les utilisateurs sont aujourd’hui prêts à passer à la domotique, c’est la maturité des futurs utilisateurs qui crée l’opportunité, et ce n’est pas le marketing qui a fait la différence. Les utilisateurs sont de plus en plus équipés de tablettes et de téléphones intelligents, ce sont des éléments concret  la perception de l’utilité change aussi, faire des économies d’énergie, l’environnement durable, la maîtrise de son habitation les actions à distance sont vraiment des éléments déterminants dans l’intérêt des utilisateurs.

Interopérabilité – Machine to machine

Machine to machine ou M2M est un terme utilisé en informatique et télécommunication pour désigner les technologies permettant à deux machines d’échanger des informations (Source : Wikipédia Fr).

Il est illusoire de penser qu’une technologie suffit à répondre aux besoins de chacun. Alors méfiez-vous des prescripteurs affirmant qu’une technologie vaut mieux qu’une autre. La convergence IP est le socle central de toutes ces technologies (EIB/KNX, Zwave, Zigbee, RFx …). Dans ce monde technologique hétérogène, il faut donc compter essentiellement sur les passerelles IP et les interfaces de développement (API) pour faire communiquer tous ces équipements (Objets). En effet, à contrario de la domotique qui est riche en protocoles ou technologies de communication diverses, en informatique le protocole IP est très standardisé et normé selon les RFC (Requests for Comments).

Domotique - Interopérabilité - M2M - API - Socket IP ...

Le M2M définit un dispositif qui permet à des objets (machine) d’utiliser les télécommunications et l’informatique pour communiquer entre eux, et ceci sans intervention humaine. Ces objets communiquent entre eux, prennent des relevés ou mesures. Les communications entre objets, sondes, capteurs et un système centralisé d’information s’effectuent au travers d’interface M2M. Ces interfaces peuvent être des équipements de liaison (Carte IP), ou des interfaces de développement (API) que des tiers applicatifs exploiteront pour faire communiquer les machines.

TABM2M

Il y a quatre opérations principales pour un dispositif M2M : la récolte de données, son transport, son traitement et le réveil du périphérique afin qu ’il puisse émettre un rapport de données non programmé.

Collecte de données (domaine de l’électronique) : La remontée d’informations se fait grâce aux capteurs embarqués dans les périphériques M2M. Les évolutions technologiques dans ce domaine donnent naissance à des dispositifs de moindre taille, moins coûteux et moins consommateurs en énergie.

Transport des données (domaine des télécommunications) : Plusieurs technologies de réseaux, radio ou filaire, peuvent coexister dans une même solution M2M. Le choix technologique dépendra de la couverture requise, du mode de connectivité, de la quantité de données à transmettre, de sa fréquence et du modèle économique.

Traitement des données (domaine de l’informatique) : L’application reçoit les données, les traite et intègre les données résultantes dans le système d’information de l’entreprise.

Réveil pour envoi de données (domaine des télécommunications) : Les périphériques M2M sont généralement programmés pour se réveiller à intervalle de temps fixe (e.g., toutes les heures), réaliser des mesures, s’attacher au réseau, établir une connexion de données, transférer leur rapport, puis libérer leur connexion et se détacher du réseau. Il peut arriver que l’application souhaite que le périphérique M2M lui communique un rapport de données non programmé. L’application réveille donc le périphérique par exemple par SMS et ce dernier transmet les données au serveur M2M.

Les domaines d’applications sont énormes :

  • L’énergie et la télémétrie ;
  • Distributeurs automatiques de biens consommables ;
  • L’automobile ;
  • La santé et le suivi à distance des patients ;
  • La surveillance et la sécurité ;
  • Et bien entendu la domotique.

Intels-M2M-Ecosystem-of-Smart-Services

Kézako une API ?

En informatique une interface de programmation (abr. API pour Application Programming Interface) est un ensemble normalisé de classes, des méthodes ou des fonctions offertes par une bibliothèque logicielle ou un service web, qui sert de façade par laquelle un logiciel offre des services à d’autres logiciels. Elle est le plus souvent accompagnée d’une description qui spécifie comment des programmes consommateurs peuvent se servir des fonctionnalités du programme fournisseur  (Source : Wikipédia Fr).

Pour ma part, je l’expliquerai ainsi :

Une API est une passerelle logicielle permettant la communication entre deux environnements logiciels distincts. Comme un interprète, l’API se charge d’offrir une interface de communication entre deux mondes applicatifs. De plus, cette API normalise les méthodes d’accès et de communication entre les deux environnements. Ces API peuvent-être de plusieurs types :

Les API Web (ou plutôt réseau) sont souvent plus connues du public dans le monde internet sous le nom de Webservice (M2M), et sont normalisé par le W3C (XML-RPC, SOAP, REST, JSON …). Citons par exemple, les API de sites internet marchant. Celle-ci permettent aux comparateurs de prix (du type « Prix du net ») d’intérroger et collecter le prix des références sur plusieurs sites afin d’établir un comparatifs de produits (schéma ci-dessous). Il existe des annuaires de Web-services inventoriant les API connues comme par exemple http://www.programmableweb.com/apilist.

Domotique - Interopérabilité - M2M - API - Socket IP ...

Il y a aussi les API dont le fonctionnement reste localisé au système lui-même. Celle-ci n’ont donc pas de transport réseau mais ont comme point commun leur un système de fichiers. Prenons l’exemple des systèmes d’exploitations tels que Linux ou Windows. Dans les deux cas le système s’appuie sur une quantité phénoménale de « librairies » (par exemple les fichiers : *.mo, *.so, *.dll) qui peuvent être exploitées par les processus exécutables comme celui de Firefox, Thunderbird ou autre. Les sous-processus pouvant offrir une généricité utiles à plusieurs exécutables sont souvent détachés afin d’être unifié et appelé par une instance du processus maître. L’avantage est de ne pas réinventer dans chaque développement ce qui peut-être traité par un sous-processus déjà existant (factorisation).

Domotique - Interopérabilité - M2M - API - Socket IP ...

Kézako une Socket ?

La notion de socket a été introduite dans les distributions de Berkeley (un fameux système de type UNIX, dont beaucoup de distributions actuelles utilisent des morceaux de code), c’est la raison pour laquelle on parle parfois de sockets BSD (Berkeley Software Distribution) (Source : Wikipédia Fr).

Il s’agit d’un modèle permettant la communication inter processus (Inter Process Communication) afin de permettre à divers processus de communiquer aussi bien sur une même machine qu’à travers un réseau TCP/IP. La communication par Socket est souvent comparée aux communications humaines. On distingue ainsi deux modes de communication :

Le mode connecté (comparable à une communication téléphonique), utilisant le protocole TCP. Dans ce mode de communication, une connexion durable est établie entre les deux processus, de telle façon que l’adresse de destination n’est pas nécessaire à chaque envoi de données.
Le mode non connecté (analogue à une communication par courrier), utilisant le protocole UDP. Ce mode nécessite l’adresse de destination à chaque envoi, et aucun accusé de réception n’est donné.

Partant encore une fois du principe qu’un dessin vaut un long discours, je vous ai concocté deux diagrammes pour comprendre les mécanismes fonctionnels du « socket » réseau. Il existe  3 types de sockets (j’en présenterai que deux), mais sachez que le troisième nommé « Multicast UDP » est une variante du socket UDP. En effet les sockets TCP et UDP sont des mécanismes de communication réseau « point à point » à contrario du Multicast UDP qui fonctionne d’un point à plusieurs de manière synchrone (la même information sur tous les canaux simultanément) .

Domotique - Interopérabilité - M2M - API - Socket IP ...

Les fonctions

  • Socket() permet la création du socket ;
  • Bind() permet d’attacher une adresse IP et un port réseau à l’application (point de rendez-vous) ;
  • Listen() permet de mettre un socket en attente de connexion ;
  • Accept() permet la connexion un appel entrant ;
  • Connect() permet d’établir une connexion avec un serveur ;
  • Recv() et recvfrom() permettent de lire dans un socket en mode connecté (TCP) et déconnecté (UDP) ;
  • Send() et sendto() permettent d’écrire dans un socket en mode connecté (TCP) et déconnecté (UDP) ;
  • Close() permet la fermeture d’un socket en permettant d’envoyer les données restantes (TCP).

Ce qu’il y a d’intéressant avec l’usage d’une Socket est que dans tous les cas de mise en oeuvre et de langage de développement, la logique reste la même. Pour cela, vous trouverez sur le site Developpez.com un tutoriel de Benjamin Roux expliquant l’usage d’une Socket en langage C. Au-delà du langage, les explications y sont plutôt bien faites.

Tour d’horizon des possibilités

Voici ci-dessous représenté schématiquement les possibilités offertes par mon infrastructure. Certes cela n’est pas représentatif de tous les environnements domotiques, mais cela donne quelques pistes. Par contre, Il faut savoir que l’usage des Sockets restent l’apanage des contrôleurs domotiques (box Vera, HC2 Fibaro …) permettant l’exploitation d’un langage interprété tels que peuvent-être le Lua, le PHP … Box ayant de facto des possibilités démultipliés et personnalisables par rapport aux autres. Dans mon cas les perspectives de communications entre mes équipements (Machines) est assez important et nécessite de faire un état des lieux systémique pour déterminer les opportunités et la pertinence des flux de communications M2M possible. Je vous encourage à faire cet exercice et  cette analyse avant de commencer.

Domotique - Interopérabilité - M2M - API - Socket IP ...

Quelques exemples d’applications avec une Vera

Bien entendu, vous l’aurez deviné, je citerai des exemples autour de la Vera, mais sachez que pour les API, il est souvent possible d’adapter l’appel de requêtes Http aux autres box du marché. Pour les sockets, seules les box dotées d’un langage (système) interprété tel que par exemple Lua, seront capable de travailler directement en M2M. Cependant, il existe des alternatives et méthode de contournement en déportant sur un serveur web personnel du code relais avec un socket en PHP par exemple.

Vera -> IPX800

La carte IPX800V3 est doté d’un serveur socket TCP sur le port d’écoute 9870 (par défaut). Il est relativement simple de mettre en place un pilotage de la carte web avec quelques ligne de code en Lua Script (Téléchargeable ici).

script-lua

Socket PHP :

Il est aussi tout à fait possible d’utiliser du code PHP déporté sur un serveur web pour piloter votre carte IPX800v3. Vous trouverz un tutoriel sur le site www.myipx800.comCommander l’IPX en PHP : utilisation du M2M.

Vera -> IRtrans

scene-vera-irtrans-01

Vous trouverez sur le site un tutoriel évoquant les mécanismes de communications (API et Socket) avec un IRTrans.

Vera -> Synology -> Freebox

Un peu plus complexe mais néanmoins accessible à ceux disposant d’une box domotique et d’un serveur de stockage en réseau (NAS /serveur Web PHP) , vous pouvez mettre en place une gestion déporté de votre Freebox V6 exploitant une classe PHP en surcharge. Pour cela rien de plus simple, il suffit d’appliquer la procédure du tutoriel de Fabien sur le site www.planete-domotique.com. Il est cependant, plus  pertinent de suivre le référentiel GitHub pour toujours avoir des sources à jour de toutes modifications. A ce stade de développement de la classe PHP, il est possible d’exécuter les requêtes HTTP suivantes :

  • Eteindre la carte wifi : http://IP/freebox.php?do=wifi_off
  • Allumer la carte wifi : http://IP/freebox.php?do=wifi_on
  • Rebooter la box : http://IP/freebox.php?do=reboot
  • Rebooter la box après XX secondes : http://IP/freebox.php?do=reboot&val=XX
  • Régler la luminosité de l’afficheur LCD à XX% : http://IP/freebox.php?do=lcd&val=XX

vera-nas-fb6

Vera -> Eco-device

ecodevicesihm

Vous trouverez dans un futur proche un tutoriel sur ce site (en attente de réception de l’Eco-device).

Vera -> Netatmo

sj-netatmo

Vous trouverez sur le site un tutoriel évoquant les mécanismes de communications (API) avec une Station Météo Netatmo.

Vera -> Koubachi

Il est possible de mettre en place une remonté des informations fournies par votre Koubachi, en interrogeant l’API. J’ai personnellement cet équipement mais je n’en suis pas satisfait pour plusieurs raisons que vous pouvez lire dans l’article ici. Cependant, quoiqu’il en soit, le dispositif  fait partie de mon infrastructure et celui-ci a été configuré pour ma Vera avec le tutoriel de Cédric Locqueneux sur www.maison-et-domotique.com

koubachi-vera-api

Vera -> MCE

MCE Controller est un logiciel résident pour des plateformes Windows faisant office de serveur ou client d’actions distantes. Depuis un système distant il est donc possible d’exécuter des commandes à l’ordinateur exécutant le serveur « MCE Controller ». A titre d’exemple, il est possible d’exécuter toutes les commandes du système distant et cela dans le mode interactif.
Pour cela, il faut dans le fichier « MCEControl.commands » déclarer toutes les commandes que vous voudriez pouvoir exécuter. Dans mon cas, je vous propose de mettre en place cette solution sur votre Vera en utilisant des scripts Lua.

  1. Télécharger et installer « MCEController 1.8.3 Setup.exe » ;
  2. il y a un prérequis à l’exécution du logiciel : le « Framework .net 4.5 » ;
  3. Paramétrer l’exécution au démarrage ;
  4. Le code LUA/LUA à mettre dans votre scène Vera :
1
2
3
4
local socket = require("socket") host = "<adresse ip du server>" 
c = assert(socket.connect(host, 5150)) 
c:send("<item de la commande déclarée dans le fichier de commande>\r>") 
c:close()

Dans mon cas je mets en place un shutdown de mon PC :

1
2
3
4
5
local socket = require(« socket ») 
host = "192.168.1.7" 
c = assert(socket.connect(host, 5150)) 
c:send("shutdown\r") 
c:close()

Conclusion

Par le passé les systèmes domotiques n’étaient pas vraiment des systèmes ouverts, hétérogènes, interopérables et connectés. Ces systèmes étaient le plus souvent mis en place par des installateurs spécialisés aux profils d’électriciens. Aujourd’hui les technologies du passé se mettent à niveau progressivement pour s’ouvrir vers l’interopérabilité. Cependant, les installeurs sont encore souvent un passage obligé. Les nouveaux systèmes domotiques à technologie sans fil sont de nos jours accessible à tout le monde en raison d’interfaces hommes machines (IHM) très conviviales et ergonomiques, mais surtout en raison des technologies sans-fil qui permettent à moindre coûts et rapidement de réaliser soi-même son installation. Le travers obligé de la situation, fait que les amateurs de la domotique « moderne » doivent développer leurs connaissances informatiques pour répondre à la personnalisation de leur infrastructure. J’espère que cet article aura suscité l’intérêt des novices en domotique, et apporté des explications simples à un sujet assez compliqué. N’hésitez pas à commenter et poser vos questions, nous ferons de notre mieux pour vous aider.

;)

Author: Sébastien Joly

Passionné de plongée, de voile croisière, de navigation, d'océans, de géomatique, de domotique, d'informatique ... des tictictics, je suis technophile un point c'est tout. Je m'intéresse à la domotique depuis plusieurs années mais je me suis lancé fin 2012 seulement. [ Accéder à mes articles ] [ Mon installation domotique ]

Share This Post On

10 Comments

  1. Très intéressant…. merci.

  2. Merci pour ces éclaircissements !

  3. Super, je crois que l’on a fait le tour avec quelques exemples. Un retour aux sources ne fait pas de mal. Merci

  4. Au départ cet article devait-être exclusivement technique et orienté sur le code. Cependant au travers de quelques remarques de lecteurs sur d’autres articles, j’ai découvert que ce n’était pas toujours accessible à tous publics et que nos utilisateurs faisaient bien souvent du copier-coller sans bien comprendre leur action. Donc pour cette fois un effort de simplification a été fait sur cet article. J’essaierai tant que possible de continuer dans cette démarche lors que le temps ne me fera pas défaut.

  5. @Serge : Te lancerais-tu dans la domotique ?

  6. je te remercie pour l’énoooorme effort de simplification. je comprend pourquoi tu parlais de jour »s » de rédaction. Maintenant, j’ai décroché à un endroit et je pense que c’est aussi ce qui fait qu’un informaticien ne peut prendre la place d’un comptable qui lui même ne peut prendre celui d’un médecin. S’il peut exister des facilités (un cerveau technique fait qu’un elec se mettra plus facilement à la domotique) ou un medecin à une autre science dure, un passage de comptable a informaticien me parait plus compliqué. C’est aussi ce qui fait la nature humaine, le marché de l’emploi…
    Je me rassure en me disant que tu as fait un très gros effort mais que malgré cela je n’en retiendrai que 30%, tout comme ce serait le cas si tu venais mettre un pied dans mon domaine. C’est ce qui segmente aussi entre les pro, les passionnés, les utilisateurs avertis et les utilisateurs lambda. Ensuite, c’est a la communauté de jouer. les plus grand aident les plus petits. les plus grands seront toujours très (trop?) sollicités et le petit se sentiront redevables sans pouvoir remercier plus qu’un « merci ».

    Je reviendrais juste sur une phrase que j’ai aimé : « Les utilisateurs sont aujourd’hui prêt à passer à la domotique, c’est la maturité des futurs utilisateurs qui crée l’opportunité, et ce n’est pas le marketing qui a fait la différence ». Le marketing a été dévoyé et fait plus partie aujourd’hui de la force de vente. Mais la réalité est la tienne, pas celle de TF1. je ne lance pas un produit et le matraque pour le faire acheter. Je fais une étude de marché, puis une étude d’opportunité, et lance un produit dont a besoin la population étudiée.

  7. Bonsoir, je comprends le décalage qu’il existe dans la population de lecteurs. Ceci étant dit, il faut se rendre à l’évidence, la compréhension des éléments techniques de cet article est encore rude pour beaucoup. Mais il faut se dire que si vous avez partiellement compris des choses, un grand pas vers la geekerie domotique aura été fait pour vous. De là à développer il y aura encore à apprendre, mais en tous cas vous aurez gagné en autonomie de compréhension.
    Peut-être devrions nous positionner systématiquement le niveau utile au début de nos articles. Du style : Débutant, intermédiaire, initier ???

  8. Je pense que l’idée de notion « niveau de compréhension » peut être un plus…

  9. Lorsqu’on débute comme moi, on commence à faire reconnaitre les capteurs et les différents actionneurs entre eux. Ensuite on va créer des scénarii de plus en plus complexes. Avec l’aide d’article comme celui-ci, on va avoir de nouvelles idées, de nouveaux besoins et ainsi acquérir de nouvelles connaissance qui nous permettrons d’aller plus loin…. (même si à la base notre formation est à des années lumières de l’informatique et de la domotique…) Merci à vous pour ces articles forts intéressants.

  10. Mon précédent commentaire a été zappé…. Je reprenais le « niveau de compréhension » de Pascal. L’utilisateur novice que je suis regarde l’article et si cela est trop complexe pour moi je passe à autre chose. Je pense que l’on se créé nos besoins en fonction de nos connaissances et vice versa. Il y a 20 ans je n’avais pas d’ordinateur car je ne savais pas quoi en faire. De même pour les smartphones ou les tablettes qui sont devenues presque indispensables. Pour moi la domotique est au niveau de l’ordinateur d’il y a 20 ans. Les gens vont découvrir ce domaine, se créer des besoins et ainsi leurs connaissances en s’aidant d’articles comme celui-ci.

Trackbacks/Pingbacks

  1. Spécialistes | Pearltrees - […] Domotique - Interopérabilité - M2M - API - Socket IP ... Domotique - Interopérabilité - M2M - API - …

Laisser un commentaire