Pre-commissioning diagnostics for wireless networks

Abstract

The present invention relates to devices and a system for providing pre- commissioning diagnostics for wireless networks (e.g., Zigbee, Bluetooth or Thread networks) by using a direct communication technology (e.g., InterPAN, Zigbee Direct, etc.) for exchanging information with devices in their local area without forming or joining a network. Thereby, a pre-commissioning diagnosis of installed nodes of a wireless network (e.g., a Zigbee wireless lighting infrastructure) can be provided prior to commissioning, wherein the nodes (e.g., lighting nodes) may be configured to join a distributed ad hoc network (e.g., a pre-defined Zigbee or Bluetooth or Thread network) and to perform own and network diagnostics. Diagnostics results can then be processed and presented e.g. via a simple and intuitive user interface of a mobile device wirelessly connected to a diagnostic device that uses the direct communication technology.

Description

[0001] PRE-COMMISSIONING DIAGNOSTICS FOR WIRELESS NETWORKS

[0002] FIELD OF THE INVENTION

[0003] The invention relates to the field of commissioning devices (e.g., nodes, sensors etc.) in wireless networks, such as - but not limited to - Zigbee networks, for use in various different applications for home, office, retail, hospitality and industry.

[0004] BACKGROUND OF THE INVENTION

[0005] In wireless networks, such as used for lighting or load control, problems may materialize resulting from a wide range of causes. In order to resolve such problems, understanding the nature of the problems is important, US 2023 / 0189410 Al to this end proposes a feedback mechanism, whereby load control device(s) in a lighting system, may be triggered by means of a mobile device, or by means of a system controller, to visualize network diagnostics and / or configuration information, by appropriately controlling their respective lighting load, so as to provide visual feedback by blinking, by varying intensity levels, changing colors, and / or chromaticity .

[0006] When installing wireless networks (e.g., a wireless lighting infrastructure), installers of network devices may encounter a variety of challenges that can prevent the system from functioning properly. These challenges can include issues such as poor wiring, faulty hardware, network congestion caused by other co-located wireless devices, and poor device placement. These issues can often be identified during the commissioning stage, which is the next stage of installation where the wireless devices (e.g., nodes, fixtures, etc.) are configured in the network for operation in the commissioned system so that they can communicate data to each other and provide application layer functions, such as in case of a lighting system, a heating, ventilation, and air conditioning (HVAC) system, or a building management system. However, identifying these issues at the commissioning stage means that the wireless devices have already been installed and configured, which can result in further need of human resources, more delay and additional expenses to resolve issues. In some cases, it may even require an installer to completely reinstall and reconfigure the system, which can be a costly and time-consuming process. SUMMARY OF THE INVENTION

[0007] It is an object of the present invention to improve installation speed of wireless networks.

[0008] This object is achieved by a diagnostic device as claimed in claim 1, by a network device as claimed in claim 7, and by a network system as claimed in claim 11.

[0009] According to a first aspect, a diagnostic device (e.g., a mobile device or a stationary network device (e.g., a Zigbee Direct Device) for controlling a pre-commissioning diagnosis of a plurality of network devices in a wireless network is provided, wherein the diagnostic device is configured to: receive a diagnostic mode request from a mobile application via a wireless connection, trigger a switch to a diagnostic mode at the one or more network devices by broadcasting a diagnostic mode request via a first inter-network message via a first type of wireless communication, establishing a first ad hoc network using the first type of wireless communication comprising the plurality of network devices upon receipt of a diagnostic mode request from a mobile application on a mobile device via a wireless connection using a second type of wireless communication, prior to commissioning of the one or more network devices use the first ad hoc network for querying diagnostic test reports from the plurality of network devices; receive diagnostic test reports from the plurality of network nodes via an inter-network message; and forward received diagnostic test reports of the plurality of network devices to the mobile application via the wireless connection using the second type of wireless communication.

[0010] According to a second aspect, a network device for use in a wireless network is provided comprising a diagnostic device in accordance with the first aspect. The network device may be a luminaire and / or smart lamp and / or sensor of a lighting network.

[0011] According to a third aspect, a network system, preferably a lighting network system, is provided, that comprises at least one of the diagnostic device of the first aspect and a network device of the second aspect and a plurality of further network devices, wherein the further network devices are configured to receive the diagnostic mode request from the diagnostic device or from a network device. Accordingly, a user may after having installed the network devices at their respective positions, initiate a transmission of diagnostic mode request via a network-independent inter-network message (e.g., an InterP AN message) by a diagnostic device or first network device (e.g. a Zigbee Direct Device (ZDD)) using e.g. a mobile app (e.g., a Zigbee Virtual Device (ZVD)), prior to commissioning of network devices. Receiving network devices (e.g., Zigbee devices) may enter a diagnostic mode in response to a received diagnostic mode request and may configure themselves to pre-defined network parameters of an established ad hoc network and may rebroadcast the request again. Hence, making sure that all network devices receive the diagnostic mode request and configure themselves to a pre-defined ad hoc network. This ad hoc network is a coordinatorless network (distributed network).

[0012] The diagnostic test reports generated by the network devices in the diagnostic mode may be used for detecting faulty hardware. Network devices entering the diagnostic mode can initiate device-specific self-diagnostics. Upon completion of the self-diagnostics, network devices that are on the pre-configured distributed ad hoc network can send their diagnostics test reports to the diagnostic device or first network device, as the case may be, which may then relay the diagnostic test reports to the mobile app for further detailing and presentation on a user interface. This can help electricians / installers understand issues with installed network devices prior to commissioning.

[0013] Furthermore, performing the diagnostic process upfront during the installation stage prior to commissioning (e.g., on network devices in a factory new state) can save time and costs by identifying any faulty devices early in the installation process. This allows for prompt and targeted troubleshooting of certain issues such as faulty cabling and / or incorrect device types, rather than having to go back and identify the faults, rewire / replace devices and fix the issues. By identifying and resolving such issues with individual devices beforehand, the overall commissioning process can proceed more smoothly and with fewer interruptions.

[0014] Subsequent commissioning of the network devices into a commissioned application network system may involve network level and application level commissioning, where network-level commissioning may for example involve tasks such as, grouping of network devices into (sub)networks, configuring security settings for the (sub)networks and where application-level commissioning may for example involve tasks such as the grouping of network devices (e.g., lights in case of a lighting control system) in control groups, associating sensors with such network devices or groups of network devices, associating network devices and / or groups of network devices with (user and / or system) control function(s), etc.. As the diagnostic procedure reduces the likelihood that commissioning needs to be interrupted, commissioning of the network devices into an application network system may thus progress faster. Additionally, the proposed pre-commissioning diagnosis aims at simplifying the process of diagnosing and monitoring a network by providing a user- friendly mobile interface. This interface can enable users to form a network, trigger diagnostic mode and retrieve and process detailed diagnostics reports. Typically, commissioning takes place once the electricians / installers have finalized their work, but nevertheless they would have to remain on call during the commissioning to fix installation issues, whereas using the new approach, the likelihood that electricians / installers need to be called in during the commissioning phase is reduced. The user interface can also help electricians and installers identify faulty devices / fixtures. Based on processed data, the user interface can output troubleshooting instructions to electricians / installers. This is helpful, as electricians / installers may not necessarily have knowledge about the products and / or their features. Providing a simple and intuitive user interface improves efficiency of the installation process.

[0015] Accordingly, the diagnostic device is configured to establish an ad hoc network comprising the plurality of network nodes and to use the ad hoc network for querying diagnostic test reports from the plurality of network devices, and the diagnostic device may be configured to receive diagnostic test reports from the plurality of network nodes via an inter-network message.

[0016] The diagnostic device is configured to receive the diagnostic mode request from a mobile application via a wireless connection, preferably a Bluetooth connection, and to forward received diagnostic test reports of the plurality of network devices to the mobile application via the wireless connection.

[0017] Options First Aspect

[0018] According to a first option of the first aspect, a diganostic device is provided that is configured as a ZDD.

[0019] According to a second option that builds on the first aspect or the first option of the first aspect, the first inter-network message comprises first network parameters for use in joining the first ad hoc network. In this manner first network parameters may be provided with the first inter-network message and need not be pre-defined.

[0020] According to a third option that builds on the first option of the first aspect, the diagnostic device further comprising a diagnostic test mode timer and the diagnostic device is configured to: when the diagnostic test mode time has lapsed, broadcast a “Match Descriptor” command in the first ad hoc network; receive Match Descriptor response(s) from the network devices comprising device short addresses; and add the received short addresses to a short address table. In this manner the diagnostic device builds up knowledge of device short addresses.

[0021] According to a fourth option that builds on the third option of the first aspect, the diagnostic device is further configured to: for each network device in the short address table, transmit a diagnostic test report request using a corresponding short address from the short address table; and receive the diagnostic report responses from each addressed network device. In this manner the diagnostic node can collect relevant diagnostic reports for the mobile application.

[0022] According to a fifth option htat builds on the fourth option of the first aspect the diagnostic device is further configured to: signal to the first ad hoc network that the diagnostic test phase is finished. Accordingly, network devices may leave the first ad hoc network.

[0023] Options Second Aspect

[0024] According to a first option of the second aspect, the network device is configured to switch to a diagnostic mode in response to a receipt of a diagnostic mode request broadcast via a second inter-network message using the first type of wireless communication prior to commissioning of the network device, to join a second ad hoc network, perform self-diagnostics in the diagnostic mode generating a diagnostic test report, rebroadcast the diagnostic mode request, and, when requested to, transmit the diagnostic test report via the second ad hoc network.

[0025] According to a second option of the second aspect that builds on the first option of the second aspect, the network device (20) is configured to join the second ad hoc network, using second network parameters provided in the second inter-network message. Using this option, the network parameters can be varied at run-time and need not be predefined.

[0026] Alternatively, according to a third option of the second aspect that builds on the first option of the second aspect the network device is configured to join the second ad hoc network, using pre-defined network parameters. Using pre-defined network parameters, means the second inter-network message can be kept short.

[0027] Options Third Aspect

[0028] According to a first option of the third aspect the network system further comprises a mobile device, the mobile device comprising a mobile application configured to transmit a diagnostic mode request to and to receive diagnostic test reports from the diagnostic device, wherein the mobile device comprises a user interface for indicating a type and / or status of a present phase of the pre-commissioning diagnosis.

[0029] It is noted that the above devices may be implemented based on discrete hardware circuitries with discrete hardware components, integrated chips, or arrangements of chip modules, or based on signal processing devices or chips controlled by software routines or programs stored in memories, written on a computer readable media, or downloaded from a network, such as the Internet.

[0030] These and other aspects of the invention will be apparent from and elucidated with reference to the embodiments described hereinafter.

[0031] BRIEF DESCRIPTION OF THE DRAWINGS

[0032] In the following drawings:

[0033] Fig. 1 shows a schematic system architecture of a wireless lighting network with pre-commissioning diagnosis system, according to an embodiment;

[0034] Fig. 2 shows a flow diagram of a pre-commissioning diagnosis procedure according to an embodiment at a diagnostic device;

[0035] Fig. 3 shows a flow diagram of a pre-commissioning diagnosis procedure according to an embodiment at a newly installed network device;

[0036] Fig. 4 shows a schematic processing and signaling diagram of a pre- commissioning diagnosis process according to an embodiment;

[0037] Fig. 5 shows a schematic processing and signaling diagram of a more detailed pre-commissioning diagnosis process according to an embodiment; and

[0038] Fig. 6 shows an example of a user interface display sequence during a pre- commissioning diagnosis procedure, according to an embodiment.

[0039] DETAILED DESCRIPTION OF EMBODIMENTS

[0040] Embodiments of the present invention are now described based on a Zigbee lighting network.

[0041] Zigbee networks represent a type of a low-power / low-cost wireless network that allows multi-hop communication among devices in a mesh topology. Zigbee devices offer reduced power consumption and cost, together with mesh networking capability, which make them suitable for use in large-scale deployments. Examples of application of Zigbee mesh networks include home automation, building automation, retail services, smart energy, and wireless indoor / outdoor lighting systems.

[0042] During initial setup, a new Zigbee device needs to perform a commissioning procedure that allows the new Zigbee device to join a Zigbee network. More specifically, the Zigbee device is configured into the network (e.g., obtains credentials (network key), unique ID, etc.), so that it can start communicating with other network nodes. If there is no network to join, the commissioning procedure may ensure that a new network is created. The following embodiments of the present invention are directed to a pre- commissioning diagnosis option which is based on an access of network devices via an internetwork (e.g., broadcast) message prior to commissioning to initiate self-diagnostics at the network devices.

[0043] Fig. 1 shows a schematic system architecture of a wireless lighting network with pre-commissioning diagnosis system, according to an embodiment.

[0044] According to Fig. 1, components used in the proposed diagnosis system may comprise a mobile device 30 (e.g., smartphone, tablet, laptop, etc.), on which a mobile application 34 (“app”) is installed to initiate a diagnostics procedure and process received diagnostic reports for presentation on a user interface 32. A microprocessor or microcontroller (uP) 36 is provided to control the operation of the mobile device 30 as described in embodiments below based on program routines stored in a memory (not shown). Furthermore, a first radio frequency unit (RF1) 38-1 for a first type of wireless communication e.g. with a cellular network (e.g., 5G network), and a second radio frequency unit (RF2) 38-2 for a second type of wireless communication (e.g., Bluetooth, WiFi, near field communication (NFC), etc.) may be provided.

[0045] Furthermore, a diagnostic device (DD) 10, which may be implemented by a Zigbee direct device, comprises a microprocessor or microcontroller (uP) 16 to control the operation of the diagnostic device 10 as described in embodiments below based on program routines stored in a memory (not shown). Furthermore, the diagnostic device 10 is configured to communicate via a first wireless connection 120 by using a first radio frequency unit (RF1) 18-1 for a first type of wireless communication (Zigbee communication) with upstream Zigbee devices 20 (e.g., luminaires, sensors etc.) of the lighting network and to communicate via a second wireless connection 130 by using a second radio frequency unit (RF2) 18-2 for a second type of wireless communication (e.g., Bluetooth, WiFi, NFC, etc.) with the mobile app 34, wherein the first wireless connection allows a transfer of internetwork messages that can be transmitted to the upstream Zigbee devices 20 prior to commissioning and establishing of a joint network.

[0046] Note that, similar to the mobile device 30 and the diagnostic device 10, the upstream Zigbee devices (network devices) 20 comprise a microprocessor or microcontroller (not shown) configured to control the operation of the Zigbee devices 20 as described in embodiments below based on program routines stored in a memory (not shown). Furthermore, at least one radio frequency unit (not shown) is provided in the Zigbee devices 20 for Zigbee communication with other Zigbee devices 20. An inter-network message is to be understood as a type of message that can be transmitted across different networks via a connection or communication between two or more separate networks, e.g., over a public network such as the Internet. Inter-network communication enables the exchange of data and information amongst network devices that are not in a network and / or between different networks, allowing devices, regardless whether or not in a network, to access resources and services on other networks.

[0047] In the above embodiment, the diagnostic device 10 may be implemented by a Zigbee Direct device (ZDD) where the first wireless connection 120 is a Zigbee connection and the second wireless connection 130 is a Bluetooth Low Energy (BLE) connection. Zigbee Direct is an extension of Zigbee that lets users seamlessly interact with their Zigbee networks directly using a Zigbee Virtual Device (ZVD) such as a smart phone, or other BLE device, without needing a hub. With Zigbee Direct, users can onboard and control Zigbee devices and networks directly, so that Zigbee devices become more accessible to users and other device ecosystems. Zigbee Direct is a protocol standard that enables Bluetooth Low Energy (BLE)-capable devices, like smartphones or tablets, to onboard and optionally control certain Zigbee devices on a network. The Zigbee Direct protocol describes two types of devices: Zigbee Virtual Device (ZVD) and Zigbee Direct Device (ZDD). A ZVD acts as a full BLE device that communicates with the ZDD over BLE. ZVDs have the option to run a Zigbee stack as well, however, this is not a requirement. In practice, a ZVD could be a smartphone application, such as the mobile app 34 of the mobile device 30, that acts like a network controller and can commission and interact with other ZDDs on a network. The other device type, ZDD, is a full Zigbee device running an additional BLE stack that enables BLE communications with the ZVD.

[0048] It is noted that the diagnostic device 10 and the mobile device 30 may be integrated as a single mobile device, e.g., the mobile app 34 may be provided on the diagnostic device 10.

[0049] According to Fig. 1, the upstream Zigbee devices 20 may be installed in an office building, as shown by a lighting plan 200 with black dots for the Zigbee devices 20 and connection lines indicating wireless connections 22 of the Zigbee network.

[0050] The diagnostic device 10 may be provided to agents and / or distributers of the lighting network to facilitate site installation. It may be a portable and battery-powered device, so that an electrician / installer does not need a power cable.

[0051] The Zigbee devices 20 may comprise connected luminaires (e.g., light emitting diode (LED) luminaires), smart (LED) lamp, separate or integrated sensors, and other connected devices with established networking and cloud architectures to enable data gathering and sharing, adding intelligence to all illuminated spaces. The smart lamps may be LED-based lamps, gas-discharge lamp or filament bulb, plus any associated support, casing or other such housing, arranged to emit illumination in into an environment.

[0052] As an alternative to the embodiment of Fig. 1, the environment may be an outdoor space such as a park, garden, road, or outdoor parking area, or a partially covered space such as a stadium, structured parking facility or gazebo, or any other space such as an interior of a ship, train or other vehicle, or any combination of such possibilities.

[0053] The luminaires may take any suitable form such as a ceiling or wall mounted luminaire, a free-standing luminaire, a wall washer, a chandelier, or a less conventional form such as embedded lighting built into an item of furniture, a building material such as glass or concrete, or any other surface.

[0054] The smart lamps and / or the luminaires may be equipped with a wireless communication interface allowing them to be controlled remotely by lighting control commands received from a user device (not shown) such as a smartphone, tablet, laptop or desktop computer, or by a wireless switch device (e.g., a wall switch) and / or based on sensor readings received from one or more of the (hardware) sensors.

[0055] The (hardware) sensors may be configured to collect data about an illuminated environment, including motion, light levels, occupancy, people counting, temperature, humidity, air quality, and more. Positioning and density of sensors may depend on ceiling height, configuration of space, and other factors. In examples, at least some of the hardware sensors (e.g., using passive infrared (PIR) or microwave) may also report occupancy by sending out a broadcast / multicast (either directly or via a Zigbee parent node).

[0056] Wireless communication between the Zigbee devices 20 (e.g., luminaires, lamps and / or sensors) may comply with the ZigBee Pro standard (IEEE 802.15.4, WPAN) in the 2.4 GHz frequency band within a predefined range (e.g., 10 m) from one or more of the ZigBee nodes to form a mesh network.

[0057] In embodiments, the commissioning process of the Zigbee devices 20 can be accelerated by a pre-commissioning diagnosis procedure. This can be achieved by initiating a diagnostic procedure at the Zigbee devices 20 after their installation has been completed but prior to commissioning.

[0058] In examples, during the above pre-commissioning check, a “sanity check” may be performed to ensure that correct devices are installed (e.g., proper version and / or software), and / or that devices are powered and booting, and / or that all nodes are accounted for (e.g., proper address and / or connection).

[0059] Furthermore, because the system is not yet commissioned at this stage, in other words the devices are in the factory new state, no network has been set up yet. Thus, an ad hoc diagnostic network may be set up for the pre-commissioning diagnosis procedure. Such an ad hoc network can be created between devices without the use of other network devices. In an ad hoc network, one device connects directly to another. This connection allows the two or more devices to communicate with each other, share resources and in some situations allow the sharing of e.g. an internet connection. Ad hoc networks are very flexible and can consist of many devices, each connected in a different manner and each providing different resources to the network. Devices can connect to an ad hoc network via a physical cable plugged directly into another device or through radio signals such as Wi-Fi, Bluetooth or Cellular. The connection method does not matter or affect the functionality of the network. The connection method does, however, affect the device's range and ability to move.

[0060] The Zigbee devices 20 (luminaires, sensors etc.) with radio frequency (RF) unit are installed e.g. in a building. During or after installation, an inter-network message, such as a non-network-bound broadcast message (NNBB), can be transmitted from the diagnostic device 10 under control of the mobile app 34, which acts as a starter node.

[0061] The NNBB may be a Zigbee InterP AN message, which is a message intended for communicating with a device from a different personal area network (PAN) with different PAN identity (PAN ID). Zigbee specification defines InterP AN communication as a mechanism whereby Zigbee devices can perform exchanges of information with devices in their local area without having to form or join the same Zigbee network.

[0062] Upon receipt of a NNBB or other inter-network message as trigger message from the diagnostic device 10, a receiving Zigbee device 20 may use network parameters that are either preset or derived from the NNBB e.g. to set up an ad hoc network, may rebroadcast the trigger message, may enter a diagnostic mode (where it may be insensitive to further trigger messages), and may report back a diagnostic report to the starter node.

[0063] In an example, an ad hoc diagnostic network that uses e.g. a broadcast messaging system (e.g., in the form of InterP AN communication as a mechanism whereby the Zigbee devices 20 can perform exchanges of information with devices in their local area without having to form or join the same ZigBee network) may be created in response to an InterP AN message or a Zigbee Direct message. The starter node or mobile app 34 may then collect the diagnostic reports and may verify whether all devices of the lighting plan 200 have been accounted for and are available (e.g., ready for commissioning, no malfunction). Optionally, the starter node can toggle or trigger all diagnosed Zigbee devices 20 to output an optical or acoustical feedback signal (e.g., a blinking light), where those Zigbee devices 20 that do not output the feedback signal are faulty). Additionally or alternatively, the starter node may be configured to single out (e.g., deactivate, report, etc.) Zigbee devices 20 with reported errors (that are in the network). Positively diagnosed Zigbee devices 20 may then be reset for commissioning in a conventional manner.

[0064] If the Zigbee devices 20 are capable of auto-commissioning, they may be configured to wait with the commissioning process until they are triggered (i.e., a triggerbased pre-commissioning step).

[0065] Alternatively, in situations where the network devices are equipped with both a Zigbee and Bluetooth capable radio, such as nowadays often the case in dual radio or timedivision multiplexed radio solutions, a mobile phone may use the Bluetooth (BLE) link to connect with a first network device, wherein the first network device is configured to receive a diagnostic mode request from the mobile phone (application) via a wireless connection, preferably a Bluetooth connection, and to switch to a diagnostic mode wherein it broadcasts a diagnostic mode request via an inter-network message to other network devices. In this approach, the first network device essentially takes on the role of the diagnostic device 10 and the first Zigbee device 20 that the diagnostic device 10 connects to. This is made possible by the fact that the first network device is a Zigbee Direct Device, preferably with a dual radio setup.

[0066] When all network devices are dual radio Zigbee Direct Devices, the mobile phone may initiate the pre-commissioning diagnosis at any one of the network devices. Moreover, the Bluetooth capability of the network devices may then be used to locate devices (that were properly powered) but that failed diagnostic testing, for example because they originate from a batch with the wrong firmware version, in which case the Bluetooth link may also be used to upgrade the device firmware.

[0067] In the following, a pre-commissioning diagnostic procedure according to an embodiment is described with reference to Figs. 2 and 3.

[0068] During network setup, an installer completes installation of Zigbee devices (e.g., fixtures etc.) and powers all devices. Then, the installer places a ZDD (e.g., the diagnostic device 10 of Fig. 1) in vicinity of installed Zigbee devices (e.g., the Zigbee device 20 of Fig. 1). Additionally, the installer may also be provided with a mobile device (e.g., the mobile device 30 of Fig. 1) with one or more diagnostic mobile applications (e.g., the mobile app 34 of Fig. 1), which will act as a ZVD. Then, the installer selects the correct nearby ZDD via a mobile app of the ZVD e.g. over Bluetooth and initiates a diagnostic mode via a user interface (e.g., the user interface 32 of Fig. 1) of the mobile app.

[0069] Fig. 2 shows a flow diagram of a pre-commissioning diagnosis procedure at a diagnostic device according to an embodiment with a pre-defined distributed Zigbee network formation.

[0070] The ZDD receives in step S201 (RX DMRQ) a diagnostic mode request from the mobile app and broadcasts the request in step S202 (BC DMRQ) using Zigbee InterP AN messages.

[0071] In step S203 (RX DTRPs) upon completion of diagnostic tests, the ZDD receives diagnostic test reports generated and transmitted by the Zigbee devices along with (minimal) device identities to the host ZDD.

[0072] Then, in step S204, the ZDD relays / forwards (FW MA) the received diagnostic test reports to the mobile app e.g. via Bluetooth.

[0073] In step S205 (PRES), the mobile app collects and processes the forwarded diagnostic test reports and presents results on the user interface of the mobile app.

[0074] The installer can now view and optionally interact with the Zigbee devices by identifying them e.g. via the mobile app, which may trigger a visual identification of identified Zigbee devices (e.g., blinking LED, fixture, luminaire etc.)

[0075] Optionally, in step S206 (INSTR), the mobile app may also provide troubleshooting instructions to initiate troubleshooting of specific Zigbee devices for which diagnostics failed or indicated a fault.

[0076] Fig. 3 shows a flow diagram of a pre-commissioning diagnosis procedure according to an embodiment at a newly installed Zigbee device (e.g., Zigbee device 20 of Fig. 1).

[0077] In step S301 (RX DMRQ), the newly installed Zigbee device receives the diagnostic mode request from the ZDD.

[0078] Then, in step S302 (D-MD?), the receiving Zigbee device will check whether it has been set to the diagnostic mode already. If so, the procedure branches to step S303 (IGN) where the receiving Zigbee device ignores the request.

[0079] Otherwise, the procedure continues with step S304 (D-MD) where the receiving Zigbee device will enter the diagnostic mode. The diagnostic mode may be time dependent. On expiry of a predetermined time period, the receiving Zigbee device may exit the diagnostic mode.

[0080] In step S305 (CFG NW-PAR), the receiving Zigbee device in diagnostic mode may configure Zigbee parameters (e.g., PAN ID, Extended PAN ID, Channel, etc.) to join a Zigbee ad hoc network. This may be a distributed network (i.e., a coordinator-less network) without any form and join process.

[0081] In a subsequent or previous step S306 (RBC DMRQ), after entering the diagnostic mode, the receiving Zigbee device may rebroadcast the received diagnostic mode request further to other Zigbee devices e.g. using InterP AN message(s). By rebroadcasting the received diagnostic mode request, likelihood that each receives the diagnostic mode request is substantially increased and eventually all Zigbee devices may ultimately belong to the same Zigbee ad hoc network.

[0082] In step S307 (JN AH-NW), the receiving Zigbee device joins the Zigbee ad hoc network and may then start in step S308 (SLF-D) a self-diagnostic test. Thereby, all receiving Zigbee devices run their own device-specific tests to test their internal / external interfaces and generate diagnostics reports.

[0083] Finally, in step S309 (TX DTR), upon completion of the self-diagnostic test, the receiving Zigbee device may send the diagnostic report along with its (minimal) device identities to the host ZDD.

[0084] Fig. 4 shows a schematic processing and signaling diagram of a pre- commissioning diagnosis process according to an embodiment, where a diagnostic device (e.g., a ZDD) (DD) 10 is configured to initiate a self-diagnosis and reporting process at a plurality of network devices (N1 to Nn) 20.

[0085] The diagram indicates involved network entities (i.e., a diagnostic device 10 and network devices 20) at the top, wherein arrows indicate successive message flows in time-dependent order and wherein blocks indicate processing steps with time passing from the top to the bottom.

[0086] Initially, the pre-commissioning diagnosis process is triggered at the diagnostic device 10 via a diagnostic mode request issued e.g. by a mobile app stored on the diagnostic device 10 or on another mobile device (not shown) connected to the diagnostic device 10. In response, the diagnostic device 10 broadcasts in step S401 (DMRQ) diagnostic mode request(s) over inter-network message(s) (e.g., Zigbee InterP AN message(s)) to the network devices 20. When receiving the diagnostic mode request(s), the receiving network nodes 20 initiate steps S402-1 to S402-n (J / D) where they enter the diagnostic mode (which may last for a predetermined time period and may then be exited again) or ignore it when already set in the diagnostic mode, and rebroadcast the diagnostic mode request message to other network devices 20 using an inter-network message (e.g., Zigbee InterP AN). As an additional action of step S402, the receiving network devices 20 in diagnostic mode configure network parameters (e.g., PAN ID, Extended PAN ID, Channel, etc.) to join an ad hoc network, which may be a distributed coordinator-less network without any form and join process. Finally, upon joining a pre-configured ad hoc network, the receiving network devices 20 then start a self-diagnostic test.

[0087] On completion of the diagnostic tests, the network devices 20 device send their diagnostic reports along with (minimal) device identities to the diagnostic device 10 in steps S403-1 to S403-n (DTRl-DTRn).

[0088] In step S404 (PRES), the diagnostic device 10 collects and processes the received diagnostic reports and presents the results on a user interface.

[0089] In the following, a more detailed example of the pre-commissioning diagnosis procedure with preparatory and side steps for a Zigbee lighting network according to an embodiment is described with reference to Fig. 5.

[0090] Fig. 5 shows a schematic processing and signaling diagram of the more detailed pre-commissioning diagnosis process according to the embodiment.

[0091] The processing and signaling steps are performed at / between a mobile device (MD) 30 with a mobile app (MA), a diagnostic device (DD) 10, and a Zigbee device (Ni) 20 representative of a plurality of Zigbee devices (e.g., luminaires, sensors, etc.) to be commissioned for the Zigbee lighting network.

[0092] Initial preparatory steps S501 to S507 are part of a start-up phase,

[0093] In step S501 (PC), the Zigbee device 20 (and possibly other Zigbee devices to be commissioned) is power cycled (e.g., restarted), which is a process of turning hardware off and then turning it on again. This action can be used to clear any current issues or temporary glitches in the device. In response, in step S502 (BU), the Zigbee device 20 is boot up in a normal operation mode for use as network node in the Zigbee network. Then, in step S503 (SC), the Zigbee device 20 performs a periodic scan for a Zigbee network. As the Zigbee device 20 is not yet a member of a Zigbee network, it scans channels for an open network to associate with. Once it finds a suitable Zigbee network, it attempts to join it and get the credentials. If the Zigbee device 20 finds more than one available Zigbee networks, it may attempt to join one of them, one by one.

[0094] In step S504 (PO), the diagnostic device 10 is switched on e.g. by an installer who wants to start the diagnosis procedure.

[0095] In a subsequent or previous step S505 (LMA), the mobile app is launched or activated at the mobile device 30, e.g., by the installer. Then, in step S506, the mobile app of the mobile device 30 issues a signaling (SC + CNT) e.g. via Bluetooth to search for a ZDD (i.e., the diagnostic device 10) and connect to it. In step S507 (CNTD), the diagnostic device 10 signals to the mobile device 30 that they are connected.

[0096] With the following steps S508 to S516, Zigbee devices to be commissioned are switched to a diagnostic mode and diagnostic tests are initiated.

[0097] In step S508 (TRDM), the mobile app of the mobile devicelO sends a trigger message / signal to the diagnostic device 10 to trigger a diagnostic mode at the diagnostic device 10. In response, the diagnostic device 10 starts in step S509 (ST DMT) a diagnostic test mode timer. The diagnostic test mode time period (duration) counted by the diagnostic test mode timer may be determined to correspond to a maximum time required for any Zigbee device to complete its own diagnosis plus some more time as a buffer.

[0098] Then, in step S510 (SW N / W), the diagnostic device 10 switches to a predefined Zigbee ad hoc network. The switching to the pre-defined Zigbee network parameters may include one or more of a channel number, a PAN ID, an extended PAN ID, etc. These parameters may be pre-programmed on the diagnostic device 10 and, upon receiving the diagnostic mode request, the diagnostic device 10 may configure a Zigbee stack to switch to and announce this pre-defined Zigbee ad hoc network. In step S511 (SW N / W), the switch to the pre-defined Zigbee ad hoc network is signaled to the mobile app of the mobile device 10.

[0099] In the following or previous step S512 (BC DMRQ), the diagnostic device 10 broadcasts a diagnostic mode request to Zigbee devices (including Zigbee device 20) to be commissioned by using an inter-network message (e.g., an InterP AN message).

[0100] Responsive to the received diagnostic mode request, the Zigbee device 20 (and possibly other receiving Zigbee devices) switches in step S513 (SW DM) Network devices 20 to the diagnostic mode. If already set in the diagnostic mode, it may ignore the diagnostic mode request.

[0101] Then, is step S514 (ST DMT), the Zigbee device 20 (and possibly other receiving Zigbee devices) may start a diagnostic test mode timer that is configured to count a predefined diagnostic test mode time period (duration). The diagnostic test mode time period may be determined based on a maximum time period required for any of the Zigbee devices to complete its own diagnosis plus some additional time as a buffer. Upon completion of this time period, the Zigbee device 20 can switch back to the normal operation mode.

[0102] In step S515 (SW N / W) the Zigbee device 20 (and possibly other receiving Zigbee devices) switches to the same pre-defined ad hoc network as the diagnostic device 10.

[0103] In the following step S516 (R-BC DMRQ), which may be performed several times (e.g., 3 times) in a loop, the Zigbee device 20 (and possibly other receiving Zigbee devices) rebroadcast the received diagnostic mode request using inter-network message(s) (e.g., InterP AN message(s)). The rebroadcasting message transmission may be periodic with some random back-off. Thereby, the chance of delivery of the rebroadcast diagnostic mode request to desired Zigbee devices to be commissioned and the resulting switch to the diagnostic mode can be increased. However, it may not be guaranteed that all Zigbee devices are switched to the diagnostic mode, e.g., if they are not operating correctly.

[0104] The next steps are related to conduction of diagnostic tests at the Zigbee device 20 and other Zigbee devices to be commissioned.

[0105] In step S517 (ST STD), the Zigbee device 20 starts a self-diagnostic test which may be based on (specific to) the type of device. The test may include one of more of a peripheral test, interfaces and communication tests, etc.

[0106] Then, in step S518 (DTRP), the Zigbee device 20 (and other testing Zigbee devices) prepares a diagnostic report which may include other device details (including e.g. a device short address, an IEEE address, a device model ID, a type ID, etc.).

[0107] Completion of the diagnostic test phase is defined in step S519 (EL DMT), when the diagnostic test mode timer at the diagnostic device 10 has elapsed. In response, the diagnostic device 10 may broadcast in step S520 (BC MDC) a standard Zigbee "Match Descriptor" command in the pre-defined ad hoc network to the Zigbee devices 20 (and other testing Zigbee devices). The Zigbee device 20 (and other receiving Zigbee devices) respond to the diagnostic device 10 in step S521 (RX MDR(SAi)) with Match Descriptor response(s) comprising a device short address. In step S522 (ADD SAi), the diagnostic device 10 adds the received device short address(es) to a short address table.

[0108] The following steps S523 to S525 may be repeated in a loop for all Zigbee devices (including Zigbee device 20) that responded with a matched descriptor command. In step S523 (DTRRQ(SAi)), the diagnostic device 10 transmits a diagnostic test report request to each Zigbee node using a corresponding short address derived from the short address table. In response, the diagnostic device 10 receives in step S524 (DTRi) diagnostic report responses with individual diagnostic test reports from each addressed Zigbee node (including the Zigbee device 20). In step S525 (DTRi), the diagnostic device 10 forwards the currently received diagnostic test report of a respective responding Zigbee device to the mobile app.

[0109] In step S526 (DTRi CLT), the received diagnostic test reports of all responding Zigbee devices (including the Zigbee device 20) are collected by the mobile app at the mobile device 30.

[0110] In step S527 (FDT), the diagnostic device 10 signals to the Zigbee ad hoc network that the diagnostic test phase is finished.

[0111] In response, the receiving Zigbee devices (including the Zigbee device 20) gracefully exit the diagnostic mode and the pre-defined ad hoc network in step S528 (EX DM). Then, in step S529 (SW NM), they switch back to their normal operating mode. In an example, factory settings may be kept during the diagnostic mode.

[0112] Options for a graceful exit may be that the Zigbee device exits the diagnostics mode after a predefined time has elapsed or that a device power cycle forces the Zigbee device to always reboot into its normal operation mode (i.e., the diagnostic mode being a special on-demand mode initiated via custom tools), or that at the end of the diagnostic process the diagnostic device 10 may broadcast another command on the predefined ad hoc network to ask all Zigbee devices to exit from the diagnostic mode, or that a user can abort an ongoing diagnostic process via the mobile app and the diagnostic device 10 may then broadcast another command on the predefined ad hoc network to ask all Zigbee devices to exit from the diagnostic mode.

[0113] In step S530 (ANA / DSP), the mobile app analyzes the collected diagnostic test reports of each tested Zigbee node (including the Zigbee node 20) and outputs (e.g., displays) a combined diagnostic report on a user interface.

[0114] In an optional step S531 (UA Ni), a user or installer can open each tested Zigbee device (including the Zigbee device 20) to see diagnostics test details, identify troubleshoot instructions, etc.

[0115] Finally, in step S532 (STP MA), the mobile app may be exited or reset or the like.

[0116] Fig. 6 shows an example of a sequence of display information shown on a display (e.g., touchscreen) 322 of a user interface of a mobile device (e.g., a the user interface 32 of the mobile device 10 of Fig. 1) during a pre-commissioning diagnosis procedure, according to an embodiment. The sequential display report may include information such as list of nodes, type, diagnostics test status, identify troubleshooting options or the like.

[0117] In Fig. 6, the sequence of successively displayed information is shown from the left portion to the right portion.

[0118] In a first display step S601, a “connect-to-device” button (CNCT) 321 may be shown, which can be activated (e.g., touched) to initiate a search and connection process (e.g., as explained in connection with step S506 of Fig. 5).

[0119] A second display step S602 may be initiated after the button 321 has been activated.

[0120] The remaining display steps S602 to S606 indicate in a central field the type or status of the phase in which the diagnoses procedure is at present and comprise a ring-shaped indicator field 323 that indicates how much of the phase has been completed. Additionally, a current phase is marked (e.g., by a bold ring) in an upper diagnosis status field 325 that shows successive phases (e.g., connection (C), network preparation (P), diagnosis (D), reports (R), and finished (F)) of the pre-commissioning diagnosis procedure. Completed phases may also be indicated by a filled ring in the diagnosis status field.

[0121] It is clear that other suitable status indicators may be used, such as bars, symbols, numbers in various shapes and at various positions.

[0122] The second display step S602 relates to the establishment of the connection (“EC”) between the mobile device and the diagnostic device. Here, an increasing angular filling length of the ring-shaped indicator field 323 may show the status of connection establishment. When, the ring-shaped indicator field 323 is filled completely, the connection is established.

[0123] The third display step S603 relates to the preparation of the ad hoc network (“PN”) by the diagnostic device. Here, an increasing angular filling length of the ring-shaped indicator field 323 may show the status of network preparation. When, the ring-shaped indicator field 323 is filled completely, the ad hoc network is prepared. Note that the diagnosis status field 325 indicates that the connection phase (C) has been completed and the network preparation phase (P) is still running.

[0124] The fourth display step S604 relates to the status of the self-diagnosis at the network devices. Here, an increasing angular filling length of the ring-shaped indicator field 323 may show the status of the diagnostic test mode timer. Here, 75% of the diagnostic test period has passed. When, the ring-shaped indicator field 323 is filled completely, the diagnostic test timer has elapsed. Note that the diagnosis status field 325 indicates that the connection phase (C) and the network preparation phase have been completed and the diagnostic phase (D) is still running.

[0125] The fifth display step S605 relates to the status of report generation by the network devices. Here, an increasing angular filling length of the ring-shaped indicator field 323 may show the number of the diagnostic test reports that have been received. When, the ring-shaped indicator field 323 is filled completely, all diagnostic test reports have been received. Note that the diagnosis status field 325 indicates that the connection phase (C), the network preparation phase and the diagnostic phase (D) have been completed and that the report generating phase is still running.

[0126] Finally, the sixth display step S606 relates to the final status of the diagnosis procedure. Here, the angular filling length of the ring-shaped indicator field 323 may show the final number of the diagnostic test reports that have been received e.g. as a portion of the maximum number of diagnostic test reports that could have been received. When, the ringshaped indicator field 323 is filled completely, the maximum number of diagnostic test reports have been received. Here, 190 out of 200 possible diagnostic test reports have been received. Note that the diagnosis status field 325 indicates that all five phases of the diagnosis procedure have been completed.

[0127] In a modification of the above embodiments, the network devices to be commissioned may report their individual diagnostic results (diagnostic test report) before relaying the diagnostic mode request to other network devices. Thereby, the test responses of other network devices (that have not yet switched to diagnostic mode) can be delayed by adding a random back-off period for relaying or diagnostics, which may help preventing message peaks (message storms) within the ad hoc network.

[0128] In another modification of the above embodiments, the network devices to be commissioned may report back their individual diagnostic results (diagnostic test report) to the diagnostic device by using respective inter-network messages (e.g., a Zigbee InterP AN messages). Thereby, the diagnostic device does not need to establish an ad hoc network but needs to listen to the broadcast inter-network messages. This approach has some limitations, in that without use of relays, such would be limited to the one-hop range of inter-network messages.

[0129] In other embodiments, diagnostic test reports of different network devices may be aggregated to condense the response flow. This may be achieved by grouping diagnostic reports together or by comparing diagnostic reports and grouping addresses to a single report for diagnostic test reports with identical or at least similar content. The above embodiments may be implemented in other networks that offer inter-network messages, or allow vendor specific extensions, such as Bluetooth or Thread or other suitable wireless networks.

[0130] Moreover, the established ad hoc network may be used for signaling in connection with later commissioning of the tested and available network devices or in connection with setting lighting parameters of luminaires of a lighting network. In examples, the ad hoc network may be used to program and / or configure at least some commissioning or lighting parameters. This may be achieved by defining a more structured interP AN command frame format (or format of another inter-network message) to address such an extended commissioning or lighting setting function.

[0131] To summarize, methods and devices have been described for providing pre- commissioning diagnostics for wireless networks (e.g., Zigbee, Bluetooth or Thread networks) by using a direct communication technology that offers inter-network messages (e.g., InterP AN, Zigbee Direct, etc.) for exchanging information with devices in their local area without forming or joining a network. Thereby, a pre-commissioning diagnosis of installed nodes of a wireless network (e.g., a Zigbee wireless lighting infrastructure) can be provided prior to commissioning, wherein the nodes (e.g., lighting nodes) may be configured to join a distributed ad hoc network (e.g., a pre-defined Zigbee or Bluetooth or Thread network) and to perform own and network diagnostics. Diagnostics results can then be processed and presented e.g. via a simple and intuitive user interface of a mobile device wirelessly connected to a diagnostic device that uses the direct communication technology.

[0132] While the invention has been illustrated and described in detail in the drawings and foregoing description, such illustration and description are to be considered illustrative or exemplary and not restrictive. The invention is not limited to the disclosed embodiments.

[0133] The invention can be implemented in various types of connected lighting systems (professional) in offices, healthcare, industry, retail, hospitality, homes, as well as applications for agriculture and outdoor applications (e.g., parking lots / garages, standalone networks in outdoor) or other wireless networks where RF sensing is implemented.

[0134] Moreover, the invention can be applied in any wireless network (e.g., Bluetooth Low Energy (BLE) or BLE mesh networks, or in Thread).

[0135] 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. 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 processor or other unit may fulfil 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. The foregoing description details certain embodiments of the invention. It will be appreciated, however, that no matter how detailed the foregoing appears in the text, the invention may be practiced in many ways, and is therefore not limited to the embodiments disclosed. It should be noted that the use of particular terminology when de-scribing certain features or aspects of the invention should not be taken to imply that the terminology is being re-defined herein to be restricted to include any specific characteristics of the features or aspects of the invention with which that terminology is associated. Additionally, the expression “at least one of A, B, and C” is to be understood as disjunctive, i.e., as “A and / or B and / or C”.

[0136] A single unit or device may fulfil 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.

[0137] The described operations like those indicated in Figs. 2 to 6 can be implemented as program code means of a computer program and / or as dedicated hardware of gateway or luminaire devices, respectively. The computer program may be stored and / or 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.

Claims

CLAIMS:

1. A diagnostic device (10) for controlling a pre-commissioning diagnosis of a plurality of network devices (20) in a wireless network, wherein the diagnostic device (10) is configured to: trigger a switch to a diagnostic mode at the one or more network devices (20) by broadcasting a diagnostic mode request via a first inter-network message via a first type of wireless communication, establishing a first ad hoc network using the first type of wireless communication comprising the plurality of network devices (20) upon receipt of a diagnostic mode request from a mobile application (34) on a mobile device (30) via a wireless connection (130) using a second type of wireless communication, prior to commissioning of the one or more network devices (20); use the first ad hoc network for querying diagnostic test reports from the plurality of network devices (20); receive diagnostic test reports from the plurality of network nodes (20) via an inter-network message; and forward received diagnostic test reports of the plurality of network devices (20) to the mobile application (34) via the wireless connection (130) using the second type of wireless communication.

2. The diagnostic device (10) of claim 1, wherein the diagnostic device (10) is configured as a Zigbee Direct device.

3. The diagnostic device (10) of claim 1 or 2, wherein the first inter-network message comprises first network parameters for use in joining the first ad hoc network;4. The diagnostic device (10) of claim 2, the diagnostic device (10) further comprising a diagnostic test mode timer and the diagnostic device (10) is configured to: when the diagnostic test mode time has lapsed, broadcast a “Match Descriptor” command in the first ad hoc network; receive Match Descriptor response(s) from the network devices (20)comprising device short addresses; and add the received short addresses to a short address table.

5. The diagnostic device (10) of claim 4, the diagnostic device (10) further configured to: for each network device in the short address table, transmit a diagnostic test report request using a corresponding short address from the short address table; and receive the diagnostic report responses from each addressed network device.

6. The diagnostic device (10) of claim 5, the diagnostic device (10) further configured to: signal to the first ad hoc network that the diagnostic test phase is finished.

7. A network device (20) for use in the wireless network, the network device comprising a diagnostic device in accordance with any one of claims 2, or 3-6 as dependent on claim 2.

8. The network device (20) of claim 7, the network device (20) configured to: switch to a diagnostic mode in response to a receipt of a diagnostic mode request broadcast via a second inter-network message using the first type of wireless communication prior to commissioning of the network device (20) to: join a second ad hoc network; perform self-diagnostics in the diagnostic mode generating a diagnostic test report; rebroadcast the diagnostic mode request; and when requested to, transmit the diagnostic test report via the second ad hoc network.

9. The network device (20) of claim 8, wherein the network device (20) is configured to join the second ad hoc network, using second network parameters provided in the second inter-network message.

10. The network device (20) of claim 8, wherein the network device is configured to join the second ad hoc network, using pre-defined network parameters.

11. A network system, comprising: - at least one of the diagnostic device (10) of claim 1 and the network device(20) of claim 8; and a plurality of further network devices as claimed in claim 8, the further network devices configured to receive the diagnostic mode request from the diagnostic device (10) or from a network device (20).

12. The network system of claim 11, further comprising: a mobile device (30), the mobile device (30) comprising a mobile application (34) configured to transmit a diagnostic mode request to and to receive diagnostic test reports from the diagnostic device (10), wherein the mobile device (30) comprises a user interface (32) for indicating a type and / or status of a present phase of the pre-commissioning diagnosis.

Images