FR 3035560 A1 20161028 FR 1553539 A 20150421 1 La présente invention concerne un procédé de configuration, de commande et/ou de supervision d'une installation domotique. Il est connu de procéder à la commande et/ou à la supervision d'une installation domotique par l'intermédiaire d'une multiplicité de protocoles de 5 communication. Ainsi, la liste non-exhaustive des protocoles à prendre en compte pour la commande et/ou la supervision d'une installation comprend : Z-Wave, EnOcean, 10 Homecontrol, Somfy RTS, KNX, MODBUS, Wavenis, Philips HUE ainsi que d'autres protocoles propriétaires. 10 Les protocoles utilisés de façon courante présentent des différences importantes. En particulier, les différents protocoles peuvent prévoir des mécanismes de partition logique des dispositifs qui sont différents. Ainsi, un dispositif physique avec de multiples fonctions peut être modélisé comme un dispositif logique unique ou une pluralité de dispositifs logiques. 15 Un dispositif peut se trouver, selon son type, dans différents états. A titre d'exemple, un état peut correspondre à la marche ou à l'arrêt pour un interrupteur, ou à un degré ou pourcentage d'ouverture pour un volet. La description des états des dispositifs peut être générique ou spécialisée, en fonction du protocole local. Les identifiants des variables d'état peuvent être numériques ou alphanumériques. Les 20 valeurs des variables d'états peuvent utiliser des formats ou des échelles personnalisées ou propriétaires. Les dispositifs sont aptes à interpréter et exécuter des commandes. La description des commandes de dispositif peut être générique ou spécialisée, les identifiants des commandes pouvant être numériques ou alpha numériques. Les 25 commandes peuvent présenter des paramètres, dont les valeurs peuvent utiliser des formats ou des échelles personnalisées ou propriétaires. Les protocoles de communication locaux utilisés peuvent être monodirectionnels, bidirectionnels sous forme d'échange requête/réponse ou de double échange monodirectionnel utilisant une approche évènementielle. Ces 30 protocoles utilisent un format propriétaire, usuellement binaire. Ainsi, le manque de normalisation dans les protocoles de communications locaux de dispositifs rend difficile la commande à distance et la supervision d'installations domotiques hétérogènes. La présente invention a pour but de résoudre tout ou partie des 35 inconvénients mentionnés ci-dessus. 3035560 2 A cet effet, la présente invention concerne un procédé de supervision d'au moins une installation domotique d'un bâtiment, l'installation domotique comprenant une pluralité de dispositifs domotiques, chaque dispositif domotique étant représenté par au moins une instance de modèle de dispositif générique et au moins une instance de modèle de dispositif de bas niveau ; le procédé étant exécuté par une unité de gestion connectée à l'au moins une installation domotique et comprenant les étapes suivantes : i. Réception d'un message de notification d'état en provenance d'une unité centrale de commande d'une installation domotique contenant une indication concernant au moins une variable d'état de bas-niveau d'un dispositif domotique ; ii. Détermination de l'au moins une instance de modèle de dispositif de bas-niveau représentant le dispositif domotique ; iii. Détermination d'une conversion d'état convertissant l'au moins une variable d'état de bas niveau en au moins une variable d'état générique sur la base d'au moins une règle de conversion d'état sélectionnée en fonction de l'au moins une variable d'état de bas-niveau ou de son type. iv. Détermination de l'au moins une instance de modèle de dispositif générique pour l'au moins une instance de modèle de dispositif de bas-niveau déterminée à l'étape ii ; v. Mise à jour de l'au moins une variable d'état générique de l'au moins une instance de modèle de dispositif générique déterminée à l'étape iv en fonction de la conversion d'état déterminée à l'étape iii. Il est à noter que l'étape iii peut être réalisée avant l'étape ii ou après l'étape iv suivant les modes de réalisation considérés. Grâce aux dispositions selon l'invention, il est possible de procéder à une supervision, notamment à une supervision à distance, de l'installation domotique de façon uniforme quelque soit le protocole de communication ou de commande local utilisé pour superviser les dispositifs domotiques. Ainsi, Le modèle générique de dispositif est un modèle indépendant du protocole permettant de décrire les dispositifs du bâtiment de façon fonctionnelle. Il est à noter que l'on entend par dispositif domotique un équipement domotique et/ou un capteur, ou encore une partie d'équipement domotique ou une partie de capteur correspondant à un sous-ensemble fonctionnel. 3035560 3 Par ailleurs, on entend par message un élément d'information notifié ou réceptionné sous la forme d'un appel synchrone ou asynchrone à l'unité de gestion, pouvant également correspondre à un appel de fonction local ou distant. Selon un aspect de l'invention, chaque instance de modèle de dispositif 5 générique comprend une indication d'appartenance à une classe ou un type de modèle de dispositif générique. Selon un aspect de l'invention, chaque instance de modèle de dispositif de bas- niveau comprend une indication d'appartenance à une classe ou un type de modèle de dispositif de bas-niveau. 10 Selon un aspect de l'invention, chaque instance de modèle de dispositif de bas- niveau comprend une indication d'un type de protocole de communication local reconnu par le dispositif domotique. Le traitement des informations stockées dans ce modèle de bas niveau pour un dispositif donné implique une connaissance du protocole particulier et du 15 format de données pour ce dispositif. Selon un aspect de l'invention, ce modèle peut présenter un format de structure commun pour les différents types de dispositifs de bas-niveau, mais les types des attributs, des variables d'états et des commandes définies dans ce modèle ne sont pas génériques. La conversion entre le modèle générique et le modèle de bas-niveau est 20 opérée sur la base d'un ensemble de règles de conversion de modèle prédéfinies, qui sont notamment enregistrées sur l'unité de gestion et permettent de fournir une abstraction des dispositifs pour les applications ou les utilisateurs. Selon un aspect de l'invention, l'unité de gestion est un serveur connecté à distance à l'au moins une installation domotique, par l'intermédiaire d'un réseau 25 étendu. Selon un autre aspect de l'invention, l'unité de gestion est une unité centrale destinée à être reliée à une ou plusieurs unités centrales de commande sur des réseaux privés ou locaux distincts, ou encore sur le même réseau local. Selon un aspect de l'invention, la sélection d'une règle de conversion 30 d'état en fonction de la variable d'état de bas niveau est réalisée sur la base du type de la variable d'état et du type de dispositif de bas-niveau. Selon un aspect de l'invention, les règles de conversion d'état sont stockées en association avec les données suivantes : un identifiant ou un nom de variable générique ; 35 un type de dispositif générique ; un identifiant ou un nom de variable de bas niveau ; 3035560 4 Selon un aspect de l'invention, une règle de conversion d'état définit la correspondance entre un identifiant d'une variable d'état de bas niveau et un identifiant d'une variable d'état générique, ainsi que une règle de conversion entre la 5 valeur d'une variable d'état de bas-niveau et une valeur d'une variable d'état générique. Selon un aspect de l'invention, le procédé comprend une étape de mise à jour de la valeur de la variable d'état de bas-niveau et de stockage de cette valeur. Selon un aspect de l'invention, les instances de modèle de dispositif 10 générique sont seulement partiellement mémorisées de façon persistante. Les valeurs des variables d'états générique sont recalculées à partir des données des instances de modèles de bas-niveau sur la base des règles de conversion d'état. Selon un aspect de l'invention, le procédé comprend en outre une étape d'émission d'un message de communication d'au moins une valeur de variable d'état 15 générique GS mise à jour à destination d'un terminal utilisateur ou d'une application exécutée sur l'unité de gestion ou sur une autre unité de gestion connectée. Cette communication peut être réalisée de façon sollicitée ou non par l'utilisateur ou l'application. Selon un aspect de l'invention, un système de notification et d'abonnement peut être mis en place. 20 Il est à noter que par autre unité de gestion connectée, il est entendu une autre unité de gestion présente sur le même réseau local ou sur un autre réseau local avec une connection à l'unité de gestion exécutant le procédé de supervision. Selon un aspect de l'invention, l'étape de détermination de l'instance de modèle de dispositif de bas-niveau comprend une détermination d'une clef 25 d'indexation sur la base d'éléments d'identification contenus dans le message ou déterminables à réception du message dont la combinaison permet une identification unique d'un dispositif domotique. Selon un aspect de l'invention, les différents éléments d'identification, pris individuellement, ne sont pas nécessairement uniques pour chaque dispositif ; 30 mais la combinaison de deux ou plusieurs éléments d'information doit l'être. L'identifiant de l'unité centrale de commande à laquelle le dispositif domotique est rattaché ou l'adresse du dispositif domotique, ou éventuellement celle de son parent dans un système d'adressage hiérarchique dans le réseau local géré par l'unité centrale de commande sont des exemples d'éléments d'identification. 35 La présente invention concerne également un procédé de commande d'au moins une installation domotique d'un bâtiment, l'installation domotique 3035560 5 comprenant une pluralité de dispositifs domotiques, chaque dispositif domotique étant représenté par au moins une instance de modèle de dispositif générique et au moins une instance de modèle de dispositif de bas niveau ; le procédé est exécuté par une unité de gestion connectée à l'au moins une installation domotique et comprend 5 les étapes suivantes : i. Réception d'un message de commande en provenance d'un utilisateur ou d'une application sur l'unité centrale de gestion ou sur une autre unité de gestion connectée, le message de commande correspondant à une commande générique relative à un dispositif 10 domotique ; ii. Détermination de l'au moins une instance de modèle de dispositif générique représentant le dispositif domotique ; iii. Détermination de l'au moins une instance de modèle de dispositif de bas-niveau pour l'au moins une instance de modèle de dispositif 15 générique déterminée à l'étape ii ; iv. Détermination d'une conversion de commande convertissant l'au moins une commande générique en au moins une commande de bas-niveau sur la base d'au moins une règle de conversion de commande sélectionnée en fonction de l'au moins une commande générique ou 20 de son nom. v. Envoi d'au moins un message de commande de bas-niveau comprenant l'au moins une commande de bas niveau correspondant à la conversion de commande déterminée à l'étape iv à destination d'une unité centrale de commande de l'installation domotique de 25 façon à déclencher l'exécution d'au moins une commande réelle correspondant à l'au moins une commande de bas-niveau sur le dispositif domotique correspondant à l'instance de bas niveau déterminée à l'étape iii. Il est à noter que l'étape iv peut être réalisée avant ou après l'étape iii 30 suivant les modes de réalisation considérés. Dans le cas ou l'étape iv est réalisée préalablement à l'étape iii, une éventuelle information relative au protocole local peut être utilisée de façon additionnelle à l'information concernant la commande générique. Cette information concernant le protocole local peut être obtenue d'un identifiant de l'instance de modèle de dispositif générique. 35 Grâce aux dispositions selon l'invention, il est possible de procéder à une commande, notamment à une commande à distance, de l'installation domotique de 3035560 6 façon uniforme quelque soit le protocole de communication ou de commande local utilisé pour commander les dispositifs domotiques. Il est ainsi possible, par exemple, de fournir une interface de programmation commune pour le pilotage de tous les dispositifs domotique réels ayant un même modèle générique, quelque soit le 5 protocole local et le dispositif de bas-niveau sous-jacent. Par autre unité de gestion connectée, on entend une autre unité de gestion présente sur le même réseau local ou sur un autre réseau avec une connection à l'unité de gestion exécutant le procédé. Selon un aspect de l'invention, la règle de conversion de commande est 10 sélectionnée en fonction de l'au moins une commande générique ou de son nom, et d'un type de dispositif de bas-niveau correspondant l'au moins une instance de modèle de dispositif de bas-niveau déterminée à l'étape iii. Selon un aspect de l'invention, les règles de conversion de commande sont stockées en association avec les données suivantes : 15 un type de dispositif de bas-niveau; - un nom ou identifiant de commande générique. Selon un aspect de l'invention, la sélection de la règle de conversion de commande est réalisée en utilisant le type de protocole de communication local et le nom ou identifiant de la commande générique. 20 Selon un aspect de l'invention, la conversion de commande d'au moins une commande générique applicable à l'au moins une instance du modèle générique en au moins une commande de bas niveau correspond à une combinaison d'une pluralité de commandes de bas niveau de et l'étape d'envoi correspond à l'envoi d'une pluralité de commandes à destination de l'unité centrale de commande de 25 façon à déclencher l'exécution d'une combinaison d'une pluralité de commandes réelles sur le dispositif. Selon un aspect de l'invention, le procédé comprend en outre les étapes suivantes : stockage en mémoire de la correspondance entre ladite commande 30 générique et la pluralité de commandes de bas niveau ; et détermination d'un résultat de la commande générique en fonction des résultats des commandes bas-niveau correspondantes. Grâce à ces dispositions, il est possible de déterminer un résultat de commande globale sur la commande générique originale en agrégeant des résultats 35 de commande reçus pour chaque commande de bas-niveau exécutée. 3035560 7 Selon un aspect de l'invention, la commande générique est considérée comme effectuée si toutes les commandes de bas-niveau ont été réalisées avec succès, et non-effectuée si une ou plusieurs commande de bas-niveau ont échoué. Selon un aspect de l'invention, les codes d'erreurs spécifiques du 5 protocole sont traduits en des types d'erreur génériques. La présente invention concerne également un procédé de configuration d'au moins une installation domotique d'un bâtiment, l'installation domotique comprenant une pluralité de dispositifs domotiques, chaque dispositif domotique 10 étant représenté par au moins une instance de modèle de dispositif générique et au moins une instance de modèle de dispositif de bas niveau ; le procédé est exécuté par une unité de gestion connectée à l'au moins une installation domotique et comprend les étapes suivantes : i. réception d'un message de configuration émis à partir d'une unité 15 centrale de commande d'une installation domotique ou d'un terminal utilisateur, le message contenant une indication d'une mise en service , d'une configuration ou d'une reconfiguration d'un dispositif domotique. ii. détermination d'au moins une classe ou type de modèle de dispositif 20 de bas-niveau correspondant au dispositif domotique ; iii. création d'au moins une instance de modèle de dispositif de bas-niveau en fonction de la classe ou type de dispositif de bas-niveau définie à l'étape ii et correspondant au dispositif domotique. iv. détermination d'une conversion de modèle convertissant un type ou 25 classe de dispositif de bas niveau en au moins une classe ou type de modèle de dispositif générique sur la base d'une règle de conversion de modèle sélectionnée en fonction de l'instance de modèle de dispositif bas-niveau déterminée à l'étape iii ou de son type. v. création d'au moins une instance de modèle de dispositif générique 30 pour l'au moins une instance de modèle de dispositif de bas-niveau sur la base de l'au moins un type ou classe correspondant à la conversion de modèle déterminé à l'étape iv. Selon un aspect de l'invention, on procède à un enregistrement des instances de modèles de dispositifs génériques de façon associée avec l'instance de 35 modèle de dispositif de bas-niveau. 3035560 8 Selon un aspect de l'invention, les règles de conversion de modèle sont stockées sous forme d'une association entre : - un type de dispositif de bas-niveau ; - au moins un type ou classe de dispositif générique 5 correspondant GDT. Selon un aspect de l'invention, le procédé comprend en outre les étapes suivantes : - Emission d'un message de communication de la configuration d'au moins un dispositif à destination d'un terminal utilisateur ou d'une application 10 exécutée sur l'unité de gestion ou sur une autre unité de gestion connectée. Cette communication peut être réalisée de façon sollicitée ou non par l'utilisateur ou l'application. Selon un aspect de l'invention, un système de notification et d'abonnement peut être mis en place. Par autre unité de gestion connectée, on entend une autre unité de 15 gestion présente sur le même réseau local ou sur un autre réseau avec une connection à l'unité de gestion exécutant le procédé. Selon un aspect de l'invention concernant le procédé de configuration, le procédé de commande et le procédé de supervision précédemment décrits, la détermination d'au moins une instance de modèle de dispositif générique pour l'au 20 moins instance de modèle de dispositif de bas-niveau correspond à une détermination d'un groupe d'instances de modèles de dispositif générique. Grâce à ces dispositions, il est possible de représenter de façon générique un dispositif réel complexe offrant des fonctions multiples. Dans un tel cas, les instances de modèles de dispositif génériques sont dispositifs relatifs à la même 25 instance de modèle de dispositif bas-niveau sont appelés sous-systèmes. Cela est notamment le cas en raison du fait que la couverture fonctionnelle d'un modèle de dispositif de bas niveau peut être différente suivant les protocoles considérés. Ainsi, un modèle de dispositif de bas niveau peut soit couvrir une fonction simple, soit de multiples fonctions d'un système complexe. A titre 30 d'exemple, un équipement de chauffage peut couvrir fonctionnellement des commandes de marche/arrêt/réglage du chauffage qui correspondent à une première instance modèle de dispositif générique de type « système de chauffage ». Cet équipement de chauffage peut également comprendre un ou plusieurs capteurs de température, éventuellement localisés à des positions distinctes qui peuvent 35 correspondre à des instances d'un autre modèle de dispositif générique relatif à un type ou une classe « capteur ». 3035560 9 Il est ainsi possible de définir un scénario de commande comprenant une commande destinée à un premier dispositif réel en utilisant un dispositif correspondant à un second dispositif réel, comme par exemple un capteur appartenant au second dispositif réel. 5 Cette disposition permet d'utiliser ces parties de dispositif ou sous- systèmes de façon séparée logiquement et fonctionnellement. Selon un aspect de l'invention, chaque instance de modèle de dispositif générique comprend un identifiant unique de dispositif générique. Grâce à ces dispositions, la description réalisée est indépendante du 10 protocole de communication local ou des détails d'implémentation du dispositif réel et de l'instance de modèle de dispositif de bas-niveau sous-jacent. Selon un aspect de l'invention, le modèle de dispositif générique définit un ensemble de commandes ou de fonctions associées audit modèle. Selon un aspect de l'invention, le modèle de dispositif générique définit 15 un ensemble d'états ou de variables d'états associés audit modèle. Selon un aspect de l'invention, le modèle de dispositif générique définit un ensemble d'attributs associés audit modèle. Selon un aspect de l'invention, les noms des états ou des variables d'états attachés à un modèle de dispositif générique sont explicites. 20 Selon un aspect de l'invention, les valeurs de variables d'états attachés à un modèle de dispositif générique sont normalisées. Selon un aspect de l'invention, les noms des commandes attachés à un modèle de dispositif générique sont explicites. Selon un aspect de l'invention, les paramètres de commandes attachés à 25 un modèle de dispositif générique sont normalisés. Selon un aspect de l'invention, l'identifiant unique de l'instance de modèle générique peut être constitué en particulier par un identifiant utilisant notamment une notation d'adresse indépendante du protocole, par exemple selon un format de type URL. 30 Selon un aspect de l'invention, chaque instance de modèle de dispositif de bas-niveau comprend en outre un identifiant de dispositif de bas-niveau unique dans le réseau local associé à une unité centrale de commande d'une installation domotique Selon un aspect de l'invention, le modèle de dispositif de bas niveau 35 définit un ensemble de commandes ou de fonctions associées audit modèle. 3035560 10 Selon un aspect de l'invention, le modèle de dispositif de bas niveau définit un ensemble d'états ou de variables d'états associés audit modèle. Selon un aspect de l'invention, le modèle de dispositif de bas niveau définit un ensemble d'attributs associés audit modèle. 5 Selon un aspect de l'invention, chaque instance de modèle de dispositif de bas-niveau comprend un type ou une classe de dispositif ; Selon un aspect de l'invention, chaque instance de modèle de dispositif de bas-niveau comprend un type de protocole utilisé dans le réseau local Selon un aspect de l'invention, une instance de modèle de dispositif de 10 bas-niveau RD peut être associé à une ou plusieurs commandes de bas niveau avec : - un nom ou identifiant de commande ; et - un ou plusieurs paramètres de bas-niveau. Selon un aspect de l'invention, la description des commandes n'est pas stockée dans les instances, mais peut être déterminée en fonction du type de 15 dispositif de bas-niveau et/ou du type de protocole utilisé dans le réseau local. En particulier, une commande de bas niveau peut être déterminée en fonction d'une règle de conversion de commande. Selon un aspect de l'invention, un méta-modèle de référence est maintenu pour stocker des informations communes sur les modèles de dispositif de 20 bas niveau, leurs variables d'états et les commandes attachées, à savoir : Les types de dispositifs de bas niveau supportés et leurs noms ; Les variables d'états de bas niveau supportés avec leurs identifiants RSID et les types de données pour les valeurs ; Les profils décrivant la relation entre les types de modèles de 25 dispositif de bas niveau et les valeurs de variables d'état autorisées. Selon un aspect de l'invention, ce méta-modèle de référence est partagé dans l'architecture pour permettre des vérifications d'intégrité et une gestion appropriée des valeurs de variables d'états des instances de modèles de dispositifs de bas niveau lorsque la connaissance du type de données est nécessaire, sans besoin de 30 stocker cette information pour chaque instance de modèle de dispositif de bas-niveau. Selon un aspect de l'invention, l'identifiant unique de dispositif générique comprend une adresse logique de dispositif qui établit une correspondance entre l'au moins une instance de modèle de dispositif générique et une instance de modèle de dispositif de bas-niveau. 35 Selon un aspect de l'invention, l'adresse logique de dispositif comprend : - un type protocole de communication du dispositif; 3035560 11 - un chemin de communication vers le dispositif. Selon un aspect de l'invention, le chemin de communication vers le dispositif inclut les éventuelles unités centrales de commande intermédiaires et les adresses de terminaison à traverser, organisées de préférence selon une topologie 5 hiérarchique. Selon un aspect de l'invention, l'adresse logique de dispositif comprend en outre : Un identifiant de sous-système si l'instance de modèle de dispositif générique appartient à un groupe d'instances de modèles de 10 dispositifs génériques associés à la même instance de modèle de dispositif de bas-niveau sous-jacente. La présente invention concerne également un produit programme d'ordinateur comprenant des instructions de code agencées pour mettre en oeuvre les étapes d'un procédé tel que détaillé précédemment, lorsque ledit programme est 15 exécuté par un processeur. La présente invention concerne également un système comprenant une unité de gestion agencée pour exécuter l'un des procédés détaillés ci-dessus, de façon connectée à une unité centrale de commande d'une installation domotique. Les différents aspects définis ci-dessus non incompatibles peuvent être 20 combinés. 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 une vue schématique d'un bâtiment et d'une installation domotique conforme à un mode de réalisation de l'invention ; 25 La figure 2 est un schéma présentant une architecture d'un système comprenant l'installation domotique illustrée à la figure 1 ainsi qu'un serveur destiné à être connecté à un terminal utilisateur ; La figure 3 est un schéma représentant un système d'abstraction des dispositifs domotiques. 30 La figure 4 est un schéma représentant un modèle de dispositif de bas niveau. La figure 5 est un schéma représentant un modèle de dispositif générique La figure 6 est un schéma illustrant un mode de mise en oeuvre d'un procédé de configuration d'une installation domotique selon l'invention. 35 La figure 7 est un schéma illustrant un mode de mise en oeuvre d'un procédé de supervision d'une installation domotique selon l'invention. 3035560 12 La figure 8 est un schéma illustrant un mode de mise en oeuvre d'un procédé de commande d'une installation domotique selon l'invention. Dans la description détaillée qui va suivre des figures définies ci-dessus, les mêmes éléments ou les éléments remplissant des fonctions identiques pourront 5 conserver les mêmes références de manière à simplifier la compréhension de l'invention. Comme illustré à la figure 1, un bâtiment 1 comprend à titre d'exemple trois pièces Pl, P2, P3. Le bâtiment 1 comprend également des équipements domotiques 3 et des capteurs 5. 10 Un équipement domotique 3 peut être un actionneur agencé pour déplacer ou régler un élément du bâtiment 1, par exemple un actionneur 7 pour déplacer un volet roulant 9 ou un store de terrasse 19, ou un système de régulation 10 pour un chauffage 11 ou un système aéraulique 13. Un équipement domotique 3 peut également être un éclairage, par exemple un éclairage extérieur de terrasse 21 ou un 15 système de commande d'éclairage, ou encore un système d'alarme. L'installation domotique 17 peut également comprendre un point de commande 15 d'un actionneur 7, comme un boîtier de commande B sans fil pour le volet roulant 9. L'installation domotique 17 peut comprendre un ou plusieurs capteurs 5, 20 de façon intégrée à un actionneur 7, à un point de commande 15 ou encore au boîtier de commande B, ou de façon indépendante à ces éléments. Un capteur 5 peut, notamment, être agencé pour mesurer une grandeur physique, par exemple un capteur de température, un capteur d'ensoleillement ou un capteur d'humidité. Des capteurs 5 de position d'équipements domotiques 3 du bâtiment 1, comme, par 25 exemple, des capteurs de l'état d'ouverture d'un volet roulant 9 ou des capteurs de position d'un ouvrant tel une fenêtre, motorisée ou non, peuvent également être prévus. L'installation domotique peut également comprendre un ou plusieurs capteurs de présence. Un équipement domotique 3 et un capteur 5 sont ainsi à considérer 30 comme des unités ayant à disposition des informations sur des états réels constatés d'éléments du bâtiment 1 et étant aptes à partager ces informations avec d'autres éléments de l'installation domotique 17. Les équipements domotiques 3 et les capteurs 5 peuvent ainsi avoir accès à toute grandeur physique mesurable, comme la température de chaque pièce Pl, P2, 35 P3 ou un état d'un élément du bâtiment 1, comme l'état d'ouverture d'un volet roulant 9, le statut d'une alarme, etc. 3035560 13 L'installation domotique 17 comprend une unité centrale de commande U agencée pour commander et/ou contrôler l'ensemble ou une partie des équipements domotiques 3 à distance, notamment en utilisant un protocole de communication sans fil, par exemple un protocole de communication radio. L'unité 5 centrale de commande est agencée pour regrouper l'ensemble des données en provenance des équipements domotiques 3 et pour traiter ces données. Les dispositifs appartiennent à un réseau local au sein de l'installation domotique et communiquent selon un protocole de communication local. Ils ont une adresse locale dans ce réseau. Les dispositifs logiques peuvent être modélisés comme 10 des noeuds ou points d'extrémité dans le réseau local. Le système d'adressage local peut être hiérarchique ou à plat, le format d'adresse pouvant être numérique ou alphanumérique. Comme cela est représenté sur la figure 2, l'unité centrale de commande U est agencée pour communiquer avec un serveur Sv. 15 L'unité centrale de commande U est disposée sur un réseau privé PN, PN', dont l'accès est en général protégé par un pare-feu FW. Le serveur Sv est également disposé sur un réseau privé SN. Le réseau privé PN est relié à un réseau étendu N, par exemple Internet. En particulier, l'unité centrale de commande U de l'installation 20 domotique 17 comprend une unité de traitement 2 agencée pour contenir et exécuter un premier programme d'ordinateur. La figure 2 représente deux unités centrales de commande U disposées sur deux réseaux privés correspondant à différentes installations domotiques. Bien entendu, le serveur Sv est agencé pour communiquer avec un ensemble de telles unités centrales de commande U. Nous décrirons par la 25 suite une de ces unités. 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. L'unité centrale de commande U comprend, en outre, au moins un module de communication 2' destinée au contrôle et/ou à la commande 30 d'équipements domotiques 3 et/ou de capteurs 5, les équipements domotiques 3 pouvant être des actionneurs 7, des éclairages 21 ou un système d'alarme. A titre d'exemple, comme cela est représenté sur la figure 2, le module de communication 2' permet le contrôle et la commande d'au moins un actionneur 7, d'un élément mobile du bâtiment 1, comme par exemple un volet roulant 9, ou d'un 35 brise soleil orientable 9' ou d'autres actionneurs 7 ou d'éclairages 21, comme cela est précédemment décrit en référence à la figure 1. 3035560 14 A titre d'exemple, le module de communication 2' peut être agencé pour mettre en oeuvre par exemple un ou plusieurs des protocoles Z-Wave, EnOcean, 10 Homecontrol, Somfy RTS, KNX, MODBUS, Wavenis, Philips HUE. La réception d'informations d'un capteur 5 fournissant des informations 5 de présence d'un utilisateur ou des valeurs des paramètres environnants, comme la température, l'humidité et la luminosité, est également prévue. De la même façon, l'unité centrale U peut permettre le contrôle et/ou la commande d'un système d'alarme. Chaque unité centrale de commande U comprend, en outre, un module 10 de communication 4 avec le serveur Sv. Le serveur Sv permet la commande et/ou le contrôle à distance et comprend une ou plusieurs unités de traitement 102 agencée pour contenir et exécuter un deuxième programme d'ordinateur. Le serveur Sv comprend, en outre, au moins une interface de communication 104 destinée à la communication avec l'unité centrale U. 15 Le serveur Sv peut comprendre également une interface de communication 106 destinée à la communication avec une interface de commande et/ou de contrôle IN permettant à un utilisateur de contrôler à distance l'installation domotique. 20 Il est à noter que le terme serveur est une désignation logique qui peut recouvrir l'utilisation de plusieurs serveurs physiques pour répartir la charge de traitement informatique à réaliser. L'interface de commande et/ou de contrôle IN comprend, par exemple, un serveur web 107 et un terminal de communication mobile T communiquant par le 25 réseau étendu N. Le terminal de communication mobile T peut être, par exemple, un téléphone intelligent ou une tablette. L'interface de commande et/ou de contrôle IN comprend un processeur qui peut être disposé au niveau du serveur web 107 et/ou du terminal de communication mobile T. 30 Le processeur de l'interface de commande et/ou de contrôle IN est agencé pour utiliser un troisième programme d'ordinateur. Ce troisième programme d'ordinateur est quant à lui agencé pour exécuter une application téléchargeable. Le terminal de communication mobile T comprend un dispositif d'entrée de données et un dispositif d'affichage, par exemple sous forme d'une partie de 35 commande tactile d'un écran du terminal T et sous forme d'un ou de plusieurs boutons du terminal T. 3035560 15 Selon un aspect de l'invention, et comme cela est représenté sur la figure 3, l'unité de traitement du serveur 102 est agencée pour mettre en oeuvre un système d'abstraction destinée à la commande et/ou au contrôle des dispositifs, équipements domotiques ou capteurs. Par la suite nous utiliserons la désignation de 5 dispositif D indifféremment pour désigner des capteurs ou des équipements domotiques, ou encore des parties d'équipements domotiques 3 ou de capteurs 5. Comme cela est représenté sur la figure 3, le système d'abstraction proposé met en oeuvre : Une pluralité de modèles de dispositifs de bas-niveau RDM destinés 10 au stockage d'informations dans un format spécifique d'un protocole sur un dispositif réel D donné, un seul modèle étant représenté sur la figure 3; Une pluralité de modèles de dispositifs génériques de haut-niveau GDM permettant la description des dispositifs réels D, de leurs 15 états S et des commandes C d'une façon indépendante du protocole, un seul modèle étant représenté sur la figure 3 ; ; et Une pluralité de pilotes de protocoles PD qui mettent en oeuvre les conversions nécessaires pour passer d'un modèle à l'autre et forment une couche d'abstraction de protocole PAL. 20 Comme cela est représenté sur la figure 4, le modèle de dispositif de bas niveau permet le stockage d'information sur les dispositifs et leur état, dans un format proche de leur format natif de protocole de communication. Le traitement des informations stockées dans ce modèle pour un dispositif donné implique une connaissance du protocole particulier et du format de 25 données pour ce dispositif. Selon un aspect de l'invention, ce modèle peut présenter un format de structure commun pour les différents types de dispositifs de bas-niveau, mais les types des attributs, des variables d'états et des commandes définies dans ce modèle ne sont pas génériques. Chaque instance RD d'un modèle de bas niveau RDM correspond à un 30 noeud adressable dans le réseau local auquel il appartient et dans lequel il communique selon le protocole cible. Le noeud agit comme une terminaison. Un tel noeud peut correspondre à un dispositif physique, une partie d'un dispositif (un sous-ensemble fonctionnel). Une instance RD d'un modèle de bas-niveau comprend : 3035560 16 Un identifiant de l'instance de modèle de bas niveau RDID, qui peut comprendre en particulier une adresse de terminaison dans le réseau local. Un type ou une classe de dispositif RDT; 5 Un type de protocole RDPT utilisé dans le réseau local. L'identifiant RDID ou adresse est utilisée comme une adresse de communication ou comme un chemin de routage. Cette adresse est unique, au moins dans le réseau local auquel appartient le dispositif D. L'information de type RDT peut être obtenue directement du dispositif 10 domotique D, mais il est peut être nécessaire d'utiliser des tables de référence externes ou même une information fournie par un utilisateur pour connaître le type de dispositif exact. Dans le cas où cette information est demandée à l'utilisateur, cette information RDT peut être demandée une unique fois à l'utilisateur lors de la phase de configuration/appairage du produit et ensuite stockée dans l'instance RD, en 15 particulier dans la base IDB qui sera décrite ultérieurement. Par ailleurs, chaque instance de modèle de bas niveau RD peut présenter : - Un ou plusieurs attributs RA; - Une ou plusieurs variables d'états RS; 20 Un attribut RA est notamment défini par un nom d'attribut RAN et par une valeur RAV. Les attributs RA représentent par exemple des informations additionnelles de type et/ou de configuration obtenues par exemple pendant la phase d'appairage. Les attributs sont notamment des informations invariables après l'appairage. 25 Une variable d'état RS est notamment définie par un identifiant unique RSID dans la portée du modèle de dispositif de bas-niveau RDM considéré, et par une valeur RSV. Les instances de modèles de dispositifs de bas niveau RD présentant des variables d'états RS peuvent autoriser des requêtes sur leur état et/ou envoyer des notifications lorsque la valeur de la variable d'état RSV change. 30 Une instance de modèle de dispositif de bas niveau RD peut également comporter une adresse parente RDPID. L'adresse parente RDPID permet aux instances de modèles de dispositif de bas niveau RD du même protocole d'être organisés en un arbre de noeuds hiérarchique. Cela est utile pour les protocoles dans lequel la topologie hiérarchique est nécessaire au routage des informations vers les noeuds, ou 35 dans le cas où un dispositif ne peut pas exister sans parent. 3035560 17 Ainsi, l'ensemble des instances RD d'une installation 17 peut former une liste ou un arbre de noeuds, dans le cas d'une topologie hiérarchique, suivant les protocoles utilisés. Comme cela est indiqué sur la figure 3, un méta-modèle de 5 référence RMM est maintenu pour stocker des informations communes sur les modèles de dispositif de bas niveau RDM, leurs variables d'états RS et les commandes attachées RC, à savoir : Les types de dispositifs de bas niveau RT supportés et leurs noms ; Les variables d'états RS de bas niveau supportées avec leurs 10 identifiants RSID et les types de données pour les valeurs RSV ; Les profils décrivant la relation entre les types de modèles de dispositif de bas niveau RDM et les valeurs de variables d'état RS autorisées. Ce méta-modèle de référence RMM est partagé dans l'architecture pour 15 permettre des vérifications d'intégrité et une gestion appropriée des valeurs de variables d'états RSV des instances de modèles de dispositifs de bas niveau RD lorsque la connaissance du type de données est nécessaire, sans besoin de stocker cette information pour chaque instance de modèle de dispositif de bas-niveau RD. Comme cela est représenté sur la figure 5, le modèle de dispositif 20 générique GDM est un modèle indépendant du protocole permettant de décrire les dispositifs du bâtiment de façon fonctionnelle. En particulier, une instance de modèle de dispositif générique GD comprend : Un identifiant unique de l'instance de modèle générique GDURL, 25 pouvant être constitué en particulier par un identifiant utilisant notamment une notation d'adresse indépendante du protocole, par exemple selon un format de type URL ; Un type ou une classe de dispositif générique GDT ; Par ailleurs, chaque instance de modèle générique GD peut présenter : 30 Un ou plusieurs attributs GA; Une ou plusieurs variables d'états GS . Un attribut GA est notamment défini par un nom d'attribut GAN et par une valeur GAV. Les attributs GA représentent par exemple des informations additionnelles de type et/ou de configuration obtenues par exemple pendant la phase 35 d'appairage. 3035560 18 Une variable d'état GS est notamment définie par un identifiant ou un nom unique GSID dans la portée du modèle de dispositif générique GDM considéré, et par une valeur GSV. Les instances de modèles de dispositif générique GD présentant des variables d'états GS peuvent autoriser des requêtes sur leur état et/ou envoyer 5 des notifications lorsque la valeur de la variable d'état GSV change. Une instance de modèle de dispositif générique GD peut possèder au moins une variable d'état GS. Cette variable d'état GS présente un identifiant ou nom d'état GSID explicite prédéfini par le modèle considéré, et une valeur de variable d'état GSV, sélectionnée parmi plusieurs valeurs prédéfinies ou appartenant à une 10 plage de valeur de variables d'état prédéfinie par le modèle considéré. En outre, une instance de modèle de dispositif générique GD peut être associée à une ou plusieurs commandes génériques GC avec : un nom de commande explicite GCID ; et Un ou plusieurs paramètres normalisés GCP. 15 Les commandes supportées sont définies par le modèle de dispositif générique GDM. Cette description est indépendante du protocole réel ou des détails d'implémentation d'un modèle de dispositif de bas niveau RDM sous-jacent. A titre d'exemple, un volet roulant peut être modélisé par une instance 20 de modèle de modèle de dispositif générique GD défini de la façon suivante : Classe ou Type GDT: « Volet Roulant Positionnable »/ (PositionableRollerShutter) ; Variable d'état GS: « Etat de fermeture »/(ClosureState) pouvant prendre des valeurs suivant une échelle normalisée de 0 à 100%; 25 Commande générique GC supportée : « réglage d'ouverture »/(SetClosure) avec un paramètre d'ouverture (amount) pouvant prendre des valeurs suivant une échelle normalisée de 0 à 100%. Une instance de modèle de dispositif générique GD est implicitement 30 reliée à au moins une instance de modèle de dispositif de bas niveau RD sous-jacente. En pratique, ce lien peut être modélisé par l'identifiant unique de l'instance de modèle générique GDURL qui correspond à une adresse de dispositif, et qui tient le rôle à la fois d'identifiant unique et de pointeur vers l'instance de modèle de dispositif de bas niveau RD sous-jacente. La réalisation du lien ou de la clé d'indexation sera 35 détaillée ultérieurement. 3035560 19 Il est à noter que dans certains cas, une instance de modèle de dispositif de bas-niveau RD peut correspondre à plusieurs instances de modèles de haut-niveau GD. Cela est notamment le cas en raison du fait que la couverture 5 fonctionnelle d'un modèle de dispositif de bas niveau peut être différente suivant les protocoles considérés. Ainsi, un modèle de dispositif de bas niveau peut soit couvrir une fonction simple, soit de multiples fonctions d'un système complexe. A titre d'exemple, un système de chauffage peut couvrir fonctionnellement des commandes de marche/arrêt/réglage du chauffage qui correspondent à une première instance 10 d'un modèle de dispositif générique GD de type « système de chauffage ». Ce système peut également comprendre un ou plusieurs capteurs de température, éventuellement localisés à des positions distinctes de l'installation domotique qui peuvent correspondre à des instances d'un autre modèle de dispositif générique GD relatif à un type ou une classe « capteur ». 15 Le système d'abstraction conçu permet de modéliser plusieurs instances de modèles de dispositif générique GD sur la base du même dispositif réel et de la même instance de modèle de dispositif de bas niveau RD sous-jacent. Dans un tel cas, les instances de modèles de dispositifs génériques GD relatifs à la même instance de dispositif de bas niveau RD peuvent être appelées sous-20 systèmes. Dans le cas où plusieurs dispositifs domotiques D sont groupés, dans leur protocole natif, par exemple dans le cas d'un ensemble de volets d'une façade d'un bâtiment, il est possible de créer une instance de modèle de dispositif de bas niveau virtuel RD, pour représenter le groupe dans un format proche de son protocole natif, 25 puis de lier cette instance de modèle de dispositif de bas niveau virtuel RD à une ou plusieurs instances de modèle de dispositif génériques GD. De cette façon, il est possible de conserver une correspondance entre au moins une instance de modèle de dispositif générique GD et une instance de modèle de dispositif de bas-niveau RD. La structure de l'identifiant unique d'une l'instance de modèle 30 générique GDURL va être à présent décrite de façon correspondante à un mode de réalisation particulier. Selon ce mode de réalisation, l'identifiant unique d'une instance de modèle générique GDURL comprend des informations sur : Le protocole natif local du dispositif domotique D; 35 Le chemin de communication vers le dispositif D, incluant les unités centrales de commande intermédiaires U et les adresses de 3035560 20 terminaison à traverser, organisées ou non dans une topologie hiérarchique ; Un identifiant de sous-système subsystemld si le dispositif appartient à un groupe d'instances de modèles de dispositifs génériques GD 5 associés à la même instance de modèle de dispositif de bas niveau RD sous-jacent. Les dispositifs qui sont une expression unique d'une instance de modèle de dispositif de bas niveau GD ne présentent pas d'extension d'identification d'un sous-système. Ainsi, la forme de l'identifiant unique d'une l'instance de modèle 10 générique GDURL peut être la suivante : :// krawDeviceAddress>(# ) Dans laquelle les champs suivants sont présents : protocol : identifiant du protocole local de dispositif natif; gatewayld : identifiant de la première unité centrale de commande U, par 15 exemple un numéro de série ou un identifiant unique. rawDeviceAddress : un chemin simple ou à plusieurs niveaux. Sa signification et son format dépendent du schéma d'adressage du protocole de communication local du dispositif D. subsystemld : ce champ optionnel indique une identification, par 20 exemple un rang du sous-système (démarrant par exemple à 1), si un tel sous-système est présent. Exemples: 1) knx://0201-0001-1234/1.1.3 Cet identifiant unique d'une l'instance de modèle de dispositif 25 générique GDURL correspond à un dispositif D communiquant par le protocole KNX avec une adresse individuelle 1.1.3 accessible par l'unité centrale de commande U portant l'identifiant #0201-0001-1234. 2) io://0201-0001-1234/145036#2 Cet identifiant unique d'une l'instance de modèle générique GDURL 30 correspond à un sous-système portant le n°2 associé à un dispositif D communiquant par le protocole io homecontrol avec une adresse radio 145036 accessible par l'unité centrale de commande U portant l'identifiant #0201-0001-1234. Les manipulations des différentes instances de modèles de dispositif de bas niveau RD et de dispositif génériques GD sont réalisées par un processus ou 35 service d'exécution ES. Afin de stocker les différentes instances de modèles mentionnées ci-dessus, le service d'exécution peut avoir accès à une base de données 3035560 21 d'instances IDB. Bien entendu, ces différents types d'instances peuvent être stockées également de façon séparée. Par ailleurs, par base de données, on entend ici un mode de stockage approprié pour un ensemble d'instances, qui peuvent être mémorisées dans une liste, un arbre ou des tables ou tout autre structure de données appropriée. 5 Un mode de réalisation de la base de données IDB va à présent être décrit. Selon ce mode de réalisation, la base de données IDB peut contenir des tables organisées sous forme de tableaux. Chaque ligne correspond à une instance de modèle dispositif domotique, bas niveau RD ou générique GD, selon la table considérée. Les colonnes correspondent aux différents types d'information stockée. 10 Ainsi, une table RDTbl des instances de modèle de dispositif de bas niveau RD peut contenir des colonnes comprenant les données suivantes : I - l'identifiant de l'unité centrale de commande U à laquelle un dispositif domotique est rattaché UID; Il - l'adresse du dispositif domotique dans le réseau local géré par l'unité 15 centrale de commande RDID; III - le type de protocole local utilisé RDPT; IV - type de modèle de dispositif bas niveau RDT, correspondant par exemple à une désignation de volet roulant ou encore d'éclairage. Une clé d'indexation RDK, unique pour chaque dispositif domotique, est 20 utilisée. Cette clé d'indexation unique RDK peut être générée à partir des trois éléments I, II, III énumérés ci-dessus; elle peut être stockée dans chaque table. Une autre possibilité est d'utiliser comme clé d'indexation RDK un identifiant qui s'autoincrémente au fur et à mesure de l'entrée des données dans la base IDB. Selon encore une autre possibilité, la clé d'indexation RDK peut être 25 calculée à chaque accès, en partant des éléments I, II, éventuellement III. De façon générale, dans le cas où la clé d'indexation est calculée, ce calcul peut se baser sur des éléments d'identification. Les éléments d'identification combinés doivent permettre l'identification d'un unique dispositif domotique de bas-niveau RD. 30 A noter que les différents éléments d'identification, pris individuellement, ne sont pas nécessairement uniques pour chaque dispositif mais la combinaison de deux ou plusieurs éléments d'information doit l'être. L'identifiant UID de l'unité centrale de commande U à laquelle le dispositif domotique D est rattaché ou l'adresse RDID du dispositif domotique, ou éventuellement celle de son parent 35 dans un système d'adressage hiérarchique dans le réseau local géré par l'unité 3035560 22 centrale de commande U sont des exemple d'éléments d'identification évoqués ci-dessus. Ces deux éléments sont suffisants pour une identification sans ambigüité du dispositif domotique. D'autres éléments d'identification peuvent être utilisés, par 5 exemple le type de protocole local utilisé par le dispositif. Cet élément supplémentaire d'identification permet la sélection rapide des instances RD, GD concernées, et du pilote de protocole PD à exécuter, étant donné qu'un pilote de protocole PD est spécifique d'un type de protocole natif. Il est à noter que, dans le cas où la clé d'indexation est calculée à chaque 10 accès, les mêmes informations peuvent être présentes dans des éléments d'identification sous des formats différents. Un exemple de ligne de table RDTbl est reproduit ci-dessous. UID RDID RDPT RDT 0201-0001-1234 120403 10 0x0100202 15 Cette ligne correspond à une table dans laquelle la clé d'indexation RDK est calculée et non stockée, pour un dispositif reliée à une unité centrale de commande portant l'identifiant 0201-0001-1234, le dispositif étant identifié par son adresse radio 10 120403 sur le réseau local 10, le type de protocole local utilisé étant 10 homecontrol, le type de modèle de dispositif de bas niveau étant 0x0100202, ce qui 20 correspond selon une implémentation à un volet roulant avec gestion de basse vitesse du fabricant SOMFY. D'autres informations, comme le nom des variables d'état RSID, les valeurs des variables d'états RSV, des indicateurs binaires (VRAI/FAUX) pour des commandes en cours d'exécution, etc., peuvent être stockées dans des tables 25 différentes ou dans la même table. Si des tables différentes sont utilisées, la clé d'indexation unique RDK pour chaque instance de modèle de dispositif de bas-niveau RD assure la correspondance entres les informations stockées et le dispositif concerné. Une table GDTbl des instances de modèle de dispositif générique GD peut 30 comprendre des colonnes comportant les données suivantes : 1- l'identifiant unique d'une l'instance de modèle générique GDURL ; Il - la classe ou type de dispositif générique GDT. Ainsi, un exemple de ligne de table GDTbl, correspondant à l'exemple précédemment illustré de ligne de table RDTbl est reproduite ci-dessous. 3035560 23 GDURL GDT io://0201-0001-1234/120403 RollerShutterWithLowSpeedSupport Cette ligne est relative à une instance de modèle de dispositif générique GD correspondant à l'instance de modèle de dispositif de bas-niveau RD 5 représentée dans l'exemple de table RDTbl représentée précédemment. D'autres informations, comme le nom des variables d'état GSID, les valeurs des variables d'états GSV peuvent être stockées dans des tables différentes ou dans la même table. Il peut être intéressant d'associer d'autres informations aux instances de modèles de dispositifs génériques, comme un nom, une localisation 10 physique du dispositif D dans l'installation. Toutefois, ces informations ne peuvent pas nécessairement être détectées et sont typiquement définies par l'installateur ou l'utilisateur. Une clé d'indexation unique GDK, représentant un dispositif domotique donné, peut être stockée dans la table. 15 Comme pour la table des instances de bas niveau, la clé d'indexation peut être calculée à chaque accès. Pour l'accès à la table des instances de modèle générique, il peut être utile de calculer cette clé GDK à partir de l'identifiant GDURL, par exemple en utilisant directement cet identifiant comme clé. Les instances de modèles bas niveau RD et générique GD sont calculées 20 et/ou stockées avec la même valeur de clé d'indexation GDK ou RDK, en ajoutant éventuellement un identifiant de sous-système dans le cas où plusieurs instances de dispositif génériques GD correspondent à une seule instance de modèle de dispositif de bas-niveau. Selon un mode de mise en oeuvre, les instances de modèle de dispositif 25 générique GD sont seulement partiellement mémorisées de façon persistante. Ainsi, seules les identifiants GDURL de dispositif et les classes ou types GDT sont persistées. Les attributs GA et les variables d'états GS sont recalculés à partir des données des instances de modèles de bas-niveau comme cela sera décrit ultérieurement. Les pilotes de protocoles PD identifiés sur la figure 3 vont être à présents 30 décrits. Les pilotes de protocole mettent en oeuvre la logique centrale de la couche d'abstraction, à savoir les règles de conversion diverses entre les deux modèles génériques et de bas niveau. Il peut exister un pilote de protocole PD par type de protocole supporté, même si différents pilotes peuvent partager des fonctionnalités communes, en capitalisant sur les implémentations existantes. 3035560 24 Chaque pilote de protocole PD peut réaliser un ensemble d'opérations de conversions. Afin de réaliser les différentes conversions mentionnées ci-dessous, un pilote de protocole peut être associé à une base de donnée de règles de conversion RDB comprenant les différents types de règles de conversion mentionnées ci-dessous, 5 à savoir : des règles de conversion de modèles MCR; des règles de conversion d'état SCR ; des règles de conversion de commande CCR. Bien entendu, ces différents types de règles peuvent être stockées également de façon séparées. Par ailleurs, par base de données, on entend ici un mode de stockage approprié pour un ensemble de règles, qui peuvent être mémorisées dans une liste, un arbre ou des tables ou tout 10 autre structure de données appropriée. Il est à noter que les règles de conversions MCR, SCR, CCR sont stockées ou enregistrées de façon indépendante des instances. Ces dispositions permettent de limiter le volume d'informations relatives aux conversions qui ne sont pas dupliquées pour chaque instance de modèle. En particulier, un pilote de protocole PD peut réaliser une conversion de 15 modèle CvM, c'est à dire la détermination ou la sélection d'une classe ou type de dispositif générique GDT, ou d'une liste de classes ou types GDT, à partir d'une instance de modèle de dispositif de bas niveau RD donnée, sur la base d'au moins une règle de conversion de modèle MCR. Si l'instance de modèle de dispositif de bas niveau RD nécessite d'être représentée par plusieurs instances de modèles de 20 dispositifs génériques GD, le pilote retournera une liste de tels sous-systèmes en tant que conversion de modèle CvM. En particulier, La sélection d'une classe générique de dispositif peut utiliser le type d'une instance de modèle dispositif de bas niveau RDT mais pourrait également utiliser d'autres attributs dans le processus de sélection. Ceci est utile par exemple pour les dispositifs modulaires pour lesquels une fonction 25 optionnelle peut être présente ou non. Par exemple : la présence optionnelle d'un capteur additionnel pour un système de chauffage. Selon un mode de réalisation, le pilote de protocole PD peut réaliser la détermination du type ou classe de modèle de dispositif générique GDT en consultant une table MTbl de sa base de données RDB. A titre d'exemple, la table MTbl peut 30 comprendre des colonnes comprenant les données suivantes : un type de dispositif de bas-niveau RDT au moins un type ou classe de dispositif générique correspondant GDT. Deux exemples de sélection de type GDT sont décrits ci-dessous. 35 Exemple 1: 3035560 25 Nous supposons que l'instance de dispositif de bas-niveau RD découverte ou configurée est définie de la façon décrite dans le tableau ci-dessous. RDPT RDT RA RDID 10 0x0100202 120403 5 Cette ligne correspond à un dispositif identifié par son adresse radio 10 120403 sur un réseau local 10 géré par une unité centrale de commande définie par identifiant UID non représenté, le type de protocole local utilisé étant 10 homecontrol, le type de modèle de dispositif de bas niveau étant 0x0100202, ce qui correspond selon une implémentation à un volet roulant avec gestion de basse vitesse du 10 fabricant SOMFY. Ces données sont communiquées comme entrée au pilote de protocole PD correspondant au protocole 10. Le pilote de protocole réalise la détermination du type ou classe de modèle de dispositif générique GDT en consultant la table MTbl de sa base de données RDB. La sélection permet d'identifier un exemple 15 de ligne de table MTbl reproduite ci-dessous. RDT GDT Ox0100202 RollerShutterWithLowSpeedSupport Ainsi, le type de dispositif générique identifié est « volet roulant avec gestion de basse vitesse » / (RollerShutterWithLowSpeedSupport). Dans cet exemple, 20 le type de dispositif de bas-niveau RDT est associé à un seul type de dispositif générique qui correspond à la conversion de modèle CvM. Il n'y a pas de sous-système. Exemple 2: 25 Nous supposons que l'instance de dispositif de bas-niveau RD découverte ou configurée est définie de la façon décrite dans le tableau ci-dessous. RDPT RDT RA RDID MODBUS 0x00101 TsensorAvailableT=true 4 3035560 26 Cette ligne correspond à un dispositif identifié par son adresse bus MODBUS 4 sur le réseau local MODBUS, le type de protocole local utilisé étant MODBUS, le type de modèle de dispositif de bas niveau étant 0x00101, ce qui correspond selon une implémentation à un système de chauffage avec un capteur de 5 température extérieure optionnel. Ces données sont communiquées comme entrée au pilote de protocole PD correspondant au protocole MODBUS. Le pilote de protocole réalise la détermination du type ou classe de modèle de dispositif générique GDT en consultant la table MTbl de sa base de données RDB. La sélection permet d'identifier un exemple 10 de ligne de table MTbl reproduite ci-dessous. RDT GDT 0x00101 HeatingSystemController OutsideAirTemperatureSensor attribute TsensorAvailableT=true) (only if Ainsi, les types de dispositif génériques GDT identifiés sont : « Contrôleur de système de chauffage » / (HeatingSystemController) ; 15 et « Capteur de température extérieure» / (OutsideAirTemperatureSensor). Dans cet exemple, le type de dispositif de bas-niveau RDT est associé à deux types de dispositif génériques qui correspondent à la conversion de 20 modèle CvM. Ainsi, l'instance de dispositif de modèle de bas-niveau RD sera associée à deux instances de modèle de dispositif générique GD qui forment deux sous-systèmes, à savoir un contrôleur principal et un capteur. Dans cet exemple le capteur est optionnel mais est présent sur le dispositif particulier considéré. Si le capteur n'était pas présent, par exemple parce qu'il n'avait pas été installé, le pilote de 25 protocole n'aurait retourné qu'un seul type correspondant donc à un seul sous-système, à savoir le contrôleur principal. Un pilote de protocole PD peut par ailleurs procéder à la conversion d'une variable d'état de bas niveau RS en une ou plusieurs variables d'états 30 génériques GS décrits dans la classe de dispositif générique GDT, sur la base d'au moins une règle de conversion d'état SCR. Ainsi, un pilote de protocole peut déterminer les valeurs des variables d'état génériques GS d'un type de modèle de 3035560 27 dispositif générique GDT à partir des valeurs de variables d'état de bas niveau RS correspondant à un identifiant RSID donné. Selon un mode de réalisation, le pilote de protocole PD peut réaliser la détermination d'une conversion d'état CvS d'une variable d'état de bas niveau RS en 5 une ou plusieurs variables d'états génériques GS en consultant une table STbl de sa base de donnée RDB. A titre d'exemple, la table STbl peut comprendre des colonnes comprenant les données suivantes : un identifiant ou un nom de variable générique GSID ; un type de dispositif générique GDT ; 10 un identifiant ou un nom de variable de bas niveau RSID; une règle de conversion d'état SCR entre la valeur d'une variable d'état de bas-niveau RSV et une valeur d'une variable d'état générique GSV. Deux exemples de conversion de variable d'état de bas-niveau RS sont 15 décrits ci-dessous. Exemple 1: Nous supposons qu'un message est reçu d'une unité centrale de commande U d'une installation domotique 17 contenant une indication d'une 20 modification concernant la valeur d'une variable d'état S du dispositif définie de la façon décrite dans le tableau ci-dessous. RDPT RDID RSID RSV MODBUS 1234 Ox0C213 123 Ce message correspond à la mise à jour de la variable de d'état RSID 25 Ox0C213 correspondant au mode de régulation d'un dispositif de type système de chauffage à l'adresse RDID 1234 de son réseau local communiquant selon le protocole local RDPT MODBUS, la nouvelle valeur RSV étant 123. Le pilote de protocole PD du protocole MODBUS peut sur cette base procéder à la conversion, en sélectionnant une règle de conversion d'état SCR ou 30 fonction de conversion en utilisant le type de dispositif de bas-niveau RDT (non représenté) et le nom ou identifiant de la variable d'état de bas niveau RSID. La sélection permet d'identifier un exemple de ligne de table STbl reproduite ci-dessous. 3035560 28 GSID GDT RSID SCR RegulationModeState HeatingSystem 0x0C213 if (v == 123) then return 'auto' else return 'manual' end; Ainsi, la nouvelle valeur identifiée 123 pour la variable d'état de bas niveau identifiée par le RSID 0x0C213 correspond à la valeur de conversion d'état CvS « Auto» pour une variable générique GS « RegulationModeState » d'une instance 5 de modèle de dispositif générique « HeatingSystem ». Exemple 2: Nous supposons qu'un message est reçu d'une unité centrale de commande U d'une installation domotique 17 contenant un une indication d'une 10 modification concernant une variable d'état RS du dispositif de bas-niveau. La mise à jour d'une variable d'état RS est décrite dans le tableau ci-dessous. RDPT RDID RSID RSV 10 101 0x14 1024000 Ce message correspond à la mise à jour de la variable de d'état RSID 15 0x014 correspondant à la température mesurée par un capteur d'un système de chauffage à l'adresse RDID 101 de son réseau local communiquant selon le protocole local RDPTIO homecontrol, la nouvelle valeur RSV étant 1024000. Le pilote de protocole PD de protocole 10 peut sur cette base procéder à la conversion, en sélectionnant une règle de conversion d'état SCR ou fonction de 20 conversion en utilisant le type de dispositif de bas-niveau RDT (non représenté) et le nom ou identifiant de la variable d'état de bas niveau RSID. La sélection permet d'identifier un exemple de ligne de table STbl reproduite ci-dessous. GSID GDT RSID SCR TemperatureState TemperatureSensor 0x14 return v/51200; 25 3035560 29 Ainsi, la nouvelle valeur identifiée 1024000 pour la variable d'état identifiée par le RSID 0x014 correspond à une valeur de conversion d'état CvS de 21 (°C) pour une variable générique GS de Température / (« TemperatureState ») d'une instance de modèle de dispositif générique de type « Capteur de température » / 5 ( Tem peratu reSensor ). Un pilote de protocole peut en outre procéder à la conversion des commandes génériques GC associées à une instance de modèle de dispositif générique GD en une ou plusieurs commandes de bas-niveau RC spécifiques du 10 protocole à exécuter sur le dispositif réel D, sur la base d'au moins une règle de conversion de commande CCR. Par exemple, la commande décrite ci-dessus setClosure(50%) peut avoir différentes traductions en fonction du protocole du dispositif de bas niveau RD et de son type RDT, et parfois de la configuration particulière de ce dispositif. Cette conversion est implémentée dans le pilote de 15 protocole correspondant au protocole de communication local utilisé par le dispositif domotique. Ainsi, pour convertir une commande générique GC en une commande de bas-niveau RC ou une combinaison de commandes de bas niveau RC, il convient de procéder à : 20 une reconnaissance de l'instance de modèle de dispositif de bas- niveau cible RD, par l'intermédiaire de l'identifiant d'instance de modèle de dispositif générique fournie GDURL ; puis une détermination de la conversion à réaliser sur la base de l'instance sélectionnée RD en utilisant une règle de conversion de 25 commande CCR ou fonction de conversion. Dans la plupart des cas, le pilote de protocole utilise seulement le type de dispositif de bas-niveau RDT, mais dans certains cas complexes, la valeur de certains attributs peut être nécessaire pour déterminer complètement la commande de bas niveau à générer. Dans de tels cas, le pilote de protocole peut accéder aux attributs 30 requis en utilisant l'identifiant d'unité centrale de commande UID et l'identifiant de l'instance de dispositif de bas-niveau RDID. La commande générique GC peut présenter des paramètres, auquel cas ceux seront transmis à règle de conversion CCR. La règle de conversion CCR peut également utiliser des informations contextuelles comme l'utilisation attendue de la 35 commande ou le niveau de priorité de la commande. Les commandes de bas-niveau 3035560 30 peuvent ensuite être transmises à l'unité centrale de commande correspondante pour exécution. Selon un mode de réalisation, le pilote de protocole PD peut réaliser la détermination d'une conversion d'une commande générique GC en une ou plusieurs 5 commandes de bas-niveau RC en consultant une table CTbl de sa base de données RDB. A titre d'exemple, la table CTbl peut comprendre des colonnes comprenant les données suivantes : - un type de dispositif de bas-niveau RDT; - un nom ou identifiant de commande générique GCID; 10 - une règle de conversion de commande CCR ou fonction de conversion. Deux exemples de conversion de commande générique GC sont décrits ci-dessous. 15 Exemple 1: Nous supposons que la commande générique GC appelée est définie de la façon décrite dans le tableau ci-dessous. GDURL GC io :1/1234-5678-0000/120403 setClosure(60%) 20 Cette commande correspond à un ordre à un volet roulant communiquant en 10 avec une adresse radio 120403 dans le réseau local géré par l'unité centrale de commande ayant l'identifiant 1234-5678-0000, de se fermer à 60%. Il convient dans un premier temps de déterminer l'instance de modèle de dispositif de bas niveau correspondante et son type, en utilisant l'adresse comprise 25 dans le GDURL. Nous supposerons que le type de dispositif de bas-niveau RDT est 0x0100202, ce qui correspond à un volet roulant avec gestion de basse vitesse du fabricant SOM FY. Le pilote de protocole peut ensuite sur cette base procéder à la conversion, en sélectionnant une règle de conversion de commande CCR ou fonction 30 de conversion en utilisant le type de dispositif de bas-niveau RDT et le nom ou identifiant de la commande générique GCID. La sélection permet d'identifier un exemple de ligne de table CTbl reproduite ci-dessous. 3035560 31 RDT GCID CCR 0x0100202 setClosure (with one return parameter pl) createActivateFunc(pl*51200) La règle de conversion de commande CCR crée une commande de bas-niveau RC de type 'Activate Func', spécifique du protocole 10 avec un paramètre principal mis à l'échelle à partir du paramètre générique pl. Ici, la fonction 5 « createActivateFunc()» retourne des données binaires destinées à être utilisée par une unité centrale de commande U pour former le corps (payload) d'une trame radio 10. Exemple 2: 10 Nous supposons que la commande générique GC appelée est définie de la façon décrite dans le tableau ci-dessous. GDURL GC modbus://1234-5678-0000/4 setTargetTemperature(21) Cette commande correspond à un ordre à un système de chauffage 15 communiquant en MODBUS avec une adresse bus 4 dans le réseau local géré par l'unité centrale de commande 1234-5678-0000 de régler son thermostat sur une température de consigne de 21°C. Il convient dans un premier temps de déterminer l'instance de modèle de dispositif de bas niveau correspondante et son type, en utilisant l'adresse comprise 20 dans le GDURL. Nous supposerons que le type de dispositif de bas-niveau RDT est 0x00101, ce qui correspond selon une implémentation à un système de chauffage avec un capteur de température extérieure optionnel. Le pilote de protocole peut ensuite sur cette base procéder à la conversion, en sélectionnant une règle de conversion de commande CCR ou fonction 25 de conversion en utilisant le type de dispositif de bas-niveau RDT et le nom ou identifiant de la commande générique GCID. La sélection permet d'identifier un exemple de ligne de table CTbl reproduite ci-dessous. 30 3035560 32 RDT GCID CCR 0x00101 setTargetTemperature (with one parameter pl) return { createConfigurationModeCommand(), createSetTargetTemperatureCommand(p1) } La règle de conversion de commande CCR crée deux commandes de bas-niveau RC : la première commande met le dispositif en mode configuration et la seconde commande définit la température cible en utilisant la valeur du paramètre 5 générique pl. Ici, les fonctions « createConfigurationModeCommand() » et « createSetTargetTemperatureCommand() » retournent des données binaires spécifiques au protocole MODBUS destinées à être transmise sur le bus du dispositif par une unité centrale de commande U pour changer la configuration du système de chauffage. 10 Les figures 6 à 8 représentent des modes de mise en oeuvre de procédés de configuration, de supervision et de commande sur la base du système décrit ci-dessus. Un procédé de configuration d'une d'au moins une installation domotique 17 d'un bâtiment 1 exécuté par un serveur Sv connecté à l'au moins une 15 installation domotique 17 va être à présent décrit en référence à la figure 6. Dans un premier temps, le procédé comprend une étape de réception ECfES1 d'un message de configuration MCf émis à partir d'une unité centrale de commande U d'une installation domotique 17, dans une étape ECfUl. Le message de configuration MCf contient une indication d'une mise en service d'un 20 nouveau dispositif domotique D ou d'une mise à jour/reconfiguration d'un dispositif préalablement installé. Selon une alternative, il est possible que le message MCf soit émis par un terminal T d'un utilisateur dans une étape ECfTl. A titre d'exemple, dans le cas de protocoles monodirectionnels, l'utilisateur peut effectuer la mise en service, la 25 configuration ou la reconfiguration/mise à jour du dispositif D sur le lieu de l'installation domotique et envoyer ensuite les informations avec son terminal T pour initier le procédé de configuration. Le procédé comprend ensuite une étape de création ECfES2 de l'au moins une instance de modèle de dispositif de bas-niveau RD représentant le dispositif domotique D. L'instance de modèle de dispositif de bas- 30 niveau RD est stockée dans la base de données IDB accessible au service d'exécution ES. En particulier une ligne de la table RDTbl peut être créée comme cela a été décrit précédemment sur la base des informations contenues ou déduites de la réception du 3035560 33 message MCf. En effet, le contenu du message MCf ou les informations sur son émetteur permettent de déterminer des informations sur : l'identifiant de l'unité centrale de commande U à laquelle un dispositif domotique est rattaché Ul D; 5 l'adresse du dispositif domotique dans le réseau local géré par l'unité centrale de commande RDID; le type de protocole local utilisé RDPT; type de modèle de dispositif bas niveau RDT, correspondant par exemple à une désignation de volet roulant ou encore d'éclairage. 10 Une étape de détermination ECfS3 d'une classe ou type de dispositif générique GDT, ou d'une liste de classes ou types GDT, à partir d'une instance de modèle de dispositif de bas niveau RD donnée est ensuite réalisée, ce qui correspond à la détermination d'une conversion de modèle CvM. Cette étape est réalisée par le biais d'un appel de fonction du pilote de protocole PD qui reçoit cet appel dans une 15 étape ECfPD3 et qui dispose de la base de données de règles de conversion RDB comprenant des règles de conversion de modèle MCR. Si l'instance de modèle de dispositif de bas niveau RD nécessite d'être représentée par plusieurs instances de modèles de dispositifs génériques GD, le pilote retournera une liste de telles classes ou types de sous-systèmes GDT1, GDT2, comme cela a également été décrit 20 précédemment. Une étape de création ECfES4 de l'au moins une instance de modèle de dispositif générique GD1, GD2 pour l'au moins une instance de modèle de dispositif de bas-niveau RD est ensuite réalisée sur la base des types ou classes GDT1, GDT2 déterminés à l'étape ECfES3. Les instances de modèles de dispositifs génériques GD1, 25 GD2 sont stockées dans la base IDB, par exemple dans une table GDTbl comme cela a été décrit précédemment. Le lien entre une instance de modèle de dispositif de bas-niveau RD et une ou plusieurs instances de modèles génériques GD1, GD2 peut notamment être réalisé par les identifiants GDURL ou les clés d'indexation GDK et RDK comme cela a été décrit précédemment. 30 Le procédé peut comprendre une étape ultérieure ECfES5 de notification de l'utilisateur sur la configuration d'un nouveau dispositif D, de façon sollicitée ou non par l'utilisateur, qui reçoit cette notification dans une étape ECfUsr5. Il est également possible de procéder à la notification d'une autre application A exécutée sur le serveur Sv qui reçoit cette notification dans une étape ECfA5. 35 Le procédé de configuration est réalisé lors de la mise en service, de la configuration ou de la reconfiguration d'un équipement domotique D. 3035560 34 Un procédé de supervision d'au moins une installation domotique 17 d'un bâtiment 1 exécuté par un serveur Sv connecté à l'au moins une installation domotique 17 va être à présent décrit en référence à la figure 7. Nous supposerons que le procédé de supervision est réalisé postérieurement au procédé de 5 configuration précédemment décrit. Ainsi, les instances de modèles de dispositif de bas-niveau RD, et les instances de modèles de dispositif génériques GD sont stockées dans une base de données d'instances IDB accessible au service d'exécution ES, comme nous l'avons précédemment décrit. Dans un premier temps, le procédé comprend une étape de 10 réception ESES1 d'un message de notification d'état MS émis lors d'une étape ESU1 par une unité centrale de commande U d'une installation domotique 17. Le message de notification d'état MS contient une indication concernant une variable d'état de bas niveau RS d'un dispositif domotique D. Le message MS peut contenir un identifiant de protocole RDPT, une adresse du dispositif dans le protocole RDID, un 15 identifiant de la variable d'état concernée RSID et la nouvelle valeur de la variable d'état RSV. Le procédé comprend ensuite une étape de détermination ESES2 de l'au moins une instance de modèle de dispositif de bas-niveau RD représentant le dispositif domotique D. Cette détermination peut notamment être réalisée en 20 utilisant le contenu du message de notification d'état MS et/ou en identifiant l'émetteur de ce message, dans cet exemple l'unité centrale de commande U. En particulier, il convient soit d'utiliser une clé d'indexation RDK déjà présente dans le message, soit, si cette clé n'est pas présente, d'identifier les éléments d'identification permettant de déterminer cette clé RDK qui sera ensuite 25 utilisée pour sélectionner l'instance de dispositif de modèle de bas-niveau RD dans la base de donnée IDB, par exemple dans la table RDTbl décrite précédemment. Les éléments d'identification sont soit contenus explicitement dans le message de notification MS en provenance de l'unité centrale de commande U, si ce message comporte des champs dédiés pour l'identification des entités source et 30 destination du message ; soit déduits lors de la réception du message de notification MS. A titre d'exemple, une unité centrale de commande peut être identifiée par : son adresse IP, par le n° de port TCP ou la combinaison de ces deux éléments (adresse IP, port TCP, c'est-à-dire l'identifiant d'un socket pour une connexion Internet) ; ou encore par l'identifiant logique d'un canal de communication établi entre l'unité 35 centrale de commande U et le serveur Sv. Une fois l'instance de dispositif de modèle 3035560 35 de bas niveau RD identifiée, Une étape de mise à jour ESES3 de la variable d'état de bas niveau RS dans la base de données IDB est réalisée. Une étape de conversion ESES4 d'une variable d'état de bas niveau RS en une ou plusieurs variables d'états génériques GS décrits dans une ou plusieurs classes 5 de dispositif générique GDT est ensuite réalisée. Cette étape est effectuée en particulier par un appel au pilote de protocole PD qui possède une base de règles de conversion RDB comprenant notamment des règles de conversion d'état SCR qui permettent de convertir une variable d'état de bas niveau RS d'un type de dispositif de bas niveau RDT en une ou plusieurs variables génériques GS1, GS2, GS3 d'une ou 10 plusieurs instances de modèles de dispositifs génériques GD, comme cela a été décrit précédemment, en utilisant par exemple la table STbl. Le pilote de protocole effectue à cet effet une étape de sélection de règle de conversion d'états SCR dans la base de règles de conversion RDB dans une étape ESPD4, puis retourne soit le résultat de la conversion CvS d'une variable d'état RS en une ou plusieurs variables d'état 15 génériques GS, soit une règle à exécuter par le service d'exécution pour obtenir une conversion CvS correspondant à une ou plusieurs variables d'état génériques GS. Une étape de détermination ESES5 de l'au moins une instance de modèle de dispositif générique GD pour laquelle l'au moins une variable d'état GS doit être mise à jour est ensuite réalisée. Cette détermination peut se baser sur le ou les types 20 de dispositif générique RDT associées à l'au moins une variable d'état générique GS à mettre à jour et sur l'instance de modèle de dispositif de bas-niveau RD déterminée lors de l'étape ESES2. Une fois que la clé d'indexation RDK a été déterminée pour l'instance de modèle de dispositif de bas-niveau RD, la clé d'indexation GDK, qui correspond à 25 l'identifiant est aisée à déterminer. Dans le cas où plusieurs sous-systèmes GD correspondent à une même instance de modèle de dispositif de bas-niveau, l'information concernant le type de dispositif générique retournée par le pilote de protocole PD permet de définir le sous-système GD devant être mis à jour. Le procédé comprend ensuite une étape ESES6 de mise à jour d'une ou 30 plusieurs variables d'états génériques GS sur la base de la conversion CvS déterminée pour l'instance de modèle de dispositif générique déterminé GD dans la base de données IDB. Le procédé peut comprendre une étape ultérieure ESES7 de restitution des valeurs de variables d'états génériques GS mises à jour à destination d'un 35 utilisateur Usr, de façon sollicitée ou non par l'utilisateur, qui reçoit ces valeurs dans une étape ESUsr7. Il est également possible de procéder à la notification d'une autre 3035560 36 application A exécutée sur le serveur Sv qui reçoit cette notification dans une étape ESA7. Un procédé de commande d'au moins une installation domotique 17 d'un bâtiment 1 exécuté par un serveur Sv connecté à l'au moins une installation 5 domotique 17 va être à présent décrit en référence à la figure 8. Ce procédé peut être exécuté par exemple par un processus ou service d'exécution ES utilisant les fonctions d'un ou de plusieurs pilotes d'exécution PD tels que décrits ci-dessus. Dans un premier temps, le procédé comprend une étape de réception ECES1 d'une commande générique GC dans un message MC en provenance 10 i) d'un terminal T d'un utilisateur Usr ou ii) d'une application A s'exécutant sur le serveur Sv émis dans une étape ECUsr1 ou ECA1 respectivement et relative à un dispositif domotique D. Une étape de détermination ECES2 de l'au moins une instance de modèle 15 de dispositif générique GD représentant le dispositif domotique D est ensuite réalisée, notamment en utilisant l'identifiant unique GDURL du dispositif générique GD qui fait office de clé d'indexation et qui regroupe les éléments d'identification nécessaires correspondant à une instance unique de modèle de dispositif générique GD. Cet identifiant peut être inclus dans le message de commande MC. Une fois l'étape ECES2 20 réalisée, le procédé comprend une étape de détermination ECES3 de l'au moins une instance de modèle de dispositif de bas-niveau RD correspondant à l'au moins une instance de modèle générique GD déterminé à l'étape précédente. Les instances de modèles de dispositif de bas-niveau RD, et les instances de modèles de dispositif génériques GD sont stockées dans une base de données d'instances IDB accessible au 25 service d'exécution ES. Ainsi, les étapes ECES2 et ECES3 peuvent être réalisées en consultant ladite base IDB. Une étape de conversion ECES4 d'une ou plusieurs commandes génériques GC de l'au moins une instance de modèle de dispositif générique GD déterminée à l'étape ECES2 en au moins une commande de bas-niveau RC de 30 l'instance de modèle de dispositif de bas niveau RD déterminée à l'étape ECES3 est ensuite réalisée. Cette étape est effectuée en particulier par un appel au pilote de protocole PD qui possède une base de règles de conversion de commande en fonction des types de modèles de dispositif génériques GD et de modèles de dispositif de bas-niveau RD utilisés. Le pilote de protocole effectue à cet effet une étape de sélection 35 de règle de conversion dans la base de règles de conversion RDB dans une étape ECPD4, puis retourne une conversion de commande CyC correspondant à une 3035560 37 commande de bas niveau RC à exécuter ou une pluralité de commandes de bas niveau RC1, RC2, RC3 à exécuter. Par la suite, l'exécution de la commande peut être réalisée. La figure 7 correspond à un cas où la conversion d'au moins une commande générique GC applicable à l'au moins une instance du modèle de dispositif générique 5 GD correspond à une pluralité de commande de bas niveau RC1, RC2, RC3, correspondant l'exécution d'une combinaison d'une pluralité de commandes réelles C sur le dispositif domotique D. Dans un tel cas, la correspondance entre les commandes de haut-niveau GC et les commandes de bas niveau RC associées sont gardées en mémoire pour une gestion d'erreur appropriée. En particulier le service 10 d'exécution ES peut mettre en oeuvre un automate à états à cette fin. Ainsi, dans une étape ECES5, une première commande RC1 est envoyée à destination de l'unité centrale U de l'installation domotique 17 en vue de l'exécution de la commande par le dispositif D, dans un premier message de commande de bas-niveau MRC1. Dans l'exemple représenté, nous supposons que le retour de cette 15 première commande correspond à un succès de la commande avec un code de retour RRC1, envoyé par l'unité centrale de commande U dans une étape ECU5. Le service d'exécution peut stocker cette valeur de succès OK pour la première commande RC1. Dans une étape ECES6, une deuxième commande RC2 est envoyée à 20 destination de l'unité centrale U de l'installation domotique 17 en vue de l'exécution de la commande par le dispositif D, dans un deuxième message de commande de bas-niveau MRC2. Dans l'exemple représenté, nous supposons que le retour de deuxième commande correspond à un échec de la commande, avec retour d'un code de retour RRC2 présentant par exemple une valeur numérique -2 correspondant à une 25 erreur, envoyé par l'unité centrale de commande U dans une étape ECU6. Par la suite, le service d'exécution demande, dans une étape ECES7, une conversion du code de retour RRC2 en un code de retour générique GRC2 auprès du pilote de protocole PD qui procède à cette conversion dans une étape ECPD7. A titre d'exemple, le code d'erreur numérique -2 peut être traduit en un code de retour 30 générique GRC2 correspondant à une erreur de type « commande non autorisée ». Le code GRC2 est stocké par le service d'exécution ES. Dans une étape ECES8, une troisième commande RC3 est envoyée à destination de l'unité centrale U de l'installation domotique 17 en vue de l'exécution de la commande par le dispositif domotique D, dans un troisième message de 35 commande de bas-niveau MRC3. Dans l'exemple représenté, nous supposons que le retour de troisième commande correspond à un échec de la commande, avec retour 3035560 38 d'un code RRC3 présentant par exemple une valeur numérique -7, envoyé par l'unité centrale de commande U dans une étape ECU8. Par la suite, le service d'exécution demande, dans une étape ECES9, une conversion du code de retour RRC3 en un code de retour générique GRC3 auprès du 5 pilote de protocole PD qui procède à cette conversion dans une étape ECPD9. A titre d'exemple, le code d'erreur numérique -2 peut être traduit en un code d'erreur générique GRC3 « pas de réponse radio ». Le code GRC3 est stocké par le service d'exécution ES. Dans une dernière étape ECES10, le service d'exécution définit une 10 réponse à retourner à l'utilisateur suite au message de commande MC, qui la reçoit dans une étape ECUsr10. Etant donné qu'un résultat de commande ou code de retour GERC1, a été reçue pour chaque commande de bas niveau RC1, RC2, RC3 exécutée, les résultats doivent être agrégés pour simuler un résultat de commande globale sur la commande 15 générique originale. En particulier, la commande générique est considérée comme effectuée si toutes les commandes de bas niveau ont été réalisées avec succès, et non-effectuée si une ou plusieurs commande de bas niveau ont échoué. Dans le cas illustré à la figure 7, il peut être considéré que la commande GC a échoué, et que le code de retour donné au client doit être : « commande non 20 autorisée » et « pas de réponse radio ». Cette réponse est communiquée à l'utilisateur Usr ou à l'application A qui la reçoit dans une étape ECUsr10. Il est à noter que le procédé de commande peut permettre le pilotage en parallèle de plusieurs produits utilisant le même protocole ou des protocoles de 25 communication locale différents. En particulier, il est possible dans ce cas d'appliquer les étapes suivantes : les commandes de bas-niveau RC applicables à un dispositif domotique D ne présentant pas de sous-ensembles fonctionnels sont exécutées séquentiellement comme décrit précédemment, c'est-à- 30 dire qu'une nouvelle commande est envoyée seulement après la réception du code de retour correspondant à l'exécution de la commande précédente les commandes relatives à des dispositifs domotiques D comprenant des sous-ensembles fonctionnels ou à un groupe de dispositifs 35 domotiques peuvent être réalisées parallèlement, c'est-à-dire que les différentes commandes sont envoyées l'une après l'autre, mais sans 3035560 39 attendre la réception du code de retour correspondant à l'exécution des commandes précédemment envoyées, pour autant que ces commandes ne concernent pas le même sous-ensemble fonctionnel ou même dispositif dans le cadre d'un groupe, ce qui revient à un 5 fonctionnement correspondant à des files d'attente de commande par dispositif ou par sous-ensemble fonctionnel du dispositif domotique D. Ces dispositions permettent de paralléliser le traitement des commandes sur des dispositifs distincts ou sur des sous-ensembles fonctionnels d'un même 10 dispositif domotique, de façon à diminuer le temps de traitement de commandes génériques destinées à plusieurs dispositifs domotique distincts ou à des sous-ensembles fonctionnels d'un même dispositif domotique. Ces dispositions sont particulièrement adaptées pour le suivi de commande longue. A titre d'exemple, considérons un ensemble de dispositifs 15 domotiques formé par un ensemble de 10 volets roulants communiquant selon un protocole bidirectionnel, par exemple du type 10 homecontrol communiquant une information d'atteinte de la position souhaitée en retour, chaque volet pouvant parcourir la course souhaitée en 30 secondes. Un traitement séquentiel occasionnera une réalisation de la commande en 5 minutes, alors qu'un traitement en parallèle 20 permettra une réalisation de la commande et un retour au bout de 30 secondes. REVENDICATIONS1. Procédé de supervision d'au moins une installation domotique (17) d'un bâtiment (1), l'installation domotique (17) comprenant une pluralité de dispositifs domotiques (D), chaque dispositif domotique (D) étant représenté par au moins une instance de modèle de dispositif générique (GD) et au moins une instance de modèle de dispositif de bas niveau (RD) ; le procédé étant exécuté par une unité de gestion (Sv) connectée à l'au moins une installation domotique (17) et comprenant les étapes suivantes : i. Réception (ESES1) d'un message de notification d'état (MS) en provenance d'une unité centrale de commande (U) d'une installation domotique (17) contenant une indication concernant au moins une variable d'état de bas-niveau (RS) d'un dispositif domotique (D) ; ii. Détermination (ESES2) de l'au moins une instance de modèle de dispositif de bas-niveau (RD) représentant le dispositif domotique (D) ; iii. Détermination (ECES4) d'une conversion d'état (CvS) convertissant l'au moins une variable d'état de bas niveau (RS) en au moins une variable d'état générique (GS) sur la base d'au moins une règle de conversion d'état (SCR) sélectionnée en fonction de l'au moins une variable d'état de bas-niveau (RS) ou de son type (RSID). iv. Détermination (ESES5) de l'au moins une instance de modèle de dispositif générique (GD) pour l'au moins une instance de modèle de dispositif de bas-niveau (RD) déterminée à l'étape ii ; v. Mise à jour (ECES6) de l'au moins une variable d'état générique (GS) de l'au moins une instance de modèle de dispositif générique (GD) déterminée à l'étape iv en fonction de la conversion d'état (CvS) déterminée à l'étape iii. 2. Procédé selon la revendication 1, comprenant en outre les étapes suivantes : - Emission (ESES7) d'un message de communication d'au moins une valeur de variable d'état générique GS mise à jour à destination d'un terminal utilisateur (T) ou d'une application (A) exécutée sur l'unité de gestion (Sv) ou sur une 35 autre unité de gestion connectée. 3035560 41 3. Procédé selon l'une des revendications précédentes, dans lequel l'étape de détermination de l'instance de modèle de dispositif de bas-niveau comprend une détermination d'une clef d'indexation (RDK) sur la base d'éléments d'identification (UID, RDID, RDPT) contenus dans le message de 5 notification d'état (MS) ou déterminables à réception du message de notification d'état (MS), dont la combinaison permettent une identification unique d'un dispositif domotique (D). 4. Procédé de commande d'au moins une installation domotique (17) 10 d'un bâtiment (1), l'installation domotique (17) comprenant une pluralité de dispositifs domotiques (D), chaque dispositif domotique (D) étant représenté par au moins une instance de modèle de dispositif générique (GD) et au moins une instance de modèle de dispositif de bas niveau (RD) ; le procédé étant exécuté par une unité de gestion (Sv) connectée à l'au moins une installation domotique (17) et comprenant les 15 étapes suivantes : i. Réception (ECES1) d'un message de commande (MC) en provenance d'un utilisateur (Usr) ou d'une application (A) sur l'unité de gestion (Sv) ou sur une autre unité de gestion connectée, le message de commande correspondant à une commande générique (GC) 20 relative à un dispositif domotique (D) ; ii. Détermination (ECES2) de l'au moins une instance de modèle de dispositif générique (GD) représentant le dispositif domotique (D) ; iii. Détermination (ECES3) de l'au moins une instance de modèle de dispositif de bas-niveau (RD) pour l'au moins une instance de modèle 25 de dispositif générique (GD) ; iv. Détermination (ECES4) d'une conversion de commande (CvC) convertissant l'au moins une commande générique (GC) en au moins une commande de bas-niveau (RC) sur la base d'au moins une règle de conversion de commande (CCR) sélectionnée en fonction de l'au 30 moins une commande générique (GC) ou de son nom (GCID) ; v. Envoi (ECES5, ECES6, ECES8) d'au moins un message de commande de bas-niveau (MRC) comprenant l'au moins une commande de bas niveau (RC) obtenue par la conversion de commande (CvC) déterminée à l'étape iv, à destination d'une unité centrale de commande (U) de l'installation domotique (17) de façon à déclencher l'exécution d'au moins une commande réelle correspondant à l'au 3035560 42 moins une commande de bas-niveau (RC) sur le dispositif domotique (D) correspondant à l'instance de bas niveau déterminée (GD) à l'étape iii. 5 5. Procédé selon la revendication 4, dans lequel la règle de conversion de commande (CCR) est sélectionnée en fonction de l'au moins une commande générique (GC) ou de son nom (GCID), et d'un type de dispositif de bas-niveau (RDT) correspondant l'au moins une instance de modèle de dispositif de bas-niveau (RD) déterminée à l'étape iii. 10 6. Procédé selon la revendication 5, dans lequel la conversion de commande (CyC) d'au moins une commande générique (GC) relative au dispositif domotique (D) en au moins une commande de bas niveau (RC) correspond à une pluralité de commandes de bas niveau (RC), et l'étape d'envoi correspond à l'envoi 15 d'une pluralité de commandes de bas niveau à destination de l'unité centrale de commande (U) de façon à déclencher l'exécution d'une pluralité de commandes réelles (C) sur le dispositif domotique (D). 7. Procédé selon la revendication 6, comprenant en outre les étapes 20 suivantes : stockage en mémoire de la correspondance entre ladite commande générique (GC) et la pluralité de commandes de bas niveau (RC) ; et détermination d'un résultat de la commande générique en fonction des résultats des commandes bas-niveau (RC) correspondantes. 25 8. Procédé de configuration d'au moins une installation domotique (17) d'un bâtiment (1), l'installation domotique (17) comprenant une pluralité de dispositifs domotiques (D), chaque dispositif domotique (D) étant représenté par au 30 moins une instance de modèle de dispositif générique (GD) et au moins une instance de modèle de dispositif de bas niveau (RD) ; le procédé étant exécuté par une unité de gestion (Sv) connectée à l'au moins une installation domotique (17) et comprenant les étapes suivantes : i. réception (ECfES1) d'une message de configuration (MCf) émis à 35 partir d'une unité centrale de commande (U) d'une installation domotique (17) ou d'un terminal utilisateur (T), le message (Mcf) 3035560 43 contenant une indication d'une mise en service , d'une configuration ou d'une reconfiguration d'un dispositif domotique (D). ii. détermination d'au moins une classe ou type de modèle de dispositif de bas-niveau (RDT) correspondant au dispositif domotique (D) ; 5 iii. création (ECfES2) d'au moins une instance de modèle de dispositif de bas-niveau (RD) en fonction de la classe ou type de dispositif de bas-niveau (RDT) définie à l'étape ii et correspondant au dispositif domotique (D). iv. détermination (ECfS3) d'une conversion de modèle (CvM) 10 convertissant un type ou classe de dispositif de bas niveau (RDT) en au moins une classe ou type de modèle de dispositif générique (GDT) sur la base d'une règle de conversion de modèle (MCR) sélectionnée en fonction de l'instance de modèle de dispositif bas-niveau (RD) déterminée à l'étape iii ou de son type (RDT). 15 v. création (ECfES4) d'au moins une instance de modèle de dispositif générique (GD) pour l'au moins une instance de modèle de dispositif de bas-niveau (RD) sur la base de l'au moins un type ou classe (GDT) correspondant à la conversion de modèle (CvM) déterminé à l'étape iv. 20 9. Procédé selon la revendication 8, comprenant en outre les étapes suivantes : - Emission d'un message de communication de la configuration d'au moins un dispositif domotique (D) à destination d'un terminal utilisateur (T) ou d'une 25 application (A) exécutée sur l'unité de gestion (Sv) ou sur une autre unité de gestion connectée. 10. Procédé selon l'une des revendications précédentes, dans lequel la détermination d'au moins une instance de modèle de dispositif générique (GD) pour 30 l'au moins une instance de modèle de dispositif de bas-niveau (RD) correspond à une détermination d'un groupe d'instances de modèles de dispositif générique (GD). 11. Procédé selon l'une des revendications précédentes, dans lequel chaque instance de modèle de dispositif générique (GD) comprend un identifiant 35 unique de dispositif générique (GDURL). 3035560 44 12. Procédé selon la revendication 11, dans lequel l'identifiant unique de dispositif générique (GDMID) comprend une adresse logique de dispositif (GDURL) qui établie une correspondance entre l'au moins une instance de modèle de dispositif générique et une instance de modèle de dispositif de bas-niveau (RDM). 13. Procédé selon la revendication 12, dans lequel l'adresse logique de dispositif (GDURL) comprend des informations sur: un type protocole de communication local(RDPT) du dispositif (D); un chemin de communication vers le dispositif (D); 14. Produit programme d'ordinateur comprenant des instructions de code agencées pour mettre en oeuvre les étapes d'un procédé selon l'une quelconque des revendications précédentes, lorsque ledit programme est exécuté par un processeur. 5 10 15