METHOD FOR CONFIGURATION, MONITORING AND CONTROLLING AT LEAST ONE HOME AUTOMATION SYSTEM IN A BUILDING

Description

[0001] The present invention relates to a method for configuring, controlling and / or supervising a home automation system.

[0002] It is known to control and / or supervise a home automation system through a multitude of communication protocols.

[0003] Thus, the non-exhaustive list of protocols to consider for the control and / or supervision of an installation includes: Z-Wave, EnOcean, IO Homecontrol, Somfy RTS, KNX, MODBUS, Wavenis, Philips HUE as well as other proprietary protocols.

[0004] The protocols commonly used exhibit significant differences. In particular, different protocols may employ different mechanisms for logically partitioning devices. Thus, a physical device with multiple functions can be modeled as a single logical device or as a plurality of logical devices.

[0005] Depending on its type, a device can be in different states. For example, a state might be on or off for a switch, or a degree or percentage of openness for a shutter. Device state descriptions can be generic or specialized, depending on the local protocol. State variable identifiers can be numeric or alphanumeric. State variable values ​​can use custom or proprietary formats or scales.

[0006] Devices are capable of interpreting and executing commands. Device command descriptions can be generic or specialized, and command identifiers can be numeric or alphanumeric. Commands may have parameters, the values ​​of which can use custom or proprietary formats or scales.

[0007] The local communication protocols used can be unidirectional, bidirectional in the form of a request / response exchange, or bidirectional using an event-driven approach. These protocols use a proprietary format, usually binary.

[0008] Thus, the lack of standardization in local communication protocols of devices makes it difficult to remotely control and supervise heterogeneous home automation installations.

[0009] The document MARC-OLIVIER PAHL ET AL: “Knowledge-based middleware for future home network,” WIRELESS DAYS (WD), 2009 2ND IFIP, IEEE, PISCATAWAY, NJ, USA, December 15, 2009, ISBN: 978-1-4244-5660-4, describes an abstraction for the software orchestration of smart spaces. The goal is to facilitate the programming of orchestration software without limiting its functionality. More specifically, the document MARC-OLIVIER PAHL ET AL describes a “Knowledge Agent (KA)” that can be used as a “node-exchanging point” or “proxy for the slow-link devices.”

[0010] The present invention aims to resolve all or part of the drawbacks mentioned above.

[0011] The embodiments relating to a supervision method and a control method are not part of the invention and are present only for illustrative purposes.

[0012] To this end, a method for supervising at least one home automation system in a building is described, the home automation system comprising a plurality of home automation devices, each home automation device being represented by at least one instance of a generic device model and at least one instance of a low-level device model; the method being executed by a management unit connected to at least one home automation system and comprising the following steps: i. Receiving a status notification message from a central control unit of a home automation system containing information about at least one low-level state variable of a home automation device; ii. Determining at least one low-level device model instance representing the home automation device; iii. Determining a state conversion that converts at least one low-level state variable into at least one generic state variable based on at least one state conversion rule selected according to the at least one low-level state variable or its type; iv. Determining at least one generic device model instance for the at least one low-level device model instance determined in step ii; v.Update at least one generic state variable of at least one instance of generic device model determined in step iv based on the state conversion determined in step iii.

[0013] It should be noted that step iii can be carried out before step ii or after step iv depending on the embodiments considered.

[0014] Thanks to the provisions according to the invention, it is possible to carry out supervision, in particular remote supervision, of the home automation installation in a uniform manner regardless of the local communication or control protocol used to supervise the home automation devices.

[0015] Thus, the generic device model is a protocol-independent model that allows for the functional description of building devices.

[0016] It should be noted that the term home automation device refers to home automation equipment and / or a sensor, or a part of home automation equipment or a part of a sensor corresponding to a functional subset.

[0017] Furthermore, a message is understood to be an element of information notified or received in the form of a synchronous or asynchronous call to the management unit, which may also correspond to a local or remote function call.

[0018] According to one aspect of the invention, each instance of a generic device model includes an indication of membership in a class or type of generic device model.

[0019] According to one aspect of the invention, each instance of a low-level device model includes an indication of membership in a class or type of low-level device model.

[0020] According to one aspect of the invention, each instance of a low-level device model includes an indication of a type of local communication protocol recognized by the home automation device.

[0021] Processing the information stored in this low-level model for a given device requires knowledge of the specific protocol and data format for that device. According to one aspect of the invention, this model may have a common structural format for different types of low-level devices, but the types of attributes, state variables, and commands defined in this model are not generic.

[0022] The conversion between the generic model and the low-level model is carried out on the basis of a set of predefined model conversion rules, which are notably recorded on the management unit and allow to provide an abstraction of devices for applications or users.

[0023] According to one aspect of the invention, the management unit is a server remotely connected to at least one home automation installation, via a wide area network.

[0024] According to another aspect of the invention, the management unit is a central unit intended to be connected to one or more central control units on separate private or local networks, or even on the same local network.

[0025] According to one aspect of the invention, the selection of a state conversion rule based on the low-level state variable is carried out on the basis of the type of the state variable and the type of low-level device.

[0026] According to one aspect of the invention, the state conversion rules are stored in association with the following data: a generic identifier or variable name; a generic device type; a low-level identifier or variable name;

[0027] According to one aspect of the invention, a state conversion rule defines the correspondence between an identifier of a low-level state variable and an identifier of a generic state variable, as well as a conversion rule between the value of a low-level state variable and a value of a generic state variable.

[0028] According to one aspect of the invention, the method includes a step of updating the value of the low-level state variable and storing that value.

[0029] According to one aspect of the invention, the generic device model instances are only partially stored persistently. The values ​​of the generic state variables are recalculated from the data of the low-level model instances based on state conversion rules.

[0030] According to one aspect of the invention, the method further comprises a step of sending a communication message of at least one updated generic state variable value GS to a user terminal or an application running on the management unit or on another connected management unit.

[0031] This communication can be initiated by the user or the application, or not. According to one aspect of the invention, a notification and subscription system can be implemented.

[0032] It should be noted that by another connected management unit, it is understood that another management unit is present on the same local network or on another local network with a connection to the management unit executing the monitoring process.

[0033] According to one aspect of the invention, the step of determining the low-level device model instance includes determining an indexing key based on identification elements contained in the message or determinable upon receipt of the message, the combination of which allows for the unique identification of a home automation device.

[0034] According to one aspect of the invention, the various identification elements, taken individually, are not necessarily unique for each device; however, the combination of two or more information elements must be. Examples of identification elements include the identifier of the central control unit to which the home automation device is connected, the address of the home automation device, or possibly that of its parent device in a hierarchical addressing system within the local network managed by the central control unit.

[0035] Also described is a method for controlling at least one home automation system in a building, the home automation system comprising a plurality of home automation devices, each home automation device being represented by at least one instance of a generic device model and at least one instance of a low-level device model; the method is executed by a management unit connected to at least one home automation system and comprises the following steps: i. Receiving a command message from a user or application on the central management unit or another connected management unit, the command message corresponding to a generic command relating to a home automation device; ii. Determining at least one instance of a generic device model representing the home automation device; iii. Determining at least one instance of a low-level device model for the at least one instance of a generic device model determined in step ii; iv. Determining a command conversion that converts the at least one generic command into at least one low-level command based on at least one command conversion rule selected according to the at least one generic command or its name. v.Sending at least one low-level command message including at least one low-level command corresponding to the command conversion determined in step iv to a central control unit of the home automation installation so as to trigger the execution of at least one actual command corresponding to at least one low-level command on the home automation device corresponding to the low-level instance determined in step iii.

[0036] It should be noted that step iv can be performed before or after step iii, depending on the embodiments considered. If step iv is performed before step iii, information relating to the local protocol may be used in addition to the information concerning the generic command. This information concerning the local protocol may be obtained from an identifier of the generic device model instance.

[0037] Thanks to the provisions of the invention, it is possible to control, particularly remotely, the home automation system in a uniform manner, regardless of the local communication or control protocol used to control the home automation devices. It is thus possible, for example, to provide a common programming interface for controlling all real home automation devices sharing the same generic model, irrespective of the local protocol and the underlying low-level device.

[0038] By another connected management unit, we mean another management unit present on the same local network or on another network with a connection to the management unit executing the process.

[0039] According to one aspect of the invention, the command conversion rule is selected based on at least one generic command or its name, and a type of low-level device corresponding to at least one instance of a low-level device model determined in step iii.

[0040] According to one aspect of the invention, the order conversion rules are stored in association with the following data: a type of low-level device; a generic command name or identifier.

[0041] According to one aspect of the invention, the selection of the command conversion rule is performed using the local communication protocol type and the generic command name or identifier.

[0042] According to one aspect of the invention, the command conversion of at least one generic command applicable to at least one instance of the generic model into at least one low-level command corresponds to a combination of a plurality of low-level commands, and the sending step corresponds to sending a plurality of commands to the central control unit so as to trigger the execution of a combination of a plurality of actual commands on the device.

[0043] According to one aspect of the invention, the method further comprises the following steps: storing in memory the correspondence between said generic command and the plurality of low-level commands; and determining a result of the generic command based on the results of the corresponding low-level commands.

[0044] Thanks to these provisions, it is possible to determine an overall order result on the original generic order by aggregating order results received for each low-level order executed.

[0045] According to one aspect of the invention, the generic command is considered to have been executed if all the low-level commands have been successfully executed, and not executed if one or more low-level commands have failed.

[0046] According to one aspect of the invention, the protocol-specific error codes are translated into generic error types.

[0047] The present invention relates to a method for configuring at least one home automation system in a building, the home automation system comprising a plurality of home automation devices, each home automation device being represented by at least one instance of a generic device model and at least one instance of a low-level device model; the method is executed by a management unit connected to at least one home automation system and comprises the following steps: i. Receiving a configuration message issued from a central control unit of a home automation system or a user terminal, the message containing an indication of the commissioning, configuration, or reconfiguration of a home automation device. ii. Determining at least one low-level device model class or type corresponding to the home automation device; iii. Creating at least one low-level device model instance based on the low-level device class or type defined in step ii and corresponding to the home automation device. iv. Determining a model conversion that converts a low-level device type or class into at least one generic device model class or type based on a model conversion rule selected according to the low-level device model instance determined in step iii or its type. v.creation of at least one instance of generic device model for at least one instance of low-level device model based on at least one type or class corresponding to the model conversion determined in step iv.

[0048] According to one aspect of the invention, instances of generic device models are recorded in association with the low-level device model instance.

[0049] According to one aspect of the invention, the model conversion rules are stored as an association between: a type of low-level device; at least one type or class of generic device corresponding to GDT.

[0050] According to one aspect of the invention, the method further comprises the following steps: Sending a communication message of the configuration of at least one device to a user terminal or an application running on the management unit or on another connected management unit.

[0051] This communication can be initiated by the user or the application, or not. According to one aspect of the invention, a notification and subscription system can be implemented.

[0052] By another connected management unit, we mean another management unit present on the same local network or on another network with a connection to the management unit executing the process.

[0053] According to one aspect of the invention concerning the configuration method, the control method and the supervision method previously described, the determination of at least one instance of generic device model for the at least instance of low-level device model corresponds to a determination of a group of instances of generic device models.

[0054] These provisions allow for the generic representation of a complex real-world device offering multiple functions. In such a case, instances of generic device models, and devices related to the same low-level device model instance, are called subsystems.

[0055] This is particularly true because the functional coverage of a low-level device model can vary depending on the protocols considered. Thus, a low-level device model can cover either a single function or multiple functions within a complex system. For example, a heating system might functionally cover on / off / heating control commands, which correspond to a first instance of a generic device model of type "heating system." This heating system might also include one or more temperature sensors, possibly located at different positions, which could correspond to instances of another generic device model related to a "sensor" type or class.

[0056] It is therefore possible to define a control scenario including a command intended for a first real device using a device corresponding to a second real device, such as a sensor belonging to the second real device.

[0057] This arrangement allows these parts of the device or subsystems to be used separately, logically and functionally.

[0058] According to one aspect of the invention, each instance of a generic device model includes a unique generic device identifier.

[0059] Thanks to these provisions, the description produced is independent of the local communication protocol or the implementation details of the actual device and the underlying low-level device model instance.

[0060] According to one aspect of the invention, the generic device model defines a set of commands or functions associated with said model.

[0061] According to one aspect of the invention, the generic device model defines a set of states or state variables associated with said model.

[0062] According to one aspect of the invention, the generic device model defines a set of attributes associated with said model.

[0063] According to one aspect of the invention, the names of the states or state variables attached to a generic device model are explicit.

[0064] According to one aspect of the invention, the values ​​of state variables attached to a generic device model are normalized.

[0065] According to one aspect of the invention, the names of the commands attached to a generic device model are explicit.

[0066] According to one aspect of the invention, the control parameters attached to a generic device model are standardized.

[0067] According to one aspect of the invention, the unique identifier of the generic model instance can be constituted in particular by an identifier using in particular a protocol-independent address notation, for example in a URL-type format.

[0068] According to one aspect of the invention, each instance of a low-level device model further comprises a unique low-level device identifier in the local network associated with a central control unit of a home automation system.

[0069] According to one aspect of the invention, the low-level device model defines a set of commands or functions associated with said model.

[0070] According to one aspect of the invention, the low-level device model defines a set of states or state variables associated with said model.

[0071] According to one aspect of the invention, the low-level device model defines a set of attributes associated with said model.

[0072] According to one aspect of the invention, each instance of a low-level device model comprises a device type or class;

[0073] According to one aspect of the invention, each instance of a low-level device model includes a type of protocol used in the local network

[0074] According to one aspect of the invention, a low-level device model instance RD can be associated with one or more low-level commands with: a command name or identifier; and one or more low-level parameters.

[0075] According to one aspect of the invention, the command description is not stored in the instances, but can be determined based on the type of low-level device and / or the type of protocol used in the local network. In particular, a low-level command can be determined based on a command conversion rule.

[0076] According to one aspect of the invention, a reference meta-model is maintained to store common information about low-level device models, their state variables, and attached commands, namely: The types of low-level devices supported and their names; The low-level state variables supported with their RSID identifiers and the data types for the values; The profiles describing the relationship between the types of low-level device models and the allowed state variable values.

[0077] According to one aspect of the invention, this reference meta-model is shared in the architecture to enable integrity checks and proper handling of state variable values ​​of low-level device model instances when knowledge of the data type is required, without needing to store this information for each low-level device model instance.

[0078] According to one aspect of the invention, the unique generic device identifier includes a logical device address that establishes a correspondence between at least one instance of a generic device model and an instance of a low-level device model.

[0079] According to one aspect of the invention, the device's logical address comprises: a type of communication protocol for the device; a communication path to the device.

[0080] According to one aspect of the invention, the communication path to the device includes any intermediate central control units and termination addresses to be traversed, preferably arranged according to a hierarchical topology.

[0081] According to one aspect of the invention, the device's logical address further comprises: A subsystem identifier if the generic device model instance belongs to a group of generic device model instances associated with the same underlying low-level device model instance.

[0082] The present invention also relates to a computer program product comprising code instructions arranged to implement the steps of a process as detailed above, when said program is executed by a processor.

[0083] The following embodiment is not part of the invention and is presented only by way of illustration, such as a system comprising a management unit arranged to perform one of the processes detailed above, connected to a central control unit of a home automation installation.

[0084] The arrangements described above allow for the availability of low-level information about devices at the management unit level, and simultaneously, high-level data. This achieves an abstraction effect without sacrificing the technical information of the underlying home automation protocols. This enables: maintain a more concise, generic model presented to services and interfaces; retain knowledge of the low-level specificities of each device.

[0085] These provisions can, for example, be implemented to: The product pairing phase: indeed, the procedures can be specific depending on the protocol, the manufacturer, or even the product version. The implementation of diagnostic services requires access to technical specifications and proprietary functionalities depending on the product model. The ability to reconfigure a product using information stored in this layer, and in particular, to allow the replacement of a defective product without going through all the pairing phases again.

[0086] The various aspects defined above, which are not incompatible, can be combined.

[0087] The invention will be better understood with the aid of the detailed description set forth below opposite the accompanying drawing in which: There figure 1 is a schematic view of a building and a home automation system according to an embodiment of the invention; The figure 2 is a diagram showing the architecture of a system including the home automation installation illustrated in the figure 1 as well as a server intended to be connected to a user terminal; The figure 3 is a diagram representing an abstract system of home automation devices. figure 4 is a diagram representing a low-level device model. figure 5 is a diagram representing a generic device model. figure 6 is a diagram illustrating a method for implementing a configuration process for a home automation system according to the invention. figure 7 This is a diagram illustrating a method for implementing a monitoring process for an unclaimed home automation system. figure 8 is a diagram illustrating a method of implementing a control process for an unclaimed home automation installation.

[0088] In the detailed description that will follow of the figures defined above, the same elements or elements fulfilling identical functions may retain the same references in order to simplify the understanding of the invention.

[0089] As illustrated in the figure 1 Building 1, for example, includes three rooms P1, P2, P3. Building 1 also includes home automation equipment 3 and sensors 5.

[0090] A home automation device 3 can be an actuator arranged to move or adjust an element of the building 1, for example an actuator 7 to move a roller shutter 9 or a terrace blind 19, or a control system 10 for a heating 11 or an air handling system 13. A home automation device 3 can also be a lighting, for example outdoor terrace lighting 21 or a lighting control system, or even an alarm system.

[0091] The home automation installation 17 may also include a control point 15 of an actuator 7, such as a wireless control box B for the roller shutter 9.

[0092] The home automation system 17 may include one or more sensors 5, integrated with an actuator 7, a control point 15, or the control unit B, or independently of these elements. A sensor 5 may, in particular, be configured to measure a physical quantity, for example, a temperature sensor, a sunlight sensor, or a humidity sensor. Position sensors 5 for home automation equipment 3 in building 1, such as sensors for the open status of a roller shutter 9 or position sensors for an opening such as a window, motorized or not, may also be included. The home automation system may also include one or more presence sensors.

[0093] A home automation device 3 and a sensor 5 are thus to be considered as units having at their disposal information on actual observed states of elements of building 1 and being able to share this information with other elements of the home automation installation 17.

[0094] Home automation equipment 3 and sensors 5 can thus have access to any measurable physical quantity, such as the temperature of each room P1, P2, P3 or a state of an element of the building 1, such as the open state of a roller shutter 9, the status of an alarm, etc.

[0095] The home automation system 17 includes a central control unit U designed to remotely control and / or manage all or part of the home automation devices 3, notably using a wireless communication protocol, such as a radio communication protocol. The central control unit is designed to collect and process all the data from the home automation devices 3.

[0096] The devices belong to a local network within the home automation system and communicate using a local communication protocol. They have a local address within this network. The logical devices can be modeled as nodes or endpoints in the local network.

[0097] The local addressing system can be hierarchical or flat, and the address format can be numeric or alphanumeric.

[0098] As depicted on the figure 2 The central control unit U is configured to communicate with an Sv server.

[0099] The central control unit U is located on a private network PN, PN', access to which is generally protected by a firewall (FW). The server Sv is also located on a private network SN. The private network PN is connected to a wide area network N, for example, the Internet.

[0100] In particular, the central control unit U of the home automation system 17 includes a processing unit 2 arranged to contain and execute a first computer program. figure 2 represents two central control units (U) arranged on two private networks corresponding to different home automation installations. Naturally, the Sv server is configured to communicate with a set of such central control units (U). We will describe one of these units later.

[0101] As an example, processing unit 2 includes a processor, flash storage memory, RAM, and an Ethernet chip.

[0102] The central control unit U also includes at least one communication module 2' intended for the control and / or command of home automation equipment 3 and / or sensors 5, the home automation equipment 3 being able to be actuators 7, lights 21 or an alarm system.

[0103] For example, as shown on the figure 2 The communication module 2' allows the control and command of at least one actuator 7, a moving element of the building 1, such as a roller shutter 9, or an adjustable sunshade 9', or other actuators 7, or lighting 21, as previously described with reference to the figure 1 .

[0104] As an example, the communication module 2' can be arranged to implement, for example, one or more of the following protocols: Z-Wave, EnOcean, IO Homecontrol, Somfy RTS, KNX, MODBUS, Wavenis, Philips HUE.

[0105] The system also includes the ability to receive information from a sensor 5 that provides user presence data or environmental parameter values ​​such as temperature, humidity, and brightness. Similarly, the central unit U can enable the control and / or command of an alarm system.

[0106] Each central control unit U also includes a communication module 4 with the server Sv. The server Sv enables remote command and / or control and includes one or more processing units 102 arranged to contain and execute a second computer program.

[0107] The Sv server also includes at least one communication interface 104 for communication with the central unit U.

[0108] The Sv server may also include a communication interface 106 intended for communication with a command and / or control interface IN allowing a user to remotely control the home automation installation.

[0109] It should be noted that the term server is a logical designation that can cover the use of several physical servers to distribute the computer processing load to be performed.

[0110] The command and / or control interface IN includes, for example, a web server 107 and a mobile communication terminal T communicating via the wide area network N. The mobile communication terminal T can be, for example, a smartphone or a tablet.

[0111] The command and / or control interface IN includes a processor which can be arranged at the level of the web server 107 and / or the mobile communication terminal T.

[0112] The command and / or control interface (IN) processor is configured to use a third computer program. This third computer program is configured to run a downloadable application.

[0113] The mobile communication terminal T includes a data input device and a display device, for example in the form of a touch control part of a screen of the terminal T and in the form of one or more buttons of the terminal T.

[0114] According to one aspect of the invention, and as shown in the figure 3 The processing unit of server 102 is configured to implement an abstraction system for the command and / or control of devices, home automation equipment, or sensors. Hereafter, we will use the designation "device D" interchangeably to refer to sensors, home automation equipment, or parts of home automation equipment 3 or sensors 5.

[0115] As depicted on the figure 3 The proposed system of abstraction implements: A plurality of RDM low-level device models intended for storing information in a specific format of a protocol on a given real device D, only one model being represented on the figure 3 A plurality of high-level generic device models (GDMs) allowing the description of real devices D, their states S, and commands C in a protocol-independent manner, with only one model being represented on the figure 3 ; ; and A plurality of PD protocol drivers that implement the necessary conversions to move from one model to another and form a PAL protocol abstraction layer.

[0116] As depicted on the figure 4 The low-level device model allows information about devices and their state to be stored in a format close to their native communication protocol format.

[0117] Processing the information stored in this model for a given device requires knowledge of the specific protocol and data format for that device. According to one aspect of the invention, this model may have a common structural format for different types of low-level devices, but the types of attributes, state variables, and commands defined in this model are not generic.

[0118] Each RD instance of a low-level RDM model corresponds to an addressable node in the local network to which it belongs and in which it communicates according to the target protocol. The node acts as an endpoint. Such a node can correspond to a physical device or a part of a device (a functional subset).

[0119] A low-level model RD instance includes: A low-level template instance identifier (RDID), which may include, in particular, a termination address on the local network. A type or class of RDT device; A type of RDPT protocol used on the local network.

[0120] The RDID identifier or address is used as a communication address or as a routing path. This address is unique, at least within the local network to which device D belongs.

[0121] RDT-type information can be obtained directly from the home automation device D, but it may be necessary to use external reference tables or even user-provided information to determine the exact device type. If this information is requested from the user, the RDT information can be requested only once during the product configuration / pairing phase and then stored in the RD instance, specifically in the IDB database, which will be described later.

[0122] Furthermore, each low-level RD model instance can exhibit: One or more RA attributes; One or more RS state variables;

[0123] An RA attribute is defined by a RAN attribute name and a RAV value. RA attributes represent, for example, additional type and / or configuration information obtained during the pairing phase. These attributes are information that remains unchanged after pairing.

[0124] An RS state variable is defined by a unique RSID identifier within the scope of the relevant RDM low-level device model, and by an RSV value. RD low-level device model instances with RS state variables can allow queries about their state and / or send notifications when the RSV state variable value changes.

[0125] A low-level RD device model instance can also have a parent address, RDPID. The parent RDPID allows low-level RD device model instances of the same protocol to be organized into a hierarchical node tree. This is useful for protocols where a hierarchical topology is necessary for routing information to nodes, or in cases where a device cannot exist without a parent.

[0126] Thus, the set of RD instances of an installation 17 can form a list or a tree of nodes, in the case of a hierarchical topology, depending on the protocols used.

[0127] As indicated on the figure 3 , a reference meta-model RMM is maintained to store common information about low-level device models RDM, their RS state variables and attached RC commands, namely: The supported RT low-level device types and their names; The supported RS low-level state variables with their RSID identifiers and the data types for RSV values; The profiles describing the relationship between the RDM low-level device model types and the allowed RS state variable values.

[0128] This RMM reference meta-model is shared in the architecture to enable integrity checks and proper handling of RSV state variable values ​​of RD low-level device model instances when knowledge of the data type is required, without needing to store this information for each RD low-level device model instance.

[0129] As depicted on the figure 5 The generic device model GDM is a protocol-independent model that allows for the functional description of building devices.

[0130] In particular, a generic device model (GD) instance includes: A unique identifier for the generic GDURL model instance, which may consist in particular of an identifier using, for example, a protocol-independent address notation, such as a URL-type format; A type or class of generic GDT device;

[0131] Furthermore, each instance of the generic GD model can exhibit: One or more GA attributes; One or more GS state variables.

[0132] A GA attribute is defined by a GAN attribute name and a GAV value. GA attributes represent, for example, additional type and / or configuration information obtained, for instance, during the pairing phase.

[0133] A GS state variable is defined by a unique identifier or name (GSID) within the scope of the relevant generic device model (GDM), and by a GSV value. Instances of generic device models (GDM) with GS state variables can allow queries about their state and / or send notifications when the GSV value changes.

[0134] A generic device model instance (GD) can have at least one state variable (GS). This state variable has an explicit state identifier or name (GSID) predefined by the model in question, and a state variable value (GSV), selected from several predefined values ​​or belonging to a range of state variable values ​​predefined by the model in question.

[0135] Furthermore, a generic device model (GD) instance can be associated with one or more generic commands (GC) with: an explicit GCID command name; and one or more normalized GCP parameters.

[0136] The supported commands are defined by the generic device model GDM.

[0137] This description is independent of the actual protocol or implementation details of an underlying low-level RDM device model.

[0138] As an example, a roller shutter can be modeled by an instance of a generic device model (GD) defined as follows: GDT Class or Type: "Positionable Roller Shutter"; GS State Variable: "Closure State" (ClosureState) which can take values ​​on a normalized scale from 0 to 100%; Supported GC Generic Command: "SetClosure" (SetClosure) with an opening parameter (amount) which can take values ​​on a normalized scale from 0 to 100%.

[0139] A generic device model (GD) instance is implicitly linked to at least one underlying low-level device model (RD) instance. In practice, this link can be modeled by the unique identifier of the generic model instance, GDURL, which corresponds to a device address and serves as both a unique identifier and a pointer to the underlying low-level device model instance. The implementation of the link or indexing key will be detailed later.

[0140] It should be noted that in some cases, one instance of a low-level device model RD may correspond to several instances of high-level models GD.

[0141] This is particularly true because the functional coverage of a low-level device model can vary depending on the protocols considered. Thus, a low-level device model can cover either a single function or multiple functions within a complex system. For example, a heating system might functionally cover on / off / heating adjustment commands, which correspond to a first instance of a generic device model (GD) of type "heating system." This system might also include one or more temperature sensors, possibly located at different points within the home automation installation, which could correspond to instances of another generic device model (GD) related to a "sensor" type or class.

[0142] The designed abstraction system allows for the modeling of multiple instances of generic device models (GD) based on the same real device and the same underlying low-level device model instance (RD).

[0143] In such a case, instances of generic device models GD related to the same low-level device instance RD can be called subsystems.

[0144] In cases where several home automation devices (D) are grouped according to their native protocol—for example, a set of shutters on a building's facade—it is possible to create a virtual low-level device model instance (RD) to represent the group in a format close to its native protocol. This virtual low-level device model instance (RD) can then be linked to one or more generic device model instances (GD). This way, a correspondence can be maintained between at least one generic device model instance (GD) and one low-level device model instance (RD).

[0145] The structure of the unique identifier of a generic GDURL model instance will now be described in a manner corresponding to a particular embodiment.

[0146] According to this embodiment, the unique identifier of a GDURL generic template instance includes information about: The local native protocol of the home automation device D; the communication path to the device D, including intermediate control units U and termination addresses to be traversed, whether or not organized in a hierarchical topology; a subsystem identifier subsystemld if the device belongs to a group of generic device model instances GD associated with the same underlying low-level device model instance RD. Devices that are a single expression of a low-level device model instance GD do not have a subsystem identifier extension.

[0147] Thus, the form of the unique identifier of a GDURL generic template instance can be the following: <protocol> : / / <gatewayld> / <rawdeviceaddress> (# <subsystemld>)

[0148] In which the following fields are present: protocol: identifier of the native device's local protocol; gatewayld: identifier of the first central control unit U, for example, a serial number or a unique identifier. rawDeviceAddress: a simple or multilevel path. Its meaning and format depend on the addressing scheme of the device's local communication protocol D. subsystemld: this optional field indicates an identifier, for example, a subsystem rank (starting, for example, at 1), if such a subsystem is present. Exemples: 1) knx: / / 0201-0001-1234 / 1.1.3

[0149] This unique identifier of a generic device model instance GDURL corresponds to a device D communicating via the KNX protocol with an individual address 1.1.3 accessible by the central control unit U bearing the identifier #0201-0001-1234. 2) io: / / 0201-0001-1234 / 145036#2

[0150] This unique identifier of a generic model instance GDURL corresponds to a subsystem bearing the number 2 associated with a device D communicating via the io homecontrol protocol with a radio address 145036 accessible by the central control unit U bearing the identifier #0201-0001-1234.

[0151] The manipulation of the various low-level device model (RD) and generic device (GD) instances is performed by an execution process or service (ES). To store the aforementioned model instances, the execution service may access an instance database (IDB). Of course, these different types of instances can also be stored separately. Furthermore, a database here refers to a suitable storage method for a set of instances, which can be stored in a list, a tree, tables, or any other appropriate data structure.

[0152] One implementation of the IDB database will now be described. According to this implementation, the IDB database can contain tables organized as arrays. Each row corresponds to an instance of a home automation device model, either low-level (RD) or generic (GD), depending on the table. The columns correspond to the different types of information stored.

[0153] Thus, an RDTbl table of RD low-level device model instances may contain columns including the following data: I - the identifier of the central control unit U to which a home automation device is attached UID; II - the address of the home automation device in the local network managed by the central control unit RDID; III - the type of local protocol used RDPT; IV - type of low-level device model RDT, corresponding for example to a designation of roller shutter or lighting.

[0154] A unique RDK indexing key is used for each home automation device. This unique RDK indexing key can be generated from the three elements I, II, and III listed above; it can be stored in each table. Alternatively, the RDK indexing key can be an identifier that auto-increments as data is entered into the IDB database.

[0155] According to yet another possibility, the RDK indexing key can be calculated at each access, starting from elements I, II, possibly III.

[0156] Generally, when an indexing key is calculated, this calculation can be based on identifying elements. The combined identifying elements must allow for the identification of a single low-level home automation device (RD).

[0157] Note that the individual identification elements are not necessarily unique for each device, but the combination of two or more pieces of information must be. Examples of identification elements mentioned above include the UID of the central control unit U to which the home automation device D is connected, the RDID of the home automation device, or possibly that of its parent in a hierarchical addressing system within the local network managed by the central control unit U.

[0158] These two elements are sufficient for unambiguous identification of the home automation device. Other identifying elements can be used, such as the type of local protocol used by the device. This additional identifying element allows for the rapid selection of the relevant RD and GD instances, and the PD protocol driver to execute, since a PD protocol driver is specific to a native protocol type.

[0159] It should be noted that, in the case where the indexing key is calculated at each access, the same information may be present in identification elements in different formats.

[0160] An example of an RDTbl table row is reproduced below. UID RDID RDPT RDT 0201-0001-1234 120403 IO 0x0100202

[0161] This line corresponds to a table in which the RDK indexing key is calculated and not stored, for a device connected to a central control unit bearing the identifier 0201-0001-1234, the device being identified by its radio address IO 120403 on the local IO network, the type of local protocol used being IO homecontrol, the type of low-level device model being 0x0100202, which corresponds according to an implementation to a roller shutter with low-speed management from the manufacturer SOMFY.

[0162] Other information, such as the names of RSID state variables, the values ​​of RSV state variables, binary flags (TRUE / FALSE) for currently executing commands, etc., can be stored in different tables or in the same table. If different tables are used, the unique RDK indexing key for each low-level RD device model instance ensures the mapping between the stored information and the relevant device.

[0163] A GDTbl table of GD generic device model instances may include columns containing the following data: I - the unique identifier of a generic model instance GDURL; II - the class or type of generic device GDT.

[0164] Thus, an example of a GDTbl table row, corresponding to the previously illustrated example of an RDTbl table row, is reproduced below. GDURL GDT io: / / 0201-0001-1234 / 120403 RollerShutterWithLowSpeedSupport

[0165] This line relates to a generic device model instance GD corresponding to the low-level device model instance RD represented in the RDTbl example table shown previously.

[0166] Other information, such as the names of GSID state variables and the values ​​of GSV state variables, can be stored in separate tables or in the same table. It can be useful to associate other information with generic device model instances, such as a name or the physical location of device D within the installation. However, this information may not be readily available and is typically defined by the installer or user.

[0167] A unique GDK indexing key, representing a given home automation device, can be stored in the table.

[0168] As with the low-level instance table, the indexing key can be calculated on each access. For accessing the generic model instance table, it can be useful to calculate this GDK key from the GDURL identifier, for example, by directly using this identifier as the key.

[0169] Instances of low-level RD and generic GD models are computed and / or stored with the same GDK or RDK indexing key value, optionally adding a subsystem identifier in cases where multiple instances of generic GD devices correspond to a single instance of low-level device model.

[0170] In one implementation, generic device model (GD) instances are only partially persistently stored. Specifically, only device GDURL identifiers and GDT classes or types are persisted. GA attributes and GS state variables are recalculated from the data in the low-level model instances, as will be described later.

[0171] The PD protocol drivers identified on the figure 3 will now be described. Protocol drivers implement the core logic of the abstraction layer, namely the various conversion rules between the two generic, low-level models. There can be one protocol driver (PD) per supported protocol type, although different drivers can share common functionalities, building upon existing implementations.

[0172] Each PD protocol driver can perform a set of conversion operations. To perform the various conversions mentioned below, a protocol driver can be associated with a conversion rule database (RDB) containing the different types of conversion rules mentioned below: model conversion rules (MCR); state conversion rules (SCR); and command conversion rules (CCR). These different types of rules can also be stored separately. Furthermore, a database here refers to a suitable storage method for a set of rules, which can be stored in a list, a tree, tables, or any other appropriate data structure. It should be noted that the MCR, SCR, and CCR conversion rules are stored or recorded independently of the instances.These provisions make it possible to limit the volume of conversion information that is not duplicated for each model instance.

[0173] In particular, a PD protocol driver can perform a CvM model conversion, that is, the determination or selection of a generic device class or type, or a list of GDT classes or types, from a given low-level device model instance, based on at least one model conversion rule. If the low-level device model instance needs to be represented by multiple generic device model instances, the driver will return a list of such subsystems as the CvM model conversion. Specifically, the selection of a generic device class can use the type of a low-level device model instance but could also use other attributes in the selection process. This is useful, for example, for modular devices where an optional function may or may not be present.For example: the optional presence of an additional sensor for a heating system.

[0174] According to one embodiment, the PD protocol driver can determine the type or class of the generic GDT device model by consulting an MTbl table in its RDB database. For example, the MTbl table might include columns containing the following data: a type of low-level device RDT at least one corresponding generic device type or class GDT.

[0175] Two examples of GDT-type selection are described below. Exemple 1 :

[0176] We assume that the discovered or configured low-level RD device instance is defined as described in the table below. RDPT RDT RA RDID IO 0x0100202 - 120403

[0177] This line corresponds to a device identified by its radio address IO 120403 on an IO local network managed by a central control unit defined by UID identifier not shown, the type of local protocol used being IO homecontrol, the type of low level device model being 0x0100202, which corresponds according to an implementation to a roller shutter with low speed management from the manufacturer SOMFY.

[0178] This data is communicated as input to the PD protocol driver corresponding to the IO protocol. The protocol driver determines the type or class of the generic GDT device model by consulting the MTbl table in its RDB database. The selection allows you to identify an example of an MTbl table row, reproduced below. RDT GDT 0x0100202 RollerShutterwithLowSpeedSupport

[0179] Thus, the identified generic device type is "roller shutter with low-speed support". In this example, the low-level device type RDT is associated with a single generic device type that corresponds to the CvM model conversion. There are no subsystems. Exemple 2 :

[0180] We assume that the discovered or configured low-level RD device instance is defined as described in the table below. RDPT RDT RA RDID MODBUS 0x00101 'sensorAvailable'=true 4

[0181] This line corresponds to a device identified by its MODBUS 4 bus address on the MODBUS local network, the local protocol type used being MODBUS, the low-level device model type being 0x00101, which corresponds according to one implementation to a heating system with an optional outdoor temperature sensor.

[0182] This data is communicated as input to the PD protocol driver corresponding to the MODBUS protocol. The protocol driver determines the type or class of the generic device model (GDT) by consulting the MTbl table in its RDB database. The selection allows you to identify an example of an MTbl table row, reproduced below. RDT GDT 0x00101 HeatingSystemController OutsideAirTemperatureSensor (only if attribute 'sensorAvailable'=true)

[0183] Thus, the identified types of generic GDT devices are: “Heating System Controller” / (HeatingSystemController); and “Outside Air Temperature Sensor” / (OutsideAirTemperatureSensor).

[0184] In this example, the low-level device type RDT is associated with two generic device types that correspond to the CvM model conversion. Thus, the low-level model device instance RD will be associated with two generic device model instances GD, which form two subsystems: a main controller and a sensor. In this example, the sensor is optional but is present on the particular device under consideration. If the sensor were not present, for example, because it had not been installed, the protocol driver would have returned only one type, corresponding to a single subsystem: the main controller.

[0185] A PD protocol driver can also convert a low-level RS state variable into one or more generic GS state variables described in the generic device class GDT, based on at least one SCR state conversion rule. Thus, a protocol driver can determine the values ​​of the generic GS state variables of a GDT generic device model type from the values ​​of the low-level RS state variables corresponding to a given RSID.

[0186] According to one embodiment, the PD protocol driver can perform a CvS state conversion of a low-level RS state variable into one or more generic GS state variables by consulting an STbl table in its RDB database. For example, the STbl table might include columns containing the following data: a generic GSID identifier or variable name; a generic GDT device type; a low-level RSID identifier or variable name; a state conversion SCR rule between the value of a low-level RSV state variable and a value of a generic GSV state variable.

[0187] Two examples of RS low-level state variable conversion are described below. Exemple 1 :

[0188] We assume that a message is received from a central control unit U of a home automation installation 17 containing an indication of a change in the value of a state variable S of the device defined in the way described in the table below. RDPT RDID RSID RSV MODBUS 1234 0x0C213 123

[0189] This message corresponds to the update of the RSID status variable 0x0C213 corresponding to the regulation mode of a heating system type device at address RDID 1234 of its local network communicating according to the local protocol RDPT MODBUS, the new value RSV being 123.

[0190] The MODBUS protocol PD driver can, on this basis, perform the conversion by selecting an SCR state conversion rule or conversion function using the low-level device type RDT (not shown) and the name or identifier of the low-level state variable RSID.

[0191] The selection allows us to identify an example of an STbl table row reproduced below. GSID GDT RSID SCR RegulationModeState HeatingSystem 0x0C213 if (v == 123) then return 'auto' else return 'manual' end;

[0192] Thus, the new value identified as 123 for the low-level state variable identified by RSID 0x0C213 corresponds to the CvS state conversion value "Auto" for a generic GS variable "RegulationModeState" of a generic device model instance "HeatingSystem". Exemple 2 :

[0193] We assume that a message is received from a central control unit U of a home automation system 17 containing an indication of a change in a state variable RS of the low-level device. The update of a state variable RS is described in the table below. RDPT RDID RSID RSV IO 101 0x14 1024000

[0194] This message corresponds to the update of the RSID status variable 0x014 corresponding to the temperature measured by a sensor of a heating system at address RDID 101 of its local network communicating according to the local protocol RDPT IO homecontrol, the new value RSV being 1024000.

[0195] The IO protocol PD driver can, on this basis, perform the conversion by selecting an SCR state conversion rule or conversion function using the low-level device type RDT (not shown) and the name or identifier of the low-level state variable RSID.

[0196] The selection allows us to identify an example of an STbl table row reproduced below. GSID GDT RSID SCR TemperatureState TemperatureSensor 0x14 return v / 51200;

[0197] Thus, the new value identified as 1024000 for the state variable identified by RSID 0x014 corresponds to a CvS state conversion value of 21 (°C) for a generic GS variable of Temperature / ("TemperatureState") of a generic device model instance of type "Temperature Sensor" / (TemperatureSensor).

[0198] A protocol driver can also convert generic commands (GC) associated with a generic device model (GD) instance into one or more protocol-specific low-level commands (RC) to be executed on the actual device (D), based on at least one command conversion rule (CCR). For example, the command described above, `setClosure(50%)`, can have different translations depending on the protocol of the low-level device (RD) and its type (RDT), and sometimes on the specific configuration of that device. This conversion is implemented in the protocol driver corresponding to the local communication protocol used by the home automation device.

[0199] Therefore, to convert a generic GC command into a low-level RC command or a combination of low-level RC commands, the following steps should be taken: a recognition of the target low-level device model instance RD, via the provided generic device model instance identifier GDURL; then a determination of the conversion to be performed based on the selected RD instance using a CCR command conversion rule or conversion function.

[0200] In most cases, the protocol driver uses only the low-level device type (RDT), but in some complex cases, the value of certain attributes may be necessary to fully determine the low-level command to be generated. In such cases, the protocol driver can access the required attributes using the command unit identifier (UID) and the low-level device instance identifier (RDID).

[0201] The generic command GC can have parameters, in which case these will be passed to the conversion rule CCR. The conversion rule CCR can also use contextual information such as the intended use of the command or its priority level. Low-level commands can then be passed to the corresponding central command unit for execution.

[0202] According to one embodiment, the PD protocol driver can determine the conversion of a generic GC command into one or more low-level RC commands by consulting a CTbl table in its RDB database. For example, the CTbl table might include columns containing the following data: a type of low-level RDT device; a generic command name or identifier GCID; a command conversion rule CCR or conversion function.

[0203] Two examples of GC generic command conversion are described below. Exemple 1 :

[0204] We assume that the generic GC command called is defined as described in the table below. GDURL GC io: / / 1234-5678-0000 / 120403 setClosure(60%)

[0205] This command corresponds to an order to a roller shutter communicating via IO with a radio address 120403 in the local network managed by the central control unit with the identifier 1234-5678-0000, to close to 60%.

[0206] The first step is to determine the corresponding low-level device model instance and its type, using the address contained in the GDURL. We will assume that the low-level device type RDT is 0x0100202, which corresponds to a roller shutter with low-speed control from the manufacturer SOMFY.

[0207] The protocol driver can then proceed with the conversion on this basis, by selecting a CCR command conversion rule or conversion function using the RDT low-level device type and the generic command name or identifier GCID.

[0208] The selection allows us to identify an example of a CTbl table row reproduced below. RDT GCID CCR 0x0100202 setClosure (with one parameter p1) return createActivateFunc(p1*51200)

[0209] The CCR command conversion rule creates a low-level RC command of type 'Activate Func', specific to the IO protocol with a main parameter scaled from the generic parameter p1. Here, the "createActivateFunc()" function returns binary data intended to be used by a central command unit U to form the body (payload) of an IO radio frame. Exemple 2 :

[0210] We assume that the generic GC command called is defined as described in the table below. GDURL GC mod bus: / / 1234-5678-0000 / 4 setTargetTemperature(21)

[0211] This command corresponds to an order to a heating system communicating via MODBUS with a bus address 4 in the local network managed by the central control unit 1234-5678-0000 to set its thermostat to a setpoint temperature of 21°C.

[0212] The first step is to determine the corresponding low-level device model instance and its type, using the address contained in the GDURL. We will assume that the low-level device type RDT is 0x00101, which, according to one implementation, corresponds to a heating system with an optional outdoor temperature sensor.

[0213] The protocol driver can then proceed with the conversion on this basis, by selecting a CCR command conversion rule or conversion function using the RDT low-level device type and the generic command name or identifier GCID.

[0214] The selection allows us to identify an example of a CTbl table row reproduced below. RDT GCID CCR 0x00101 setTargetTemperature (with one parameter p1) return { createConfigurationModeCommand(), createSetTargetTemperatureCommand(p1)}

[0215] The CCR command conversion rule creates two low-level RC commands: the first command puts the device into configuration mode and the second command sets the target temperature using the value of the generic parameter p1. Here, the functions "createConfigurationModeCommand()" and "createSetTargetTemperatureCommand()" return MODBUS protocol-specific binary data intended to be transmitted on the device bus by a central control unit U to change the heating system configuration.

[0216] THE figures 6 à 8 represent methods of implementing configuration, supervision and control processes based on the system described above.

[0217] A method for configuring at least one home automation installation 17 of a building 1, executed by an Sv server connected to at least one home automation installation 17, will now be described with reference to the figure 6 .

[0218] Initially, the process includes a step ECfES1 of receiving a configuration message MCf issued from a central control unit U of a home automation installation 17, in a step ECfU1. The configuration message MCf contains an indication of the commissioning of a new home automation device D or an update / reconfiguration of a previously installed device.

[0219] Alternatively, the MCf message can be sent by a user's terminal T in an ECfT1 step. For example, in the case of unidirectional protocols, the user can commission, configure, or reconfigure / update device D at the home automation installation site and then send the information from their terminal T to initiate the configuration process. The process then includes an ECfES2 creation step of at least one low-level device model instance RD representing the home automation device D. The low-level device model instance RD is stored in the IDB database accessible to the ES execution service. Specifically, a row in the RDTbl table can be created, as described previously, based on the information contained in or inferred from the received MCf message.Indeed, the content of the Mcf message or information about its sender allows us to determine information about: . the identifier of the central control unit U to which a home automation device is attached UID; the address of the home automation device in the local network managed by the central control unit RDID; the type of local protocol used RDPT; type of low-level device model RDT, corresponding for example to a designation of roller shutter or lighting.

[0220] An ECfS3 step is then performed to determine a generic GDT device class or type, or a list of GDT classes or types, from a given low-level RD device model instance. This corresponds to determining a CvM model conversion. This step is performed via a function call from the PD protocol driver, which receives this call in an ECfPD3 step and has the RDB conversion rules database, which includes MCR model conversion rules. If the low-level RD device model instance needs to be represented by multiple generic GD device model instances, the driver will return a list of such GDT1 and GDT2 subsystem classes or types, as also described previously.

[0221] An ECfES4 creation step then performs at least one instance of the generic device model GD1, GD2 for at least one instance of the low-level device model RD, based on the GDT1, GDT2 types or classes determined in the ECfES3 step. The generic device model instances GD1, GD2 are stored in the IDB database, for example, in a GDTbl table as described previously. The link between an RD low-level device model instance and one or more generic model instances GD1, GD2 can be established using GDURL identifiers or GDK and RDK indexing keys, as described previously.

[0222] The process may include a subsequent step ECfES5 of notifying the user about the configuration of a new device D, whether or not requested by the user, who receives this notification in a step ECfUsrS. It is also possible to notify another application A running on the server Sv, which receives this notification in a step ECfA5.

[0223] The configuration process is carried out during the commissioning, configuration or reconfiguration of a home automation equipment D.

[0224] A method for monitoring at least one home automation installation 17 in a building 1, executed by an Sv server connected to at least one home automation installation 17, will now be described with reference to the figure 7 We will assume that the monitoring process is performed after the configuration process described previously. Thus, the low-level device model instances (RD) and the generic device model instances (GD) are stored in an instance database (IDB) accessible to the execution service (ES), as previously described.

[0225] Initially, the process includes a step ESES1 of receiving a status notification message MS issued during a step ESU1 by a central control unit U of a home automation installation 17. The status notification message MS contains an indication concerning a low-level status variable RS of a home automation device D. The MS message may contain a protocol identifier RDPT, a device address in the protocol RDID, an identifier of the relevant status variable RSID and the new value of the status variable RSV.

[0226] The process then includes an ESES2 determination step of at least one instance of low-level device model RD representing the home automation device D. This determination can in particular be carried out using the content of the status notification message MS and / or by identifying the sender of this message, in this example the central control unit U.

[0227] In particular, it is necessary either to use an RDK indexing key already present in the message, or, if this key is not present, to identify the identifying elements that allow determining this RDK key which will then be used to select the RD low-level model device instance in the IDB database, for example in the RDTbl table described earlier.

[0228] The identifying elements are either explicitly contained in the MS notification message from the control unit U, if this message includes dedicated fields for identifying the source and destination entities of the message; or inferred upon receipt of the MS notification message. For example, a control unit can be identified by: its IP address, its TCP port number, or a combination of these two elements (IP address, TCP port, i.e., the identifier of a socket for an Internet connection); or by the logical identifier of a communication channel established between the control unit U and the server Sv. Once the low-level model device instance RD is identified, an ESES3 update step is performed on the low-level state variable RS in the IDB database.

[0229] An ESES4 conversion step then takes place, transforming a low-level RS state variable into one or more generic GS state variables described in one or more generic GDT device classes. This step is performed in particular by calling the PD protocol driver, which has a RDB conversion rule base. This base includes SCR state conversion rules that allow the conversion of a low-level RS state variable of a low-level RDT device type into one or more generic GS1, GS2, GS3 variables of one or more instances of generic GD device models, as described previously, using, for example, the STbl table.The protocol driver performs for this purpose a step of selecting an SCR state conversion rule from the RDB conversion rule base in an ESPD4 step, then returns either the result of the CvS conversion of an RS state variable into one or more GS generic state variables, or a rule to be executed by the execution service to obtain a CvS conversion corresponding to one or more GS generic state variables.

[0230] An ESES5 step is then performed to determine at least one instance of a generic device model (GD) for which at least one state variable (GS) must be updated. This determination can be based on the generic device type(s) (RDT) associated with the at least one generic state variable (GS) to be updated and on the low-level device model instance (RD) determined in the ESES2 step.

[0231] Once the RDK indexing key has been determined for the RD low-level device model instance, the GDK indexing key, which corresponds to the identifier, is easily determined. In cases where multiple GD subsystems correspond to the same low-level device model instance, the generic device type information returned by the PD protocol driver allows the GD subsystem to be defined and updated.

[0232] The process then includes an ESES6 step of updating one or more generic state variables GS based on the CvS conversion determined for the generic device model instance determined GD in the IDB database.

[0233] The process may include a subsequent ESES7 step of returning updated generic state variable (GS) values ​​to a user (Usr), whether requested by the user or not, who receives these values ​​in an ESUsr7 step. It is also possible to notify another application (A) running on the server (Sv), which receives this notification in an ESA7 step.

[0234] A method for controlling at least one home automation installation 17 in a building 1, executed by an Sv server connected to at least one home automation installation 17, will now be described with reference to the figure 8 This process can be executed, for example, by an ES execution process or service using the functions of one or more PD execution drivers as described above.

[0235] Initially, the process includes an ECES1 reception step of a generic GC command in an MC message from i) from a terminal T of a user Usr or ii) from an application A running on the server Sv issued in an ECUsr1 or ECA1 stage respectively and relating to a home automation device D.

[0236] An ECES2 step is then performed to determine at least one instance of the generic device model GD representing the home automation device D. This involves using the unique GDURL identifier of the generic device GD, which serves as an indexing key and contains the necessary identifying elements corresponding to a unique instance of the generic device model GD. This identifier can be included in the MC command message. Once the ECES2 step is completed, the process includes an ECES3 step to determine at least one instance of the low-level device model RD corresponding to the at least one instance of the generic device model GD determined in the previous step. The instances of the low-level device model RD and the instances of the generic device model GD are stored in an IDB instance database accessible to the ES execution service.Thus, the ECES2 and ECES3 steps can be carried out by consulting the said IDB database.

[0237] An ECES4 conversion step is then performed, converting one or more generic (GC) commands from at least one generic (GD) device model instance determined in ECES2 into at least one low-level (RC) command from the low-level (RD) device model instance determined in ECES3. This step is carried out specifically by a call to the PD protocol driver, which has a command conversion rule base based on the types of generic (GD) device models and low-level (RD) device models used. The protocol driver performs a conversion rule selection step in the conversion rule base (RDB) in an ECPD4 step, and then returns a CvC command conversion corresponding to one low-level (RC) command to be executed, or a plurality of low-level (RC1, RC2, RC3) commands to be executed. Subsequently, the command execution can be performed. figure 7 This corresponds to a case where the conversion of at least one generic command GC applicable to at least one instance of the generic device model GD results in a plurality of low-level commands RC1, RC2, RC3, corresponding to the execution of a combination of a plurality of actual commands C on the home automation device D. In such a case, the correspondence between the high-level commands GC and their associated low-level commands RC is stored in memory for appropriate error handling. In particular, the execution service ES can implement a state machine for this purpose.

[0238] Thus, in an ECES5 step, an initial RC1 command is sent to the central unit U of the home automation system 17 for execution by device D, in an initial low-level command message MRC1. In the example shown, we assume that the response to this initial command corresponds to a successful execution with a return code RRC1, sent by the central control unit U in an ECUS step. The execution service can store this success value, OK, for the first RC1 command.

[0239] In an ECES6 step, a second RC2 command is sent to the central unit U of the home automation system 17 for execution by device D, in a second low-level command message MRC2. In the example shown, we assume that the return of the second command corresponds to a command failure, with a return code RRC2, for example, a numerical value of -2 corresponding to an error, sent by the central control unit U in an ECU6 step.

[0240] Subsequently, the execution service requests, in an ECES7 step, a conversion of the RRC2 return code to a generic GRC2 return code from the PD protocol driver, which performs this conversion in an ECPD7 step. For example, the numeric error code -2 can be translated into a generic GRC2 return code corresponding to an "unauthorized command" error. The GRC2 code is stored by the ES execution service.

[0241] In an ECES8 step, a third RC3 command is sent to the central control unit U of the home automation system 17 for execution by the home automation device D, in a third low-level command message MRC3. In the example shown, we assume that the return value of the third command corresponds to a command failure, with the return value of an RRC3 code, for example, a numerical value of -7, sent by the central control unit U in an ECU8 step.

[0242] Subsequently, the execution service requests, in an ECES9 step, a conversion of the RRC3 return code to a generic GRC3 return code from the PD protocol driver, which performs this conversion in an ECPD9 step. For example, the numeric error code -2 can be translated into a generic GRC3 error code, "no radio response." The GRC3 code is stored by the ES execution service.

[0243] In a final ECES10 step, the execution service defines a response to be returned to the user following the MC command message, which is received in an ECUsr10 step.

[0244] Since a command result, or GERC1 return code, was received for each executed low-level command (RC1, RC2, RC3), the results must be aggregated to simulate an overall command result for the original generic command. Specifically, the generic command is considered executed if all low-level commands were successful, and not executed if one or more low-level commands failed.

[0245] In the case illustrated in the figure 7 , it can be considered that the GC order has failed, and that the return code given to the customer should be: "order not authorized" and "no radio response".

[0246] This response is communicated to the user Usr or to the application A which receives it in an ECUsr10 step.

[0247] It should be noted that the control process can allow the parallel control of several products using the same protocol or different local communication protocols.

[0248] In particular, the following steps can be applied in this case: Low-level RC commands applicable to a home automation device D without functional subsets are executed sequentially as described above, i.e. a new command is sent only after receiving the return code corresponding to the execution of the previous command. Commands relating to home automation devices D including functional subsets or to a group of home automation devices can be carried out in parallel, i.e. the different commands are sent one after the other, but without waiting to receive the return code corresponding to the execution of the commands previously sent, provided that these commands do not concern the same functional subset or even device within a group, which amounts to an operation corresponding to command queues per device or per functional subset of the home automation device D.

[0249] These provisions allow the parallel processing of commands on separate devices or on functional subsets of the same home automation device, in order to reduce the processing time of generic commands intended for several separate home automation devices or functional subsets of the same home automation device.

[0250] These features are particularly well-suited for tracking long command cycles. For example, consider a home automation system consisting of 10 roller shutters communicating via a bidirectional protocol, such as IO HomeControl. Each shutter receives feedback when it has reached the desired position, with each shutter able to travel its full range in 30 seconds. Sequential processing would result in the command being executed in 5 minutes, whereas parallel processing would allow the command to be executed and the feedback received within 30 seconds.< / subsystemld> < / rawdeviceaddress> < / gatewayld> < / protocol>

Claims

1. A method for configuring at least one home automation installation (17) of a building (1), the home automation installation (17) comprising a plurality of home automation devices (D), the method being executed by a management unit (Sv) connected to the at least one home automation installation (17) and comprising the following steps: i. Reception (ECfES1) of a configuration message (MCf) emitted from a central control unit (U) of a home automation installation (17) or a user terminal (T), the message (Mcf) containing an indication on a commissioning, a configuration or a reconfiguration of a home automation device (D); ii. Determination of at least one low-level device model class or type (RDT) corresponding to the home automation device (D), each home automation device (D) being represented by at least one generic device model instance (GD) and at least one low-level device model instance (RD); iii. Creation (ECfES2) of at least one low-level device model instance (RD) according to the low-level device class or type (RDT) defined at step ii and corresponding to the home automation device (D); iv. Determination (ECfS3) of a model conversion (CvM) converting a low-level device type or class (RDT) into at least one generic device model class or type (GDT) on the basis of a model conversion rule (MCR) selected according to the low-level device model instance (RD) determined at step iii or its type (RDT); v. Creation (ECfES4) of at least one generic device model instance (GD) for the at least one low-level device model instance (RD) on the basis of the at least one type or class (GDT) corresponding to the model conversion (CvM) determined at step iv; vi. Saving of the at least one generic device model instance (GD) in an associated manner with the at least one low-level device model instance (RD); Wherein the generic device model defines: - A set of commands or functions associated to said model and / or - A set of statuses or status variables associated to said model and / or - A set of attributes associated to said model.

2. The method according to claim 1, further comprising the following steps: - Emission of a message for communicating the configuration of at least one home automation device (D) toward a user terminal (T) or an application (A) executed on the management unit (Sv) or on another connected management unit.

3. The method according to claim 2, wherein a notification and subscription system may be set up.

4. The method according to claim 1, wherein the model conversion rules are stored in the form of an association between: - A low-level device type; - At least one corresponding generic device type or class GDT.

5. The method according to any one of claims 1 to 4, wherein each generic device model instance comprises a generic device unique identifier.

6. The method according to any one of claims 1 to 5, wherein the names of the statuses or status variables relating to a generic device model are explicit.

7. The method according to any one of claims 1 to 6, wherein the status variables values relating to a generic device model are standardized.

8. The method according to any one of claims 1 to 7, wherein the names of the commands relating to a generic device model are explicit.

9. The method according to any one of claims 1 to 8, wherein the command parameters relating to a generic device model are standardized.

10. The method according to any one of claims 1 to 9, wherein the unique identifier of the generic model instance may be constituted in particular by an identifier using in particular an address notation independent of the protocol, for example according to a URL-type format.

11. The method according to any one of claims 1 to 10, wherein each low-level device model instance further comprises a unique low-level device identifier in the local area network associated to a central control unit of a home automation installation.