WO2023052259A1 - Delegated bridge discovery - Google Patents

Delegated bridge discovery Download PDF

Info

Publication number
WO2023052259A1
WO2023052259A1 PCT/EP2022/076508 EP2022076508W WO2023052259A1 WO 2023052259 A1 WO2023052259 A1 WO 2023052259A1 EP 2022076508 W EP2022076508 W EP 2022076508W WO 2023052259 A1 WO2023052259 A1 WO 2023052259A1
Authority
WO
WIPO (PCT)
Prior art keywords
bridge
network
control
add
local
Prior art date
Application number
PCT/EP2022/076508
Other languages
French (fr)
Inventor
Walter Jeroen Slegers
Original Assignee
Signify Holding B.V.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Signify Holding B.V. filed Critical Signify Holding B.V.
Publication of WO2023052259A1 publication Critical patent/WO2023052259A1/en

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/2803—Home automation networks
    • H04L12/283—Processing of data at an internetworking point of a home automation network
    • H04L12/2832—Interconnection of the control functionalities between home networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/2803—Home automation networks
    • H04L12/2816—Controlling appliance services of a home automation network by calling their functionalities

Definitions

  • the present invention is in the field of network control. It relates to a control device for performing control functions for one or more devices of a local network arrangement in a local wireless network, and to a method for operating a control device.
  • mesh networking is a networking topology allowing nodes in the network to exchange data and act as a relay to forward data onwards to another node.
  • ZigBee Light Link (ZLL) is an exemplary open standard designed for LED lighting control in a mesh network.
  • An example of another networking topology uses a central access point for allowing other connected network nodes to connect to a local area network (LAN).
  • LAN local area network
  • Such access points may additionally provide connectivity with a wide area network (WAN), either by providing connectivity to an external router device or using an integral router component.
  • WAN wide area network
  • the IEEE 802.11 set of protocols related to wireless local area networks (WLAN, also known as WiFi) allows using such a network topology.
  • Control communication from a control device connected to a WLAN with devices in a mesh network can be performed using a local bridge device.
  • US 2009/303926 Al describes a proxy-bridge for connecting Universal Plug and Play (UPnP) compliant devices with Bluetooth (BT) compliant devices.
  • a device and service announcer advertises bridge device availability at regular intervals.
  • the proxy-bridge has a converter for converting the discovered Bluetooth devices and services into associated UPnP device and service information, and the discovered UPnP compliant devices and services into associated Bluetooth device, service, and/or profile information.
  • a UPnP adapter represents the Bluetooth devices towards the UPnP devices and a Bluetooth adapter represents the UPnP compliant devices towards the Bluetooth compliant devices.
  • a first aspect of the invention is formed by a control device of claim 1.
  • a second aspect of the invention is formed by a method of claim 7, and a third aspect of the invention is formed by a computer program of claim 10.
  • the present invention is based on considerations by the inventor laid out in the following. The discussion of these considerations uses a non-limiting example from the field of networked control of lighting devices. This is not intended to limit the applicability of the present invention to this field of technology.
  • the invention is generally applicable in the field of control of devices via network communication, which includes Intemet-of-things (loT) control applications.
  • LoT Intemet-of-things
  • Philips hue is an example of aZLL based lighting system.
  • the local bridge device operates to provide a communication bridge between controlled lighting devices, sensors etc. and other devices which are not part of the mesh network but exert functions for the lighting devices such as lighting control.
  • Lighting control devices may for instance be implemented as handheld computer devices, in particular as a smart phone or a tablet computer executing lighting control software.
  • Such lighting control devices are typically associated with a local area network to which the bridge device is also connected, and may additionally establish wide area network connections to servers such as a lighting-device-network administration server, which provides administrative resources for supporting maintenance and operation of the network.
  • An advantageous way of performing a bridge discovery process in accordance with the present invention is to acquire bridge address data of the local bridge device associated with the local device-network arrangement from a remote device-network administration server via a wide-area network connection.
  • Such device-network administration server is maintained for administration of a large number of network arrangements in different locations.
  • Privileged access to the information stored by data resources on the device-network administration server and to processing capabilities is enabled using authentication information, which is provided by the operator of the devicenetwork administration server, typically at the same time also the manufacturer of main components of the network arrangement, which includes in particular the local bridge device.
  • a control device may allow expanding these core control functions by later installation of add-on control functions.
  • a third party manufacturer of lighting devices compatible with a lighting system may wish to offer add-on control functionality that is particularly designed for his third-party lighting devices and that is not comprised in the core control functionality for the lighting network arrangement, or provides an alternative user interface for performing some or all of the core control functions, which may be particularly suited to control the devices or to the needs of a particular user group. This is typically achieved by installing an add-on control unit, for instance using software components provided by the third party manufacturer.
  • different embodiments of the add-on control unit may provide the same control functions, additional control functions, or a subset of the control options of the core control unit.
  • a requirement for activating operation of the control device with such add-on control functionality in a given local network arrangement is the establishment of a connection of the add-on control unit with the bridge device.
  • bridge-discovery unit which is configured to acquire bridge address data indicative of a network address associated with a local area network that is different from the local wireless device network and assigned to a local bridge device that provides local wireless control connectivity between the control device and the controllable devices in the local wireless device network;
  • a core control unit that is configured to use the acquired bridge address data to perform control communication with the controllable devices via the local bridge device for implementing a set of core control functions;
  • the bridge-discovery unit is additionally configured
  • the control device of the first aspect of the invention provides an efficient bridge discovery process as a “broker” service for an add-on control unit.
  • the bridge discovery process for the add-on control unit does not require the add-on control to perform a bridge discovery process on its own. Instead, the control unit allows using an intra-device communication channel for a bridge-discovery request by the add-on control unit.
  • the bridge-discovery unit of the control device uses a wide-area network connection to the device-network administration server to acquire the bridge-data resource comprising the bridge address data from the device-network administration server, and provides it via the intra-device communication channel to the add-on control unit.
  • an add-on control unit no functionality for performing a bridge-discovery process, nor any information required for interacting with the devicenetwork administration server (e.g., login information) is required to obtain bridge address data, but only a simple bridge-discovery request via an intra-device communication channel to trigger provision of the required information from the core control unit.
  • the add-on control unit thus can delegate the task of performing the bridge discovery to the bridge-discovery unit associated with the core control unit.
  • the different units, in particular the bridge-discovery unit and the core control unit of the control device are in preferred embodiments implemented in the form of software installed and executed on a computer such as a smart phone, tablet computer, notebook or desktop computer.
  • the bridge-discovery unit and the core control unit of the control device are preferably provided as a single integrated unit in the form of a single software product/ app.
  • the add-on control unit is provided in these embodiments as a third-party software/app that is installed and executed in addition to the mentioned software implementing the other units.
  • the bridge address data includes any information required to identify a bridge device and perform network communication with it in the local area network.
  • the network protocol used may vary according to a given implementation.
  • the bridge address data of one embodiment complies with an Internet Protocol (IP) that is used within the local area network.
  • IP Internet Protocol
  • the bridge address data comprises, for the same bridge device, address data according to different protocol versions of a network protocol, such as an IP Version 4 address and an IP Version 6 address.
  • the bridge address data may comprise address data of one or more local bridge devices, depending on the particulars of the local network arrangement.
  • the bridge-discovery unit of the control device obtains network addresses of all bridge devices that belong to a user’s home, as registered with the device-network administration server.
  • the intra-device communication channel is in preferred embodiments formed using suitable interfaces for exchange between the bridge discovery unit and the add-on control unit.
  • Such interfaces may for instance be application programming interfaces between a core control software and the add-on control software.
  • the bridge-discovery request comprises a deep link.
  • the bridge-discovery request comprises a http call to the deep link.
  • a deep link allows implementing an advantageous intra-device communication channel that makes use of an interception mechanism which is per se known in web applications and provided by operating systems of control devices implemented as a mobile device such as a smart phone or tablet computer. Widely used examples of such operating systems are Apple’s iOS or Google’s Android.
  • the deep link does not point directly to the bridge data resource maintained by the device network administration server.
  • the present embodiment makes use of a deep link to another URL of a pre-specified web resource that is suitably operated by the provider of a software implementing the bridge-discovery unit, but some other pre-specified URL registered with the operating system in association with the software.
  • the bridge-discovery unit of this embodiment is preferably configured to use the received deep link only for triggering the acquisition of the bridge-data resource from the device-network administration server.
  • the bridgediscovery unit is configured, at start up of the control device, to register itself with the operating system to intercept the pre-specified deep link and to invoke a service that includes the acquisition of the bridge-data resource.
  • the bridge-discovery unit again makes use of the intra-device communication channel provided by the operating system to provide the bridge-data resource to the requesting add-on control unit, possibly after processing the bridge-address data, for instance by filtering to reduce the number of bridge devices to be indicated to the add-on control unit.
  • the response will not appear different than a response to its initial http call from a cloud server.
  • the solution of the present embodiment offers a particularly simple bridge discovery service to the add-on control unit.
  • URL uniform resource locator
  • the URL used by the addon control unit in the deep link comprised in the bridge discovery request and the URL used by the bridge-discovery unit to acquire the bridge-data resource must be different. For otherwise, in case they were identical, a http call issued by the bridge discovery unit and pointing to the bridge-data resource and would be intercepted and redirected back to the bridge discovery unit itself which has issued the http call.
  • the deep link is interpreted by the core app to trigger the acquisition of the bridge-data resource comprising the bridge address data, in particular to address or redirect to the bridge-data resource maintained by the device-network administration server.
  • the bridge-discovery request is received as a GET command under the hypertext transfer protocol (HTTP).
  • HTTP hypertext transfer protocol
  • the GET command specifies a URL of the deep link.
  • the device-network administration server can be reached in different ways.
  • the bridge-discovery unit is configured, for establishing the wide-area network connection, to establish a connection with an access point and router device providing access to a local area network, which is different from the local wireless mesh network, and connectivity to the wide area network.
  • the bridge-discovery unit is configured to establish a connection with the local bridge device via the access point and router device.
  • control device of another embodiment actually comprises one or more add-on control units, each of which is suitably configured
  • the bridge addresses can change over time, it is preferred to use the bridge-discovery request at every start-up of the add-on control unit, in particular embodiments also after suspending and resuming the operation of the add-on control unit which happens even more often on a mobile phone. For instance, a user may switch to operation of another app, and return to operation of the app implementing the add-on control unit, which might happen even days after its start-up.
  • the bridge-discovery unit is preferably further configured, upon detecting more than one local bridge device in the local wireless device network, to prompt for a user input indicative of a user selection of one or more of the detected local bridge devices, the bridge address data of which are to be provided to the add-on control unit via the intra-device communication channel;
  • bridge-discovery unit has on previous occasions detected or just received from the device-network administration server the following bridge address data operated by a given user in different locations, e.g.: at home: a bridge A on 192.168.0.208 at a work location: bridges B on 10.0.1.53 and C on 10.0.2.54 at friend’s home: a bridge D on 192.168.178.17 and at a Holiday home: a bridge E on 172.16.28.155.
  • the core control unit can use this bridge address data to try to connect to the IP addresses of these bridges and then detect, for the sake of example, that bridge-ids B and C can be reached.
  • the bridge-discovery unit can then show to the user the detected bridge identification information so the user can decide by selection that the add-on control unit gets bridge address data of only the selected bridge or bridges for this home.
  • the bridge discovery also provides a mechanism to detect where the user currently is.
  • a method for operating a control device in performing control functions for one or more controlled devices of a local network arrangement in a local wireless device network comprises:
  • bridge address data indicative of a network address associated with a local area network that is different from the local wireless device network, and assigned to a local bridge device that provides local wireless control connectivity between the control device and the controllable devices in the local wireless device network;
  • the bridge-discovery request comprises a deep link to the bridge-data resource maintained by the device-network administration server.
  • the method preferably further comprises using the received deep link for acquiring the bridge-data resource from the device-network administration server.
  • the method further comprises performing the method of claim of the second aspect or one of its embodiments using a core control unit.
  • the method comprises, upon starting up or resuming operation of the add-on control unit, generating and providing, via a predetermined intra-device communication channel, the bridge-discovery request from the add-on control unit to the core control unit.
  • the add-on control unit establishes, using the bridge address data received from the core control unit, a connection with the local bridge device and, upon establishing the connection with the local bridge device, performs the set of add-on control functions for the network-devices.
  • a computer program comprises executable code, which causes a computer executing the code to perform a method according to the second aspect of the present invention or any of its embodiments described herein.
  • control device of claim 1 the method of claim 8, and the computer program of claim 11 have similar and/or identical preferred embodiments, in particular, as defined in the dependent claims.
  • Fig. 1 is an illustration of a network arrangement that includes a wireless device network, a local area network and a control device connected with the local area network for control of devices in the wireless device-network, and a wide area network that comprises a device-network-administration server; and
  • Fig. 2 is an illustration of a method for operating a control device.
  • Fig. 1 is an illustration of an arrangement that includes a lighting network arrangement 120, a local area network 140 and a lighting control device 150 connected with the local area network for control of lighting devices in the lighting network arrangement 120, and a wide area network 146 that comprises a lighting-device-network administration server 148.
  • the lighting network arrangement 120 comprises lighting devices 122 to 130 and a bridge device 132, which communicate via a local wireless mesh network. This wireless mesh communication is graphically indicated by a dashed line 133 extending between the bridge device 132 and the lighting device 122. This way, the lighting devices 122 to 130 and the bridge device 132 exchange data and each act as a relay to forward data onwards to another of the devices.
  • the lighting network arrangement is a Philips hue system which follows the ZigBee protocol, an open standard that is designed for LED lighting control.
  • the bridge device 132 operates to provide a communication bridge between the lighting devices 122 to 130 and other devices which are not part of the mesh network.
  • the bridge device 132 is also part of the local area network (LAN) 140 which spanned by a LAN access point 142, which in the present exemplary embodiment at the same time operates as an Internet router device to implement a communication capability with a wide area network 146.
  • the LAN access point 142 thus provides LAN and WAN access for connected network devices via a wireless and/or wired communication.
  • the bridge device 132 is in communication with a remote lighting-device- network administration server 148.
  • the lighting-device-network administration server 148 provides a cloud platform that allows a user of the lighting-network arrangement 120 to use a personal computing device such as a smart phone or a tablet computer that is executing a locally installed control software/app or a web app as a lighting control device 150 to securely access, monitor and interact with the lighting network arrangement 120 via the LAN access point 142 and the bridge device 132.
  • the lighting-device-network administration server 148 is used for registration of the user’s lighting network arrangement 120, for storing, in a data base 149, data associated with providing administration services for the lighting-network arrangement 120.
  • the lighting-device-network administration server maintains in the data base 149 various data resources for use in the administration of associated lighting-network arrangements and access control to them, including a bridge-data resource comprising identification and address information of any bridge device 132 associated with the lighting network arrangement 120. This information is used in particular for providing a server-based “brokered” or delegated bridge discovery process.
  • the lighting-device-network administration server 148 also performs registration and authentication services for any lighting control device 150, for allowing connectivity between the bridge device 132 and the lighting-control device 150, in order to allow the lighting control device 150 performing core lighting control functions for the lighting devices of the lighting network arrangement 120.
  • the lighting-device-network administration server 148 further performs registration and authentication services for third party lighting devices as well as associated third party lighting control units that are to be connected to the lightingnetwork arrangement as an add-on lighting control unit for providing add-on control functions associated with at least the third party lighting devices.
  • the lighting device 130 is a third-party device.
  • the mentioned functions of the lighting-device network administration server are in other embodiments distributed over different servers.
  • user authentication may be done by another cloud service in another domain, and local authentication (local core/add-on control to bridge) may be performed by the bridge device 132.
  • the lighting-device-network administration server is used for bridge discovery only.
  • the bridge device 132 is connected by a wired network connection 144 to the LAN access point 142 to serve as a local control center for the exchange between the lighting devices 122 to 130 and the user's lighting control device 150. It is noted that a wireless connection via a WLAN / WiFi connection would equally work.
  • the lighting control device 150 may for instance be implemented as handheld computer device, in particular as a smart phone or a tablet computer executing lighting control software.
  • the lighting control functions are distributed over two controllers, which are typically implemented as separate apps on the computer device: a core lighting controller C, implemented using a core lighting control software, and an add-on lighting controller A, implemented using an add-on lighting control software.
  • a typical application scenario is that the core lighting control software is provided by a manufacturer of the bridge device 132 as the main component for building and controlling the mesh network of lighting devices 122 to 130 in the lighting network arrangement 120. In the present case, the manufacturer also provides the lighting devices 122 to 128.
  • the add-on-lighting control software for the add-on lighting controller A is typically provided by a third party which may be the manufacturer of the third-party lighting device 130.
  • Add-on lighting control functions are designed especially for controlling operation of the lighting device 130 manufactured by the third party.
  • the add-on lighting controller A may implement another style of user interface (UI) such as a simplified UI because not all features are offered, or implement a UI that focusses on a specific use case, or a use case which is not supported by the core lighting controller C, or implement an integration with other ecosystems.
  • UI user interface
  • core is used herein for the lighting control functions provided by the core lighting controller C in order to distinguish from add-on lighting control functions which may be performed by the add-on lighting controller A provided by a third party manufacturer and installed in the lighting control device 150.
  • the lighting control devices is also configured to establish wide area network connections to remote servers such as the lighting-device-network administration server 148, which provides administrative resources for supporting maintenance and control of the network.
  • the lighting control device 150 is connected with the LAN access point 142 via a wireless WLAN/WiFi connection 152.
  • the connection with the LAN access point 142 allows network communication between the lighting control device 150 and the bridge device 132 for performing lighting control.
  • the lighting control device 150 needs to perform an initial bridge discovery process.
  • a bridge-discovery unit 156 of the lighting control device 150 is provided as a part of the core lighting controller C. It is configured to acquire bridge address data indicative of a network address assigned to the local bridge device 132 in the local area network (i.e., not in the mesh network). For detecting the bridge device 132, the bridgediscovery unit 156 performs a local bridge-discovery method.
  • Several local bridge discovery methods are per se known, using for instance Universal Plug and Play (UPnP) based on the Simple Service Discovery Protocol (SSDP) or using multicast DNS (mDNS).
  • UDP Universal Plug and Play
  • SSDP Simple Service Discovery Protocol
  • mDNS multicast DNS
  • a local wireless control connectivity between the lighting-control device 150 and the lighting devices 122 to 130 in the local wireless mesh network of the lighting network arrangement 120 is established.
  • a core lighting control unit 158 provided as a part of the core lighting controller C is configured to use the acquired bridge address data to perform lighting control communication with the lighting network-devices 122 to 130 via the local bridge device 132 for implementing a set of core lighting control functions.
  • the add-on lighting control unit 160 Before the add-on lighting control unit 160 is able to perform the add-on lighting control functions, it needs to obtain the bridge address data of the local bridge device 132. In order to avoid that the third party manufacturer must also develop an implementation of low level UDP based communication stacks and provide for interaction with the operating system to find bridge devices on the network, the core lighting controller C has a broker bridge detection capability.
  • the bridge-discovery unit 156 is additionally configured to receive, via a predetermined intra-device communication channel 157 of the lighting control device, from the add-on lighting control unit 160, a bridge-discovery request to provide the bridge address data. Upon receiving the bridge-discovery request it either provides, via the intra-device communication channel, the acquired bridge address data to the add-on lighting control unit 160.
  • the bridge discovery unit 154 acquires, via a wide-area network connection and using the authentication information, from the remote lightingdevice-network administration server 148 a bridge-data resource comprising the bridge address data and provide, via the intra-device communication channel, the bridge address data to the add-on lighting control unit.
  • the intra-device communication channel is established via an API between the add-on-lighting control unit 160 of the add-on lighting controller A and the bridge discovery unit 156 of the core lighting controller C.
  • the bridge-discovery request comprises a deep link.
  • the bridge discovery request generated by the add-on lighting control unit 160 combines the deep link with a GET command known from the Hypertext Transfer Protocol HTTP.
  • the deep link takes the form of a uniquely defined Unified Resource Identifier (URI), and thus forms a unique sequence of characters.
  • URI Unified Resource Identifier
  • the use of a deep link implements an intra-device communication channel via an interception mechanism provided by operating systems on a mobile device.
  • the deep link comprised by the bridge-discovery request does not point directly to the bridge data resource maintained by the device network administration server. Instead, it points to another URI of a pre-specified web resource, which is typically, but not necessarily operated by the provider of the core lighting controller C.
  • the URI is some pre-specified URL registered with the web application implementing the core lighting controller C.
  • the registration allows the operating system to identify the URI, intercept the bridge-discovery request and redirect it to the core lighting controller C instead of forwarding it to the specified URL via the Internet. This way, the bridge-discovery request can be handled by the bridge-discovery unit 156 of the core lighting controller C.
  • the URI of the pre-specified web resource used by the add-on lighting controller A in the bridge discovery request is different from the URI of the bridge-data resource to avoid the undesired effect that the subsequent request issued by the core lighting controller C is intercepted as well and redirected back to the core lighting controller C that issued it.
  • the bridge-discovery unit 156 uses the received deep link for acquiring the bridge-data resource from the lighting-device-network administration server, for instance using a GET command associated with the URI of the bridge-data resource, or performs an initial an authentication process. Again, the URI used at this point is different from that used by the add-on lighting controller A in the bridge-discovery request.
  • the bridge discovery unit may initially show a screen to let the user login. Subsequently, the bridge-discovery unit uses the lighting-device-network administration server (or a suitable pre-defined other server) in the cloud to get an access token for this user, which will be stored in the authentication storage unit 154.
  • the authentication storage unit 154 stores any authentication information that is required for acquiring data resources maintained by the remote lighting-device-network- administration server 148.
  • the bridge discovery unit initially presents the user with a web-page managed by an authentication cloud server such as an AuthO cloud server to login. Upon successful login, that server will provide an access token to be stored in the authentication storage unit of the core lighting control device that it can use for subsequent accesses to the lighting-device-network administration server, in particular for bridge discovery.
  • the access token will after some time expire and can be renewed via authentication cloud server.
  • the lighting-device-network administration server or another suitable server in the domain of this server will validate the access token with the authentication cloud server on each request, so an app or user access without proper authentication information can be rejected or revoked.
  • the bridge-discovery unit uses a pre-defined URL to obtain bridge-data resource including a list of bridges from the lightingdevice-network administration server.
  • the pertaining request may suitably include the obtained access token.
  • the received bridge-data resource is in one variant pre-processed before forwarding the requested bridge address data to the add-on lighting controller A.
  • a received list may be reduced before forwarding.
  • the solution of the present embodiment offers a particularly simple bridge discovery service to the add-on lighting control unit 160.
  • a developer of the software for implementing the add-on lighting controller A only needs to make use of a URI of the bridge data resource that is provided by the manufacturer of the core lighting controller, and of a simple GET command including the URI of the bridge data resource as a deep link.
  • Fig. 2 is a flow diagram illustrating a method 200 for operating a lighting control device.
  • the method starts with performing a local bridge discovery process in step S202.
  • the local bridge discovery process comprises acquiring bridge address data indicative of a network address associated with a local area network and assigned to a local bridge device that provides local wireless control connectivity between the lighting-control device and the lighting devices in the local wireless mesh network, which is different from the local area network.
  • the acquired bridge address data is used to perform lighting control communication with the lighting network-devices via the local bridge device for implementing a set of core lighting control functions.
  • step S206 operation of an add-on lighting controller is started.
  • the add-on lighting controller generates and provides, via a suitable intra-device communication channel, the bridge-discovery request from the add-on lighting controller unit to the core lighting controller.
  • the bridge-discovery request comprises a deep link maintained by the lighting-device-network administration server in the data base.
  • the bridge discovery request generated by the add-on lighting controller combines the deep link with a GET command known from the Hypertext Transfer Protocol HTTP.
  • the deep link takes forms a unique sequence of characters that can be identified by the operating system of the lighting control device under which the core lighting controller and the add-on lighting controller are operated.
  • the bridge-discovery unit of the core lighting controller acquires, via a wide-area network connection and using stored authentication information, the bridge-data resource from the lighting-device-network administration server.
  • the bridge-discovery unit provides, via the intra-device communication channel, the bridge address data to the add-on lighting controller.
  • the add-on lighting control unit establishes, using the bridge address data received from the core lighting control unit, a connection with the local bridge device.
  • the add-on controller Upon establishing the connection with the local bridge device, the add-on controller performs a set of add-on lighting control functions for the lighting network-devices in step S216.
  • a lighting-control device has a core lighting control unit that uses acquired bridge address data to perform lighting control communication with lighting devices via a local bridge device for implementing a set of core lighting control functions.
  • a bridge-discovery unit is configured to receive, via a predetermined intra-device communication channel, from an add-on lighting control unit, which is to implement a set of add-on lighting control functions for the lighting devices, a bridge-discovery request to provide the bridge address data. It then acquires, via a wide-area network connection, from a remote lighting-device-network-administration server a bridgedata resource comprising the bridge address data and to provides, via the intra-device communication channel, the bridge address data to the add-on lighting control unit.
  • the bridge-discovery request preferably comprises a deep link.
  • the lighting control device may alternatively establish an Internet connection via another channel, for instance via a wireless WAN connection, in particular via a terrestrial wireless cellular communication network.
  • a computer program may be stored/distributed on a suitable medium, such as an optical storage medium or a solid-state medium, supplied together with or as part of other hardware, but may also be distributed in other forms, such as via the Internet or other wired or wireless telecommunication systems.
  • a suitable medium such as an optical storage medium or a solid-state medium, supplied together with or as part of other hardware, but may also be distributed in other forms, such as via the Internet or other wired or wireless telecommunication systems.

Abstract

A control device (150) for performing control functions for one or more controllable devices (122 to 130) has a core control unit (158) that uses acquired bridge address data to perform control communication with controllable devices (122 to 130) of a local wireless network via a local bridge device (132), for implementing a set of core control functions. A bridge-discovery unit (156) of the control device is configured to receive, via a predetermined intra-device communication channel (157), from an add-on control unit (160), which is to implement a set of add-on control functions for the controllable devices (122 to 130), a bridge-discovery request to provide the bridge address data. It then acquires from a remote device-network-administration server (148) a bridge-data resource comprising the bridge address data and provides, via the intra-device communication channel, the bridge address data to the add-on control unit (160).

Description

Delegated bridge discovery
FIELD OF THE INVENTION
The present invention is in the field of network control. It relates to a control device for performing control functions for one or more devices of a local network arrangement in a local wireless network, and to a method for operating a control device.
BACKGROUND OF THE INVENTION
Control of networked devices is often performed via communication with network nodes across different network topologies. For instance, mesh networking is a networking topology allowing nodes in the network to exchange data and act as a relay to forward data onwards to another node. ZigBee Light Link (ZLL) is an exemplary open standard designed for LED lighting control in a mesh network. An example of another networking topology uses a central access point for allowing other connected network nodes to connect to a local area network (LAN). Such access points may additionally provide connectivity with a wide area network (WAN), either by providing connectivity to an external router device or using an integral router component. For instance, the IEEE 802.11 set of protocols related to wireless local area networks (WLAN, also known as WiFi) allows using such a network topology. Control communication from a control device connected to a WLAN with devices in a mesh network can be performed using a local bridge device.
US 2009/303926 Al describes a proxy-bridge for connecting Universal Plug and Play (UPnP) compliant devices with Bluetooth (BT) compliant devices. A device and service announcer advertises bridge device availability at regular intervals. The proxy-bridge has a converter for converting the discovered Bluetooth devices and services into associated UPnP device and service information, and the discovered UPnP compliant devices and services into associated Bluetooth device, service, and/or profile information. A UPnP adapter represents the Bluetooth devices towards the UPnP devices and a Bluetooth adapter represents the UPnP compliant devices towards the Bluetooth compliant devices.
SUMMARY OF THE INVENTION
It would be desirable to provide a control device and a method for operating a control device across different network topologies that allow a simple activation of add-on control functions, for instance provided by third party manufacturers, in addition to or as an alternative to core control functions for controllable network devices in a local wireless device network.
The following description is directed to embodiments of three different aspects of the present invention. A first aspect of the invention is formed by a control device of claim 1. A second aspect of the invention is formed by a method of claim 7, and a third aspect of the invention is formed by a computer program of claim 10.
The present invention is based on considerations by the inventor laid out in the following. The discussion of these considerations uses a non-limiting example from the field of networked control of lighting devices. This is not intended to limit the applicability of the present invention to this field of technology. The invention is generally applicable in the field of control of devices via network communication, which includes Intemet-of-things (loT) control applications.
Philips hue is an example of aZLL based lighting system. In the Philips hue network, the local bridge device operates to provide a communication bridge between controlled lighting devices, sensors etc. and other devices which are not part of the mesh network but exert functions for the lighting devices such as lighting control. Lighting control devices may for instance be implemented as handheld computer devices, in particular as a smart phone or a tablet computer executing lighting control software. Such lighting control devices are typically associated with a local area network to which the bridge device is also connected, and may additionally establish wide area network connections to servers such as a lighting-device-network administration server, which provides administrative resources for supporting maintenance and operation of the network.
Before being able to perform the control function for a given local network arrangement, such control devices need to establish a network connection with the local bridge device. To this end, the presence of a local bridge device is detected by the control device using a bridge discovery procedure. An advantageous way of performing a bridge discovery process in accordance with the present invention is to acquire bridge address data of the local bridge device associated with the local device-network arrangement from a remote device-network administration server via a wide-area network connection. Such device-network administration server is maintained for administration of a large number of network arrangements in different locations. Privileged access to the information stored by data resources on the device-network administration server and to processing capabilities is enabled using authentication information, which is provided by the operator of the devicenetwork administration server, typically at the same time also the manufacturer of main components of the network arrangement, which includes in particular the local bridge device.
In addition to providing core control functions foreseen by the manufacturer of main components, a control device may allow expanding these core control functions by later installation of add-on control functions. For instance, a third party manufacturer of lighting devices compatible with a lighting system may wish to offer add-on control functionality that is particularly designed for his third-party lighting devices and that is not comprised in the core control functionality for the lighting network arrangement, or provides an alternative user interface for performing some or all of the core control functions, which may be particularly suited to control the devices or to the needs of a particular user group. This is typically achieved by installing an add-on control unit, for instance using software components provided by the third party manufacturer. Thus, in comparison with the scope of control functions of the core control unit, different embodiments of the add-on control unit may provide the same control functions, additional control functions, or a subset of the control options of the core control unit.
A requirement for activating operation of the control device with such add-on control functionality in a given local network arrangement is the establishment of a connection of the add-on control unit with the bridge device.
Returning to the first aspect of the invention, a control device of the present invention for performing control functions for one or more controllable devices of a local wireless device network across different network topologies comprises:
- a bridge-discovery unit, which is configured to acquire bridge address data indicative of a network address associated with a local area network that is different from the local wireless device network and assigned to a local bridge device that provides local wireless control connectivity between the control device and the controllable devices in the local wireless device network;
- a core control unit that is configured to use the acquired bridge address data to perform control communication with the controllable devices via the local bridge device for implementing a set of core control functions; wherein
- the bridge-discovery unit is additionally configured
- to receive, via a predetermined intra-device communication channel of the control device, from an add-on control unit, which is to implement a set of add-on control functions for the controllable devices, a bridge-discovery request to provide the bridge address data; and
- upon receiving the bridge-discovery request, to acquire, via a wide-area network connection, from a remote device-network administration server a bridge-data resource comprising the bridge address data and to provide, via the intra-device communication channel, the bridge address data to the add-on control unit.
The control device of the first aspect of the invention provides an efficient bridge discovery process as a “broker” service for an add-on control unit. The bridge discovery process for the add-on control unit does not require the add-on control to perform a bridge discovery process on its own. Instead, the control unit allows using an intra-device communication channel for a bridge-discovery request by the add-on control unit. In response to receiving the bridge-discovery request via this intra-device communication channel, the bridge-discovery unit of the control device uses a wide-area network connection to the device-network administration server to acquire the bridge-data resource comprising the bridge address data from the device-network administration server, and provides it via the intra-device communication channel to the add-on control unit.
Thus, on the side of an add-on control unit, no functionality for performing a bridge-discovery process, nor any information required for interacting with the devicenetwork administration server (e.g., login information) is required to obtain bridge address data, but only a simple bridge-discovery request via an intra-device communication channel to trigger provision of the required information from the core control unit. The add-on control unit thus can delegate the task of performing the bridge discovery to the bridge-discovery unit associated with the core control unit.
In the following, embodiments of the control device of the first aspect of the invention will be described.
The different units, in particular the bridge-discovery unit and the core control unit of the control device are in preferred embodiments implemented in the form of software installed and executed on a computer such as a smart phone, tablet computer, notebook or desktop computer. The bridge-discovery unit and the core control unit of the control device are preferably provided as a single integrated unit in the form of a single software product/ app. Typically, the add-on control unit is provided in these embodiments as a third-party software/app that is installed and executed in addition to the mentioned software implementing the other units. The bridge address data includes any information required to identify a bridge device and perform network communication with it in the local area network. The network protocol used may vary according to a given implementation. The bridge address data of one embodiment complies with an Internet Protocol (IP) that is used within the local area network. In another embodiment, the bridge address data comprises, for the same bridge device, address data according to different protocol versions of a network protocol, such as an IP Version 4 address and an IP Version 6 address. The bridge address data may comprise address data of one or more local bridge devices, depending on the particulars of the local network arrangement. Suitably, the bridge-discovery unit of the control device obtains network addresses of all bridge devices that belong to a user’s home, as registered with the device-network administration server.
The intra-device communication channel is in preferred embodiments formed using suitable interfaces for exchange between the bridge discovery unit and the add-on control unit. Such interfaces may for instance be application programming interfaces between a core control software and the add-on control software.
In one embodiment of the control device the bridge-discovery request comprises a deep link. In one implementation of this embodiment, the bridge-discovery request comprises a http call to the deep link. Using a deep link allows implementing an advantageous intra-device communication channel that makes use of an interception mechanism which is per se known in web applications and provided by operating systems of control devices implemented as a mobile device such as a smart phone or tablet computer. Widely used examples of such operating systems are Apple’s iOS or Google’s Android. According to the present embodiment, the deep link does not point directly to the bridge data resource maintained by the device network administration server. Instead, the present embodiment makes use of a deep link to another URL of a pre-specified web resource that is suitably operated by the provider of a software implementing the bridge-discovery unit, but some other pre-specified URL registered with the operating system in association with the software.
The bridge-discovery unit of this embodiment is preferably configured to use the received deep link only for triggering the acquisition of the bridge-data resource from the device-network administration server. In a preferred variant of this embodiment, the bridgediscovery unit is configured, at start up of the control device, to register itself with the operating system to intercept the pre-specified deep link and to invoke a service that includes the acquisition of the bridge-data resource. Upon acquisition of the bridge-data resource, the bridge-discovery unit again makes use of the intra-device communication channel provided by the operating system to provide the bridge-data resource to the requesting add-on control unit, possibly after processing the bridge-address data, for instance by filtering to reduce the number of bridge devices to be indicated to the add-on control unit. To the requesting add-on control unit, the response will not appear different than a response to its initial http call from a cloud server.
Thus, the solution of the present embodiment offers a particularly simple bridge discovery service to the add-on control unit.
A deep link is per se known and sometimes also referred to as universal link, depending on the used operating system of the control device. It may point to a specified domain such as “discovery.meethue.com” or to a specific path, e.g., “discovery.meethue.com/bridges”, or include a query parameter like “discovery. meethue.com/bridge?appname=3rdpartyapp”, where “3rdparty app” refers to the add-on control unit. It thus contains a resource locator, in particular a uniform resource locator (URL), identifying a data resource. It should be noted that the URL used by the addon control unit in the deep link comprised in the bridge discovery request and the URL used by the bridge-discovery unit to acquire the bridge-data resource must be different. For otherwise, in case they were identical, a http call issued by the bridge discovery unit and pointing to the bridge-data resource and would be intercepted and redirected back to the bridge discovery unit itself which has issued the http call.
Using a deep link in the described manner deviating from the original concept of a deep link thus provides a particularly simple method for switching of operation between different executed software products, in the present case the add-on control unit and the bridge-discovery unit. In the present embodiment, the deep link is interpreted by the core app to trigger the acquisition of the bridge-data resource comprising the bridge address data, in particular to address or redirect to the bridge-data resource maintained by the device-network administration server.
In one variant of the present embodiment, the bridge-discovery request is received as a GET command under the hypertext transfer protocol (HTTP). The GET command specifies a URL of the deep link.
The device-network administration server can be reached in different ways. In one embodiment, the bridge-discovery unit is configured, for establishing the wide-area network connection, to establish a connection with an access point and router device providing access to a local area network, which is different from the local wireless mesh network, and connectivity to the wide area network.
Suitably, in this embodiment of the control device, the bridge-discovery unit is configured to establish a connection with the local bridge device via the access point and router device.
The functionality of serving a third-party add-on control unit is present in the control device even if no such add-on control unit is active or even installed on the control device. However, best use of it is made if the control device of another embodiment actually comprises one or more add-on control units, each of which is suitably configured
- upon a start-up or a resumption of operation, to generate and provide to the core control unit, via the predetermined intra-device communication channel, the bridgediscovery request;
- to establish, using the bridge address data received from the core control unit, a connection with the local bridge device;
- and, upon establishing the connection with the local bridge device, to perform the set of add-on control functions for the network-devices.
Since the bridge addresses can change over time, it is preferred to use the bridge-discovery request at every start-up of the add-on control unit, in particular embodiments also after suspending and resuming the operation of the add-on control unit which happens even more often on a mobile phone. For instance, a user may switch to operation of another app, and return to operation of the app implementing the add-on control unit, which might happen even days after its start-up.
In this embodiment of the control device the bridge-discovery unit is preferably further configured, upon detecting more than one local bridge device in the local wireless device network, to prompt for a user input indicative of a user selection of one or more of the detected local bridge devices, the bridge address data of which are to be provided to the add-on control unit via the intra-device communication channel; and
- upon receiving the user input, to provide the bridge address data of the selected one or more local bridge devices to the add-on control unit via the intra-device communication channel.
For illustration of this embodiment, assume the bridge-discovery unit has on previous occasions detected or just received from the device-network administration server the following bridge address data operated by a given user in different locations, e.g.: at home: a bridge A on 192.168.0.208 at a work location: bridges B on 10.0.1.53 and C on 10.0.2.54 at friend’s home: a bridge D on 192.168.178.17 and at a Holiday home: a bridge E on 172.16.28.155.
The core control unit can use this bridge address data to try to connect to the IP addresses of these bridges and then detect, for the sake of example, that bridge-ids B and C can be reached. The bridge-discovery unit can then show to the user the detected bridge identification information so the user can decide by selection that the add-on control unit gets bridge address data of only the selected bridge or bridges for this home.
This way, the bridge discovery also provides a mechanism to detect where the user currently is.
According to a second aspect of the present invention, a method for operating a control device in performing control functions for one or more controlled devices of a local network arrangement in a local wireless device network is provided. The method comprises:
- acquiring bridge address data indicative of a network address associated with a local area network that is different from the local wireless device network, and assigned to a local bridge device that provides local wireless control connectivity between the control device and the controllable devices in the local wireless device network;
- using the acquired bridge address data to perform control communication with the controllable devices via the local bridge device for implementing a set of core control functions;
- receiving, via a predetermined intra-device communication channel of the control device, from an add-on control unit, which is to implement a set of add-on control functions for the devices of the device-network, a bridge-discovery request to provide the bridge address data; and
- upon receiving the bridge-discovery request, acquiring (S210), via a wide- area network connection, the bridge-data resource from a remote device-network administration server and provide, via the intra-device communication channel, the bridge address data to the add-on control unit.
The advantages of the method correspond to those described for the control device of the first aspect of the invention.
In the following, embodiments of the method of the second aspect will be described.
In one embodiment of the method, the bridge-discovery request comprises a deep link to the bridge-data resource maintained by the device-network administration server. In this embodiment, the method preferably further comprises using the received deep link for acquiring the bridge-data resource from the device-network administration server.
In a further embodiment, the method further comprises performing the method of claim of the second aspect or one of its embodiments using a core control unit. In this embodiment, the method comprises, upon starting up or resuming operation of the add-on control unit, generating and providing, via a predetermined intra-device communication channel, the bridge-discovery request from the add-on control unit to the core control unit. Furthermore, the add-on control unit establishes, using the bridge address data received from the core control unit, a connection with the local bridge device and, upon establishing the connection with the local bridge device, performs the set of add-on control functions for the network-devices.
According to a third aspect of the present invention, a computer program is provided. The computer program comprises executable code, which causes a computer executing the code to perform a method according to the second aspect of the present invention or any of its embodiments described herein.
It shall be understood that the control device of claim 1, the method of claim 8, and the computer program of claim 11 have similar and/or identical preferred embodiments, in particular, as defined in the dependent claims.
It shall be understood that a preferred embodiment of the present invention can also be any combination of the dependent claims or above embodiments with the respective independent claim.
These and other aspects of the invention will be apparent from and elucidated with reference to the embodiments described hereinafter.
BRIEF DESCRIPTION OF THE DRAWINGS
In the following drawings:
Fig. 1 is an illustration of a network arrangement that includes a wireless device network, a local area network and a control device connected with the local area network for control of devices in the wireless device-network, and a wide area network that comprises a device-network-administration server; and
Fig. 2 is an illustration of a method for operating a control device.
DETAILED DESCRIPTION OF EMBODIMENTS
The following description relates to illustrative embodiments in the application field of lighting. However, from the foregoing general description, it should be clear that the application field of lighting is only a non-limiting example of an application field, which can make use of the present invention. Other technical application fields, such as networked sensing, control of technical operation of machines, control of actuation, etc. can equally make use of the disclosed bridge-discovery concept.
Fig. 1 is an illustration of an arrangement that includes a lighting network arrangement 120, a local area network 140 and a lighting control device 150 connected with the local area network for control of lighting devices in the lighting network arrangement 120, and a wide area network 146 that comprises a lighting-device-network administration server 148.
The lighting network arrangement 120 comprises lighting devices 122 to 130 and a bridge device 132, which communicate via a local wireless mesh network. This wireless mesh communication is graphically indicated by a dashed line 133 extending between the bridge device 132 and the lighting device 122. This way, the lighting devices 122 to 130 and the bridge device 132 exchange data and each act as a relay to forward data onwards to another of the devices. In the present embodiment, the lighting network arrangement is a Philips hue system which follows the ZigBee protocol, an open standard that is designed for LED lighting control. The bridge device 132 operates to provide a communication bridge between the lighting devices 122 to 130 and other devices which are not part of the mesh network. To this end, the bridge device 132 is also part of the local area network (LAN) 140 which spanned by a LAN access point 142, which in the present exemplary embodiment at the same time operates as an Internet router device to implement a communication capability with a wide area network 146. The LAN access point 142 thus provides LAN and WAN access for connected network devices via a wireless and/or wired communication.
The bridge device 132 is in communication with a remote lighting-device- network administration server 148. The lighting-device-network administration server 148 provides a cloud platform that allows a user of the lighting-network arrangement 120 to use a personal computing device such as a smart phone or a tablet computer that is executing a locally installed control software/app or a web app as a lighting control device 150 to securely access, monitor and interact with the lighting network arrangement 120 via the LAN access point 142 and the bridge device 132. In particular, the lighting-device-network administration server 148 is used for registration of the user’s lighting network arrangement 120, for storing, in a data base 149, data associated with providing administration services for the lighting-network arrangement 120. In particular, the lighting-device-network administration server maintains in the data base 149 various data resources for use in the administration of associated lighting-network arrangements and access control to them, including a bridge-data resource comprising identification and address information of any bridge device 132 associated with the lighting network arrangement 120. This information is used in particular for providing a server-based “brokered” or delegated bridge discovery process. The lighting-device-network administration server 148 also performs registration and authentication services for any lighting control device 150, for allowing connectivity between the bridge device 132 and the lighting-control device 150, in order to allow the lighting control device 150 performing core lighting control functions for the lighting devices of the lighting network arrangement 120. The lighting-device-network administration server 148 further performs registration and authentication services for third party lighting devices as well as associated third party lighting control units that are to be connected to the lightingnetwork arrangement as an add-on lighting control unit for providing add-on control functions associated with at least the third party lighting devices. For the purpose of illustration, it will be assumed in the following description that the lighting device 130 is a third-party device.
It is noted that the mentioned functions of the lighting-device network administration server are in other embodiments distributed over different servers. For example, user authentication may be done by another cloud service in another domain, and local authentication (local core/add-on control to bridge) may be performed by the bridge device 132. In one embodiment, the lighting-device-network administration server is used for bridge discovery only.
In the present embodiment illustrated in Fig. 1, the bridge device 132 is connected by a wired network connection 144 to the LAN access point 142 to serve as a local control center for the exchange between the lighting devices 122 to 130 and the user's lighting control device 150. It is noted that a wireless connection via a WLAN / WiFi connection would equally work.
The following description turns to the structure and functionality of the lighting control device 150.
The lighting control device 150 may for instance be implemented as handheld computer device, in particular as a smart phone or a tablet computer executing lighting control software. The lighting control functions are distributed over two controllers, which are typically implemented as separate apps on the computer device: a core lighting controller C, implemented using a core lighting control software, and an add-on lighting controller A, implemented using an add-on lighting control software. A typical application scenario is that the core lighting control software is provided by a manufacturer of the bridge device 132 as the main component for building and controlling the mesh network of lighting devices 122 to 130 in the lighting network arrangement 120. In the present case, the manufacturer also provides the lighting devices 122 to 128. In contrast, the add-on-lighting control software for the add-on lighting controller A is typically provided by a third party which may be the manufacturer of the third-party lighting device 130. Add-on lighting control functions are designed especially for controlling operation of the lighting device 130 manufactured by the third party. Or, the add-on lighting controller A may implement another style of user interface (UI) such as a simplified UI because not all features are offered, or implement a UI that focusses on a specific use case, or a use case which is not supported by the core lighting controller C, or implement an integration with other ecosystems.
Thus, the term “core” is used herein for the lighting control functions provided by the core lighting controller C in order to distinguish from add-on lighting control functions which may be performed by the add-on lighting controller A provided by a third party manufacturer and installed in the lighting control device 150.
The lighting control devices is also configured to establish wide area network connections to remote servers such as the lighting-device-network administration server 148, which provides administrative resources for supporting maintenance and control of the network.
In operation, the lighting control device 150 is connected with the LAN access point 142 via a wireless WLAN/WiFi connection 152. The connection with the LAN access point 142 allows network communication between the lighting control device 150 and the bridge device 132 for performing lighting control. However, before being admitted to performing lighting control for the lighting network arrangement 120, the lighting control device 150 needs to perform an initial bridge discovery process.
To this end, a bridge-discovery unit 156 of the lighting control device 150 is provided as a part of the core lighting controller C. It is configured to acquire bridge address data indicative of a network address assigned to the local bridge device 132 in the local area network (i.e., not in the mesh network). For detecting the bridge device 132, the bridgediscovery unit 156 performs a local bridge-discovery method. Several local bridge discovery methods are per se known, using for instance Universal Plug and Play (UPnP) based on the Simple Service Discovery Protocol (SSDP) or using multicast DNS (mDNS). The local bridge discovery typically involves the use of low level UDP (User Datagram Protocol) based communication stacks and interaction with the operating system of the lighting control device 150.
By detecting and connecting to the bridge device 132, a local wireless control connectivity between the lighting-control device 150 and the lighting devices 122 to 130 in the local wireless mesh network of the lighting network arrangement 120 is established. In particular, a core lighting control unit 158 provided as a part of the core lighting controller C is configured to use the acquired bridge address data to perform lighting control communication with the lighting network-devices 122 to 130 via the local bridge device 132 for implementing a set of core lighting control functions.
However, before the add-on lighting control unit 160 is able to perform the add-on lighting control functions, it needs to obtain the bridge address data of the local bridge device 132. In order to avoid that the third party manufacturer must also develop an implementation of low level UDP based communication stacks and provide for interaction with the operating system to find bridge devices on the network, the core lighting controller C has a broker bridge detection capability.
In particular, the bridge-discovery unit 156 is additionally configured to receive, via a predetermined intra-device communication channel 157 of the lighting control device, from the add-on lighting control unit 160, a bridge-discovery request to provide the bridge address data. Upon receiving the bridge-discovery request it either provides, via the intra-device communication channel, the acquired bridge address data to the add-on lighting control unit 160. In the alternative, the bridge discovery unit 154 acquires, via a wide-area network connection and using the authentication information, from the remote lightingdevice-network administration server 148 a bridge-data resource comprising the bridge address data and provide, via the intra-device communication channel, the bridge address data to the add-on lighting control unit. The intra-device communication channel is established via an API between the add-on-lighting control unit 160 of the add-on lighting controller A and the bridge discovery unit 156 of the core lighting controller C.
The bridge-discovery request comprises a deep link. In particular, the bridge discovery request generated by the add-on lighting control unit 160 combines the deep link with a GET command known from the Hypertext Transfer Protocol HTTP. The deep link takes the form of a uniquely defined Unified Resource Identifier (URI), and thus forms a unique sequence of characters. The use of a deep link implements an intra-device communication channel via an interception mechanism provided by operating systems on a mobile device. For implementation of the deep-link mechanism, the deep link comprised by the bridge-discovery request does not point directly to the bridge data resource maintained by the device network administration server. Instead, it points to another URI of a pre-specified web resource, which is typically, but not necessarily operated by the provider of the core lighting controller C. The URI is some pre-specified URL registered with the web application implementing the core lighting controller C. The registration allows the operating system to identify the URI, intercept the bridge-discovery request and redirect it to the core lighting controller C instead of forwarding it to the specified URL via the Internet. This way, the bridge-discovery request can be handled by the bridge-discovery unit 156 of the core lighting controller C.
It is important in this context that the URI of the pre-specified web resource used by the add-on lighting controller A in the bridge discovery request is different from the URI of the bridge-data resource to avoid the undesired effect that the subsequent request issued by the core lighting controller C is intercepted as well and redirected back to the core lighting controller C that issued it.
The bridge-discovery unit 156 uses the received deep link for acquiring the bridge-data resource from the lighting-device-network administration server, for instance using a GET command associated with the URI of the bridge-data resource, or performs an initial an authentication process. Again, the URI used at this point is different from that used by the add-on lighting controller A in the bridge-discovery request.
To allow access to the bridge-data resource, the bridge discovery unit may initially show a screen to let the user login. Subsequently, the bridge-discovery unit uses the lighting-device-network administration server (or a suitable pre-defined other server) in the cloud to get an access token for this user, which will be stored in the authentication storage unit 154. The authentication storage unit 154 stores any authentication information that is required for acquiring data resources maintained by the remote lighting-device-network- administration server 148. In one specific example, the bridge discovery unit initially presents the user with a web-page managed by an authentication cloud server such as an AuthO cloud server to login. Upon successful login, that server will provide an access token to be stored in the authentication storage unit of the core lighting control device that it can use for subsequent accesses to the lighting-device-network administration server, in particular for bridge discovery.
The access token will after some time expire and can be renewed via authentication cloud server. The lighting-device-network administration server or another suitable server in the domain of this server will validate the access token with the authentication cloud server on each request, so an app or user access without proper authentication information can be rejected or revoked. The bridge-discovery unit then uses a pre-defined URL to obtain bridge-data resource including a list of bridges from the lightingdevice-network administration server. The pertaining request may suitably include the obtained access token.
The received bridge-data resource is in one variant pre-processed before forwarding the requested bridge address data to the add-on lighting controller A. In particular, a received list may be reduced before forwarding.
Thus, the solution of the present embodiment offers a particularly simple bridge discovery service to the add-on lighting control unit 160. A developer of the software for implementing the add-on lighting controller A only needs to make use of a URI of the bridge data resource that is provided by the manufacturer of the core lighting controller, and of a simple GET command including the URI of the bridge data resource as a deep link.
Fig. 2 is a flow diagram illustrating a method 200 for operating a lighting control device.
The method starts with performing a local bridge discovery process in step S202. The local bridge discovery process comprises acquiring bridge address data indicative of a network address associated with a local area network and assigned to a local bridge device that provides local wireless control connectivity between the lighting-control device and the lighting devices in the local wireless mesh network, which is different from the local area network.
Subsequently, in a step S204, the acquired bridge address data is used to perform lighting control communication with the lighting network-devices via the local bridge device for implementing a set of core lighting control functions.
In a step S206, operation of an add-on lighting controller is started.
In a following step S208, the add-on lighting controller generates and provides, via a suitable intra-device communication channel, the bridge-discovery request from the add-on lighting controller unit to the core lighting controller. The bridge-discovery request comprises a deep link maintained by the lighting-device-network administration server in the data base. In particular, the bridge discovery request generated by the add-on lighting controller combines the deep link with a GET command known from the Hypertext Transfer Protocol HTTP. The deep link takes forms a unique sequence of characters that can be identified by the operating system of the lighting control device under which the core lighting controller and the add-on lighting controller are operated.
In a step S210, the bridge-discovery unit of the core lighting controller acquires, via a wide-area network connection and using stored authentication information, the bridge-data resource from the lighting-device-network administration server. In a step S212, the bridge-discovery unit provides, via the intra-device communication channel, the bridge address data to the add-on lighting controller.
Subsequently, in a step S214, the add-on lighting control unit establishes, using the bridge address data received from the core lighting control unit, a connection with the local bridge device.
Upon establishing the connection with the local bridge device, the add-on controller performs a set of add-on lighting control functions for the lighting network-devices in step S216.
In summary, according to the present invention a lighting-control device has a core lighting control unit that uses acquired bridge address data to perform lighting control communication with lighting devices via a local bridge device for implementing a set of core lighting control functions. A bridge-discovery unit is configured to receive, via a predetermined intra-device communication channel, from an add-on lighting control unit, which is to implement a set of add-on lighting control functions for the lighting devices, a bridge-discovery request to provide the bridge address data. It then acquires, via a wide-area network connection, from a remote lighting-device-network-administration server a bridgedata resource comprising the bridge address data and to provides, via the intra-device communication channel, the bridge address data to the add-on lighting control unit. The bridge-discovery request preferably comprises a deep link.
Other variations to the disclosed embodiments can be understood and effected by those skilled in the art in practicing the claimed invention, from a study of the drawings, the disclosure, and the appended claims.
For instance, the lighting control device may alternatively establish an Internet connection via another channel, for instance via a wireless WAN connection, in particular via a terrestrial wireless cellular communication network.
In the claims, the word "comprising" does not exclude other elements or steps, and the indefinite article "a" or "an" does not exclude a plurality. A single unit or device may fulfill the functions of several items recited in the claims. The mere fact that certain measures are recited in mutually different dependent claims does not indicate that a combination of these measures cannot be used to advantage.
A computer program may be stored/distributed on a suitable medium, such as an optical storage medium or a solid-state medium, supplied together with or as part of other hardware, but may also be distributed in other forms, such as via the Internet or other wired or wireless telecommunication systems.
Any reference signs in the claims should not be construed as limiting the scope.

Claims

CLAIMS:
1. A control device (150) for performing control functions for one or more controllable devices (122 to 130) of a local wireless device network (120), the control device (150) comprising:
- a bridge-discovery unit (156), which is configured to acquire bridge address data indicative of a network address associated with a local area network (140) that is different from the local wireless device network (120) and assigned to a local bridge device (132) that provides local wireless control connectivity between the control device (150) and the controllable devices (122 to 130) in the local wireless network (120);
- a core control unit (158) that is configured to use the acquired bridge address data to perform control communication with the controllable devices (122 to 130) via the local bridge device (132) for implementing a set of core control functions, said core control functions being lighting control functions provided by the core control unit;
- an add-on control unit (160) for implementing a set of add-on control functions for the controllable devices (122 to 130), said add-on control functions being lighting control functions provided by the add-on control unit, said add-on control unit configured to;
- upon a start-up or resumption of operation, generate and provide to the core control unit (158), via a predetermined intra-device communication channel (157), a bridgediscovery request to provide the bridge address data; wherein
- the bridge-discovery unit (156) is additionally configured
- to receive, via the predetermined intra-device communication channel (157) of the control device (150), from the add-on control unit (160), a bridge-discovery request; and
- upon receiving the bridge-discovery request, to acquire, via a wide-area network connection, from a remote device-network administration server (148) a bridge-data resource comprising the bridge address data and to provide, via the intra-device communication channel, the bridge address data to the add-on control unit (160), and wherein, the add-on control unit (160), is additionally configured - to establish, using the bridge address data received from the core control unit, a connection with the local bridge device (132);
- and, upon establishing the connection with the local bridge device (132), to perform the set of add-on control functions for the lighting devices (122 to 130).
2. The control device of claim 1, wherein
- the bridge-discovery request comprises a deep link; and wherein
- the bridge-discovery unit (156) is configured to use the received bridge discovery request for triggering the acquisition of the bridge-data resource from the devicenetwork administration server (148).
3. The control device of claim 1, wherein the bridge-discovery unit (156) is configured, for establishing the wide-area network connection, to establish a connection with an access point and router device (142) providing access to the local area network (140), which is different from the local wireless device network, and connectivity to the wide area network (146).
4. The control device of claim 3, wherein the bridge-discovery unit (156) is configured to establish a connection with the local bridge device (132) via the access point and router device (142).
5. The control device of claim 1, further comprising an authentication storage unit (154) configured to store and provide authentication information for acquiring data resources maintained by the remote device-network administration server (148) that is associated with the local wireless device network (120); wherein
- the bridge-discovery unit (156) is configured to use the authentication information for requesting access to the bridge-data resource from the device-network administration server (148).
6. The control device of claim 1, wherein the bridge-discovery unit (156) is further configured, upon detecting more than one local bridge device in the local wireless device network, to prompt for a user input indicative of a user selection of one or more of the detected local bridge devices (132), the bridge address data of which are to be provided to the add-on control unit via the intra-device communication channel; and - upon receiving the user input, to provide the bridge address data of the selected one or more local bridge devices (132) to the add-on control unit (160) via the intradevice communication channel.
7. A method (200) for operating a control device in performing control functions for one or more controllable devices of a local wireless device network t, the method comprising:
- acquiring (S202) bridge address data indicative of a network address associated with a local area network that is different from the local wireless device network, and assigned to a local bridge device that provides local wireless control connectivity between the control device and the one or more controllable devices in the local wireless network;
- using (S204) the acquired bridge address data to perform control communication with the one or more controllable devices via the local bridge device for implementing a set of core control functions;
- upon starting up or resuming operation of an add-on control unit, which is to implement a set of add-on control functions for the one or more controllable devices, generating and providing (S208), via a predetermined intra-device communication channel, a bridge-discovery request to provide the bridge address data from the add-on control unit to the core control unit;
- receiving (S208), via the predetermined intra-device communication channel of the control device, from an add-on control unit, , the bridge-discovery request; and
- upon receiving the bridge-discovery request, acquiring (S210), via a wide- area network connection, the bridge-data resource from a remote device-network administration server (148) and provide, via the intra-device communication channel, the bridge address data to the add-on control unit;
- the add-on control unit establishing (S214), using the bridge address data received from the core control unit, a connection with the local bridge device;
- and, upon establishing the connection with the local bridge device, performing (S216) the set of add-on control functions for the one or more controllable devices of the local wireless device network.
8. The method of claim 7, wherein 21
- the bridge-discovery request comprises a deep link to the bridge-data resource maintained by the device-network administration server; and further comprising
- using (S210) the received deep link for triggering the acquisition of the bridge-data resource from the device-network administration server.
9. A computer program, comprising instructions to cause the control device of claim 1 to execute all the steps of the method according to any of the claims 7 to 8.
PCT/EP2022/076508 2021-09-30 2022-09-23 Delegated bridge discovery WO2023052259A1 (en)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
EP21200232 2021-09-30
EP21200232.3 2021-09-30

Publications (1)

Publication Number Publication Date
WO2023052259A1 true WO2023052259A1 (en) 2023-04-06

Family

ID=78293884

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2022/076508 WO2023052259A1 (en) 2021-09-30 2022-09-23 Delegated bridge discovery

Country Status (1)

Country Link
WO (1) WO2023052259A1 (en)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090303926A1 (en) 2006-06-06 2009-12-10 Frank Theodoor Henk Den Hartog Proxy-bridge for connecting different types of devices
US20120324567A1 (en) * 2011-06-17 2012-12-20 General Instrument Corporation Method and Apparatus for Home Network Discovery
US20190182067A1 (en) * 2017-12-07 2019-06-13 K4Connect Inc. Home automation system including designated user interface device to push downloaded media content and related methods
US20200336564A1 (en) * 2019-04-17 2020-10-22 Sure Universal Ltd. Seamless connectivity to smart devices, cameras and home care devices over wifi networks and cloud

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090303926A1 (en) 2006-06-06 2009-12-10 Frank Theodoor Henk Den Hartog Proxy-bridge for connecting different types of devices
US20120324567A1 (en) * 2011-06-17 2012-12-20 General Instrument Corporation Method and Apparatus for Home Network Discovery
US20190182067A1 (en) * 2017-12-07 2019-06-13 K4Connect Inc. Home automation system including designated user interface device to push downloaded media content and related methods
US20200336564A1 (en) * 2019-04-17 2020-10-22 Sure Universal Ltd. Seamless connectivity to smart devices, cameras and home care devices over wifi networks and cloud

Similar Documents

Publication Publication Date Title
US9246921B1 (en) Secure external access to device automation system
US11153754B2 (en) Devices, systems and methods for connecting and authenticating local devices to common gateway device
US8089953B2 (en) Method and system for network entity configuration
US9154378B2 (en) Architecture for virtualized home IP service delivery
CA2530343C (en) System for the internet connections, and server for routing connections to a client machine
KR20200012945A (en) Methods, Registration Centers, and Devices for Service Discovery
EP2245831B1 (en) Configuration of user terminal settings in communications system
KR101605968B1 (en) Method and system for supportin dynamic instance hosting service of virtual object
US8234363B1 (en) Dynamic object management protocol
JP6629345B2 (en) Device and method for adding M2M service
KR101139836B1 (en) Method and system for two-phase mechanism for discovering web services based management service
KR20170028878A (en) Method for processing request messages in wireless communication system, and device for same
US20130064250A1 (en) Remotely accessing and controlling user equipment in a private network
CN108366382B (en) WiFi automatic configuration method for mobile terminal
KR100661856B1 (en) Service discovery system based on agent and method thereof, and recording medium thereof
CN105050028B (en) Method and device for controlling household electrical appliance
WO2013178157A2 (en) Method and device for automatically establishing wifi-based local area networks among devices in private cloud
WO2023052259A1 (en) Delegated bridge discovery
US20200174798A1 (en) Device bootstrapping
KR100860413B1 (en) Extended home service apparatus and method for providing extended home service in p2p networks
Wall et al. Decentralized configuration of embedded web services for smart home applications
JP2008033831A (en) Communication equipment and communication control program
KR100940814B1 (en) Automation setting method for network
CN111385371B (en) MAC address acquisition method, device and equipment
CN114915553A (en) Equipment management tool

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22782734

Country of ref document: EP

Kind code of ref document: A1