Control unit and a control system node for a control system

Abstract

A control unit for an installation of a sensor control system comprising a plurality of nodes identified by node identifiers, the control unit configured to issue a broadcast command to multiple nodes using a node identifier which is not specific to a node but instead conveys the broadcast nature of the command. A control unit identified by an installation identifier and configured to receive and store the installation identifier, wherein the control unit is configured to not be able to export the installation identifier outside the installation including to a user of the control system or to a node unrelated to the control system. A control unit comprising a plurality of nodes identified by zone identifiers indicating geographic zones of the installation, the control unit configured to issue a command to the same node using multiple zone identifiers. Related control system nodes, methods, computer programs and computer readable media.

Description

[0001] P12681 PC01

[0002] CONTROL UNIT AND A CONTROL SYSTEM NODE FOR A CONTROL SYSTEM

[0003] Priority Claim

[0004] This application claims priority from GB2500926.7 and GB2501885.5, the contents of which are incorporated by reference.

[0005] Field of Invention

[0006] The present invention relates to a control unit and a control system node for an installation of a sensor and / or lighting control system.

[0007] Summary of Invention

[0008] In accordance with the present invention, there is provided a control unit and a control system node as claimed in the accompanying claims.

[0009] According to a first aspect of the present invention, there is provided a control unit for an installation of a sensor and / or lighting control system comprising a plurality of nodes, the control unit being configured to issue a functional command to a control system node supporting a network of devices to be controlled, wherein the functional command is such that the node will be required to issue multiple implementing commands to device(s) of the network to implement the functional command.

[0010] In an embodiment, the functional command may be directed to a specific device or specific devices of the network of devices, to devices of the network of devices of a specific type and / or all devices of the network of devices by reference to the node.

[0011] In an embodiment, the control unit may be further configured to receive and recognise a combined response to the functional command from the control system node, the combined response containing information from multiple responses sent by device(s) of the network to the control system node.

[0012] In an embodiment, the functional command may be such that the node will be required to issue implementing commands to device(s) of the network at specific times to implement the functional command.

[0013] In an embodiment, the functional command may be such that the node will be required to issue implementing commands to device(s) of the network upon specific criteria being met to implement the functional command.

[0014] Further provided in accordance with a first of the present invention is a corresponding control system node for an installation of a sensor and / or lighting control system. The node is configured to: support a network of devices to be controlled; receive and recognise a functional command from a control unit of the control system; and implement the functional command by issuing multiple implementing commands to device(s) of the network.P12681 PC01

[0015] In an embodiment, the functional command may be directed to a specific device or specific devices of the network of devices, to devices of the network of devices of a specific type and / or all devices of the network of devices by reference to the node.

[0016] In an embodiment, the control system node may be further being configured to: receive and recognise multiple responses to the implementing commands sent from the device(s) of the network; and issue a combined response to the functional command, the combined response containing information from the multiple responses sent.

[0017] In an embodiment, the functional command may be such that the node will be required to issue implementing commands to device(s) of the network at specific times to implement the functional command.

[0018] In an embodiment, the functional command is such that the node will be required to issue implementing commands to device(s) of the network upon specific criteria being met to implement the functional command.

[0019] According to a second aspect of the present invention, there is provided a control unit for an installation of a sensor and / or lighting control system comprising a plurality of nodes, the control unit being configured to issue commands to a node supporting a first protocol compliant network of first protocol devices, the command including: non-first protocol compliant addressing of the node; and first protocol compliant addressing of a first protocol device of the network.

[0020] In an embodiment, the first protocol compliant addressing of a first protocol device may be of a wired network of first protocol-2 devices attached to the node

[0021] In an embodiment, the command to the node may include a payload containing: at least one first protocol compliant command to a first protocol device of the network of first protocol devices. In an embodiment, the command to the node may include includes a payload containing: a plurality of first protocol compliant commands to a first protocol device of the network of first protocol devices.

[0022] In an embodiment, the command to the node may include a payload containing: a first protocol compliant command to a plurality of first protocol devices of the network of first protocol devices. In an embodiment, the command to the node includes a payload containing: a first protocol compliant command to be broadcast to all first protocol devices of the network of first protocol devices.

[0023] In an embodiment, the command to the node may include a payload containing: a plurality of first protocol compliant commands to a plurality of first protocol devices of the network of first protocol devices.

[0024] The first protocol may be Digital Illumination Interface Alliance (DALI) IEC 62386 or derivatives thereof. Also, other standards are contemplated such as Digital Serial Interface (DSI), Digital Multiplex DMX512 etc.

[0025] Further provided in accordance with the second aspect of the present invention is a corresponding control system node for an installation of a sensor and / or lighting control system, the controlP12681 PC01

[0026] system node being configured to receive and recognise a command from a control unit of the control system, wherein the node is configured to: support a first protocol compliant network of first protocol devices, and receive and recognise a command from a control unit of the control system, the command including: non-first protocol compliant addressing of the node; and first protocol compliant addressing of a first protocol device of the network.

[0027] The first protocol compliant addressing of a first protocol device may be of a wired network of first protocol devices attached to the node.

[0028] The control system node may be further configured to: receive and recognise a payload of the command to the node including at least one first protocol compliant command to a first protocol device of the network of first protocol devices, and instruct that first protocol device of the network of first protocol devices in accordance with a first protocol compliant command.

[0029] In an embodiment, the control system node may be further configured to: receive and recognise a payload of the command to the node including a plurality of first protocol compliant commands to a first protocol device of the network of first protocol devices, and instruct that first protocol device of the network of first protocol devices in accordance with the corresponding first protocol compliant commands.

[0030] In an embodiment, the control system node may be further configured to: receive and recognise a payload of the command to the node including at least one first protocol compliant command to a plurality of first protocol devices of the network of first protocol devices, and instruct those first protocol devices of the network of first protocol devices in accordance with the corresponding first protocol compliant command.

[0031] In an embodiment, the control system may be further configured to: receive and recognise a payload of the command to the node including at least one first protocol compliant command to be broadcast to all first protocol devices of the network of first protocol devices, and instruct by broadcast all first protocol devices of the network of first protocol devices in accordance with the corresponding first protocol compliant command.

[0032] In an embodiment, the control system may be further configured to: receive and recognise a payload of the command to the node including a plurality of first protocol compliant command to a plurality of first protocol devices of the network of first protocol devices, and instruct those first protocol devices of the network of first protocol devices in accordance with the corresponding first protocol compliant commands.

[0033] According to a third aspect of the present invention, there is provided a control unit for an installation of a sensor and / or lighting control system comprising a plurality of nodes, the control unit being configured to issue a bundled command to a control system node supporting a network of devices to be controlled, wherein the bundled command contains a payload comprising a plurality of individual commands for the node to transmit to device(s) of the network.

[0034] Further provided in accordance with the third aspect of the present invention is a control system node for an installation of a sensor and / or lighting control system, the control system node being configured to: receive and recognise a bundled command from a control unit of the control system,P12681 PC01

[0035] wherein the bundled command contains a payload comprising a plurality of individual commands for the node to transmit to device(s) of the network; and transmit the plurality of individual commands for the node to device(s) of the network.

[0036] According to a third aspect of the present invention, there is provided a control system node for an installation of a sensor and / or lighting control system, wherein the node is configured to: support a network of devices to be controlled, wherein each device has a unique address; and issue a command to a specific device(s) of the network by issuing the command to all devices of the network on the assumption that only the specific device(s) of the network will recognise and acknowledge the command. The network of devices may be a wired DALI network.

[0037] The node may be further configured to maintain a register of network devices, optionally including an indication of device type and / or an indication of recognised commands.

[0038] The node may be further configured to: determine from the presence of unexpected acknowledgements in response to the command from device(s) from the network that the network of devices is non-compliant with a predetermined network configuration; and notify a user of the determination.

[0039] In accordance with a fifth aspect of the present invention, there is provided a control unit for an installation of a sensor and / or lighting control system comprising a plurality of nodes identified by node identifiers or identifiers of groups of nodes, the control unit being configured to: issue a broadcast command to multiple nodes or multiple groups of nodes using a node identifier or identifier of a group of nodes which is not specific to a node or group but instead conveys the broadcast nature of the command.

[0040] Further provided in accordance with the third aspect of the present invention is a control system node for an installation of a sensor and / or lighting control system and identified by a node identifier or identifiers of groups of nodes with which the node is associated, the control system node being configured to: receive and recognise a broadcast command from a control unit of the installation using a node identifier or identifier of a group of nodes which is not specific to a node or group but instead conveys the broadcast nature of the command.

[0041] In accordance with a sixth aspect of the present invention, there is provided a control unit for an installation of a sensor and / or lighting control system identified by an installation identifier, the control unit being configured to: receive and store the installation identifier, wherein the control unit is configured so as to not be able to export the installation identifier outside the installation including to a user of the control system or to a node unrelated to the control system.

[0042] In an embodiment, the control unit is further configured to: export the installation identifier to other nodes related to the installation including to switches, sensors and other control units of the installation and to commissioning tools for commissioning the installation.

[0043] Further provided in accordance with the sixth aspect of the present invention is a control system node for an installation of a sensor and / or lighting control system identified by an installation identifier, the control system node being configured to: receive and store the installation identifier, wherein the control system node is configured so as to not be able to export theP12681 PC01

[0044] installation identifier outside the installation including to a user of control system or to a node unrelated to the control system.

[0045] In an embodiment, the control system node is further configured to: export the installation identifier to other nodes related to the installation including to switches, sensors and control units of the installation and to commissioning tools for commissioning the installation.

[0046] In accordance with a seventh aspect of the present invention, there is provided a control unit for an installation of a sensor and / or lighting control system comprising a plurality of nodes identified by zone identifiers indicating geographic zones of the installation, the control unit being configured to: to issue a command to the same node using multiple zone identifiers.

[0047] Further provided in accordance with the seventh aspect of the present invention is a control system node for an installation of a sensor and / or lighting control system, the control system node being configured to: receive and recognise a command from a control unit of the control system using multiple zone identifiers of which the node is a part of.

[0048] Further provided in accordance with the first to seventh aspects of the present invention are corresponding methods and computer programs and computer readable media comprising instructions which when executed by an apparatus cause the apparatus to perform at least such methods.

[0049] Some aspects and embodiments provide or relate to wireless solution for providing light control and emergency test management for an installation.

[0050] A communication protocol may be implemented to support a range of node types and may include underlying architecture that means that it is capable of supporting additional node types and functions that are developed in the future.

[0051] Each luminaire or device in a system may supplied with an integral wireless node that communicates to establish networks of varying size and complexity to match requirements. For example, from a simple single office PIR grouping to a full multi-site complex control methodology, the system can adapt to requirements.

[0052] The solution of some embodiments is made up of components that can fit together to offer different levels of control. At the heart of this is a node that is present within each device.

[0053] At the heart of the solution of some embodiments are our core devices that can be deployed at the level to support the needs of a project both now and in the future.

[0054] The devices are versatile, with lighting devices having the ability to auto-detect if mains or DALI emergency devices are connected to work in local semi-broadcast mode; or they can be fully addressed to support up to 64 DALI devices acting as a remote DALI router.

[0055] Devices may be vertically compatible without the need to upgrade or replace as scale up, down or mixing different solution levels is possible.

[0056] Options to have integrated presence and daylight detection, IR receiver, support for self-test and scheduled emergency events as well as being able to schedule automatic running of various tasks autonomously.P12681 PC01

[0057] Devices can be programmed with a versatile full IR controller that is used to set up presence and daylight profiles as well as the creation of wireless PIR groups.

[0058] The personal IR controller can be used for local override and control when the need arises for a specific task related illumination level. This override can be cancelled via the remote, a mains reset of the node or optionally via a selected in-built maintenance timer.

[0059] Emergency function and duration tests can be instigated via the remote fora single luminaire; this can be used for a local test following installation or maintenance when it may not be convenient to instigate a full system wide emergency test via a key switch.

[0060] Devices can be configured using an app. Access to the network may be facilitated, for example, through a BLE enabled wall switch plate or companion device that bridges the app to a propriety network.

[0061] The app may allow access to additional fine-tuning features and more extensive grouping capabilities. Adding pre-defined profiling and system integrity tools that manages the deployment and ensures accuracy as well and offering system backup and reporting features.

[0062] Emergency tests can be instigated with results and any failure data visible; however, this should not be considered as a full auto-test emergency system but rather as a way of gaining additional information when carrying out your manual emergency test obligations or maintenance.

[0063] Connecting the devices to on-site hubs enables the full feature set of the network solution. Pre-commissioning may be carried out to minimise the time required on site, thus reducing the time between final installation and sign off and testing of the control system. Devices may be precommissioned graphically against as-fitted drawings that can be split across various areas or floors of an installation. When they are added to the network the devices may adopt the precommissioned settings and groupings that have been agreed prior to site attendance. This process can streamline the commissioning process and reduce time and cost on site.

[0064] Emergency testing can be set as self-test and report or to test against pre-defined emergency test schedules. Each time an emergency test is completed the status of the test may be sent back to the hub; the date and time of the next test is confirmed and if there is a failure fault data is also automatically received by the hub.

[0065] Emergency testing can also be user-instigated and logged for a single luminaire or group without affecting any pre-defined schedules.

[0066] Full data twin integrity may be maintained between the devices and hub, and multiple hubs can be aggregated where a single pane view of the health and emergency status of the installation can be viewed via a hub-hosted web application. This enables a user to see the health of a system area by area graphically or installation wide showing emergency test status, when next tests are due and the health of the system.

[0067] A primary hub can be set to send reports and alerts either on or off site to ensure that a user stays on top of emergency test obligations and the general health of a lighting installation.P12681 PC01

[0068] The nodes can be configured to report their status or the status of their connected devices, as well and being enabled to carry out a variety of tasks against defined schedules or timed events. If there is a requirement for remote monitoring of multiple sites, the primary hub can be configured to update a cloud managed solution where you can remotely graphically see individual sites or get an overall picture of the health and operation of an entire estate.

[0069] Packet Control

[0070] Radio Frequency Module (RFM)

[0071] The RFM command can be used to fine tune how Radio Frequency (RF) data packets are managed at an end node granular level. The purpose of this is to create a mechanism to allow you to reduce the overall network communication stack when multiple repeaters are in use and restrict the reach of ‘local’ traffic beyond their intended use.

[0072] The RFM mnemonic forms part of the encoded command header in the RF packet.

[0073] DEFAULT BEHAVIOUR

[0074] Each node receives RF packets of data which it will only process if a ‘to address’ scope of the packet matches the one of the following criteria;

[0075] Addressed directly to the Node

[0076] Addressed to one of the Groups that the Node belongs to

[0077] Addressed to one of the Zones that the Node belongs to

[0078] Addressed to all (global broadcast)

[0079] If the packet received requires a response it will respond back to the originator at a default dBm level.

[0080] If the Node self generates an RF packet (prompted by an internal timer or event) it will also send out this packet at a default dBm level.

[0081] CUSTOMISING BEHAVIOUR

[0082] Using a single RFM configuration instruction you can control how a Node configures sent packets and, if a Node has been designated as a Repeater what / how it repeats received packets.

[0083] Packets may be categorised as follows:

[0084] All traffic

[0085] Traffic being sent to / from a Hub

[0086] Traffic being sent to a Group

[0087] Traffic being sent to a Zone

[0088] Node generated Triggers

[0089] Traffic being sent to a single AddressP12681 PC01

[0090] Against each of the above categories an individual dBm value can be set to use and the number of times the packet will be sent.

[0091] It is also possible to set the number of Hop Counts at an individual Node level that will be assigned to any packets that it generates.

[0092] For example, this may enable:

[0093] Define different dBm levels for self-generated ‘local’ traffic that is designed to only be shared with nearby Nodes and a different dBm level when you are sending data to a Hub that may be located further away.

[0094] Only repeat certain types of traffic and at different dBm levels.

[0095] To send selected packet types multiple times if there is a certain areas or location where packets being dropped has been experienced.

[0096] An RFM configuration can be set for an individual Node.

[0097] Further aspects and embodiments are provided in the following numbered paragraphs.

[0098] Hierarchical Command Structure (abstraction)

[0099] Control unit - functional instruction implemented at node

[0100] 1. A control unit for an installation of a sensor and / or lighting control system comprising a plurality of nodes, the control unit being configured to issue a functional command to a control system node supporting a subnet of devices to be controlled, wherein the functional command is such that the node will be required to issue multiple implementing commands to device(s) of the subnet to implement the functional command.

[0101] 2. A control unit according to paragraph 1 , wherein the functional command is directed to a specific device or specific devices of the subnet of devices.

[0102] 3. A control unit according to paragraph 1 , wherein the functional command is directed to devices of the subnet of devices of a specific type.

[0103] 4. A control unit according to paragraph 1 , wherein the functional command is directed to all devices of the subnet of devices by reference to the node.

[0104] Combined response

[0105] 5. A control unit according to any preceding paragraph, wherein the control unit is further configured to receive and recognise a combined response to the functional command from the control system node, the combined response containing information from multiple responses sent by device(s) of the subnet to the control system node.

[0106] Scheduling

[0107] 6. A control unit according to any preceding paragraph, wherein the functional command is such that the node will be required to issue implementing commands to device(s) of the subnet at specific times to implement the functional command.

[0108] ConditionalityP12681 PC01

[0109] 7. A control unit according to any preceding paragraph, wherein the functional command is such that the node will be required to issue implementing commands to device(s) of the subnet upon specific criteria being met to implement the functional command.

[0110] Control system node - functional instruction implemented at node

[0111] 11. A control system node for an installation of a sensor and / or lighting control system, the node being configured to:

[0112] support a subnet of devices to be controlled;

[0113] receive and recognise a functional command from a control unit of the control system; implement the functional command by issuing multiple implementing commands to device(s) of the subnet.

[0114] 12. A control system node according to paragraph 11 , wherein the functional command is directed to a specific device or specific devices of the subnet of devices.

[0115] 13. A control system node according to paragraph 11 , wherein the functional command is directed to devices of the subnet of devices of a specific type.

[0116] 14. A control system node according to paragraph 13, wherein the functional command is directed to all devices of the subnet of devices by reference to the node.

[0117] Combined response

[0118] 15. A control system node according to any of paragraphs 11 to 14, the node further being configured to:

[0119] receive and recognise multiple responses to the implementing commands sent from the device(s) of the subnet;

[0120] issue a combined response to the functional command, the combined response containing information from the multiple responses sent.

[0121] Scheduling

[0122] 16. A control system node according to any of paragraphs 11 to 15, wherein the functional command is such that the node will be required to issue implementing commands to device(s) of the subnet at specific times to implement the functional command.

[0123] Conditionality

[0124] 17. A control system node according to any of paragraphs 11 to 16, wherein the functional command is such that the node will be required to issue implementing commands to device(s) of the subnet upon specific criteria being met to implement the functional command.

[0125] Hierarchical Command Structure (mixed protocol addressing)

[0126] General principle for control unit

[0127] 21. A control unit for an installation of a sensor and / or lighting control system comprising a plurality of nodes, the control unit being configured to issue commands to a node supporting a first protocol compliant subnet of first protocol devices, the command including:P12681 PC01

[0128] non-first protocol compliant addressing of the node; and

[0129] first protocol compliant addressing of a first protocol device of the subnet.

[0130] first protocol-2 Wired Subnet

[0131] 22. A control unit according to paragraph 21 wherein the first protocol compliant addressing of a first protocol device is of a wired subnet of first protocol-2 devices attached to the node Command payload

[0132] 23. A control unit according to paragraph 21 or 22 wherein the command to the node includes a payload containing:

[0133] - at least one first protocol compliant command to a first protocol device of the subnet of first protocol devices.

[0134] Multiple command (i.e. $sAUT), single first protocol device

[0135] 24. A control unit according to paragraph 21 or 22 wherein the command to the node includes a payload containing:

[0136] a plurality of first protocol compliant commands to a first protocol device of the subnet of first protocol devices.

[0137] Single command, multiple first protocol devices

[0138] 25. A control unit according to paragraph 21 or 22 wherein the command to the node includes a payload containing:

[0139] a first protocol compliant command to a plurality of first protocol devices of the subnet of first protocol devices.

[0140] Single command, broadcast to all first protocol devices

[0141] 26. A control unit according to paragraph 25 wherein the command to the node includes a payload containing:

[0142] a first protocol compliant command to be broadcast to all first protocol devices of the subnet of first protocol devices.

[0143] Multiple command, multiple first protocol devices

[0144] 27. A control unit according to paragraph 21 or 22 wherein the command to the node includes payload containing:

[0145] a plurality of first protocol compliant commands to a plurality of first protocol devices of the subnet of first protocol devices.

[0146] 28. A control unit according to any of paragraphs 21 to 27 wherein the first protocol is a DALI protocol.

[0147] General principle for node

[0148] 31. A control system node for an installation of a sensor and / or lighting control system, the control system node being configured to receive and recognise a command from a control unit of the control system, wherein the node is configured to:P12681 PC01

[0149] support a first protocol compliant subnet of first protocol devices, and

[0150] receive and recognise a command from a control unit of the control system, the command including:

[0151] non-first protocol compliant addressing of the node; and

[0152] first protocol compliant addressing of a first protocol device of the subnet.

[0153] first protocol-2 Wired Subnet

[0154] 32. A control system node according to paragraph 31 wherein the first protocol compliant addressing of a first protocol device is of a wired subnet of first protocol-2 devices attached to the node

[0155] Command payload (and passing on instruction by node to first protocol device)

[0156] 33. A control system node according to paragraph 31 or 32 further configured to: receive and recognise a payload of the command to the node including at least one first protocol compliant command to a first protocol device of the subnet of first protocol devices, and instruct that first protocol device of the subnet of first protocol devices in accordance with a first protocol compliant command.

[0157] Multiple command, single first protocol device

[0158] 34. A control system node according to paragraph 31 or 32 further configured to: receive and recognise a payload of the command to the node including a plurality of first protocol compliant commands to a first protocol device of the subnet of first protocol devices, and (individually / sequentially?) instruct that first protocol device of the subnet of first protocol devices in accordance with the corresponding first protocol compliant commands.

[0159] Single command, multiple first protocol devices

[0160] 35. A control system node according to paragraph 31 or 31 further configured to: receive and recognise a payload of the command to the node including at least one first protocol compliant command to a plurality of first protocol devices of the subnet of first protocol devices, and

[0161] instruct those first protocol devices of the subnet of first protocol devices in accordance with the corresponding first protocol compliant command.

[0162] Single command, broadcast to all first protocol devices

[0163] 36. A control system node according to paragraph 13 further configured to:

[0164] receive and recognise a payload of the command to the node including at least one first protocol compliant command to be broadcast to all first protocol devices of the subnet of first protocol devices, and

[0165] instruct by broadcast all first protocol devices of the subnet of first protocol devices in accordance with the corresponding first protocol compliant command.

[0166] Multiple command, multiple first protocol devicesP12681 PC01

[0167] 37. A control system node according to paragraph 10 or 11 further configured to: receive and recognise a payload of the command to the node including a plurality of first protocol compliant command to a plurality of first protocol devices of the subnet of first protocol devices, and

[0168] instruct those first protocol devices of the subnet of first protocol devices in accordance with the corresponding first protocol compliant commands.

[0169] 38. A control unit according to any of paragraphs 31 to 37 wherein the first protocol is a DALI protocol.

[0170] Hierarchical Command Structure (INSTRUCTION bundling)

[0171] General principle for control unit

[0172] 41. A control unit for an installation of a sensor and / or lighting control system comprising a plurality of nodes, the control unit being configured to issue a concatenated command to a control system node supporting a subnet of devices to be controlled, wherein the concatenated command contains a payload comprising a plurality of individual commands for the node to transmit to device(s) of the subnet.

[0173] General principle for node

[0174] 42. A control system node for an installation of a sensor and / or lighting control system, the control system node being configured to:

[0175] receive and recognise a concatenated command from a control unit of the control system, wherein the concatenated command contains a payload comprising a plurality of individual commands for the node to transmit to device(s) of the subnet; and

[0176] transmit the plurality of individual commands for the node to device(s) of the subnet.

[0177] Specific DevicelD or GroupID indicates a broadcasting command.

[0178] General principle for control unit

[0179] 51. A control unit for an installation of a sensor and / or lighting control system comprising a plurality of nodes identified by node identifiers or identifiers of groups of nodes, the control unit being configured to:

[0180] to issue a broadcast command to multiple nodes or multiple groups of nodes using a node identifier or identifier of a group of nodes which is not specific to a node or group but instead conveys the broadcast nature of the command.

[0181] General principle for node

[0182] 52. A control system node for an installation of a sensor and / or lighting control system and identified by a node identifier or identifiers of groups of nodes with which the node is associated, the control system node being configured to:

[0183] to receive and recognise a broadcast command from a control unit of the installation using a node identifier or identifier of a group of nodes which is not specific to a node or group but instead conveys the broadcast nature of the command.P12681 PC01

[0184] Installation ID not accessible by users of a site installation / external nodes.

[0185] 61. A control unit for an installation of a sensor and / or lighting control system identified by an installation identifier, the control unit being configured to:

[0186] receive and store the installation identifier,

[0187] wherein the control unit is configured so as to not be able to export the installation identifier outside the installation including to a user of the control system or to a node unrelated to the control system.

[0188] 62. A control unit according to paragraph 61 , wherein the control unit is further configured to: export the installation identifier to other nodes related to the installation including to switches, sensors and other control units of the installation and to commissioning tools for commissioning the installation.

[0189] 63. A control system node for an installation of a sensor and / or lighting control system identified by an installation identifier, the control system node being configured to:

[0190] receive and store the installation identifier,

[0191] wherein the control system node is configured so as to not be able to export the installation identifier outside the installation including to a user of control system or to a node unrelated to the control system.

[0192] 64. A control system node according to paragraph 63, wherein the control system node is further configured to:

[0193] export the installation identifier to other nodes related to the installation including to switches, sensors and control units of the installation and to commissioning tools for commissioning the installation.

[0194] Mapping to more than one zone.

[0195] 71. A control unit for an installation of a sensor and / or lighting control system comprising a plurality of nodes identified by zone identifiers indicating geographic zones of the installation, the control unit being configured to:

[0196] to issue a command to the same node using multiple zone identifiers.

[0197] 72. A control system node for an installation of a sensor and / or lighting control system, the control system node being configured to:

[0198] receive and recognise a command from a control unit of the control system using multiple zone identifiers of which the node is a part of.

[0199] Different aspects and embodiments of the invention may be used separately or together.

[0200] The present invention is also described, by way of example, with reference to the accompanying drawings.

[0201] All orientational terms, such as upper, lower, radially and axially, are used in relation to the drawings and should not be interpreted as limiting on the invention or its connection to a closure.P12681 PC01

[0202] Example embodiments are described in sufficient detail to enable those of ordinary skill in the art to embody and implement the systems and processes herein described. It is important to understand that embodiments can be provided in many alternate forms and should not be construed as limited to the examples set forth herein.

[0203] Accordingly, while embodiments can be modified in various ways and take on various alternative forms, specific embodiments thereof are shown in the drawings and described in detail below as examples. There is no intent to limit to the particular forms disclosed and as well as individual embodiments the invention is intended to cover combinations of those embodiments as well. On the contrary, all modifications, equivalents, and alternatives falling within the scope of the appended claims should be included. Elements of the example embodiments are consistently denoted by the same reference numerals throughout the drawings and detailed description where appropriate.

[0204] The terminology used herein to describe embodiments is not intended to limit the scope. The articles “a,” “an,” and “the” are singular in that they have a single referent; however, the use of the singular form in the present document should not preclude the presence of more than one referent. In other words, elements referred to in the singular can number one or more, unless the context clearly indicates otherwise. It will be further understood that the terms “comprises,” “comprising,” “includes,” and / or “including,” when used herein, specify the presence of stated features, items, steps, operations, elements, and / or components, but do not preclude the presence or addition of one or more other features, items, steps, operations, elements, components, and / or groups thereof.

[0205] Unless otherwise defined, all terms (including technical and scientific terms) used herein are to be interpreted as is customary in the art. It will be further understood that terms in common usage should also be interpreted as is customary in the relevant art and not in an idealized or overly formal sense unless expressly so defined herein.

[0206] Brief Description of the Drawings

[0207] Figure 1A illustrates, schematically, a lighting control system deployed in a building and implementing some aspects of the present invention;

[0208] Figure 1B illustrates, schematically, the lighting control system of fig. 1A.

[0209] Figure 2 illustrates, schematically, a control system element / node of the control system of fig. 1A and 1B; and

[0210] Figure 3 illustrates, schematically, a further embodiment of a control system with centralised and distributed control elements according to some further aspects of the present invention; and Figure 4 illustrates a control method according to a further aspect of the present invention.

[0211] Detailed DescriptionP12681 PC01

[0212] Aspects of the present invention can be implemented in a system architecture, firmware and hardware developed by the Applicant, especially for lighting control systems. Also related thereto are end-user interfaces (e.g. GUIs, phone and tablets apps, database management etc.) for control of the same.

[0213] System

[0214] Figs 1A illustrates, schematically, a lighting control system installation 10 suitable for implementing aspects of the present invention. The lighting control system is shown illustrated in an office / factory environment 11 with six rooms 12 and a corridor 12’, each having a number of lighting system elements. A number of luminaires are shown represented by a star, located in each room and the corridor. A luminaire can be thought of as dumb, and not part of the lighting control system though it would be possible for lighting control system elements to be incorporated in a luminaire as opposed to being merely wired to a luminaire. Such luminaires might be LED lights, fluorescent strip lighting etc. The lighting control system is shown comprises lighting switches in each room 14 and a lighting switch panel 14’ in the corridor which may control lighting for the whole corridor and / or the rooms. Also in the corridor is a number of PIR sensors 15, 15’ used to control lighting based on in the presence / absence of movement. Lighting switch panel 14’ may be configured to issue suitable lighting control commands to selectable luminaires or groups thereof, and also may configure the behaviour of sensors (e.g. PIR sensitivity, how long a PIR activated luminaires is switched on for etc.). Conventional control technologies might be used to implement this such as the commercially available Digital Addressable Lighting Interface (DALI), a 2-way communications protocol that for control of DALI enabled luminaires.

[0215] A lighting control hub 16 is shown which may further control the luminaries via the switches, configure the switches, instigate / record lighting tests, and provide an interface to an external server 17 of the provider of the lighting control system for the purposes of commissioning and, optionally managing, the lighting control system (e.g. establishing lighting configurations, behaviour etc.). For example, the hub may be provided on a single board, Raspberry Pi, platform equipped with interfaces for connecting to the other elements of the lighting control system and the server. In addition, a dedicated commissioning tool 18 is shown which may be used by a technician to control and also commission the lighting control system on the move, i.e. with similar abilities as the hub. Such a commissioning tool might be implemented in software on a laptop PC or tablet with wireless network access (not shown) to the hub 16 and the server 17.

[0216] Logically, the lighting control system installation 10 is defined to include the lighting system elements (switches 14, sensors 15 and the hub) but also the external server 17 of the provider of the lighting control system and the commissioning tool. I.e. as illustrated in fig. 1 B. Also, logically defined are two geographic regions 19, 19’ for the purposes of controlling lighting elements within those geographic regions.

[0217] Note, the lighting control system installation of fig. 1 is very simple and, in practice, a lighting control system installation might occupy a substantially larger area, multiple buildings and consist of many 100s or 1000s of elements (including other types of elements than those illustrated). Installation (Installation! D)P12681 PC01

[0218] At the time of commissioning, the lighting control system installation was assigned a unique installation identifier, generated by the external server 17 of the provider of the lighting control system, and conveyed to the elements of the lighting control system installation within the building via hub 16 and the commissioning tool 18.

[0219] In accordance with one aspect of the present invention, elements of the lighting control system (switches 14, sensors 15, hub 16) may receive and store the installation identifier, but are configured as to not be able to export the Installation ID outside the installation including to a user of the lighting control system or to an element unrelated to the installation. For this purpose, The Installation ID may logically define the installation as including the server 17 and commissioning tool 18 since they necessarily interface with lighting control system elements even though they may be located off site. Elements of the lighting control system may be configured to export the Installation ID to other elements of the installation.

[0220] By preventing exporting of the Installation ID outside the installation, a level of security is provided to mitigate the risks of unauthorised or inadvertent access to the control off the site. Ideally, it will not be possible for any device outside the installation to discover or retrieve this installation ID including communications devices which share communications infrastructure with elements of the installation (i.e. an Ethernet or WiFi network etc).

[0221] Device Addressing (DevicelD)

[0222] As mentioned above, in a large scale installation, there may be many 100s or 1000s of elements / nodes with each requiring a unique identifying address. This may be provided by a MAC address (a hardware identification number) that uniquely identifies each device. For example, a unique MAC address can be pre-programmed into each MCU, hub and commissioning tool. This address will be addressable using a command set for component configuration. Each node may be assigned a 16-bit logical address, usually at the time of commissioning. This corresponds to one of 64,535 (0xFC17 in hex) possible addresses. The address comprises just 2 bytes and may be configured in a logical way so the numbers may be ‘grouped’ to simplify installation commissioning.

[0223] Geographic Zone Addressing (ZonelD)

[0224] As mentioned above, geographic zones 19, 19’ can be logically defined for the purposes of controlling lighting elements within those geographic zones. As shown in figure 1A, region 19 encompasses 3 lights (stars) and region 19’ encompasses 4 lights (stars) with one in common. In accordance with a further aspect of the invention, lighting settings for all luminaires in a geographic zone can be effected by a zonal command. I.e. whereby a control unit such as a switch or control panel issue a command, typically as a broadcast, to a control system element / node of a luminaires referencing a ZonelD. In the case of the overlapping luminaire, it may be controlled by reference to multiple zone identifiers. Correspondingly, such a control system element / node may receive and recognise a command from a control unit using any one of multiple zone identifiers of which the control system element / node is a part of.

[0225] BroadcastP12681 PC01

[0226] Many commands may be sent by a control system element / node (source) to one other receiving control system element / node (destination), i.e. one-to-one communication. In these cases, the specific device address DevicelD will be contained within the command. Where a command is sent from a control system element / node (source), a corresponding response from the receiving device can be provided once the device has executed the function required by the controlling device.

[0227] Alternatively, in accordance with a further aspect of the present invention, a controlling device may sent a command to multiple receiving control system element / nodes. Such a broadcasted command may be addressed to a specific ‘destination’ control system element / node defined so as to convey the broadcast nature of the command, i.e. not one that actually exists. For example, destination = control system element / node DevicelD 0x0000 can be flag for a broadcasted command, not a control system element / node as such. All devices will react to a broadcast to DevicelD 0x0000. To minimize RF traffic, commands sent in a broadcast mode may not be responded to. All nodes will take note of a general broadcast command and process that command if the command function is supported by the device. If not, the command is ignored. Group Addressing (GroupID)

[0228] In addition to geographic zoning, each control system element / node can be organised in to logical groups which do not necessarily align to the geographic zones. For example, a control system element / node may maintain a stored table of n logical lighting groups. This enables broadcast lighting commands to be routed throughout the group members and to different groups. Consequently, unlike lighting zones, nodes within a group can be configured to control each other. Although not necessarily aligned to the geographic zones, groups of control system element / node may have some geographic relationship. Examples in corridors, demonstration stage areas, lobbies etc.

[0229] Similarly to the flagging of a broadcasting command by referencing a specific control system element / node (which is a flag for a broadcasted command, not a control system element / node as such), the same can be achieved by referencing a specific group of control system elements / nodes. For example, destination GroupID = control system element / node 0x0000. All devices in each group will react to a broadcast to GroupID 0x0000.

[0230] Fig. 2 illustrates a suitable architecture of a control system elements / node. The architecture provides for a microcontroller unit with an integral transceiver (not shown), a Joint Test Action Group (JTAG) programming interface, a serial Transistor-Transistor Logic (TTL) communications interface and a general-purpose input / output (GPIO) interface. The MCU is connected to memory and an antenna. For example, the MCU may be a Texas Instruments CC1310 MCU - a three-core device incorporating two ARM cores (M3 which handles the main firmware application & M0 which handles the RF physical link), a sub-GHz Transceiver and a proprietary sensor controller core (which handles GPIO input including from sensors and switches).

[0231] Centralised and Distributed Control Elements

[0232] Figure 3 illustrates, schematically, a further embodiment of a control system with centralised and distributed control elements according to some further aspects of the present invention. A centralP12681 PC01

[0233] control unit 31 is provided which may provide functionality along the lines of the hub 16 of figs.

[0234] 1A and 1B. Multiple control system nodes 32 are also provided which may provide functionality along the lines of the switches 14 of figs. 1A and 1B. I.e. an architecture having both centralised and distribution control elements. The control unit may communicate with the control system nodes wirelessly. Each node may be DALI compliant and wired to control individual networked DALI devices (collectively, a DALI ‘subnet’ 33 of which only one is shown) composed of individual control sensors, luminaires and the like.

[0235] An architecture having both centralised and distribution control elements offers certain advantages.

[0236] First, control of an individual device by a control system node can be effected by one control protocol and the control of a control system node by the central control unit can be effected using another control protocol. For example, collection of individual, wired network devices can be efficiency controlled using DALI subnet control. However, aspects of DALI including device discovery are notoriously complex and another protocol could be used for wireless control between the control unit 31 and the control system nodes 30.

[0237] Wireless control between the control unit 31 and the control system nodes 30 using a non-DALI protocol could provide for a suitably configured control unit to issue complex, compound and functional commands to a control system node (e.g. ‘dim all luminaires in the corresponding DALI subnet’) offering a level of command abstraction. Upon receiving and recognising such a non-DALI command, the control system node implement the command by issuing corresponding multiple individual DALI instructions to luminaires in the DALI subnet.

[0238] Such complex, compound and functional commands might include commands to:

[0239] ■ control multiple devices attached to a control node in a single instruction such as:

[0240] ■ turn on all devices connected to the control node

[0241] ■ turn off all lighting connected to the control node (i.e. reference to type but also possibly logical groups with group addressing as discussed above)

[0242] ■ instigate self-testing of all devices connected to the control node

[0243] ■ firm alarm drills in a control node subnet, lighting is turned on, relays thrown to release door locks, alarms sound etc.

[0244] ■ control multiple devices in a single instruction by reference to device type such as lighting as mentioned

[0245] ■ control a single device multiple times such as:

[0246] ■ scheduling periodic tasks such as regular self-testing

[0247] ■ scheduling default lighting on / off periods

[0248] ■ implement conditional behaviour including involving multiple devices such as:

[0249] ■ instructing all lighting connected to the control node to be on if the ambient light level determined by periodically interrogating a nearby PIR sensor connected to the control node is below a threshold.P12681 PC01

[0250] Where those individual instructions yield multiple acknowledgements sent from individual devices of a subnet to a corresponding control node, those acknowledgements could be concatenated / combined into a single response to be sent by the corresponding control node to the control unit. For example, when the control node has received all expected asynchronous acknowledgements so the centralised control unit need receive only a single response.

[0251] Using different protocols for control unit-control node communication as compared to control node-device communication might entail different or compound device addressing. For example, a control unit may be configured to address commands to controls node using a first protocol addressing scheme, whereas those control nodes may issue commands to individual devices using a second addressing protocol. So, in the event that the central control unit wishing to command a specific device may have to provide an address of a corresponding node according to the first addressing protocol and the address of the specific device according to a second protocol.

[0252] DALI device acknowledgement

[0253] In a wired DALI device subnet 33, successful recognition and receipt of a control node command will ordinarily be acknowledged by DALI devices. In the event that such a command is not issued to an individually addressed device, but to all devices of a subnet (a DALI subnet can typically consist of up to 64 devices), a control node may experience inference or crossover if multiple simultaneous device acknowledgements are received at the same time (since anti-collision measures such as listen-before-talk may not be employed with acknowledgements).

[0254] Here, the inventors have recognised that, in the event that the configuration of a DALI subnet can be controlled whereby it can be assumed or determined that a particular control node command will only be recognised by a specific device(s) of the network, the likelihood of acknowledgement interference for a command issued to all devices of a DALI subnet can be avoided or at least reduced.

[0255] For example, as illustrated in fig. 4, suppose a control node wishes to interrogate the only PIR sensor in a DALI subnet to ascertain the ambient lighting level with a PIR specific command. The control node maintains a device register including devicelD and deviceType and thus is able to determine at Step S1 that a PIR specific command will only be recognised and acknowledged by the single PIR sensor device of the DALI device subnet.

[0256] As such, although the PIR sensor can be individually addressed to the PIR sensor using devicelD (optional Step 2a), an alternative is to issue a DALI command to all devices on the subnet (alternative Step 2b) on the assumption that only a single acknowledgement (Step S3) will be received by the control node.

[0257] The advantage of doing this is to avoid the complexity of DALI device addressing. Also, upon a determination of a presence of an unexpected acknowledgement(s) in response to a device specific command issued to all device(s) of a DALI subnet, it may be determined that the network of devices is non-compliant with a predetermined network configuration, and a user may be notified accordingly.P12681 PC01

[0258] Example Firmware

[0259] The architecture supports proprietary command and communication protocols that have been developed by the inventors which provide for certain functional requirements including:

[0260] ■ supporting a large number of nodes.

[0261] ■ low RF packet size to minimize radio traffic.

[0262] ■ a comprehensive and flexible command set.

[0263] ■ a straightforward and logical command structure to facilitate end-user software (application level) development.

[0264] ■ straightforward installation and commissioning.

[0265] ■ remote testing and fault-finding.

[0266] ■ semi-autonomous monitoring, testing and reporting including for emergency lighting. Local ‘Direct’ Connection 0x0001

[0267] When a hub, access point or hand-held controller has a one-to-one connection with a device, for example over a USB-TTL serial link or Bluetooth connection, the connected device will always respond to an address ‘1’ irrespective of any pre-configured RF node address. This is termed a ‘local’ or ‘direct’ connection and enables the directly coupled device to be configured, tested or commissioned. Commands communicated in this mode are never forwarded.

[0268] System controllers, hubs, access points 0xFF01- OxFFFE

[0269] These reserved addresses mean that up to 253 hubs / access points may be distributed across an installation. Commands intended for supervisory control of the system can be routed to all access points whilst being ignored by all other devices on the network. A ‘broadcast’ command of “OxFFOO” will be actioned by all hubs.

[0270] Factory use OXFFFF

[0271] No device in any installation will be able to be configured to this address - it is restricted solely to factory use. There will be small number of configuration commands that can only be set or interrogated at the point of manufacture and will only be executed by the receiving device if the ‘source’ is identified as being a factory address. This will prevent accidental re-configurations by incorrect commands being set from a controller or access point that would render the installation unusable, (e.g. changing the mode of RF transmission).

[0272] Geographic Zones (0x02 - 0x3E7)

[0273] As mentioned above, commands sent to lighting zones will be acted upon by all nodes in that zone. To minimize RF traffic, the receiving nodes will generally not send a response message. Zones are distinct from Groups in that nodes within a zone can only be controlled by controllers. E.g. Wall Switches Plates, Hubs etc.. Therefore, nodes configured to be within a zone cannot trigger other nodes within that zone just by the fact of being in a zone. Node to node control is possible with Groups, see below. In effect, Areas I Lighting Zones can be viewed as acting as ‘filtered’ broadcast commands.P12681 PC01

[0274] Groups

[0275] Each device integrated within a luminaire (or wired to multiple luminaires) will maintain a stored table of 16 logical lighting groups. This enables ‘broadcast’ lighting commands to be ‘routed’ to different scenes or groups. Examples might be corridors, demonstration stage areas, lobbies etc. Consequently, unlike lighting zones, nodes within a group can be configured to control each other. The theoretical maximum number of lighting groups in an installation will be 65,534 (OxFFFE).AII devices in each Lighting Group e will react to a ‘broadcast’ lighting Group of 0 (0x0000).

[0276] Packet Structure & Command Line Interface (CL!)

[0277] The communication of Dexnet commands between nodes is by variable length binary data packets. The structure of these packets is proprietary to DLG and has been specifically designed to enable most control commands to be sent, repeated and received with the smallest possible data packet size.

[0278] The network functionality requires:

[0279] ■ Support for over 60,000 uniquely addressable system modules (nodes) in each site installation.

[0280] ■ Sub-addressing by Lighting Zones (physical location / areas)

[0281] ■ Sub -addressing by Lighting ‘Groups’ (logical ‘scenes’ etc.)

[0282] ■ Broadcast - all nodes reacting (but not responding)

[0283] ■ Repeaters - the ability to ‘forward’ r.f packets to extend communication range.

[0284] ■ Hop counts and suppression of already received (i.e., repeated packets).

[0285] ■ Received packet ‘queuing’ to minimize risk of missed packets.

[0286] ■ Functionality of nodes to generate autonomous event messages.

[0287] ■ Potential individual control of up to 64 addressed DALI devices wired to node.

[0288] All the above to be contained within very short data packet lengths. Ideally, where responses are required from a given node, the command packets should be limited to two - i.e. A ‘command’ transmitted and a ‘response’ received.

[0289] Each command packets needed to be contained within maximum size of the Tl EasyLink_Packet payload field. (Defined as EASYLINK_MAX_DATA_LENGTH 128).

[0290]

[0291] P12681 PC01

[0292]

[0293] Table 1 : Explanatory Notes on Packet Fields

[0294] Start Header

[0295] The Start Header determines which of four types of command:

[0296] ■ General Command - Command instigated by controlling device (Source). ASCII character ‘$’

[0297] ■ Response Command - Indicates returned ‘answer’ from receiving device. ASCII character ‘#’

[0298] ■ Event Command - A notification autonomously generated from a node. ASCII character ‘I’

[0299] ■ Special Command - Reserved for development or future use. ASCII character '*’ The MSB is set (Byte OR’ed with (0x80) to indicate the frame is in binary form.

[0300] Frame Version

[0301] Determines the version of the packet. Currently this is, by, default 1. For future proofing, it may be possible to introduce new shorter packets, or ones with different functionalities. This would necessitate pre-existing products being able to detect and reject various packet types.

[0302] Packet LengthP12681 PC01

[0303] This supports the TX and RX of variable packet sizes. The minimum size of the packet is 17 bytes but can be extended to a maximum of 128. This maximum value is dictated by the Tl EasyLink Payload length.

[0304] Hop Count / Packet ID

[0305] Whenever a node instigates a transmission of a command, it first sets a packet ID number. This number may be generated sequentially or, in some case, randomly. It also initializes a hop count value. This enables repeater functionality to be implemented. As packets are received by a node, the packet ID and source address is stored in a circular buffer table. Hence, if an identical frame is received (i.e. because of it being repeated) then the node ignores the packet. If a node is configured to act as a repeater, any received packet is forwarded, but with a decremented hop count. When the hop count reaches 0, it is no longer forwarded.

[0306] Destination Address

[0307] If set to a specific address >= 1000 then the node with that unique address will process the command and respond accordingly. If set to a broadcast address (0, or 2-999) then all nodes within that Lighting Zone will process the command but will not instigate a response.

[0308] Source Address

[0309] Normally, this will be the address of the node instigating the command. The receiving node then will generate a response to that node if appropriate. However, in some circumstances the node issuing the command can be configured to ‘redirect’ the response to a different node - e.g. a hub. This use-case is probably restricted to system diagnostic tests.

[0310] Group

[0311] This field works in a similar way to the Lighting Zone, but has significantly more flexibility. Firstly, it supports a table of up to 16 groups, each of which can be assigned a 16 bit value. It also supports the implementation of presence detection trigger sharing include Aisle mode (bubble-of-light). This is detailed further in this document (see . ).

[0312] Command ID

[0313] The command protocol currently supports some 49 commands in its API. Each command may be either ‘setters’ (e.g. to update a value or sets of) or ‘getters’ to request a current value. Each command has its unique ID (currently from 0x00 through 0x31). However, these commands themselves may have an extensive sub-set of commands. For example, ‘raw’ DALI commands can be ‘tunnelled’ which can comprise over 200 commands. A full explanation of these is outside the scope of this document, however some examples will be given further.

[0314] Command Index

[0315] This field that contains options or selection of a ‘sub-command’ for a specific command ID. The upper bits of this fields determines the parameter type, e.g. integer (fixed length) or string (variable length).

[0316] ParametersP12681 PC01

[0317] This is the only variable size field in the packet whose size is determined by the parameter type and, if applicable, the length of the string.

[0318] TestCode

[0319] Initially this field was intended for development / diagnostic use only. However, some amended commands use this field for enhanced functionality.

[0320] Error Code

[0321] If a processing error is detected by the firmware, for example a parameter received would exceed an index entry into a table or say, exceed a maximum value, then the response would report a corresponding error code in this field.

[0322] Packet - Summary

[0323] The packet described above has similarities to the IP (Internet Protocol) packet structure. However, the IP structure has been specifically designed to support the TX and RX of large data packets (up to 64Kbytes). The IP structure is also agnostic to the nature of data being communicated. The IP Packet structure may be viewed as the Network level in the OSI model of computer networking. The above packet differs significantly from this model as it encapsulates, within very small packet sizes (potentially less than 30 bytes) both the Network and Transport level in the Dexnet / Dexcore communication architecture. It would be portable to any Data or Physical layers.

[0324] Command Line Interface

[0325] Every system component (nodes) has a method of direct one-to-one ‘local’ connectivity, although the physical form may vary. Sensor Controllers - The serial communication lines (TX / RX) are exposed at TTL level. This connection is primarily intended, not only to aid system development and debugging, but to facilitate automated factory testing and configuration.

[0326] ■ Comms Tool - These have two communication methods via USB ‘C’ Device (operating as Virtual Com Port) or Bluetooth Low Energy (BLE).

[0327] ■ Wall Switch Plate - These have two communication methods via serial communication lines (TX / RX) are exposed at TTL level (operating as Virtual Com Port) or Bluetooth Low Energy (BLE). In common with Sensor Controllers the TTL connection facilitate automated factory testing and configuration.

[0328] ■ Hub - As described previously (add link TODO) a hub comprises a Raspberry Pi SBC directly connected by a pluggable ‘hat’ to the Pl’s power supply and serial port lines. There are additional connections to the programming interface connectors to facilitate automated factory testing and configuration. A command line interface, ASCII based, is incorporated into each system component to provide a simple API to external devices such as P.C.s, laptops, tablets, smartphones etc. Data will be transmitted to and from a node via a 2 wire TTL (3.3v max level) connection (RX / TX). This will not apply if method of interface is by way of USB-TTL module / device (e.g. FTDI) or wirelessly using Bluetooth. The default baud rate will be 115200, one start bit, one stop bit, no parity. The text format will be simple ‘C’ string character (unsignedP12681 PC01

[0329] byte) arrays which are null terminated. The maximum length is TBD but would not exceed 64 bytes.

[0330] Note, although all devices will have hardware support for direct (hard-wired) serial communications, these will not be generally accessible by the end-user. The primary requirement is to enable the devices to be tested at the time of production or integrating to a suitable single board computer (e.g. Raspberry PI etc.)

[0331] ASCII (Text Based) Frames

[0332] These frames will be single frames of ‘C’ type strings (i.e. array of character bytes terminated by ‘null’ (0)). The variable length of these strings will be unrestricted (for practical purposes) and will be exclusively used in the direct / local mode described previously. The local connection mode will be the method in which the application (user software) interfaces. This will facilitate the development of the user software by other parties.

[0333] Data Types

[0334] The command structures will recognize three data types:

[0335] ■ Text - e.g. setting I getting installation location, serial number, firmware versions etc. ■ Single value numeric - integer values (signed or unsigned). Values can be expressed in decimal or hexadecimal format, (e.g. 1234, or 0x4D2 [case insensitive]).

[0336] ■ Byte array - integer unsigned values only, expressed in hexadecimal format, (e.g.

[0337] 0x12bgf1d7c3)

[0338] Frame Structure

[0339]

[0340] P12681 PC01

[0341]

[0342] Table 2: Frame Structure

[0343] Result Code: All error codes have a value greater than 100. Unless there is an error, this result code will be an indication of the RSSI level. This has been introduced primarily as an aide to site testing and commissioning.

[0344] Tool Chain / Utilities

[0345] The firmware is written in ‘C’ and built and debugged using Tl’s Code Composer Studio. The code for the CC1310 Sensor Controller CPU is developed using the Tl’s Sensor Controller Studio Application. Tl’s Smart R.F. Studio Application is a useful application for low-level monitoring of RF data traffic.

[0346] Being based on the Tl CC1310, it was deemed appropriate to follow the application notes from Tl and base the code on the sample project code examples provided by Tl and implemented on their “Launchpad” evaluation boards. Consequently, a substantive part of the code developed at Dextra has retained references to system #defines prefixed with CC1310_LAUNCHXL. AlthoughP12681 PC01

[0347] theoretical possible to re-structure source code to eliminate these references, it was considered prudent to leave ‘as-is’.

[0348] Tl CC1310 Key Source Code Files

[0349] The architecture for all the code used in “Dexcore” is bare-metal. i.e. It utilizes the NRTOS (no Real Time Operating System) versions of the Tl produced source files. Basing the following on the Open Systems Interconnection (OSI) network model, the Physical Data Link layer in the “Dexcore” is wireless transmission in the 868 MHz ISM band. The Transceiver is embedded within the CC1310 MCU controlled by its own 32-bit MO ARM-based core.

[0350] The Data Link Layer has been coded by Tl in their proprietary pre-compiled driver libraries, with the header #include <ti / drivers / rf / RF.h>. No amendments to this driver code have been made. Tl provide an API library named “EasyLink”. The EasyLink API is intended to abstract the RF Driver to provide a simple API for customers to use as is or extend to suit their application use cases.

[0351] This library requires several files that determine the precise settings for the RF driver. These ‘IT and ‘c’ files for these are found in the smartrf_settings folder. Save for one key modification detailed in EasyLink Packet Structure & Site IDs no amendments have been made to these files. However, it is to be noted that these files are automatically created by the Tl Smart RF Studio application. Currently, the “Dexcore” utilizes the ‘out-of-the-box’ settings used by the ‘EasyLink’ demonstration applications. In the future, Dextra may Dextra RF Lighting Control System -“DexCore & DexNet” consider varying these settings to maximise range or communication timings. Any such variations would, of course, result in inoperability between systems.

[0352] Tool Chain / Utilities

[0353] The firmware is written in ‘C’ and built and debugged using Tl’s Code Composer Studio.

[0354] The code for the CC1310 Sensor Controller CPU is developed using the Tl’s Sensor Controller Studio Application.

[0355] Tl’s Smart RF Studio Application is a useful application for low-level monitoring of RF data traffic. Being based on the Tl CC1310, it was deemed appropriate to follow the application notes from Tl and base the code on the sample project code examples provided by Tl and implemented on their “Launchpad” evaluation boards. Consequently, a substantive part of the code developed at Dextra has retained references to system #defines prefixed with CC1310_LAUNCHXL. Although theoretical possible to re-structure source code to eliminate these references, it was considered prudent to leave ‘as-is’.

[0356] Tl CC1310 Key Source Code Files

[0357] The architecture for all the code used in “Dexcore” is bare-metal. i.e. It utilizes the NRTOS (no Real Time Operating System) versions of the Tl produced source files.

[0358] Basing the following on the Open Systems Interconnection (OSI) network model, the Physical Data Link layer in the “Dexcore” is wireless transmission in the 868 MHz ISM band.P12681 PC01

[0359] The Transceiver is embedded within the CC1310 MCU controlled by its own 32-bit MO ARMbased core.

[0360] The Data Link Layer has been coded by Tl in their proprietary pre-compiled driver libraries, with the header #include <ti / drivers / rf / RF.h>. No amendments to this driver code have been made. Tl provide an API library named “EasyLink”. The EasyLink API is intended to abstract the RF Driver to provide a simple API for customers to use as is or extend to suit their application use cases.

[0361] This library requires several files that determine the precise settings for the RF driver. These ‘IT and ‘c’ files for these are found in the smartrf_settings folder. Save for one key modification detailed in EasyLink Packet Structure & Site IDs no amendments have been made to these files. However, it is to be noted that these files are automatically created by the Tl Smart RF Studio application. Currently, the “Dexcore” utilizes the ‘out-of-the-box’ settings used by the ‘EasyLink’ demonstration applications. In the future, Dextra may consider varying these settings to maximise range or communication timings. Any such variations would, of course, result in inoperability between systems.

[0362] EasyLink Packet Structure & Site IDs

[0363] The EasyLink API transceives data in the following packet structures: (defined in “EasyLink.h”)

[0364]

[0365]

[0366] These structures contain arrays for the destination addresses. However, by default, the actual data length was set to 1.

[0367] / / Addr size for Filter and Tx / Rx operations

[0368] / / Set default to 1 byte addr to work with SmartRF

[0369] / / studio default settings

[0370] / / static uint8_t addrSize = 1 ;

[0371] static uint8_t addrSize = 4; / / JFH CHANGEDP12681 PC01

[0372] However, the “Dexcore” node addressing system does not utilize the Tl dstAddr field. This is for two reasons:

[0373] ■ 1 byte would restrict the total number of addressable nodes to 255, clearly insufficient commercially.

[0374] ■ The EasyLink API does not, implicitly, support ‘broadcast’ addressing. To implement this, all devices would need to be ‘set’ to the same dstAddr.

[0375] For these reasons, the “Dexcore” addressing structures are contained within the EasyLink uint8_t payload[EASYLINK_MAX_DATA_LENGTH]; / / !< payload of RX'ed packet The payload comprises the “Dexnet” Packet Structure documented in ‘Dexnet’ Packet Structure The EASYLINK_MAX_DATA_LENGTH is #defined as 128 bytes. This limits the Dexnet Packet size to this value.

[0376] Site Addressing

[0377] A ‘Site’ is defined as a complete installation specific to one client in a post-coded area. To prevent the control of one site inadvertently affected a neighbouring one, all nodes (once commissioned) will be assigned a numeric Site ID as determined by Dextra. These IDs will not be configurable or identifiable by the client.

[0378] The dstAddr variable in the EasyLink Stack has been repurposed to support ‘site addressing’. To achieve this, the addrSize field has been amended to 4 bytes, sufficient to support a 24 bit integer value. Since transceiving between nodes requires all dstAddr to be identical, setting this value restricts network communication to that ‘address’. Hence this mechanism supports the concept of a ‘Site Address’ whereby adjacent installations would be communication ‘invisible’ to each other.

[0379] The setting of the addrSize field appears twice in the EasyLink_nortos.c file at line 678:

[0380] EasyLink_cmdPropRxAdv.pAddr = addrFilterTable;

[0381] / / addrSize = 1 ;

[0382] addrSize = 4; / / JFH CHANGED

[0383] N.B. Although this adds a level of security to a site installation it will not reduce the RF network traffic. If installation sites are in close proximity, then additionally they should be configured to operate on different frequency channels

[0384] Firmware Structure

[0385] This section outlines the basic file structure and program ‘flows’. Although there exist several system component types, there is a commonality of files and functionalities across each. As much of the firmware is based Tl’s reference designs and hardware drivers, the underlying source code (‘.C’) and header files (‘.h’) are incorporated without modification. These are:

[0386]

[0387] P12681 PC01

[0388] &

[0389] &

[0390]

[0391]

[0392] Where any Dextra derived code calls functions in any of Tl low-level driver files (e.g. uart.h, gpio.h, spi.h, i2c.h etc) the driver files are unmodified.

[0393] Modified Tl Source / Header Files

[0394]

[0395] Tl Sensor Controller CPU Files

[0396] These relate to the source and output files generated by the Tl Sensor Controller application needed to produce the executable RAM-based code to drive the Sensor Controller Engine. The “Tl Sensor Controller” term does not refer to Dextra’s presence detector sensors (e.g. PIR, Microwave etc.) but to the Tl “Sensor Engine” core within the CC1310.

[0397]

[0398] P12681 PC01

[0399] &

[0400]

[0401] When these projects are compiled and built with the Sensor Controller application the set of files (commencing with ‘seif’) which defines the Sensor Controller Driver Interface to the main application.

[0402] Key Dextra Derived Files

[0403] All Dexcore system component firmware source will contain a version of the following files:

[0404]

[0405] P12681 PC01

[0406]

[0407] Device Specific Dextra Derived Files

[0408] The table given above refers to those files common to all System Component types, albeit that that the functions included will differ dependant on the hardware architecture of a Component. Reference and explanatory notes will be included later in this document as relevant to each command in the Instruction Set. (See... add link TODO).

[0409] Example Dexnet Command StructureP12681 PC01

[0410] A powerful feature incorporated into the ‘Dexnet’ Command Protocol, which can be embedded into a single binary command frame is a hierarchical command structure.

[0411] In ‘Dexnet’ there are three command related fields:

[0412] CommandJD - (60,000 + theoretical possible ‘primary’ commands)

[0413] Commandjndex- (8192 theoretical ‘secondary’ commands)

[0414] Command_Parameter(s) - which can be of up to 8 different data types.

[0415] Examples:

[0416] i)

[0417] In a ‘wired’ DALI lighting control system, the standard DALI commands set comprises two bytes representing one of 254 commands and 255 parameters.

[0418] In Dexnet, executing any one of these DALI commands is implemented by the sending of (CLI ASCII version, prior to encoding into a binary frame: )

[0419] $sDAL:1234,5678,0,254,100,0,0

[0420] Where DAL is encoded into the CommandJD, the DALI command is 254 and the 100 is the DALI command parameter.

[0421] ii)

[0422] Since a number of DALI functions require the TX and RX of, potentially, hundreds of DALI commands to be issued within clear timing restraints (for example, in auto-addressing a DALI network), this precludes or severely limits, these operations wirelessly. Dexnet implements an abstraction layer (API).

[0423] e.g.

[0424] $sAUT:1234,5678,0,3,0,0,0 where the Commandjndex (3) specifies the auto-addressing options.

[0425] (this command may take up to 15 minutes to execute)

[0426] iii) Because there are numerous functions that require an API, Dexnet incorporates a further ‘higher’ level API abstraction level where the API call is identified by an integer value.

[0427] (e.g. an AUT command has an abstraction level number of ‘5’.)

[0428] The TRF (Task related function command)

[0429] $sTRF:1234,5678,0,5,0,0,0 has, effectively the same functionality as the above (ii) (again, this may take several minutes to execute)

[0430] All the above operations execute synchronously, which would potentially result in extended time delays when commissioning a complex installation.

[0431] In Dexnet, up to 32 task related functions (TRFs) can be instigated to be executed sequentially, asynchronously, only generating a completion event response when all tasks have been executed.P12681 PC01

[0432] iv) Example

[0433] Using RTC (Real time clock command)

[0434] $sRTC:1234,5678,0, 7, mask,0, 0,0 where mask is a 32 bit-wise value determining which task related functions are to be executed. (The 7’ in this example represents ‘do-now’).

[0435] To put this into context, because these functions can be ‘broadcast’ to multiple end-nodes, either by zones or groups, thousands of end-nodes can be set to self-configure or auto-test by the issuing of just one r.f. command.

[0436] Configuring a Wall Switch Plate

[0437] One product in the Dexnet / Dexcore system architecture is a wall switch plate, each having up to 16 push buttons.

[0438] The command structure enables the configuration of each button to transmit any (*) of the Dexnet Commands when pressed, held, toggled or released.

[0439] Consequently, these commands themselves are encoded into the parameter field of the configuration instruction.

[0440] e.g.

[0441] $sSWI:1234,5678, 0,n,£>yte array.0.0,0 where ‘n’ is the button to be configured and the byte_array is an encoded version of the Dexnet command to be executed.

[0442] n.b. (*) excludes string based parameters.

[0443] Although illustrative embodiments of the invention have been disclosed in detail herein, with reference to the accompanying drawings, it is understood that the invention is not limited to the precise embodiments shown and that various changes and modifications can be effected therein by one skilled in the art without departing from the scope of the invention.

Claims

P12681 PC01CLAIMS1. A control unit for an installation of a sensor and / or lighting control system comprising a plurality of control system node nodes, the control unit being configured to issue a functional command to a control system node supporting a network of devices to be controlled, wherein the functional command is such that the node will be required to issue multiple implementing commands to device(s) of the network to implement the functional command.

2. A control unit according to claim 1, wherein the functional command is directed to a specific device(s) of the network of devices.

3. A control unit according to claim 1 , wherein the functional command is directed to devices of the network of devices of a specific type.

4. A control unit according to claim 1 , wherein the functional command is directed to all devices of the network of devices by reference to the node.

5. A control unit according to any preceding claim, wherein the control unit is further configured to receive and recognise a combined response to the functional command from the control system node, the combined response containing information from multiple responses sent by device(s) of the network to the control system node.

6. A control unit according to any preceding claim, wherein the functional command is such that the node will be required to issue implementing commands to device(s) of the network at specific times to implement the functional command.

7. A control unit according to any preceding claim, wherein the functional command is such that the node will be required to issue implementing commands to device(s) of the network upon specific criteria being met to implement the functional command.

8. A control system node for an installation of a sensor and / or lighting control system, the node being configured to:support a network of devices to be controlled;receive and recognise a functional command from a control unit of the control system; implement the functional command by issuing multiple implementing commands to device(s) of the network.

9. A control system node according to claim 8, wherein the functional command is directed to a specific device or specific devices of the network of devices.

10. A control system node according to claim 8, wherein the functional command is directed to devices of the network of devices of a specific type.

11. A control system node according to claim 10, wherein the functional command is directed to all devices of the network of devices by reference to the node.

12. A control system node according to any of claims 8 to 11 , the node further being configured to:P12681 PC01receive and recognise multiple responses to the implementing commands sent from the device(s) of the network;issue a combined response to the functional command, the combined response containing information from the multiple responses sent.

13. A control system node according to any of claims 8 to 12, wherein the functional command is such that the node will be required to issue implementing commands to device(s) of the network at specific times to implement the functional command.

14. A control system node according to any of claims 8 to 13, wherein the functional command is such that the node will be required to issue implementing commands to device(s) of the network upon specific criteria being met to implement the functional command.

15. A control unit for an installation of a sensor and / or lighting control system comprising a plurality of nodes, the control unit being configured to issue commands to a node supporting a first protocol compliant network of first protocol devices, the command including:non-first protocol compliant addressing of the node; andfirst protocol compliant addressing of a first protocol device of the network.

16. A control unit according to claim 15 wherein the first protocol compliant addressing of a first protocol device is of a wired network of first protocol-2 devices attached to the node 17. A control unit according to claim 15 or 16 wherein the command to the node includes a payload containing:at least one first protocol compliant command to a first protocol device of the network of first protocol devices.

18. A control unit according to claim 15 or 16 wherein the command to the node includes a payload containing:a plurality of first protocol compliant commands to a first protocol device of the network of first protocol devices.

19. A control unit according to claim 15 or 16 wherein the command to the node includes a payload containing:a first protocol compliant command to a plurality of first protocol devices of the network of first protocol devices.

20. A control unit according to claim 19 wherein the command to the node includes a payload containing:a first protocol compliant command to be broadcast to all first protocol devices of the network of first protocol devices.

21. A control unit according to claim 15 or 16 wherein the command to the node includes payload containing:a plurality of first protocol compliant commands to a plurality of first protocol devices of the network of first protocol devices.P12681 PC0122. A control unit according to any of claims 15 to 21 wherein the first protocol is a DALI protocol.

23. A control system node for an installation of a sensor and / or lighting control system, the control system node being configured to receive and recognise a command from a control unit of the control system, wherein the node is configured to:support a first protocol compliant network of first protocol devices, andreceive and recognise a command from a control unit of the control system, the command including:non-first protocol compliant addressing of the node; andfirst protocol compliant addressing of a first protocol device of the network.

24. A control system node according to claim 23 wherein the first protocol compliant addressing of a first protocol device is of a wired network of first protocol-2 devices attached to the node25. A control system node according to claim 23 or 24 further configured to:receive and recognise a payload of the command to the node including at least one first protocol compliant command to a first protocol device of the network of first protocol devices, and instruct that first protocol device of the network of first protocol devices in accordance with a first protocol compliant command.

26. A control system node according to claim 23 or 24 further configured to:receive and recognise a payload of the command to the node including a plurality of first protocol compliant commands to a first protocol device of the network of first protocol devices, andinstruct that first protocol device of the network of first protocol devices in accordance with the corresponding first protocol compliant commands.

27. A control system node according to claim 23 or 24 further configured to:receive and recognise a payload of the command to the node including at least one first protocol compliant command to a plurality of first protocol devices of the network of first protocol devices, andinstruct those first protocol devices of the network of first protocol devices in accordance with the corresponding first protocol compliant command.

28. A control system node according to claim 23 or 24 further configured to:receive and recognise a payload of the command to the node including at least one first protocol compliant command to be broadcast to all first protocol devices of the network of first protocol devices, andinstruct by broadcast all first protocol devices of the network of first protocol devices in accordance with the corresponding first protocol compliant command.

29. A control system node according to claim 23 or 24 further configured to:P12681 PC01receive and recognise a payload of the command to the node including a plurality of first protocol compliant commands to a plurality of first protocol devices of the network of first protocol devices, andinstruct those first protocol devices of the network of first protocol devices in accordance with the corresponding first protocol compliant commands.

30. A control unit according to any of claims 23 to 39 wherein the first protocol is a DALI protocol.

31. A control unit for an installation of a sensor and / or lighting control system comprising a plurality of nodes, the control unit being configured to issue a compound command to a control system node supporting a network of devices to be controlled, wherein the compound command contains a payload comprising a plurality of individual commands for the node to transmit to device(s) of the network.

32. A control system node for an installation of a sensor and / or lighting control system, the control system node being configured to:receive and recognise a compound command from a control unit of the control system, wherein the compound command contains a payload comprising a plurality of individual commands for the node to transmit to device(s) of the network; andtransmit the plurality of individual commands for the node to device(s) of the network.

33. A control system node for an installation of a sensor and / or lighting control system, wherein the node is configured to:support a network of devices to be controlled, wherein each device has a unique address; andissue a command to a specific device(s) of the network by issuing the command to all devices of the network on the assumption that only the specific device(s) of the network will recognise and acknowledge the command.

34. A control system node according to claim 33, wherein the node is further configured to maintain a register of network devices.

35. A control system node according to claim 34, wherein the register of network devices includes an indication of device type.

36. A control system node according to claim 34, wherein the register of network devices includes an indication of recognised commands.

37. A control system node according to claim 33, wherein the node is further configured to:determine from the presence of unexpected acknowledgements in response to the command from device(s) from the network that the network of devices is non-compliant with a predetermined network configuration; andnotify a user of the determination.P12681 PC0138. A control system node according to any of claims 33 to 37 wherein the network of devices is a wired DALI network.

39. A control unit for an installation of a sensor and / or lighting control system comprising a plurality of nodes identified by node identifiers or identifiers of groups of nodes, the control unit being configured to:to issue a broadcast command to multiple nodes or multiple groups of nodes using a node identifier or identifier of a group of nodes which is not specific to a node or group but instead conveys the broadcast nature of the command.

40. A control system node for an installation of a sensor and / or lighting control system and identified by a node identifier or identifiers of groups of nodes with which the node is associated, the control system node being configured to:to receive and recognise a broadcast command from a control unit of the installation using a node identifier or identifier of a group of nodes which is not specific to a node or group but instead conveys the broadcast nature of the command.

41. A control unit for an installation of a sensor and / or lighting control system identified by an installation identifier, the control unit being configured to:receive and store the installation identifier,wherein the control unit is configured so as to not be able to export the installation identifier outside the installation including to a user of the control system or to a node unrelated to the control system.

42. A control unit according to claim 41 , wherein the control unit is further configured to:export the installation identifier to other nodes related to the installation including to switches, sensors and other control units of the installation and to commissioning tools for commissioning the installation.

43. A control system node for an installation of a sensor and / or lighting control system identified by an installation identifier, the control system node being configured to:receive and store the installation identifier,wherein the control system node is configured so as to not be able to export the installation identifier outside the installation including to a user of control system or to a node unrelated to the control system.

44. A control system node according to claim 43, wherein the control system node is further configured to:export the installation identifier to other nodes related to the installation including to switches, sensors and control units of the installation and to commissioning tools for commissioning the installation.

45. A control unit for an installation of a sensor and / or lighting control system comprising a plurality of nodes identified by zone identifiers indicating geographic zones of the installation, the control unit being configured to:P12681 PC01to issue a command to the same node using multiple zone identifiers.

46. A control system node for an installation of a sensor and / or lighting control system, the control system node being configured to:receive and recognise a command from a control unit of the control system using multiple zone identifiers of which the node is a part of.

Images