SYSTEMS AND METHODS FOR LOW POWER STATE MANAGEMENT

CROSS REFERENCE

[0001] This application is a non-provisional of US Application No. 63/395796, entitled “SYSTEMS AND METHODS FOR LOW POWER STATE MANAGEMENT”, filed 06-Aug-2022. The provisional application is incorporated herein by reference in its entirety.

[0002] This application is related to and incorporates by reference the following application in its entirety: PCT Application No. PCT/CA2019/050012, filed 04-Jan- 2019, entitled “TRANSPORT METHOD IN HIERARCHICAL DATA NETWORK”.

FIELD

[0003] Embodiments of the present disclosure relate to the field of power management, and more specifically, embodiments relate to systems and methods for low power state management for interconnected modular circuitry.

INTRODUCTION

[0004] Smart devices can be provided to control or provide various functionality, and can include modular circuit components which interoperate together to provide functionality such as temperature monitoring, home alarms, sensors, lighting, etc.

[0005] A challenge with smart devices is that the operating modes can consume significant amounts of electricity and power, and electricity and power are limited resources. It is desirable to provide an approach to reduce the amount of electrical resource consumption in respect of overall operation of electronic devices.

[0006] These low power management approaches can include provisioning state changes including wake and sleep states for the electronic devices. Low power management approaches need to be balanced against a need for responsive functionality from the electronic devices. [0007] Low power management is important to aid in improving overall operating efficiency and contributes to an overall reduced environmental footprint by aiding in conserving energy resources.

SUMMARY

[0008] Systems, methods, and computer readable media (storing computer program products) directed to managing low power mode on modular devices that are managed via a centralized controller are described herein. The controller controls the modular devices to enter low power modes and synchronizes the wake up when requested (e.g., by the user or other device through a computer controlled request data message or object). The modular devices and controller devices, in some embodiments, can be different physical devices (e.g., different hardware), while in other embodiments, can be similar devices having been assigned different roles (e.g., same hardware, interchangeable based on software configuration).

[0009] Low power modes are useful and power savings are also useful in promoting energy efficiency electronic devices that are coupled together, such as light panels, cameras, home temperature control, etc. Controlling any of these types of devices are contemplated in this application. While an objective is to achieve power savings, there are several technical challenges as described herein relating to wake up latency and managing data communications between modular devices due to low power mode clock errors that can have significant errors (e.g., +/- 40%). Power management is an important and practical application of the proposed approaches and provides a useful practical implementation in an attempt to achieve a technical objective having regard to practical trade-offs between competing technical priorities.

[0010] Conserving energy is an important consideration in reducing overall burden on limited electrical resources, especially for larger implementations or more powerdemanding applications. Energy conservation can aid with the reduction or reliance on non-renewable energy sources and aid in the adoption of green I clean technology. A cumulative power savings across a large number of installations could help contribute to the reduction of overall reliance on green-house gas emitting I climate stressing energy source. This is particularly important when the modular devices relate to approaches for intelligent control of devices to save energy (e.g., smart lighting, smart thermostats, smart sensors) during particular times of day or peak energy usage periods.

[0011 ] These low power mode clock errors exist due to technical limitations around the devices that arise due to the need for inexpensive electronic components, a need for flexible consumer deployment that may not lend itself well to time-consuming and resource consuming synchronization steps, among others. On the other hand, it is important to address these clock errors and latency as it is desired to be able to have a reasonable level and/or speed of communications so that the electronic devices are able to operate in concert with some level of synchronicity.

[0012] An approach for managing low power states of modular electronic devices that are interconnected to one another is described in various embodiments herein, along with corresponding systems, methods, and computer program products provided in the form of non-transitory computer readable media storing machine interpretable instruction sets for execution by a processor.

[0013] In particular, the approach implements a number of control steps that are utilized to control operation of the modular electronic devices in respect of low-power state “sleep” states and wake states, the control steps adapted to minimize latency associated with waking the modular electronic devices to reduce a perceived latency that may impede a user experience associated with the modular electronic devices.

[0014] A number of variant approaches are described herein, including (1) an approach for a system wake by a controller device, (2) an approach for a system wake by module device, and (3) an approach for a path wake by module device. The approaches, for example, can include recursive steps where the system or parts of the system progressively wake in each scenario. [0015] In these steps, the modules (modular devices or modular electronic devices, e.g., lighting panels) communicate with one another, for example, through connections that are designated as “root” I “parent”, and “child”, and the communications propagate accordingly. Recursive steps are useful in situations where the arrangement, number of modules, or the geospatial relationship is not known or subject to change.

[0016] The modular electronic devices can be coupled to one another through the usage of linking elements, which may be physical or virtual for the sharing of power and/or data (e.g., signals transmission) capability. The sharing of power and data can be conducted across the same (e.g., an AC signal coupled over a DC power transmission) or on separate circuitry (e.g., separate power and data lines).

[0017] Each of the modular electronic devices can include one or more (or a plurality of) linking sections where a modular electronic device can be linked with another modular electronic device. For example, there could be 2, 3, 4, 5, 6, ... N linking sections for a particular modular electronic device to link to others, and furthermore, there may be one or more specific controller devices which operate to provide a coordinated power transfer or signal control point to/from which the modular electronic devices are subordinate to. The controller device could be the first point in which there is a coupling to a power source, such as a wall outlet.

[0018] When the modular electronic devices are coupled together, in some cases, the specific physical or geometric arrangement I layout of the modular electronic devices may be periodically modifiable or “hot swappable” by a user such that the specific physical or geometric arrangement I layout is modifiable and thus not known a priori by the system. A layout detection approach may be utilized to traverse the physical or geometric arrangement I layout to, store in a data structure, a representation of the linkage connections as between modular electronic devices (e.g., Device1 Edge1 is coupled to Device2Edge1), and so forth. [0019] In the variant approach directed to a system that is awoken by controller, a flow of a normal sleep mechanism is both initiated and interrupted by the controller device, whereby the controller device “wakes” children modular electronic devices coupled to it, and then the modular electronic devices progressively awaken their children. Upon all of the modular electronic devices being awoken, the controller can then initiate various functioning of the system, such as communicating a modular electronic device assembly-wide effect to be generated, etc.

[0020] In the variant approach directed to a system that is awoken by a modular electronic device (e.g., initiated through a specific modular electronic device receiving a touch input a user or motion sensor data by a user), for example, the module with data communicates to wake all of its neighboring modular electronic devices, and then a progressive waking approach can be utilized. When a path to the controller device is established, data relating to the modular electronic device that initiated the wake protocol can be obtained by the controller, and modular electronic devices can continue to be woken through various neighboring connections. Upon all of the modular electronic devices being awoken, the controller can then initiate various functioning of the system, such as communicating a modular electronic device assembly-wide effect to be generated, etc.

[0021] In the variant approach directed to a path awakening by a modular electronic device, the modular electronic device may be interacted with, and then begin waking neighboring modular electronic devices until a path to the controller device is established. When the path to the controller is established, a signal to stop waking neighbors can be optionally propagated to avoid unnecessarily awakening modular electronic devices, and the controller can conduct various functions associated with the specific initiating modular electronic device (e.g., clearing an error condition, updating firmware), etc. The controller device can also return various woken modules to sleep by propagating a sleep signal when the function is completed.

[0022] The approach is useful in respect of various types of electronic devices. [0023] In a first example, the electronic devices can include interconnected lighting panels having edges that can be coupled together to provide a lighting assembly where individual lighting modules that are luminaires constituting the modular electronic devices can be re-arranged and reconnected, for example, to create flexible and modular lighting structures. In some embodiments, each of the lighting modules may have various sensors on-board that allow them to be interacted with at various times, for example, having motion sensors to identify proximate movement, light sensors to calibrate for a time of day, touch sensors to detect touch inputs, or on-board buttons or switches. Power management states can be utilized so that the even while the lighting assembly is in various sleeping modes to save energy, the lighting assembly can be awoken in a reasonable amount of time when one of the lighting panels is interacted with by a user.

[0024] In a second example, the electronic devices can include temperature sensors that are coupled together across a set of rooms in a home or an office. The temperature sensors can be placed in each room or a portion of each room, and can have a plurality of edge interconnections for coupling to other temperature sensors. Power management states can be utilized so that the even while the temperature sensor assembly is in various sleeping modes to save energy, the temperature sensor assembly can be awoken in a reasonable amount of time when one of the temperature sensors detects a change in temperature beyond a triggering threshold, for example.

[0025] In the example approach, the devices are utilized to establish power conservation states of the modular system to control the modular devices that are coupled either with one another, or with a central controller device. Because the system of some embodiments can be hot-swappable or modified, a challenge is that the controller and/or devices cannot pre-determine the number of modular elements that form the whole of the system, nor how they are connected - they are only able to observe their neighbors through their corresponding edge communication interfaces. [0026] This is especially challenging when establishing time-based power conservation states which can be woken from in a reasonable period of time (e.g., when a user interacts with one of the modular devices or the controller), and this is further compounded as noted below when the timing circuitry is not synchronized and/or not sufficiently accurate (e.g., to keep manufacturing costs reasonable for consumer electronics, or to use lower latency I lower power consumption chipsets). For example, each of the modular devices and/or the controller may have onboard timing functionality on the circuitry, but these might have experienced drift relative to one another since manufacturing and/or were never initially synchronized.

[0027] Accordingly, when the modular devices enter into the power conservation states, they wake periodically in an asynchronous manner and “check” whether their edge communication devices and/or coupled message or data buffers include an unprocessed wake message, which they can then process to transition into a fully woken state and/or discard if already awake. As each of the modular devices is able to poll and/or otherwise interrogate their coupled edge communication devices and coupled ports or buffers, this can be used to respond to various poll messages from a controller such that a modular device that is awake can respond with whether all of the outstanding wake messages to its neighbors have been processed or not.

[0028] The controller can periodically propagate a poll message that radiates outwards requesting communication responses from awakened modular devices. The awakened modular devices can respond with message fields indicating the status of each of their edge communication device ports and/or a message field indicating that they themselves are on, along with any other information (e.g., operational state information, such as the specific brightness I color output, a temperature reading, whether there has been a touch input to be processed), among others. For example, the other information provided can then be utilized for other functionality, such as initiating a visual effect to be propagated across lighting panels by controlling their lighting output, etc. , or for a home thermometer system, a desired change in humidity or temperature settings. [0029] For the system wake examples, if there are outstanding wake messages, then the entirety of the system is not in the wake state and the controller can continue to poll or wait until all devices are opened. When the system wake is complete, the system can save, cache or identify the existing spatial relationship (e.g., edge hops based on pre-identified edges) based on the poll response messages, which can then be useful for more targeted communications to a specific modular device if the spatial orientation has not been changed. Even if the spatial orientation has been changed, the saved existing spatial relationship can still be useful as a first approximation for a path for attempting point to point messaging (e.g. , attempt across this path first, and then variations based on branches I tree nodes, and failing that, broadcasting a new poll to obtain responses to rebuild the spatial relationship).

[0030] For the path wake example, the controller can propagate the poll to check if a device flagged as the path wake initiator is awake, and if it receives that indication (potentially along with other initiator characteristics), it can establish a communication path directly with that device and stop the propagation of wake messages and/or stop polling messages. The path wake mechanism can be used for localized effects or functionality, or for maintenance activities, such as pushing out firmware updates or requesting debugging information for a faulting modular device. When the path wake is complete, a spatial orientation can similarly be established as a potential path to the initiating modular device. While the path may not always be the shortest or most efficient, it nonetheless represents a path that has worked previously. The path wake mechanism may be used in cases where a module wants to send information to the controller by disturbing or waking the least number of other modules. An example use case, as mentioned, may be a firmware upgrade or update, where data flow might be from the controller to the individual module.

[0031] Variant embodiments are also contemplated with accurate (but unsynchronized) clocks, and the approaches described herein can be utilized to instead include as part of the data fields, synchronization information to re- synchronize clocks during wake periods (or set of wake periods), in order to minimize latency and improve power savings. This can be used, for example to address clock drift and other challenges relating to practical limitations of clock mechanisms, as even subtle variations in manufacturing, gravity, or relativistic effects cause clocks to eventually be unsynchronized with respect to one another. Clock synchronization is particularly important when the modular devices are being used for time sensitive functionality, such as home I premises recording devices (e.g., time stamps).

[0032] Coupling as described in this application between ports is not necessarily a physical electrical connection. While physical electrical connection devices are contemplated, such as a luminaire that is a system of modular devices that are interconnected together using interconnection linkers, etc., it is not the only implementation that is possible.

[0033] For example, coupling could occur in the context of a mesh-based network, where devices have medium or low-range communications capability and can “see” various neighbors, and the modular devices include wireless communications transceivers. For example, the devices could be coupled as communications enabled lighting, communications enabled cameras, thermostats, alarms, that cover a larger area, such as across an office, an apartment building complex, among others. Mesh networking can be electromagnetic coupling, and coupling could also occur in the context of communication from a vertex or otherwise arbitrary location along a surface of a module.

[0034] The proposed power conservation approaches and wake approaches described herein are useful to help conserve limited electrical and/or communications resources for a variety of smart device implementations.

[0035] Variations and different combinations and permutations of some or all of the above approaches are contemplated. Practical testing has been conducted against some embodiments using a large layout test, with results indicative of improved power savings. DESCRIPTION OF THE FIGURES

[0036] In the figures, embodiments are illustrated by way of example. It is to be expressly understood that the description and figures are only for the purpose of illustration and as an aid to understanding.

[0037] Embodiments will now be described, by way of example only, with reference to the attached figures, wherein in the figures:

[0038] FIG. 1 is a schematic diagram showing an example modular lighting system, according to some embodiments.

[0039] FIG. 2 is a block diagram showing a workflow for waking a system by its controller, according to some embodiments.

[0040] FIG. 3 is a flowchart of a process for waking a system by its controller, according to some embodiments.

[0041] FIG. 4 is a block diagram showing a workflow for waking a system by a module, according to some embodiments.

[0042] FIG. 5 is a flowchart of a process for waking a system by a module, according to some embodiments.

[0043] FIG. 6 is a block diagram showing a workflow for waking a module path, according to some embodiments.

[0044] FIG. 7 is a flowchart of a process for waking a module path, according to some embodiments.

[0045] FIG. 8 is a schematic diagram showing an example lighting module, according to some embodiments.

[0046] FIG. 9 is a flowchart of a process for waking a module by controller using low energy (LE) sleep timer, according to some embodiments. [0047] FIG. 10 is a flowchart of a process for waking a module by controller using interrupt, according to some embodiments.

[0048] FIG. 11 is a flowchart of a process illustrating low power mode control, according to some embodiments.

DETAILED DESCRIPTION

[0049] Systems, methods, and computer readable media (storing computer program products) directed to managing low power mode on modular devices that are managed via a centralized controller are described herein. The controller controls the modular devices to enter low power modes and synchronizes the wake up when requested (e.g., by the user or other device through a computer controlled request data message or object).

[0050] Described herein are embodiments of a modular electronic system that can include various variations of different electronic modular devices (e.g., modules, lighting panels) adapted for different functionality. In the examples described herein, a lighting system with a controller unit and various lighting modules is used as an example, but other variations are possible and contemplated. Other different types of modular devices that are contemplated for use include coordinated cameras, sensors, light switches, thermostats, among others, where the different devices interoperate together through data communications. The examples relating to lighting system apply mutadis mutanis to the other variations. The term “module” in this application refers to physical electronic devices that are designed for modular interconnection I coupling (not necessarily directly connected).

[0051] For example, there can be sensors, thermostats, cameras, etc., that are coupled together wirelessly over a near distance communications protocol such as Zigbee™ , Bluetooth™. In a further variation, the modules can be connected using local or wide area network protocols, such as modular devices that are connected over TCP/IP connections, UDP connections, datagrams, etc. As described herein, some of the challenges with consumer electronic type modular electronics are technical limitations that arise in respect of the types of microprocessors and/or electronic components available for usage. These components can have specific technical challenges associated with latency and clock accuracy (e.g., clock drift), and these complicate approaches for power savings I state management.

[0052] In some embodiments, a controller unit is used to coordinate operation (e.g., the lighting state) of the various modules (e.g., lighting modules) which may constitute a modular system I arrangement (e.g., lighting system). The modular system I arrangement may have a specific geometric arrangement that is established through the positioning and/or orientation of the different modules in Cartesian I Euclidean space. For the lighting example, when the lighting output of the system is turned off by the user, the respective lighting modules may, in some embodiments, be able to go into a low power state such that they can conserve the energy. The approaches proposed herein are adapted to provide practical solutions to control state management of different devices using different approaches to handle wake I sleep commands.

[0053] Other types of commands can be provided in combination with the wake I sleep commands, and the commands can be provided in the form of machine instruction sets, such as commands sent in the form of analog device signals (e.g., voltage up I voltage down relative to neutral), or digital signals (e.g., sending data packets having specific fields and payloads, such as those encapsulated in XML or JSON messaging formats).

[0054] A technical challenge, to which the described embodiments present a solution, is while in such a low power state, the modules may need to be woken with minimal latency perceived by the user and they should be able to continue time- critical communication functions with minimal impact to communication latency. There is a trade-off between latency and energy savings (e.g., time panels need to be awake to make sure they catch a wake message before going back to sleep). [0055] While there are scenarios contemplated where device clocks are accurate, this challenge is further compounded in other example scenarios where low-cost devices and low-power devices are coupled with inaccurate device clocks, inaccurate such that a wake interval cannot be precisely scheduled, for example. With accurate clocks, one can simply tighten the tolerances for sleep/wake duty cycles and attain adequate power savings with even shorter latency, but however, these approaches would not be available with inaccurate device clocks. Clock drift occurs as each of the clocks start to “drift” apart from one another and become desynchronized over time. This is a practical problem as processor clocks start to drift and thus not run at the same rate as a reference clock (until resynchronized). Accordingly, until a re-synchronization, the desynchronization may cause the time difference to diverge over time. A problem with consumer electronics is that it is not always possible to enforce a re-synchronization or expect individual users to have the technical skills to successfully conduct a re-synchronization. This is further compounded with lower cost electronic devices, which are even more susceptible to clock drift.

[0056] An example maximum latency of 0.5 s is derived from energy standards minimums (e.g., turn on time for lightbulbs), and in certain cases, an 100 ms maximum overall system response could be even more preferred, and as described in various embodiments herein, the controller device can be configured to controlled to periodically poll the assembly (e.g., roughly every 25 ms or 50 ms).

[0057] Given an effectively random wake time that is implied by the inaccurate clocks, the approach described herein can include adapting modules to be awake for at least 2 periods to ensure that the model is able to receive and process the wake signal from a neighbor.

[0058] This caps energy savings at 90% for a 500 ms response time (50/500 ms).

For a 100 ms response time, this drops to 50% (50 ms/100 ms). [0059] In a variant embodiment with accurate clocks, the approach could include a different process to re-synchronize clocks every wake period (or set of wake periods), in order to minimize latency and power savings.

[0060] Applicants have tested a number of different iterations of demonstrative approaches to assess the technical viability of various solutions.

[0061] A first iterative approach utilized panel low energy timer (LE timer) to place the processor into a timed low power mode. In this approach, the controller would broadcast a message to the panels to sleep for a specified amount of time and then once the panels woke up it would check for user interaction and put them back to sleep if no user interaction is detected. This method had reasonable performance, however, due to the inaccuracies in the clock, the wake up period was large, and required the controller to wait until panels were awake before being able to react to user interaction. This resulted in a high latency before the panels could react to the user’s interaction. If we attempted to reduce the latency the panels wouldn't be in low power mode for a very small amount of time in the sleep-wake period. The second issue was the inaccuracy of the LE timer which resulted in a max low power mode time of no more than 70%, leading to theoretical savings of no more than 30%.

[0062] In a second iteration, Applicants changes the configuration of the approach and removed the dependency of the panels on the LE timer and modified the panel wake mechanism to be based on GPIO interrupts from serial messages received on the root edge. The root edge is the receiving edge of the panel which the panel is listening on for a message from the parent. The controller now would put the panel to sleep, and wait for a wake up message from the panels based on user interaction or send a wake up message to the panel when the user requested the panels to display colour. The controller still needed to a refresh every few seconds, to ensure that no layout changes had occurred. This was done using existing methods which resulted in the panels being in active mode for time in the order of seconds, which once again capped the low power mode timer to 80% in the implementation of this second iteration. [0063] In a third iteration, an internal request queue for the various software modules which was done specifically during a ‘refresh’ wake period. This was accomplished using a small number of couple messages and took in the order of few ms. This restricted the panels to be awake for a very short period of time, such as less than 10ms. This allowed the power savings to reach as high as 95% in testing. This approach is described in more detail in the below embodiments.

[0064] FIG. 1 is a schematic diagram showing an example modular lighting system, according to some embodiments.

[0065] Shown in FIG. 1, is a power source 100 providing input power which feeds into a controller, through to eight lighting modules, 102, 104, 106, 108, 110, 112, 114, and 116.

[0066] In some embodiments, lighting modules 102 - 116 may draw 0.18 W of power from power source 100 in a standby mode, and may draw 0.0165 W in a low power state. Lighting modules 102 - 116 may provide minimal latency, which may, in some embodiments, provide response times of 500 ms or less.

[0067] Previous polling approaches to modular lighting often sacrifice latency for reduced power consumption. This may be harmful to user experience, should, for example, a user tap a light providing a touch input and then due to high latency, be unaware whether or not their input was detected. Described embodiments propose solutions to this problem.

[0068] Other technical challenges are present with inaccurate device clocks. For instance, in some embodiments, the clocks on a system on a chip (SoC) of a lighting module may have a documented margin of error of 40%. Embodiments and approaches described may be clock time agnostic, since the controller awaits for all modules, such as lighting modules 102 - 116, to wake up and has methods to verify if all modules have woken up or not. [0069] Ideally, if wake intervals were precisely scheduled, then modules could be put to sleep, and there could be high confidence in when the modules will wake up to interrupt the sleep when, for example, a user interaction wakes the layout. The described GPIO interrupt method embodiments, for example, do not require this precise scheduling to function appropriately. It does not necessarily need to be a user interaction, but this can also include various interactions or triggered conditions, such as the modules being woken up by when a specific module identifies a leak condition (e.g., water sensor), a camera detections motion, an error condition occurs (e.g., over-voltage, over-temperature detected).

[0070] Touch inputs from a user are one example of time-critical communication functions which may require low latency. Other examples of time-critical communications may include module touch data, motion sensor data, button presses, and/or other sensor data, among others.

[0071] The layout of the individual lighting modules 102 - 116 may have an impact on communication time. For example, if lighting modules 102 - 116 were arranged in a long 1-D line, the communication time would be the time of propagation multiplied by the number of lighting modules in the chain. For instance, with lighting modules 102 - 116, if they were re-arranged into a long 1-D chain with eight modules, then the communication time from one end to the controller at the other end may be Tprop*8.

[0072] As shown in FIG. 1, the lighting modules 102 - 116 and controller may have a certain layout, and this layout may be mapped according to the connections between the each of the individual modules. For example, the controller connected to module 102, which is connected to both modules 104 and 106, and these two way connections continue and propagate through to the others creating a loop connecting all modules back to the controller. In some embodiments, there may be various different paths from each module to and from the controller. [0073] FIG. 2 is a block diagram showing a workflow 200 for waking a system by its controller, according to some embodiments. In workflow 200, the flow of the normal sleep mechanism that is both initiated and interrupted by the controller is described, according to some embodiments, below. The process described below should be understood as exemplary only.

[0074] At 202, the controller sends out a message using a layout detection protocol to instruct all the lighting modules to go to sleep for a defined period of time. A sleep instruction message can include a coded data message that is sent from the controller communication interface and transmitted to each of the modules. The modules transmission can be propagated through each through device to device interconnections. In some embodiments, the controller can identify a path to each module and send individualized messages. In other embodiments, the controller can simply broadcast a sleep message that is broadcast across all modules to instruct them all to enter the sleep state. The sleep state can be handled through a finite state machine residing on state registers or state memory residing on each module. The sleep state can be set for a defined period of time.

[0075] In some embodiments, the layout detection protocol may be transport methods for hierarchical data networks. Such a protocol may provide methods to transport data providing “address-less data transport” using various approaches to implementation using hardware, software, embedded firmware, circuitry, and/or combinations thereof. An order may be introduced or associated with the nodes to establish relationships, and the order may be stored in the form of a tree topology in a data structure, for example. The order of nodes is thus known, and logic and/or other data sets, data payloads, etc., may be transmitted across the nodes. The transmitting of the content provides for an improved data transport across a topology, for example, such as traversal across a tree topology of address-less nodes.

[0076] In some embodiments, the layout detection protocol may provide a method for transporting data arrays in a data network with multiple nodes, and with connections between nodes. Each node may include multiple network interfaces through which data arrays can be sent and received, and the connections between nodes of the plurality of nodes may be formed through pairwise joining of a plurality of network interfaces of the nodes, such that the network topology of the connections is a tree topology, for example.

[0077] The method for transporting data (the “communications protocol”) may, in some embodiments, include: assigning a first order (e.g. a first ordinal relation) to the network interfaces for all the nodes; determining a second order (e.g. a second ordinal relation) for the nodes as a function of a network topology and the first order, for the network interfaces; and generating a first composite data array by a concatenation of a multiple data arrays, such that a first and a second data array in the first composite data array are in an equivalent order to each other as a corresponding pair of nodes in the second order.

[0078] The orders may be in relation to the network interfaces of any given node are in. That means, the first order makes statements such as: “select the first network interface” or “select the next network interface” unambiguous and for any specific data network installation persistent. This may be an important consideration for connecting address-less nodes, especially for modular electronics having multiple connectable interfaces where it is not known ahead of time which connections will connect with which, and in what order (e.g. a user is assembling a geometric shape using modular LED panels and would like to be able to conveniently connect them without regard to matching specific panel interfaces or establishing and communicating the shape to a central controller). The second order is similarly an order of the nodes of any given data network. One important consideration is to derive or determine the second order. That may be done on basis of two other properties of the data network: the precise tree topology of the data network, as well as the first order for the nodes comprising the data network. With the second order in place, the transport of the composite data array method exploits the determined second order for efficient transport. [0079] The content of a first composite data array may be transmitted throughout the data network, such that each node can receive from at least one other node connected through a first network interface, a first contiguous sequence of the first composite data array, and such that each node may send to other nodes connected to it through a second network interface, a second contiguous sequence of the first composite data array, wherein the second contiguous sequence may be constructed from the first contiguous sequence as a function of the first and second order.

[0080] A first contiguous sequence of the composite data array may be created. The significance of the word “contiguous” is that (1) the sequence is ordered and (2) that it overlaps with one stretch of the content of the first composite data array. The first contiguous sequence can therefore be obtained by simply defining one lower bound and one upper bound to be applied to the content of the first composite data array.

[0081] This process can continue recursively, according to some embodiments. A second contiguous sequence may, in some embodiments, be constructed from the first contiguous sequence by applying the same type of minimal set operations, which will, in effect, decompose the first composite data array (or the ordered content comprising the first composite data array, if that is a preferable way to formulate it), into contiguous sequences.

[0082] In addition, these contiguous sequences may be for one given node, overlapping or non-overlapping. In other words, any single unit of content of the first composite data array that has been received through a first network interface of a given node, defined as a unit of content Q, will only be sent through at most one other network interface of the same given node, in some embodiments. It is possible it is sent through no network interface, since this unit of content can be intended to be consumed by the one given node.

[0083] At 204, the modules proceed to sleep for the period of time defined at 202. The modules may have networking interfaces residing, for example, on different edges of each module for interconnection. These receive the sleep message payload, and process it to enter into a state transition for a sleep, for the defined period of time, either a default amount of time pre-defined on the system, or a specific sleep duration field from the sleep message payload.

[0084] At 206, the modules individually wake for a second period of time, waiting to receive a message on their root side from their parent I root module. Should the modules not receive the message within the second period of time, they may resume sleep. In some embodiments, if there is a plurality of available connections (e.g., on each edge) of the modular device, either all of the connections can be used to await a message, or in a more specific embodiment, only the connections on a “root side” designated as the connection which the path to the controller is designated is woken. The approach to check only the root side can yield more cost I power savings, but has less redundancy in the event of a failure of the root side interface.

[0085] At 208, when the system of modules needs to be woken, the controller wakes its children (e.g., modules that are proximate from a connection perspective). In some embodiments, this may be done using a serialized message (e.g., root detect). In other embodiments, this may be done using a general purpose input I output (GPIO) interrupt. The modules may progressively wake their children moving out the tree. Children may be woken by the controller at 208 during the second period of time at 206.

[0086] At 210, the controller may periodically check the lighting module system to see if all modules are awake, as expected, using a layout detection protocol approach. This can be done by propagating various detection messages to effectively poll each module to see if it has woken up yet (e.g., identifying their specific states). The responses from each poll as returned to the controller can be compared, for example, to an expected desired response to check to see if all modules have been woken. For example, this can be compared against a full list of available modules. [0087] The controller may then resume normal functions of the system. These functions can include, for example, the rendering of geometric lighting effects on each or some of the modules, running smart thermostat functions (e.g., maintaining a desired temperature or humidity), turning on cameras, etc.

[0088] The workflow 200 for waking a system initiated by its controller according to one embodiment may follow such a process outlined above, but may in other embodiments include more or less steps, and may be performed in various orders.

[0089] Workflow 200 may be initiated, for example, when the modules are turned off by a user and the modules are not required to supply any output. The time period defined at 202 may be the period of time for the modules to sleep, and be completely unresponsive. For the wake up latency to be minimum, the system requires the modules to wake up after a defined time which may be 500 ms or less, and check for messages from the controller, other modules on their side and/or using a GPIO interrupt.

[0090] In some embodiments, at 206, the modules individually wake for a second period of time, waiting to receive a message on their root side from their parent I root module using a very low energy clock available on the hardware to track time for how to sleep. The modules may be woken up by a low energy (LE) timer, and the modules may be configured to check for interruptions to the sleep. These messages, for example, can be stored on buffers on the root side. Detection can include interrogation of the buffer memory registers. In another variation, the messages can only be processed when the module is awakened (e.g., there can be variations without buffers for messaging).

[0091 ] If they detect nothing, the modules may return to sleep for the period of time defined in 202. Due to the low accuracy of a LE timer, for example, the modules may wake up in a staggered manner. A staggered wake can include the controller initiating the wake by sending out the wake message, and individual modules waking up and then waking its children gradually as they wake periodically. Because the timing may not be particularly synchronized as between the individual modules, they may be waking up in waves.

[0092] The individual waking of the modules at 206 may be adapted to check for messages from other modules or the controller. Since messages cannot be received in the sleep state, modules may need to periodically wake up to check. If interrupted via GPIO, for example, this checking may not needed.

[0093] FIG. 3 is a flowchart 300 of a process for waking a system by its controller, according to some embodiments. In some embodiments, the process shown in flowchart 300 may follow similar steps to those described in workflow 200.

[0094] For example, consider a situation where modules 102 - 116 are turned off by a user and the modules are not required to supply any output. Since messages cannot be received in the sleep state, modules 102 - 116 need to periodically wake up to check.

[0095] In such a situation, the controller may interrupt and initiate a system wide wake up. The controller may be sending out a message using a layout detection protocol instructing modules 102 - 116 to sleep for a defined period of time. For the wake up latency to be minimum, the system may require modules 102 - 116 to wake up after a defined time which may be 500 ms or less, and check for messages from the controller, other modules on their side and/or using a GPIO interrupt.

[0096] Modules 102 - 116 may wake individually for a second period of time to check if they have received a message on their root side from their parent I root module. If the individual module of modules 102 - 116 does not receive a message during this second period of time, the individual module will resume sleeping. In some embodiments, the modules may wake up on expiration of a timer. Differences in the timer’s base frequency may lead to variation in when the modules wake up from sleep mode, for example. [0097] Once the system of modules needs to be woken, the controller can wake its children by, for example, sending a serialized message or using a GPIO interrupt. Beginning from the controller, the modules 102 - 116 may progressively wake their children as the children modules move out the tree.

[0098] For example, a user may input a desire for all the module lights to turn on, so the controller may send a serialized message to module 102. Module 102 would wake modules 104 and 106. Module 106 would then wake modules 108 and 110. This message sending would continue to propagate through the tree until all of the modules 102 - 116 were awake, which may be confirmed by the controller periodically checking the system to ensure all modules were awake.

[0099] FIG. 4 is a block diagram showing a workflow 400 for waking a system by a module, according to some embodiments. In workflow 400, modules in the system may periodically have real-time information relevant to the controller that is time sensitive (e.g., module touch data, motion sensor data, button presses, and/or other sensor data, among others). It can be beneficial to wake the entire system when this data needs to be transmitted, as it may have relevance to the entire system.

[00100] A practical example of a waking the from a module can include a lighting module that is being touched by a user. The lighting module has a touch sensor that when the user touches it, it is designed to wake up either a path to the controller, or the entire lighting system and render a geometric lighting effect, for example, starting from the specific module that was touched and radiating outwards. A challenge with such a system to process this touch input is that when the modules are asleep (e.g., to save power instead of constantly having all of the individual modules awake), the touched module now has to wake the entire system. There are some countervailing technical trade-off considerations in the waking of the system: it is important to be fast enough for the user to feel that the system is responsive, but it is also important to reduce power usage during sleep periods. [00101] Another use case for wake from module can include a user desiring to initiate a system update without having to interact with the main controller first. In this example, the user can connect to a single module, provide the update instructions (e.g., firmware update, BIOS update), and that single module can then begin the wake process and either transmit the instructions to the controller for the controller to propagate out. Another variation can include the update instructions being propagated by way of the wake messages as a piggy backed payload.

[00102] The workflow 400, of the normal sleep mechanism that is first initiated by the controller and later interrupted by any module in the system is described, according to some embodiments, below. The process described below should be understood as exemplary only. The interruption is the approach to waken the system as initiated by a module (as opposed to the controller).

[00103] At 402, the controller sends out a message using a layout detection protocol to instruct all the lighting modules to go to sleep for a defined period of time.

[00104] At 404, the modules proceed to sleep for the period of time defined at 402.

[00105] At 406, the modules individually wake for a second period of time, waiting to receive a message on any side. Should the modules not receive the message within the second period of time, they may resume sleep. As noted above, these can be messages that are stored either in buffers (if buffer memory is available), or received in real-time to be processed. In FIG. 2, in a variation, only the root side needed to wake periodically. Unlike that variation of FIG. 2, these messages can be configured to be received at any of the plurality of interfaces (e.g., each interface corresponding to a side) because there cannot be a presumption of which interface the message is received from.

[00106] At 408, when the system of modules needs to be woken, the module with the data to be communicated may wake up all of its neighbors. In some embodiments, this may be done using a serialized message (e.g., root detect). In other embodiments, this may be done using a GPIO interrupt. The modules may progressively wake their neighbors moving out the tree. Neighbors may be woken by the controller at 408 during the second period of time at 406.

[00107] At 410, the controller may periodically check the lighting module system to see if all modules are awake, as expected, using a layout detection protocol approach (the “pixel” approach), as described above, for example.

[00108] At 412, once the modules at least along the shortest path from the module performing the wake back to the controller are awake, the data may be queried successfully by the controller. In some embodiments, step 412 may be skipped, and the controller may resume functionality once all panels have been woken up. The controller, once aware of the fact that the system is in the process of being awoken (e.g., a short path has indicated that a wake command was initiated by a module) can start tracking the progress of the wake through polling the system.

[00109] At 414, the controller may continue to periodically check the system to see if all modules are awake, as expected, using various layout detection protocol methods, such as those described in the related patent application.

[00110] The controller may then resume normal functions of the system. For example, the system begins asleep. The user touches a non-controller module to initiate a geometric lighting effect. The workflow 400 is initiated and the system eventually wakes up all of the modules. While, from a computational perspective, the system may take a number of cycles to full awaken before the geometric lighting effect can be implemented, from a human perspective, it may be an acceptable or non-noticeable level of delay. The longer the sleep duration is relative to the second period of time for individual module wake, the greater the power savings at a tradeoff of system responsiveness. However, even if the second duration is relatively small, depending on the frequency of which it occurs, there may be significant power savings. [00111] The periodic check can include periodically polling or sending messages to each module and comparing against a list of all available modules. Once all available modules are awake or a timeout period has elapsed, for example, the controller can designate the entire system as being awake and begin normal functionality, such as the rendering of a geometric lighting effect, temperature control, camera operation, etc.

[00112] The workflow 400 for waking a system by a module according to one embodiment may follow such a process outlined above, but may in other embodiments include more or less steps, and may be performed in various orders.

[00113] Time sensitive information may be understood to be information within 100s of ms, but under 500 ms, for example.

[00114] According to some embodiment in workflow 400, the controller may continue to poll the system, broadcasting messages across all awake modules until it reaches the wake initiator module. The controller may wait until it receives messages from all the modules in the system layout, and the controller keeps track of the modules connected in the system layout.

[00115] In some embodiments, it does not matter which module woke the other modules up. So long as the controller knows that the modules have woken up due to an interaction with some other module, the controller may use a layout detection protocol methods to query the layout and retrieve the interaction information.

[00116] FIG. 5 is a flowchart 500 of a process for waking a system by a module, according to some embodiments. In some embodiments, the process shown in flowchart 500 may follow similar steps to those described in workflow 400.

[00117] For example, consider a situation where module 116 in the system receives real-time information relevant to the controller that is time sensitive (e.g., button presses). It can be beneficial to wake the entire system when this data needs to be transmitted, as it may have relevance to the entire system. [00118] The controller may be sending out a message using a layout detection protocol instructing modules 102 - 116 to sleep for a defined period of time. For the wake up latency to be minimum, the system requires modules 102 - 116 to wake up after a defined time which may be 500 ms or less, and check for messages from the controller, other modules on their side and/or using a GPIO interrupt.

[00119] Modules 102 - 116 may wake individually for a second period of time to check if they have received a message from any side (e.g., a message being received at a network interface on each side). If the individual module of modules 102 - 116 does not receive a message during this second period of time, the individual module may resume sleeping.

[00120] Once the system of modules needs to be woken due to the time sensitive input being received by a module, in this case module 116 which receives an input during one of the second waiting periods, said module with the data will wake its neighbors by, for example, sending a serialized message or using a GPIO interrupt. Beginning from the module with the data to be communicated, the modules 102 - 116 may progressively wake their neighbors moving out the tree.

[00121] For instance, in some embodiments, module 116 would wake modules 108 and 114. This message sending may continue to propagate out through neighbor modules. The controller may periodically be querying the system checking for new data, such as the input received by module 116 which would now propagating through the system. Once at least the modules along the shortest path from module 116 to the controller are awake, the data can be queried by the controller. This message sending would continue to propagate through the tree until all of the modules 102 - 116 were awake, which may be confirmed by the controller periodically checking the system to ensure all modules were awake. See an example embodiment of the wake shown in flowchart 500 following a similar path to that described in workflow 400 in Table 1 below:

[00122] Table 1 : Example System Wake by a Module

[00123] FIG. 6 is a block diagram showing a workflow 600 for waking a module path, according to some embodiments. In workflow 600, modules in the system may periodically have real-time information relevant to the controller that is time sensitive (e.g., firmware update, module touch data, motion sensor data, button presses, and/or other sensor data, among others). It can be beneficial to wake only the path from the module to the controller to allow this data to be transmitted when this data needs to be transmitted, as it may not have relevance to the rest of the system.

[00124] Another variation for workflow 600 is the usage of the system for error condition clearing, and reporting same to the controller so that the controller can update internal records. For example, a camera module may be obstructed or have fallen over due to wind, and a user may take steps to rectify the situation. The user rights the camera, and then presses a button to clear the error. An error condition clearing message triggered by the button press is then desired to be sent from the camera module back to the controller. However, this is compounded because the modules along the path to the controller may be asleep. Workflow 600 can be used for the path routing and message sending back to the controller without unnecessarily waking up too many modules along the way back to the controller. By avoiding unnecessarily waking up certain modules, a technical benefit of this approach is to save power by allowing those modules to remain asleep, while being still able to clear the error condition.

[00125] This can also be used for various other types of commands not necessarily restricted to the camera, for example, a module may have interactive buttons or tactile inputs that cause messages relating to the controller to be initiated. These messages can include different controller operation settings (e.g., changing an overall power level drawn from the power grid), etc.

[00126] Accordingly, in some embodiments, the module attempts to find a fast I fastest path to the controller to transmit a message to the controller instead of waking the entire system. In a variation, the path to the controller is awakened to send the message to the controller, and once the controller is aware of the instruction, it can also begin waking up modules to resume normal functions.

[00127] The workflow 600, of the normal sleep mechanism that is first initiated by the controller and later interrupted by any module in the system is described, according to some embodiments, below. The process described below should be understood as exemplary only.

[00128] In this variation, each of the modules may periodically assign a module side as the parent I root side module based on a layout detection approach to determine path communications to a parent node or controller.

[00129] At 602, the controller sends out a message using a layout detection protocol to instruct all the lighting modules to go to sleep for a defined period of time. The layout detection protocol can be, for example, one of the embodiments utilized as described in PCT Application No. PCT/CA2019/050012, filed 04-Jan-2019, entitled “TRANSPORT METHOD IN HIERARCHICAL DATA NETWORK” as the communications protocol.

[00130] At 604, the modules proceed to sleep for the period of time defined at 602.

[00131] At 606, the modules individually wake for a second period of time, waiting to receive a message on any side. Should the modules not receive the message within the second period of time, they may resume sleep. This second period of time could be a short duration designed for significant power savings. However, the drawback of a short duration can be that it may take a number of cycles as the modules wake up in a staggered manner (due to the clock drifts that arise over time as between modules).

[00132] At 608, when a module needs to transmit data, the module with the data to be communicated may wake its parent I root side module. In some embodiments, this may be done using a serialized message (e.g., root detect). In other embodiments, this may be done using a GPIO interrupt. The modules may continue to wake moving back to the controller. The modules may be woken by the controller at 608 during the second period of time at 606.

[00133] At 610, the controller may periodically query the lighting module system to check for new data. In some embodiments, step 610 may not be required. In some embodiments, the controller is the root I parent, and is the last module to receive the wake up message for a message moving up the tree towards the root I parent. In such an embodiment, it may be guaranteed that all modules on the path to the root I parent are awake by the time the controller receives a message. In some embodiments, step 612 may be directly after step 608.

[00134] At 612, once the modules along the short (sometimes shortest) path from the module performing the wake back to the controller are awake, the data may be queried successfully by the controller. In some embodiments, this is not necessarily the shortest path, but a short path is sufficient due to the potential complexity of the layout.

[00135] The controller may then resume normal functions of the system. These can include firmware upgrades of the controller, error condition clearing, etc.

[00136] The workflow 600 for waking a module path according to one embodiment may follow such a process outlined above, but may in other embodiments include more or less steps, and may be performed in various orders.

[00137] A path-only relevant scenario, where a workflow 600 may be a preferred wake method may be, for instance, a sensor input that does not result in all the modules having to wake up. A button input, for example, will result in the modules needing to wake up. Another path-only relevant scenario may be a firmware update for a particular module or to clear an error-condition in a module, for example. In some embodiments, the modules may only wake up their root I parent modules, while making way to the controller. The controller is the parent I root node of the layout tree, so moving up the parent route (via root modules, for example), is the surest way to reach the controller for any module. In other embodiments, different path routing algorithms and/or trajectories may be implemented. The layout tree can be established during a periodic poll session that, for example, can be triggered whenever a device is detected to be removed or added to the topology. In another variation, or complementarily, the layout tree can also be periodically determined through interrogation of the modules. The layout tree or a portion thereof can also be propagated to each module and stored on on-board memory. Instead of the full tree being provided (which could use too much memory), an alternative to save memory can include simply a designation of which of the connections if there is a plurality of connection is designated as a root connection.

[00138] In some embodiments, the modules may denote each interconnection as a root I parent or children connection. For example, consider a module A, which is connected to modules B and C. In some embodiments, on-board memory of module A could indicate that module B is a root I parent module and module C is a child module, and on-board memory may be used to distinguish between the connections. In this example, module A would be parent to both modules B and C. In some embodiments, if B and C were also connected to each other (i.e., all modules connected to one another), these may be referred to as redundant connections. In some embodiments, redundant connections may be used. The usage of redundant connections can be triggered as backup connections when the path does not appear to work and the module cannot confirm that the controller has received the message.

[00139] In another example, redundant connects may be used when coupling occurs in the context of a mesh-based network, where devices have medium or low- range communications capability and can “see” various neighbors, and the modular devices include wireless communications transceivers. For example, the devices could be coupled as communications enabled lighting, communications enabled cameras, thermostats, alarms, that cover a larger area, such as across an office, an apartment building complex, among others. Mesh networking can be electromagnetic coupling, and coupling could also occur in the context of communication from a vertex or otherwise arbitrary location along a surface of a module.

[00140] FIG. 7 is a flowchart 700 of a process for waking a module path, according to some embodiments. In some embodiments, the process shown in flowchart 700 may follow similar steps to those described in workflow 600.

[00141] For example, consider a situation where module 116 in the system receives real-time information relevant to the controller that is time sensitive (e.g., firmware update, layout change, module touch data, motion sensor data, and/or other sensor data, among others). It can be beneficial to wake only the path from the module to the controller to allow this data to be transmitted when this data needs to be transmitted, as it may not have relevance to the rest of the system. For example, module 116 may require a module specific firmware update, which is not relevant to the entire system of modules. [00142] The controller may be sending out a message using a layout detection protocol instructing modules 102 - 116 to sleep for a defined period of time. For the wake up latency to be minimum, the system may require modules 102 - 116 to wake up after a defined time which may be 500 ms or less, and check for messages from the controller, other modules on their side and/or using a GPIO interrupt.

[00143] Modules 102 - 116 may wake individually for a second period of time to check if they have received a message from any side. If the individual module of modules 102 - 116 does not receive a message during this second period of time, the individual module may resume sleeping.

[00144] Once the system of modules needs to be woken due to the time sensitive input being received by a module, in this case module 116 which receives an input during one of the second waiting periods, said module with the data may wake its parent I root side module, for example, sending a serialized message or using a GPIO interrupt. Beginning from the module with the data to be communicated, the modules 102 - 116 may progressively wake their parent I root side modules moving out the tree back to the controller.

[00145] For instance, module 116 may wake modules 108 and 114. This message sending may continue to propagate out through the modules by their parent I root side. The controller may periodically be querying the system checking for new data, such as the input received by module 116 which may now propagating through the system. Once the modules along the shortest path from module 116 to the controller are awake, the data can be queried by the controller. In some embodiments, the parent or root side may be the side on which the module receives a message. In some embodiments, even in the case of a looped layout, such as that shown in part of FIG. 7, a message may be received first on one of the two sides, for example, and not on both sides. The first side to receive a message may be called the parent side or the root side, and the other(s) may be called the redundant side(s). [00146] See an example embodiment of the wake shown in flowchart 700 following a similar path to that described in workflow 600 in Table 2 below:

[00147] Table 2: Example Waking a Module Path

[00148] FIG. 8 is a schematic diagram showing an example lighting module 800, according to some embodiments. As illustrated, lighting module 800 includes one or more digital signal processor(s) 802, memory 804, one or more light emitter(s) 806, a power input 808, and connectors 810, 812, and 814.

[00149] Processor(s) 802 may be one or more Intel™ x86, Intel x64, AMD™ x86- 64, PowerPC™ , ARM™ processors or the like. [00150] Memory 804 may include random-access memory, read-only memory, or persistent storage such as a hard disk, a solid-state drive or the like. Read-only memory or persistent storage is a computer-readable medium. A computer-readable medium (e.g., a non-transitory computer readable medium) may be organized using a file system, controlled and administered by an operating system governing overall operation of the computing device.

[00151 ] Light emitter(s) 806 may be one or more of light-emitting diodes, or the like. The In some embodiments, lighting module 800 can also include different types of interactive I input components, such as touch sensors (capacitive sensors), physical buttons, or environmental sensors (e.g., humidity, water, temperature). In another variation, the input components can include further components, such as a data receipt port such as a USB port so that firmware or other machine instruction sets can be uploaded into the lighting module 800 for ultimately sending same to either all of the modules, some of the modules, or the controller (e.g., firmware upgrade that can be initiated at any capable module). There can also be various types of button inputs for conducting tasks such as a user confirming clearing error conditions (e.g., user presses reset button for a module that was originally shut down due to over-temperature now that the module has returned to a normal temperature). In some embodiments, DSP 802 can automatically track conditions and upon a condition trigger being achieved, may initiate the wake of either all of the modules itself or a wake of a path back to the controller. For example, there could be a over voltage condition, and the lighting module 800 needs to wake a path back to the controller to indicate to the controller that it is entering a danger condition. Similarly, a user, upon validating the issue, may press a reset button to indicate that the lighting module 800 has made a spurious message. The pressing of the reset button may require to wake a path back to the controller to indicate to the controller that error is cleared. In another variation, the lighting module 800 can detect that the error condition (e.g., currentvoltage < thresholdvoltage) has cleared and conducts the wake automatically. [00152] Connectors 810, 812, and 814 may serve to interconnect the lighting module 800 with other lighting modules. The lighting modules connected to lighting module 800 via connectors 810, 812, and 814 may be substantially similar to lighting module 800.

[00153] For example, if the layout shown in FIG. 1 was made up of lighting modules 800, that is lighting modules 102 - 116 were all substantially similar to module 800, they may be interconnected by their respective connectors 810, 812, and 814. For instance, module 110 would have nothing connected to its connector 810, but would be connected at its connector 812 to the connector 812 of module 106, and module 110 would also be connected at its connector 814 to the connector 814 of module 112. Each 810, 812, and 814 can have its own networking interfaces and these may, in some embodiments, be designated as different types of connections for the purposes of the messaging as described in embodiments herein.

[00154] For example a layout detection protocol may be used periodically and each of these connections can be designated as root/parent (e.g., the root side), or child side. The root/parent connections can be prioritized for communications depending on the method and the child side can be prioritized for redundant communications, or vice versa. The memory 804 can store layout information, or in some embodiments where memory is very limited, simply a set of data records designating each of the plurality of connections as a root/parent connection or a child connection. The memory 804 can also include a message buffer (e.g., memory registers) that track whether there is a recent sleep I wake message to be processed and, in some embodiments store the sleep I wake message for processing when lighting module 800 is awake. The memory 804 can also store information such as that relating to the input command or a function command to be processed by the lighting module 800 (e.g., touchCommand_Wake_all_Modules = TRUE, time_ touchCommand_Wake_all_Modules = 294860, touchCommand_Wake_all_Modules_Progress = “In Progress”). [00155] The memory 804, in some embodiments, can also store information to be relayed to a controller, such as firmware update information, error clearing I error condition information, etc.

[00156] The module lighting system, controller and power source may then, according to various embodiments, pass messages to and from the modules and the controller. The controller may in some embodiments, continue to poll to determine the different layout of the individual lighting modules, as they are modular and can be moved. Should a new path be found when a message is being sent, the controller may update its layout tree so that messages can be sent more efficiently.

[00157] Software instructions are executed by processor(s) 802 from a computer- readable medium. For example, software may be loaded into random-access memory from persistent storage of memory 804 or from one or more devices via I/O interfaces for execution by one or more processors 802. As another example, software may be loaded and executed by one or more processors 802 directly from read-only memory.

[00158] Example software components and data stored within memory 804 of lighting module 800 may include software to perform the wake methods described within.

[00159] FIG. 9 is a flowchart of a process 900 for waking a module by controller using low energy (LE) sleep timer, according to some embodiments.

[00160] In some embodiments, process 900 may expand on the recursive logic that may sit within steps 204-208, 404-408, and/or 604-608, for example. Steps 902, 904, 906, 908, 910, 912, 914, 916, 918, 920, 922, and 924 are shown.

[00161] For instance, consider a module (e.g., modular lighting panel), such as module 800, is in active mode, and receives a signal to sleep. The module may place its processor into a low power mode for a certain amount of time. Should the LE timer expire, and the module wakes, the module may, in some embodiments, iterate through its ports, checking for messages.

[00162] For example, consider a hexagon shaped module with six ports. Following the LE timer expiry, and the module waking up, port 1 may be checked, and the module may continue checking from port 1 through to port 6. If there are no messages received on any port, in some embodiments, the module may once again place the processor into a low power mode for a certain amount of time.

[00163] While checking the ports for messages, for example, consider that port 3 has received a message. Once the module checks for a message on port 3, and the message is received, it may check if the message is to wake up all modules, or to only wake up modules on a path to the controller. For all modules, the module may once again iterate through its ports, in some embodiments. For example, such a hexagon shaped module may send a message on port 1 to wake up a child module, if present, and then may send a message on port 2 to wake up a child module, if present, and may continue to send messages through to port 6, waking all present child modules. All modules would thus be in active mode, and may in some embodiments, continue within such a process 900.

[00164] For only waking modules on a path to the controller, the module which has received the message may send a message on its parent I root port to wake up the connected module. In some embodiments, the parent I root port may be determined by a previous propagation of a message through to the controller.

[00165] FIG. 10 is a flowchart of a process 1000 for waking a module by controller using interrupt, according to some embodiments. Steps 1002, 1004, 1006, 1008, 1010, 1012, 1014, 1016, 1018 are shown.

[00166] Process 1000 shows, according to some embodiments, a simpler GPIO flow, which may be similar and/or equivalent to process 900, for example. [00167] For instance, consider a module (e.g., modular lighting panel), such as module 800, is in active mode at 1002, and receives a signal to sleep at 1004. The module may, in some embodiments, place its processor into a low power mode indefinitely at 1006. Should the processor be woken up by an interrupt on one of the module ports at 1008, and the module wakes, the module may, in some embodiments, check if the message is for waking up all panels or only for panels on a path to the controller at 1010.

[00168] For example, consider a hexagon shaped module with six ports. Following an interrupt waking the processor, the module may check and read a message to wake up all other modules. In some embodiments, to wake all modules, the module may iterate through its ports. For example, such a hexagon shaped module may send a message on port 1 to wake up a child module, if present, and then may send a message on port 2 to wake up a child module, if present, and may continue to send messages through to port 6, waking all present child modules. All modules would thus be in active mode, and may in some embodiments, continue within such a process 1000.

[00169] Should the message received in the interrupt be for only waking modules on a path to the controller, the interrupted module may send a message on its parent I root port to wake up the connected module. In some embodiments, the parent I root port may be determined by a previous propagation of a message through to the controller.

[00170] In some embodiments, process 1000 may illustrate a flow for a single module. If, for example, the module is woken up, irrespective of path wake or system wake, the module may end up in the active mode. However, before the module enters active mode, it may check where it should propagate the wake up message, based on path or system wake. The module may then send the message. [00171] FIG. 11 is a flowchart of a process 1100 illustrating low power mode control, according to some embodiments. Steps 1102, 1104, 1106, 1108, 1110, 1112 are shown.

[00172] FIG. 11 illustrates, according to some embodiments, an example implementation on the controller side, and may show how user interaction (e.g. from a smartphone app or voice assistant) can trigger interrupts.

[00173] For instance, the controller may check if modules may be placed into a low power mode at 1102. In some circumstances, modules may be required to be on, or in an active state, and would not be permitted to be placed into a low power mode.

[00174] If the panels are allowed to be placed into low power mode at 1104, the controller may send an “enter low power” message to the modules. While in low power mode, the modules may listen for a wake up message from other modules, for example at 1106. If no messages are received, in some embodiments the module may then check and listen for user interactions at 1108. If no interaction is received, the module may continue listening for wake up messages from panels, and cycling through as shown in process 1100, for example. In some embodiments, the module may listen for a user interaction before listening for a wake up message from other panels.

[00175] When a user interaction is performed on a module, the module “wakes up” (e.g., becomes active) and sends a message or changes the state of a pin on the edges. Depending on the kind of interaction and whether a system or path wake is required, either all the edges or only the parent edge of the panel is switched. This is a useful approach to help optimize power savings.

[00176] As adjacent modules to the interactive modules wake up, the message propagates depending on the message type and whether it’s a system or path wake. Message type can be processed based on fields in the message payload, such as header or body message payloads indicating whether the message is a system or a path wake.

[00177] As the modules propagate the message, they exit low power mode, and remain in active mode until instructed by the system controller to enter low power mode again. Instruction by the system controller can include messages being propagated by the controller.

[00178] An example of a system wake would be the user pressing a button on a module which would have to be processed as an action by the system controller. In this case, since the button press will likely result in the system controller exiting the modules from low power mode, it is prudent to have the interacted module itself to make all the other modules exit low power mode.

[00179] The total latency of the message propagation to the system controller would be the time for a module to exit low power mode multiplied with the number of modules in the path to the system controller.

[00180] In order to ensure that the latency is kept to a minimum some embodiments may use signal on edge pins as an interrupt to exit low power mode. Some embodiments may also sample the edge pins and/or communication pins for a message. This can lead to a higher latency but may be a simpler option for the processor architecture. An example of a pure path wake would be a sensory module that needs to report the observation from its sensor to the system controller. In such a case, the module does not know if the observation will result in the system exiting low power mode, and hence only the path to the system controller needs to exit low power mode. Similar methods as mentioned above for system wake can be used for path wake as well. If a wake up message is received from a module at 1110, the system may check if the modules have exited low power mode. In some embodiments, this check may be done using a layout detection protocol as described in detail above, for example. If a user interaction is detected, a wake up message may be sent to the modules, and the system may check if the modules have exited lower power mode at 1112. In some embodiments, this check may be done using a layout detection protocol, for example. In both cases, as shown in example process 1100, this check may reiterate until all panels have exited low power mode.

[00181] Once all panels have exited low power mode, the controller may continue to check if the modules may be placed into lower power mode, and wait if the modules are still required to be on, until they may return to be placed into low power mode again.

[00182] In some embodiments, edge communications may refer to communications on an edge of the system, such as the edge of a module. In some embodiments, communication interfaces may not be restricted to physical edges, but rather may occur at different locations along a surface, interior, or exterior of a modular device, for example.

[00183] In an aspect, there is provided a controller device for controlling power conservation states of a modular system including one or more modular devices electromagnetically coupled to one another or the controller device across one or more communication interfaces of each modular device. The controller device comprising: at least a processor, computer readable memory, and the one or more controller communication interfaces.

[00184] The processor configured to: communicate a wake message to children modular devices of the one or more modular devices that are coupled directly to the controller device, each of the children modular devices configured to wake periodically during a sleep state period of a corresponding power management protocol and to process the wake message to transition to a woken state. Each of the children modular devices, after transitioning to the woken state, proceed to propagate the wake message to its corresponding children modular devices that are coupled across the corresponding one or more communication interfaces such that successive children modular devices are transitioned to the woken state. [00185] The processor also configured to periodically communicate a poll message to be propagated across all of the children modular devices to receive a poll response from each of the children modular devices that are in the woken state; and upon determining that all of the children modular devices are in the woken state, initiate a desired system functionality across the entire modular system.

[00186] In another aspect, there is provided a modular device for controlling power conservation states of a modular system including one or more modular devices electromagnetically coupled to one another or the controller device across one or more edge communication interfaces of each modular device. The modular device comprising: a processor, computer readable memory, and the one or more edge communication interfaces.

[00187] The processor configured to: in response to a triggering event, transition the modular device into a woken state; communicate a wake message to children and parent modular devices that are coupled directly to the modular device, each of the children and parent modular devices configured to wake periodically during a sleep state period of a corresponding power management protocol and to process the wake message to transition to a woken state. Each of the children and parent modular devices, after transitioning to the woken state, proceed to propagate the wake message to its corresponding children and parent modular devices that are coupled across the corresponding one or more communication interfaces such that successive children and parent modular devices are transitioned to the woken state.

[00188] The controller device periodically communicates a poll message to be propagated across all of the children modular devices to receive a poll response from each of the children modular devices that are in the woken state. Upon determining that all of the children modular devices are in the woken state, the controller device initiate a desired system functionality across the entire modular system.

[00189] In another aspect, there is provided a modular device for controlling power conservation states of a modular system including one or more modular devices electromagnetically coupled to one another or the controller device across one or more communication interfaces of each modular device. The modular device comprising: a processor, computer readable memory, and the one or more communication interfaces.

[00190] The processor configured to: in response to a triggering event, transition the modular device into a woken state; communicate a wake message to parent modular devices that are coupled directly to the modular device, each of the parent modular devices configured to wake periodically during a sleep state period of a corresponding power management protocol and to process the wake message to transition to a woken state. Each of the parent modular devices, after transitioning to the woken state, proceed to propagate the wake message to its corresponding parent modular devices that are coupled across the corresponding one or more communication interfaces such that successive parent modular devices are transitioned to the woken state.

[00191] The controller device periodically communicates a poll message to be propagated across all of the children modular devices to receive a poll response from each of the children modular devices that are in the woken state. Upon determining that the child modular device that initiated the wake is in the woken state, the controller device initiate a desired system functionality relating to the child modular device that initiated the wake.

[00192] In an embodiment, propagating the wake message to the corresponding children modular devices by the modular device includes maintaining the propagated message on a message buffer at the corresponding one or more communication interface until the wake message is processed.

[00193] In an embodiment, propagating the wake message to the corresponding children and parent modular devices by the modular device includes maintaining the propagated message on a message buffer at the corresponding one or more communication interface until the wake message is processed. [00194] In an embodiment, propagating the wake message to the corresponding parent modular devices by the modular device includes maintaining the propagated message on a message buffer at the corresponding one or more communication interface until the wake message is processed.

[00195] In an embodiment, the message buffer is stored in a memory buffer of the modular device propagating the wake message.

[00196] In an embodiment, the message buffer is stored in a memory buffer of the modular device receiving the wake message.

[00197] In an embodiment, each of the modular devices, during the sleep state period, are configured to wake asynchronously free of a precise schedule for waking during the sleep state period to identify whether the wake message is present on the message buffer and to process the wake message if it is present on the message buffer.

[00198] In an embodiment, each of the modular devices, if already in a woken state, processes any wake message present on the message buffer by discarding it.

[00199] In an embodiment, the poll response from each of the modular devices includes at least one data field indicating that there are no wake messages present on any message buffer associated with the corresponding modular device, and the at least one data field of the poll responses from each of the one or more modular devices is utilized in determining that all of the children modular devices are in the woken state.

[00200] In an embodiment, the poll response from each of the modular devices includes at least one data field indicating that there are no wake messages present on any message buffer associated with the corresponding modular device, and the at least one data field of the poll responses from each of the one or more modular devices is utilized in determining that all of the children modular devices are in the woken state. [00201] In an embodiment, the wake message is communicated through a serialized message or a general purpose input I output interrupt message.

[00202] In an embodiment, the modular devices are modular lighting devices.

[00203] In an embodiment, a periodic wake during the sleep state period is controlled by a low accuracy or unsynchronized low energy clock of each of the modular devices.

[00204] In an aspect, there is provided a method for controlling power conservation states of the modular system including the devices according to any of the described embodiments.

[00205] In an aspect, there is provided a non-transitory computer readable medium storing machine interpretable instruction sets representing a software program product, which when executed by a processor, cause the processor to perform the method for controlling power conservation states of the modular system including the devices according to any one of the described embodiments.

[00206] Applicant notes that the described embodiments and examples are illustrative and non-limiting. Practical implementation of the features may incorporate a combination of some or all of the aspects, and features described herein should not be taken as indications of future or existing product plans.

[00207] Although the embodiments have been described in detail, it should be understood that various changes, substitutions and alterations can be made herein without departing from the scope. Moreover, the scope of the present application is not intended to be limited to the particular embodiments of the process, machine, manufacture, composition of matter, means, methods and steps described in the specification.

[00208] As one of ordinary skill in the art will readily appreciate from the disclosure, processes, machines, manufacture, compositions of matter, means, methods, or steps, presently existing or later to be developed, that perform substantially the same function or achieve substantially the same result as the corresponding embodiments described herein may be utilized. Accordingly, the appended embodiments are intended to include within their scope such processes, machines, manufacture, compositions of matter, means, methods, or steps.

[00209] As can be understood, the examples described above and illustrated are intended to be exemplary only.

Appendix: Power Savings Measurements

[00210] An experiment was conducted with 30 panels. Standby power consumption previously: 7.15W. Standby power consumption with low power mode: 0.3W.

[00211 ] The power saving is calculated to be 96%. It is important to note that these experimental results are not necessarily the same all the time as it depends on the percentage of sleep time and duration and the intensity of wake commands and how quickly the system returns to sleep.

Appendix: Sample System Logs

[00212] Appendix A - Sample System Logs when the controller wants to wake the panels through system wake, due to a layout change

[00213] [691.623][PW_LOG, debug,

[00214] /home/ubuntu/nanoleaf_programs/pixel/modules/power_engine/sr c/Pa nelPowerController.cpp, panelPowerControllerStateMachineTick, 81 , 2003201384] panels are going low power wait! [693.723][CC_LOG, info,

[00215] /home/ubuntu/nanoleaf_programs/pixel/modules/command_center/ src/ CommandCenter. cpp, panelPowerControllerEventHandler, 3149, 2003201384] panels entering low power mode [00216] [693.724][PW_LOG, debug,

[00217] /home/ubuntu/nanoleaf_programs/pixel/modules/power_engine/sr c/Pa nelPowerController.cpp, panelPowerControllerStateMachineTick, 106, 2003201384] panels are going low power!

[00218] [703.049][PW_LOG, debug,

[00219] /home/ubuntu/nanoleaf_programs/pixel/modules/power_engine/sr c/Pa nelPowerController.cpp, panelPowerControllerStateMachineTick, 160, 2003201384] 1 F 00 1 F 00 1 F 00 1 F 00 1 F 00 1 F 00 1 F 00 1 F 00 1 F 00

[00220] [703.050][PW_LOG, debug,

[00221] /home/ubuntu/nanoleaf_programs/pixel/modules/power_engine/sr c/Pa nelPowerController.cpp, panelPowerControllerStateMachineTick, 165, 2003201384] not all panels are awake, sending a bulk pull again

[00222] [703.130][PW_LOG, debug,

[00223] /home/ubuntu/nanoleaf_programs/pixel/modules/power_engine/sr c/Pa nelPowerController.cpp, panelPowerControllerStateMachineTick, 160, 2003201384] 10 00 10 00 10 00 10 00 10 00 10 00 10 00 10 00 10 00

[00224] [703.130][PW_LOG, debug,

[00225] /home/ubuntu/nanoleaf_programs/pixel/modules/power_engine/sr c/Pa nelPowerController.cpp, panelPowerControllerStateMachineTick, 165, 2003201384] not all panels are awake, sending a bulk pull again

[00226] [703.210][PW_LOG, debug,

[00227] /home/ubuntu/nanoleaf_programs/pixel/modules/power_engine/sr c/Pa nelPowerController.cpp, panelPowerControllerStateMachineTick, 160, 2003201384] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [00228] [703.211][PW_LOG, debug,

[00229] /home/ubuntu/nanoleaf_programs/pixel/modules/power_engine/sr c/Pa nelPowerController.cpp, panelPowerControllerStateMachineTick, 165, 2003201384] not all panels are awake, sending a bulk pull again

[00230] [703.291 ][PW_LOG, debug,

[00231] /home/ubuntu/nanoleaf_programs/pixel/modules/power_engine/sr c/Panel PowerController.cpp, panelPowerControllerStateMachineTick, 160, 2003201384] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

[00232] [703.291 ][PW_LOG, debug,

[00233] /home/ubuntu/nanoleaf_programs/pixel/modules/power_engine/sr c/Panel PowerController.cpp, panelPowerControllerStateMachineTick, 165, 2003201384] not all panels are awake, sending a bulk pull again

[00234] [703.371 ][PW_LOG, debug,

[00235] /home/ubuntu/nanoleaf_programs/pixel/modules/power_engine/sr c/Panel PowerController.cpp, panelPowerControllerStateMachineTick, 160, 2003201384] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

[00236] [703.371 ][PW_LOG, debug,

[00237] /home/ubuntu/nanoleaf_programs/pixel/modules/power_engine/sr c/Panel PowerController.cpp, panelPowerControllerStateMachineTick, 165, 2003201384] not all panels are awake, sending a bulk pull again

[00238] [703.471 ][PW_LOG, debug, [00239] /home/ubuntu/nanoleaf_programs/pixel/modules/power_engine/sr c/Panel PowerController.cpp, panelPowerControllerStateMachineTick, 192, 2003201384] performing single bulk pull

[00240] [703.483][PW_LOG, debug,

[00241] /home/ubuntu/nanoleaf_programs/pixel/modules/power_engine/sr c/Pa nelPowerController.cpp, panelPowerControllerStateMachineTick, 201 , 2003201384] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

[00242] [703.484][PW_LOG, debug,

[00243] /home/ubuntu/nanoleaf_programs/pixel/modules/power_engine/sr c/Pa nelPowerController.cpp, panelPowerControllerStateMachineTick, 210, 2003201384] number of bytes mismatch in BP response for PPC

[703.485][PW_LOG, debug,

[00244] /home/ubuntu/nanoleaf_programs/pixel/modules/power_engine/sr c/Pa nelPowerController.cpp, panelPowerControllerStateMachineTick, 232, 2003201384] refresh wake done, something interesting [703.486][CC_LOG, info,

[00245] /home/ubuntu/nanoleaf_programs/pixel/modules/command_center/ src/ CommandCenter.cpp, panelPowerControllerEventHandler, 3154, 2003201384] panels exit low power mode

[00246] [703.507][PC_LOG, error,

/home/ubuntu/nanoleaf_programs/pixel/modules/panel_commun ication

[00247] Appendix B Under normal operation, controller querying the panels for changes

[00248] [706.986][CC_LOG, info,

/home/ubuntu/nanoleaf_programs/pixel/modules/command_cent er/src/CommandC enter.cpp, panelPowerControllerEventHandler, 3149, 2003201384] panels entering low power mode

[00249] [706.988][PW_LOG, debug,

/home/ubuntu/nanoleaf_programs/pixel/modules/power_engine /src/PanelPowerCo ntroller.cpp, panelPowerControllerStateMachineTick, 106, 2003201384] panels are going low power!

[00250] [716.301 ][PW_LOG, debug,

/home/ubuntu/nanoleaf_programs/pixel/modules/power_engine /src/PanelPowerCo ntroller.cpp, panelPowerControllerStateMachineTick, 160, 2003201384] 1 F 00 1 F 00 1 F 00 1 F 00 1 F 00 1 F 00 1 F 00 1 F 00 1 F 00

[00251] [716.401 ][PW_LOG, debug,

/home/ubuntu/nanoleaf_programs/pixel/modules/power_engine /src/PanelPowerCo ntroller.cpp, panelPowerControllerStateMachineTick, 192, 2003201384] performing single bulk pull

[00252] [716.403][PW_LOG, debug,

/home/ubuntu/nanoleaf_programs/pixel/modules/power_engine /src/PanelPowerCo ntroller.cpp, panelPowerControllerStateMachineTick, 201 , 2003201384] 1000 1000 10 00 10 00 10 00 10 00 10 00 10 00 10 00

[00253] [716.403][PW_LOG, debug,

/home/ubuntu/nanoleaf_programs/pixel/modules/power_engine /src/PanelPowerCo ntroller.cpp, panelPowerControllerStateMachineTick, 217, 2003201384] refresh wake done, nothing interesting

[00254] [725.719][PW_LOG, debug,

/home/ubuntu/nanoleaf_programs/pixel/modules/power_engine /src/PanelPowerCo ntroller.cpp, panelPowerControllerStateMachineTick, 160, 2003201384] 1 F 00 1 F 00 1 F 00 1 F 00 1 F 00 1 F 00 1 F 00 1 F 00 1 F 00 [00255] [725.819][PW_LOG, debug,

/home/ubuntu/nanoleaf_programs/pixel/modules/power_engine /src/PanelPowerCo ntroller.cpp, panelPowerControllerStateMachineTick, 192, 2003201384] performing single bulk pull

[00256] [725.821 ][PW_LOG, debug,

/home/ubuntu/nanoleaf_programs/pixel/modules/power_engine /src/PanelPowerCo ntroller.cpp, panelPowerControllerStateMachineTick, 201 , 2003201384] 1000 1000 10 00 10 00 10 00 10 00 10 00 10 00 10 00

[00257] [725.821 ][PW_LOG, debug,

/home/ubuntu/nanoleaf_programs/pixel/modules/power_engine /src/PanelPowerCo ntroller.cpp, panelPowerControllerStateMachineTick, 217, 2003201384] refresh wake done, nothing interesting

[00258] Appendix C - System Logs for when one interacts with a module when the panels are in low power mode. In this case, the user is interacting with the button puck of tsystem while the system was in low power mode. This is an example of system wake by module

[00259] [110.048][PW_LOG, debug,

/home/eski/Nanoleaf/pixel/modules/power_engine/src/PanelP owerController.cpp, panelPowerControllerStateMachineTick, 81 , 2002554216] panels are going low power wait!

[00260] [112.149][CC_LOG, info,

/home/eski/Nanoleaf/pixel/modules/command_center/src/Comm andCenter.cpp, panelPowerControllerEventHandler, 3168, 2002554216] panels entering low power mode

[00261] [112.153][PW_LOG, debug,

/home/eski/Nanoleaf/pixel/modules/power_engine/src/PanelP owerController.cpp, panelPowerControllerStateMachineTick, 106, 2002554216] panels are going low power!

[00262] [121.474][PW_LOG, debug,

/home/eski/Nanoleaf/pixel/modules/power_engine/src/PanelP owerController.cpp, panelPowerControllerStateMachineTick, 161 , 2002554216] 00 02 00 0000 0000 00 00 7F

[00263] [121 ,574][PW_LOG, debug,

/home/eski/Nanoleaf/pixel/modules/power_engine/src/PanelP owerController.cpp, panelPowerControllerStateMachineTick, 193, 2002554216] performing single bulk pull

[00264] [121 ,576][PW_LOG, debug,

/home/eski/Nanoleaf/pixel/modules/power_engine/src/PanelP owerController.cpp, panelPowerControllerStateMachineTick, 202, 2002554216] 00 02 00 0000 0000 03 00 7F

[00265] [121 ,576][PW_LOG, debug,

/home/eski/Nanoleaf/pixel/modules/power_engine/src/PanelP owerController.cpp, panelPowerControllerStateMachineTick, 218, 2002554216] refresh wake done, nothing interesting

[00266] [125.374][PW_LOG, debug,

/home/eski/Nanoleaf/pixel/modules/power_engine/src/PanelP owerController.cpp, panelPowerControllerStateMachineTick, 127, 2002554216] panels have been woken up by user interaction!

[00267] [125.574][CC_LOG, info,

/home/eski/Nanoleaf/pixel/modules/command_center/src/Comm andCenter.cpp, panelPowerControllerEventHandler, 3173, 2002554216] panels exit low power mode [00268] [125.589][CC_LOG, info,

/home/eski/Nanoleaf/pixel/modules/command_centei7src/Comm andCenter.cpp, bulkPullControllerEventHandler, 1366, 2003127656] lines button state changed 8 4

[00269] [125.640][CC_LOG, info,

/home/eski/Nanoleaf/pixel/modules/command_center/src/Comm andCenter.cpp, bulkPullControllerEventHandler, 1366, 2003127656] lines button state changed 0 4

[00270] /src/BulkPullController.cpp, doBulkPull, 123, 2004061544] bpc received less than expected response (18 bytes)! [703.507][PC_LOG, info,

[00271 ] /home/ubuntu/nanoleaf_programs/pixel/modules/panel_communica tion

[00272] /src/BulkPullController.cpp, fireEvents, 211 , 2004061544] layout change detected (new 0 missing 1)

[00273] Under normal operation, controller querying the panels for changes

[00274] [706.986][CC_LOG, info,

[00275] /home/ubuntu/nanoleaf_programs/pixel/modules/command_center/ src/Co mmandCenter.cpp, panelPowerControllerEventHandler, 3149, 2003201384] panels entering low power mode [706.988][PW_LOG, debug,

[00276] /home/ubuntu/nanoleaf_programs/pixel/modules/power_engine/sr c/Panel PowerController.cp p, panelPowerControllerStateMachineTick, 106, 2003201384] panels are going low power! [716.301 ][PW_LOG, debug,

[00277] /home/ubuntu/nanoleaf_programs/pixel/modules/power_engine/sr c/Panel PowerController.cp p, panelPowerControllerStateMachineTick, 160, 2003201384]

1 F 00 1 F 00 1 F 00 1 F 00 1 F 00 1 F 00 1 F 00 1 F 00 1 F 00 [716.401 ][PW_LOG, debug, [00278] /home/ubuntu/nanoleaf_programs/pixel/modules/power_engine/sr c/Panel PowerController.cp p, panelPowerControllerStateMachineTick, 192, 2003201384] performing single bulk pull [716.403][PW_LOG, debug,

[00279] /home/ubuntu/nanoleaf_programs/pixel/modules/power_engine/sr c/Panel PowerController.cp p, panelPowerControllerStateMachineTick, 201 , 2003201384] 10 00 10 00 10 00 10 00 10 00 10 00 10 00 10 00 10 00 [716.403][PW_LOG, debug,

[00280] /home/ubuntu/nanoleaf_programs/pixel/modules/power_engine/sr c/Panel PowerController.cp p, panelPowerControllerStateMachineTick, 217, 2003201384] refresh wake done, nothing interesting

[00281] [725.719][PW_LOG, debug,

[00282] /home/ubuntu/nanoleaf_programs/pixel/modules/power_engine/sr c/Panel PowerController.cp p, panelPowerControllerStateMachineTick, 160, 2003201384]

1 F 00 1 F 00 1 F 00 1 F 00 1 F 00 1 F 00 1 F 00 1 F 00 1 F 00 [725.819][PW_LOG, debug,

[00283] /home/ubuntu/nanoleaf_programs/pixel/modules/power_engine/sr c/Panel PowerController.cp p, panelPowerControllerStateMachineTick, 192, 2003201384] performing single bulk pull [725.821 ][PW_LOG, debug,

[00284] /home/ubuntu/nanoleaf_programs/pixel/modules/power_engine/sr c/Panel PowerController.cp p, panelPowerControllerStateMachineTick, 201 , 2003201384] 10 00 10 00 10 00 10 00 10 00 10 00 10 00 10 00 10 00

[00285] [725.821 ][PW_LOG, debug,

/home/ubuntu/nanoleaf_programs/pixel/modules/power_engine /src/PanelPowerCo ntroller.cp p, panelPowerControllerStateMachineTick, 217, 2003201384] refresh wake done, nothing interesting