FR3031260A1 - Procede de transmission de donnees entre un serveur et une unite electronique de controle d’une installation domotique - Google Patents

Procede de transmission de donnees entre un serveur et une unite electronique de controle d’une installation domotique Download PDF

Info

Publication number
FR3031260A1
FR3031260A1 FR1463300A FR1463300A FR3031260A1 FR 3031260 A1 FR3031260 A1 FR 3031260A1 FR 1463300 A FR1463300 A FR 1463300A FR 1463300 A FR1463300 A FR 1463300A FR 3031260 A1 FR3031260 A1 FR 3031260A1
Authority
FR
France
Prior art keywords
server
electronic control
control unit
message
communication protocol
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
FR1463300A
Other languages
English (en)
Other versions
FR3031260B1 (fr
Inventor
Sylvain Pognant
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Overkiz SAS
Original Assignee
Overkiz SAS
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Overkiz SAS filed Critical Overkiz SAS
Priority to FR1463300A priority Critical patent/FR3031260B1/fr
Priority to US15/539,890 priority patent/US20170346905A1/en
Priority to EP15823713.1A priority patent/EP3238384A1/fr
Priority to PCT/FR2015/053740 priority patent/WO2016102903A1/fr
Publication of FR3031260A1 publication Critical patent/FR3031260A1/fr
Application granted granted Critical
Publication of FR3031260B1 publication Critical patent/FR3031260B1/fr
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/14Session management
    • H04L67/141Setup of application sessions
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/2803Home automation networks
    • H04L12/2807Exchanging configuration information on appliance services in a home automation network
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00Network arrangements, protocols or services for addressing or naming
    • H04L61/09Mapping addresses
    • H04L61/25Mapping addresses of the same type
    • H04L61/2503Translation of Internet protocol [IP] addresses
    • H04L61/255Maintenance or indexing of mapping tables
    • H04L61/2553Binding renewal aspects, e.g. using keep-alive messages
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00Network arrangements, protocols or services for addressing or naming
    • H04L61/09Mapping addresses
    • H04L61/25Mapping addresses of the same type
    • H04L61/2503Translation of Internet protocol [IP] addresses
    • H04L61/256NAT traversal
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/18Multiprotocol handlers, e.g. single devices capable of handling multiple protocols
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/02Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/0227Filtering policies
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0894Escrow, recovery or storing of secret information, e.g. secret key escrow or cryptographic key storage

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Automation & Control Theory (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer And Data Communications (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

L'invention concerne un procédé de transmission de données entre un serveur (S) et une unité électronique de contrôle (U) d'une installation domotique (I) comprenant les étapes suivantes : - Une première étape de réception (E5) par l'unité électronique de contrôle (U) d'un message de demande d'ouverture de connexion (Mopen) en provenance du serveur (S) selon un premier protocole de communication (P1) ; - une étape d'établissement (E6) d'une connexion (Cnx) vers le serveur (S) à l'initiative de l'unité électronique de contrôle (U) selon un deuxième protocole de connexion (P2) ; - Une deuxième étape de réception (E8) par l'unité électronique de contrôle (U) d'un message descendant (MRp) en provenance du serveur (S) selon le deuxième protocole de communication (P2). L'invention concerne également un serveur et une unité électronique de contrôle mettant en œuvre le procédé.

Description

1 La présente invention concerne un procédé de transmission de données entre un serveur et une unité électronique de contrôle d'une installation domotique. Il est connu de procéder à des échanges de données entre un 5 serveur et une pluralité d'unités électroniques de contrôle d'installations domotiques. Chaque unité de contrôle électronique d'une installation domotique est disposée sur un réseau privé, dont l'accès est en général protégé par un pare-feu. Il peut être souhaitable de procéder à ces échanges de données notamment pour opérer un contrôle à distance des installations par 10 le serveur, par exemple dans le cas où le serveur reçoit des instructions d'une interface utilisateur permettant à l'utilisateur de contrôler à distance son installation. En conséquence, l'échange de données entre le serveur et l'ensemble des unités électroniques de contrôle doit prendre en compte la 15 présence de ce pare-feu. En particulier, l'établissement d'une connexion à l'initiative d'un serveur extérieur au réseau privé est de façon usuelle interdite par un pare-feu ou peut être rendue difficile par l'utilisation de mécanisme de traduction d'adresse (NAT). Selon une première possibilité, une configuration spécifique du 20 pare-feu peut être réalisée pour permettre l'établissement de connexion à l'initiative du serveur. Il apparaît toutefois que cela impose une intervention sur chaque pare-feu et une autorisation pour réaliser ladite intervention. Selon une deuxième possibilité, un mécanisme de connexion à l'initiative de l'unité électronique peut être utilisé, les connexions ainsi établies 25 étant maintenues par le serveur afin d'acheminer les données du serveur à l'unité électronique de contrôle. Il apparaît toutefois que cette deuxième possibilité conduit à une utilisation importante de ressources sur le serveur qui doit maintenir les données relatives à l'ensemble des connexions correspondant à chaque unité électronique. 30 La présente invention a pour but de résoudre tout ou partie des inconvénients mentionnés ci-dessus. A cet effet, la présente invention concerne un procédé de transmission de données entre un serveur et une unité électronique de contrôle d'une installation domotique comprenant les étapes suivantes : 3031260 2 - Une première étape de réception selon un premier protocole de communication par l'unité électronique de contrôle d'un message de demande d'ouverture de connexion en provenance du serveur ; - une étape d'établissement d'une connexion vers le serveur à l'initiative de l'unité électronique de contrôle selon un deuxième protocole de connexion ; - Une deuxième étape de réception par l'unité électronique de contrôle d'un message descendant en provenance du serveur selon le deuxième protocole de communication.
Grâce aux dispositions selon l'invention, l'établissement de la connexion selon le deuxième protocole de communication est réalisé à l'initiative de l'unité électronique de contrôle vers le serveur, suite à la demande d'ouverture de connexion formulée par le serveur selon le premier protocole. Ainsi, l'établissement de la connexion sera autorisé par le pare-feu, car elle est à l'initiative de l'unité électronique de contrôle. Le serveur pourra ensuite utiliser la connexion selon le deuxième protocole pour communiquer les données utiles correspondant à sa demande d'ouverture de connexion dans le message descendant. Ces dispositions permettent de réaliser la communication 20 d'informations entre le serveur et l'unité électronique de façon descendante en utilisant uniquement un établissement de connexion à l'initiative de l'unité électronique de contrôle. Par ailleurs, l'utilisation de deux protocoles de communication permet d'utiliser un premier protocole plus simple impliquant une utilisation de 25 ressources faible sur le serveur, et un deuxième protocole connecté impliquant une utilisation plus importante de ressources uniquement lorsque des informations doivent être communiquées par le serveur. En particulier, le premier protocole est un protocole en mode non connecté. Le deuxième protocole correspond à une communication en mode 30 connecté. Le premier protocole utilisé peut être de divers types permettant de ne pas être soumis aux contraintes imposées par le pare-feu. Selon un mode de réalisation, le premier protocole de communication est un protocole comprenant l'envoi d'un message du serveur 35 vers l'unité électronique de contrôle, notamment un message SMS.
3031260 3 Selon un autre mode de réalisation, le premier protocole correspond à une donnée fournie dans un flux audio et/ou vidéo, par exemple un flux MPEG. Il est à noter que le terme montant concerne les messages 5 transmis par l'unité électronique de contrôle vers le serveur et que le terme descendant concerne les messages transmis par le serveur vers l'unité électronique de contrôle. Selon un aspect de l'invention, le procédé comprend une première 10 étape de transmission périodique d'un message montant selon le premier protocole de communication par l'unité électronique de contrôle à destination du serveur ; la première étape de réception d'un message de demande d'ouverture de connexion comprenant une étape de réception selon le premier protocole d'au moins un message descendant ultérieure à la première étape de 15 transmission. L'unité électronique étant disposée sur un réseau privé dont l'accès est de façon usuelle protégé par un pare-feu, l'émission d'un message montant permet au serveur de répondre à ce message par un message descendant qui pourra atteindre l'unité électronique car il sera considéré comme une réponse au message montant. Ainsi, l'envoi périodique de message montant offre des fenêtres de temps au serveur pour communiquer des demandes d'ouverture de connexion. En choisissant une périodicité des messages inférieurs à la fenêtre de temps autorisée par le pare-feu pour répondre à un message montant, il est possible 25 de maintenir en permanence une possibilité de communication du serveur vers l'unité de contrôle électronique, c'est-à-dire un canal de communication ouvert. Par ailleurs, un envoi périodique permet de connaitre l'état du lien réseau entre l'unité électronique de contrôle et le serveur. Selon un aspect de l'invention, le procédé comprend, 30 préalablement à la première étape de réception d'une demande d'ouverture de connexion, une étape de réception selon le premier protocole de communication par l'unité électronique de contrôle d'un message descendant en provenance du serveur correspondant à une réponse d'accessibilité ; L'étape préalable et la deuxième peuvent être simultanées, 35 successives et/ou présenter une période de recouvrement temporel. En particulier, l'étape préalable de réception correspond à la réception d'une 3031260 4 réponse d'accessibilité selon un premier délai après l'étape de transmission, afin de maintenir la possibilité de réception d'une deuxième trame selon un deuxième délai. La deuxième étape correspond à la réception d'une demande de connexion pendant ledit deuxième délai.
5 Il apparaît en effet que le fonctionnement d'un pare-feu usuel peut empêcher le passage d'un message descendant dans la mesure où celui-ci est reçu au-delà d'un premier délai après l'envoi d'un message montant. Egalement de façon usuelle, dans la mesure où un premier message descendant est reçu, un deuxième délai plus important est accordé pour 10 recevoir un ou plusieurs autres messages descendants. Selon un aspect de l'invention, le procédé comprend une étape de surveillance d'au moins un délai de réception d'un message descendant en provenance du serveur suite à la première étape de transmission, le déclenchement d'une nouvelle première étape de transmission étant 15 déclenchée en cas de dépassement de l'au moins un délai de réception. Ces dispositions permettent de maintenir des fenêtres de communication ouvertes afin que le serveur puisse communiquer Selon un aspect de l'invention, le procédé comprend une étape de transmission d'un message montant à destination du serveur selon le 20 deuxième protocole de communication suite à l'étape d'établissement de connexion et précédemment à la deuxième étape de réception d'un message descendant ; En réponse au message montant de l'unité de contrôle électronique, le serveur pourra dans une réponse sous forme de message 25 descendant selon le deuxième protocole communiquer les données utiles correspondant à sa demande d'ouverture de connexion. Ces dispositions permettent de réaliser la communication d'informations entre le serveur et l'unité électronique de façon descendante en utilisant un mode de requêtes et réponses sous formes de messages montants 30 et descendants à l'initiative de l'unité électronique de contrôle. A titre d'exemple, une communication de type HTTP ou HTTPS peut être mise en oeuvre. Il est à noter que les messages montants et descendants ne contiennent pas tous nécessairement des données utiles. Ainsi, dans un 35 échange de requête et réponse sous forme d'un message montant ou 3031260 5 descendant, seule la réponse ou seule la requête peut contenir des données utiles Selon un aspect de l'invention, le procédé comprend une étape de libération et/ou d'acceptation de la libération de la connexion selon le deuxième 5 protocole de communication après un nombre déterminé de transmissions de messages montants et/ou de réception de messages descendants selon le deuxième protocole de communication ou après un délai déterminé après l'étape d'établissement de la communication. Grâce à ces dispositions, les ressources utilisées sur le serveur 10 pour maintenir les données de sessions sont limitées, car le nombre de connexions concurrentes est faible étant donné que les connexions sont fermées après échange de quelques informations. Ce mode de communication est adapté aux applications domotiques dans lesquelles un grand nombre d'unités électroniques de 15 contrôle sont connectées à un serveur avec un faible volume de données à échanger avec celui-ci. La libération de la connexion peut être réalisée selon les cas à l'initiative du serveur ou de l'unité électronique de contrôle. Selon un mode de réalisation, un seul échange selon le deuxième 20 protocole comprenant un message applicatif montant et un message applicatif descendant est prévu avant libération de la connexion. Selon un autre mode de réalisation, un seul message applicatif descendant est reçu avant libération de la connexion. Selon un aspect de l'invention, le procédé comprend une étape de transmission d'une clé de chiffrement par l'unité électronique de contrôle au serveur, de façon à permettre une signature des messages montants et/ou descendants selon le premier protocole de communication et/ou selon le deuxième protocole de communication. Ces dispositions permettent de réaliser une signature des 30 échanges entre le serveur et l'unité électronique de contrôle afin d'authentifier les deux entités en présence, à savoir le serveur et l'unité électronique de contrôle. Selon un aspect de l'invention, le procédé comprend une étape de réception d'une indication de clef invalide ou expirée en provenance du 35 serveur, et en réponse une nouvelle étape de transmission d'une clef de chiffrement.
3031260 6 Ces dispositions permettent de rétablir une communication par le premier mode de communication en cas d'expiration de la clé de chiffrement. La présente invention concerne également un procédé de transmission de données entre un serveur et une unité électronique de contrôle 5 d'une installation domotique comprenant les étapes suivantes : - Une première étape de transmission selon un premier protocole de communication par le serveur d'un message de demande d'ouverture de connexion à destination de l' unité électronique de contrôle ; - une étape d'acceptation de l'établissement d'une connexion par le 10 serveur à l'initiative de l'unité électronique de contrôle selon un deuxième protocole de connexion ; - Une deuxième étape de transmission selon le deuxième protocole de communication par le serveur d'un message descendant à destination de l'unité électronique de contrôle selon le deuxième 15 protocole de communication. Selon un aspect de l'invention, le procédé comprend une première étape de réception périodique d'un message montant selon le premier protocole de communication par le serveur en provenance de l'unité électronique de contrôle ; la première étape de transmission d'un message de 20 demande d'ouverture de connexion comprenant une étape de transmission d'au moins un message descendant ultérieure à la première étape de réception. Selon un aspect de l'invention, le procédé comprend, préalablement à la première étape de transmission d'une demande d'ouverture 25 de connexion, une étape préalable de transmission par le serveur à destination de l'unité électronique de contrôle d'un message descendant correspondant à une réponse d'accessibilité. Selon un aspect de l'invention, le procédé comprend une étape de réception d'un message montant par le serveur en provenance de l'unité électronique de contrôle selon le deuxième protocole de communication suite à l'étape d'acceptation d'établissement de connexion et précédemment à la deuxième étape de transmission d'un message descendant ; Selon un aspect de l'invention, le procédé comprend une étape de libération et/ou d'acceptation de libération de la connexion selon le deuxième 35 protocole de communication après un nombre déterminé de réception de messages montants et/ou de transmission de messages descendants selon le 3031260 7 deuxième protocole de communication ou après un délai déterminé après l'étape d'acceptation d'établissement de la communication. Selon un aspect de l'invention, le premier protocole de communication est le protocole UDP.
5 Selon un aspect de l'invention, le deuxième protocole de communication est le protocole TCP. Selon un autre aspect de l'invention, le premier et/ou le deuxième protocole peuvent être de type Raw IP ou autre protocole au dessus d'IP. La présente invention concerne également un produit programme 10 d'ordinateur comprenant des portions de code de programme pour l'exécution des étapes d'un procédé de transmission de données par une unité électronique de contrôle tel que décrit précédemment. La présente invention concerne également une unité électronique de contrôle d'une installation domotique comprenant une unité de traitement 15 agencée pour contenir et exécuter le produit programme d'ordinateur selon la revendication précédente, l'unité électronique de contrôle comprenant en outre au moins une interface de communication destinée à la commande et/ou au contrôle d'au moins un actionneur, notamment d'un élément mobile d'un bâtiment, ou d'un autre équipement commandable ou contrôlable 20 électriquement ou électroniquement, comme par exemple un système d'alarme, ou d'au moins un capteur, et une interface de communication destinée à la communication selon le premier protocole de communication ou le deuxième protocole de communication avec un serveur. La présente invention concerne également un produit programme 25 d'ordinateur comprenant des portions de code de programme pour l'exécution des étapes d'un procédé de transmission de données par un serveur tel que décrit précédemment. La présente invention concerne également un serveur de commande et ou de contrôle à distance d'au moins une unité électronique de 30 contrôle d'une installation domotique comprenant une unité de traitement agencée pour contenir et exécuter le produit programme d'ordinateur selon la revendication précédente, le serveur comprenant en outre au moins une interface de communication destinée à la communication selon le premier protocole de communication ou le deuxième protocole de communication avec au moins une unité de commande électronique.
3031260 8 Selon un aspect de l'invention, le serveur peut comprendre également une interface de communication destiné à la communication avec une interface utilisateur. Ces dispositions permettent un contrôle à distance de l'installation 5 domotique par l'utilisateur, et l'envoi d'ordres par l'intermédiaire du serveur vers l'unité électronique de contrôle, ou l'obtention de données sur l'état de l'installation. L'interface utilisateur peut par exemple être formée par un serveur web communiquant avec un terminal utilisateur, par exemple un ordinateur, un 10 téléphone portable ou une tablette. La présente invention concerne également un système distribué comprenant au moins un serveur et une pluralité d'unités électroniques de contrôle agencées pour communiquer avec le serveur de façon à mettre en oeuvre le procédé tel que décrit précédemment.
15 L'invention sera mieux comprise à l'aide de la description détaillée qui est exposée ci-dessous en regard du dessin annexé dans lequel : La figure 1 est un schéma illustrant la structure d'un système destiné à la mise en oeuvre d'un procédé de transmission de données entre un serveur et un ensemble d'unités électroniques de contrôle d'installations 20 domotiques. La figure 2 est un schéma illustrant un mode de mise en oeuvre d'un procédé de transmission de données. La figure 3 est un schéma illustrant une étape additionnelle du procédé de figure 2.
25 La figure 4 est un schéma illustrant la structure d'un deuxième système destiné à la mise en oeuvre d'un procédé de transmission de données entre un serveur et un ensemble d'unités électroniques de contrôle d'installations domotiques. Dans la description détaillée qui va suivre des figures définies ci-30 dessus, les mêmes éléments ou les éléments remplissant des fonctions identiques pourront conserver les mêmes références de manière à simplifier la compréhension de l'invention. Comme cela est représenté sur la figure 1, un système distribué comprend au moins un serveur S et une pluralité d'unités électroniques de 35 contrôle U d'installations domotiques agencées pour communiquer avec le 3031260 9 serveur S de façon à mettre en oeuvre un procédé de transmission de données. Chaque unité de contrôle électronique d'une installation domotique est disposée sur un réseau privé PN, PN', dont l'accès est en général protégé 5 par un pare-feu FW. Le serveur S est également disposé sur un réseau privé NS. Les réseaux privés PN, PN', SN sont reliés à un réseau étendu N, par exemple Internet. En particulier, une unité électronique de contrôle U d'une 10 installation domotique comprend une unité de traitement 2 agencée pour contenir et exécuter un premier programme d'ordinateur. A titre d'exemple, l'unité de traitement 2 comprend un processeur, une mémoire flash de stockage ainsi d'un mémoire vive, et d'une puce Ethernet PHY.
15 L'unité électronique de contrôle U comprend en outre au moins une interface de communication 3 destinée au contrôle/commande d'actionneurs d'éléments mobiles d'un bâtiment, de capteurs, ou encore d'autres équipements à commande électrique ou électronique tels qu'un système d'alarme.
20 A titre d'exemple, comme cela est représenté sur la figure 1, l'interface de communication 3 permet le contrôle et la commande d'au moins un actionneur 5, 5' d'un élément mobile d'un bâtiment, comme par exemple un volet roulant 6 ou un brise-soleil orientable 6'ou encore la réception d'informations d'un capteur 7 fournissant des informations de présence d'un 25 utilisateur ou des valeurs des paramètres environnants comme la température, l'humidité, la luminosité. De la même, façon l'interface peut permettre le contrôle/commande d'un système d'alarme 8. En particulier, l'interface de communication 3 peut comprendre une puce radiofréquence lo-homecontrol et/ou Zwave et/ou WM-Bus 30 communiquant à une fréquence de 868Mhz, et/ou une puce radiofréquence RTS/RTD/RTD+ communiquant à une fréquence de 433 Mhz. L'unité électronique de contrôle U comprend par ailleurs une batterie et/ou une alimentation secteur, ainsi que des ports de connexion physique tels que par exemple USB host, RJ45 et micro-USB.
35 L'unité électronique de contrôle U comprend également des éléments d'interface comme des boutons de réinitialisation, de configuration, 303 12 60 10 des boutons tactiles de lancement de scenarii, et/ou des indicateurs lumineux de fonctionnement, comme par exemple des LED. L'unité électronique de contrôle U comprend par ailleurs une interface de communication 4 destinée à la communication selon le premier 5 protocole de communication P1 ou le deuxième protocole de communication P2 avec un serveur S. Le serveur S qui permet la commande et/ou le contrôle à distance de la pluralité d'unités électroniques de contrôle U d'une installation domotique comprend une unité de traitement 102 agencée pour contenir et exécuter un 10 deuxième programme. Le serveur S comprend en outre au moins une interface de communication 104 destinée à la communication selon le premier protocole de communication P1 ou le deuxième protocole de communication P2 avec la pluralité d'unités électroniques de contrôle U.
15 Le serveur S peut comprendre également une interface de communication 106 destiné à la communication avec une interface utilisateur 107. L'interface utilisateur 107 peut par exemple être formée par un serveur web communiquant avec un terminal utilisateur 108 par le réseau N, par exemple un ordinateur, un téléphone portable ou une tablette.
20 La figure 2 représente un schéma de mise en oeuvre des procédés de transmission de données exécutés sur le serveur S et sur une unité électronique de contrôle U d'une installation domotique I. Selon le mode de mise en oeuvre décrit sur la figure 2, le procédé comprend une première phase PhO de négociation d'une clef secrète, une 25 deuxième phase Ph1 réalisée selon le premier protocole de communication destiné à recueillir une demande de connexion de la part du serveur S et une troisième phase Ph2 de transmission de données suite à l'établissement d'une connexion selon le deuxième protocole de communication à l'initiative de l'unité électronique de contrôle.
30 La phase de négociation d'une clef secrète PhO comprend une étape de transmission E0 d'une clé de chiffrement dans un message Mkey par l'unité de contrôle électronique U au serveur S qui le reçoit lors d'une étape E0', de façon à permettre une signature des messages montants et/ou descendants selon le premier protocole de communication P1 et/ou selon le 35 deuxième protocole de communication P2. La clef de chiffrement peut 3031260 11 notamment être choisie de façon aléatoire par l'unité électronique de contrôle U. Le serveur accuse réception de la clé et valide qu'il a bien pris en compte la nouvelle clef par un message descendant MkeyAck transmis dans 5 une étape El' qui est reçu par l'unité électronique de contrôle U lors d'une étape de réception E1. Les échanges entre l'unité électronique de contrôle U lors de la phase de négociation peuvent être réalisées selon un protocole de communication distinct ou similaire au premier protocole de communication et 10 au deuxième protocole de communication PI et P2. A titre d'exemple, un protocole de type HTTPS peut être choisi qui permet de communiquer la clef de façon sécurisée. Il est à noter que cet échange n'est pas réalisé fréquemment, et en conséquence ne représente pas une consommation de ressources 15 significative. A titre d'exemple, une périodicité de plusieurs jours peut être prévue pour la validité des clefs. La deuxième phase de communication Phi selon le premier protocole PI comprend une première étape de transmission E2 périodique d'un message montant Mping selon le premier protocole de communication PI par 20 l'unité électronique de contrôle U à destination du serveur S qui le reçoit dans une étape E2'. A titre d'exemple, une périodicité de l'ordre d'une dizaine de secondes peut être prévue pour la périodicité de la transmission, et notamment de l'ordre de 20s. En réponse à ce message montant, le serveur S transmet dans une 25 étape E4' un message descendant Mpong à destination de l'unité électronique de contrôle U qui est reçu dans une étape préalable de réception E4 dans un premier délai DO court après la transmission du message montant Mping. A titre d'exemple, le délai DO peut être de l'ordre de quelques secondes, et notamment de l'ordre de 5 s.
30 Ce premier message Mpong descendant permet de maintenir le canal de communication ouvert pendant un deuxième délai Dr2 supérieur au premier délai DO . Il apparaît en effet que le fonctionnement d'un pare-feu usuel peut empêcher le passage d'un message descendant dans la mesure où celui-ci est reçu au-delà d'un premier délai après l'envoi d'un message 35 montant. Egalement de façon usuelle, dans la mesure où un premier message descendant est reçu, un deuxième délai plus important est accordé pour 3031260 12 recevoir un ou plusieurs autres messages descendants. Il est notamment possible de choisir de déclencher une nouvelle transmission du message Mping avant l'expiration du délai Dr2. Par la suite, dans le cas où le serveur S a des données utiles DU à 5 transmettre à l'unité électronique de contrôle U, celui-ci transmet selon le premier protocole de communication PI lors d'une étape E5' un message de demande d'ouverture de connexion Mopen, qui est reçu par l'unité électronique de contrôle U lors d'une étape E5. La deuxième phase Phi de communication selon le premier 10 protocole PI comprend une étape de surveillance E3 d'un délai de réception Dr d'un message descendant en provenance du serveur S suite à la première étape de transmission Mping, le déclenchement d'une nouvelle première étape de transmission E2 étant réalisé en cas de dépassement du délai de réception. Lors de cette phase, les échanges sont signés avec la clé secrète 15 communiquée lors de la première phase de communication PhO. Comme cela est illustré sur la figure 3, lors de la deuxième phase Phi de communication selon le premier protocole de communication P1, le serveur peut réaliser une étape de transmission ERO' d'une indication de clef invalide ou expirée Minvalidkey en provenance du serveur S, et en réponse 20 une nouvelle étape de transmission d'une clef de chiffrement EO. Typiquement, cette situation peut intervenir lors de la transmission d'un message montant MPing, le serveur ayant constaté que le message présente un format correct mais n'est pas signé avec une clé valide. Il est à noter qu'en cas de redémarrage de l'unité électronique de contrôle, la première phase de 25 communication PhO avec communication de la clé est réalisée à nouveau. Lors de la deuxième phase de communication Phi, Le premier protocole de communication peut notamment être le protocole UDP. La troisième phase Ph2 du procédé est réalisée suite à la réception de la demande d'ouverture de connexion reçue par l'unité électronique de 30 contrôle dans la deuxième phase à l'étape E5. Dans un premier temps, une étape d'établissement E6 d'une connexion Cnx vers le serveur S qui accepte cette connexion dans une étape correspondante E6' est réalisée, à l'initiative de l'unité électronique de contrôle U selon un deuxième protocole de connexion P2. En particulier, le 35 protocole de communication peut être le protocole TCP. Dans ce cas, l'étape d'établissement E6 peut comprendre plusieurs échanges entre le serveur et 3031260 13 l'unité U, et en particulier des échanges de messages de gestion de connexion, comme les messages du protocole TCP SYN, SYN/ACK, ACK. Une fois la connexion Cnx établie, une étape de transmission E7 d'un message montant MRq est réalisée selon le deuxième protocole de 5 communication P2 à destination du serveur S qui reçoit ce message dans un étape E7'. En particulier, le message MRq peut être un message sans données utiles mais constituant un message montant auquel une réponse pourra être envoyée par le serveur.
10 Ainsi, le serveur transmet un message descendant MRp dans une étape de transmission E8' à destination de l'unité électronique de contrôle U. Ce message descendant contient les données utiles DU que le serveur devait transmettre à l'unité électronique de contrôle. Suite à cet échange, une étape de libération ou d'acceptation de la 15 libération E9, E9' de la connexion Cnx est réalisée. Le deuxième protocole de communication utilisé peut être en particulier le protocole TCP. Les échanges des étapes E7/E7' et E8/E8' peuvent notamment être réalisés sous forme d'une requête et d'une réponse selon le protocole HTTPS qui utilise TCP.
20 Selon des variantes de mise en oeuvre, la libération de la connexion peut intervenir après plusieurs échanges de messages montants et/ou de réception de messages descendantes selon le deuxième protocole de communication ou encore après un délai déterminé après l'étape d'établissement de la communication E6.
25 Selon un deuxième mode de mise en oeuvre d'un système mettant en oeuvre l'invention représenté sur la figure 4, le premier protocole de communication est un protocole de type SMS comprenant l'envoi d'un message du serveur vers l'unité électronique de contrôle U identifiée dans ce cas par un numéro téléphonique. Ce deuxième protocole est utilisé sur un 30 réseau de type téléphonique N2, par exemple un réseau GSM ou téléphonie filaire sur Internet, avec une fonction de gestion de messages numériques. Le serveur S comprend à cet effet une interface de communication 107 sur le réseau N2, comme par exemple une carte GSM, tout comme l'unité électronique de contrôle, qui comprend également une interface 35 de communication 7 sur le réseau N2, comme une carte GSM ou un module 3031260 14 matériel et logiciel de téléphonie sur Internet, pouvant être intégré au pare-feu ou à l'unité électronique de contrôle U. Ainsi, l'échange selon le premier protocole et l'étape de réception d'une demande d'ouverture de connexion correspond à un simple envoi de 5 SMS entre le serveur S et l'unité électronique de contrôle U. La figure 4 ne représente qu'une unité électronique de contrôle, mais ce deuxième mode de réalisation s'applique bien entendu à la communication avec une multitude d'unités électroniques de contrôles. Selon des variantes de mise en oeuvre, le premier protocole utilisé 10 peut être de divers types permettant de ne pas être soumis aux contraintes imposées par le pare-feu. Selon une deuxième variante, le premier protocole correspond à une donnée fournie dans un flux audio et/ou vidéo, par exemple un flux MPEG. Selon cette variante, l'unité électronique de contrôle U comprend ou est 15 associée à une interface de décodage du flux audio et/ou vidéo correspondant. Selon une autre variante, le premier et/ou le deuxième protocole peuvent être de type Raw IP ou autre protocole au dessus d'IP. Selon des variantes de la troisième phase de communication Ph2, il est possible que les échanges applicatifs suivent le modèle des transactions, 20 comprenant une requête et une réponse. Les requêtes sont envoyées sous forme de messages montants, et les réponses sous forme de messages descendants. Ainsi, dans un échange de requête et réponse sous forme d'un message montant, respectivement descendant, seule la réponse ou seule la requête peut contenir des données utiles. Un message montant et le message 25 descendant transmis en retour peuvent contenir des données utiles qui ne correspondent pas nécessairement à la même transaction. Par exemple une requête en cours nécessitant un traitement applicatif est transmise sous forme de message montant, et peut déclencher la transmission d'un message descendant sans données utiles, ou contenant des données utiles relatives à 30 une requête antérieure. De la même manière, la réponse applicative correspondant à la requête en cours peut être envoyée lors d'un échange message montant/message descendant ultérieur. Cet échange peut comprendre un message montant sans données utiles. Selon une variante de la troisième phase de communication Ph2, il 35 est possible que suite à l'établissement de la connexion E6, seul un message descendant soit transmis par le serveur S, sans transmission d'un message 3031260 15 montant par l'unité de contrôle électronique. Dans ce cas, un protocole distinct de HTTPS peut être utilisé, tout en s'appuyant sur les services fiables fournis par un protocole transport fonctionnant en mode connecté, comme TCP Il est à noter que la description ci-dessus décrit des procédés 5 permettant la transmission de données du serveur S vers l'unité électronique de contrôle U. La transmission de données dans le sens de l'unité électronique de contrôle vers le serveur peut être réalisée par exemple selon le deuxième protocole de communication sans difficulté étant donné qu'il est possible 10 d'établir directement une connexion à l'initiative de l'unité électronique de contrôle. A titre d'exemple une requête et une réponse selon le protocole HTTPS peuvent être réalisée, puis la connexion établie libérée afin de limiter l'utilisation de ressources du serveur.
15 Exemple Nous allons à présent décrire à titre d'exemple un format des messages utilisés dans le procédé tel que décrit précédemment selon le 20 premier mode de réalisation dans la configuration du système présenté sur la figure 1. Dans l'exemple considéré, le premier protocole est le protocole UDP. Les messages sont transmis dans des datagrammes UDP. En 25 particulier, un message peut correspondre à un datagramme UDP. Le corps du datagramme UDP est constitué d'une unique trame encodée en UTF-8. La forme générale du format des trames comprend un premier bloc appelé BODY, un deuxième bloc SEQUENCE et un dernier BLOC de SIGNATURE, ces blocs étant séparés par des séparateurs / et % comme cela 30 est représenté ci-dessous : <BODY>/<SEQUENCE>%<SIGNATURE> Il est à noter toutefois que le message ou la trame Minvalidkey ou INVALIDKEY ne possède ni séquence ni signature, et donc seulement le bloc BODY.
35 Nous détaillons ci-dessous les différents blocs identifiés.
3031260 16 Le bloc BODY présente la forme générale suivante : <TYPE>#<SERIAL>#<TIMESTAMP>#.... Le champ TYPE comprend une information de type de message qui peut être: PING (pour un message Mping), PONG (pour un message 5 Mpong), OPEN (pour un message Mopen), INVALIDKEY (pour un message Minvalidkey). Le champ SERIAL comprend le numéro de série du l'unité électronique de contrôle U. Le champ TIMESTAMP comprend un horodatage, par exemple un 10 Timestamp UNIX correspondant au nombre de secondes depuis EPOCH, calculé par l'émetteur du message. D'autres champs peuvent être présents en fonction du type de message comme décrit ci-dessous. En particulier, dans le cas d'un message Mping, transmis de l'unité 15 électronique de contrôle U vers le serveur S, le bloc BODY présente la structure suivante : PING#<SERIAL>#<TIMESTAMP>#<ACTIVITY_INTERVAL> Le champ ACTIVITY_INTERVAL correspond au nombre de secondes maximum entre deux activités de l'unité électronique de contrôle U, 20 c'est-à-dire une transmission vers le serveur selon le premier ou le deuxième protocole de communication. L'unité électronique de contrôle U doit envoyer un message Mping immédiatement après son démarrage puis doit ensuite régulièrement : soit émettre un nouveau message Mping, soit établir une connexion Cnx pour 25 affirmer sa présence auprès du serveur. La durée maximum entre une de ces deux activités est : - Récupérée par l'unité électronique de contrôle U dans sa configuration au démarrage ; - Transmise par l'unité électronique de contrôle U dans chaque 30 message Mping pour préciser au serveur qu'elle est sa période d'activité actuelle. - Peut être modifiée par un message Mpong renvoyée par le serveur comme cela est décrit ci-après. Dans le cas d'un message Mpong transmis du serveur S vers 35 l'unité électronique de contrôle U, le bloc BODY présente la structure suivante : 3031260 17 PONG#<SERIAL>#<TIMESTAMP>#<NEW ACTIVITY _INTERVAL Le champ NEW_ACTIVITY_INTERVAL comprend une nouvelle valeur (en secondes) de la période d'activité souhaitée.
5 Le serveur doit renvoyer un message Mpong pour chaque message Mping reçue. Si la valeur de période d'activité de l'unité électronique de contrôle U est différente de celle fournie dans le message Mpong, l'unité électronique de contrôle U doit mettre à jour sa valeur en conséquence.
10 Dans le cas d'un message Mopen transmis du serveur S vers l'unité électronique de contrôle U, le bloc BODY présente la structure suivante : OPEN#<SERIAL>#<TIMESTAMP> Le serveur envoie un message Mopen à l'unité électronique de contrôle U lorsqu'il désire que celle-ci se connecte au plus tôt au serveur par le 15 canal HTTPs. Dans le cas d'un message Minvalidkey transmis du serveur S vers l'unité électronique de contrôle U, le bloc BODY présente la structure suivante : INVALIDKEY#<SERIAL>#<TIMESTAMP>#<REJECTED SIGNAT URE> 20 Le serveur envoie un message Minvalidkey lorsqu'il reçoit un message Mping au format valide mais dont la signature est incorrecte ou lorsqu'il a épuisé sa source de numéro de séquence. Lorsque l'unité électronique de contrôle U reçoit un message Minvalidkey, une phase de renégocier d'une nouvelle clef secrète est réalisée 25 avec le serveur S. L'unité électronique de contrôle U doit vérifier que REJECTED_SIGNATURE correspond bien à la signature du dernier message Mping envoyé, sinon il peut ignorer silencieusement le message.
30 Le bloc SEQUENCE correspond à une valeur entière (32bits) représentant le numéro de séquence de la trame transmise. Chaque message transmis doit contenir un numéro de séquence strictement croissant afin d'éviter les attaques de type REPLAY. Chaque acteur de la communication (unités électroniques de 35 contrôle et serveur) possède son propre compteur de séquence qu'il utilise pour numéroter le message qu'il envoie.
3031260 18 Le premier message transmis doit avoir un numéro de séquence égal à 1. Les messages suivants doivent avoir un numéro de séquence strictement croissant, incrémenté de 1 à chaque message (soit 2, 3, 4,5,...) 5 Les compteurs de séquence doivent être remis à zéro à chaque fois qu'une nouvelle clef secrète est négociée. Comme le protocole UDP ne garantit pas l'ordre d'arrivée des paquets transmis, le contrôle du numéro de séquence doit faire appel à un mécanisme de fenêtre glissante, en appliquant en particulier l'algorithme de 10 contrôle suivant: - Si le numéro de séquence reçu est égal au dernier numéro reçu, il est considéré comme invalide ; - Si le numéro de séquence reçu est strictement supérieur au dernier numéro reçu, il est considéré comme valide ; Ce numéro 15 remplace alors la dernière valeur reçue et la fenêtre glissante se décale pour faire une place à cette nouvelle valeur ; - Si le numéro de séquence reçu est strictement inférieur au dernier numéro reçu : o Si la différence entre les deux valeurs est strictement 20 inférieure à la taille de la fenêtre ^ Si la nouvelle valeur n'apparait pas déjà dans la fenêtre, le numéro de séquence est considéré comme valide ; la fenêtre glissante se décale pour faire une place à cette nouvelle valeur ; 25 ^ Si la nouvelle valeur apparait déjà dans la fenêtre, le numéro de séquence est considéré comme invalide ; o Si la différence entre les deux valeurs est supérieure ou égale à la taille de la fenêtre ; le numéro de séquence est 30 considéré comme invalide. Les fenêtres de contrôle doivent être remises à zéro à chaque fois qu'une nouvelle clef secrète est négociée. Tout message possédant un numéro de séquence invalide doit être ignorée silencieusement.
35 Le bloc SIGNATURE correspond à une signature du message, disposée à la fin du message après le séparateur % en notation hexadécimale.
3031260 19 Chaque message transmis doit posséder une signature La signature porte sur tout le contenu du message avant le séparateur % non-inclus. L'algorithme et la clef secrète de signature doivent être négociés au préalable par un canal HTTPS.
5 La signature des messages est systématiquement vérifiée, sauf pour les messages Minvalidkey. Tout message possédant une signature invalide est ignoré silencieusement. La signature d'une trame doit être vérifiée avant de vérifier le numéro de séquence. Comme il va de soi, l'invention ne se limite pas à la seule forme 10 d'exécution de ce procédé et du système, décrit ci-dessus à titre d'exemple, elle en embrasse au contraire toutes les variantes de réalisation.

Claims (15)

  1. REVENDICATIONS1 Procédé de transmission de données entre un serveur (S) et une unité électronique de contrôle (U) d'une installation domotique (I) comprenant les étapes suivantes - Une première étape de réception (E5) selon un premier protocole de communication (P1) par l'unité électronique de contrôle (U) d'un message de demande d'ouverture de connexion (Mopen) en provenance du serveur (S) ; - une étape d'établissement (E6) d'une connexion (Cnx) vers le serveur (S) à l'initiative de l'unité électronique de contrôle (U) selon un deuxième protocole de connexion (P2) ; Une deuxième étape de réception (E8) par l'unité électronique de contrôle (U) d'un message descendant (MRp) en provenance du serveur (S) selon le deuxième protocole de communication (P2).
  2. 2. Procédé selon la revendication 1, comprenant : - Une première étape de transmission (E2) périodique d'un message montant (Mping) selon le premier protocole de communication (P1) par l'unité électronique de contrôle (U) à destination du serveur (S) ; et dans lequel la première étape de réception (E5) d'un message de demande d'ouverture de connexion (Mopen) comprend une étape de réception selon le premier protocole (P1) d'au moins un message descendant (Mopen) ultérieure à la première étape de transmission (E2). 25
  3. 3. Procédé selon l'une des revendications précédentes, comprenant, préalablement à la première étape de réception (E5) d'une demande d'ouverture de connexion (Mopen) Une étape préalable de réception (E4) selon le premier protocole de 30 communication (P-I) par l'unité électronique de contrôle (U) d'un message descendant en provenance du serveur (S) correspondant â une réponse d'accessibilité (Mpong) ;
  4. 4. Procédé selon l'une des revendications 2 ou 3, comprenant une étape 35 de surveillance (E3) d'au moins un délai de réception (Dr) d'un message descendant en provenance du serveur (S) suite à la première étape de 3031260 21 transmission (Mping), le déclenchement d'une nouvelle première étape de transmission (E2) étant déclenchée en cas de dépassement de l'au moins un délai de réception. 5
  5. 5. Procédé selon l'une des revendications précédentes, comprenant : une étape de transmission (E7) d'un message montant (MRq) à destination du serveur (S) selon le deuxième protocole de communication (P2) suite à l'étape d'établissement de connexion (E6) et précédemment à la deuxième étape de 10 réception (E8) d'un message descendant ;
  6. 6. Procédé selon l'une des revendications précédentes, comprenant une étape de libération et/ou d'acceptation de la libération (E9) de la connexion (Cnx) selon le deuxième protocole de communication (P2) 15 après un nombre déterminé de transmissions de messages montants et/ou de réception de messages descendants selon le deuxième protocole de communication (P2) ou après un délai déterminé après l'étape d'établissement de la communication (E6). 20
  7. 7. Procédé de transmission de données entre un serveur (S) et une unité électronique de contrôle (U) d'une installation domotique (I) comprenant les étapes suivantes : Une première étape de transmission (E5') selon un premier protocole de communication (P1) par le serveur (S) d'un message de demande d'ouverture de connexion (Mopen) à destination de l'unité électronique de contrôle (U) ; une étape d'acceptation de l'établissement (E6') d'une connexion (Cnx) par le serveur (S) à l'initiative de l'unité électronique de contrôle (U) selon un deuxième protocole de connexion (P2) ; Une deuxième étape de transmission (E8') selon le deuxième protocole de communication (P2) par le serveur (S) d'un message descendant (Mrp) à destination de l'unité électronique de contrôle (U) selon le deuxième protocole de communication (P2).
  8. 8. Procédé selon la revendication 7, comprenant : 3031260 22 Une première étape de réception (E2') périodique d'un message montant (Mping) selon le premier protocole de communication (P1) par le serveur (S) en provenance de l'unité électronique de contrôle (U) ; 5 et dans lequel la première étape de transmission (E5') d'un message de demande d'ouverture de connexion (Mopen) comprend une étape de transmission d'au moins un message descendant (Mopen) ultérieure à la première étape de réception (E2'). 10
  9. 9. Procédé selon l'une quelconque des revendications 7 ou 8, comprenant, préalablement à la première étape de transmission (E5') d'une demande d'ouverture de connexion (Mopen) Une étape préalable de transmission (E4') par le serveur (S) à destination de l'unité électronique de contrôle (U) d'un message 15 descendant correspondant à une réponse d'accessibilité (Mpong) ;
  10. 10. Procédé selon l'une quelconque des revendications 7 à 9, comprenant : une étape de réception (E7') d'un message montant (MRq) par le-serveur (S) en provenance de l'unité électronique de contrôle (U) 20 selon le deuxième protocole de communication (P2) suite à l'étape d'acceptation d'établissement de connexion (E6') et précédemment à la deuxième étape de transmission (E8') d'un message descendant (Mrp) ; 25
  11. 11. Procédé selon l'une quelconque des revendications 7 à 10, comprenant une étape de libération ou d'acceptation de libération (E9') de la connexion (Cnx) selon le deuxième protocole de communication (P2) après un nombre déterminé de réception de messages montants et/ou de transmission de messages descendants selon le deuxième protocole 30 de communication (P2) ou après un délai déterminé après l'étape d'acceptation d'établissement de la communication (E6').
  12. 12. Produit programme d'ordinateur comprenant des portions de code de programme pour l'exécution des étapes d'un procédé de transmission 35 de données selon l'une des revendications 1 à 6 lorsque ledit programme est exécuté par un ordinateur. 3031260 23
  13. 13.Unité électronique de contrôle (U) d'une installation domotique comprenant une unité de traitement (2) agencée pour contenir et exécuter le produit programme d'ordinateur selon la revendication 5 précédente, l'unité électronique de contrôle comprenant en outre au moins une interface de communication (3) destinée à la commande et/ou au contrôle d'au moins un actionneur, notamment d'un élément mobile d'un bâtiment, ou d'un autre équipement commandable ou contrôlable électriquement ou électroniquement, comme par exemple-un 10 système d'alarme, ou d'au moins un capteur, et une interface de communication (4) destinée à la communication selon le premier protocole de communication (P1) ou le deuxième protocole de communication (P2) avec un serveur (S). 15
  14. 14. Produit programme d'ordinateur comprenant des portions de code de programme pour l'exécution des étapes d'un procédé de transmission de données selon l'une des revendications 7 à 11 lorsque ledit programme est exécuté par un ordinateur. 20
  15. 15. Serveur (S) de commande et ou de contrôle à distance d'au moins une unité électronique de contrôle (U) d'une installation domotique comprenant une unité de traitement (102) agencée pour contenir et exécuter le produit programme d'ordinateur selon la revendication précédente, le serveur comprenant en outre au moins une interface de 25 communication (104) destinée à la communication selon le premier protocole de communication (P1) ou le deuxième protocole de communication (P2) avec au moins une unité de commande électronique (U).
FR1463300A 2014-12-24 2014-12-24 Procede de transmission de donnees entre un serveur et une unite electronique de controle d’une installation domotique Active FR3031260B1 (fr)

Priority Applications (4)

Application Number Priority Date Filing Date Title
FR1463300A FR3031260B1 (fr) 2014-12-24 2014-12-24 Procede de transmission de donnees entre un serveur et une unite electronique de controle d’une installation domotique
US15/539,890 US20170346905A1 (en) 2014-12-24 2015-12-23 Method of transmitting data between a server and an electronic unit for control of a home automation installation
EP15823713.1A EP3238384A1 (fr) 2014-12-24 2015-12-23 Procédé de transmission de données entre un serveur et une unité électronique de contrôle d'une installation domotique
PCT/FR2015/053740 WO2016102903A1 (fr) 2014-12-24 2015-12-23 Procédé de transmission de données entre un serveur et une unité électronique de contrôle d'une installation domotique

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1463300 2014-12-24
FR1463300A FR3031260B1 (fr) 2014-12-24 2014-12-24 Procede de transmission de donnees entre un serveur et une unite electronique de controle d’une installation domotique

Publications (2)

Publication Number Publication Date
FR3031260A1 true FR3031260A1 (fr) 2016-07-01
FR3031260B1 FR3031260B1 (fr) 2018-02-09

Family

ID=52737280

Family Applications (1)

Application Number Title Priority Date Filing Date
FR1463300A Active FR3031260B1 (fr) 2014-12-24 2014-12-24 Procede de transmission de donnees entre un serveur et une unite electronique de controle d’une installation domotique

Country Status (4)

Country Link
US (1) US20170346905A1 (fr)
EP (1) EP3238384A1 (fr)
FR (1) FR3031260B1 (fr)
WO (1) WO2016102903A1 (fr)

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR3047374B1 (fr) * 2016-01-28 2018-07-27 Overkiz Procede de configuration, de controle ou de supervision d’une installation domotique
FR3061390B1 (fr) * 2016-12-28 2022-12-16 Overkiz Procede de configuration, de controle ou de supervision d’une installation domotique
FR3061399B1 (fr) 2016-12-28 2023-04-21 Overkiz Procede de configuration d’acces, de commande et de supervision a distance d’au moins un dispositif domotique appartenant a une installation domotique
FR3061400A1 (fr) 2016-12-28 2018-06-29 Overkiz Procede de configuration d’acces, de commande et de supervision a distance d’au moins un dispositif domotique appartenant a une installation domotique
EP3451606A1 (fr) * 2017-08-30 2019-03-06 Siemens Aktiengesellschaft Procédé de vérification de datagrammes transmis à l'intérieur d'un système d'automatisation industrielle et appareil d'automatisation et/ou de communication
US10834306B2 (en) 2019-01-15 2020-11-10 International Business Machines Corporation Method for a remote control of a radiation detection apparatus

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040151132A1 (en) * 2003-01-21 2004-08-05 Kabushiki Kaisha Toshiba Method of and apparatus for communication, communication control system, and computer product
DE102007016416A1 (de) * 2007-04-05 2008-10-09 Deutsche Telekom Ag Externer Zugriff auf lokales Netzwerk mit nichtpermanenter Internet-Anbindung
DE102011109678A1 (de) * 2011-08-08 2013-02-14 Rwe Effizienz Gmbh Kommunikationssystem
DE102012105698A1 (de) * 2012-06-28 2013-10-31 Deutsche Telekom Ag Externer Zugriff auf IP-basierte Haussteuereinheit in lokalem Netzwerk

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
TW200408242A (en) * 2002-09-06 2004-05-16 Matsushita Electric Ind Co Ltd Home terminal apparatus and communication system
JP3445986B1 (ja) * 2002-09-27 2003-09-16 松下電器産業株式会社 インターネットに接続するサーバ、機器および通信システム

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040151132A1 (en) * 2003-01-21 2004-08-05 Kabushiki Kaisha Toshiba Method of and apparatus for communication, communication control system, and computer product
DE102007016416A1 (de) * 2007-04-05 2008-10-09 Deutsche Telekom Ag Externer Zugriff auf lokales Netzwerk mit nichtpermanenter Internet-Anbindung
DE102011109678A1 (de) * 2011-08-08 2013-02-14 Rwe Effizienz Gmbh Kommunikationssystem
DE102012105698A1 (de) * 2012-06-28 2013-10-31 Deutsche Telekom Ag Externer Zugriff auf IP-basierte Haussteuereinheit in lokalem Netzwerk

Also Published As

Publication number Publication date
US20170346905A1 (en) 2017-11-30
WO2016102903A1 (fr) 2016-06-30
EP3238384A1 (fr) 2017-11-01
FR3031260B1 (fr) 2018-02-09

Similar Documents

Publication Publication Date Title
WO2016102903A1 (fr) Procédé de transmission de données entre un serveur et une unité électronique de contrôle d&#39;une installation domotique
EP3409054B1 (fr) Procede de synchronisation pour un noeud dans un réseau cellulaire
US7085937B1 (en) Adaptive method for amortizing authentication overhead
US10200504B2 (en) Communication protocols over internet protocol (IP) networks
EP3809388B1 (fr) Compteur de fluide communiquant avec une vanne électromécanique
EP3556151A1 (fr) Procédé de contrôle d&#39;un signal radio émis par une passerelle, passerelle et programme d&#39;ordinateur correspondants
US11811845B2 (en) Communication protocols over internet protocol (IP) networks
Nazir et al. Reliable image notifications for smart home security with MQTT
EP3622688B1 (fr) Singularisation de trames à émettre par un objet connecté et blocage de trames réémises sur un réseau de communication sans-fil basse consommation
WO2020089565A1 (fr) Systeme de supervision ameliore de capteurs connectes
EP3238383A1 (fr) Procédé de traitement de messages montants ou descendants applicatifs en provenance ou à destination d&#39;une unité électronique de contrôle d&#39;une installation domotique par un serveur
FR3012279A1 (fr) Procede de diffusion multipoints
Juste et al. Litter: A lightweight peer-to-peer microblogging service
EP2002585A1 (fr) Transmission de donnees confidentielle par changement de frequence dans un reseau de telecommunications
FR3087981A1 (fr) Procede securise de transmission de donnees au sein d&#39;un systeme de supervision
WO2023078995A2 (fr) Procédé de vérification de la fiabilité d&#39;une première valeur d&#39;un paramètre de contrôle de flux relatif à une connexion destinée à être établie entre un premier équipement de communication et un deuxième équipement de communication reliés par un chemin comprenant au moins un nœud intermédiaire au moyen d&#39;une valeur d&#39;un paramètre de performance intermédiaire déterminée par le nœud intermédiaire
WO2023078993A1 (fr) Procédé de gestion d&#39;une retransmission de données échangées sur un chemin établi entre un premier équipement de communication et un deuxième équipement de communication au moyen d&#39;une valeur d&#39;un paramètre de performance intermédiaire
WO2023169938A1 (fr) Procédé de gestion d&#39;une retransmission de données échangées sur un chemin établi entre un premier équipement de communication et un deuxième équipement de communication au moyen d&#39;une valeur d&#39;un paramètre de performance intermédiaire déterminée par un nœud intermédiaire appartenant audit chemin
EP2614630B1 (fr) Traitement de données pour la notification d&#39;un équipement
FR3079643A1 (fr) Procede de gestion d&#39;un dispositif electronique.
EP3360293A1 (fr) Moyens de gestion d&#39;accès à des données
FR3097666A1 (fr) Procédé de stockage de données d’authentification de documents
WO2016016576A1 (fr) Procédé automatique de mise a jour a distance d&#39;un logiciel contenu dans un dispositif émetteur radio autonome du type beacon
EP3224994A1 (fr) Procédé de notification de messages
WO2014108621A1 (fr) Dispositif de synchronisation de diffusion de signal sonore et diffuseur sonore

Legal Events

Date Code Title Description
PLFP Fee payment

Year of fee payment: 2

PLSC Publication of the preliminary search report

Effective date: 20160701

PLFP Fee payment

Year of fee payment: 3

PLFP Fee payment

Year of fee payment: 4

PLFP Fee payment

Year of fee payment: 6

PLFP Fee payment

Year of fee payment: 7

PLFP Fee payment

Year of fee payment: 8

PLFP Fee payment

Year of fee payment: 9

PLFP Fee payment

Year of fee payment: 10