MESH-NETWORKED POWER CONTROL DEVICES, SYSTEMS AND METHODS

Abstract

A platform services system communicating with and controlling a plurality of power distribution micro-networks is provided. Each power distribution micro-network has its own wireless mesh network and a master control unit for scheduling efficient power allocation to devices in the micro-network and communicating with the platform services system. Each device in the micro-network is controlled by its own satellite unit. Each satellite unit communicates with and receives tokens from its master control unit. Each wireless mesh network uses both a Zigbee protocol and a Dynamic Device Addressing (DDA) protocol. The DDA allows communication with a neighboring micro-network in the event that its master controller cannot communicate with the platform services system.

Claims

1. A power distribution micro-network comprising: a plurality of satellites, each of the satellites controlling power allocation to a respective appliance or a control system; a master controller configured to schedule the power allocation, the master controller comprising: a local area wireless transceiver, the master controller being configured to communicate with the plurality of satellites, a memory storing processor-executable program code including: at least one function type representing a type of a function that is a power-consuming activity of at least one appliance, at least one function priority associated with the function type, at least one task representing a subtype of the at least one function type, at least one task priority associated with the at least one task in which a user task type has a highest priority, and a set of tasks to be performed comprising a last task of the at least one task, and at least one processor configured to have access to the processor-executable program code and configured to execute the processor-executable program code; and a local area wireless mesh network allowing communication between the master controller and the plurality of satellite units, wherein, when the at least one processor executes the program code, the master controller is configured to: receive a plurality of power allocation requests via the local area wireless transceiver from the plurality of satellites forming part of the localized mesh network, each of the power allocation requests relating to a proposed power usage by the respective appliance which is controlled by a respective one of the satellites, each of the power allocation requests specifying a function type of the at least one function type and a task of the at least one task, determine available power resources, determine which of the power allocation requests to accommodate based on the available power resources, a priority level of the request, and an estimate of required power associated with the request, the priority level being determined by the at least one function priority and the at least one task priority associated with the request, and respond to each of the power allocation requests to be accommodated by sending an approval message to each of the satellites from which the accommodated power allocation requests were received, indicating a designated time interval at or during which the requested power is to be allocated, the approval message comprising a resource allocation token defining a validity period corresponding to the designated time interval during which the respective power allocation request is considered valid to authorize performance of the function of the at least one appliance, wherein, on receipt of the user task type for a respective one of the satellites, immediately granting power at a highest appliance priority to the appliance controlled by the respective satellites, regardless of the priority level of the function associated with the respective appliance, wherein each of the satellites includes: a power control device configured to control power to one of the appliances, a local area wireless transceiver configured to form part of the local area wireless mesh network, at least one processor, and a memory accessible to the at least one processor of the satellite and storing executable program code that, when executed by the at least one processor of the satellite, causes the satellite to: determine that the respective appliance requires power to perform an appliance function, determine whether a valid resource allocation token is stored in the memory to authorize performance of the appliance function of the appliance, when there is no valid resource allocation token stored in the memory of the satellite, transmit a resource allocation request to the master controller via the local area wireless transceiver of the satellite, and when the valid resource allocation token is stored in the memory of the satellite, switch power to the respective appliance to perform the appliance function during the designated time interval.

2. The power distribution micro-network as claimed in claim 1, wherein each of the plurality of satellites is coupled with a power usage monitor configured to collect power consumption information relating to the appliance with which the respective satellite is associated, and wherein the respective satellite is configured to output the power consumption information as part of the power allocation request.

3. The power distribution micro-network as claimed in claim 2, wherein the plurality of satellites is configured to perform critical control functions in an event of failure of the master controller.

4. The power distribution micro-network as claimed in claim 3, wherein control parameters comprising at least predictive parameters are cached within the plurality of satellites.

5. A system comprising: the power distribution micro-network as claimed in claim 4; and a platform services system that is remote from the power distribution micro-network and communicable with the power distribution micro-network.

6. A plurality of power distribution micro-networks, each of the power distribution micro-networks according to claim 1, each of the power distribution micro-networks being configured to connect to a platform services system that is remote from the power distribution micro-networks and communicable with power distribution micro-networks, each of the power distribution micro-networks having a cellular transceiver configured to receive and send cellular messages from or to a person associated with a specific one of the power distribution micro-network to control one or more appliances in the specific power distribution micro-network.

7. The plurality of power distribution micro-network as claimed in claim 6, wherein the platform services system comprises a learning module configured to predict future power consumption activity, a database service that retains a record of power consumption, a listener service configured to collect and transmit data to at least one of the master controllers, and an alert service that records any system failures and is configured to generate fault state alerts.

8. The plurality of power distribution micro-networks as claimed in claim 7, wherein at least some of the power distribution micro-networks are neighbors and in range of the localized mesh network of each of the neighboring power distribution micro-networks, and the platform services system has a cellular transceiver.

9. The plurality of power distribution micro-networks as claimed in claim 8, wherein at least one of the satellites is configured to transfer data outside of one of the power distribution micro-networks and temporarily join the neighboring power distribution micro-network such that data is still able to be exchanged with the platform services system, when the respective satellite ceases to receive communications from the master controller of the one power distribution micro-network.

10. The plurality of power distribution micro-networks as claimed in claim 9, wherein each of the power distribution micro-networks is configured to allow communication between the satellites of the respective power distribution micro-network and the master controller of the respective power distribution micro-network using both a Zigbee protocol and a Dynamic Device Addressing (DDA) protocol.

11. A method for scheduling power allocation within a plurality of power distribution micro-networks, each of the power distribution micro-networks having a master controller configured to communication with a platform services system via cellular transceivers, each of the power distribution micro-networks having a plurality of satellites in a localized mesh network, the master controller having a local area wireless transceiver, each of the plurality of satellites having a local area wireless transceiver, each of the satellites controlling the power allocation to an appliance or a control system, the method comprising: receiving, by the master controller of one of the plurality of power distribution micro-networks, a plurality of power allocation requests, each of the power allocation requests relating to proposed power usage by the appliance to which the respective satellite is coupled, each of the power allocation requests comprising at least a function and a task, the power allocation requests being received via the local area wireless transceiver from the plurality of satellites forming part of the localized mesh network; determining available power resources; determining which of the power allocation requests to accommodate based on the available power resources, a priority level of the request, and an estimate of required power associated with the request, the priority level being determined by a function priority and a task priority corresponding to the function and the task associated with the request; and responding to each of the power allocation requests to be accommodated by sending an approval message or token to each of the satellites from which the accommodated power allocation requests were received, indicating a designated time interval at or during which the requested power is to be allocated, the approval message comprising a resource allocation token defining a validity period corresponding to the designated or time interval during which the respective power allocation request is considered valid to authorize performance of the function of the at least one appliance, wherein any appliance manually activated by a user is immediately granted power, regardless of the priority level of the function and the task for which the appliance is manually activated.

12. The method for scheduling power allocation as claimed in claim 11, further comprising: when one of the satellites within a specific one of the power distribution micro-networks stops receiving communication from the master controller of the respective power distribution micro-network, transferring data, by the satellite, outside of the power distribution micro-network of the respective satellite, and temporarily joining, by the satellite, a neighboring one of the power distribution micro-networks such that data is still able to be exchanged with the platform services system.

13. The method for scheduling power as claimed in claim 12, further comprising: when data is sent from a first one of the power distribution micro-networks via a neighboring one of the power distribution micro-networks to the platform services system, marking, by a listener service of the platform services system, the first power distribution micro-network with a fault state; and keeping a record of the satellites currently in neighboring power distribution micro-networks.

14. The method as claimed in claim 13, further comprising: generating an alert, by the platform services system, when one of the power distribution micro-networks remains in the fault state for more than a predetermined time.

15. The method as claimed in claim 12, further comprising: when the master controller resumes operation after the one satellite stops receiving communication from the master controller of the respective power distribution micro-network, updating, by a listener service of the platform services system, an availability of the master controller to alert services.

Description

BRIEF DESCRIPTION OF DRAWINGS

[0113] Embodiments are described in further detail below, with reference to the accompanying drawings, in which:

[0114] FIG. 1 is an example block diagram of a system according to some embodiments;

[0115] FIG. 2 is a block diagram of an example of the system of FIG. 1;

[0116] FIG. 3 is a block diagram of a power control device according to some embodiments;

[0117] FIG. 4 is a block diagram of a master control unit according to some embodiments;

[0118] FIG. 5 a schematic diagram of a processor of power control device according tom some embodiments;

[0119] FIG. 6 is a schematic diagram of power usage monitoring circuitry, current sensor circuitry, power control circuitry, actuator circuitry and lighting circuitry used in the power control device according to some embodiments;

[0120] FIG. 7A is a schematic diagram of power supply circuitry, infrared transmission circuitry and timing circuitry used in the power control device according to some embodiments;

[0121] FIG. 7B is a schematic diagram of local area wireless transceiver circuitry and programming circuitry used in the power control device according to some embodiments;

[0122] FIG. 8 is a flowchart of a method of operation of the master control unit according to some embodiments;

[0123] FIG. 9 is a flowchart of a method of operation of the power control device according to some embodiments;

[0124] FIG. 10 is a flowchart of an example method of operation of a power control device when controlling power to a pump according to some embodiments; and

[0125] FIG. 11 is an example data format for message transmissions within and external to a local mesh network according to some embodiments.

DESCRIPTION OF EMBODIMENTS

[0126] Embodiments of some systems and devices are described with reference to FIGS. 1 to 4. Embodiments involve the use of localised mesh networks 120 for connected appliances and control systems, primarily for sharing available energy resources. The mesh networks form part of a larger system 100 for mesh-networked power usage control and monitoring. Each mesh network 120 includes at least one master control unit (MCU) 210 that acts as an interface device for external networks and can include up to more than 64,000 (65535) endpoint devices called satellite units (SUs) 215 that act as power control devices for the appliances or control systems.

[0127] Traditionally power/load distribution and management is in the context of power being generated in generating stations and distributed to end consumers. The responsibility of management in this context terminates at a residential or commercial facility. Described embodiments allow the management and distribution of load from this point onwards. Appliances within a household or control systems within a commercial facility can be controlled and managed by satellite units under the direction or supervision of the master control unit.

[0128] Each mesh network is configured and controlled by a master control unit that forms part of the network. The primary function of the governor is the formation and maintenance of the mesh network and handling traffic routing in and out of the network.

[0129] As the network is formed, for example by the ad hoc addition of appliances having satellite units coupled to them, user preferences and control parameters are downloaded and distributed by the MCU 210 to rest of the network. Preferences and setup parameters are managed by the users via a web application and/or App provided by a platform services system 110.

[0130] All major predictive analytics computations are carried out by the platform services system 110. For this purpose and for reporting, usage and behavioural data are periodically collected by the master control unit 210 of each local area mesh networks 120 and posted via a cellular data network 125 to platform services system 110 for analysis and storage.

[0131] Collection and distribution of information from and to the SUs 215, such as predictive results, parameter changes, calibration constants and switch status, are part of the responsibility of the master control unit (MCU) 210. The MCU 210 maintains a cache of this information for the local mesh network 120 to which that MCU 210 is dedicated in case of a platform services system failure and/or network connection failures.

[0132] The primary mode of communication between the MCU 210 and platform services system 110 is via SMDT (Secure Minimal Data Transfer) over a cellular network 125. The MCU 210 is also capable of communication via Ethernet or routing communications via other media, for example by utilising connectivity from local smart devices.

[0133] The MCU 210 is also capable of transporting communications (wrapped in secure data envelopes) from other nearby mesh networks, as described in further detail below, with 35 reference to FIG. 11. The MCU 210 cannot open or access information within the envelope, but it can relay the information on behalf of other mesh networks to and from the platform services system 110.

[0134] The MCU 210 is also the controlling body for all (energy) resource negotiations between satellite units 215 within the one localised mesh network 120 in the event of contention. In the event of failure of the MCU 210, a satellite unit (SU) 215 within the mesh network can assume some of the MCU 210 functions and responsibilities (other than cellular network communication).

[0135] The combination of the MCU 210 and SUs 215 allow the formation the mesh network 120 for appliance power control and monitoring with predictive power management. This provides the ability to create a power distribution micro-network, which offers customers the ability to accurately measure electricity generated and consumed, to remotely control power to appliances/equipment in the network and to configure the network for efficient operation.

[0136] The MCU 210 and SUs 215 record user behaviour, along with load distribution, within a household or business at fixed (configurable) intervals, periodically, for example every 15 minutes, and the platform services system 110 can apply a machine learning algorithm to effectively predict future power demand and make decisions on parameters such as: [0137] Export power to grid when green power is available; [0138] Run specific appliances nominated by the user when green power is available; [0139] Store excess power to battery storage units; and [0140] When to use power from battery or the grid.

[0141] The mesh network 120 components (MCU 210 and SUs 215) are designed to measure 3 phase consumption and, in the case of the MCU 210 also measure local generation of power, for example by a solar cell array or wind or water turbine. The MCU 210 and SUs 215 are preferably encased by a tamper-proof box or housing, with minimal or no interactive features or functions.

[0142] The MCU 210 can support over 64,000 satellite units for monitoring and control, although it is more likely that less than 100 SUs 215 will be paired with a single MCU 210 for most domestically used mesh networks 120. MCU 210 is capable of measuring power consumption with Class 1 accuracy. It is also capable of switching and control functions. This gives users and the system 110 control over every appliance/equipment component within a device area network 120. A predictive power management unit (executing on the platform services system 110) works with this mesh network 120 to form a micro-power distribution network.

[0143] Power Distribution Micro Network: the mesh network 120 forms a local area ZigBee mesh with the MCU 210 as the controller and satellite units 215 as routers. In addition to a standard ZigBee personal area network (“PAN”), the ZigBee implementation for the MCUs 210 has a layer to allow communications to hop to other PANs in nearby mesh networks 120 in case of MCU 210 communication failure to the platform service system 110 in one network 120. The communication packets when carried via foster PANs are wrapped in an encrypted data envelop during transport for additional security and data tracking. This gives the transmitted data and messages from the satellite units 215 the ability to find their way to the platform services system 110 in case of a MCU cellular transceiver failure.

[0144] Measurements: In addition to measuring power usage with Class 0.5 accuracy, MCUs 210 are capable of measuring the following parameters: [0145] Net solar power exported; [0146] Net solar power generated; [0147] Net solar power used; and [0148] Individual measurements from satellite units 215.

[0149] Open API: the platform services system 110 provides an open Representational State Transfer (“REST”) based Application Programming Interface (API) 252 which can be used to utilise and extend the functions of the mesh networks 120 and the platform functionality.

[0150] Over the air updates: Every device within the mesh network 120 is capable of over-the-air updates. This allows the end point satellite units 215 to be updated and reconfigured based on specific profiles and control functions from an MCU 210 or from the platform services system 110 via the MCU 210.

[0151] Lossless compression: All devices within the mesh network 120 are capable to compress and decompress data using a lossless compression algorithm. This enables the MCU 210 and SUs 215 to communicate effectively with fewer data packets and packet losses within device area network 120. The compressed data envelop is then lifted to the server via a Minimum Data Transfer (“MDT”) protocol, as described in PCT/AU2014/000119.

[0152] Independent control: All devices within the mesh network 120 are capable of performing critical control functions in the event of a MCU 210 failure or communication failure. The control and predictive parameters are cached within the individual SUs 215 on a regular basis for this purpose.

[0153] Each SU215 is an endpoint control system within the mesh network which is capable of performing the following functions: [0154] Accurate energy measurement of an appliance to which it is coupled; [0155] Control functions for a wide range of equipment; [0156] Programmable control (via configuration instructions received from the MCU 210); and [0157] Network routing.

[0158] The SU 215 can be embedded into equipment or appliances or it can be a separately connectable device that provides independent remote control functions. The SU 215 includes a number of programmable hardware peripherals to support control functions.

[0159] These peripherals assume a specified role at the time of initial configuration as prescribed by commands sent from the MCU 210. The MCU 210 can re-configure the role and function set of the SU 215 at any given point in time. This feature makes the combination of a plurality of SUs 215 with a MCU 210 in a mesh network 120 a versatile power monitoring and control system.

[0160] The SU 215 accurately monitors and logs the amount of energy used by the appliance or system that it is connected to and is capable of predicting the amount of energy required to finish a task at hand from the current state. This allows power resource management in circumstances where energy efficiency or conservation is desired.

[0161] Within the mesh network, energy resource allocation and management are based on task and task priority. These priorities are initially set by the user and as the control systems gather usage data and provide it to the platform services system 110, the system 100 can learn about the environment of each mesh network 120 and it can re-adjust control parameters and priorities based on usage patterns. SUs 215 send resource allocation requests to the MCU 210 to negotiate power resources based on availability and task priority.

[0162] Resource availability can be based on a number of parameters, such as type of resource (grid/generated (solar/wind)), time of day, tariff, peak load demand schedules etc. A number of external factors can also be considered when resource availability is computed by the MCU. For example, based on the function types requesting for resources with the mesh network 120, the MCU 210 can request external data to be sent to it from the platform services system 110. This could be weather data, for example, in the case of photovoltaic (PV) solar arrays or HVAC systems, or can include usage patterns from historical data or prediction factors based on computed projections.

[0163] The MCU 210 continuously monitors and computes resource availability and allocates available power to SUs 215 based on priorities.

[0164] SUs 215 are profile-based and have a designated function, which is assigned a function type. Each function type has a number of defined tasks. Each task consists of a number of steps. Priorities are assigned to function type and task.

[0165] The table below illustrates an example of function priority and task priority for a heating, ventilation and air conditioning (HVAC) system that draws mains power via an SU 215:

TABLE-US-00001 Function Function Task Task Function Type Priority Task Type Priority Step HVAC 2 2 MaintainSteady User 1 Check Temp Temperature Sensor If Temp < Set Point Is yes, turn on heating/cooling Pre-Heat/Pre- System 3 Check Temp Cool with loss Sensor compensation Is Temp < Set Point If yes, compute time required to heat Request resource allocation Go to Task Maintain Steady Temperature Pre-Hear/Pre- System 5 Calculate loss Cool with based on previous compensation loss history and time of use Adjust set point with loss compensation factor Request excess resource allocation Go to Task -Pre- Heat/Pre-Cool

[0166] Functions and tasks are assigned a priority of 1-5, where 1 represents highest priority and 5 represents lowest priority status. In the above example, the HVAC system is assigned a priority of 2. It has 3 Tasks with priorities of 1, 3 and 5 respectively. Each task has a number of steps.

[0167] In the above example, the HVAC system is assigned a priority of 2 and task ‘Maintain Set Temperature’ is assigned a priority of 1. This task is of type ‘User’ and has a priority of 1. When this task is activated, the MCU 210 will allocate power at the highest priority even though the function is only priority 2. All ‘User’ tasks are considered equivalent to a manual override and get immediate resource allocation. On the other hand, the task ‘Pre-Heat or Pre-Cool’ is a ‘System’ Task and has a priority of 3. This SU 215 will only get resource allocation if there is power available after all function priority 1 and task priority 1 and 2 allocations are complete. Task priority 3 and above are considered green mode operation and are only allocated resources when green power (e.g. energy from renewable resources) is available.

[0168] All SUs 215 are required to send an estimate of resource required and the duration for which it is required to the MCU 210. The MCU 210 in some instances can then push a 20 lower priority Task ahead of a higher priority Task if the quantity and duration of the resource required fits within the computed availability estimates for the requested duration. This can only happen if the higher priority task cannot be completed within the resource availability estimate. This enables the mesh network 120 to effectively utilise available resource with minimal or no waste.

[0169] Any manual intervention or control commands sent via a client computing device 130 by a user take the highest priority. For example, a user can turn a Satellite Unit on/off at any given time via the user interface hosted by the user interface module of the web services 254. The MCU 210 can also turn off devices operating out of control cycles, such as pool pumps, when there is a shortage of available resources.

[0170] The combination of the MCU 210 and SUs 215 allows the mesh network 120 to avoid a single point of failure and also extend the physical range of operation. ZigBee is one preferred base protocol used for communication within the mesh network 120, although other suitable medium-short range wireless communication protocols can be used instead. The mesh network 120 employs a proprietary Envelope Service Protocol over ZigBee to enable secure cross-grid communication in case of failure by a MCU 210. This is described in further detail below with reference to FIG. 11.

[0171] The platform services system 110 consists of a number of hosted services as part of an overall platform system 100 to enable creation and operation of a number of mesh networks 120 in parallel.

[0172] Database services 250 within the platform services system 110 acts as a central repository of all information sent from the MCUs 210 to the platform services system 110. Database services 250 consists of relational objects capable of storing information about each SU 215 within the mesh network 215. This is a shared service and is common to all mesh networks 120 within the overall platform system 100. This allows the prediction engines within learning module 262 access to large sets of data in different geographic locations to make more accurate predictions.

[0173] The listener service 256 is a specialised data transfer service responsible for data collection and transmission to and from all MCUs 210 within the power control system.

[0174] The listener service 256 is equipped with handling and management of SMDT and ESP messages from the MCUs 210 of many respective mesh networks 120 at a very high rate. A number of servers in a farm architecture may be used to perform this service. A desirable design criterion for this service is to handle all data processing transactions within 1 millisecond.

[0175] Web services 254 comprise a number of web applications to manage and interact with the local mesh networks 120. Functions and responsibilities of the web services 254 include the following: [0176] User application portal; [0177] Administration and management portal; [0178] Reporting; [0179] Debugging and operational support applications; and [0180] External data request and collection.

[0181] The platform services system 110 comprises a rich set of APIs 252 for 3rd party applications to interact with the platform system 100. These services are technology agnostic and can be accessed from any programming language and operating system hosting it.

[0182] All platform system services are monitored by the monitoring and recovery service 258. At any given point in time, there are at least two mirrored instances of this service active. If one fails, the mirror recovers the failed service. Although there are multiple monitoring and recovery services 258 active, to avoid contention, only one is allocated the task of monitoring other services within the platform services system 110. By design, this service is not intended to fail and it requires a special shut down procedure.

[0183] Alert services 260 allows a user to set up alert parameters for a particular mesh network 120 that that user controls or is subscribed to (for example because it is established at the user's place of residence and the appliances are owned by that user). In addition to this, there are a number of system level alerts that are also generated as early warning and/or failure notifications. Alert services 260 operate as a separate (virtual or dedicated) server unit as it handles all communication via email, SMS or push notification where applicable.

[0184] Referring particularly to FIGS. 1 and 2, a power control system 100 is described in further detail. The system 100 relies on a platform services system 110, which comprises a plurality of servers to provide various platform services for the system 100.

[0185] Multiple servers will be employed as part of platform services system 110 and such multiple servers may be distributed or co-located. Any of the servers may be executed on physical hardware or may be virtualized. Each such server has at least one processing device and has access to memory that stores executable programme code such that, when the programme code is executed by the at least one processing component, the one or more servers are caused to perform functions or tasks as described herein.

[0186] The system 100 allows multiple client devices 130, such as hand held computing devices (e.g. smart phones, tablets, computing devices or laptops) or desktop client devices, to communicate with the platform services system 110 over a network, such as a public network 135. The public network 135 may include the internet and/or various other publicly accessible networks, including wireless and wired networks.

[0187] System 100 further comprises one or multiple local mesh networks 120 that each communicate with platform services system 110 via a cellular data network 125. If local mesh networks 120 are within sufficient proximity to each other, they may communicate via a wireless local area network protocol, such as ZigBee, for example. Each of the local mesh networks 120 comprises an interface device, which is the master control unit (MCU 210) and at least one power control device configured to control power to an appliance. Each such power control device is a satellite unit (SU 215) as described herein and is effectively slaved to the MCU 210. Each of the SUs 215 acts as a remotely controllable power switch or power control unit dedicated to a particular electrically-powered appliance, plant or equipment. The MCU 210 communicates with the platform services system 110 via a cellular data transceiver and communicates with the SUs in the local area mesh network 120 via a local area transceiver, for example using the ZigBee local area wireless communication protocol.

[0188] One example of how the local mesh network 120 may be arranged is for control of domestic appliances within a household, such as in a rural environment or in an urban or suburban domestic context. The local mesh network 120 may also be of particular use in office environments and in small and large business environments where multiple appliances and/or plant or equipment draw power.

[0189] In the example shown in FIG. 2, the local mesh network 120 as applied to a domestic situation may comprise 1, 2, 3, 4, 5, 7, 8, 9, 10 or more power control devices 215, each communicating with, and being configured and controlled by, one MCU 210. For example, a SU 215 may be used for control of a refrigerator 220, a pool pump 222, washers and/or dryers (laundry apparatus 224), a dishwasher 226, entertainment units 228, such as televisions or home theatre units, remote control devices such as garage door openers 230, heating, ventilation and air conditioning (HVAC) systems 232, water heaters 234 and battery storage units 236. There are a number of different types of appliances and/or equipment, the power to which can be controlled by an SU 215, and each type of appliance or plant or piece of equipment may have a distinct function for which different control paradigms may be desired. In the above list of examples illustrated in FIG. 2, each of the appliances has a different function type. However, the local mesh network 120 may comprise multiple ones of the same type of appliance or equipment and different SUs 215 may therefore may be configured with the same function type.

[0190] Depending on the function type of the appliance or equipment, it may need to be always on, intermittently on, on only on user command or automatically on according to automatic operational settings or parameters. As described herein, the MCU 210 in combination with the SUs 215 allow remote user control of the various appliances within the local mesh network 120 while also allowing selective power consumption and prioritising of certain functions over others, in order to make efficient use of limited (possibly costly) energy resources or make use of energy derived from renewable resources (e.g. a solar panel or a local wind turbine) instead of energy from the power supply grid. The control paradigm of each of the SUs 215 is user configurable via a client device 130 through the web services 254 of platform services system 110.

[0191] Satellite units 215 are shown and described in further detail in relation to FIG. 3. As shown in FIG. 3, each SU 215 comprises a housing 305 that contains a processor 310, a memory 315 and a wireless transceiver 318, which may be carried on a printed circuit board (PCB) contained in the housing 305. The SU 215 has a mains power interface port 352 and an appliance power interface port 354 in order to supply power to the appliance where the SU 215 is physically and electrically interposed between the appliance and the mains power supply. The PCB within the housing 305 contains a current sensing circuit 332, for example including a shunt resistor with a low resistance (e.g. 0.001 ohms) that feeds into a power usage monitor circuit 330 (shown as current/voltage sense circuits in FIG. 6). The output of the current sensor 332 is used by the processor (after amplification by the power usage monitor 330) to determine the amount of power being supplied to the appliance over time. The processor 310 stores the power usage data in a part of memory 315, which may be random access memory (RAM) or other volatile or non-volatile memory. The stored power usage data is provided periodically to the MCU 210 for uploading to platform services system 110 via the listener service 256 and the power usage data is ultimately stored by database services 250.

[0192] The processor 310 controls a switch 340 to interrupt supply of power along a mains supply line 342 within the SU 215. The switch 340 may comprise a Triac or relay or a combination of switching elements, for example.

[0193] The SU 215 comprises a push button 370 that, when pressed, provides a direct input to the processor 310 in order to initiate wireless communication pairing of the SU 215 with the MCU 210 (during configuration of local mesh network 120). The push button 370 may also be used, if held down for a longer period for example, to trigger the processor 310 to run a self-diagnostic check and send its self-diagnostic information to the MCU 210.

[0194] The SU 215 may further include an infrared port 360 in order to allow line of sight communication with an appliance that is hard-wired into a household or business electrical system, such as a split system air-conditioner. In this instance, the infrared port 360 functions to transmit control signals to such an appliance, including on/off control signals, and setting reconfiguration signals, such as to reset a desired temperature in a room, for example.

[0195] In embodiments employing an infrared (or other wireless line of site) communication port 360, the SU 215 may also comprise a temperature sensor 365 or other local environment sensor in order to provide data in place of power usage data. In the example where the appliance to be controlled by the SU 215 is a split system air-conditioner, the SU 215 does not in fact supply the mains power to the appliance via the interface 354 and must rely on commands via the infrared port 360. Thus, in order to determine how much power is used by the split system air-conditioner, the user must provide certain information regarding that system via a client device 130, such as a manufacturer and model number, to allow platform services system 110 to look up the power rating of that system. In this way, the sensed temperature data from temperature sensor 365, together with timing and control data known by the processor 310 can be stored in the data memory 322 and uploaded to the platform services system 110 via the MCU 210 to allow power usage to be calculated as a function of temperature change over time and power rating of the system.

[0196] Each SU 215 has a portion of memory 315 that is non-volatile in order to store the program code 320 which includes the ZigBee software stack (or another communication protocol), plus software to implement a method 900 on a control loop such as is illustrated in FIG. 9. Additionally, such non-volatile memory stores function and control parameters 324 that are received from MCU 210 and define the function type according to which the SU 215 is to control the appliance, together with priority and task information according to which the appliance is to be controlled. The program code 320 is also executable in order to perform the dynamic device addressing technique as described herein. Further, the data memory 322 or other parts of memory 315 may store a resource allocation token that authorises the SU 215 to switch power to the appliance for a specified time.

[0197] Referring now to FIG. 4, the MCU 210 is described in further detail. The MCU 210 has a housing 405 to contain a PCB (not shown) that carries the electronic circuitry of the MCU 210. The MCU 210 has a processor 410 and a memory 415 that is accessible to the processor 410. The memory 415 comprises stored program code 420, data memory 422 and function and control parameters 424. The MCU 210 further comprises a communication interface 212 that includes a local area wireless transceiver 418 and a cellular data transceiver 416, plus a subscriber identity module (SIM) 417 for the cellular data transceiver 416.

[0198] The MCU 210 further comprises a power supply 434 to supply power as appropriate to the components of MCU 210, with that power being derived from mains power 422. MCU 210 further comprises a current sensor 432, which may be in the form of a three phase clamp, for example including a current transformer. The current sensor 432 provides output signals to a current sensor circuit 430, which supplies output signals to processor 410 indicative of the sensed current in the mains power supply line 422, in order to monitor power supplied from the power supply grid to the household or business. Where the household or business has the capability to supply energy back to the grid, for example due to a solar power generation system or a wind power generation system, the MCU 210 may further comprise a current sensor (and associated circuitry) to measure the amount of power being supplied back to the grid. In some situations, the MCU 210 may comprise battery storage units 236 to store locally generated energy, the power of which may be monitored and consumed locally rather than being returned to the grid.

[0199] The program code 420 comprises executable code to allow the MCU 210 to perform the functions described herein, including communicating with the platform services system 110 and the SUs 215, as well as transmitting configuration commands to the SUs 215 and transmitting to the SUs 215 control commands received from a user via the platform services system 110, for example to remotely turn on or off one or more of the appliances in the local mesh network 120. The function and control parameters 424 dictate the behaviour of the MCU 210 and, together with the program code 420, are used to cause the MCU 210 to execute the method 800 illustrated by the control loop shown and described in relation to FIG. 8.

[0200] FIG. 5 is a schematic diagram of a processor 310 of an SU 215. The processor 310 is carried by a PCB (not shown) and comprises memory 315 internally of the processor chip. In the example shown, the processor 310 may be a microcontroller such as the ATMEGA2564RFR2 chip from Atmel. The processor 410 of the MCU 210 may comprise a microcontroller similar to the processor 310 (but possibly with more memory or processing capability) or similar to that described and shown in PCT/AU2014/000119, for example.

[0201] FIG. 6 illustrates example circuits that interface with the processor 310, such as an AC power control circuit (switch 340), the shunt resistor of the current sensor 332, the current and voltage sensing circuits of the power usage monitor 330, the push button circuit 370, plus circuits 372 comprising red and blue status LEDs. The status LEDs may be used to indicate that the SU 215 is functioning normally, is in the process of pairing or is not functioning properly or is not in communication with the MCU 210, for example.

[0202] FIG. 7A illustrates an example power supply circuit 375 for supplying power to the components of the SU 215 from the mains power socket when the SU 215 is appropriately coupled thereto. FIG. 7A also shows example timing circuits 377 and 35 circuitry for infrared transmitter 360. FIG. 7B includes example circuitry for the local area wireless transceiver 318 and for testing and programming interface circuitry (JTAG programming 380 and SPI programming 382).

[0203] Referring also now to FIG. 8, a control method 800 for each MCU 210 is described in further detail. At 802, the control loop is entered, following which the MCU 210 checks at 805 whether a parameter update interval has expired. This interval may be in the order of 15, 30 or 60 minutes, for example. If the parameter interval has expired, then at 807, the MCU 210 sends control parameters collected from the SUs 215 to the platform services system 110. At 810, the MCU 210 receives and stores any changes in the predicted parameters calculated by the platform services system 110. At 812, the MCU 210 receives and stores control change requests from platform services system 110.

[0204] After 805 or 812, the MCU checks at 815 whether any control flags have been set by platform services system 110 in the commands received therefrom. If at 817 there has been a parameter change (e.g. indicated by a control flag), then the MCU 210 checks the SU list and the current status of the SUs 215 on that list at 820 and then sends appropriate commands to SUs 215 at 822 for only those SUs that have had their parameters changed.

[0205] At 825, the MCU 210 checks whether a resource reallocation request was received and, if so, then at 827, the MCU 210 checks the SU list and the current status of SUs 215. Then at 830, the MCU requests from each of the SUs 215 the time determined by that SU to complete performance of a task that is currently underway (operational). At 832, the MCU checks the priority of each of the tasks being executed by SUs 215 and determines a reallocation of energy resources among the SUs to complete the tasks according to the task and function priorities for the SUs 215 in the tasks that they are performing. At 835, the MCU 210 generates and transmits resource allocation tokens to those SUs that are to be allocated resources (i.e. power) according to the resource requests. Each resource allocation token specifies a start and end time that together define a validity period of the token. Outside of that validity period, the token is not usable and the SU 215 will need to make a further resource allocation request if it has not been able to complete the task within the validity period of that token.

[0206] At 837, the MCU 210 checks whether a SU update interval has expired and, if so, then at 840, the MCU 210 determines whether a status update is required. If a status update is required, then a command is sent from the MCU 210 to one or more of the SUs at 842, requesting a message back from the SUs 215 indicating their operational status. At 845, the updates from the SUs 215 regarding their respective statuses are processed by MCU 210.

[0207] At 847, the MCU 210 processes any resource allocation conflicts or contentions, determining which resource allocation request can be satisfied, if not all of them can be satisfied, and then an update is sent to the SUs 215 that have made resource allocation requests, either by transmission of a token or denial of a token at 850.

[0208] At 852, the MCU 210 conducts a system wide health check. At 855, the MCU 210 checks for alert states and, if an alert report is determined to be required at 857, then at 860 the MCU 210 generates and sends an alert notification to the platform services system 110.

[0209] At 862, the MCU 210 computes the overall resource utilisation for the mesh network 120 and then determines at 865 battery storage parameters, such as battery storage capacity, if battery storage is provided within the network. If at 867 MCU 210 determines that renewable energy (sometimes called green power) has been generated and is available for use, then at 870, the MCU 210 sends control updates to all SUs 215 in the SU list that control appliances that rely on renewable energy for operation, indicating that they can turn on. At 872, the MCU 210 computes excess renewable energy availability and, if it is determined at 875 that there is such excess availability, then the excess renewable energy is provided to battery storage at 877.

[0210] Referring now to FIG. 9, a method 900 of operation of one of the SUs 215 is described in further detail. If at 905 the SU 215 is determined not to be acting as a power monitoring and control system, but is instead acting simply as a remotely controlled switching device (e.g. according to user input via a client device 130, communicated through to the SU 215 via the platform services system 110 and MCU 210), then the SU 215 simply waits for a command at 907. This operational state (acting as a switching device or a control system) is user configurable. Otherwise, then the SU 215 loads profile operational parameters at 910 and begins running a control loop at 912. As part of that control loop, the SU 215 checks the validity of predictive parameters stored in 324. If at 917 the SU 215 determines that the stored predictive parameters have expired (i.e. not been updated more recently than a predetermined time), then at 920, the SU 215 sends a message to the MCU 210 to fetch predictive parameters from the platform services system 110. The SU 215 then computes usage prediction for the next programmed timeslot of the SU 215 at 922 based on predictive parameters received from the platform services system 110 and stored in parameter storage 324 within memory 315. For example, depending on the time of day, a hot water system can be predicted to be required for domestic use at certain times in the morning and potentially also at certain times in the evening, but are unlikely to be required at certain times during the day or the middle of the night Similar usage based predictions (example generated by learning module 262 of the platform services system 110) can be determined for HVAC systems.

[0211] At 925, the SU 215 checks whether a resource utilisation token is stored in RAM and whether it is valid. If it is not stored or is not valid, then at 927, the SU 215 computes a usage prediction for the appliance to which it is controllably coupled for the next programmed timeslot and then at 930 the SU 215 generates and sends a request for a resource allocation/utilization token from the MCU 210 according to the predicted power requirements of the appliance to complete a predicted task. In some instances, such prediction may involve calculations based on multiple inputs that may include environmental parameters. For example, if an SU 215 is configured to control a cooling function of an HVAC system, then the SU 215 may take a temperature sensor reading using temperature sensor 365 and determine a difference in temperature between the current temperature and the desired temperature set point and may check historical data indicating for that HVAC system how much energy was used to cool the space in which it is positioned by one degree or a fraction of a degree, and then determine how much energy is predicted to be required for the present cooling task. Another input to this calculation may also be a time period over which the cooling is desired to be performed, which may dictate a power consumption level of the HVAC system and may therefore affect the overall predicted power consumption for the task.

[0212] At 932, the SU 215 checks for operational flag changes and then at 935 checks real time. Then at 937, the SU 215 checks whether a relay switch flag has been set and, if yes, then at 940 the SU 215 switches on or off power to the appliance via switch 340.

[0213] Alternatively, if the SU 215 controls the appliance by control signals transmitted from the infrared port 360 at 942, then these are used to generate and send appropriate control signals at 945, rather than using a switch 340.

[0214] At 947, the SU 215 reads and records control parameters, such as consumed power, current temperature and other operational and/or environmental parameters. These data are stored in memory 324 as they are accumulated over time and then they are sent to the MCU 210 periodically. The period at which the stored power usage data and other measured or determined control, temperature or environmental data are sent to the MCU 210 may coincide with the time taken to perform the control loop initiated at 912 or may be a less frequent time interval, for example.

[0215] A method 1000 of controlling a pump is described in further detail, as one example of an appliance that an SU 215 can be used to control. In this example, the pool pump is an example of a type of appliance that can often be automatically turning on more than is necessary and may run during peak energy consumption times unnecessarily. The function type for this type of appliance would carry with it a low priority and it would generally be turned on within mesh network 120 only when low tariff rates apply for energy consumption or when excess renewable energy had been generated, for example.

[0216] At 1005, the SU 215 enters a control loop and initially determine whether the appliance (in this case, the pump) is active at 1007. If the pump is active, then at 1010, the SU 215 checks the recent usage history of the pump, either by checking locally stored data or requesting such data from the MCU 210. At 1012, the SU 215 recomputes the daily active time based on the previous recorded activity. At 1015, the SU 215 checks whether a valid resource allocation token is stored in memory 315. If no token is stored or it is invalid, then at 1017, the SU 215 computes the predicted usage for the appliance for the next programmed timeslot and then at 1020, the SU 215 generates and sends a resource allocation token request to the MCU 210.

[0217] At 1022, the SU 215 determines whether renewable energy is available, and if so, then at 1025, the pump is turned on. Otherwise, the SU 215 computes at 1027 the required time to run for the day and the available time of the day before midnight. If at 1030, the SU 215 determines that the required time is less than the available time and there is a valid resource token, then at 1032, the pump is turned on.

[0218] However, if the required time is greater than the available time or the resource token is not valid for the required time, then the SU 215 checks at 1035 whether the pump is operating outside of the allowed parameters and, if so, turns off the pump at 1037. At 1040, the SU 215 checks control flag updates from the MCU 210. If a remote control command has been received via a client device 130, for example, then this may cause a control flag update to be sent from the MCU 210 to the SU 215 in order to require that the pump turn on and off, for example. Following 1040, the loop 1005 is repeated.

[0219] In order to optimise energy usage, SUs 215 collect energy usage data periodically, at fixed intervals, such as every 1, 2, 3, 4, 5, 10, 15 or 20 seconds or longer time periods. This includes data concerning parameters such as power usage, duration of use, power factor and time of use. These parameters are accumulated and sent to a central server for processing. In order to assist the SUs 215 to work effectively, the SUs 215 require predictive parameters to be computed externally and sent to the SUs 215. The key for success here is to be able to communicate accumulated parameters and receive predictive parameters from the learning module 262 within the platform services system 110.

[0220] Due to the relatively small size of the on-board processor 310, the predictive analysis of energy resource (power) usage for an appliance to which the SU 215 is connected cannot be computed locally in the SU 215. Therefore, the data that are collected at the SU 215 are sent to the learning module 262 within the platform services system 110 for analysis. All communication to the platform services system 110 from the SUs 215 is handled by the MCU 210, which maintains the mesh network 120 within the household.

[0221] The SUs 215 use ZigBee as its communication protocol. ZigBee is a high-level communication protocol that supports point-to-point and mesh networks. ZigBee's low power consumption limits the communication distance range from 10-100 meters and it requires line-of-sight for achieving the upper end of the range.

[0222] Due to the size limitation and local interference that is inherent to the hardware due having a switch-mode power supply, the communication range of the SU 215 is likely to be around 20 meters. In many cases, the MCU 210 may be located more than 20 meters from at least one of the SUs 215. This poses a potential problem in reliably collecting data in a timely manner. The problem may be addressed by increasing the number of SU 215 in the network and having it within 20 meters of each other and the MCU 210. Due to the nature of ZigBee mesh, data packets from an SU 215 to the MCU 210 or from the MCU 210 to the SU 215 will often be routed through the nearest nodes (i.e. other SUs 215) to its destination.

[0223] Although this architecture was intended to have the data packets arrive at the destination address without losses, it was found that this was not always the case in real word testing conducted in multiple sites. Some packet losses were seen and information was not received in a timely manner. ZigBee mesh architecture also has one single point of failure which is the co-ordinator, which in this case is the MCU 210.

[0224] A Dynamic Device Addressing (DDA) protocol was created to overcome these issues and provide a robust communication platform. The DDA protocol also allows information packets to be transmitted through foster co-ordinates (MCU 210) when the parent governor cannot be reached. The DDA protocol is not part of the ZigBee specification. The DDA protocol allows the mesh network 120 to overcome some of the limitations of ZigBee.

[0225] There are two widely used addressing schemes available today, transmission control protocol (TCP) and user datagram protocol (UDP). TCP is more reliable as it is a connection-oriented protocol. When a file or message is sent, the protocol ensures delivery unless the connection fails. UDP is a connectionless protocol. Messages are just broadcasted. The sender does not rely on message receipt communication, so no delivery receipt is sent back.

[0226] TCP is resource-intensive and it requires a dedicated hardware and software stack to handle TCP traffic to endpoints. It also requires other hardware, such as routers to handle traffic routing between other devices on the network.

[0227] The DDA scheme is described herein as a way of addressing devices on a connectionless layer with a very high degree of reliability. It requires no specialised hardware implementation; it is a software stack with a small footprint, allowing it to be loaded onto most embedded processing devices.

[0228] The processor 310 of the SUs 215 have a relatively sized small Random Access Memory (RAM) and can only hold a small amount of accumulated data. Each SU 210 periodically transfers this data to database services 250 on platform services system 110 via the MCU 210 for storage and analysis. Once this data is received by the platform services system 110 and an acceptance receipt is received by the SU 215 via the MCU 210, the SU 215 will clear its RAM and start the next cycle of data accumulation and storage. Therefore, in order to prevent data loss and to minimise the risk of RAM overflow, it is desirable to have a robust communication protocol.

[0229] SUs 215 powering large commercial appliances will run out of RAM in a much shorter amount of time than those powering smaller appliances, due to accumulation of large numbers for power values. RAM is a shared space used for normal operation by the processor 310 as well as data storage. A RAM overflow can result in unexpected behaviours outside of normal operational parameters and in most cases reboots. In commercial operations, it is desirable to avoid any crash or reboot so that business as usual is not interrupted and safety issues arising from power disruptions can be minimised or avoided.

[0230] The DDA protocol is designed to ensure the power usage and other data 322 stored in the RAM is off-loaded reliably and in a timely manner and to achieve zero data loss.

[0231] According to the protocol, each SU 215 sends out a capacity transfer broadcast to nearby nodes (other SUs 215). SUs 215 in the network with more than half their data memory 322 capacity free for storage send back a capacity transfer token. Upon receipt of the token, the SU 215 with the lower available capacity can transfer some or all of its data to the SU 215 that sent the token. Data from SUs 215 stored on other nodes are known as foster data and the SU 215 which stores the data for other SUs 215 is known as a foster node. The foster node becomes responsible for transferring the foster data all the way to database services 250 on platform services system 110 via the MCU 210 for storage and analysis.

[0232] An aspect of the DDA protocol is to ensure appliance-related data can only be accessed by authorised users on the mesh network 120. In other words, a user should only be able to access devices on their own mesh network 120. For this security reason, ZigBee does not allow cross network communication and devices can only communicate within a single Personal Area Network (PAN). However, this poses the risk of a single point of failure in the event of a MCU 210 failure. The DDA protocol overcomes this problem by allowing SUs 215 to temporarily communicate outside of its home mesh network 120 if it stops receiving acknowledgements (or other feedback) from the MCU 210 for that mesh network 120. In this situation, the SU 215 can effectively join another network nearby to establish contact with the platform services system 110 and 35 ensure data flow. Any network that hosts SUs 215 from another network is known as a foster network. The mesh network 120 from which the foster data was received is called the parent network.

[0233] The DDA protocol also facilitates the SUs 215 to leave a foster network and re-join the parent network when the parent network again becomes available. When foster data is received by the listener service 256 on platform service system 110, listener service 256 (or alternatively alert services 260) marks the parent network with a fault state. The alert services 260 may also maintain a list of SUs 215 in foster networks. In addition to this, a fault state alert may also be generated by alert services 260 if a mesh network 120 remains in a fault state more than a predetermined time, such as 30 minutes for example. When a MCU 210 resumes operation, the direct receipt of messages from that MCU 210 causes listener service 256 to report the availability of that MCU 210 to the alert services 260. The alert services 260 marks that MCU 210 for review and sends all foster SUs 215 belonging to this particular network a notification to leave the foster network and resume connection to the parent network. The alert services 260 only resets the fault flag of the parent network once data from SUs 215 starts arriving from its parent MCU 210.

[0234] These features make the SUs 215 with DDA capable of securely hopping between mesh networks 120 if necessary and then resume communicating with the parent network without data loss.

[0235] The data envelope for the DDA consists of 3 sections as indicated in FIG. 11:

[0236] Single Byte Header

[0237] Bit Description

[0238] 0 Foster data

[0239] 1 Reserved

[0240] 7-2 Data ID

[0241] Device Identification Number

[0242] Payload

[0243] A special encryption key may be employed when a SU 215 is operating via a foster network. This key is made from a combination of a ZigBee network key and the MAC address of the parent MCU 210. This ensures that the foster network cannot decrypt the data. When the foster data arrives at the listener services 256, the listener services 256 identifies the data to be for a different network and will use the MAC address of the parent network to decrypt the data. The listener services 256 can access database services 250 to retrieve the MAC addresses of all MCUs 210 in the system 100. The MAC address of MCU 210 is sent to the listener services 256 when the mesh network 120 is created for the first time. The MAC address is unique to every MCU 210.

[0244] The foster data also includes a device identification number (DIN) as part of its payload. The DIN is encrypted only with the network key. The server uses the DIN to retrieve the MAC address of the parent MCU 210 from database services 250 to decrypt the payload.

[0245] It will be appreciated by persons skilled in the art that numerous variations and/or modifications may be made to the above-described embodiments, without departing from the broad general scope of the present disclosure. The present embodiments are, therefore, to be considered in all respects as illustrative and not restrictive.