Domaine de l'invention

La présente invention concerne un procédé et un appareil fournissant certaines fonctionnalités dans le domaine de l'automatisation des bâtiments tels que la sélection, la mise en liste, la configuration, la programmation, l'installation et l'utilisation de composants d'automatisme dans les bâtiments.

Arrière-plan technologique de l'invention

L'automatisation des bâtiments qui regroupe la domotique, l'immotique, la gestion technique des bâtiments et la gestion technique centralisée appliquée aux domaines industriel, résidentiel et tertiaire, peut inclure un contrôle centralisé et/ou par télécommande de l'éclairage, CVCA (chauffage, ventilation et conditionnement d'air), des appareils électroménagers, des ouvrants, de la sécurité des biens et des personnes et d'autres systèmes, pour fournir plus de praticité, de confort, de rendement énergétique et de sécurité. Des exemples des différents composants qui peuvent être automatisés dans un bâtiment sont : la commande de l'éclairage, la commande du chauffage/de la ventilation et du conditionnement d'air, la commande des volets/des stores et des pare-soleil, la surveillance de l'alarme, la gestion de l'énergie et le mesurage de l'électricité/du gaz et de l'eau et la distribution audio et vidéo. Alors que le nombre de dispositifs contrôlables augmente dans les foyers, l'interconnexion et la communication deviennent une caractéristique utile et souhaitable. Les termes « automatisation des bâtiments », « immotique » et « domotique » sont utilisés dans la présente description de manière interchangeable (sauf indication contraire).

Le domaine de l'automatisation des bâtiments implique une combinaison d'appareils électriques, de réseaux d'interconnexion et de protocoles de communication de données. A la base, les dispositifs consistent en des Contrôleurs matériels, des capteurs, des actionneurs, etc. qui sont conçus pour communiquer avec un système. Des exemples de mise en réseau physique d'interconnexion sont les réseaux filaires (par exemple, par fibre optique, Firewire, USB, DSL, Ethernet, Powerline, etc.), sans fil (par exemple, par Wi-Fi, GPRS, UMTS, Bluetooth, DECT, Zibgee, infrarouge, etc.) ou une combinaison de dispositifs filaires et sans fil (par exemple, Instéon). Ces dispositifs interconnectés peuvent communiquer les uns avec les autres selon une variété de protocoles de communication, tels que SCS BUS avec OpenWebNet, C-Bus, CEBus, EnOcean, EHS, KNX, etc. Les systèmes d'automatisation des bâtiments qui peuvent être contrôlés par ces technologies de domotique incluent : le chauffage, la ventilation et l'air conditionné (CVCA), les systèmes de commande de l'éclairage, l'audio et la vidéo, la sécurité, la robotique, etc.

Différentes solutions sont actuellement disponibles, qui fournissent certaines capacités de domotique; cependant elles souffrent toutes de certains inconvénients. Certaines de ces solutions ne sont typiquement pas compatibles avec une grande variété de dispositifs, et sont au contraire liées à un ensemble propriétaire de composants/fournisseurs. D'autres ne fournissent pas typiquement une solution globale à la fois pour la phase d'installation/de reconfiguration (par exemple, la sélection, la configuration, la programmation, la mise en liste, etc. les caractéristiques et les composants désirés), et la phase d'utilisation (par exemple, la génération d'une interface utilisateur pour une utilisation intuitive des composants par un utilisateur final) d'un projet de domotique donné. De plus, elles ne permettent pas typiquement d'entrer/sélectionner des caractéristiques souhaitées et de générer automatiquement des rapports résumant certaines caractéristiques des composants résultants. Ces solutions correspondant à l'état de la technique ne programment pas typiquement automatiqueme nt l es com posa nts , o u n e fou rn issent pa s automatiquement d'instructions pour l'installation, par exemple, pour un projet donné. La Figure 1 illustre une approche de l'art antérieur décrite dans la publication de la demande de brevet américain N° 2010/0121968, par Clark et al., et attribuée à QWEBL Inc. (ci-après mentionné comme la « référence '968 »). La Figure 1 illustre une topologie domotique consistant en un appareil utilisateur comprenant une interface utilisateur et une application client, un dispositif de domotique comprenant un module traducteur, et une collection de dispositifs comprenant une caméra, des interrupteurs d'éclairage, des claviers, un thermostat et un appareil A/V. L'aspect clé de la référence '968 est l'utilisation d'un module traducteur situé dans l'appareil de domotique, qui est intercalé entre l'application client en charge de l'exécution sur l'appareil utilisateur et la collection de dispositifs. Ce module traducteur lit/distribue les informations reçues de l'application client et les traduit en signaux spécifiques au dispositif pour les envoyer à chaque dispositif. Ce module traducteur écoute également les signaux au niveau de la commande envoyés par chaque dispositif et les traduit en messages qu'il envoie ensuite à l'application client. Une telle approche nécessite que le module traducteur envoie des messages de protocole domotique à l'application client, ce qui nécessite que chaque client ait un programme personnalisé qui soit capable d'interpréter ces messages de protocole d'automatisation des bâtiments. Un inconvénient important de cette approche est qu'elle limite le type de clients à uniquement ceux pour lesquels un programme personnalisé est disponible tel que les systèmes propriétaires ou les fournisseurs.

La Figure 2 illustre une approche de l'art antérieur décrite dans la publication de demande de brevet américain N° 2010/013007 par Clark et al., et attribuée à QWEBL, Inc. (ci-après référencé comme étant la « référence Ό07 »). La Figure 2 illustre une interface homme machine, souvent désignée interface graphique utilisateur ou par l'acronyme GUI de l'expression anglaise graphical user interface. Cette interface homme machine (GUI) est destinée à être utilisée dans la configuration d'un système de domotique comprenant une caractéristique de découverte. Cette caractéristique de découverte implique en Etape 1 la génération automatique d'une liste des nombres et des types de dispositifs découverts dans une installation de domotique existante. Le mode de réalisation préféré de la référence Ό07 inclut un système propriétaire, tel que celui qui est vendu par Creston Electronics, Inc., ou AMX LLC. Un inconvénient important de cette caractéristique est que ce serait très difficile de fournir cette caractéristique dans un contexte ouvert, où une grande variété de dispositifs différents sont présents, et où l'installation n'est pas limitée à un système propriétaire ou à un fournisseur. Une telle fonctionnalité de découverte dans un contexte non propriétaire nécessiterait un processus complexe et long d'investigation concernant chaque type possible de dispositif, utilisant chaque type possible de protocole, et nécessiterait une mise à jour permanente au fur et à mesure que de nouveaux produits et/ou protocoles sont mis au point.

En conséquence, les procédés et les dispositifs actuellement connus pour la gestion de bâtiments souffrent de différentes carences comme : être limités à une ligne de produits propriétaires donnée ; nécessiter un processus long, coûteux et fastidieux de configuration ; limiter les types de dispositifs utilisateurs qui peuvent être utilisés pour commander le système de domotique ; et limiter les types de composants qui peuvent constituer le système de domotique. De plus, les approches de l'art antérieur ne fournissent pas de sélection et de reconfiguration faciles et intuitives d'un système contenant des composants non propriétaires, et ne permettent pas des rapports automatiques pour les instructions relatives à l'installation ou les coûts des composants, etc., afin de réduire au minimum les efforts et le coût nécessaires pour installer un tel système.

Résumé de l'invention

La présente invention cherche à surmonter tous les inconvénients mentionnés ci-dessus. Elle vise en particulier à fournir des systèmes et des procédés destinés à déterminer (par exemple, sélectionner et lister des composants spécifiques en se fondant sur des caractéristiques préférées, etc.), configurer, programmer, installer et utiliser des composants de domotique dans un bâtiment, utilisant une interface simple, ergonomique et conviviale. Certains aspects de ces caractéristiques sont de préférence ciblés vers un installateur utilisateur (par exemple, la détermination, la configuration, l'installation, la reconfiguration, la programmation, etc.), et d'autres aspects sont de préférence ciblés vers un utilisateur final (par exemple, la détermination, l'utilisation, la reconfiguration, etc.). De préférence, dans certains modes de réalisation décrits dans la présente description, certaines des tâches décrites sont effectuées par un installateur utilisateur, et peuvent également ou alternativement être exécutées par un utilisateur final. En particulier, alors que des aspects du processus relatif à l'installation deviennent plus conviviaux du fait de certaines des améliorations décrites dans les présents documents, on s'attend à ce que certaines tâches relatives à l'installation soient exécutées par un utilisateur final, telles que la reconfiguration ou la mise à jour du système.

En conséquence, des objets que certains modes de réalisation préférés de la présente invention fournissent sont : une interface homme machine (GUI) (par exemple, un écran tactile, un clavier avec un écran ou toute autre interface utilisateur) ; des informations décrivant des composants dédiés à la domotique ; des fonctions/commandes destinées à faire fonctionner des composants d'une manière simple et intuitive ; la capacité de préciser les préférences (par exemple, des marques, la qualité par rapport au prix, et la consommation d'énergie, etc.) ; la capacité de générer différents types de rapports détaillés qui peuvent être utilisés pour donner la liste des détails du projet (liste inventaire pour un projet donné, instructions relatives à l'installation, diagrammes de câblage, estimations des coûts détaillées, disponibilité, état des stocks, etc.) ; la programmation automatique des éléments comprenant le projet de domotique ; la génération automatique d'une interface homme machine (GUI) destinée à être utilisée par un utilisateur final grâce à une variété de plates-formes (par exemple, Smartphone, tablette, ordinateur, etc.).

Certains aspects de la présente invention seront mieux compris en se fondant sur la description détaillée donnée ci-après.

Il convient tout d'abord de rappeler que l'invention concerne un procédé de fourniture d'un bâtiment automatisé caractérisé en ce qu'il comprend :

la fourniture d'un Serveur connecté de manière contrôlable à une pluralité de composants domotiques, dans lequel il existe des moyens de stockage de données et une Base de données, une pluralité d'interfaces de communication et un Serveur Web ; dans lequel une première interface de communication fournit une connexion de données avec la pluralité de composants domotiques; et dans lequel la Base de données comporte des informations relatives à la configuration pour la pluralité de composants domotiques;

la fourniture d'une interface homme machine (GUI) installateur-utilisateur comprenant une pluralité de pièces du bâtiment sélectionnâmes par l'utilisateur et des dispositifs domotiques sélectionnâmes par l'utilisateur, dans lequel l'installateur- utilisateur peut sélectionner une pluralité de dispositifs domotiques pour chaque pièce ; la fourniture d'un rapport détaillé avec des informations relatives à la configuration associées à chacun des dispositifs domotiques sélectionné, dans lequel les informations relatives à la configuration comprennent des informations relatives à l'installation ou des informations relatives au prix collectées en partie dans la Base de données ; et

la fourniture d'un rapport de programmation avec des informations relatives à la programmation associées à chacun des dispositifs domotiques, dans lequel les informations relatives à la programmation comprennent des informations d'adresse détaillées ou des données de séquence de programmation collectées en partie dans la Base de données ;

dans lequel l'interface homme machine (GUI) installateur-utilisateur est fournie sur un dispositif pouvant fonctionner sur le Web ou localement via le Serveur Web.

Suivant des variantes cumulatives ou alternatives, le procédé est tel que :

- il comprend en outre :

la fourniture d'une interface homme machine (GUI) utilisateur final comprenant une pluralité de parties d'écran ; dans laquelle une première partie d'écran fournit une sélection de pièces dans le bâtiment automatisé, et dans laquelle une deuxième partie d'écran fournit une sélection de composants domotiques pertinents ou disponibles dans une pièce sélectionnée sur la première partie d'écran ;

une interface homme machine (GUI) utilisateur final, fournie par le serveur Web sur un dispositif compatible avec les technologies Web - au moins une première partie de la Base de données peut être située à l'extérieur du Serveur et être accessible par le Serveur localement ou via une connexion Internet.

- le dispositif compatible avec les technologies Web est un dispositif à écran tactile comprenant au moins un processeur et connecté au Serveur via un réseau local.

- le dispositif compatible avec les technologies Web est un appareil de calcul portable à écran tactile connecté au Serveur via un réseau cellulaire.

- la première partie d'écran sélectionne automatiquement une pièce donnée en se fondant en partie sur l'emplacement détecté du dispositif compatible avec les technologies Web.

- la première partie d'écran sélectionne automatiquement une pièce donnée en se fondant en partie sur l'emplacement détecté d'un utilisateur utilisant le dispositif compatible avec les technologies Web.

- l'interface homme machine (GUI) utilisateur final comprend une première partie de bordure sélectionnable par l'utilisateur qui révèle de manière contrôlable la première partie d'écran. - l'interface homme machine (GUI) utilisateur final comprend en outre une seconde partie de bordure sélectionnable par l'utilisateur qui révèle de manière contrôlable la seconde partie d'écran.

- le dispositif compatible avec les technologies Web comprend un dispositif portatif à écran tactile et l'interface homme machine (GUI) utilisateur final est optimisée pour un affichage sur un écran de plus petites dimensions.

- la première interface de communications est une interface de mise en réseau du standard KNX.

- comme cela sera décrit en détail par la suite, l'étape de fourniture d'une interface homme machine (GUI) installateur-utilisateur ; l'étape de fourniture d'un rapport détaillé et l'étape de fourniture d'un rapport de programmation sont effectuées de manière automatique. Typiquement au moins un microprocesseur effectue ces étapes lorsqu'il est exécuté.

L'invention concerne également un appareil de bâtiment automatisé caractérisé en ce qu'il comprend :

un Serveur connecté de manière contrôlable sur une pluralité de composants domotiques, dans lequel le Serveur comprend des moyens de stockage de données mémorisant une Base de données, une pluralité d'interfaces de communication, et un Serveur Web ; dans lequel une première interface de communications fournit une connexion de données avec la pluralité des composants domotiques ; et dans lequel la Base de d on nées est constitu ée d ' informations relatives à l a configuration pour la pluralité des composants domotiques;

une interface homme machine (GUI) installateur-utilisateur comprenant une pluralité de pièces du bâtiment sélectionnables par un utilisateur et de dispositifs domotiques sélectionnables par l'utilisateur dans lequel un installateur-utilisateur peut sélectionner une pluralité de dispositifs domotiques pour chaque pièce ; et

une fonction de rapport détaillé configurée pour préparer un rapport avec des informations relatives à la configuration associées à chaque dispositif domotiques sélectionné, dans lequel les informations relatives à la configuration comprennent des informations relatives à l'installation ou des informations relatives aux coûts collectées en partie dans la Base de données : et une fonction de rapport de programmation configurée pour préparer un rapport avec les informations relatives à la programmation associées à chaque dispositif domotiques, dans lequel les informations relatives à la programmation comprennent des informations relatives aux adresses ou des données de séquences de programmation collectées en partie dans la Base de données ;

une interface homme machine (GUI) utilisateur final fournie à un dispositif compatible avec les technologies Web via le Serveur Web.

De manière facultative, l'appareil comprend en outre au moins l'une quelconque des caractéristiques optionnelles suivantes :

- l'appareil comprend une interface homme machine (GUI) utilisateur final comprenant une pluralité de parties d'écran ; dans laquelle une première partie d'écran fournit une sélection de pièces dans le bâtiment automatisé et dans laquelle une seconde partie d'écran fournit une sélection de composants domotiques pertinents ou disponibles dans une pièce sélectionnée dans la première partie d'écran ; l'interface homme machine (GUI) utilisateur final étant fournie à un dispositif compatible avec les technologies Web via le Serveur Web.

- au moins une première partie de la Base de données peut être située à l'extérieur du Serveur et accessible par le Serveur via une connexion Internet.

- le dispositif compatible avec les technologies Web est un dispositif à écran tactile équipé d'un processeur et connecté au Serveur via un réseau local.

- le dispositif compatible avec les technologies Web est un appareil de calcul portable à écran tactile équipé d'un processeur et connecté au Serveur via un réseau cellulaire.

- la première partie d'écran sélectionne automatiquement une pièce donnée en se fondant en partie sur l'emplacement détecté du dispositif compatible avec les technologies Web.

- la première partie d'écran sélectionne automatiquement une pièce donnée en se fondant en partie sur l'emplacement détecté d'un utilisateur utilisant le dispositif compatible avec les technologies Web. - l'interface homme machine (GUI) utilisateur final comprend une première partie de bordure sélectionnable par l'utilisateur qui révèle de manière contrôlable la première partie d'écran.

- l'interface homme machine (GUI) utilisateur final comprend en outre une seconde partie de bordure sélectionnable par l'utilisateur qui révèle de manière contrôlable la seconde partie d'écran.

- le dispositif compatible avec les technologies Web comprend un dispositif portatif à écran tactile. De plus l'interface homme machine (GUI) utilisateur-final est optimisée pour un affichage sur un écran de plus petites dimensions.

- la base de données comporte une partie statique relative aux composants et une partie dynamique relative à la configuration du bâtiment.

L'invention concerne également un produit programme d'ordinateur contenant des instructions exécutables par au moins un microprocesseur qui lorsqu'elles sont exécutées par au moins un microprocesseur effectuent les étapes du procédé tel que décrit ci-dessus.

Brève description des dessins

Les objectifs ainsi que les autres avantages de la présente invention mentionnés ci-dessus seront plus évidents en décrivant en détail les modes de réalisation préférés de la présente invention en faisant référence aux dessins joints sur lesquels :

la Figure 1 illustre une architecture de l'art antérieur donné à titre d'exemple destinée à fournir certaines fonctionnalités de domotique utilisant un module traducteur ;

la Figure 2 illustre une interface homme machine utilisateur (GUI) de l'art antérieur donnée à titre d'exemple destinée à fournir certaines fonctionnalités de domotique utilisant un processus de découverte automatique ;

la Figure 3 illustre une architecture donnée à titre d'exemple destinée à fournir certaines fonctionnalités du mode de réalisation préféré ; la Figure 4 illustre une partie d'une Base de données donnée à titre d'exemple destinée à fournir certaines fonctionnalités du mode de réalisation préféré ;

la Figure 5 illustre une autre partie d'une Base de données donnée à titre d'exemple destinée à fournir certaines fonctionnalités du mode de réalisation préféré ; la Figure 6 illustre une autre partie d'une Base de données donnée à titre d'exemple destinée à fournir certaines fonctionnalités du mode de réalisation préféré ; la Figure 7 illustre une partie d'une interface homme machine utilisateur (GUI) donnée à titre d'exemple destinée à fournir certaines fonctionnalités du mode de réalisation préféré ;

la Figure 8 illustre une autre partie d'une interface homme machine utilisateur

(GUI) donnée à titre d'exemple destinée à fournir certaines fonctionnalités du mode de réalisation préféré ;

la Figure 9 illustre une autre partie d'une interface homme machine utilisateur (GUI) donnée à titre d'exemple destinée à fournir certaines fonctionnalités du mode de réalisation préféré ;

la Figure 10 illustre une autre partie d'une interface homme machine utilisateur (GUI) donnée à titre d'exemple destinée à fournir certaines fonctionnalités du mode de réalisation préféré ;

la Figure 1 1 illustre une autre partie d'une interface homme machine utilisateur (GUI) donnée à titre d'exemple destinée à fournir certaines fonctionnalités du mode de réalisation préféré ;

la Figure 12 illustre une autre partie d'une interface homme machine utilisateur (GUI) donnée à titre d'exemple destinée à fournir certaines fonctionnalités du mode de réalisation préféré ;

la Figure 13 illustre une autre partie d'une interface homme machine utilisateur

(GUI) donnée à titre d'exemple destinée à fournir certaines fonctionnalités du mode de réalisation préféré ;

la Figure 14 illustre une autre partie d'une interface homme machine utilisateur (GUI) donnée à titre d'exemple destinée à fournir certaines fonctionnalités du mode de réalisation préféré ; la Figure 15 illustre une partie d'un rapport donné à titre d'exemple provenant d'une Base de données destinée à fournir certaines fonctionnalités du mode de réalisation préféré ;

la Figure 16 illustre une autre partie d'un rapport donnée à titre d'exemple provenant d'une Base de données destinée à fournir certaines fonctionnalités du mode de réalisation préféré ;

la Figure 17 illustre une partie d'un rapport donnée à titre d'exemple provenant d'une Base de données destinée à fournir certaines fonctionnalités du mode de réalisation préféré ;

la Figure 18 illustre une partie d'un rapport donnée à titre d'exemple provenant d'une Base de données destinée à fournir certaines fonctionnalités du mode de réalisation préféré ;

la Figure 19 illustre une autre partie d'une interface homme machine utilisateur (GUI) donnée à titre d'exemple destinée à fournir certaines fonctionnalités du mode de réalisation préféré ;

la Figure 20 illustre une autre partie d'une interface homme machine utilisateur (GUI) donnée à titre d'exemple destinée à fournir certaines fonctionnalités du mode de réalisation préféré ;

la Figure 21 illustre une autre partie d'une interface homme machine utilisateur (GUI) donnée à titre d'exemple destinée à fournir certaines fonctionnalités du mode de réalisation préféré ;

la Figure 22 illustre une autre partie d'une interface homme machine utilisateur (GUI) donnée à titre d'exemple destinée à fournir certaines fonctionnalités du mode de réalisation préféré ;

la Figure 23 illustre une autre partie d'une interface homme machine utilisateur

(GUI) donnée à titre d'exemple destinée à fournir certaines fonctionnalités du mode de réalisation préféré ;

la Figure 24 illustre une autre partie d'une interface homme machine utilisateur (GUI) donnée à titre d'exemple destinée à fournir certaines fonctionnalités du mode de réalisation préféré ;

la Figure 25 illustre une autre partie d'une interface homme machine utilisateur (GUI) donnée à titre d'exemple destinée à fournir certaines fonctionnalités du mode de réalisation préféré ; la Figure 26 illustre une autre partie d'une interface homme machine utilisateur (GUI) donnée à titre d'exemple destinée à fournir certaines fonctionnalités du mode de réalisation préféré.

les Figures 27 et 28 illustrent des exemples de listes proposées par les algorithmes pour simplifier l'entrée des paramètres de configuration.

la Figure 29 illustre un exemple du résultat de la configuration requise.

la Figure 30 illustre un exemple de table intermédiaire (liste partielle des colonnes) stockant les informations par exemple nécessaires aux algorithmes de choix d'éléments, ainsi qu'à la génération automatique de divers rapports et d'une maquette de télécommande.

la Figure 31 illustre un exemple de Résumé de la Configuration généré automatiquement à partir du cahier de charges, des bases de données et des algorithmes de sélection d'éléments physiques.

la Figure 32 illustre un exemple de Directives d'Installation générées automatiquement à partir du cahier de charges, des bases de données et des algorithmes de sélection d'éléments physiques.

la Figure 33 illustre un autre exemple de Directives de Programmation générées automatiquement à partir du cahier de charges, des bases de données et des algorithmes de sélection d'éléments physiques.

la Figure 34 donne un exemple d'Etude de Prix générée automatiquement à partir du cahier de charges, des bases de données et des algorithmes de sélection d'éléments physiques.

la Figure 35 illustre un exemple de d'interface homme machine, c'est à dire de télécommande, générée automatiquement à partir du cahier de charges, des bases de données et des algorithmes de sélection d'éléments physiques.

Description détaillée des modes de réalisation préférés donnés à titre d'exemples

La présente invention sera décrite plus en détail en faisant référence à certains modes de réalisation préférés et à certains autres modes de réalisation qui peuvent servir à faciliter la compréhension des modes de réalisation préférés de la présente invention. Tel que décrit plus loin dans le présent document, différents raffinements et remplacements des différents éléments des différents modes de réalisation sont possibles en se fondant sur les principes et les enseignements des présents documents.

La Figure 3 illustre une architecture donnée à titre d'exemple destinée à fournir certaines caractéristiques du mode de réalisation préféré.

Le Serveur 12 est situé sur un site donné de domotique et comprend une interface de réseau étendu (WAN) 20, une interface de réseau local (LAN) 22 et un exemple d'interface d'interconnexion de domotique de KNX 24. En outre, le Serveur 12 comprend de préférence un routeur/passerelle 19 tel qu'un bloc fonctionnel routeur/passerelle qui permet de préférence aux dispositifs récemment connectés (par exemple, tel que les tablette/PC/téléphone 2) d'avoir automatiquement accès au système, et de préférence permet également aux dispositifs d'un sous-réseau (par exemple, connecté via le LAN 22) d'avoir accès aux autres sous-réseaux du système (par exemple, des dispositifs connectés via le WAN 20 et/ou le KNX 24). Le routeur/passerelle 19 est représenté par une ligne en pointillés parce que, dans certains modes de réalisation, il est peut-être préférable d'utiliser à la place un routeur/passerelle extérieur(e) tel que par exemple dans des situations où un routeur et/ou une passerelle extérieur(e) fait déjà partie de l'environnement du réseau. Cependant, dans certains modes de réalisation préférés, il est préférable d'inclure une telle capacité de passerelle et/ou routeur dans le Serveur 12, car cela peut simplifier l'utilisation du système en fournissant une possibilité rapide et facile de relier un dispositif et d'utiliser le système. En outre, dans certains modes de réalisation, il est préférable d'intégrer certaines caractéristiques de sécurité à la passerelle/au routeur telles que le verrouillage ou la restriction de certains ports ou sous-réseaux et la limitation de leur utilisation, et/ou la limitation de l'accès à certains dispositifs matériels qui ont été authentifiés par le système. Dans cette illustration, pour faciliter la référence, la norme KNX est utilisée comme un exemple du protocole de domotique interconnectant le Serveur 12 et les différents composants de domotique tels que les Contrôleurs 32 et 38 et les Actionneurs 34 et 40. Le KNX est un protocole de communications par réseau standardisé et « ouvert » (non propriétaire) pour les environnements des bâtiments intelligents, fondés sur l'effort d'interconnexion de systèmes ouverts dans l'Organisation Internationale de Normalisation (ISO). KNX est simplement un exemple d'un protocole de communications qui peut être utilisé, car certaines caractéristiques de la présente invention peuvent également être utilisées avec d'autres protocoles de communications, tels que ceux utilisés dans des systèmes de domotique propriétaire. En conséquence, chaque référence dans les présents documents à « KNX » ou « réseau KNX » peut également être appliquée à d'autres protocoles de communication de domotique (par exemple, les protocoles tels que ASHRAE, BACnet, S-Bus, CIBSE, Dynet, EnOcean, LonTalk, Midac, OpenTherm, ZigBee, OpenWebNet, LONWorks, DALI, DMX, ModBus, etc.).

Le Serveur 12 comprend un logiciel d'application (SW App.) 16, et inclut également en option un logiciel de configuration (SW Conf.) 14 et une Base de données 18. Ces deux derniers items sont représentés par une ligne en pointillés, puisque dans certains modes de réalisation, ils peuvent chacun également (ou bien alternativement) être de préférence localisés dans un Serveur en option situé sur Internet 4. Un tel Serveur en option est illustré en tant que Serveur 6 qui comprend en option un logiciel de Configuration (SW Config.) 8 et une Base de données 10. Dans certains modes de réalisation préférés, SW App. 16 comprend un Serveur Web qui peut fournir des pages Web (par exemple, des pages Web dynamiques, tel qu'en utilisant une langue d'écriture PHP (préprocesseur hypertexte) et une Base de données sous une forme compatible avec un langage d'interrogation de bases de données tel que le langage SQL (Structured Query Language) pour n'importe quel dispositif compatible avec les technologies Web (par exemple, en utilisant Javascript). Ces pages Web sont de préférence utilisées pour présenter une interface homme machine utilisateur (GUI) qui fournit différentes fonctionnalités décrites plus loin dans ce document. Typiquement, le Logiciel d'Application pour une installation de domotique donnée n'est pas situé sur un Serveur Internet, puisque le Logiciel d'Application est utilisé par le système pour commander individuellement les dispositifs de domotique, et en conséquence toute interruption du service Internet rendrait le Serveur 6 inaccessible à l'utilisateur final. Il convient de noter que, dans certains modes de réalisation préférés, il est avantageux d'utiliser une pluralité de Serveurs (par exemple, à la fois le Serveur 12 et le Serveur 6, des Serveurs distants multiples, des Serveurs locaux multiples, etc.), de manière à fournir des fonctionnalités redondantes et/ou faciliter la commande centralisée d'une pluralité de composants domotiques qui peuvent être géographiquement dispersés. De préférence, comme cela sera décrit plus en détail plus loin dans le présent document, dans certains modes de réalisation SW App. est utilisé par un utilisateur final pour la commande quotidienne des éléments composant le réseau de domotique.

Egalement décrits par une ligne en pointillés, on trouve les tablette/PC/téléphone 2 qui peuvent être utilisés pour fournir une interface homme machine utilisateur (GUI) selon certaines caractéristiques préférées décrites dans les présents documents, mais qui seraient également affectées par n'importe quelle interruption du service Internet entre Internet 4 et le Serveur 12. En conséquence, on attend que le dispositif principal pour la fourniture de l'interface homme machine utilisateur (GUI) décrite dans ce document soit la tablette/le PC/le téléphone 28 qui est connecté(e) au Serveur 12 (et au Serveur 6) via un réseau local (par exemple, filaire ou sans fil). Est également connecté via le réseau local le Serveur Multimédia 26, qui peut être n'importe quel type de dispositif multimédia pouvant fonctionner sur un LAN en fournissant des fonctionnalités audio et vidéo dans le foyer, telles que la Playstation 3 de Sony, un PC fonctionnant sur Windows ou n'importe quel dispositif fonctionnant de préférence sur Linux, Android ou un système Apple qui fournit des fonctionnalités audio ou vidéo via un réseau local.

Le réseau KNX 30 est l'interconnexion entre le Serveur 12 et les différents composants de domotique dans une installation donnée, tels que les Contrôleurs 32 et 38, l'Actionneur 34 (connecté à la LAMPE 36) et l'Actionneur 40 (connecté à la CVCA 42). Ces exemples ont pour but d'illustrer les différentes caractéristiques décrites dans les présents documents, et comprennent typiquement une faible partie de l'installation globale. D'autres composants de domotique qui peuvent être de même inclus comprennent les dispositifs utilisés pour l'audio et/ou la vidéo, la sécurité, la robotique, les volets des fenêtres, les écrans de projection, etc. Différents Contrôleurs et Actionneurs sont disponibles ; par exemple, des Actionneurs à interrupteur KNX sont disponibles auprès de ABB Stotz-Kontakt GmbH qui se trouve à Heidelberg (Allemagne), des routeurs compatibles KNX sont disponibles auprès de Siemens AG Automation and Drives Group basé à Regenberg (Allemagne) et des détecteurs à bouton poussoir KNX sont disponibles auprès de Albrecht Jung GmbH & Co KG basé à Schalksmuhle (Allemagne).

La Figure 4 décrit une partie d'une Base de données qui peut être utilisée dans la génération automatique d'une interface utilisateur. De préférence, cette partie de la Base de données est située en tant que partie de la Base de données 18 pour garantir un accès ininterrompu bien que, en option, elle puisse être située sur la Base de données 10. Dans certains modes de réalisation préférés, la partie de Base de données peut être fournie sous une forme compatible avec un langage d'interrogation de bases de données tel que le langage SQL (Structured Query Language) et peut comprendre de multiples tableaux. Le tableau décrit sur la Figure 4 décrit le tableau qui peut être utilisé pour effectuer une interface homme machine (GUI) avec la fonctionnalité de multiples langues. Chaque item de texte de l'interface homme machine (GUI) peut être présent en utilisant une langue présélectionnée (par exemple, voir les colonnes décrites sur la Figure 4 intitulées « LangueOI », « Langue02 » et « Langue03 »). En conséquence, dans certains modes de réalisation préférés, tout écran particulier de l'interface homme machine (GUI) peut être généré « activement » (par exemple, en utilisant le PHP), de telle sorte que l'interface homme machine (GUI) puisse être accessible dans n'importe quelle langue). Dans les exemples d'interface homme machine (GUI) cités plus loin dans la présente description, les items de texte individuels sont présentés sur la Figure 4; en utilisant ce type de Base de données, l'interface homme machine (GUI) peut être facilement présentée « dynamiquement » dans n'importe quelle langue compatible. De même, l'utilisation de cette Base de données décrite sur la Figure 4, en même temps que l'utilisation des caractéristiques bien connues d'un Serveur Web (telles que PHP) permettent de mettre à jour facilement les écrans de l'interface homme machine (GUI) de manière à refléter des nouvelles caractéristiques ou des nouvelles langues.

La Figure 5 décrit une autre partie d'une Base de données qui peut être utilisée principalement dans la phase d'installation d'un projet donné. Dans certains modes de réalisation préférés, la partie de la Base de données peut être fournie sous une forme compatible avec un langage d'interrogation de bases de données tel que le langage SQL (Structured Query Language) et peut inclure des tableaux multiples. Le tableau décrit sur la Figure 5 contient différents composants individuels qui sont utilisés comme exemples plus loin dans le présent document. Chaque composant est associé à différents domaines, tels que « nom du fabricant », « nom du produit », « numéro de la pièce », « prix », « info produit associé », « priorité », « finition » et « paramètres supplémentaires ». La dernière colonne a pour but d'illustrer une pluralité de champs supplémentaires qui sont utilisés dans le système afin de contrôler de préférence un dispositif particulier, et dans certains cas peut varier en fonction du protocole de communication (par exemple, KNX) qui est compatible avec le dispositif. D'autres parmi ces champs peuvent être utilisés pour classer les dispositifs (par exemple, pour les grouper selon différents « types »), ce qui permet de préférence différentes optimisations grâce à des algorithmes traditionnels qui sont l'état de l'art dans la programmation de l'ordinateur. Par exemple, si plusieurs commandes du même type dans la même zone sont requises, les algorithmes sélectionnent de préférence des dispositifs séparés dans ce tableau de la Figure 5 qui combinent des commandes multiples de ce type dans leur fonctionnalité. Ceci réduit de préférence les coûts et simplifie l'installation de la domotique, car cela peut influencer (par exemple, réduire) les choix particuliers d'éléments. De préférence cette partie de la Base de données est localisée comme faisant partie de la Base de données 10, puisqu'elle inclut de préférence une liste « maître » de composants qui peut être utilisée dans n'importe quelle installation de domotique, et on attend qu'elle soit régulièrement mise à jour pour refléter les changements des différents paramètres associés à chaque composant (par exemple, la disponibilité, le prix, les caractéristiques supplémentaires, etc.)- En plus des mises à jour sur une ligne donnée, ce tableau sera de préférence mis à jour pour inclure des lignes supplémentaires pour les nouveaux dispositifs et pour retirer les produits obsolètes. Bien qu'il soit préférable pour cette partie de la Base de données d'être située sur le Serveur 6 (c'est-à-dire, étant donné sa possibilité d'application plus grande sur des installations multiples), dans certains cas elle peut être située sur le Serveur 12.

La Figure 6 décrit une autre partie d'une Base de données qui peut être utilisée dans la phase d'installation (par exemple, par un installateur pour décrire comment chaque élément doit être interconnecté/installé afin d'obtenir les caractéristiques souhaitées) ou dans la phase d'utilisation d'un projet donné (par exemple, par un utilisateur final dans un foyer donné afin de contrôler les composants de la domotique). De préférence, cette partie de la Base de données est localisée comme faisant partie de la Base de données 18 afin de garantir un accès ininterrompu, bien que, en option, elle puisse être située sur la Base de données 10. Dans certains modes de réalisation préférés, la partie de Base de données peut être fournie sous une forme compatible avec un langage d'interrogation de bases de données tel que le langage SQL (Structured Query Language) et peut comprendre de multiples tableaux. Le tableau décrit sur la Figure 6 décrit le tableau qui peut être utilisé pour effectuer une interface homme machine (GUI) destinée à commander une installation de domotique individuelle (par exemple, l'utilisation quotidienne des composants de la domotique dans une installation donnée). Les items donnés à titre d'exemples qui constituent la Base de données décrite sur la Figure 6 sont pris sur les écrans de l'interface homme machine (GUI) décrite plus loin dans la présente description, et ils seront traités un peu plus en détail ci-après. La dernière colonne a pour but d'illustrer une pluralité de champs supplémentaires qui sont utilisés par le système pour contrôler, de préférence, un dispositif particulier et dans certain cas peut varier en fonction du protocole de communication (par exemple, KNX) qui est compatible avec le dispositif. D'autres parmi ces champs sont utilisés pour classer les dispositifs (par exemple, pour les grouper selon différents « types » ), ce qui permet, de préférence, différentes optimisations par des algorithmes traditionnels qui constituent l'état de l'art dans la programmation des ordinateurs. La Figure 7 décrit un écran d'installation de projet d'une interface homme machine utilisateur (GUI) 100, qui de préférence peut être utilisée pendant la phase d'installation. Il convient de noter que les exemples décrits dans les Figures 7 à 14 sont orientés vers une phase d'installation ou de réinstallation, bien que les mêmes enseignements dans la présente description puissent être appliqués afin de générer dynamiquement des caractéristiques similaires orientées vers un utilisateur final qui souhaite contrôler les composants de la domotique sur une base quotidienne. De préférence, certains éléments textuels dans l'interface homme machine (GUI) 100 sont générés en utilisant la partie de Base de données décrite sur la Figure 4. Par exemple login 102, nom du projet 106, nouvelle installation 1 12, installation existante 1 16, et nombre de pièces 1 18 sont générés en utilisant SW Conf. 14 situé sur le Serveur 12. Ces items de texte font de préférence partie d'une page Web générée de manière dynamique (par exemple, en utilisant PHP, SQL et Javascript) qui sont pris dans la Base de données décrite sur la Figure 4. Alors que le français est la langue utilisée dans l'exemple de la Figure 7, dans le cas où une langue différente est souhaitée, SW App. 16 commute pour faire référence à une autre colonne dans ce tableau lorsqu'il génère une page Web pour « fabriquer» l'interface homme machine (GUI). Dans l'exemple décrit sur la Figure 4, SW App. 16 commute sur la colonne intitulée « LangueOI » pour présenter une interface homme machine (GUI) en langue française, et sur la colonne intitulée « Langue03 » pour présenter une version en langue japonaise de l'interface homme machine (GUI). Dans certains modes de réalisation, il est avantageux pour l'interface homme machine (GUI) d'inclure un ou plusieurs objet(s) graphique(s) qui peu(ven)t être spécifique(s) à une langue donnée (par exemple, une image graphique contenant un mot ou le nom/le logo d'une société) ; dans ces modes de réalisation, la Base de données contient des références à des éléments graphiques, et de cette manière une interface homme machine (GUI) peut être générée dynamiquement avec des éléments de texte et graphique spécifiques à un paramètre donné (tel qu'une langue donnée).

Si l'on se réfère à nouveau à la Figure 7, l'interface homme machine (GUI) fournit de préférence un ou plusieurs des éléments suivants : une partie pour entrer un nom de connexion 104 (autorisant un accès protégé par un mot de passe), une partie 108 destinée à fournir un nom configurable pour un projet (décrit ici et ailleurs dans le même document comme « bâtimentOI »), des parties 1 10 et/ou 1 14 pour sélectionner s'il s'agit d'une nouvelle installation (par exemple, à l'étape de la fabrication des plans) ou d'une installation existante (par exemple, déjà installée mais accessible à une reconfiguration), une partie 120 pour indiquer le nombre de pièces, une partie 122 pour indiquer l'acceptation de modifications quelconques, et une partie 124 pour permettre à l'utilisateur de revenir à un écran d'accueil.

La Figure 8 décrit un autre écran d'installation en projet de l'interface homme machine (GUI) 100 qui indique le nom du projet 130, s'il s'agit d'une nouvelle installation 132, et le nombre des pièces 134. Il est préférable que différentes parties de texte de l'interface homme machine (GUI) (par exemple, 130, 132, 134 et 136) puissent être générées en utilisant la partie de la Base de données décrite dans la Figure 4, en utilisant SW Conf. 14 situé sur le Serveur 12. Une catégorie particulière des dispositifs automatiques peut être sélectionnée (dans l'exemple de la Figure 8, la catégorie « éclairage » est sélectionnée 138 près du mot « Application » 136, qui a pour but ici de faire référence à la catégorie. Chaque pièce 140 et 150 peut être sélectionnée, et les zones 148 et 158 peuvent être configurées (142 et 152). De nouvelles zones peuvent être ajoutées 144 et 154 et des noms uniques de tableaux électriques pour chaque zone peuvent être édités 146 et 156. Un autre projet existant ou nouveau peut être sélectionné 160, et d'autres caractéristiques peuvent être sélectionnées qui seront décrites plus en détail dans la suite du présent document 164. L'exemple de la Figure 8 décrit un nouveau projet avec deux pièces, chacune ayant une zone (zone01 ). De nombreuses pièces et/ou zones peuvent être ajoutées (de préférence en utilisant des items/menus interface homme machine (GUI) qui s'étendent ou qui rétrécissent automatiquement) ; cet exemple doit être très simple afin de présenter de manière plus efficace certaines caractéristiques des modes de réalisation préférés.

La Figure 9 décrit un autre écran d'installation de projet de l'interface homme machine (GUI) 100. Il est préférable que différentes parties de texte de l'interface homme machine (GUI) (par exemple, 130, 132, 134, 136, 178, 180, 182, 186, 190 et 194) puissent être générées en utilisant la partie de Base de données décrite sur la Figure 4, en utilisant SW Conf. 14 situé sur le Serveur 12. Au moment de sélectionner une catégorie 172 donnée, l'utilisateur peut se concentrer sur une zone donnée 176 qui fait partie d'une pièce donnée 174. Il convient de noter que, dans chacun des exemples de l'interface homme machine (GUI) traités dans ce document, il peut être préférable de mettre en valeur la partie de l'écran qui présente le focus actuel, tel qu'en changeant l'apparence de l'item centralisé (par exemple, en le mettant en surbrillance ou en gras, etc.), ou des items qui n'ont pas de focus (par exemple, en les assombrissant ou en les ombrant, etc.) L'utilisateur peut sélectionner un dispositif spécifique 184, une fonction associée 180 et des commandes associées 192 et 196. Il convient de noter que sur les écrans de l'exemple décrits sur les Figures, le terme « Appareil» fait de préférence référence à un type d'applications d'un point de vue de l'utilisateur final. SW Conf. 14 et/ou 8 sélectionnera de préférence une fonction et une commande appropriées dans la Base de données sur le Serveur 12 et/ou 6 en se fondant sur le dispositif choisi. Dans certains modes de réalisation, il est préférable que chaque choix dépende du contexte et ne soit pas uniquement basé sur l'appareil « choisi ». Comme exemple, une commande peut dépendre non seulement du type de la catégorie (liée à l'appareil) mais également à la fonction qui a été sélectionnée. De cette manière, il est préférable que seules les commandes « compatibles » (par exemple, qui correspondent à la catégorie/à l'appareil et la fonction sélectionnée) soient affichées. De préférence, la détermination de la compatibilité est fournie grâce à l'utilisation de la Base de données, puisque les informations concernant la compatibilité peuvent être incluses dans la Base de données (par exemple, dans l'exemple de la Figure 5, ces informations relatives à la compatibilité peuvent être conservées dans les « informations de produit associées » ou « paramètres supplémentaires ». Dans certains modes de réalisation, l'utilisateur a également le choix de sélectionner une commande préalablement choisie, par exemple de commander différentes fonctions avec le même contrôleur. De la même manière, dans certains modes de réalisation, l'utilisateur peut sélectionner un appareil déjà défini de manière à être capable de le contrôler depuis différentes pièces/zones. De préférence, le choix de sélectionner des commandes préalablement choisies est fourni grâce à l'utilisation de la Base de données, puisque les informations concernant les commandes préalablement choisies peuvent être conservées dans la Base de données (par exemple, dans l'exemple de la Figure 6, les commandes préalablement choisies peuvent être ajoutées en tant qu'entrées supplémentaires dans la Base de données pour une installation donnée).

Si l'on revient à l'exemple de la Figure 9, un utilisateur peut sélectionner un type incandescent de dispositif d'éclairage et peut sélectionner une fonction marche/arrêt également désignée M/A, souvent désignée par son vocable anglais on/off, qui peut inclure un accès à distance et des commandes marche/arrêt. Il convient de noter que « accès à distance » a pour but ici de décrire une commande qui est accessible depuis une certaine distance, telle que mettre en marche et éteindre un dispositif en utilisant une tablette/un PC/un téléphone 2 ou 28. La Figure 9 inclut également des parties d'écran préférables pour ajouter un appareil à une zone 202, ajouter une fonction à un appareil 200 et ajouter une commande à une fonction 198. De plus, la Figure 9 intègre une partie de curseur 170, qui peut être, de préférence, utilisée pour indiquer quelle partie d'un écran existant est visible. Il convient de noter que la partie de curseur 170 est décrite de la même manière sur les Figures 10 à 13, bien que la description visuelle varie en fonction de la partie de l'écran qui est visible.

La Figure 10 décrit un autre écran d'installation de projet de l'interface homme machine (GUI) 100. Il est préférable que différentes parties de texte de l'interface homme machine (GUI) (par exemple, 130, 132, 134, 246, 252 et 256) puissent être générées en utilisant la partie de la Base de données décrite sur la Figure 4, en utilisant SW Conf. 14 situé sur le Serveur 12. Au moment de sélectionner une catégorie différente 220, l'utilisateur peut se concentrer sur une autre zone 232 qui fait partie d'une autre pièce 230. L'utilisateur peut sélectionner un autre dispositif (appareil) spécifique 242, une fonction associée 248 et des commandes associées 254 et 258. Dans cet exemple de la Figure 10, un utilisateur peut sélectionner un type essentiel de dispositif CVCA et peut sélectionner une fonction marche/arrêt qui peut inclure un accès à distance et des commandes marche/arrêt (mise en marche/arrêt) à distance.

La Figure 1 1 décrit un autre écran d'installation de projet de l'interface homme machine (GUI) 100. Il est préférable que différentes parties de texte de l'interface homme machine (GUI) (par exemple, 130, 132, 134, 240, 246, 250, 252, 256, 270, 274 et 278) puissent être générées en utilisant la partie de Base de données décrite sur la Figure 4, en utilisant SW Conf. 14 situé sur le Serveur 12. Au moment de la sélection d'une catégorie différente 220 (par exemple, en sélectionnant 200 sur la Figure 10), l'utilisateur peut ajouter une nouvelle fonction de dispositif 242. L'utilisateur peut sélectionner une autre fonction spécifique 272 et des commandes associées 276 et 278. Sur cet exemple de la Figure 1 1 , un utilisateur peut ajouter à l'appareil 242 de type CVCA une fonction supplémentaire « ventilateur On/off» 272, et peut sélectionner un accès à distance associé 276 et des commandes On/Off 280.

La Figure 12 décrit un autre écran d'installation de projet de l'interface homme machine (GUI) 100. Il est préférable que différentes parties de texte de l'interface homme machine (GUI) (par exemple, 130, 132, 134, 246, 252, 256, 270, 274, 278, 290, 294, 298 et 302) puissent être générées en utilisant la partie de Base de données décrite sur la Figure 4, en utilisant SW Conf. 14 situé sur le Serveur 12. L'utilisateur peut ajouter une fonction supplémentaire au dispositif (appareil) 242. L'utilisateur peut sélectionner une autre fonction spécifique 292 et les commandes associées 296, 300 et 304. Dans cet exemple de la Figure 12, un utilisateur peut ajouter à l'appareil de type CVCA une fonction supplémentaire « température montée/baisse » 292, et peut sélectionner un accès à distance associé 296, des commandes « Augmenter» 300, et « Réduire» 304. La Figure 13 décrit un autre écran d'installation de projet de l'interface homme machine (GUI) 100. Il est préférable que différentes parties de texte de l'interface homme machine (GUI) (par exemple, 130, 132, 134, 290, 294, 298, 302, 310, 314 et 318) puissent être générées en utilisant la partie de Base de données décrite sur la Figure 4, en utilisant SW Conf. 14 situé sur le Serveur 12. L'utilisateur peut ajouter une fonction supplémentaire au dispositif (appareil) 242. L'utilisateur peut sélectionner une autre fonction spécifique 312 et des commandes associées 316 et 320. Dans cet exemple de la Figure 13, un utilisateur peut ajouter à un appareil de type CVCA une fonction supplémentaire « température prédéfinie » 312, et peut sélectionner un accès à distance associé 316 et des commandes « valeur préréglée» 320.

Si l'on fait référence à la Figure 8, il est préférable de fournir à l'utilisateur une partie d'écran 164, qui permet à l'utilisateur de spécifier différentes préférences qui peuvent être utilisées par la sélection algorithmique des composants individuels. Au moment de la sélection de ces boutons de préférences 164, l'utilisateur peut, de préférence, être orienté vers un écran supplémentaire afin d'entrer les préférences que l'utilisateur peut avoir. Décrit sur la Figure 14, on trouve un écran d'interface homme machine (GUI) 1 00 qui permet à un utilisateur d'indiquer les préférences parmi différents critères disponibles, qui peuvent être utilisés par SW Conf. 14 afin de déterminer algorithmiquement des produits spécifiques à partir de la Base de données illustrée sur la Figure 6, qui suivent au plus près les préférences spécifiées. Dans l'exemple de la Figure 14, l'utilisateur peut sélectionner des choix multiples 334, 338 et 342 de différentes sociétés 336, 340 et 348. De plus, dans certains modes de réalisation, il est préférable de fournir l'option de la sélection des choix 352, 356 et 360 de critères supplémentaires 354, 358 et 362, tels que « meilleure qualité », « meilleur prix », « économie d'énergie », etc. En outre, des critères supplémentaires peuvent être de préférence sélectionnés, tels que Finition par défaut 364 (par exemple, « blanc », « noir », « argent », etc.). Ces différentes sélections de critères seront, de préférence, référencées de manière croisée par rapport aux paramètres de la Base de données (par exemple, décrits sur la Figure 5), de telle sorte qu'elles puissent être prises en compte lors de la sélection de composants spécifiques destinés à être utilisés dans l'installation donnée.

Est décrite sur la Figure 14 une partie 162 intitulée « instructions ». De préférence ce type de caractéristique permettra à l'utilisateur d'initier SW Conf. 14 pour qu'il génère automatiquement des instructions d'installation qu'un installateur devra suivre. Est décrit sur les Figures 15 et 16 un rapport donné en exemple contenant des informations détaillées fournissant à un installateur des instructions d'installation. Les informations données à titre d'exemple contenues dans ce rapport sont prises dans les informations de Base de données données à titre d'exemple et décrites sur la Figure 5, ainsi que les sélections d'utilisateur données à titre d'exemple présentées sur les différents écrans d'interface homme machine utilisateur (GUI) des Figures 7 à 14.

La Figure 15 décrit la « page 1 » du rapport d'instructions d'installation qui concerne les sélections d'utilisateur décrites sur les Figures 7 à 14. Sur cette page donnée à titre d'exemple, des informations détaillées sont présentées qui décrivent les différents Actionneurs (A1-A5) qui ont été sélectionnés par SW Conf. 14 en comparant des sélections d'utilisateur dans les écrans interface homme machine (GUI) aux informations de la Base de données décrites sur la Figure 5. Pour chaque composant (par exemple, « ID composant : A1 »), une description de composant (par exemple, « société X-Actionneur Interrupteur ») et un numéro de composant (par exemple, « 9999ABCD01 ») sont de préférence inclus, en même temps qu'un tableau indiquant quelle sortie a besoin d'être raccordée électriquement. Il est important de noter que, bien qu'une seule sortie donnée à titre d'exemple soit montrée dans ces exemples, des installations réelles peuvent inclure beaucoup de sorties pour un composant donné, puisque certains composants sont prévus pour avoir des sorties multiples disponibles pour des actions multiples, etc. En commençant par A1 , l'installateur est orienté vers la sortie filaire 1 de ce composant jusqu'à un emplacement dans la zoneOI de la pièceOI , et il indique ensuite que le nom de l'appareil est « incandescent 01 », et que la fonction est « On/Off » (Marche/Arrêt). Cette instruction particulière correspond à des parties d'écran 184, 188 et 196 de la Figure 9. En cas de plusieurs fonctions utilisées sur le même composant (par exemple utilisant plusieurs sorties du même composant) plusieurs lignes supplémentaires apparaîtraient dans ce tableau (par exemple commençant par Sortie n°1 , puis Sortie n°2, etc). Si l'on continue avec A2, l'installateur est orienté vers une sortie filaire 1 de ce composant jusqu'à un emplacement dans la zoneOI de la pièce02, et il indique en outre que nom de l'appareil est « Air Conditionné 01 », et que la fonction est « On/Off». Cette instruction particulière correspond à des parties d'écran 242, 248 et 258 de la Figure 10. Si l'on continue avec A3, l'installateur est dirigé vers une sortie filaire 1 de ce composant jusqu'à un emplacement dans la zoneOI de la pièce02, et il indique en outre que le nom de l'appareil est « Air Conditionné 01 » et que la fonction est « température montée/baisse ». Cette instruction particulière correspond à des parties d'écran 242, 292, 300 et 304 de la Figure 12. Si l'on continue avec A4, l'installateur est dirigé vers la sortie filaire 1 de ce composant jusqu'à un emplacement dans la zoneOI de la pièce02, et il indique en outre que le nom de l'appareil est « Air Conditionné 01 » et que la fonction est « température prédéfinie». Cette instruction particulière correspond à une partie d'écran 312 de la Figure 13. Si l'on continue avec A5, l'installateur est dirigé vers la sortie filaire 1 de ce composant jusqu'à un emplacement dans la zoneOI de la pièce 02, et il indique en outre que le type de dispositif est « Air Conditionné» et que la fonction est « ventilateur On/Off». Cette instruction particulière correspond à des parties d'écran 242, 272 et 280 de la Figure 12. La partie de rapport illustrée sur la Figure 15 inclut également, de préférence, des i nform ation s associées supplémentaires qui concernent un composant, tel que « ventilateur ou conditionnement d'air contrôlable par fermeture contact », qui peut être vu sur la Figure 15, ainsi que la partie de Base de données illustrée sur la Figure 5. De cette manière, les informations supplémentaires provenant de la Base de données peuvent être incluses « automatiquement » dans le rapport qui est spécifique à chaque composant, ou associé avec un groupe de composants. Il faut noter que, dans les exemples décrits sur les Figures 15 et 16, il est préférable que l'information « Appareil» fasse référence à un nom d'appareil incluant éventuellement un type (par exemple, incandescent, CVCA, air conditionné, lampe de bureau, ventilateur de salle de bain, etc.) pour indiquer à l'installateur quelle sortie va vers quelle entrée d'appareil, ainsi que son type, etc.

La Figure 16 décrit la « page 2 » du rapport d'instructions de l'installation qui concerne les sélections de l'utilisateur décrites sur les Figures 7 à 14. Sur cette page donnée à titre d'exemple, des informations détaillées sont présentées comme décrivant les différents Contrôleurs (C1-C5) qui ont été sélectionnés par SW Conf. 14 en comparant les sélections de l'utilisateur sur les écrans interface homme machine (GUI) aux informations de la Base de données décrites sur la Figure 5. Pour chaque composant (par exemple, « ID composant : C1 »), une description de composant (par exemple, « société Y-Contrôleur Interrupteur ») et un numéro de composant (par exemple, « 1234XY01 ») de préférence sont inclus en même temps qu'un tableau indiquant quelle sortie doit être raccordée électriquement. Il est important de noter que, bien qu'une seule sortie donnée à titre d'exemple soit visible dans ces exemples, les installations réelles peuvent inclure de nombreuses sorties pour un composant donné, puisque certains composants sont prévus pour avoir plusieurs sorties disponibles pour des contrôles multiples, etc. En commençant avec C1 , l'installateur est orienté vers ce composant qui est situé à l'emplacement « ZoneOI » dans la Pièce 01 , et il indique en outre que le type de commande est « bouton-poussoir » pour un appareil Incandescent 01 , et que la fonction est : « On/Off » (Marche/Arrêt). Cette indication particulière correspond aux parties d'écran 174, 176, 184, 188 et 196 de la Figure 9. Si l'on continue avec C2, l'installateur reçoit comme indication que ce composant doit être situé dans un emplacement « ZoneOI » dans la Pièce 02 et on lui indique en outre que le type de commande est un « bouton-poussoir » pour Air Conditionné 01 et que la fonction est « On/Off». Cette instruction particulière correspond aux parties d'écran 230, 232, 242, 258 et 248 de la Figure 10. Si l'on continue avec C3, l'installateur est averti que ce composant doit être situé dans l'emplacement « zone01 » de la Pièce 02, et on lui indique en outre que le type de commande est un « bouton-poussoir long » pour Air Conditionné 01 et que la fonction est « température prédéfinie ». Cette indication particulière correspond aux parties d'écran 312 et 320 de la Figure 13. Si l'on continue avec C4, l'installateur est averti que le composant doit être situé dans l'emplacement « ZoneOI » de la Pièce 02, et on lui indique en outre que le type de commande est un « bouton-poussoir long+ » pour Air Conditionné 01 et que la fonction est « Température montée/baisse ». Cette indication particulière correspond aux parties d'écran 292 et 300 de la Figure 13. Si l'on continue avec C5, l'installateur est averti que ce composant doit être situé dans l'emplacement « Zone 01 » dans la Pièce 02, et on lui indique en outre que le type de commande est « bouton-poussoir long - » pour Air Conditionné 01 et que la fonction est « Température montée/baisse». Cette instruction particulière correspond aux parties d'écran 292 et 304 de la Figure 13. Si l'on continue avec C6, l'installateur est averti que ce composant doit être situé dans l'emplacement « zone01 » dans la pièce 02 et on lui indique en outre que le type de dispositif est « bouton-poussoir » pour Air Conditionné 01 et que la fonction est « ventilateur on/off ». Cette instruction particulière correspond aux parties d'écran 238, 272 et 3280 de la Figure 13. La partie de rapport illustrée sur la Figure 16 inclut également, de préférence, des informations supplémentaires liées à un composant telles que « finition : blanc », ainsi que la partie de Base de données illustrée sur la Figure 5. De cette manière, des informations supplémentaires de la Base de données peuvent être « automatiquement » incluses dans le rapport qui est spécifique à chaque composant ou associées à un groupe de composants.

La Figure 17 décrit une autre sortie de rapport donnée à titre d'exemple de la configuration SW 14 qui itémise de préférence les dispositifs sélectionnés pour une nouvelle installation d'une manière qui peut être aisément incluse par un installateur dans une facture ou un autre type de document. Le rapport donné à titre d'exemple illustré sur la Figure 17 peut être généré automatiquement par SW Conf. 14, et est de préférence fondé sur les informations de Base de données à titre d'exemple et décrites sur la Figure 5, ainsi que sur les sélections de l'utilisateur données à titre d'exemple présentées sur les écrans d'interface homme machine utilisateur (GUI) des Figures 7 à 14. Comme représenté, les composants sélectionnés sont intégrés à une liste, de préférence accompagnés d'informations supplémentaires, telles que des informations sur les fabricants, les composants et leurs prix. De cette manière, un installateur peut rapidement et facilement produire une liste détaillée des dispositifs utilisés dans les différents exemples décrits ci-dessus. Il convient de noter que ces items correspondent non seulement à l'écran interface homme machine (GUI) traité dans ce document, mais également à l'architecture donnée à titre d'exemple illustrée sur la Figure 3. En particulier, il convient de noter que l'item 05 fournit des informations-produits données à titre d'exemple associées au Serveur 12.

En conséquence et en se fondant sur les informations entrées par l'installateur

(voir les Figures 7 à 14 et les descriptions qui les accompagnent), ainsi que les données contenues dans les tableaux de Base de données (voir les Figures 4 à 6 et les descriptions qui les accompagnent), des rapports peuvent être automatiquement générés qui donnent la liste des différentes informations concernant le projet de domotique (voir les Figures 15 à 18 et les passages de description qui les accompagnent). Différentes précisions supplémentaires peuvent, de préférence, être fournies en utilisant le même jeu de caractéristiques. Par exemple, les données utilisées pour la programmation spécifiques à chacun des composants de domotique peuvent être organisées de la même manière dans la Base de données (par exemple, voir les « paramètres supplémentaires » sur les Figures 5 et 6). En utilisant ces approches, dans certains modes de réalisation les programmations spécifiques des composants de domotique sélectionnés peuvent, de préférence, être générées automatiquement tel que par SW Conf. 8/14, pour résulter en une sortie de rapports telle que décrite su r la Figu re 18. Typiquement, la programmation de chaque composant de domotique est essentielle, par exemple, pour définir les connexions virtuelles entre les Contrôleurs et les Actionneurs. Par exemple, dans certains protocoles tels que le protocole KNX, une commande de pilotage (par exemple, un bouton pour allumer une lampe) a une adresse logique qui sera utilisée dans un message de communication donné et, de cette façon, la même adresse logique sera de préférence utilisée par l'Actionneur (par exemple, un composant qui envoie effectivement du courant à la lampe au moment où il reçoit l'instruction de le faire). Dans ce cas, le dispositif de commande et les composants du dispositif de commande de l'Actionneur ont, de préférence, une connexion virtuelle avec la même adresse logique, qui créera effectivement un lien virtuel entre les deux. Dans l'exemple décrit sur la Figure 18, la fonction « On/Off » (Marche/Arrêt) (listée comme « action » sur la Figure 18) pour le dispositif Actionneur A1 a une adresse logique de « 1/2/10 », qui est la même adresse logique que la fonction « On/Off » pour le dispositif Contrôleur C1. Tel que décrit sur la Figure 16, le dispositif Contrôleur C1 est une interface de commande d'un bouton-poussoir avec une fonction « On/Off » qui est utilisée pour commander un type incandescent de dispositif d'éclairage. Dans cet exemple, C1 est virtuellement connecté à un dispositif Actionneur AI décrit sur la Figure 15. Cette même relation est décrite d'une autre manière sur la Figure 3. C1 correspond au Contrôleur 32, et A1 correspond à l'Actionneur 34. En utilisant SW Conf. pou r programmer automatiquement les composants individuels, la même adresse logique peut être, de préférence, programmée dans les composants appropriés en se fondant sur les informations entrées par l'installateur pendant la phase d'installation, et basée sur les données contenues dans la Base de données.

En conséquence, la Figure 18 décrit un rapport donné à titre d'exemple sorti par SW Conf. 14, qui donne de préférence la liste des dispositifs sélectionnés pour une nouvelle installation, en même temps que les détails techniques associés à chaque dispositif, pour fournir à un installateur un jeu organisé de spécifications de matériel et les détails concernant la programmation pour la nouvelle installation. Le rapport donné à titre d'exemple illustré sur la Figure 18 peut être automatiquement généré par SW Conf. 14, et il est, de préférence, basé sur les informations de Base de données données à titre d'exemple et décrites sur la Figure 5, ainsi que les sélections de l'utilisateur données à titre d'exemple et présentées sur les différents écrans de l'interface homme machine utilisateur (GUI) des Figures 7 à 14. Tels que montrés, les composants sélectionnés sont listés, de préférence accompagnés par des informations supplémentaires, telles que des informations concernant le fabricant, des informations concernant l'identification des dispositifs, des informations concernant l'action associée à chaque dispositif, des informations d'adresses physiques et logiques, des séquences de programmation , et d'autres paramètres associés à chaque dispositif. Dans l'exemple de la Figure 18, la séquence de programmation pour un dispositif donné est décrite comme « XX XX XX XX XX » ; ceci est dû au fait que dans certains modes de réalisation préférés les informations de programmation sont sous la forme d'un code hexadécimal, qui peut être stocké dans la Base de données (par exemple, la Base de données 18 et/ou la Base de données 10 décrite sur la Figure 3) tel que, par exemple, dans les « Params supplémentaires », partie du tableau donné à titre d'exemple décrit sur la Figure 6. De cette manière, un installateur peut facilement et rapidement produire un rapport qui donne la liste des détails techniques et des séquences de programmation pour la liste des dispositifs utilisés dans une installation donnée. Dans certains modes de réalisation cette information peut être copiée et collée dans les outils de logiciel de configuration, tels que ETS (Engineering Tool Software) dans le cas de la topologie d'interconnexion KNX. En plus, dans certains modes de réalisation préférés plutôt que produire simplement un rapport qui contient ces données de p rog ra m m ati o n , u n u t i l i s ate u r ( i n s ta l l ate u r ou u ti l i s ate u r f i n a l ) pe u t programmer/reprogrammer automatiquement un ou plusieurs dispositifs, tels que par une connexion électrique d'un dispositif donné et une initiation du transfert de la séquence de programmation pour ce dispositif, en utilisant le même type de Base de données contenant les informations de séquence de programmation pour chaque dispositif sélectionné. Une telle caractéristique simplifie grandement la tâche de programmation de tous les dispositifs pour une installation donnée puisqu'elle réduit la complexité de la tâche que l'installateur doit effectuer, et réduit au minimum toutes les occasions d'erreurs qui pourraient être introduites, comme en faisant des erreurs dans la séquence de programmation pour un dispositif donné. Une telle caractéristique de programmation automatique réduit également grandement le temps requis pour l'installation, ce qui peut réduire les coûts, etc. Enfin, une telle caractéristique de programmation/reprogrammation automatique réduit la complexité, de telle sorte que la tâche devient suffisamment simple pour qu'un utilisateur final l'effectue comme cela est le cas lorsque l'utilisateur final désire reprogrammer un dispositif donné, ou ajouter une caractéristique. En utilisant la Base de données et les caractéristiques logicielles décrites dans ce document, il devient possible d'automatiser de nombreux aspects les plus complexes des processus d'installation/réinstallation et de rendre ainsi plus facile pour un utilisateur la réalisation de ces tâches.

De préférence, lorsque la phase d'installation est terminée, une interface homme machine utilisateur (GUI) est générée pour le contrôle quotidien du système de domotique par un utilisateur final. De préférence, cette interface est générée de manière dynamique de la même manière que l'interface homme machine (GUI) d'installation traitée en rapport avec les Figures 6 à 14, et graphiquement compatible avec plusieurs types d'affichage. Par exemple, la résolution, la taille, la couleur, les réglages d'autres vues, etc., sont de préférence compatibles pour les visualisations optimisées sur différents dispositifs tels qu'un Smartphone, les tablettes, les PC, les ordinateurs, etc. (voir, par exemple, le traitement, dans les présents documents, des autres exemples décrits sur les Figures 23 à 26). Bien que nous utilisions « LAN » dans ce document pour décrire le type de connexion entre le système et les téléphone/tablette/PC, etc., dans certains modes de réalisation, cette connexion peut se faire via un autre type d'interconnexion, tel que la connexion par réseau cellulaire de type GSM/CDMA, Bluetooth, ou certains autres types de connexion de données. En outre, dans certains modes de réalisation, la connexion peut être filaire, sans fil ou la combinaison de ces deux connexions. Dans les deux cas de la phase d'installation et de la phase utilisateur final, il est préférable d'adopter une caractéristique interface homme machine (GUI) adaptative pour optimiser les menus de manière à présenter les items les plus souvent utilisés de manière plus proéminente que les items les moins utilisés. De plus, dans certains modes de réalisation, il est préférable d'inclure une macro caractéristique programmable par l'utilisateur (c'est-à-dire, la capacité de programmer une commande intelligente), comme permettre le contrôle d'une pluralité de fonctions d'Actionneur utilisant un seul événement.

La Figure 19 décrit un écran donné à titre d'exemple pour le contrôle quotidien du système par un utilisateur final. De préférence, cette interface utilisateur est générée automatiquement par le système, en se fondant en partie sur la Base de données. L'interface homme machine (GUI) 100 est de préférence subdivisée entre une partie gauche 400, une partie droite 412 et une partie centrale 424. Dans certains modes de réalisation, l'utilisation des barres de défilement 402 et 414 peut être avantageuse dans n'importe laquelle des parties d'écran pour indiquer qu'il existe des icônes supplémentaires disponibles après le défilement. Dans cet exemple, la partie gauche 400 contient des icônes 404, 406, 408 et 410 correspondant à chaque pièce du bâtiment. Dans certains modes de réalisation préférés, l'interface homme machine (GUI) 100 met automatiquement en surbrillance la pièce dans laquelle se trouve l'utilisateur, en détectant par exemple où la tablette/le PC/le téléphone 28 qui décrit l'interface homme machine (GUI) 100 se trouve physiquement dans le bâtiment, ou par d'autres moyens (par exemple badge RFID, etc). Bien que des noms par défaut tels que « Pièce 01 » et « Pièce 02 » soient utilisés dans cet exemple, dans certains modes de réalisation, il peut être préférable d'autoriser une convention de dénomination plus intuitive, telle que « salle à manger », « bureau », « salle de séjour », « salon », etc., comme en autorisant l'utilisateur à nommer les pièces lui-même. La partie droite 412 décrit, de préférence, une liste de catégories/dispositifs qui sont pertinents (ou disponibles) dans une pièce sélectionnée. Dans certains cas, il peut exister certain(e)s catégories/dispositifs qui sont disponibles de manière universelle (par exemple, non limitées à une certaine pièce) telles que les catégories liées à la sécurité. Dans l'exemple de la Figure 19, la partie droite 412 contient une icône de commandes intelligentes 416 qui est de préférence utilisée pour contenir des macro-commandes préprogrammées. L'éclairage 418, la CVCA 420 et les volets des fenêtres 422 sont des icônes supplémentaires données à titre d'exemple dans la partie droite 412 qui correspond à la liste de catégories disponibles qui concernent une pièce donnée. Il convient de noter que la Figure 412 décrit une barre défilante 414 pour indiquer qu'il peut y avoir des catégories/dispositifs supplémentaires disponibles dans cette pièce donnée, accessibles en déroulant le menu. La partie centrale 424 décrit une liste de catégories/dispositifs « favoris » qui peuvent, de préférence, ne pas être limités à une pièce donnée. Cette partie décrit de préférence les items qui sont le plus souvent utilisés ou le plus utiles à l'utilisateur final. Dans cet exemple de la Figure 19, la liste des catégories/dispositifs favoris inclut Air Conditionné 01 426 qui est décrit avec un curseur 428 qui indique que la température dans la pièce sélectionnée est réglée sur 20° Celsius. Dans certains modes de réalisation, il est préférable de munir ce curseur d'un affichage tactile de manière à permettre à un utilisateur de modifier rapidement la température en touchant et en faisant glisser le curseur 428. D'autre part, les composants décrits dans la partie favorite de l'affichage incluent incandescentOI et incandescent02 430 et 432, Air Conditionné 01 Ventilateur 434 et Air Conditionné 01 Température prédéfinie 436. Température prédéfinie 436 fournit de préférence une autre manière de changer rapidement la température (par exemple, en plus d'utiliser le curseur 428) ; au moment de la sélection de l'icône 436, le Contrôleur Air Conditionné 01 changera de préférence immédiatement pour une valeur de température prédéfinie.

La Figure 20 décrit le même type d'écran que la Figure 19 avec la différence notable que la pièceOI 404 est mise en surbrillance. Il convient de noter que, sur la Figure 19, l'item mis en surbrillance est décrit en utilisant un contour en gras ; d'autres moyens d'identification visuelle d'un item peuvent être utilisés comme une animation, une coloration ou d'autres possibilités visuelles. De plus, dans certains modes de réalisation, il est recommandé d'indiquer visuellement quand un dispositif de contrôle effectue réellement une tâche ; par exem ple, si l'utilisateu r sélectionne u ne température prédéfinie 436, il peut être recommandé d'indiquer que le Contrôleur Air ConditionnéOI est effectivement en train de modifier la température de la pièce pour la mettre à la valeur préprogrammée. Comme autre exemple, lorsque Air ConditionnéOI VENTILATEUR 434 est mis en route, il peut être recommandé de l'indiquer visuellement à l'utilisateur, tel qu'en changeant l'apparence de l'icône 434 (par exemple, grâce à l'utilisation de couleurs, d'animations, etc.). De cette manière, l'interface homme machine (GUI) 100 décrira le statut actif ou inactif de chaque dispositif de commande, de manière à décrire quelles lampes sont allumées ou quels dispositifs sont actifs.

Comme mentionné par ailleurs dans ce document, dans certains modes de réalisation, le système détecte automatiquement dans quelle pièce se situe l'utilisateur ; dans l'exemple de la Figure 20, il s'agit de la pièceOI . Bien entendu, dans certains modes de réalisation, il peut être préférable de permettre à l'utilisateur de sélectionner la pièce manuellement (au lieu de ou en plus de l'auto détection de la pièce). Sur la Figure 20, l'icône éclairage 418 est sélectionnée dans la partie droite 412 (également indiquée avec un contour en gras). En conséquence, la partie centrale 424 inclut maintenant de préférence de nouveaux items liés à la catégorie éclairage sélectionnée pour une pièce donnée (PièceOI ). Dans l'exemple de la Figure 20, elle inclut incandescent06 426, LED09 432, LED sécurité03 434 et LED1 1 428. Cette dernière inclut un curseur 430, et décrit la sortie d'éclairage LED1 1 comme étant active à 90 %. Il convient de noter que bien qu'une barre de défilement ne soit pas décrite dans la moitié inférieure de la partie centrale 424, dans certains modes de réalisation, il est préférable d'inclure cette barre de défilement (par exemple, similaire aux barres de défilement 402 et 414), pour permettre que des items supplémentaires soient situés dans la partie inférieure de la partie centrale 424 ; de cette manière l'interface homme machine (GUI) 100 peut, de préférence, contenir des zones multiples qui peuvent défiler indépendamment les unes des autres.

La Figure 21 décrit le même type d'écran que la Figure 20, avec la différence notable que maintenant la Pièce04 408 est mise en surbrillance, et que la partie gauche 400 a défilé pour décrire des pièces supplémentaires 440 et 442. A nouveau, dans certains modes de réalisation préférés, cette sélection de la pièce03 se produit automatiquement, comme lorsqu'un utilisateur pénètre dans la pièce donnée, bien que dans d'autres modes de réalisation, ce puisse être une occurrence sélectionnée par l'utilisateur comme en appuyant sur l'icône 408. De plus, la Figure 21 décrit la partie droite 412 qui défile de la même manière pour décrire maintenant des catégories supplémentaires audio/vidéo 444 et piscine 446. Alors que cette sélection peut de la même manière être automatisée en se fondant sur une détection automatique de l'emplacement de l'utilisateur (par exemple en détectant un signal F tel que la communication proche (NFC), la détection des coordonnées GPS, une détection de mouvement en forme d'un signal WI-FI, etc.), on s'attend à ce que dans certains modes de réalisation ceci soit de préférence sélectionnable par l'utilisateur. Alors que, dans certains modes de réalisation, l'emplacement du dispositif décrivant l'interface homme machine (GUI) puisse être détecté, dans d'autres modes de réalisation, il est préférable de détecter l'emplacement de l'utilisateur, comme par exemple, en utilisant la détection RFID ou une étiquette RFID portée par la personne. Dans certains modes de réalisation, il est préférable d'indiquer une priorité aux utilisateurs, de telle sorte que, si plusieurs utilisateurs sont détectés (par exemple, par RFID, détection de mouvement, ou autres), seulement un des utilisateurs détectés aura la priorité la plus haute pour influencer la sélection automatique d'une pièce dans l'interface homme machine (GUI) d'un dispositif donné.

Si l'on fait à nouveau référence à la Figure 21 , dans cet exemple, l'audio/vidéo 444 est sélectionné/activé, et en conséquence, la partie inférieure de la partie centrale 424 décrit maintenant des items liés à la catégorie audio/visuelle pour la pièce donnée. L'item 448 décrit un curseur horizontal activé (par exemple en gras) 450 associé au volume sonore dans la cuisine (défini sur 20 % dans cet exemple). De préférence, l'utilisateur est capable de sélectionner et de faire coulisser ce curseur pour modifier rapidement le volume. L'item 452 est un affichage de la source audio sélectionnée ; dans cet exemple il est réglé sur une station radio de la BBC.

La Figure 22 décrit le même type d'écran que la Figure 21 , avec la différence notable que maintenant la partie droite 412 défile encore plus loin en décrivant ainsi les catégories supplémentaires disponibles de la Pièce04 408, incluant SPA 454, sécurité 456, et l'icône Autres applications 458. En l'occurrence, dans cet exemple l'icône Sécurité 456 est sélectionnée/activée, ainsi que l'icône « Autres Applications » 458. Dans cet exemple, l'icône 458 est associée à des informations rapportant des statistiques, telles que la consommation d'énergie, les mesures, la durée d'utilisation, et d'autres données statistiques qui ont été mesurées et mises en mémoire. Dans certains modes de réalisation, le système lit régulièrement les états des appareils ainsi que tous les événements sur le bus domotique (par exemple, le réseau KNX 30 décrit sur la Figure 3), et mémorise les informations résultantes (par exemple, localement sur un dispositif de stockage tel qu'un entraînement ou un système de pilotage à semiconducteurs SSD, et/ou les transfère sur le réseau vers un stockage distant, tel que sur Internet). Dans cet exemple de la Figure 22, étant donné que deux icônes sont activées 456 et 458, l'information décrite dans la partie inférieure de la partie centrale 424 comprend dorénavant une partie de sortie vidéo 460 (par exemple, la vidéo fournie par une caméra de sécurité) et une partie statistique 462 (par exemple, avec un tableau contenant les données statistiques référencées ci-dessus). De cette manière, il est préférable de permettre à l'utilisateur d'avoir accès à différents catégories/systèmes de contrôle dans la même pièce, et par conséquent différentes fonctions. En outre, dans certains modes de réalisation, il est préférable de permettre que des informations concernant l'utilisation (par exemple, la configuration/implantation d'une installation donnée) et/ou des informations d'util isation (par exemple, statistiques, etc.) soient sauvegardées dans un lieu de sauvegarde, tel qu'un dispositif de stockage amovible fixé au système 12, ou un dispositif de stockage distant connecté au système 12 via une ou plusieurs interfaces de réseau (par exemple, WAN 20 ou LAN 22).

Nombreux sont les exemples d'interface utilisateur mentionnés ci-dessus qui sont destinés à être applicables à un dispositif portatif, tel qu'un téléphone cellulaire à écran tactile, un iPod Touch, un ordinateur ou une tablette, etc. Dans certains modes de réalisation, il peut être préférable de limiter le nombre d'icônes affichées sur un écran donné, de manière qu'elles puissent s'adapter sur un écran plus petit. Dans d'autres modes de réalisation, il peut être préférable de réduire l'échelle de tous les éléments, de sorte que le même affichage puisse être présenté sur un écran plus petit. De plus, les Figures 23 à 26 illustrent certains autres modes de réalisation préférés pour l'interface utilisateur optimisée pour l'affichage sur une taille d'écran plus petite (par exemple, tel qu'un téléphone cellulaire avec un affichage tactile). Les exemples décrits sur les Figures 23 à 26 sont analogues à l'interface homme machine (GUI) décrite sur la Figure 21 , qui implique un exemple de la pièce03 408 sélectionnée sur la partie d'écran gauche 400, en tant que l'audio/vidéo 444 sélectionné sur la partie droite de l'écran 412, et le volume dans la cuisine 448 sélectionné dans la partie centrale de l'écran 424. Si l'on se réfère à une interface homme machine (GUI) plus petite décrite sur la Figure 23, ces mêmes caractéristiques des Figures 21 sont disponibles sur une interface homme machine (GUI) de plus petite taille, avec l'intégration de parties de bordures 470, 472 et 474. Dans ces modes de réalisation, la partie de bordure gauche 470 affiche la pièce sélectionnée (dans cet exemple, « pièce03 »). Pour un tel cas traité par ailleurs dans les présents documents, dans certains modes de réalisation préférés, le logiciel met automatiquement à jour la pièce sélectionnée dans la partie gauche de l'écran en détectant l'emplacement de l'utilisateur (ou selon une autre possibilité, l'emplacement du dispositif utilisé par l'utilisateur). Dans l'exemple de la Figure 23, la pièce peut, de préférence, se mettre automatiquement à jour alors que l'utilisateur se déplace d'une pièce à l'autre. Dans le cas où l'utilisateur final souhaiterait modifier manuellement la pièce sélectionnée, il ou elle peut toucher la bordure gauche pour faire défiler le menu de la pièce sur le côté gauche de l'écran, tel que décrit sur la Figure 24 (en décrivant la partie d'écran gauche telle que décrite sur la Figure 21 ). Dans certains modes de réalisation, il est prévu que l'utilisateur final n'aura finalement pas besoin de modifier manuellement la pièce détectée automatiquement, et en cachant le menu de la pièce, ceci permet que la partie principale active de l'écran occupe une partie plus large de l'écran. De la même manière, la Figure 25 décrit la partie d'écran droite 412 qui coulisse de la gauche (par exemple, après qu'un utilisateur a touché la partie de bordure droite 472 de la Figure 23) pour révéler les icônes disponibles pour la pièce sélectionnée (tel que décrit sur la Figure 21 ). De la même manière, la Figure 26 décrit les parties « favorites » de l'écran révélées, comme par un utilisateur touchant la bordure supérieure 474 de la Figure 23. Dans certains modes de réalisation, ces parties d'écran sont de préférence cachées complètement, et activées via des commandes vocales (par exemple, en disant « pièces ! » pour voir le menu pièces, ou « piècel » pour sélectionner la PièceOI , etc.). Comme autre exemple, dans certains modes de réalisation , les commandes vocales peuvent être « Piècel /Zone2/Lampe1 /Marche» pour allumer la lampe, ou « Piècel /Zone2/Lampe1 /Valeur/50 » pour régler la valeur à 50, ou dire juste « Valeur/30 » en utilisant les valeurs par défaut (par exemple les dernières utilisées) pour les paramètres non verbalisés. Plus particulièrement, ces caractéristiques alternatives décrites sur les Figures 23 à 26 sont simplement alternatives pour les caractéristiques interface homme machine (GUI) décrites par ailleurs dans ce document ; dans certains modes de réalisation, il peut être préférable d'utiliser le format plus grand illustré sur les Figures 19 et 22, même dans le cas d'un affichage à écran plus petit, tel qu'un téléphone cellulaire à écran tactile.

En ce qui concerne les Figures 19 à 22, tel que décrit par ailleurs dans les présents documents (par exemple en relation avec la Figure 4), il est préférable de fournir les écrans interface homme machine (GUI) en utilisant une fonctionnalité générée de manière dynamique, en utilisant une Base de données (par exemple telle que le type SQL de la Base de données décrit/traité par ailleurs dans les présents documents) et différentes caractéristiques de Serveur Web (telles que le type PHP des fonctionnalités du Serveur Web traité par ailleurs dans ce document) permettent que les écrans interface homme machine (GUI) soient facilement mis à jour de manière à refléter les nouvelles caractéristiques ou langues. En outre, du fait que les écrans interface homme machine (GUI) décrits sur les Figures 19 à 22 sont générés en utilisant une technologie du Web (par exemple, dynamiquement en utilisant PHP, SQL et Javascript), ceci permet de préférence à l'utilisateur d'avoir accès aux fonctionnalités du système en utilisant n'importe quel dispositif pouvant fonctionner sur le Web tel que tablette/PC/ téléphone 28 décrits sur la Figure 3, et l'utilisation de ces caractéristiques pour l'interface homme machine (GUI) entraîne de préférence une large compatibilité avec tous les dispositifs pouvant fonctionner sur le Web.

Il convient de noter que, comme utilisé dans les différents exemples d'écrans interface homme machine (GUI) dans les présents documents, l'entrée utilisateur est fournie de préférence via un clavier ou un affichage tactile. Dans certains modes de réalisation, il peut être préférable que l'entrée utilisateur soit fournie via un microphone (par exemple, en utilisant les caractéristiques de reconnaissance vocale), une caméra vidéo/détection à infrarouge (par exemple, en utilisant des caractéristiques de détection de mouvement et/ou de reconnaissance faciale), ou via tout autre dispositif d'entrée. Ces approches impliquent de préférence une phase d'apprentissage, pendant laquelle l'utilisateur « programme » un geste physique (gestes avec la main ou avec les bras, etc.) ou un mouvement du visage qui sera associé avec une caractéristique donnée, etc.

Il convient de noter que les caractéristiques d'accès à distance décrites dans ce document (voir, par exemple, Figures 3, et 9 à 13, et les descriptions jointes) incluent de préférence la capacité d'utiliser, d'avoir accès, et/ou de contrôler à distance les composants comprenant le réseau de domotique (par exemple, le réseau KNX 30). Dans certains modes de réalisation, les caractéristiques d'accès à distance incluent de préférence la capacité d'effectuer à distance la maintenance d'une installation donnée.

Des modes de réalisation des techniques de choix vont maintenant être détaillés.

Il est important de noter qu'une grande partie des fonctionnalités de l'invention repose sur le choix automatiques des éléments domotiques nécessaires à l'installation finale. Pour permettre de mieux comprendre la manière avec laquelle ces choix sont effectués de manière automatisée, une terminologie spécifique doit être mise en place. Dans les paragraphes ci-après les termes suivants seront utilisés :

- Equipement domotique:

Tout boîtier spécialisé pouvant servir à piloter des appareillages électriques (ex.: un actionneur de lampe servant de passerelle entre un réseau domotique KNX et des lampes à incandescence, un contrôleur servant d'interface entre un bouton poussoir et un réseau domotique KNX, etc).

- Appareil:

Tout appareillage pouvant être piloté par des équipements domotiques (ex.: lampe, radiateur, pompe à chaleur, climatiseur, alarme, store, porte, portail, télévision, chaîne audio, etc).

- Actionneur:

Tout équipement domotique comportant des "fonctions" (voir ci-après).

- Contrôleur: Tout équipement domotique comportant des "commandes". Ces équipements peuvent également comporter des "contrôles" et des "afficheurs" (voir ci-après).

- Fonction:

Action qui modifie directement ou indirectement le comportement d'un appareil, ou qui renvoie un état lié à l'appareil. Elle inclut une "sous-application" (ex.:

Incandescent, Halogène, Convecteur, etc) et une action sur l'appareil associé (ex.: On/off, Variation, etc).

Il existe différents types de fonctions:

• Fonctions directes sur l'appareil (ex.: Incandescent On/Off, Halogène Variation d'Intensité, Porte Ouverture, Store Fermeture, etc).

Ces fonctions sont exécutées par un actionneur, qui généralement est un élément installé au tableau électrique qui envoie le courant de fonctionnement vers un appareil.

• Fonctions de retour de fonctions (ex.: retour de l'état de la fonction on/off, de la valeur envoyée à un variateur, etc). Ces fonctions sont exécutées par un actionneur et retournent vers un contrôleur-afficheur (cf commende ci-après) la valeur correspondant à une fonction de l'actionneur.

• Fonctions d'info d'état d'un actionneur (ex.: Incandescent, court-circuit, etc).

Ces fonctions sont exécutées par un actionneur et retournent vers un contrôleur-afficheur une valeur correspondant à un état de l'actionneur, dépendant de l'appareil utilisé.

• Fonctions d'entrée de paramètres dans un contrôleur (ex.: entrée température de consigne d'un contrôleur-thermostat). Egalement appelées "Contrôles", ces fonctions modifient le comportement d'un contrôleur en changeant les valeurs de ses paramètres internes.

• Fonctions de retour de contrôle (ex.: Retour de la température de consigne programmée dans un contrôleur-thermostat). Ces fonctions sont exécutées par un contrôleur et retournent la valeur correspondant à une fonction du contrôleur vers un contrôleur-afficheur (qui peut être le même contrôleur).

• Fonctions d'info d'état du contrôleur (ex.: Info de la température ambiante parla sonde interne d'un thermostat-contrôleur, etc). Ces fonctions sont exécutées par un contrôleur et retournent une valeur correspondant à un état du contrôleur vers un contrôleur-afficheur. Elles sont indépendantes de l'appareil utilisé. - Commande:

Action qui déclenche une fonction. Les actions sont physiquement intégrées dans des contrôleurs. Une action inclut un élément physique (ex.: Bouton Poussoir, Interrupteur à Bascule, etc), une action sur cet élément physique (ex.: Appui Long, Appui Court, etc), et un effet correspondant à la fonction demandée à un actionneur (ex. On, Off, Toggle On/off, Variation, etc) ou même à un contrôleur (ex.:

T°Consigne, Valeur de Minuterie, etc.).

Il existe différents types de commandes:

• Commandes directes vers un actionneur (ex.: Bouton Poussoir Appui Court On/Off, Bouton Rotatif Sans Appui Variation, etc). Elles déclenchent les fonctions définies dans un actionneur.

• Commandes envoyant des valeurs pour modifier les paramètres internes d'un contrôleur (ex.: Bouton Rotatif Sans Appui T° Consigne, etc). Elles permettent de changer les valeurs de paramètres internes d'un contrôleur en utilisant un autre (ou le même) contrôleur.

• Télécommande. C'est la commande par défaut qui permet d'envoyer des

valeurs de commandes à des actionneurs ou des contrôleurs en utilisant un ordinateur (PC, Mac, Linux, Tablette, SmartPhone, etc.) comme si c'était un contrôleur physique.

- Afficheur:

Elément d'un contrôleur qui affiche une information. Cette information peut être fournie par un retour de fonction, un état d'actionneur, un retour de contrôle ou un état de contrôleur. Elle peut être spécifique à une fonction (par ex. icône court-circuit), ou générique (par ex. LED bleue, LED rouge, etc.).

Il est également important de noter que le choix automatisé des éléments domotiques ne consiste pas en un simple tri linéaire basé sur des critères stockés dans une base de données.

Par exemple, les contrôleurs dépendent des zones dans lesquelles ils sont installés, contrairement aux actionneurs, qui eux dépendent des appareils, qui doivent être structurés en classes définissant, par exemple, la puissance nécessaire pour les piloter. Les fonctions, elles, dépendent des types d'applications (lumière, chauffage, stores, ...), tandis que les commandes dépendent des fonctions à piloter. Lors du choix d'un élément domotique il va falloir déterminer s'il existe un ou plusieurs éléments domotiques répondant aux demandes de l'utilisateur/installateur, et déterminer :

- les fonctions nécessaires pour un même appareil

- les commandes demandées pour une même fonction

- les commandes pilotant plusieurs fonctions

- les fonctions pilotées par plusieurs commandes

- les appareils pilotés par plusieurs fonctions, ne faisant pas forcément partie de la même pièce/zone

- la compatibilité de certaines fonctions dans un même élément (si on utilise une fonction, elle peut rendre indisponible d'autres fonctions du même boîtier)

- etc.

La mise en place de ces fonctionnalités nécessite le développement et la structuration de base de données et d'algorithmes de plusieurs niveaux.

Les données à définir et structurer dans les bases de données doivent servir à :

- faciliter la définition d'un cahier des charges par un non-spécialiste de la domotique/immotique en listant automatiquement, par exemple, les appareils liées à certaines applications, les fonctions liées à certains appareils, les commandes liées à certaines fonctions ;

- contrôler automatiquement la faisabilité et ne proposer que des choix possibles, par exemple déterminer automatiquement les fonctions qui peuvent être simultanément utilisées par un seul appareil, déterminer les fonctions qui peuvent être simultanément utilisées par plusieurs appareils, dans un même actionneur, un même contrôleur (commandes, affichages, contrôles) ; vérifier la compatibilité interne (par ex. l'utilisation des boutons « Haut/Bas » d'une même touche ne permet plus de l'utiliser en mode « Pleine Touche » ou en mode « Gauche/Droite »)

- effectuer les liens fonctions/contrôles - commandes/afficheurs en déterminant automatiquement quelles commandes ou fonctions peuvent ou doivent être accessibles sur un même élément domotique (ou sous- ensemble d'élément domotique (par ex. un boîtier multi_touches doit utiliser la partie haute d'une touche pour déclencher une action (fonction), et la partie basse pour une autre action, mais doit utiliser une autre touche du même élément pour d'autres actions) ;

définir des critères de choix des éléments domotiques, par ex. noms de fabricants, prix, nombre de fonctions par boîtier, finitions, etc. ;

choisir automatiquement des éléments domotiques « optimaux » en associant les fonctionnalités des éléments virtuels décrits ci-dessus avec des éléments physiques en prenant en compte par exemple le nombre d'actions demandées pour une même sortie, pour des sorties différentes, la compatibilité des actions (fonctions, commandes, etc) requises dans un même boîtier, les critères choisis, les classes et hyperclasses (surensembles de classes) d'équivalences correspondant aux paramètres physiques tels que les puissances requises, etc. ;

déterminer automatiquement les coûts d'installation, par ex. coûts des éléments choisis automatiquement à partir du cahier des charges, coûts des éléments spécifiques additionnels (alimentations, coupleurs fonctions du nombre d 'éléments installés, etc.), coûts de programmation, etc.

déterminer automatiquement les directives de programmation des éléments domotiq ues pour permettre par exemple de déterminer automatiquement le choix d'adresses (KNX, IP, ...) des éléments physiques, ainsi que des adresses de leurs fonctions logiques pour permettre de les mettre en relation ;

déterminer automatiquement les directives d'installation permettant par exemple de définir, lister et lier les éléments domotiques choisis automatiquement, le choix des sorties spécifiques d'actionneurs à connecter aux appareils définis dans le cahier des charges, les boutons spécifiques de contrôleurs utilisés pour piloter les fonctions définies dans le cahier des charges, etc. ;

rédiger automatiquement un résumé d'installation listant toutes les fonctionnalités en les classant par exemple par pièce / zone / appareil / fonction

générer automatiquement une maquette non fonctionnelle représentant dès l'entrée du cahier des charges une représentation graphique de télécommandes configurable mettant en oeuvre tous les éléments choisis dans le cahier des charges

- générer automatiquement une télécommande fonctionnelle à l'installation pouvant être utilisée à partir de n'importe quel équipement disposant d'un accès web local ou distant (smartphone, tablette, pc, etc.) pour contrôler et afficher tous les éléments choisis dans le cahier des charges, créer des scénarios d'utilisation, etc.

Pour pouvoir mettre en œuvre les applications énumérées ci-dessus, une structuration des données et des algorithmes est nécessaire pour optimiser les tris et appliquer un bon compromis temps de calcul/optimisation des résultats.

Structuration des bases de données

Les différentes tables utilisées dans l'invention peuvent se définir dans les catégories suivantes :

- Catalogues (données statiques) : liste des éléments domotiques des différents catalogues de fabricants ; liste des actions disponibles par élément et types d'action (commande, fonction, contrôle, affichage,...) ; liste des variations (finitions, modèles,...)

- Fonctionnalités génériques (don nées statiq ues) : liste des actions, commandes, fonctions, formats, classes, applications, types de pièces/salles, types d'appareils, types d'affichages (génériques, spécifiques, ...), types de préférences,...

- Données par projet/chantier/installation (données dynamiques) : pièces, zones, choix de configuration (cahier des charges des fonctionnalités demandées), préférences, gestion de projet (multi-projet), gestion des utilisateurs finaux (multi-utilisateurs) ;

- Données système (données dynamiques) : gestion des erreurs, logs, tables intermédiaires (optimisation des tris, etc), versioning ;

- Utilisation finale après installation (données dynamiques) : gestion des télécommandes, gestion des utilisateurs finaux, gestion du réseau domotique, gestion des logs (statistiques, affichages de retours, etc)

Structuration des algorithmes La prise en compte de tous les éléments utilisés dans les tables des bases de données décrites ci-dessus implique évidemment une complexité exponentielle lorsqu'on doit choisir automatiquement les éléments domotiques à partir de ces tables et des choix émis durant l'étape de configuration (cahier des charges).

Une solution théorique pour assurer le meilleur choix possible d'éléments basé sur les critères, disponibilités et choix de configuration serait d'essayer toutes les combinaisons possibles d'éléments répondant à ces requêtes, ce qui évidemment nécessiterait des ressources, en particulier temporelles, finies mais incommensurables (plusieurs années de temps de calcul...).

Dans la pratique il faut donc, à défaut de forcément trouver une solution optimale, faire un choix optimisé tout en restant dans le domaine « raisonnable » de temps de calcul (quelques minutes).

En dehors des optimisations connues par l'état de l'art de l'utilisation et l'optimisation de bases de données (organisation des tables, indexation des clés, etc.) il a fallu dans le cadre de l'invention déterminer plusieurs étapes pour éliminer les chemins trop coûteux en temps/ressources.

Après de multiples études combinant diverses structurations des bases de données et des algorithmes, les paragraphes ci-après décrivent à titre d'exemple les différentes étapes (ou niveaux) pouvant être utilisées pour le choix de contrôleurs ou d'actionneurs à partir de commandes ou de fonctions requises par le cahier des charges. A noter que les mêmes types d'algorithmes devront être définis et appliqués séparément pour les commandes, les contrôles, les affichages, ainsi que pour les fonctions dans les actionneurs.

Premier niveau :

Détermination des actions à sorties partagées, à sorties différentes, à sorties multiples (par ex. Store Montée/Descente nécessite parfois 2 sorties selon les actionneurs), à éléments différents, à zone différentes.

On peut par exemple par défaut supposer que des zones différentes impliqueront des choix de contrôleurs différents. Inversement ce n'est pas nécessairement le cas pour des actionneurs qui typiquement se retrouvent dans un même tableau électrique.

De même on pourra par défaut supposer que des commandes (contrôleur) connectées à une même fonction (actionneur) seront typiquement (mais pas nécessairement) traitées par une même touche de commande, alors que si elles s'appliquent à des fonctions elles-mêmes connectées à des appareils différents elles devront être par défaut traitées par des sorties (touches) différentes.

Tous ces choix automatiques sont définis a priori mais doivent bien sûr pouvoir être modifiables (et modifiés) par l'utilisateur/installateur, ce qui implique la possibilité de traitements différents.

Il faut donc préparer dans les tables des colonnes qui définissent les liens a priori entre les différentes actions et les éléments domotiques virtuels qui serviront de base de départ pour les étapes suivantes des algorithmes de choix. On parle ici d'éléments virtuels car :

- ils ne prennent pas encore en compte l'existence effective d'éléments physiques permettant de mettre en œuvre les différentes actions souhaitées ;

- ils ne prennent pas en compte, par exemple, l'existence de sorties disponibles dans un élément physique à partir de l'élément virtuel requis. Par exemple, ces algorithmes de premier niveau peuvent impliquer l'utilisation d'un élément domotique à 25 sorties, alors que seuls des éléments domotiques de 16 sorties maximum existent pour les actions requises, ou pour la combinaison d'actions différentes requises.

Une fois la configuration terminée, et les éventuelles modifications manuelles effectuées pour remplacer les choix par défaut déterminés par les algorithmes de premier niveau, de nouvelles tables intermédiaires ont été créées pour être utilisées par les algorithmes des niveaux suivants.

Deuxième niveau :

Détermination des solutions possibles

A partir des actions (fonctions, commandes, affichages, etc.) enregistrées dans diverses tables de la base de données avec leurs paramètres spécifiques, les algorithmes de 2 ^eme niveau peuvent considérer les actions Φ associées à un nouvel élément virtuel (dans un premier temps) ou à une nouvelle sortie d'un élément virtuel déjà défini (dans un deuxième temps).

A chaque action Φ ils vont pouvoir associer les actions φ partageant la même sortie que Φ à partir de ces données et chercher tous les éléments physiques P comportant les actions requises (ou des actions équivalentes) et les stocker dans une autre table intermédiaire. Il est à noter qu'un même élément P peut voir plusieurs possibilités d'action compatibles avec les actions requises, et chacune d'entre elles peut être mémorisée à des fins éventuelles d'optimisation par la suite.

Il faut aussi noter que certaines de ces actions seront incompatibles entre elles à l'intérieur d'un même élément physique et impliqueront alors soit le choix de 2 éléments séparés pour les traiter, soit le choix de 2 sorties séparées de ce même élément.

En fonction du type d'action, les algorithmes de 2 ^eme niveau ne seront pas exactement les mêmes. Par exemple les sorties d'actionneur correspondent à des sorties physiques, qui elles-mêmes ont des caractéristiques devant être compatibles avec les appareils auxquels elles seront connectées (par ex. puissance électrique, impédance complexe, etc.) ; les afficheurs quant à eux peuvent avoir des caractéristiques spécifiques à certains types d'affichage, ou être génériques ; de même les contrôleurs ont des contraintes topologiques (par exemple un bouton poussoir se trouve à un endroit bien précis) ; et les commandes disponibles doivent supporter les mêmes formats de données que les fonctions qu'elles sont censées supporter (nombre de bits, entiers, flottant, texte, etc.).

Troisième niveau :

Première optimisation.

En partant des solutions candidates associant les différentes actions requises par la configuration (cahier des charges) avec des actions physiquement implantées dans différents éléments domotiques, on peut rechercher, par exemple, l'élément physique Q le plus mentionné dans les solutions possibles calcules au niveau 2, et qui traite au moins une action nécessitant un nouvel élément physique, puis déterminer toutes les actions compatibles avec cet élément et sui seraient utilisables dans ce même élément physique sur des sorties différentes.

Le résultat donne alors une solution physique possible pour le traitement d'actions partageant de mêmes sorties, ainsi que d'autres actions utilisant d'autres sorties à l'intérieur d'un même appareil physique.

Le processus peut ainsi être répété pour toutes les actions requérant un nouvel élément physique, et n'ayant pas déjà été traité. Puis quand ce dernier cas n'est plus disponible, considérer un cas non traité restant et requérant de nouvelles sorties comme une action nécessitant un nouvel élément physique. Le processus s'arrête quand tous les cas enregistrés dans les tables intermédiaires ont été traités. Quatrième niveau :

Deuxième optimisation.

Pour chacune des solutions trouvée au niveau 3, on peut alors chercher de la même manière des solutions (c'est-à-dire des éléments physiques répondant aux critères demandés dans le cahier des charges) qui incluent les mêmes actions que chaque élément Q, à la fois sur de mêmes sorties et sur des sorties différentes, et effectuer une comparaison basée sur des facteurs pondérés permettant de déterminer si la nouvelle solution Q' est meilleure (au sens des critères de préférences choisi pour le projet que la solution Q.

Le processus peut ensuite être répété, d'abord pour la solution Q1 , puis pour toutes les solutions Qn envisagées à l'étape 3.

Les différentes étapes décrites ci-dessus doivent bien sûr être appliquées aux fonctions, commandes, afficheurs, contrôles (c'est-à-dire fonctions implantées dans des contrôleurs) requises par la configuration établie au départ par l'intermédiaire du GUI (décrit dans les Fig 7 à 14) par l'utilisateur/installateur, en prenant en considération que les fonctions sont toujours implantées dans des actionneurs, alors que commandes, afficheurs et contrôles sont implantées dans des contrôleurs.

A noter que n'ont pas été pris en compte dans la description les cas des commandes d'éléments multiples à partir de mêmes commandes, d'appareils aux fonctions déclenchées par plusieurs sources (commandes) possibles localisées en divers endroits, des scénarios logiques ajoutant d'autres sources possibles de commandes et d'affichages, etc., bien que ces cas fassent partie des algorithmes de choix d'éléments de l'invention.

Comme on a pu le voir dans les descriptions qui précèdent, le choix automatisé des éléments physiques ne consiste pas en un simple tri d'éléments à partir d'une base de données, mais est le fruit d'une longue recherche permettant de déterminer le meilleur compromis en termes de structures des données et d'algorithmes pour obtenir le résultat cherché en utilisant des ressources raisonnables.

Exemple concret

Un exemple est donné ci-après utilisant les méthodes de structuration des données et des algorithmes définis ci-dessus. La figure 27 donne un exemple d'une liste proposée par les algorithmes pour simplifier l'entrée des paramètres de configuration (cahier des charges). Dans la figure La figure 28, on voit de plus que la fonction « Retour ON/OFF » est proposée car la fonction Convect. ON/OFF a déjà été choisie et permet donc cette option. De même la fonction « Entrée T° Consigne Thermostat ^* (1 :2) » est proposée car le système a détecté qu'une commande de thermostat a déjà été requise (fonction#1 , commande #2) et permet donc de choisir cette option, qui est en fait un contrôle (c'est-à-dire une fonction physiquement disponible dans un contrôleur, et non dans un actionneur comme les fonctions usuelles).

La figure 29 donne un exemple du résultat de la configuration (cahier des charges) requise.

La figure 30 donne un exemple de table intermédiaire (liste partielle des colonnes) stockant les informations nécessaires aux algorithmes de choix d'éléments, ainsi qu'à la génération automatique de divers rapports et d'une maquette de télécommande.

La figure 31 donne un exemple de Résumé de la Configuration généré automatiquement à partir du cahier de charges, des bases de données et des algorithmes de sélection d'éléments physiques.

La figure 32 donne un exemple de Directives d'Installation générées automatiquement à partir du cahier de charges, des bases de données et des algorithmes de sélection d'éléments physiques. Dans cet exemple on voit que les algorithmes ont automatiquement choisi le même contrôleur physique (C1 ) pour commander les fonctions pour la lampe incandescente (même sortie n°1 ) et pour la fonction ON/OFF du radiateur (sortie, c'est-à-dire bouton, n°2 du même contrôleur). On voit également que les « fonctions » (en fait, des contrôles) d'Entrée et de Retour (affichage) de T° Consigne ont été sélectionnés dans le même contrôleur (C2), et non pas dans un actionneur.

La figure 33 donne un exemple de Directives de Programmation générées automatiquement à partir du cahier de charges, des bases de données et des algorithmes de sélection d'éléments physiques. Ici les adresses physiques des éléments physiques, ainsi que les adresses logiques des actions les concernant ont été automatiquement assignées, simplifiant considérablement le processus de programmation des éléments domotiques. La figure 34 donne un exemple d'Etude de Prix générée automatiquement à partir du cahier de charges, des bases de données et des algorithmes de sélection d'éléments physiques.

La figure 35 donne un exemple de Télécommande générée automatiquement à partir du cahier de charges, des bases de données et des algorithmes de sélection d'éléments physiques. On voit que les pièces ont été générées (en l'occurrence dans cette exemple une seule pièce, les types d'applications (icônes de chauffage et de lumière), ainsi que les graphismes permettant de piloter lampe et radiateur comme demandé dans le cahier des charges entré grâce au GUI décrit en Fig. A2.

Comme les personnes spécialistes de la domotique le comprendront aisément, les exemples traités dans les présents documents représentent l'intégralité de l'esprit et de l'étendue de l'invention. Des modifications supplémentaires, dont certaines sont décrites ici, intègrent de nouveaux aspects de la présente invention.

Bien que la présente invention ait été décrite conjointement avec des modes de réalisation spécifiques préférés ainsi que d'autres, il est évident que de nombreux remplacements, de nombreuses alternatives et variantes apparaîtront aux spécialistes de l'art à la lumière de la description précédente. En conséquence, l'invention a pour but de considérer l'intégralité des alternatives et des variantes qui viennent à l'esprit et qui tombent dans le cadre des revendications jointes. Par exemple, il convient de comprendre que, selon les différents autres modes de réalisation décrits dans les présents documents, différents systèmes, et utilisations ainsi que procédés basés sur ce système, peuvent être obtenus. Les différentes améliorations et caractéristiques supplémentaires et alternatives également décrites peuvent être combinées pour fournir des combinaisons avantageuses supplémentaires et similaires, selon la présente invention. Comme les spécialistes de la technique le comprendront en se fondant sur la description précédente, différents aspects des modes de réalisation préférés peuvent être utilisés dans différentes sous-combinaisons pour obtenir au moins certains des bénéfices et des attributs décrits dans ce document, et ces sous- combinaisons tombent également dans l'étendue de la présente invention.

Toutes ces améliorations, et autres utilisations de la présente invention tombent dans le cadre de la présente invention.