WIRELESS PROTOCOL STACK BASED INSTALLATION BUS GATEWAY AND METHOD OF ITS OPERATION
The invention relates to the field of installation bus systems for office buildings, houses, motor homes and other multi purpose appliances as well as to home automation. It also relates to the access of home installation bus systems through a wireless radio connection. The invention also relates to embedded servers.
There are several competing systems for home automation, like European Installation Bus (EIB) and Lonworks. The purpose of installation bus technology is to decouple signaling between sensors and actors and the AC power distribution. So the devices are no longer controlled via a power cut-off switch, but via control datagrams sent over a separate control network. As a result, each sensor (switch, button, control pad,...) can be set up to control every actor (lamps, electric window blinds, electric garage door,..) or clusters of actors. Similarly, sensors (e.g. temperature, humidity etc) can be read out and actions based on these (e.g. switch on your heatmg) can be triggered.
The solution for this functionality is to have two networks: first the 110/220N power distribution network and, second, a low voltage network for control purposes. Alternatively, the control information can be transmitted through the power distribution network using modulation techniques. The "standard user interface" for these systems, is largely unchanged compared to plain old electrical installation, i.e. switches, dimmers, etc.
Conventional home installation bus systems mainly suffer from three problems:
First, the user interface for typical installation remains the same. During configuration you can configure which switch, dimmer, etc. shall trigger whatever action. This is usually done with a computer connected to the network. However, once configuration is done, the "user interface"
(and thus user experience) is the same as with plain old installation.
Second, the user interface (switches, dimmers) is usually mechanically mounted on the walls, like in plain old electrical installation.
Third, once the network is configured, there is no central point in the network, which stores the whole installation information. Instead, each sensor knows the actors which it controls and
nothing about other sensors and actors.
The state of the art further offers internet gateways connected to home installation busses for remote control purposes. Internet gateways on installation busses further solve the above mentioned problems but require a computer connected to the installation bus and the internet. Further is the use of a computer as an internet gateway a waste of resources and money as standard computers consume time, space and online fees. The computer and the internet connection further require firewalls and protection against unauthorized access and so on. Such an internet based remote control is described in the United States Patent Nr. 5,956,487 "EMBEDDING WEB ACCESS MECHANISM IN AN APPLIANCE FOR USER INTERFACE FUNCTIONS INCLUDING A WEB SERVER AND WEB BROWSER" granted to Hewlett- Packard company Palo Alto, Calif, on Sep. 21, 1999.
The object of the present invention is to overcome the above mentioned problems and to provide a versatile wireless protocol stack based installation gateway.
The invention overcomes the problems using an installation bus gateway (IBG): The IBG is a device being connected to the installation bus and containing a logic to communicate with the installation bus it is connected to. Moreover, the IBG can store all or part of the configuration data of the network, like bus addresses, sensor/actor human readable names, control scenarios and the like. The purpose of the IBG is to offer an option for remote control of devices being connected to the installation bus, notification of events being detected on the installation bus, and configuration purposes. There are three typical use cases for the IBG referred to in this document: • Use case 1 : Hypertext User Interface (UI) for wireless, short-range control purposes: This can be realized by the IBG by providing a wireless, short range connection to a mobile terminal
(e.g. mobile phone) which comprises a hypertext browser. The phone may access the home network's user interface being stored in a local server in hypertext format inside the IBG.
Thus, the mobile phone can serve as a general purpose, mobile remote control device for all devices connected to the installation bus. Actions on the installation bus can be invoked by hypertext request triggering and parameterizing the execution of server side code, which in turn triggers the desired actions on the installation bus. An example implementation of the
IBG would use WAP as hypertext language and Bluetooth as a short range connection means.
• Use case 2: remote notification: In another use case, the IBG connects to a nearby terminal over a short-range, wireless link (e.g. Bluetooth serial profile) and uses said nearby terminal in order to send messages (e.g. short messages SMs) to a remote terminal over a wide-range communication network (e.g. GSM). These messages are generated by the IBG upon certain
events on the installation bus, e.g. indicating burglar alarms, temperature drop and the like. • Use case 3: remote control through messaging: Still another use case is that a remote phone sends messages (like SMS) to a local terniinal in the proximity of the IBG. The TBG connnects to the local terminal over a short-range, wireless link and periodically polls incoming messages. Subsequently, the messages polled are parsed inside the TBG for commands, like "switch on heating" that are executed subsequently.
According to a first aspect of the present invention, there is provided a method for remote controlling devices connected to an installation bus. The installation bus is connected via an installation bus gateway (TBG) containing a modem and a transceiver and via a wireless link to a remote control device comprising a browser, e.g., a wireless markup language (WML) browser. The TBG transfers a user interface comprising control options from the TBG to the remote control device by means of one or more contents request/response operations. This is executed e.g. by transferring a content request from the remote control device to the TBG generating or retrieving a user interface and transferring the user interface to the remote control device. In a first stage the request response operations can be used to transfer a user interface with certain control options to the remote control device. Subsequently, the user interface with the control options is displayed on the remote control device. The control options of the installation bus can be presented to the user by means of hyperlinks (or other interactive control widgets available in the respective content format like buttons), that reference the corresponding URLs on the server. The method of remote controlling devices comprises the transfer of a contents request to the installation bus modem whenever the user selects one of the hyperlinks or controls. Subsequently, the contents request is processed in said installation bus gateway to invoke the selected control option of the one or more devices by performing corresponding digital communication with the installation bus.
The transfer protocols can be used to transport presentation information, e.g. in WML (wireless markup language), XML (extended markup language ), XHTML (extended hypertext markup language) or any other markup language. This content request, typically including parameters, would typically invoke a server side script, e.g. via the CGI interface. Content request and response are transmitted over a wireless physical link using a suitable and widely used protocol stack, hi case of Bluetooth, the Personal Area Networking Profile or the LAN access Profile would constitute the lower part of the stack. The upper part of the stack could be realized in terms of TCP/IP/HTTP or the WAP protocol suite. The server side script invokes the desired commands on the installation bus by means of performing the corresponding communication (in EIB the so-called Physical External Interface constitutes a suitable interface) according to the interface and protocol specification of the Installation bus Interface. This results in datagrams
being sent over the bus to the devices under control and invoking the desired actions.
Preferably, the wireless link is a Bluetooth™ connection, but other low power radio or infrared connections are possible. The presentation language may be any suitable markup language like WML, HTML, XML or XHTML being widely deployed in commercially available handheld devices, like organizers and mobile phones. Therefore no compatibility problems are to be expected. The use of the existing technologies reduces the required development costs and enables the manufacturer to use elements well known from mobile phones.
Advantageously, the execution of the selected control option is confirmed in the hypertext response after execution. However, this can only be realized in case the installation bus itself supports the acknowledgement and confirmation of operations on connected devices. A hypertext response has to be returned to the terminal in all cases whether or not this contains such confirmation.
Advantageously, the TBG tracks bus events and the status of all devices inside the installation bus by constantly monitoring the communication on said installation bus. This status information is then used to
• reflect the status of the installation bus in the user interface (for example display the option "switch light off when light is currently on)
• notify events (like "burglar alarm" by means of push technology, e.g. WAP push)
• notify events as indicated in use case 2
The remote control device, e.g. a mobile phone, could also be used for network configuration. Network configuration is usually done with a special device or a computer being connected to the network. However, this is not advisable because of the poor UI of the remote control device (small screen, small keyboard, etc). At least small changes in an existing configuration would be possible, like creating new menu options that simply cluster two or more actions. For example, there may be two commands in the user interface to switch off two different lamps in the kitchen. The user could create a new command „kitchen light off combining these two commands.
According to another aspect of the invention (see use case 3), the devices connected to the installation bus can be controlled by the remote control device by means of messages received via a communication network, if the remote control device is connected to a communication network such as a mobile telephone network. This can be accomplished by the TBG polling messages from a remote control device being received by the remote control device from a communication network. If the remote control device stores such messages, the message is
transferred to the IBG. Subsequently, the messages polled are parsed for commands like "switch on heating". The parsed commands are processed in the installation bus gateway to invoke said commands of the one or more devices by performing corresponding digital communication with the installation bus.
*5
According to another aspect of the present invention a method for transferring status or event information of a device connected to an installation bus is provided: Another usage of the TBG (use case 2) is to send messages being triggered by special events on the installation bus. This use case is not directly related to the remote control concept or the WAP concept of use case 1 0 (its just a notification service), but can be realized with the same technical equipment, as far as the TBG is concerned. Thereby the device (e.g. alarm sensor) transmits an installation bus datagram via the installation bus to the installation bus gateway. Alternatively, this datagram is broadcasted onto the installation bus. The installation bus gateway receives and processes the installation bus datagram and stores the result (e.g. alarm on sensor #2). 5
Advantageously, incoming installation bus datagrams are assessed in the installation bus gateway. If the datagram notifies an important event, a message is generated by said installation bus gateway. The TBG now creates a wireless, short-range connection to a nearby terminal, which has a connection to a communication network. The TBG now uses dedicated commands in order 0 to cause said nearby Terminal to send the generated message to a predefined Terminal over said communication network. In case the technologies Bluetooth and GSM short message service (SMS) are used, this concept is realized as follows:
- A user wants to be notified on selected bus events. For example: burglar alarm. 5 - During configuration phase (see above comment) or using an options menu of the TBG, the user subscribes for this event and enters his mobile phone number into the IBG.
- The TBG detects a burglar alarm.
- A program inside the TBG searches for bluetooth phones in its proximity and find the user's second bluetooth phone, he left at home. The TBG creates a bluetooth connection to this 0 second phone and sends a short message (SM) to the users mobile phone via the second phone and the communication network. This can be accomplished by sending AT commands of bluetooth.
The user interface of the above use case is just the SMS application of the user's phone. By 5 processing and assessing or evaluating the installation bus datagram the installation bus gateway can decide, if the content of the datagram is worth being transferred via a network to a remote user.
The TBG and the remote control device can both comprise memory and other computing means to adapt, personalize and simplify the remote control options offered by the IBG by means of
• recorded user behavior, • location,
• time and date,
• temperature,
• etc.
Any discovered correlation within and between user interaction patterns and sensor time series can be used to improve the user interface.
According to another aspect of the invention a computer program product for remote controlling an installation bus with a wireless link is provided, that comprises loadable program code means for carrying out the steps of the aforementioned method of installation bus interaction when said program is run on a computer, a server, an installation bus gateway or a remote control device.
The distributed execution of the method in different devices requires different computer programs for the different devices participating in the communication between the installation device and the remote control device device.
According to yet another aspect of the present invention, the invention provides a computer program product, comprising program code means stored on a computer readable medium for carrying out the aforementioned method of installation bus interaction when said program product is ran on an installation bus gateway or a remote control device.
According to yet another different aspect of the present invention, an installation bus gateway (TBG) for remote controlling of a device connected via an installation bus is provided. The TBG can be electrically connected via an installation bus interface to the installation bus. In case of the ETB system, the Physical External Interface (PEI) would fulfil the purpose as such installation bus interface. The IBG further comprises a low power radio transceiver for communicating with a remote control device. Storage means in the TBG are used, e.g., to store the settings (Addresses, names, control scenarios, etc) of devices connected to said installation bus and remote control devices or the aforementioned algorithms necessary to decide if to transmit a SM. The TBG comprises processing means, which are connected to all the other elements of the TBG. The processing means can create and/or modify user interface content depending on detected events on the installation bus, and create the desired installation bus datagrams based on the requests
sent by the remote control device.
According to just another aspect of the present invention a bus connector for electrically connecting an installation bus gateway (TBG) with an installation bus (IB) is provided. A bus connector is a device that that provides a standard interface to allow devices to communicate with other devices being connected to the Installation bus. Typically, every installation Bus system has a different interface to connect application modules.
According to an additional aspect of the invention a remotely controllable installation bus system is provided for controlling home devices, comprising a remote control device as described above, an installation bus gateway as described above, which are interconnected via a low power radio link. The Installation bus gateway is connected to devices via an installation bus. The invention is better understood and illustrated by reference to the attached drawings in which:
Figure 1 depicts an embodiment of an installation bus system according to the invention, and
Figure 2 depict a flowchart of the method for remote controlling devices connected to an installation bus according to one embodiment of the present invention.
Figure 3 depicts another embodiment of an installation bus system according to the present invention.
Figure 4 depicts the configuration of the installation bus gateway according to the invention.
Figure 1 shows the basic setup for a simple installation bus system which is used to control devices 14, 16, 18 on the installation bus 12 or to read status information. This embodiment of the present invention proposes an embedded, Bluetooth™ enabled wireless application protocol (WAP) server (in the following referred to as TBG) which is integrated into an installation bus gateway 2 that is connected to a home installation bus 12 for remote control purposes. The TBG 2 is com ected via a bus connector 10 to the installation bus 12. The bus connector 10 provides a standard interface allowing the IBG to send and receive datagrams to and from the installation bus. The bus connector can be used to adapt mechanical or electrical the interfaces of the TBG 2 and the installation bus 12. The installation bus 12 interconnects different devices as, e.g. a washing machine 14, an aquarium 16, and an illumination device 18. Conventional installation bus input devices such as switches, dimmers and the like are not shown. The IBG 2 comprises different sub-elements as server side scripts- and applications 8, a WAP server 6 and a
bluetooth™-module 4 for low power radio transmissions. Server side scripts may be stored in native, machine dependant code, or in terms of a script language being interpreted by a script interpreter.
Thus, the TBG 2 can send datagrams to the installation bus 12, e.g. upon user interaction with a WAP/Bluetooth phone 20. For example, a WAP page displayed on the display 22 is offering the phone a "living room light on" link. If the user selects this link, a corresponding request is transmitted into the installation bus 12. The request triggers and parameterizes the execution of a server side script, which will create and send the corresponding datagram to the installation bus. As a result the light 18 is switched on. Or the user selects, e.g., a link "read aquarium 16 temperature" to retrieve the temperature of an aquarium 16 thermometer connected to the installation bus 12. In case, the thermometer sends its temperature back to the IBG, the temperature can be displayed on the phone's display 22 by the phone's WAP browser. Similarly, an event on the installation bus 12, like "fire alarm", can be pushed to the phone 20 through the TBG 2.
With such a system the following applications become possible:
Controlling all devices 14, 16, 18 on the installation bus 12 with a Bluetooth phone 20, e.g. switch on and off devices 16, 18, dim light 18, read aquarium 16 temperature, read washing machine 14 status, etc. Cluster actions
Configuration of the network ("in future, this switch shall switch off all lights, lock the house entrance-door and open the garage")
The implementation is straightforward. Basically it is an embedded, Bluetooth™ enabled WAP server which also implements server side scripting. This WAP server could be delivered in a self- contained module that could be connected to the installation bus via a standard interface. In case of an EIB system, a suitable interface would be the so-called Physical External Interface (PEI) being provided by a so-called Bus Coupling Unit. The server side scripts as well as the server applications finally send and receive datagrams from and to the installation bus via said interface.
In Figure 2 a flowchart depicts an embodiment of the method of the present invention according to the block diagram of Figure 1. The interaction of the user with the installation bus starts with a "fetch user interface" communication between the remote control device 20 and the IBG 2. The interaction of the user with the installation bus is continued by an "operation" between the remote control device 20, the TBG 2, the installation bus and a device 18 connected to the
installation bus.
In the first step SI the remote control device 20 requests the user interface from the IBG 2 for controlling any device.
In the second step S2 the IBG 2 transfers the user interface to the remote control device 20. The first steps might include several content request/response operations for retrieving e.g. a certain
"change configuration"- user interface.
Thereby the "fetch user interface" communication is terminated and the user selects a control option e.g. "switch on light number 18" at S3 and the remote control device 20 sends the request to the IBG 2. At S4ab the TBG 2 converts the request into a message send via the installation bus connector 10 and the installation bus to the light 18, which causes the light 18 to be turned on (light #18=1).
The light 18 may return a confirmation S5ba to the TBG 2, if this was a confirmed service of the installation bus.
Finally the TBG 2 sends a hypertext response message S6 to the TBG 2 that may contain a confirmation that light number 18 is switched on. The response message S6 may already include new control options (e.g. switch off light #18).
Figure. 3 depict a possible setup to notify a remote phone about important events at home, hi this case the installation bus gateway (IBG) would create a serial connection (over Bluetooth™ (BT)) to phone 20 and send a short message (SM) to phone 40. To accomplish this, the IBG would use standard asynchronous transfer (AT) commands over Bluetooth to transfer the SM to phone 20 and remotely trigger the transmission of this SM to phone 40. Phone 20 is a BT phone but not necessarily a WAP phone. Phone 40 is a regular SM enabled mobile phone, even without WAP and BT features. Alternatively, phone 40 could remotely control devices 14, 16, 18 on the installation bus 12. This is accomplished in that incoming SMS (phone 20) are polled and parsed by the TBG. case, these SMs contain a command being coded according to a format known by the JBG, this command is executed by a server side application, which will perform the corresponding protocol operations over the bus connector.
Additionally, the remote control device can be personalized for each user and the access to devices can be adapted to external conditions (time of day, temperature, etc.). With such a feature, a user can prevent that all the applications of the bus 12 can be accessed by anyone, anytime. The access of children for example to cupboards with alcohol or medicine can be limited, or the access to the TN-set can be limited to predetermined hours, and the like.
Figure 4 depicts the configuration of the installation bus gateway 2 according to the invention, order to map the UI commands to the actual network configuration of the installation bus 12, the
TBG 2 has to be configured before being put into operation. One way to accomplish this is the following:
• the network is configured as usually, e.g. using a software 50 running on a computing device being connected to the bus. The network configuration database 51, e.g. stored on this computing device, now contains information about
• Which sensor is connected to which actor(s) and the corresponding scenarios
• human readable names of actors and sensors (e.g. light livingroom, dimmer bathroom),
• human readable names for scenarios, like "leave home" (all lights off, alarm on)
• logical ordering of switches by rooms, • etc.
• The TBG 2 contains some general purpose API accessible by server-scripts to create, send and receive datagrams according to the interface specifications of the particular installation bus system (e.g. PEI for EIB)
• The configuration information 51 is rendered into a new file/database 53 in a more suitable format for the IBG to render the user interface. This database may include
• Server side scripts
• configuration data
• static markup content
The conversion is accomplished by a computer Software 52. The UI contains (not shown) hyperlinks (or any other interactive controls like buttons, dialogs etc), that reference server side scripts to execute the desired operation, when the hyperlink is selected by the user. The hyperlinks contain parameters that are used by the server scripts to parameterize the datagrams invoking the desired operation.
One aspect of the present invention is the idea that the embedded server is not part of the devices themselves, but only an extension of an existing home automation system. When this invention is applied, devices on a home installation bus can be controlled by using a mobile phone. This invention entirely builds upon open standards and extends existing systems instead of replacing them. The investment to equip an existing installation bus deployment with an installation bus gateway (TBG) is negligible compared to the initial investment for the installation bus itself. No device has to be equipped with extra hard- or software, except the installation of the TBG itself. Also the functionality of sending bus events over SMS is an aspect. It has to be noted that the expression 'home' also includes buildings, mobile homes, boats, offices, hospitals, airports and the like.