KR102628107B1 - Wall Pad and Method of Work on Wall Pad that Using OCF-based Protocol and Legacy Protocol Together - Google Patents

Abstract

The present invention relates to a wall pad device and method that uses an OCF-based protocol and a legacy protocol in combination. More specifically, the wall pad device controls non-OCF devices using connected non-OCF devices and legacy protocols, and When receiving a query to control a non-OCF device through an OCF-based protocol from an OCF client device connected to the pad device, convert information about the non-OCF device into OCF-based and provide it to the OCF client device, This relates to a wall pad device and method that uses both an OCF-based protocol and a legacy protocol to control non-OCF devices through an OCF-based protocol.

Description

Wall Pad device and method for using OCF-based protocol and legacy protocol together {Wall Pad and Method of Work on Wall Pad that Using OCF-based Protocol and Legacy Protocol Together}

The present invention relates to a wall pad device and method that uses an OCF-based protocol and a legacy protocol in combination. More specifically, the wall pad device controls non-OCF devices using connected non-OCF devices and legacy protocols, and When receiving a query to control a non-OCF device through an OCF-based protocol from an OCF client device connected to the pad device, convert information about the non-OCF device into OCF-based and provide it to the OCF client device, This relates to a wall pad device and method that uses both an OCF-based protocol and a legacy protocol to control non-OCF devices through an OCF-based protocol.

Due to improvements in communication technology and computing resources, the development of Internet of Things (IoT)-related technologies and IoT devices is actively taking place. In order to implement the Internet of Things, various standards related to the Internet of Things are being established, such as communication between Internet of Things devices and communication between Internet of Things devices and clients.

In particular, among the Internet of Things standardization organizations, the Open Connectivity Foundation (OCF) established the open source-based OCF standard for the Internet of Things, and the OCF standard is a representative Internet of Things standard that is being rapidly adopted among various standards related to the Internet of Things. It applies.

OCF is a standard platform technology that connects IoT devices and allows mutual control of resources existing in IoT devices. OCF is a server-client model, where each server defines the various Internet of Things services it can provide in the form of resources. Therefore, we adopt the Restful method, which allows clients to use the desired service. Meanwhile, the OCF uses the Constrained Application Protocol (CoAP) to enable the Internet of Things to be implemented even in small devices with limited computing power.

In this way, in the case of IoT devices to which OCF technology is applied, communication can normally be performed with other devices to which OCF technology is applied through the protocol adopted by OCF, but communication with other devices to which standard technologies other than OCF are applied is difficult. A difficult problem exists. These problems are bound to become an obstacle to both the OCF camp and other standard technology camps expanding their respective ecosystems.

Meanwhile, separate hub devices are provided to control and manage various IoT devices placed in indoor spaces such as apartments or houses, and a representative hub device is a wall pad device. Through the wall pad device, you can view the installation status of IoT devices existing in the building, such as smart lighting and smart plugs, and the resources of each IoT device (lighting on/off, dimming, color temperature control, electricity Check usage) can be used.

Meanwhile, in order to solve the problem of difficulty in communicating between OCF-based IoT devices and IoT devices using other standards, a wall pad device that can be used as a hub of the Internet of Things network uses different standards. There is a need for the development of new technologies that enable communication with IoT devices.

The present invention relates to a wall pad device and method that uses an OCF-based protocol and a legacy protocol in combination. More specifically, the wall pad device controls non-OCF devices using connected non-OCF devices and legacy protocols, and When receiving a query to control a non-OCF device through an OCF-based protocol from an OCF client device connected to the pad device, convert information about the non-OCF device into OCF-based and provide it to the OCF client device, The purpose is to provide a wall pad device and method that can control non-OCF devices through an OCF-based protocol and uses both an OCF-based protocol and a legacy protocol.

In order to solve the above problems, in one embodiment of the present invention, a wallpad device that uses OCF (Open Connectivity Foundation)-based protocol and legacy protocol in combination, one or more Non-OCF devices connected to the wallpad device and legacy A legacy control step of controlling the one or more Non-OCF devices using a protocol; A query receiving step of receiving a query from an OCF client device connected to the same network as the wallpad device; An OCF identifier allocation step of allocating an OCF identifier to each of one or more non-OCF devices connected to the wall pad device based on the query; A resource type information generation step of generating resource type information for each of the one or more Non-OCF devices based on the OCF identifier of each of the one or more Non-OCF devices; A Non-OCF device information providing step of transmitting OCF identifier and resource type information of each of the one or more Non-OCF devices to the OCF client device; And the OCF client device and the selected one or more Non-OCF devices based on the selection of one or more Non-OCF devices by the OCF client device that has received the OCF identifier and resource type information of each of the one or more Non-OCF devices. Onboarding, and an OCF control step of controlling the selected one or more non-OCF devices based on input from the OCF client device.

In one embodiment of the present invention, the wallpad device includes a virtual OCF server and a virtual OCF client, and the query receiving step includes the virtual OCF server and the onboarding request when receiving an onboarding request from the OCF client device. After onboarding the OCF client device, the query is received from the virtual OCF server, and in the Non-OCF device information providing step, the OCF identifier and resource type information of each of the one or more Non-OCF devices are sent to the virtual OCF. Transmitted to the client, the virtual OCF server may receive the OCF identifier and resource type information of each of the one or more Non-OCF devices from the virtual OCF client and transmit them to the OCF client device.

In one embodiment of the present invention, the OCF identifier allocation step includes a unique identifier receiving step of receiving a unique identifier from each of the one or more Non-OCF devices; And an OCF identifier generation step of generating an OCF identifier having a predetermined size for each of the one or more Non-OCF devices based on each unique identifier and the location information of each of the one or more Non-OCF devices. .

In one embodiment of the present invention, the unique identifier received from each of the one or more Non-OCF devices includes ID information of a controller electrically connected to the Non-OCF device and the wall pad device, and ID information of the Non-OCF device. , and may include type information of the corresponding Non-OCF device.

In one embodiment of the present invention, the resource type information generation step is 1 corresponding to the type information of the non-OCF device included in the OCF identifier assigned using a mapping table in which the resource type corresponding to the type information is stored. The resource type information can be created based on the above resource types.

In order to solve the above problem, in one embodiment of the present invention, a method of using a protocol based on OCF (Open Connectivity Foundation) and a legacy protocol performed in a wall pad device is used, and at least one non- A legacy control step of controlling the one or more non-OCF devices using an OCF device and a legacy protocol; A query receiving step of receiving a query from an OCF client device connected to the same network as the wallpad device; An OCF identifier allocation step of allocating an OCF identifier to each of one or more non-OCF devices connected to the wall pad device based on the query; A resource type information generation step of generating resource type information for each of the one or more Non-OCF devices based on the OCF identifier of each of the one or more Non-OCF devices; A Non-OCF device information providing step of transmitting OCF identifier and resource type information of each of the one or more Non-OCF devices to the OCF client device; And the OCF client device and the selected one or more Non-OCF devices based on the selection of one or more Non-OCF devices by the OCF client device that has received the OCF identifier and resource type information of each of the one or more Non-OCF devices. An OCF control step of onboarding and controlling the selected one or more non-OCF devices based on input from the OCF client device. A method of using the OCF protocol and legacy protocol together is provided.

According to an embodiment of the present invention, the Wallpad device can control Non-OCF devices using a legacy protocol, and can control Non-OCF devices using an OCF-based protocol at the request of an OCF client device. Therefore, it can be effective in using both legacy protocols and OCF-based protocols.

According to one embodiment of the present invention, the Wallpad device can control Non-OCF devices by onboarding with the OCF client device, thereby achieving the effect of controlling Non-OCF devices through the OCF client device.

According to one embodiment of the present invention, the Wallpad device allocates an OCF identifier for the Non-OCF device in order to provide information about the Non-OCF device to the OCF client device, and the assigned OCF identifier is not newly created. Since it is assigned based on the previously assigned unique identifier of the Non-OCF device, it can effectively allocate OCF identifiers.

According to one embodiment of the present invention, the resource type information of the Non-OCF device is generated through the resource type information generation step performed by the wallpad device and provided to the OCF client device, so that the Non-OCF device that the OCF client device wants to control It can have the effect of allowing the functions (resources) of the OCF device to be used.

Figure 1 schematically shows an OCF bridge platform that relays a Non-OCF device and an OCF device according to an embodiment of the present invention.
Figure 2 schematically shows a wall pad device and components connected to the wall pad device according to an embodiment of the present invention.
Figure 3 schematically shows the processes of controlling a non-OCF device in a wall pad device according to a request from an OCF client device according to an embodiment of the present invention.
Figure 4 schematically shows the process of allocating an OCF identifier to a Non-OCF device based on the unique identifier of the Non-OCF device according to an embodiment of the present invention.
Figure 5 schematically shows the process of generating resource type information according to type information of a Non-OCF device according to an embodiment of the present invention.
Figure 6 schematically shows screens of a wall pad device according to an embodiment of the present invention.

BRIEF DESCRIPTION OF THE DRAWINGS Various embodiments and/or aspects are now disclosed with reference to the drawings. In the following description, for purposes of explanation, numerous specific details are set forth to facilitate a general understanding of one or more aspects. However, it will also be appreciated by those skilled in the art that this aspect(s) may be practiced without these specific details. The following description and accompanying drawings set forth in detail certain example aspects of one or more aspects. However, these aspects are illustrative and some of the various methods in the principles of the various aspects may be utilized, and the written description is intended to encompass all such aspects and their equivalents.

Additionally, various aspects and features may be presented by a system that may include multiple devices, components and/or modules, etc. It is also understood that various systems may include additional devices, components and/or modules, etc. and/or may not include all of the devices, components, modules, etc. discussed in connection with the drawings. It must be understood and recognized.

As used herein, “embodiments,” “examples,” “aspects,” “examples,” etc. may not be construed to mean that any aspect or design described is better or advantageous over other aspects or designs. . The terms '~part', 'component', 'module', 'system', 'interface', etc. used below generally refer to computer-related entities, such as hardware, hardware, etc. A combination of and software, it can mean software.

Additionally, the terms “comprise” and/or “comprising” mean that the feature and/or element is present, but exclude the presence or addition of one or more other features, elements and/or groups thereof. It should be understood as not doing so.

Additionally, terms including ordinal numbers, such as first, second, etc., may be used to describe various components, but the components are not limited by the terms. The above terms are used only for the purpose of distinguishing one component from another. For example, a first component may be named a second component, and similarly, the second component may also be named a first component without departing from the scope of the present invention. The term and/or includes any of a plurality of related stated items or a combination of a plurality of related stated items.

In addition, in the embodiments of the present invention, unless otherwise defined, all terms used herein, including technical or scientific terms, are generally understood by those skilled in the art to which the present invention pertains. It has the same meaning as Terms defined in commonly used dictionaries should be interpreted as having a meaning consistent with the meaning in the context of the related technology, and unless clearly defined in the embodiments of the present invention, have an ideal or excessively formal meaning. It is not interpreted as

Figure 1 schematically shows an OCF bridge platform 2000 that relays a non-OCF device 1000 and an OCF device 3000 according to an embodiment of the present invention.

The OCF bridge platform (2000) shown in Figure 1 is an ecosystem that includes an OCF device (1000) using an OCF-based protocol and an ecosystem that includes a Non-OCF device (3000) using a Non-OCF (legacy) protocol. It plays a relay role so that it can be connected and integrated. More specifically, the OCF bridge platform 2000 can convert an OCF-based protocol into a non-OCF (legacy) protocol, or conversely, convert a legacy protocol into an OCF-based protocol.

For example, when the OCF device 1000 is a client and the non-OCF device 3000 is a server providing resources, the OCF bridge platform 2000 receives the client's request through an OCF-based protocol, By providing the request to the Non-OCF device (3000) using the legacy protocol, communication between devices is achieved. More specifically, the OCF bridge platform 2000 includes a virtual server and a virtual client implemented in software, receives a request from the OCF device 1000, which is a client, from the virtual server, and the virtual client makes the request. Relay can be performed by providing information to the Non-OCF device (3000) corresponding to the server. Similarly, even when the OCF device 1000 is a server and the non-OCF device 3000 is a client, the OCF bridge platform 2000 can relay between devices.

The OCF device 1000 operates based on the OCF standard and may perform both the roles of an OCF client and an OCF server, or may perform only one of the OCF client and OCF server roles.

When implementing the Internet of Things, OCF (Open Connectivity Foundation) networks IoT devices using a lightweight CoAP (Constrained Application Protocol) protocol in a client-server manner based on the REST structure (RESTful), and stores resources existing in the Internet of Things devices. It corresponds to a standard open platform technology that allows mutual control. That is, the OCF device 1000 and the OCF client device 4000 described in the present invention may correspond to devices that comply with OCF standard technology.

Meanwhile, the Non-OCF device (3000) may correspond to an Internet of Things device that communicates using a legacy protocol that corresponds to other conventional protocols rather than an OCF-based protocol. Likewise, the Non-OCF device (3000) It can perform both the roles of Non-OCF client and Non-OCF server, or it can perform only one role among Non-OCF client and Non-OCF server.

For example, if the Non-OCF device 3000 is a smart lighting with resources such as dimming and color temperature control, the Non-OCF device 3000 may correspond to a Non-OCF server, and the legacy protocol It may correspond to RS-485, one of the serial communications.

Meanwhile, the wall pad device 5000 described in the present invention may correspond to the OCF bridge platform 2000 shown in FIG. 1, and therefore the wall pad device 5000 controls various devices such as door control. In addition to including general functions, it may also include the functions of the OCF Bridge Platform (2000) described above.

Figure 2 schematically shows a wall pad device 5000 and components connected to the wall pad device 5000 according to an embodiment of the present invention.

As shown in FIG. 2, the wall pad device 5000 can communicate with various components. Specifically, the components include an OCF client device 4000 and a controller 6000, as shown in FIG. 2. ), Non-OCF device (7000), and OCF device (8000).

The OCF client device 4000 is a device that wishes to control the resources of the Non-OCF device 7000 or the OCF device 8000, and queries the Non-OCF device 7000 or the OCF device 8000. Resources included in the Non-OCF device 7000 or the OCF device 8000 can be provided, and control over specific resources can be performed. For example, the OCF client device 4000 may correspond to a user terminal such as a smartphone for controlling an Internet of Things device.

More specifically, the OCF client device 4000 can directly communicate with the OCF device 8000 through an OCF-based IoT network. On the other hand, the OCF client device 4000 cannot communicate directly with the Non-OCF device 7000 because it uses a different protocol, and therefore requires a predetermined process performed by the wallpad device 5000, which performs a relay role. Through this, communication can be performed indirectly with the Non-OCF device (7000).

The controller 6000 electrically connects the wall pad device 5000 and the Non-OCF device 7000 to each other, and controls the Non-OCF device 7000 according to a signal transmitted from the wall pad device 5000. It plays a role in controlling. Additionally, the controller 6000 not only functions to control the Non-OCF device 7000, but may also perform its own unique functions. For example, when the Non-OCF device 7000 is a lighting device, the controller 6000 performs the function of an energy meter to calculate the amount of power consumed according to the operation of the lighting, and calculates the amount of power consumed by the wall pad device 5000. It may also be provided to .

Meanwhile, the controller 6000 may include unique ID information that can identify the controller 6000, and the ID information will be used to assign an OCF identifier to the Non-OCF device 7000, which will be described later. You can.

The Non-OCF device (7000) corresponds to a device that uses a separate protocol (legacy protocol) according to a standard other than the OCF standard, and is used for control of the OCF client device (4000) or the wall pad device (5000). Depending on your needs, one or more resources may be provided. For example, the legacy protocols include various Internet of Things communication protocols that are not used in the above-mentioned OCF standards, such as AllJoyn, which is a protocol established by the AllSeen Alliance, Message Queuing Telemetry Transport (MQTT) protocol, HTTP, TCP, RS-485, etc. can do.

Meanwhile, the Non-OCF device 7000 performs the role of a server that provides resources according to the query of the OCF client device 4000. However, the Non-OCF device 7000 not only plays the role of a server but also acts as a server for other IoT It can also act as a client that queries the device.

In another embodiment of the present invention, the Non-OCF device 7000 may be electrically connected directly to the wall pad device 5000 without being connected to the controller 6000.

Meanwhile, the Non-OCF device 3000 shown in FIG. 1 and the Non-OCF device 7000 shown in FIG. 2 may be the same, but in FIG. 1, a Non-OCF device connected to a general OCF bridge platform 2000 Since this is for explaining 3000, hereinafter it will be described as Non-OCF device 7000 shown in FIG. 2.

The OCF device 8000, like the non-OCF device 7000 described above, may provide one or more resources under the control of the OCF client device 4000 or the wallpad device 5000, but the OCF device ( 8000) uses an OCF-based protocol. For example, the OCF-based protocol may include Constrained Application Protocol (CoAP).

Meanwhile, the OCF device 8000 performs the role of a server that provides resources according to queries from the OCF client device 4000. However, the OCF device 8000 not only serves as a server but also queries other IoT devices. It can also act as a client.

Meanwhile, the OCF device 1000 shown in FIG. 1 and the OCF device 8000 shown in FIG. 2 may be the same, but FIG. 1 illustrates the OCF device 1000 connected to a general OCF bridge platform 2000. Therefore, hereinafter, it will be described as the OCF device 8000 shown in FIG. 2.

The wall pad device 5000 controls the Non-OCF device 7000 using a legacy protocol and the Non-OCF device (7000) according to a query using the OCF-based protocol of the OCF client device 4000. 7000) may include elements for providing information about the OCF client device 4000.

Specifically, the wallpad device 5000 controls the non-OCF device 7000 through a legacy protocol, or assigns an OCF identifier to the non-OCF device 7000 according to a query from the OCF client device 4000, and A legacy control unit 5100 that generates resource type information, a virtual OCF server 5200 that communicates with the OCF client device 4000 and the virtual OCF client 5300, and the virtual OCF server 5200 and the legacy control unit. It may include a virtual OCF client 5300 that communicates with 5100.

More specifically, the legacy control unit 5100 may include a non-OCF device control unit 5110, an OCF device control unit 5120, an OCF identifier allocation unit 5130, and an OCF interface unit 5140.

The Non-OCF device control unit 5110 uses the legacy protocol when the user receives an input for controlling a Non-OCF device (7000) from the wall pad device (5000) or requests control from the OCF client device (4000). You can control the Non-OCF device (7000) using .

More specifically, the Non-OCF device control unit 5110 provides a first interface displayed on the wall pad device 5000 to receive input for controlling the Non-OCF device 7000 from the user, and the user Resources provided by the Non-OCF device 7000 can be used through the first interface displayed on the wall pad device 5000.

The OCF device control unit 5120 can control the OCF device 8000 connected to the wall pad device 5000 using an OCF-based protocol. To this end, the OCF device control unit 5120 provides a second interface displayed on the wall pad device 5000 to receive input from the user for controlling the OCF device 8000, and the user Can use resources provided by the OCF device 8000 through the second interface displayed on the wall pad device 5000.

Meanwhile, since the OCF client device 4000 and the OCF device 8000 use the same OCF standard, the OCF client device 4000 can directly control the OCF device 8000 or use the OCF device control unit 5120. The OCF device 8000 can be controlled through.

In another embodiment of the present invention, the first interface displayed by the Non-OCF device control unit 5110 and the second interface displayed by the OCF device control unit 5120 are connected to the wall pad device 5000 in the form of a single interface. It is displayed, and the Non-OCF device control unit 5110 or the OCF device control unit 5120 may operate depending on the user's selection of a specific device.

The OCF identifier allocator 5130 is configured to provide information on one or more Non-OCF devices (7000) connected to the wall pad device (5000) according to a query from the OCF client device (4000). (7000) Allocates an OCF identifier corresponding to the OCF standard for each, and generates resource type information for one or more resources provided by the Non-OCF device (7000).

The OCF identifier may be assigned based on a unique identifier preset for each Non-OCF device 7000, and the resource type information may be generated based on type information included in the unique identifier. This will be described later in Figures 4 and 5.

The OCF interface unit 5140 performs an interface between the virtual OCF client 5300 and the legacy control unit 5100, preferably the Non-OCF device control unit 5110 or the OCF device control unit 5120. Through this, the OCF identifier and resource type information derived from the OCF identifier allocator 5130 can be transmitted to the virtual OCF client 5300, and the virtual OCF client 5300 can use the OCF client device 4000. A query can be transmitted to the Non-OCF device control unit 5110 or the OCF device control unit 5120 through the OCF interface unit 5140.

In one embodiment of the present invention, the OCF interface unit 5140 may be implemented through various languages, but is preferably implemented through Android Interface Definition Language (AIDL).

Meanwhile, the virtual OCF server 5200 included in the wall pad device 5000 communicates with the OCF client device 4000 through an OCF-based protocol, and the OCF client device 4000 is a Non-OCF device. In order to access (7000), the resources (functions) of the Non-OCF device (7000) are converted into OCF resources and provided (exposed) to the OCF client device (4000). To this end, the virtual OCF server 5200 may communicate with the virtual OCF client 5300 included in the wallpad device 5000.

The virtual OCF client 5300 included in the above-described wallpad device 5000 provides information allocated from the OCF identifier allocator 5130 to the resources of the non-OCF device 7000 in a form related to the OCF-based protocol. It can be received through the OCF interface unit 5140, and the received OCF-based resource information can be provided to the virtual OCF server 5200. Additionally, when the OCF client device 4000 receives an input for controlling the Non-OCF device 7000, the virtual OCF client 5300 receives the corresponding input from the virtual OCF server 5200, and By transmitting to the OCF interface unit 5140, the legacy control unit 5100, preferably the Non-OCF device control unit 5110, controls the Non-OCF device 7000 using the legacy protocol according to the corresponding input. You can.

In this way, the wall pad device 5000 relays the Non-OCF device 7000, which communicates using the legacy protocol method, and the OCF client device 4000, which communicates using the OCF-based protocol, thereby connecting the OCF ecosystem and Non-OCF. -Enables integration of OCF, that is, the legacy ecosystem.

Figure 3 schematically shows the processes of controlling the Non-OCF device 7000 in the wall pad device 5000 according to the request of the OCF client device 4000 according to an embodiment of the present invention.

As shown in FIG. 3, it is a wall pad device 5000 that uses both an Open Connectivity Foundation (OCF)-based protocol and a legacy protocol, and includes one or more Non-OCF devices 7000 connected to the wall pad device 5000. A legacy control step (S10) of controlling the one or more Non-OCF devices (7000) using a legacy protocol; A query reception step (S11 to S13) of receiving a query from an OCF client device (4000) connected to the same network as the wallpad device (5000); An OCF identifier allocation step (S15) of allocating an OCF identifier to each of one or more Non-OCF devices (7000) connected to the wall pad device (5000) based on the query; A resource type information generation step (S16) of generating resource type information for each of the one or more Non-OCF devices (7000) based on the OCF identifier of each of the one or more Non-OCF devices (7000); A Non-OCF device information provision step (S17) of transmitting the OCF identifier and resource type information of each of the one or more Non-OCF devices (7000) to the OCF client device (4000); And based on the selection of one or more Non-OCF devices (7000) by the OCF client device (4000) that has received the OCF identifier and resource type information of each of the one or more Non-OCF devices (7000), the OCF client device (4000) and an OCF control step of onboarding the selected one or more Non-OCF devices (7000) and controlling the selected one or more Non-OCF devices (7000) based on input from the OCF client device (4000). (S19 to S21); can be performed.

Specifically, the wallpad device 5000 performs a legacy control step ( Perform S10). In the legacy control step (S10), the Non-OCF device control unit 5110 displays a first interface on the wall pad device 5000, and the Non-OCF is displayed according to the information entered by the user through the first interface. The device 7000 can be controlled.

Afterwards, a query reception step in which the OCF client device 4000 transmits a query to the wallpad device 5000 in order to control the non-OCF device 7000, and the wallpad device 5000 receives it. (S11 to S13) are performed.

More specifically, the wallpad device 5000 includes a virtual OCF server 5200 and a virtual OCF client 5300, and the query reception steps (S11 to S13) are performed by receiving information from the OCF client device 4000. When receiving a boarding request, the query may be received from the virtual OCF server 5200 after onboarding the virtual OCF server 5200 and the OCF client device 4000.

The wallpad device 5000 includes a virtual OCF server 5200 to receive information from the OCF client device 4000, and the virtual OCF server 5200 supports the OCF client device 4000 and the OCF-based Communication is performed through protocols. Before receiving a query from the OCF client device 4000, the virtual OCF server 5200 receives an onboarding request to start communication from the virtual OCF server 5200 (S11). Afterwards, the virtual OCF server 5200 can complete preparations for mutual communication by performing onboarding with the OCF client device 4000 (S12) according to the received onboarding request.

After the OCF client device 4000 and the virtual OCF server 5200 are onboarded, the OCF client device 4000 transmits a query to control the Non-OCF device 7000 (S13), and The virtual OCF server 5200 performs query reception steps (S11 to S13) to receive a query.

The virtual OCF server 5200, which has received the query, requests information about one or more Non-OCF devices 7000 connected to the wall pad device 5000 from the virtual OCF client 5300, and the virtual OCF client 5300 Finally requests information about one or more Non-OCF devices 7000 connected to the wall pad device 5000 from the legacy control unit 5100 through the OCF interface unit 5140 (S14).

The legacy control unit 5100 that receives the request generates OCF identifier allocation and resource type information for one or more Non-OCF devices 7000 connected to the wall pad device 5000, and preferably the OCF identifier allocation unit This is done at 5130.

More specifically, the OCF identifier allocator 5130 allocates an OCF identifier according to a predetermined rule based on the unique identifier preset in the Non-OCF device 7000 (S15), and assigns the OCF identifier to the Non-OCF device 7000. According to the type information, resource type information for one or more resources (functions) of the non-OCF device 7000 is generated (S16).

Meanwhile, the steps of allocating an OCF identifier (S15) and generating resource type information (S16) in the OCF identifier allocator 5130 are performed once when the OCF client device 4000 transmits a query for the first time. , After that, the OCF identifier allocator 5130 can omit the above process, and preferably, according to the subsequent query, the OCF identifier allocator 5130 is additionally connected to the wall pad device 5000. The process of assigning an OCF identifier to one or more non-OCF devices (7000) (S15) and generating resource type information (S16) can be performed.

Meanwhile, the legacy control unit 5100 performs a Non-OCF device information provision step (S17) of transmitting the OCF identifier and resource type information generated by the OCF identifier allocator 5130 to the OCF client device 4000.

Specifically, the Non-OCF device information provision step (S17) transmits the OCF identifier and resource type information of each of the one or more Non-OCF devices (7000) to the virtual OCF client (5300), and the virtual OCF server (5200) receives the OCF identifier and resource type information of each of the one or more Non-OCF devices (7000) from the virtual OCF client (5300) and transmits them to the OCF client device (4000).

More specifically, the OCF interface unit 5140 transmits the OCF identifier and resource type information for each of one or more Non-OCF devices 7000 connected to the wall pad device 5000 to the virtual OCF client 5300. And, the virtual OCF server 5200 may receive the OCF identifier and resource type information from the virtual OCF client 5300 and transmit the OCF identifier and type information to the OCF client device 4000 (S17). . Through this, the OCF client device 4000 can receive information about one or more Non-OCF devices 7000 connected to the wallpad device 5000 and resource type information of each Non-OCF device 7000. .

Meanwhile, according to the OCF identifier and resource type information of one or more Non-OCF devices (7000) provided by the OCF client device (4000), the user using the OCF client device (4000) or the OCF client device (4000) itself A selection input for a specific Non-OCF device (7000) to be controlled is received (S18). Preferably, the selection input may correspond to an input requesting onboarding with a specific Non-OCF device (7000) to be controlled. Thereafter, the OCF client device 4000 requests onboarding with a specific non-OCF device 7000 selected as the virtual OCF server 5200 according to the selection input (S19), and the virtual OCF server 5200 The onboarding request is transmitted to the OCF client 5300, and the virtual OCF client 5300 transmits it to the legacy control unit 5100, so that the legacy control unit 5100 can finally receive the onboarding request. Let it happen.

Meanwhile, the legacy control unit 5100 performs onboarding of the selected specific non-OCF device 7000 and the OCF client device 4000 (S20). Preferably, onboarding can be performed in the Non-OCF device control unit 5110 included in the legacy control unit 5100. In another embodiment of the present invention, the OCF client device 4000 does not directly perform onboarding with the Non-OCF device 7000, but controls the Non-OCF device 7000 based on a legacy protocol. It is onboarded with the Non-OCF device control unit 5110 and can also control a specific non-OCF device (7000) selected through the Non-OCF device control unit (5110).

After onboarding with the selected specific Non-OCF device (7000), the OCF client device (4000) transmits control information for using the resources of the selected specific Non-OCF device (7000) to the virtual OCF server (5200). (S21), the virtual OCF client 5300 receives the control information received from the virtual OCF server 5200 and transmits it to the legacy control unit 5100, preferably the Non-OCF device control unit 5110. , the Non-OCF device control unit 5110 can perform control using the resources of the specific Non-OCF device 7000 according to the control information.

In this way, the OCF client device 4000 implemented based on OCF can control the Non-OCF device 7000 implemented based on Non-OCF through the wallpad device 5000, and the wallpad device 5000 Including a virtual OCF server 5200 and a virtual OCF client 5300 implemented in software, the Non-OCF device 7000 can be controlled according to the request of the OCF client device 4000. Meanwhile, the number of the virtual OCF server 5200 and the virtual OCF client 5300 is adjusted according to the number of OCF client devices 4000 and the number of non-OCF devices 7000 connected to the wall pad device 5000. It can be flexibly varied, and thus communication with one or more OCF client devices (4000) and one or more Non-OCF devices (7000) can be performed smoothly.

Figure 4 schematically shows the process of allocating an OCF identifier to a Non-OCF device 7000 based on the unique identifier of the Non-OCF device 7000 according to an embodiment of the present invention.

As shown in FIG. 4, the OCF identifier allocation step (S15) includes a unique identifier receiving step of receiving a unique identifier from each of the one or more Non-OCF devices (7000); And an OCF identifier generation step of generating an OCF identifier with a predetermined size for each of the one or more Non-OCF devices (7000) based on each unique identifier and the location information of each of the one or more Non-OCF devices (7000). May include ;.

Specifically, the diagram shown in (A) of FIG. 4 corresponds to a diagram showing the configuration of a unique identifier preset for each Non-OCF device (7000). As shown in (A) of FIG. 4, the unique identifier of the Non-OCF device 7000 may include a plurality of detailed unique information.

More specifically, the unique identifier received from each of the one or more Non-OCF devices (7000) is the plurality of detailed unique information and is a controller ( 6000), ID information of the corresponding Non-OCF device (7000), and type information of the corresponding Non-OCF device (7000).

As shown in (A) of FIG. 4, the ID information of the controller 6000 included in the unique identifier of the Non-OCF device 7000, the ID information of the Non-OCF device 7000, and the Non-OCF device 7000. The type information of the OCF device 7000 may be allocated as a hexadecimal number with a predetermined number of digits, preferably 2 digits (total size of 1 byte).

The ID information of the controller 6000 is the ID information of the controller 6000 to which the Non-OCF device 7000 is connected. Each of one or more controllers 6000 connected to the wall pad device 5000 has different ID information. You can. In another embodiment of the present invention, the Non-OCF device 7000 may be directly connected to the wall pad device 5000 without being connected to the controller 6000, and in this case, the Non-OCF device 7000 The ID information of the controller 6000 included in the unique identifier may be set to a unique value indicating that there is no connected controller 6000.

The ID information of the Non-OCF device 7000 has a specific value for each one or more Non-OCF devices 7000 connected to the wall pad device 5000, and the Non-OCF device 7000 is connected to the wall pad device 5000. ID information of the device 7000 may be assigned, or ID information may be assigned during the manufacturing stage of the non-OCF device 7000.

The type information of the Non-OCF device 7000 corresponds to information about one or more resources (functions) possessed by the Non-OCF device 7000. That is, what type of device the Non-OCF device 7000 is (e.g., smart lighting, smart plug, door control device, etc.), and the resources (functions) that the Non-OCF device 7000 has. Type information with a unique value may be assigned depending on the type (e.g., dimming, color temperature control, on/off, etc. in the case of lighting).

Accordingly, the value of the unique identifier of the Non-OCF device 7000 shown in (A) of FIG. 4 may correspond to '0x020104'. Meanwhile, the type information can be used to generate resource type information of the corresponding Non-OCF device 7000, which will be described later in FIG. 5.

Meanwhile, Figure 4 (B) schematically shows an OCF identifier assigned based on the unique identifier of the Non-OCF device 7000 shown in Figure 4 (A).

As shown in (B) of FIG. 4, the OCF identifier can be assigned a predetermined size required by the OCF standard, preferably a hexadecimal number with 32 digits (total size of 16 bytes). Additionally, the OCF identifier can be assigned by adding a unique value to the front of the unique identifier received from the Non-OCF device 7000.

More specifically, the OCF identifier allocation step (S15) of assigning an OCF identifier includes an OCF identifier generation step of generating the OCF identifier by attaching the location information of the Non-OCF device (7000) to the front of the unique identifier. can do.

The location information of the Non-OCF device 7000 may include service ID information and detailed location information, as shown in (B) of FIG. 4. The service ID information may correspond to ID information corresponding to the service location of the Non-OCF device (7000). For example, if the Non-OCF device 7000 is located in 'ㅇㅇ Apartment', the service ID information may correspond to a unique value meaning 'ㅇㅇ Apartment'. In Figure 4(B), the service ID information of the non-OCF device 7000 is shown in hexadecimal '69 63 6F 6E - 74 72 - 6F 6C - 73'.

Meanwhile, the detailed location information of the Non-OCF device 7000 may correspond to ID information corresponding to the location of the detailed area where the Non-OCF device 7000 is installed at the service location. For example, if the Non-OCF device (7000) is located in 'Room 503, Building 101' of 'ㅇㅇ Apartment', the detailed location information may correspond to a unique value meaning 'Room 503, Building 101'. . In Figure 4(B), the detailed location information of the Non-OCF device 7000 is shown in hexadecimal '12 - 34 56 78'.

In this way, the OCF identifier allocation step (S15) can generate an OCF identifier by attaching the location information of the non-OCF device (7000) to the front of the unique identifier of the non-OCF device (7000). Since the unique identifier of the OCF device 7000 is used as is, the OCF identifier can be effectively generated, and the location of the Non-OCF device 7000 can be easily determined through the OCF identifier.

Figure 5 schematically shows the process of generating resource type information according to the type information of the Non-OCF device 7000 according to an embodiment of the present invention.

As shown in FIG. 5, the resource type information generation step (S16) is the non-OCF device 7000 included in the OCF identifier assigned using a mapping table in which the resource type corresponding to the type information is stored. The resource type information may be generated based on one or more resource types corresponding to the type information.

Specifically, the resource type information generation step (S16) may generate resource type information based on the type information included in the unique identifier of the Non-OCF device 7000. More specifically, the wall pad device 5000 stores a mapping table, and the mapping table includes each type information and resource type information corresponding to each type information.

As shown in FIG. 5, when the Non-OCF device 7000 is a smart lighting, the type information may have a hexadecimal value of 01 to 04, and resource type information corresponding to each type information is stored in the mapping table. It can be saved. For example, as shown in Figure 5, when the type information is 0x01, the corresponding resource type information can only have resources of 'on/off', and when the type information is 0x02, 'on/off' and ' Resource type information with two resources of 'dimming' may correspond, and when the type information is 0x03, resource type information with two resources of 'on/off' and 'color temperature' may correspond, and type information When is 0x04, resource type information having three resources: 'on/off', 'dimming', and 'color temperature' may correspond. In this way, resource type information mapped to each type information can be stored in the mapping table, and resource type information can be generated based on the type information and mapping table included in the unique identifier of the non-OCF device (7000). .

Meanwhile, the resource type information shown in FIG. 5 may be generated in various forms corresponding to the OCF standard, for example, in hexadecimal form with a predetermined size. Additionally, Non-OCF type information not only includes information about one or more resources included in the device, but may also mean information about the type of the device. For example, when the type information is 01 to 04, it means smart lighting, and when the type information is 05 to 07, it means a smart plug. Depending on the value of the type information, what type of device it is, and It can also indicate what resources it contains at the same time.

The resource type information generated in this way is transmitted to the OCF client device 4000, allowing the OCF client device 4000 to know what resources each Non-OCF device 7000 contains, and the OCF client Allows the device 4000 to control the resources of a specific Non-OCF device 7000.

Figure 6 schematically shows screens of the wall pad device 5000 according to an embodiment of the present invention.

(A) in FIG. 6 corresponds to a screen on which the main interface is displayed on the wall pad device 5000. As shown in (A) of FIG. 6, elements that can execute a plurality of functions provided by the wall pad device 5000 are displayed on the main interface, and element E1 in (A) of FIG. 6 is selected by the user. The OCF device control unit 5120, which controls one or more OCF devices 8000 connected to the wall pad device 5000, can be executed according to the input. Additionally, element E2 can perform the steps for relaying the OCF client device 4000 and the non-OCF device 7000 described above according to the user's selection input.

Figure 6(B) corresponds to a diagram schematically showing the screen displayed on the wall pad device 5000 when element E2 is selected. As shown in (B) of FIG. 6, the screen displays a list of one or more Non-OCF devices (7000) and one or more OCF devices (8000) that can be connected to the OCF client device (4000). The displayed list includes the type of each device, the name of the device, ID information of the controller (E/M) 6000 connected to each device, ID information of each device, type information, communication status information, and OCF client device ( 4000) and setting information may be included.

Meanwhile, the screen shown in (B) of FIG. 6 displays one or more devices connected to the wall pad device 5000 when the virtual OCF client 5300 requests information about one or more devices connected to the wall pad device 5000 to the legacy control unit 5100. It may be displayed based on the unique identifier received from the device.

Figure 6 (C) corresponds to a diagram schematically showing a screen displaying a list including the current connection status between one or more devices connected to the wall pad device 5000 and the OCF client device 4000. The list may include the unique identifier, name information, and current connection status of each device. That is, through the screen shown in (C) of FIG. 6, the user can recognize the status of the non-OCF device 7000 and OCF device 8000 that are currently connected to the OCF client device 4000.

Meanwhile, the screen shown in (C) of FIG. 6 requests information about the current connection status with each device from the legacy control unit 5100 to the virtual OCF client 5300, and receives information from the virtual OCF client 5300. The virtual OCF server 5200, which has received the request, transmits information about the current connection status with each device to the legacy control unit 5100 through the virtual OCF client 5300, so that the list is updated to the wall pad device 5000. It may also be displayed in .

Figure 6(D) schematically shows a screen for controlling one or more non-OCF devices 7000 and one or more OCF devices 8000 connected to the wall pad device 5000. As shown in (D) of FIG. 6, one or more devices connected to the wall pad device 5000 can be controlled according to input on the corresponding screen. Meanwhile, when it is desired to control the one or more Non-OCF devices (7000), the corresponding devices can be controlled through the Non-OCF device control unit (5110) included in the legacy control unit (5100), and the one or more OCF devices When it is desired to control the device 8000, the device can be controlled through the OCF device control unit 5120 included in the legacy control unit 5100. Additionally, as shown in (D) of FIG. 6, the user may individually control one or more devices connected to the wall pad device 5000, or may control all one or more devices at once.

(E) of FIG. 6 shows a list containing the power usage of one or more non-OCF devices (7000) connected to the wall pad device (5000) and the power usage of the devices measured by the controller (6000) connected to the OCF device (8000). It corresponds to a drawing schematically showing the screen being displayed. As shown in (E) of FIG. 6, the list includes a unique identifier for one or more devices connected to the wall pad device 5000, name information, current power usage of the device, accumulated power usage for the current month, and status information. may be included. More specifically, the non-OCF device control unit 5110 and the OCF device control unit 5120 included in the wall pad device 5000, preferably the wall pad device 5000, are connected to the corresponding controller 6000 from the controller 6000. ) can receive information about the power usage of devices connected to the device, and display the list accordingly.

In another embodiment of the present invention, the Non-OCF device control unit 5110 and the OCF device control unit 5120 periodically request and receive information about power usage from the controller 6000, and the wall pad device 5000 ) stores information on periodically received power usage, and when displaying the list, may display the list based on information on strategic usage stored in the wall pad device 5000.

According to an embodiment of the present invention, the Wallpad device can control Non-OCF devices using a legacy protocol, and can control Non-OCF devices using an OCF-based protocol at the request of an OCF client device. Therefore, it can be effective in using both legacy protocols and OCF-based protocols.

According to one embodiment of the present invention, the Wallpad device can control Non-OCF devices by onboarding with the OCF client device, thereby achieving the effect of controlling Non-OCF devices through the OCF client device.

According to one embodiment of the present invention, the Wallpad device allocates an OCF identifier for the Non-OCF device in order to provide information about the Non-OCF device to the OCF client device, and the assigned OCF identifier is not newly created. Since it is assigned based on the previously assigned unique identifier of the Non-OCF device, it can effectively allocate OCF identifiers.

According to one embodiment of the present invention, the resource type information of the Non-OCF device is generated through the resource type information generation step performed by the wallpad device and provided to the OCF client device, so that the Non-OCF device that the OCF client device wants to control It can have the effect of allowing the functions (resources) of the OCF device to be used.

According to an embodiment of the present invention, the Wallpad device can control Non-OCF devices using a legacy protocol, and can control Non-OCF devices using an OCF-based protocol at the request of an OCF client device. Therefore, it can be effective in using both legacy protocols and OCF-based protocols.

According to one embodiment of the present invention, the Wallpad device can control Non-OCF devices by onboarding with the OCF client device, thereby achieving the effect of controlling Non-OCF devices through the OCF client device.

According to one embodiment of the present invention, the Wallpad device allocates an OCF identifier for the Non-OCF device in order to provide information about the Non-OCF device to the OCF client device, and the assigned OCF identifier is not newly created. Since it is assigned based on the previously assigned unique identifier of the Non-OCF device, it can effectively allocate OCF identifiers.

According to one embodiment of the present invention, the resource type information of the Non-OCF device is generated through the resource type information generation step performed by the wallpad device and provided to the OCF client device, so that the Non-OCF device that the OCF client device wants to control It can have the effect of allowing the functions (resources) of the OCF device to be used.

As described above, although the embodiments have been described with limited examples and drawings, various modifications and variations can be made by those skilled in the art from the above description. For example, the described techniques are performed in a different order than the described method, and/or components of the described system, structure, device, circuit, etc. are combined or combined in a different form than the described method, or other components are used. Alternatively, appropriate results may be achieved even if substituted or substituted by an equivalent. Therefore, other implementations, other embodiments, and equivalents of the claims also fall within the scope of the claims described below.

Claims (6)

It is a wallpad device that uses OCF (Open Connectivity Foundation)-based protocols and legacy protocols in combination,
A legacy control step of controlling one or more Non-OCF devices connected to the wall pad device and the one or more Non-OCF devices using a legacy protocol;
A query receiving step of receiving a query from an OCF client device connected to the same network as the wallpad device;
An OCF identifier allocation step of allocating an OCF identifier to each of one or more non-OCF devices connected to the wall pad device based on the query;
A resource type information generation step of generating resource type information for each of the one or more Non-OCF devices based on the OCF identifier of each of the one or more Non-OCF devices;
A Non-OCF device information providing step of transmitting OCF identifier and resource type information of each of the one or more Non-OCF devices to the OCF client device; and
Based on the selection of one or more Non-OCF devices by the OCF client device that has received the OCF identifier and resource type information of each of the one or more Non-OCF devices, the OCF client device and the selected one or more Non-OCF devices are selected. Onboarding and performing an OCF control step of controlling the selected one or more Non-OCF devices based on input from the OCF client device,
The OCF identifier allocation step is,
A unique identifier receiving step of receiving a unique identifier from each of the one or more Non-OCF devices; and
An OCF identifier generation step of generating an OCF identifier with a predetermined size for each of the one or more Non-OCF devices based on each unique identifier and the location information of each of the one or more Non-OCF devices,
The unique identifier received from each of the one or more Non-OCF devices is,
Contains ID information of the non-OCF device and the controller electrically connected to the wall pad device, ID information of the non-OCF device, and type information of the non-OCF device,
The location information is,
A wall pad device that includes service ID information corresponding to the service location of the non-OCF device and detailed location information corresponding to the location of the detailed area where the non-OCF device is installed.
In claim 1,
The wall pad device,
Includes a virtual OCF server and a virtual OCF client,
The query reception step is,
When receiving an onboarding request from the OCF client device, receive the query from the virtual OCF server after onboarding the virtual OCF server and the OCF client device,
The Non-OCF device information provision step is,
The OCF identifier and resource type information of each of the one or more Non-OCF devices are transmitted to the virtual OCF client, and the virtual OCF server receives the OCF identifier and resource type information of each of the one or more Non-OCF devices from the virtual OCF client. A wallpad device that receives and transmits to the OCF client device.
delete delete In claim 1,
The resource type information creation step is,
A wall pad that generates the resource type information based on one or more resource types corresponding to the type information of the non-OCF device included in the OCF identifier assigned using a mapping table in which the resource type corresponding to the type information is stored. Device.
As a method of using a legacy protocol and a protocol based on OCF (Open Connectivity Foundation) performed on a wallpad device,
A legacy control step of controlling one or more Non-OCF devices connected to the wall pad device and the one or more Non-OCF devices using a legacy protocol;
A query receiving step of receiving a query from an OCF client device connected to the same network as the wallpad device;
An OCF identifier allocation step of allocating an OCF identifier to each of one or more non-OCF devices connected to the wall pad device based on the query;
A resource type information generation step of generating resource type information for each of the one or more Non-OCF devices based on the OCF identifier of each of the one or more Non-OCF devices;
A Non-OCF device information providing step of transmitting OCF identifier and resource type information of each of the one or more Non-OCF devices to the OCF client device; and
Based on the selection of one or more Non-OCF devices by the OCF client device that has received the OCF identifier and resource type information of each of the one or more Non-OCF devices, the OCF client device and the selected one or more Non-OCF devices are selected. An OCF control step of onboarding and controlling the selected one or more Non-OCF devices based on input from the OCF client device,
The OCF identifier allocation step is,
A unique identifier receiving step of receiving a unique identifier from each of the one or more Non-OCF devices; and
An OCF identifier generation step of generating an OCF identifier with a predetermined size for each of the one or more Non-OCF devices based on each unique identifier and the location information of each of the one or more Non-OCF devices,
The unique identifier received from each of the one or more Non-OCF devices is,
Contains ID information of the non-OCF device and the controller electrically connected to the wall pad device, ID information of the non-OCF device, and type information of the non-OCF device,
The location information is,
A method of using the OCF protocol and legacy protocol together, including service ID information corresponding to the service location of the non-OCF device and detailed location information corresponding to the location of the detailed area where the non-OCF device is installed.