JP4984898B2 - Equipment management device - Google Patents

Description

  The technical field relates to a device management apparatus that controls or manages devices.

  In recent years, home devices such as AV devices, white goods, and home appliances have begun to have a network connection function. Along with this, user needs regarding centralized control of home devices via a network, status monitoring, and cooperation between devices are increasing.

  Patent Document 1 discloses that “a module for controlling home appliances connected on a home network is automatically obtained and a communication control device and a communication control method that can be automatically updated” are provided. As a means for solving the problem, “a communication control apparatus connected to a home network and an external network, the control means for giving a predetermined command to home appliances via the home network, and the home network” Provided in the form of a Web screen to the above terminal device for control of home appliances requested from the terminal device, and provided from the terminal device through the interface in the form of the Web screen, Web server means for giving a predetermined command to the home appliance to the control means, and each external network via the external network It is disclosed that the image processing apparatus includes an acquisition unit for acquiring a file serving as an interface in the form of a Web screen for controlling each home electric appliance from a predetermined server device corresponding to the electric device. See summary).

JP-A-2004-213251 ([0010], [0011])

However, the technical idea disclosed in Patent Document 1 has the following problems.
In patent document 1, there is no consideration about the detailed procedure in which a home gateway detects a household appliance. Therefore, it is difficult for the home gateway to detect the home appliance. There is an ECHONET standard defined by the ECHONET consortium as a network standard for controlling home appliances, and there are descriptions of properties that the ECHONET equipment should have, but about the detection procedure of equipment using them There is no detailed provision. Therefore, it is difficult to detect an ECHONET device even in the ECHONET standard.

  Further, according to the technical idea disclosed in Patent Document 1, a file (based on providing a terminal device with an interface for operating a device based on information on home appliances detected by the home gateway in the form of a Web screen) CGI) is downloaded, but there is no consideration for the detailed procedure for actually operating the device in the CGI. For example, in the ECHONET standard, in the ECHONET protocol, a device to be controlled is specified using an ECHONET address for operation, but the ECHONET address may change every time the device is activated. Therefore, in order for CGI to control home appliances, a procedure is required for matching the invariant information and the ECHONET address for each device. However, since the detailed procedure for that is not considered in the prior art, there is no consideration about the third operator creating CGI and getting into the system shown in the prior art.

In addition, there is no consideration regarding software componentization technology in a device generally called a home gateway (or home server). For example, the OSGi service platform is known as a software componentization technology for the home gateway, but the method disclosed in Patent Document 1 does not consider the OSGi service platform.
The OSGi service platform includes an OSGi framework that implements lifecycle management such as downloading, installation, and execution of various software components (bundles) and interface (service) management with other bundles, an HTTP server, and UPnP. Standard bundles such as device management and control are included, and it is beginning to be recognized as a standard technology for devices generally called home gateways.

  In order to solve the above-described problem, an embodiment of the present invention is an apparatus that manages a device, and includes a driver that detects a device connected to a network and a function that manages software of the device. The driver registers device information (software) in the framework based on the information received from the device.

  More specifically, it has means for exchanging information with the ECHONET device via the physical layer defined by the ECHONET standard, and the individual identification information property acquired from the ECHONET device is already described in the individual identification information management table. The instance list property of the ECHONET device having the individual identification information when the acquired individual identification information property is not described in the individual identification information management table. An instance list acquisition means for acquiring (a list of instance codes), a service identification information generation function for generating service identification information that uniquely identifies the ECHONET device service from the individual identification information and the instance code, and the OSGi framework Registered ECH It has an individual identification information filter creation function for creating a filter for filtering only services having individual identification information from the NET device service, and the individual identification information using the filter created by the filter creation function from the OSGi framework Service identification information comparison that has a filtering service reference acquisition function that acquires only the service reference of the ECHONET device service that has the service identification information that does not correspond to the acquired service reference among the service identification information created by the service identification information generation function And an ECHOENT device service having service identification information that does not correspond to the service reference acquired by the service identification information comparison means as an ECHONET device service. And configured to have an OSGi framework registration function of registering the new device management device in the OSGi framework Te.

  Further, the device management apparatus has an individual identification information acquisition unit that acquires an individual identification information property from the ECHONET device described in the individual identification information management table, and when the individual identification information property acquisition unit is executed, Configuration having individual identification information acquisition response investigation means for examining whether or not there is a response, and ECHONET device service deletion means for deleting the ECHONET device service having the corresponding individual identification information from the OSGi framework when there is no response It was.

  Further, the device management apparatus has an ECHONET property acquisition / setting unit for acquiring and setting an ECHONET property value for a desired ECHONET device service.

  Further, the device management apparatus has an event filter creating means for creating a filter for acquiring only an event from a desired ECHONET device. After setting the event filter, the ECHONET event listener implementation object is set to the OSGi framework. It has the structure which has the event listener registration means registered into.

  Further, the device management apparatus has an event acquisition unit that acquires an event from the ECHONET device, and receives an event that generates service identification information of the corresponding ECHONET device service from the acquired event and information described in the individual identification information management table And an event notification means for notifying an ECHONET event listener implementation object corresponding to the service identification information.

According to the above means, for example, control of in-home equipment can be facilitated.
Issues, means, and effects other than those described above will also be described in the description of embodiments described later.

(1) Overview An overview of the operation of the device control apparatus in the present embodiment will be described. In the present embodiment, a device control apparatus that corresponds to the ECHONET standard and uses an OSGi service platform as a software component technology will be described. The ECHONET standard defines an ECHONET Java (registered trademark) API for handling ECHONET messages from Java (registered trademark). This ECHONET Java (registered trademark) API is also called ECHONET middle. A part that performs device detection, disconnection monitoring, and event management using the ECHONET middle is also referred to as an ECHONET driver. A portion including the ECHONET middle and the ECHONET driver is also referred to as an ECHONET bundle. Also, the OSGi framework (OSGi FW) is a part that implements lifecycle management such as downloading, installing, and executing various software components (bundles) in the OSGi service platform and interface (service) management functions with other bundles. Say. In addition, a device corresponding to the ECHONET standard is also referred to as an ECHONET device.

A procedure for registering information about the ECHONET device in the OSGi framework will be described with reference to FIG.
First, the ECHONET driver acquires information about the ECHONET device (also referred to as “individual identification information”) via the ECHONET middle (S501 to S505). The ECHONET driver determines whether or not the acquired individual identification information has been registered in an individual identification information management table described later (S506). If not registered, the individual identification information is registered in the individual identification information management table (S507).

  The ECHONET driver acquires a list of device objects (objects for controlling the actual device) held by the ECHONET device indicated by the individual identification information via the ECHONET middle (S508 to S515). The ECHONET driver registers the ECHONET device service corresponding to the unregistered device object in the OSGi framework based on the acquired list of device objects held by the ECHONET device (S516 to S520). In this way, information about the ECHONET device can be registered in the OSGi framework.

  By registering information about the ECHONET device in the OSGi framework, disconnection monitoring for monitoring whether the ECHONET device has left the home network, device control for controlling the ECHONET device, event registration for registering an event in the ECHONET device, Event notification acquisition for acquiring an event can be realized. These operations will be described later with reference to FIGS.

(2) Details Details of the operation of the device control apparatus according to this embodiment will be described with reference to the drawings.
FIG. 1 is a diagram showing an example of a network structure in the present embodiment. In this figure, 101 is a home device management apparatus, 102 is a home network, and 103, 104, and 105 are ECHONET devices. The in-home device management apparatus 101 is connected to the ECHONET device via the home network 102 and can exchange information. The home appliance management apparatus is also called a home gateway.

  The home network 102 is a network to which home ECHONET devices can be connected. The home network 102 is, for example, a wired IP network using an Ethernet (registered trademark) cable or a wireless IP network using IEEE802.1x or Bluetooth. In the ECHONET standard, the physical layer of the network for exchanging information between the ECHONET devices can be realized by using a specific low power radio, a power line, etc., and the hardware configuration of the in-home device management apparatus and the ECHONET device is those networks. The procedure in the following description can be applied as long as it conforms to.

  The ECHONET devices 103, 104, and 105 are devices that can exchange information with the home device management apparatus via the home network 102. The ECHONET equipment includes, for example, a television, a recorder, and an air conditioner.

FIG. 2 is an example of a hardware configuration diagram of the home appliance management apparatus 101.
The in-home device management apparatus 101 includes a CPU (Central Processing Unit) 201, a main memory 202, an EPROM (Erasable Programmable Read Only Member) 203, a nonvolatile storage device 204, and a LAN I / F (Local Area Network Interface) 205. . Each component is connected by a bus 206 so that necessary information can be transmitted.

The CPU 201 performs a predetermined operation by a program stored in advance in the EPROM 203 or the nonvolatile storage device 204. The CPU is also called a central processing unit, and is a device that controls each device and calculates / processes data.
The main memory 202 functions as a work memory. The main memory is also called a main storage device, and is a device that stores data and programs. It operates at high speed and can be read and written directly from the CPU.

The EPROM 203 is a read-only memory capable of erasing and writing a record any number of times, and is a means for storing a necessary program.
The non-volatile storage device 204 is a means for storing a necessary program or information to be stored in a non-volatile manner. The nonvolatile storage device 204 is, for example, a compact flash (registered trademark) or a hard disk.

  The LAN I / F 205 is a means for transmitting / receiving information to / from other devices via a communication network. The LAN I / F 205 is realized by, for example, a network adapter, a wireless transmission / reception device, or the like. The LAN is also called a local area network, and the I / F is also called an interface. Note that unnecessary components among the components of the home appliance management apparatus 101 may be omitted from the configuration. For example, if there is no information to be stored in a nonvolatile manner, the nonvolatile storage device 204 can be removed from the configuration of FIG.

FIG. 3 is an example of a hardware configuration diagram of the ECHONET devices 103, 104, and 105.
The ECHONET devices 103, 104, and 105 include a CPU 301, a main memory 302, an EPROM 303, and a LAN / IF 305. Each component is connected by a bus 307 so that necessary information can be transmitted.

The CPU 301 performs a predetermined operation by a program stored in the EPROM 303 in advance. The CPU is also called a central processing unit, and is a device that controls each device and calculates / processes data.
The main memory 302 functions as a work memory. The main memory is also called a main storage device, and is a device that stores data and programs. It operates at high speed and can be read and written directly from the CPU.

The EPROM 303 is a read-only memory that can erase and write a record any number of times, and is a means for storing a necessary program.
The LAN / IF 305 is means for transmitting / receiving information to / from the home device management apparatus 101 and / or other devices via a communication network. The LAN / IF 305 is realized by, for example, a network adapter, a wireless transmission / reception device, or the like. The LAN is also called a local area network, and the I / F is also called an interface. Note that unnecessary components among the components of the ECHONET devices 103, 104, and 105 can be removed from the configuration.

Next, a program that operates on the home appliance management apparatus 101 will be described.
The home appliance management apparatus 101 is equipped with an OSGi service platform defined by the OSGi consortium. The OSGi service platform is a Java (registered trademark) -based software componentization technology, and includes an OSGi framework and software operating on the OSGi framework. This software is also called a bundle. Bundles that run on the OSGi framework are HTTP servers (computers with the function of sending information via the World Wide Web; also called Web servers) and UPnP (Universal Plug and Play). Standard bundles included in the OSGi service platform, such as management and control of devices that support devices, telephones, home appliances and other devices connected via a network and provide functions to each other) and OSGi services There are user bundles implemented according to the basic method.

The OSGi framework is an abbreviation of API (Application Program Interface) for managing the life cycle such as downloading, installing, starting, and stopping a bundle, and for operating other bundles operating on the OSGi framework. A set of instructions and functions that can be used when developing software for the OS and middleware).
A bundle can register its API as a service in the OSGi framework and accept operations from other bundles.

  In the present embodiment, on the OSGi framework operating on the home device management apparatus 101, ECHONET devices are detected, services are registered in the OSGi framework to control the detected devices, and notification events from the ECHONET devices are managed. It is assumed that the ECHONET device management bundle to be operated is operating. This ECHONET device management bundle is also referred to as an ECHONET bundle.

  The ECHONET bundle detects an ECHONET device connected to the home network and registers it as an ECHONET device (Echonet Device) service in the OSGi framework. Further, the ECHONET bundle can notify the event information received from the ECHONET device in the home to the ECHONET event listener (Echonet Event Listener) service. The ECHONET device service is a service registered in the OSGi framework and indicates a device object of the ECHONET device. A bundle operating on the OSGi framework acquires an ECHONET device service from the OSGi framework, and exchanges information on the device object of the ECHONET device by acquiring and setting information on the ECHONET device with respect to the ECHONET device service. Can do. The Echonet Event Listener (ECHONET event listener) is an interface for a bundle operating on the OSGi framework to acquire an event from the ECHONET device. A bundle can receive an event from an ECHONET device by implementing an ECHONET event listener and registering an object of the ECHONET event listener as an ECHONET event listener service in the OSGi framework.

The application software that operates the ECHONET device in the home acquires the ECHONET device service from the OSGi framework, and uses the ECHONET property (Echonet Property) value setting and reading of the ECHONET device service API to the ECHONET device in the home. Control can be performed. Application software is also called application bundle.
In addition, the application bundle implements the interface of the ECHONET event listener provided by the ECHONET bundle, and registers with the OSGi framework as an ECHONET event listener service, thereby acquiring event information acquired by the ECHONET bundle and performing desired processing. be able to.

Next, table information in the present embodiment will be described.
FIG. 4 is an individual identification information management table 400 held by the ECHONET bundle. A column 401 is individual identification information, a column 402 is an ECHONET address, and a column 403 is a re-search waiting number.
The individual identification information management table is a table for managing individual identification information of the ECHONET device, and stores individual identification information and an ECHONET address corresponding to the individual identification information. In addition, individual identification information and the number of waiting times for re-search corresponding to the individual identification information are stored. The individual identification information management table 400 is stored on the main memory 202 of the home appliance management apparatus 101 during the operation of the ECHONET bundle, or is read from the nonvolatile storage device 204 onto the main memory 202 when the ECHONET bundle is activated. The data is stored in the nonvolatile storage device 204 again at a predetermined timing such as when the table is updated or when the ECHONET bundle ends.

  A column 401 for storing individual identification information stores individual identification information held by the ECHONET device. Individual identification information is device-specific identification information defined by the ECHONET standard, and is read from the ECHONET device by the ECHONET protocol (a communication protocol for exchanging information between ECHONET devices via the network). Can do. The ECHONET bundle reads the individual identification information from the ECHONET device when the ECHONET device is detected, and stores it in the individual identification information management table 400.

  The column 402 for storing ECHONET addresses stores ECHONET addresses that are address information on the ECHONET protocol held by the ECHONET device. The ECHONET address is information added to information exchanged by the ECHONET protocol (ECHONET message). The ECHONET message always includes the ECHONET address of the information source and the ECHONET address of the information destination. The ECHONET bundle stores the ECHONET address included in the ECHONET message at the time of reading the individual identification information when the individual identification information is read from the ECHONET device when the ECHONET device is detected and stored in the individual identification information management table 400.

  A column 403 for storing the number of waiting for re-search stores the number of waiting for re-searching, which is an index used when the ECHONET bundle detects an ECHONET device and searches for the device once detected. When the ECHONET bundle first stores the individual identification information in the individual identification information management table 400, the re-search waiting number is stored as zero. The ECHONET bundle periodically searches the individual identification information of the ECHONET devices in the home by the device detection flow described later, and corresponds to the individual identification information when received after the individual identification information is entered in the individual identification information management table 400 The re-search waiting number to be incremented by 1 (a process of increasing the value of the integer type variable by 1). If the re-search waiting number is equal to or greater than a certain value X (for example, 3) determined by the system, the ECHONET device instance corresponding to the individual identification information is re-searched.

Next, the operation in this embodiment will be described.
In this embodiment, the ECHONET bundle operating on the OSGi framework on the in-home device management apparatus 101 is used to monitor disconnection of ECHONET devices connected to the home network (detection and monitoring of disconnection from the network), and the detected ECHONET devices. The API to be controlled is registered in the OSGi framework as an ECHONET device service, and notification events from ECHONET devices in the home are managed. The processing related to these home device management apparatuses is realized by executing various programs by the CPU 201 of the home device management apparatus. Further, processing related to the ECHONET device described below (response to a request from the home device management apparatus, etc.) is realized by executing various programs by the CPU 301 of the ECHONET device. Note that some or all of the functions may be realized by hardware.

FIG. 5 is a sequence diagram showing a procedure from detection of an ECHONET device connected to the home network to registration as an ECHONET device service in the OSGi framework.
The ECHONET standard defines an ECHONET Java (registered trademark) API for handling ECHONET messages from Java (registered trademark). This ECHONET Java (registered trademark) API is also called ECHONET middle. The ECHONET bundle is an ECHONET middle, an ECHONET driver that performs device detection, disconnection monitoring, and event management (event management including event registration and event notification acquisition) using the ECHONET middle, and control of the ECHONET device. And an ECHONET service API that performs event acquisition.

In the ECHONET device detection and OSGi framework registration procedures in FIG. 5, the ECHONET middle API and the OSGi framework API are standard APIs defined by the ECHONET standard and the OSGi service platform, respectively.
ECHONET communication in the IP network (abbreviation for Internet Protocol. It defines a method for assigning addresses of devices participating in the network and selecting communication paths in a plurality of interconnected networks.) Since UDP is an abbreviation for User Datagram Protocol. It is a standard protocol used on the Internet, and it bridges the network layer IP and the protocol above the session layer. Therefore, each ECHONET message usually has a correlation. do not have. However, the ECHONET middle implements a mechanism to respond to the API caller after waiting for a response to the ECHONET message transmitted by itself, so that the ECHONET middle performs synchronous ECHONET communication. be able to.

  The ECHONET middle receives event information transmitted by the ECHONET device, but can also hold an API for notifying all the event information to the upper software. In the present embodiment, it is assumed that the ECHONET driver has been set in advance to notify all events to the ECHONET middle (at startup).

  Here, the module configuration of the ECHONET bundle will be described in more detail. The ECHONET bundle is an ECHONET service API that allows higher-level bundles to operate ECHONET devices via the ECHONET device service. ECHONET devices that are connected to the network are discovered and registered as ECHONET device services on the OSGi framework. An ECHONET driver that notifies an event from a device to a higher-level bundle, and a module such as ECHONET middleware that is a module that implements the “Level 2 ECHONET basic API (Java (registered trademark) language version)” defined in the ECHONET standard . FIG. 22 is a conceptual diagram of the module configuration of the ECHONET bundle. The ECHONET bundle realizes the functions such as dynamic connection / disconnection, control, and event notification by using these modules.

  Next, the ECHONET service API will be described. The ECHONET service API is a module that provides an API for operations and event acquisition to the upper bundle. FIG. 23 shows a class diagram of the ECHONET service API. The white part (the part without shading) in the figure is the ECHONET service API. When the ECHONET driver finds an ECHONET device on the home network, it registers an ECHONET device service corresponding to the device in the OSGi framework. By searching for and acquiring ECHONET device services registered in the OSGi framework, the upper bundle can know and control the existence of ECHONET devices connected to the home network. All events from the ECHONET device are first acquired by the ECHONET driver via the ECHONET middle. The ECHONET driver acquires the ECHONET event listener service implemented by the upper bundle and registered in the OSGi framework, and notifies the upper bundle of the event.

The sequence diagram of FIG. 5 will be described. In S501 and S502, the ECHONET driver uses the ECHONET middle to send an individual ECHONET device node profile (communication module profile) to the multicast address (IPv4 address, 224.0.23.0) defined in the ECHONET standard. A request for acquiring the property of the identification information (hereinafter referred to as “individual identification information acquisition request”) is transmitted. Means for realizing the processing of S501 and S502 is also referred to as individual identification information registration investigation means.
In S503, the ECHONET device monitors information reaching the multicast address, and the ECHONET device that has received the individual identification information acquisition request responds to the individual identification information acquisition request (hereinafter referred to as “individual identification information” with respect to the source ECHONET address). "Acquisition response"). In S504 and S505, the ECHONET middle receives the individual identification information acquisition response and transmits the received individual identification information acquisition response to the ECHONET driver.

  In S506, the ECHONET driver that has received the individual identification information acquisition response from the ECHONET middle checks whether or not the received individual identification information has been registered in the individual identification information management table 400 shown in FIG. Here, if the received individual identification information is unregistered in the individual identification information management table 400, the ECHONET driver uses the individual identification information received in S507 and the ECHONET address of the transmission source of the individual identification information as the individual identification information management table 400. And set the waiting time for re-search to 0.

  In S508 to S515, the ECHONET driver obtains a list of device objects held by the ECHONET device of the received individual identification information. Although ECHONET communication is performed between ECHONET communication functions, a plurality of device objects may correspond to one ECHONET communication function (for example, a human sensor and a communication module of one ECHONET device If a temperature sensor is attached). Since the control of the ECHONET device is performed on the device object, the ECHONET bundle acquires a list of device objects and registers the device object as an ECHONET device service in the OSGi framework. Here, the device object is also referred to as an instance, and the ECHONET communication function is also referred to as an ECHONET node.

  In S508 and S509, the ECHONET driver requests the ECHONET device to acquire its own node instance number property, which is the number of device objects held by the ECHONET device, through the ECHONET middle (hereinafter referred to as “own node instance number acquisition request”). .) In S510 and S511, the ECHONET device transmits a response to the own node instance number property acquisition request (hereinafter referred to as “own node instance number acquisition response”) to the ECHONET driver via the ECHONET middle. Means for realizing the processing of S508 and S509 is also referred to as instance number acquisition means.

In S512 and S513, the ECHONET driver requests the ECHONET device to acquire its own node instance list, which is a list of device objects attached to the node, according to the received own node instance number property, via the ECHONET middle (hereinafter, referred to as “Echonet device”). "Own node instance list acquisition request") is transmitted. Means for realizing the processing of S512 and S513 is also referred to as instance list acquisition means.
In S514 and S515, the ECHONET device transmits a response to the own node instance list acquisition request (hereinafter referred to as “own node instance list acquisition response”) to the ECHONET driver via the ECHONET middle.

  In the ECHONET standard, there are two types of properties that provide a list of device objects attached to a node. One is called the own node instance list property, and the own node instance list is provided when the device object attached to the node is not 5 or less (that is, 6 or more). The other is called a self-node instance list S property, and provides a self-node instance list when the number of device objects associated with the node is 5 or less.

  Therefore, the ECHONET driver checks the number of device objects held by the acquired ECHONET device, and transmits a local node instance list acquisition request to the ECHONET device according to the value. In steps S516 to S520, the ECHONET device service is registered with the OSGi framework for each device object based on the acquired local node instance list. A bundle operating on the OSGi framework can exchange information with an ECHONET device via an ECHONET device service.

  In S516, service identification information is created for each acquired instance. The service identification information is information that uniquely identifies an ECHONET device by a bundle operating on the OSGi framework. The service identification information is generated from the individual identification information and the ECHONET object (information indicating the type of device, instance information for distinguishing when there are a plurality of devices of that type, and information on the local node instance list). In S501 to S515, the ECHONET driver acquires the individual identification information of the ECHONET device and the ECHONET object of the device object, and the bundle uses, for example, which object (first air conditioner, etc.) of which ECHONET device based on the individual identification information and the ECHONET object. This is because it can be uniquely identified.

  Here, a specific example of creation of service identification information is given. It is assumed that the individual identification information holds 2-byte information, and the ECHONET object holds 3-byte information. For example, when the individual identification information is 0x0006 in hexadecimal notation and the ECHONET object is 0x007001 (assuming a human sensor having the first instance code), the service identification information is "0006-007001" in character string notation. Try to write. By creating the service identification information in this way, the service identification information can uniquely identify the device object.

  On the other hand, in the OSGi service infrastructure, when registering a service in the OSGi framework, service property information (which is different from the property in ECHONET) can be added. As a property indicating service specific identification information, service. Since the property “pid” exists, in this embodiment, the service.service when registering the ECHONET device service is used. The service identification information described above is set in pid. That is, service. The content of pid = 0006-007001 is registered in the OSGi framework in association with the ECHONET device service. The means for realizing the processing of S516 is also referred to as service identification information generation means.

In S517 to S519, the ECHONET driver checks the ECHONET device service registered in the OSGi framework.
In S517, the ECHONET driver makes a request for acquiring a list of ECHONET device services to the OSGi framework (hereinafter referred to as “ECHONET device service list acquisition request”). When this ECHONET device service list acquisition request is made, a service can be acquired by creating a filter in addition to the service name (here, the name of the ECHONET device service). By using a filter, for example, service. It is possible to obtain only services with a certain value of pid. As an example of the method, a wild card can be specified for the filter. In order to obtain a list of ECHONET device services for devices whose individual identification information is 0x0006, service. It may be specified as pid = 0006- * ("*" is a wild card).

  The ECHONET driver creates filter information using the individual identification information so as to acquire only the ECHONET device service created from the device object of the ECHONET device that has received the individual identification information. Means for realizing the process of creating the filter information is also referred to as individual identification information filter creation means. In addition, means for realizing processing for obtaining an ECHONET device service having arbitrary individual identification information using this filter is also referred to as filtering service reference obtaining means.

In S518, the OSGi framework returns a list of ECHONET device services that conform to the filter information (hereinafter referred to as “ECHONET device service list acquisition response”).
In S519, the ECHONET driver acquires service.service of the acquired ECHONET device service. The pid is checked, and compared with the service identification information created above, a device object that is not registered in the OSGi framework is checked. Means for realizing the processing of S519 is also referred to as service identification information comparison means.

  In S520, the ECHONET driver generates an ECHONET device object corresponding to the unregistered device object, and then sets service. Service identification information is set in pid and registered as an ECHONET device service in the OSGi framework. An ECHONET device object is a service entity that the ECHONET driver registers with the OSGi framework as an ECHONET device service. The bundle registered in the OSGi framework searches for the ECHONET device service from the OSGi framework, and acquires the ECHONET device object as a return value when the service is acquired. The means for realizing the processing of S520 is also referred to as OSGi framework registration means.

  In the sequence diagram of FIG. 5, the operation of the ECHONET bundle has been described separately for the ECHONET driver and the ECHONET middle. However, the ECHONET middle is a function for transmitting an ECHONET message according to the request of the ECHONET driver. And ECHONET middle will be described together as an “ECHONET bundle”.

6, 7, 8, and 9 are sequence diagrams describing from ECHONET device detection to ECHONET device service registration in the OSGi framework, as in FIG. 5.
Further, in FIGS. 5, 6, 7, 8, and 9, (1), (2), (2) -1, (2) -1 ', (2) -2, (2) -3. The ranges written as “” indicate procedures in the same processing range. The process (1) corresponds to the flowchart of FIG. The process (2) corresponds to the flowchart of FIG. There are subroutines (2) -1, (2) -1 ′, (2) -2, and (2) -3 in the process (2), and the process (2) -1 is shown in FIG. Corresponds to the flowchart. The process (2) -1 ′ corresponds to the flowchart of FIG. The process (2) -2 corresponds to the flowchart of FIG. The process (2) -3 corresponds to the flowchart of FIG.

  10 to 15, the procedure from the detection of the ECHONET device described in FIG. 5 to the registration of the ECHONET device service in the OSGi framework will be described using a flowchart. FIG. 10 is a flowchart showing a procedure (S501 and S502 in FIG. 5) for the ECHONET bundle to start device detection. The ECHONET bundle repeatedly performs device detection during activation.

  First, in S1001, it is confirmed that the ECHONET bundle is operating and the termination process has not been started (the operation continues). If the operation is not continued (NO in S1001), the process is terminated. If the operation continues (in the case of YES in S1001), the process proceeds to S1002, and a node profile individual identification information property acquisition request is transmitted to the multicast address (IPv4, 224.0.23.0) defined in the ECHONET standard. The process moves to S1003. In S1003, it stops for a certain period of time, and returns to S1001 again.

  FIG. 11 is a flowchart showing a procedure (S503 to S520 in FIG. 5) from device discovery to ECHONET device service registration in the OSGi framework. Processing is performed each time an individual identification information property acquisition response is received from the ECHONET device.

In S1101, an individual identification information acquisition response is received from the ECHONET device.
In 1102, it is investigated whether or not the acquired individual identification information is registered in the individual identification information management table 400 shown in FIG. If there is no registration (YES in S1102), the flow proceeds to a flow for registering a new ECHONET device in S1103 (also referred to as “new device search flow”), and then the flow proceeds to S1105. If there is a registration (NO in S1102), the process proceeds to a flow for examining a registered device in S1104 (also referred to as a “registered device examination flow”), and then proceeds to S1105. The new device registration flow will be described in more detail with reference to FIG. 12, and the registered device examination flow will be described in more detail with reference to FIG.

  S1105 is a flow for searching for a device object held by the ECHONET device (also referred to as “instance search flow”), and then the process proceeds to S1106. This instance search flow will be described in more detail with reference to FIG.

  S1106 is a flow for registering a device object held by the ECHONET device in the OSGi framework (also referred to as an “OSGi registration flow”). Here, the device object held by the ECHONET device is registered in the OSGi framework, and the process ends. This OSGi registration flow will be described in more detail with reference to FIG.

FIG. 12 is a flowchart of the new device registration flow in S1103 of FIG.
In S1201, the individual identification information received in S1101 of FIG. 11 is registered in the individual identification information management table 400. At this time, the ECHONET address of the source of the ECHONET message included in the ECHONET message received in S1101 is also registered. The re-search waiting number is set to zero. Thereafter, the process proceeds to S1202.

  In S1202, the instance search flag is set to true, and the process ends. The instance search flag is referred to in an instance search flow (FIG. 14) described later. The instance search flag is a flag for determining whether the ECHONET bundle performs an instance search. When the flag is true, the instance search is executed in the instance search flow.

FIG. 13 is a flowchart of the registered device examination flow in S1104 of FIG.
In S1301, the individual identification information and the ECHONET address of the message transmission source are acquired from the ECHONET message of the individual identification information acquisition response received in S1101 of FIG. 11, and registered in the row of the individual identification information acquired from the individual identification information management table 400. And the ECHONET address of the transmission source of the ECHONET message of the individual identification information acquisition response are compared. If the ECHONET address described in the individual identification information management table 400 is different from the ECHONET address of the transmission source of the ECHONET message of the individual identification information acquisition response (YES in S1301), the process proceeds to S1302, and the individual identification information management table 400 Is rewritten to the ECHONET address of the transmission source of the ECHONET message of the individual identification information acquisition response. Thereafter, the process proceeds to S1303. If NO in S1301, the process proceeds to S1303.

  Next, in S1303, it is investigated in the individual identification information management table 400 whether or not the number of waiting times for re-search corresponding to the individual identification information received in S1101 in FIG. If it is equal to or greater than X (YES in S1303), the process moves to S1304, the instance search flag of the individual identification information management table 400 is set to true, and the process moves to S1305. In step S1305, the waiting time for re-searching corresponding to the individual identification information received in step S1101 in FIG. 11 in the individual identification information management table 400 is cleared to 0, and the process ends. If it is not X or more (NO in S1303), the process proceeds to S1306, the instance search flag of the individual identification information management table 400 is set to false, and the process proceeds to S1307. In step S1307, the re-search waiting number corresponding to the individual identification information received in step S1101 in FIG. 11 in the individual identification information management table 400 is incremented by 1, and the process is terminated. The instance search flag is referred to in the instance search flow of FIG.

  As described above, for the ECHONET device whose individual identification information has already been registered in the individual identification information management table 400, it is investigated whether the ECHONET address has been changed, and whether to re-search the device object. By making the determination, for example, it corresponds to the possibility of occurrence of packet loss due to exchange of ECHONET messages in the IP network by UDP, or the case where the device object is added while the ECHONET device is activated. be able to. That is, it is possible to suppress an increase in the amount of information flowing through the network by re-searching the detected device every time by checking whether or not the re-search waiting number is X or more in S1303. In the present embodiment, the detected device is searched only once in X times.

FIG. 14 is a flowchart of the instance search flow in S1105 of FIG.
In S1401, the instance search flag described with reference to the flowchart of FIG. 12 or 13 is referred to, and it is determined whether or not the instance search flag is true. If the instance search flag is not true (if NO in S1401, if false), the process ends. If the flag is true (YES in S1401), the process proceeds to S1402.

In S1402, the local node instance number property of the node profile is acquired from the ECHONET device that is the transmission source of the ECHONET message of the individual identification information acquisition response received in S1101 of FIG. 11, and the process proceeds to S1403.
In S1403, it is checked whether the acquired number of own node instances is 6 or more. If 6 or more (YES in S1403), the process proceeds to S1404. If it is 4 or less (NO in S1403), the process proceeds to S1405. .

In S1404, the local node instance list property of the node profile is acquired from the ECHONET device, and the process ends.
In S1405, the local node instance list S property of the node profile is acquired from the ECHONET device, and the process ends.

  Here, it will be described about investigating whether or not the number of local node instances acquired in S1403 is 6 or more. According to the ECHONET standard, when the number of own node instance lists is “5 or less”, the own node instance list property does not have to be mounted, and when “6 or more”, only the total number is described in the own node instance list S. There is. Therefore, in the subsequent flow, when the number of own node instances is 5 or less, the own node instance list S property is acquired, and when the number is 6 or more, the own node instance list property is acquired. Since this embodiment is described based on the ECHONET standard, there is a step of S1403. However, this step may be deleted if there is no such regulation.

FIG. 15 is a flowchart of the OSGi registration flow of S1106 in the procedure of FIG.
In S1501, service identification information of the ECHONET device service is created from the individual identification information received in S1101 of FIG. 11 and the own node instance list property acquired in S1404 or the own node instance list S property acquired in S1405, and S1502 Move on. Here, as described in FIG. 5, identification information for uniquely identifying the device object from the individual identification information and the ECHONET object is created for each device object.

  In S1502, filter information for acquiring the ECHONET device service corresponding to the ECHONET device of the individual identification information received in S1101 of FIG. 11 from the OSGi framework is created, and the process proceeds to S1503. The filter is as described in FIG.

In S1503, a list of ECHONET device services corresponding to the filter information created in S1502 is acquired from the OSGi framework, and the process proceeds to S1504.
In S1504, the service identification information created in S1501 and the service.service ECHONET device service acquired in S1503. The pids are compared, a device object that is not registered in the OSGi framework is checked, and the process proceeds to S1505.

In S1505, an ECHONET device object corresponding to an unregistered instance is generated, and service.service.info (service information given to a service registered in the OSGi framework) is set as service. After setting pid (service identification information), the service is registered in the OSGi framework as an ECHONET device service (with an ECHONET device service name).
The above is the procedure for detecting the ECHONET device and registering it in the OSGi framework in this embodiment. Thereby, the application bundle can uniquely distinguish each device object on the home network.

Here, the correspondence between the sequence diagrams of FIGS. 6, 7, 8, and 9 and the flowcharts of FIGS. 10, 11, 12, 13, 14, and 15 will be clarified.
FIG. 6 is the same processing as the procedure of FIG. 5, but the individual identification information is not registered in the individual identification information management table 400 in S1102 of FIG. 11, and the number of own node instances is 6 in S1403 of FIG. This is the procedure in the above case.

  FIG. 7 shows that the individual identification information has already been registered in the individual identification information management table 400 in S1102 of FIG. 11, the number of waiting for re-search is equal to or greater than a certain number X in S1303 of FIG. 13, and in S1403 of FIG. This is a procedure when the number of local node instances is not 6 or more.

  FIG. 8 shows the procedure when the individual identification information has already been registered in the individual identification information management table 400 in S1102 of FIG. 11 and the re-search waiting number is not more than a certain number X in S1303 of FIG.

  FIG. 9 shows a procedure when the individual identification information is not described in the individual identification information management table 400 in S1102 of FIG. 11, and the number of local node instances is not 6 or more in S1403 of FIG.

  Next, a disconnection monitoring procedure for monitoring whether the ECHONET device has left the home network (whether it has been disconnected from the network) will be described.

FIG. 16 is a flowchart of disconnection monitoring.
Disconnect monitoring continues to operate while the ECHONET bundle is operating.
In S1601, it is confirmed that the operation of the ECHONET bundle is continuing. If the operation is continuing (YES in S1601), the process proceeds to S1602, and if the operation is not continuing (NO in S1601), processing is performed. Exit.

In S1602, a list of ECHONET device services registered in the OSGi framework is acquired from the OSGi framework, and the process proceeds to S1603.
In S1603, the property of the operation state of the device object superclass is acquired from each acquired ECHONET device service, and the process proceeds to S1064. The device object super class is a property of all device objects defined by the ECHONET standard.

  In S1604, it is investigated whether or not the response of S1603 is returned from the ECHONET device (the ECHONET device is operating). Here, the value returned as the property of the operation status does not matter, and if there is a response, the corresponding device object is in a state where communication is possible via the home network, so it is determined that it is online. Also good. If there is no response, it may be determined that the home network has been disconnected. If there is no response (YES in S1604), the process proceeds to S1605, and if there is a response (NO in S1604), the process proceeds to S1608.

In S1605, the ECHONET device service with no response is deleted from the OSGi framework, and the process proceeds to S1606.
In S1606, it is investigated whether there is any other device object having the same individual identification information as the ECHONET device service deleted in S1605. That is, the service.service service property of the ECHONET device service acquired in S1602. pid is checked, and service. of ECHONET device service deleted in S1605. It is investigated whether there is any other ECHONET device service having the same individual identification information as the individual identification information described in pid. If there is another ECHONET device service having the same individual identification information (NO in S1606), the process proceeds to S1608. If there is no other ECHONET device service having the same individual identification information (YES in S1606), the process proceeds to S1607.

In S1607, information corresponding to the individual identification information corresponding to the ECHONET device service deleted in S1605 is deleted from the individual device information management table 400, and the process proceeds to S1608.
In S1608, the operation is stopped for a predetermined time, and the process returns to S1601.

  The procedure of FIG. 16 is a procedure for monitoring disconnection for each ECHONET device service, that is, for each device object of the ECHONET device. In this case, it is possible to cope with a case where only a device object is deleted while a node that is a communication module of an ECHONET device is operating, but there is also a drawback that the amount of information flowing on the home network increases.

FIG. 17 is a flowchart showing the procedure for cutting monitoring, similar to FIG.
The procedure of FIG. 17 is a procedure for monitoring disconnection of the ECHONET device for each node that is a communication module. The procedure of FIG. 17 has a smaller amount of information flowing on the home network than the procedure of FIG. 16, but has a drawback that disconnection cannot be detected when only the device object is disconnected while the node is operating.

  In S1701, it is confirmed that the operation of the ECHONET bundle is continuing. If the operation is continuing (YES in S1701), the process proceeds to S1702, and if the operation is not continuing (NO in S1701), processing is performed. Exit.

  In S1702, all the individual identification information registered in the individual identification information management table 400 is read out, a node profile individual identification information acquisition request is sent to each of them, and the process proceeds to S1703. The means for realizing the processing of S1702 is also referred to as individual identification information acquisition means.

  In S1703, it is confirmed whether there is a response to the request in S1702))). If there is a response (NO in S1703), it is determined to be online and the process proceeds to S1708. If there is no response (YES in S1703), it is determined that the user is offline and the process proceeds to S1704. The means for realizing the processing of S1703 is also referred to as individual identification information acquisition response determination means.

In S1704, a filter for acquiring an ECHONET device service having individual identification information that has not been responded in S1703 from the OSGi framework is created, and the process proceeds to S1705.
In S1705, a list of ECHONET device services corresponding to the filter generated in S1704 is acquired from the OSGi framework, and the process proceeds to S1706.

  In S1706, all ECHONET device services acquired in S1705 are deleted from the OSGi framework, and the process proceeds to S1707. Means for realizing the processing of S1706 is also referred to as ECHONET device service deletion means.

In S1707, the individual identification information of the ECHONET device having the individual identification information that has not been responded in S1703 is deleted from the individual identification information management table 400, and the process proceeds to S1708.
In S1708, it stops for a certain period of time and returns to S1701.

  The above is the procedure for monitoring the disconnection of the ECHONET device in the present embodiment. By the above-described ECHONET device detection procedure and disconnection monitoring procedure, the in-home device management apparatus in the present embodiment can know the entry and withdrawal of the ECHONET device from the in-home network.

  Next, an example of a procedure in which another bundle operating on the OSGi framework controls the ECHONET device using the ECHONET device service registered by the ECHONET bundle in the OSGi framework will be described.

FIG. 18 is a flowchart illustrating an example of an operation for controlling a device. Here, a procedure in which a bundle operating on the OSGi framework controls temperature setting for an air conditioner device will be described. A bundle that operates on the OSGi framework is also referred to as an application bundle.
In S1801, the application bundle creates a filter for acquiring the ECHONET device service of the air conditioner device from the ECHONET device service registered in the OSGi framework, and proceeds to S1802. In other words, service.service, which is a service property of the ECHONET device service. Create a filter that filters what pid represents an air conditioner. For example, service. The pid is “* -0130 *”. That is, the individual identification number and the instance code of the ECHONET object are used as wild cards.

In S1802, a list of ECHONET device services corresponding to the filter created in S1801 is acquired, and the process proceeds to S1803.
Here, a case where a plurality of air conditioner devices exist in the home is not assumed, but a process of determining a desired air conditioner device from a plurality of air conditioner devices may be added as necessary. For example, by acquiring the property of the installation location of the device object superclass from each of the ECHONET device services acquired in S1802, it is possible to control only the air conditioner device in a desired room.

  In S1803, an ECHONET property object provided by the ECHONET bundle is generated, a value for the temperature setting property (that is, “temperature”) is set, and the process proceeds to S1804. The ECHONET property is information indicating a value corresponding to EPC (information that can be acquired from or settable by a device defined by the ECHONET standard for each device type) defined by the ECHONET standard for each device type. Here, the temperature setting property is one of the ECHONET properties of the air conditioner device.

In S1804, the value of the ECHONET property object generated in S1803 is set for the temperature setting property of the air conditioner in the ECHONET device service to be controlled, and the process ends. Means for realizing the processing of S1802 and S1803 is also referred to as ECHONET property acquisition and setting means.
The above is an example of the control of the ECHONET device by the application bundle in the present embodiment.

Next, a procedure for the application bundle to acquire an event from a desired ECHONET device will be described.
FIG. 19 is a flowchart illustrating an example of a procedure in which an application bundle registers an event acquisition service (an implementation object in an application bundle of an ECHONET event listener interface provided by the ECHONET bundle) with the OSGi framework. This event acquisition service is also referred to as an ECHONET event listener service. An event is, for example, notifying that a human sensor has detected the presence of a person in the sensor, or notifying that the power supply of an air conditioner has been turned “ON”. A human sensor is a type of sensor that can determine whether a person is present around the sensor. Here, a procedure for registering the ECHONET event listener service in the OSGi framework in order for the application bundle to acquire a human sensor event is shown.

  In S1901, filter information for acquiring an event from the human sensor is created, and the process proceeds to S1902. For example, service. A filter that acquires an event from a device whose pid is “* -0070 *” is created. The filter information is registered as a service property when registering the ECHONET event listener service. Key information used for registration is defined in the ECHONET event listener interface defined in the ECHONET bundle. Further, the Value information corresponding to the Key information can be filtered with higher flexibility by enabling AND and OR conditions in addition to wild cards. For example, when it is desired to acquire an event from a human sensor or an air conditioner device, it can be expressed as (service.pid = *-0070 *) | (service.pid = *-0130 *)). Means for realizing the processing of S1901 is also referred to as event filter creation means.

  In S1902, an ECHONET event listener implementation object that controls the event to be acquired is generated, and the process proceeds to S1903. Since the OSGi service infrastructure is based on Java (registered trademark), specifically, only the interface of the ECHONET event listener is defined in the ECHONET bundle. The application bundle creates an ECHONET event listener implementation class by implementing the ECHONET event listener interface and describing the actual processing. The specific content of S1902 is to generate an object of the ECHONET event listener implementation class.

  In S1903, the ECHONET event listener implementation object generated in S1902 is registered as an ECHONET event listener service with the filter information generated in S1901 as a service property and registered in the OSGi framework. Means for realizing the processing of S1903 is also referred to as event listener registration means.

  The above is the flowchart of event registration. By registering an event, the application bundle can easily receive only an event from a desired ECHONET device. Further, by applying a filter, it is possible to easily receive a notification from any human sensor or air conditioner.

Next, an event notification acquisition procedure for acquiring an event from the ECHONET device will be described.
FIG. 20 is a flowchart showing a procedure for acquiring an event notification.
In S2001, the ECHONET bundle acquires an event notification from the home device (ECHONET device in the home), and the process proceeds to S2002. The process of S2001 is also referred to as an event acquisition unit.

  In S2002, the ECHONET address of the transmission source included in the ECHONET message from the device that sent the event notification is acquired. Individual identification information corresponding to the acquired ECHONET address is acquired from the individual identification information management table 400, service identification information is created together with the transmission source ECHONET object included in the ECHONET message, and the process proceeds to S2003. Means for realizing the processing of S2002 is also referred to as event reception time service identification information generation means.

  In S2003, filter information for acquiring the corresponding ECHONET event listener service from the OSGi framework is created using the service identification information created in S2002, and the process proceeds to S2004.

  In S2004, a list of ECHONET event listener services corresponding to the filter information generated in S2003 is acquired from the OSGi framework, and the process proceeds to S2005.

  In S2005, it is investigated whether or not the ECHONET event listener service has been acquired in S2004. If there is no service (NO in S2005), the process is terminated. If there is a service (YES in S2005), the process proceeds to S2006.

  In S2006, an EchonetEvent object describing the event notification acquired in S2001 is generated, and the process proceeds to S2007. Here, the event notification from the ECHONET device is, for example, the content that what property of which device of which type has what value. Since the information “what kind of which device” is included in the service identification information, it is only necessary that the EchonetEvent object includes information “what property has become what value”.

  In S2007, the service identification information and the EchonetEvent object generated in S2006 are notified to the application bundle for all ECHONET event listener services acquired in S2004. Means for realizing the processing of S2007 is also referred to as event notification means.

  The above is the procedure for managing events of the home appliance management apparatus in the present embodiment. By doing so, there is an effect that it is easy to notify an event from the ECHONET device to the application bundle that is a notification destination of the event, and the processing efficiency can be improved.

FIG. 21 is a sequence diagram illustrating an example of the operation of the ECHONET device using the home device management apparatus according to the present embodiment.
In FIG. 21, the application bundle performs an operation of turning on the illumination when the human sensor event is acquired.

In step S <b> 2101, the application bundle creates filter information for acquiring a human sensor event.
In S2102, an ECHONET event listener implementation object is generated.
In S2103, after setting the filter information in the service property, the ECHONET event listener implementation object is registered in the OSGi framework as an ECHONET event listener service.

Steps S2101 to S2103 are similar to the registration of the event acquisition service described with reference to FIG.
In S2104, when the human sensor reacts, the human sensor notifies the human body detection information property to the home network (multicast address).
In S2105, the ECHONET bundle receives the notification, reads the individual identification information corresponding to the ECHONET address of the device that has notified the event from the individual identification information management table 400, and identifies the ECHONET object and the individual identification of the device that has notified the event. The service identification information of the device that has notified the event is generated from the information.

In S2106, filter information corresponding to the service identification information is created.
In S2107, the ECHONET bundle transmits a request for acquiring a list of ECHONET event listener services corresponding to the filter information to the OSGi framework.
In S2108, the OSGi framework returns a response to the request for the ECHONET bundle in S2107 to the ECHONET bundle.

In S2109, an EchonetEvent object corresponding to the corresponding ECHONET event listener service is generated.
In S2110, the EchonetEvent object generated in S2109 is changed to service. It notifies the ECHONET event listener service provided by the application bundle together with the pid.
In S2111, the ECHONET event listener implementation object of the application bundle receives the notification and creates filter information corresponding to the lighting device.

In step S2112, the application bundle transmits a request for acquiring a list of ECHONET device services corresponding to the filter information to the OSGi framework.
In S2113, the OSGi framework returns a response to the request in S2112 to the application bundle.
In S2114, an ECHONET property object is generated, and the value of “ON” is set as the property of the operating state of the lighting device. The ECHONET property object is an object in which a value is set in the ECHONET property.

In S2115, the application bundle requests to set the value (ON) set in the ECHONET property object in S2114 for the property of the operation state of the lighting device of the ECHONET device service.
In S2116, the ECHONET bundle performs control to turn on the operation state of the corresponding ECHONET device according to the application bundle request in S2115.
In S2117, the illumination is turned on by controlling the ECHONET bundle in S2116.
The above is an example of the operation of the ECHONET device in the present embodiment.

  As described above, the ECHONET bundle can monitor the connection / disconnection state of the ECHONET device by detecting and disconnecting the ECHONET device in the house. In addition, the device detected in the ECHONET device management table 400 is managed using the individual identification information property of the node profile, and the detected device is periodically checked whether the combination of the individual identification information and the ECHONET address has changed. Thus, the devices can be distinguished and controlled without changing the ECHONET address by restarting the ECHONET device.

  In addition, by registering ECHONET devices as services on the OSGi framework (ECHONET device services) for each device object (instance, ECHONET object), an application bundle that operates on the OSGi framework has property values for the ECHONET device. Control such as setting and reading can be performed.

  When the ECHONET bundle registers the ECHONET device service in the OSGi framework, service.service. By setting the service identification information generated from the individual identification information of the ECHONET device and the device object information in pid, the application bundle can uniquely distinguish each device object on the home network.

  Further, by registering the ECHONET event listener implementation object in the OSGi framework by applying the service identification information, the application bundle can easily receive only an event from a desired ECHONET device.

  When an ECHONET device is controlled or an event is notified, an object is not directly exchanged between the application bundle and the ECHONET bundle, and an ECHONET device service and an ECHONET event listener service are always acquired via the OSGi framework. Since the OSGi framework manages and understands the life cycle of the bundle, even if the application bundle or ECHONET bundle terminates unexpectedly, it prevents a serious impact on the entire system, such as a memory leak. Can do.

  The standard filter included in the OSGi service platform can be used as the filter that is generated when acquiring the ECHONET device service list or EchonetEventListener described in this embodiment. Therefore, the creator of the application bundle can easily create a program using a standard filter even when only the object of a desired device and the event from the desired device are to be acquired. Furthermore, since the OSGi service-based filter function can be represented by wild cards, AND, OR, etc., it is possible to use high functions and flexible programming in the standard.

  In the present embodiment, the ECHONET standard has been described. However, the present invention is not limited to the ECHONET standard.

It is a network block diagram in a present Example. It is a hardware block diagram of the household appliance management apparatus in a present Example. It is a hardware block diagram of the ECHONET apparatus in a present Example. It is an individual identification information management table in a present Example. FIG. 5 is a sequence diagram from device detection to OSGi framework registration in the present embodiment. FIG. 5 is a sequence diagram from device detection to OSGi framework registration in the present embodiment. FIG. 5 is a sequence diagram from device detection to OSGi framework registration in the present embodiment. FIG. 5 is a sequence diagram from device detection to OSGi framework registration in the present embodiment. FIG. 5 is a sequence diagram from device detection to OSGi framework registration in the present embodiment. It is a flowchart of the apparatus search start in a present Example. It is a flowchart from discovery of the apparatus in a present Example to registration to OSGi FW. It is a flowchart which adds the individual identification information of the newly discovered apparatus in a present Example to an individual identification information management table. It is a flowchart which shows the procedure which examines whether to search again for an instance with respect to the apparatus already described in the individual identification information management table in a present Example. It is a flowchart which shows the procedure at the time of performing an instance search with respect to the ECHONET node which has a certain individual identification information in a present Example. It is a flowchart which shows the procedure until a certain instance corresponding to a certain individual identification information in a present Example is registered into OSGi FW as an ECHONET device service. It is a flowchart of disconnection monitoring of an OSGi registered device in this embodiment. It is a flowchart of disconnection monitoring of an OSGi registered device in this embodiment. It is a flowchart when the application software in a present Example performs control which changes the temperature setting of an air-conditioner apparatus. It is a flowchart which registers the listener with which the application software in a present Example acquires the event from a human sensitive sensor apparatus. It is a flowchart in which the application software in a present Example acquires the event notification from a human sensitive sensor apparatus. It is a sequence diagram which shows an example of the cooperation operation | movement of the ECHONET apparatus in a present Example. It is a conceptual diagram of the module structure of the ECHONET bundle in a present Example. It is a class diagram of ECHONET service API in a present Example.

Explanation of symbols

101 Home Device Management Device 102 Home Network 103 ECHONET Device 104 ECHONET Device 105 ECHONET Device 201 CPU
202 Main memory 203 EPROM
204 Non-volatile storage device 205 LAN / IF
206 Bus 301 CPU
302 Main memory 303 EPROM
305 LAN / IF
307 Bus 400 Individual identification information management table 401 Individual identification information 402 ECHONET address 403 Re-search waiting number

Claims (7)

A device management apparatus that manages one or more ECHONET devices, which are devices compliant with the ECHONET standard, via a network,
Between the ECHONET device, and means for exchanging information via the physical layer to the provisions of the ECHONET standard,
A request for acquiring the individual identification information is periodically transmitted to a multicast address defined in the ECHONET standard of the network, an individual identification information acquisition response is received from the ECHONET device connected to the network, and the individual identification is performed. An individual identification information acquisition means for acquiring and associating the individual identification information previously given to the ECHONET device included in the information acquisition response and the ECHONET address set after the ECHONET device is activated;
Acquired addressed to the corresponding ECHONET address to the said individual identification information, transmits an acquisition request for the list in which an instance list of objects of the ECHONET device having the individual identification information, the ECHONET equipment in use the ECHONET address An instance list acquisition means for receiving the instance list from:
Specify the ECHONET device service, which is a device object registered in the OSGi framework , from the acquired individual identification information corresponding to the ECHONET address and the code of the object of the ECHONET device included in the acquired instance list Service identification information generating means for generating service identification information to be
Service identification information comparison means for investigating whether or not the ECHONET device service associated with the generated service identification information has been registered in the OSGi framework ;
By the service identification information comparing unit, when the ECHONET device services associated with the service identification information is confirmed not to be the service registered in the OSGi framework, associated with said ECHOENT device service with the service identification information Te has a OSGi framework registration means for registering the OSGi framework
A device management apparatus characterized by that . The device management apparatus according to claim 1,
An individual identification information management table for managing predetermined individual identification information for identifying the ECHONET device;
Individual identification information registration investigating means for investigating whether or not the individual identification information acquired from the ECHONET device has been registered in the individual identification information management table;
When the acquired individual identification information is not registered in the individual identification information management table, the individual identification information and the ECHONET address included in the individual identification information acquisition response are registered in the individual identification information management table. With means to
A device management apparatus characterized by that. In the apparatus management apparatus according to claim 1 or 2 ,
And individual identification information acquisition response determining means for determining whether or not there is a response from the ECHONET device when said identification information acquisition means performs an operation for acquiring the identification information,
Having a ECHONET Device Service deleting section that deletes the ECHONET device services from the OSGi framework with the individual identification information judged that there is no response in said individual identification information acquisition response determining means
A device management apparatus characterized by that . In the equipment management device according to any one of claims 1 to 3 ,
For any of the ECHONET device services, the acquisition of values that control the ECHONET equipment, ECHONET property acquired for setting, with a setting means
A device management apparatus characterized by that . A device management apparatus that manages one or more ECHONET devices, which are devices compliant with the ECHONET standard, via a network,
An individual identification information management table for managing the individual identification information for identifying the ECHONET device in association with the ECHONET address set after the ECHONET device is activated;
Means for exchanging information with the ECHONET device via a physical layer defined by the ECHONET standard;
A request for acquiring the individual identification information is periodically transmitted to a multicast address defined in the ECHONET standard of the network, an individual identification information acquisition response is received from the ECHONET device connected to the network, and the individual identification is performed. The individual identification information previously given to the ECHONET device and the ECHONET address set after activation of the ECHONET device included in the information acquisition response are acquired and managed in association with each other in the individual identification information management table Individual identification information acquisition means;
And event acquiring means for receiving an event notification from the ECHONET device,
The individual identification information management table is referred to, individual identification information corresponding to the ECHONET address included in the event notification is acquired , and the ECHONET device service is obtained from the individual identification information and the transmission source ECHONET object included in the ECHONET message. An event reception service identification information generating means for generating the service identification information of
Is registered, among the ECHONET event listener implementation object for controlling the event, has for ECHONET event listener implementation object corresponding to the generated the service identification information, and event notification means for notifying the acquired event, the
A device management apparatus characterized by that . In the equipment management device according to claim 5,
An individual identification information management table for managing predetermined individual identification information for identifying the ECHONET device;
Individual identification information registration investigating means for investigating whether or not the individual identification information acquired from the ECHONET device has been registered in the individual identification information management table;
When the acquired individual identification information is not registered in the individual identification information management table, the individual identification information and the ECHONET address included in the individual identification information acquisition response are registered in the individual identification information management table. With means to
A device management apparatus characterized by that. In the apparatus management apparatus according to claim 5 or 6 ,
An event filter creation means for creating a filter to retrieve events from any of the ECHONET equipment,
Generating the ECHONET event listener implementation object has an event listener registration means for registering the OSGi framework
A device management apparatus characterized by that .

Images