Artificial intelligence-based energy storage unit management

Abstract

An example system may include an energy storage unit and various processors configured to communicate with components of the energy storage unit. An example system may determine a consumption model that predicts future consumption of a node based on local power consumption of the node. The system may receive weather forecast data for the node and determine a power production model for the node that predicts future power production using the weather forecast data. The system may calculate a predicted power difference using the consumption model, the production model, and the current environment of the node. The system may perform automated operations using the predicted power difference, such as charging or discharging an energy storage unit or controlling one or more electrical loads.

Description

TECHNICAL FIELD

[0001] The present disclosure relates to managing local energy storage units based on data specific to the local energy storage unit. BACKGROUND

[0002] Typically, excess or backup power, such as that generated by solar panels or wind turbines, is stored in a chemical reservoir, such as a large chemical battery. More recently, other local power storage solutions include gravitational or kinetic energy storage, such as flywheels. Unfortunately, because they are typically located locally to a residential area, customers, especially large utility organizations, cannot take advantage of these systems, and thus cannot actively manage them, much less manage them on a per-battery basis.

[0003] Furthermore, the use of renewable energy, especially renewable energy stored in batteries, is passively controlled. For example, when solar production is high and power consumption is low, the batteries are charged until the remaining power production is injected into the grid. Similarly, when solar production is low, the batteries are discharged. Unfortunately, because these systems are passive, they cannot predict future demand, and can increase systemic problems for the grid. SUMMARY

[0004] In some aspects, the technology described herein relates to a computer-implemented method comprising: receiving, by one or more processors, power consumption data of one or more nodes, the one or more nodes comprising one or more meters for determining a set of power consumption data, each of the one or more nodes comprising an energy storage unit comprising one or more of a mechanical battery and a chemical battery; determining, by the one or more processors, a subset of the set of power consumption data that does not include power consumption data of one or more controllable loads for determining the set of power consumption data; training, by the one or more processors, a first machine learning model to predict future power consumption based on the subset of the set of power consumption data; receiving, by the one or more processors, environmental data of the one or more nodes, the environmental data comprising local weather data and weather forecast data of the one or more nodes; receiving, by the one or more processors, local power production data of the one or more nodes, the local power production data determined for one or more solar panels electrically coupled to the energy storage unit; training, by the one or more processors, a second machine learning model using the local power production data and the local weather data; calculating, by the one or more processors, a predicted power difference of the one or more nodes at a future time based on the weather forecast data, the first machine learning model, and the second machine learning model; controlling, by the one or more processors, a mode of the one or more nodes based on the predicted power difference at the future time, the mode defining whether the one or more nodes perform one or more of receiving, storing, or outputting electric power; and instructing, by the one or more processors, power consumption of one or more controllable loads of the one or more nodes based on the predicted power difference at the future time.

[0005] In some aspects, the technology described herein relates to a computer-implemented method comprising: determining, by one or more processors, a consumption model of a node, the consumption model predicting future power consumption of the node; receiving, by the one or more processors, environmental data of the node, the environmental data comprising weather forecast data of the node; determining, by the one or more processors, a production model of the node, the production model predicting future power production of the node using the weather forecast data of the node; calculating, by the one or more processors, a predicted power difference of the node at a future time based on the predicted power consumption, the predicted power production, and the environmental data of the node; and performing, by the one or more processors, one or more automated operations using the predicted power difference.

[0006] In some aspects, the technology described herein relates to a computer-implemented method, wherein: the consumption model of the node comprises a first machine learning model trained based on power consumption data of one or more loads electrically coupled to an energy storage unit of the node.

[0007] In some aspects, the technology described herein relates to a computer-implemented method further comprising: receiving, by one or more processors, power consumption data for a node, the node comprising one or more meters used to determine a set of power consumption data; determining, by one or more processors, a baseline power consumption for the node using a subset of the set of power consumption data; and training, by one or more processors, a first machine learning model to predict future power consumption based on the subset of the set of power consumption data.

[0008] In some aspects, the technology described herein relates to a computer-implemented method wherein: the subset of power consumption data does not include one or more controllable loads from which the set of power consumption data is determined.

[0009] In some aspects, the technology described herein relates to a computer-implemented method wherein: the environmental data comprises local weather data for the node received from a local power station, the local weather data informing one or more of a consumption model and a production model for the node.

[0010] In some aspects, the technology described herein relates to a computer-implemented method further comprising: receiving, by one or more processors, local power production data for the node; and training, by one or more processors, a second machine learning model using the local power production data and the local weather data, the production model comprising the second machine learning model.

[0011] In some aspects, the technology described herein relates to a computer-implemented method wherein: the production model comprises a second machine learning model trained using power production data and environmental data for one or more second nodes, the one or more second nodes having one or more attributes in common with the node.

[0012] In some aspects, the technology described herein relates to a computer-implemented method further comprising: aggregating, by one or more processors, predicted power differences for a plurality of nodes, the predicted power differences comprising the calculated power difference for the node; generating, by one or more processors, one or more analyses based on the predicted power differences for the plurality of nodes; and providing, by one or more processors, one or more graphical user interfaces graphically illustrating the one or more analyses.

[0013] In some aspects, the technology described herein relates to a computer-implemented method wherein performing one or more automated operations using the predicted power difference comprises: controlling, by one or more processors, a mode of the node based on the predicted power difference for a future time, the mode defining whether the node performs one or more of receiving, storing, or outputting electrical power.

[0014] In some aspects, the technology described herein relates to a computer-implemented method, wherein performing one or more automated operations using the predicted power difference comprises instructing, by the one or more processors, one or more controllable loads of the node to consume power based on the predicted power difference.

[0015] In some aspects, the technology described herein relates to a system comprising: an energy storage unit comprising: a battery that mechanically or chemically stores energy; an inverter coupled with the battery and converts direct current from the battery to alternating current; and a controller communicatively coupled with the inverter, the controller controlling one or more functions of the battery; and one or more processors executing instructions that cause the one or more processors to perform operations comprising: determining a consumption model of a node, the consumption model predicting future power consumption of the node; receiving environmental data of the node, the environmental data comprising weather forecast data of the node; determining a production model of the node, the production model predicting future power production of the node using the weather forecast data of the node; calculating a predicted power difference of the node at a future time based on the predicted power consumption, the predicted power production, and the environmental data of the node; and performing one or more automated operations using the predicted power difference.

[0016] In some aspects, the technology described herein relates to a system, wherein: the consumption model of the node comprises a first machine learning model trained based on power consumption data of one or more loads electrically coupled with an energy storage unit of the node.

[0017] In some aspects, the technology described herein relates to a system, wherein the operations further comprise: receiving power consumption data of the node, the node comprising one or more meters used to determine a set of power consumption data; determining a baseline power consumption of the node using a subset of the set of power consumption data; and training the first machine learning model to predict future power consumption based on the subset of the set of power consumption data.

[0018] In some aspects, the technology described herein relates to a system, wherein: the subset of power consumption data does not include one or more controllable loads from which the power consumption data is determined.

[0019] In some aspects, the technology described herein relates to a system, wherein: the environmental data comprises local weather data of the node received from a local power station, the local weather data informing one or more of the consumption model and the production model of the node.

[0020] In some aspects, the technology described herein relates to a system, wherein the operations further comprise: receiving local power production data for the node; and training a second machine learning model using the local power production data and the local weather data, the production model comprising the second machine learning model.

[0021] In some aspects, the technology described herein relates to a system, wherein the operations further comprise: aggregating predicted power differences for a plurality of nodes, the predicted power differences comprising the computed power difference for the node; generating one or more analyses based on the predicted power differences for the plurality of nodes; and providing one or more graphical user interfaces that graphically illustrate the one or more analyses.

[0022] In some aspects, the technology described herein relates to a system, wherein performing one or more automated operations using the predicted power difference comprises: controlling a mode of the node based on the predicted power difference for the future time, the mode defining whether the node performs one or more of receiving, storing, or outputting electrical power.

[0023] In some aspects, the technology described herein relates to a system, wherein performing one or more automated operations using the predicted power difference comprises: indicating power consumption of one or more controllable loads of the node based on the predicted power difference.

[0024] Other implementations of one or more of these aspects or other aspects include corresponding systems, apparatus, and computer programs, configured to perform the various actions and / or store the various data described in association with these aspects. These and other implementations, e.g., various data structures, are encoded on tangible computer storage devices. In some cases, many of the additional features discussed in connection with the various implementations can be included in these and other implementations. It will be appreciated that the language used in the specification is principally for the purpose of readability and guidance, and is not intended to limit the scope of the subject matter disclosed herein. BRIEF DESCRIPTION OF DRAWINGS

[0025] The disclosure is illustrated in the accompanying drawings through an example and not in a limiting manner, in which like reference numerals are used to refer to like elements.

[0026] Figure 1 A block diagram of an energy-as-a-service platform (EaaS) is shown.

[0027] Figure 2 A block diagram showing example components of a utility server, node(s), and EaaS manager and interactions therebetween is shown.

[0028] Figure 3A and Figure 3B A perspective view of an example energy storage unit assembly is shown.

[0029] Figure 4A A flowchart of an example method of artificial intelligence-based energy storage unit management is shown.

[0030] Figure 4B A flowchart of an example method for determining a production model for a node is shown.

[0031] Figures 5A to 5E An example mobile graphical user interface showing energy usage or predictions for one or more nodes is shown.

[0032] Figure 6 An example mobile graphical user interface showing node data is shown.

[0033] Figure 7 An example mobile graphical user interface showing node patterns is shown.

[0034] Figures 8A to 8D A graphical user interface showing power consumption, production, and storage for one or more nodes is shown.

[0035] Figure 9 A graphical user interface showing an example graph of an analysis comparing actual and predicted power production is shown. DETAILED DESCRIPTION

[0036] This description includes several improvements over prior art solutions, such as those described with reference to the background. These systems and methods utilize artificial intelligence to manage energy storage units and other devices, for example at the local device level, while allowing for system-wide control and analysis.

[0037] In some embodiments, one, two, or more energy storage units (ESUs) can be installed at a residence to provide backup power in the event of a power outage, to store power generated using a residential solar panel, or to offset unevenness in power production and usage (e.g., electrical storage at a residence can be controlled to address unevenness at the residence, near the residence, or in a region of the power grid). For example, an ESU can include one or more mechanical or chemical batteries. Energy storage units can be buried next to a power distribution panel, or placed in an off-site building outside the residence, in a garage or equipment room, or stored off-site.

[0038] In some embodiments, multiple energy storage units can be coupled together to scale energy backup at a larger facility (e.g., a business) or power company. For example, many energy storage units can be placed in a facility, whether buried underground or above ground, for use by the facility or power supplier. The multiple energy storage units can include or be coupled to an ESU controller or control unit that is communicably linked to each other or to a central server to control the storage and distribution of stored energy (e.g., by controlling the rotational frequency of the flywheels to keep various flywheels at an efficient speed).

[0039] In some embodiments, the ESU can be based on flywheels, chemical batteries, supercapacitors, etc., as described in further detail with reference to the figures herein.

[0040] The technology described herein uses local data to predict local power production and consumption over time, which can be used to control energy consumption, production, or storage of, for example, local mechanical or chemical batteries. For example, local predictions of data consumption and production can be used to set the mode of an energy storage unit, allowing for a target state of charge to be reached at a future point in time, to meet future demands, such as energy backup during a storm. These features can also be used to achieve power balancing across the grid and over different time periods.

[0041] In some embodiments, the models and features described herein provide for AI-powered integration with various home devices (e.g., EVs, smart thermostats, or appliances). Using the integration, the technology can generate energy usage predictions and / or schedule usage times for these devices.

[0042] The technology can also determine power production predictions for a location based on weather conditions at that location and power production (e.g., solar power generation) at that location. Based on the predicted power consumption and predicted power production, the technology can control local power production, consumption, or storage devices to achieve a target, such as maintaining a target state of charge of a battery at a future point in time or balancing power on the grid.

[0043] The technology helps to balance the load of a virtual power plant to optimize energy production and consumption. Machine learning algorithms can take into account factors such as energy demand, solar production, and availability of energy storage. This can help to ensure that energy is delivered where and when it is most needed, and to avoid system overloads. As a result, the technology can be used to improve grid stability in a virtual power plant configuration. Machine learning algorithms can analyze data on energy supply and demand, and adjust the power output of ESUs or flywheels and solar panels to maintain a stable grid frequency. This can help to prevent power outages and other energy supply disruptions.

[0044] In some embodiments, the technology can use these predictions and patterns to help a virtual power plant (e.g., composed of multiple nodes 140 or energy storage units) dynamically adjust energy prices based on energy demand and supply. Machine learning algorithms can analyze real-time data of energy usage and production to determine the optimal pricing strategy. This helps balance the demand and supply of energy, ensuring that energy is used efficiently. Thus, the technology can be used to automate energy trading in a virtual power plant. Machine learning algorithms can analyze real-time market data and make predictions on energy prices. This can help the system maximize cost-effectiveness by buying energy when prices are low and selling energy when prices are high.

[0045] The technology makes weather and energy predictions and allows individual users or power suppliers to command and control one or more nodes 140 (e.g., energy production and storage devices) at a residence or virtual power plant to operate differently. For example, the technology can transform a battery mode priority to self-consumption to curtail peak energy production from a linked solar array. Similarly, a mode can be changed based on predicted bad weather or another future energy demand. Thus, one or more (e.g., hundreds or thousands) of local devices can be controlled to store energy, feed power back into the grid, or perform other operations.

[0046] The technology described herein can provide monitoring, analysis, troubleshooting, and / or alerts at the local, individual (e.g., single ESU or flywheel) level and / or across an end-to-end network or energy ecosystem of single, multiple, clustered, or energy storage units. The technology can provide second-by-second monitoring and alerts, with faults being categorized and automatically resolved where possible, and faults being ranked by severity (e.g., alpha, bravo, charlie, delta, echo, etc.). Where the technology determines that a fault requires action that cannot be automatically resolved locally, it can automatically digitally trigger a human or other external response using firmware on the local device (e.g., through firmware running on a controller of an ESU), and the trigger message can include level / severity information. Because faults can be automatically identified, response times are shortened, uptime is improved, and safety is improved.

[0047] The technology allows for rapid, continuous monitoring of local hardware (e.g., flywheels or batteries), which can be addressed, analyzed, and / or categorized at the individual level and / or across multiple devices. For example, the system and method can determine the generation, usage, and storage of each ESU (e.g., at a particular house or site) or cluster of ESUs (e.g., a group of flywheels at one or more locations), and possibly even down to the circuit level. This can be performed using the technology described in further detail below.

[0048] As data is sampled from various sources and / or sensors at the device, the controller or other computing device can perform the following operations to perform operations locally at the ESU or report issues for judgment. As described below, alert messages generated by the local system can be processed on the cloud independently or with the local device (e.g., ESU).

[0049] For example, a flywheel or chemical battery energy storage system can have various devices and sensors that generate data or identify faults independently or in combination.

[0050] Due to the local and remote processing, as well as other features described herein, the architecture is highly scalable, able to grow organically as needed, for example, when additional devices are added to a location or cluster, or when a vendor monitors more and more devices. As a result, a vendor is able to gain insight into local devices and circuits in ways that were not previously possible. Individual residences can be monitored (e.g., by a customer or a vendor), clusters of residences, neighborhoods of residences, etc. can be monitored at the local, neighborhood / cluster level, or by a utility or vendor.

[0051] It should be noted that while certain features are summarized here and in the drawings, other features are possible and contemplated herein.

[0052] With reference to the drawings, reference numbers can be used to refer to components in any of the drawings, regardless of whether those reference numbers are shown in the described drawing. Additionally, where reference numbers include a letter that refers to one of multiple similar components (e.g., components 000a, 000b, and 000n), the reference number without the letter can be used to refer to one or all of the similar components.

[0053] The innovative energy technology disclosed herein provides novel advantages, including the ability to: combine modern technology with traditional power infrastructure; enable a rapid transition to renewable energy; provide backup to the grid, using the grid as backup; store power locally in nodes 140 and regionalized storage clusters of nodes 140; isolate and minimize the impact of power outages; whether caused by natural disaster, infrastructure failure, or other factors; provide an affordable alternative to expensive and environmentally unfriendly electrochemical batteries; provide consumers with an option independent of carbon-based energy; and decentralize power production.

[0054] The innovative energy technology disclosed herein provides novel advantages, including the ability to: combine modern technology with traditional power infrastructure; enable a rapid transition to renewable energy; use the grid 130 as a backup; store power locally in the node(s) 140 and regionalized storage clusters 160 of the nodes 140; isolate and minimize the impact of power outages; whether caused by natural disaster, infrastructure failure, or other factors; provide an affordable alternative to expensive and environmentally unfriendly electrochemical batteries; provide consumers with an option independent of carbon-based energy; and decentralize power production.

[0055] As shown in Figure 1 The innovative energy technology described herein can include an energy-as-a-service platform (EaaS platform) 100. The EaaS platform 100 can include an EaaS manager 110, third-party server(s) 116, user application(s) 172, regionalized storage clusters 160 composed of one or more nodes 140, and a grid 130. The user application(s) 172 are operable on computing devices accessible to and interactive with user(s) 170 of the EaaS platform 100 and are configured to send data to or receive data from the EaaS manager 110. The grid 130 includes one or more power facilities 132 connected to a power transmission infrastructure 134.

[0056] The node 140 can be composed of a power-consuming entity and at least one ESU (e.g., providing the ESU 150 as an example). The node 140 can be a power-consuming entity itself, or the node 140 can be coupled to a power-consuming entity. In Figure 1 The node 140 is depicted as some place 142, such as a residence, but it is understood that any power-consuming entity is applicable, such as one or more appliances, commercial buildings (such as warehouses or office buildings), electronic devices or systems (whether mobile or static), transportation systems and / or vehicles, transportation charging systems, power sources, substations, substation backup power, and the like. The regionalized storage cluster includes two or more nodes 140 within a given geographic area. The storage cluster can provide power storage functionality, discussed further below. The various elements of the node 140, including the energy storage unit(s) (ESU) 150, the independent power system 147, the grid 130, and / or any appliances and other entities can be electrically coupled through an electrical system 154. The electrical system 154 includes wires, connectors, switches, plugs, breakers, transformers, inverters, controllers, and any other suitable electrical components.

[0057] In the depicted example, node 140 is equipped with or coupled to power generation technology, such as independent power system 147 and / or power grid 130. Independent power system 147 can include power generation technology that is localized and allows for independent power generation, such as renewable power generation technology. Non-limiting examples include solar power system 144 (including solar cell arrays, controllers, inverters, etc.), wind turbine system 146 (including turbine(s), controllers, inverters, etc.), and / or other energy sources 148 (e.g., hydroelectric, geothermal, nuclear, systems and constituent components thereof, etc.). The power generation technology can additionally or alternatively be traditional carbon-based power generation technology, such as depicted power grid 130, although for carbon-negative or carbon-neutral implementations, greener power generation technology can be preferred.

[0058] Node 140 can include or be coupled to an energy storage unit that is capable of storing excess power generated by the power generation technology. In some implementations, the energy storage unit can include energy storage unit (ESU) 150. Although ESU 150 is illustrated and described herein as including one or more flywheels 152A, 152B,... 152N (also simply 152 individually or collectively), they can alternatively or additionally include chemical batteries, capacitors, or other energy storage devices. According to implementations, ESU 150 can convert power received from the power generation technology into kinetic energy by spinning flywheels 152 (increasing rotational speed) and / or by using one or more inverters that convert between direct current and alternating current.

[0059] Each battery or flywheel 152 or can be configured to store up to a certain maximum amount of energy. As a non-limiting example, motor 310 coupled to flywheel 152 can be configured to spin flywheel 152 up to between 15,000 revolutions per minute (RPM) and 25,000 RPM, such that flywheel 152 can store between 18 kilowatt-hours (kWh) and 28 kWh of power. In combination, three stacked flywheels 152 can store between 54 kWh and 84 kWh of power. During periods of time when the power generation technology, such as solar cells, generates less power than is consumed by the electrical devices (e.g., appliances) of premises 142, motor 310 can operate as a generator that converts the kinetic energy (mechanical energy) stored in flywheels 152 into electrical power, thereby drawing power from flywheels 152 to meet the local power needs of node 140 (e.g., to power the electrical devices of premises 142). In this example, advantageously, node 140 can use 15 kWh of power on average per day, and ESU 150 is capable of powering node 140 completely for approximately 4-6 days if local power generation ceases to generate any power.

[0060] In some implementations, the site 142 or node 140 can include or be coupled (physically or communicatively) to a local weather station 143 that measures light, precipitation, wind speed and direction, atmospheric pressure, or other weather data. For example, where the site 142 comprises a residence, the local weather station 143 can be placed on the roof of the residence or in the yard. The local weather station 143 can be communicatively coupled directly with the controller 254 or node 140 or the central nervous system of the ESU 150, or can be coupled with the EaaS manager 110, the third-party server(s) 116, or another device via the network 102, for example. Thus, as described below, weather and other environmental data can be used to train one or more machine learning models that predict power consumption and / or production. Weather data can also be input into trained models in order to predict future behavior (e.g., power consumption or production), as described elsewhere herein.

[0061] In another example, as discussed further elsewhere herein, a utility can be integrated with the EaaS manager 110, and its utility management application 122 signals to the power management application 111 through the storage cluster API 112 that it is experiencing a surge in power demand, and the power management application 111 can signal to the node 140 or cluster of nodes 140 (e.g., the storage cluster 160) to decouple power from the flywheel 152 and provide energy back to the grid through the transmission infrastructure 134, which can be connected to the node(s) 140 through a connection point (e.g., a two- or three-phase electrical service branch connected to a service panel or buried power line, which typically includes power meter(s)). Conversely, a utility can be generating excess power and can wish to store / power. The utility management application 122 can signal to the power management application 111 through the storage cluster API 112 that it needs to store a given amount of power, and the power management application 111 can in turn signal to the node 140 or cluster(s) of nodes 140 (e.g., one or more regionalized storage clusters 160) to store the demand, and those node(s) 140 in the storage cluster(s) 160 that have excess capacity and are configured to receive power from the grid can receive power through the transmission infrastructure 134 and store it as mechanical energy in the ESU for later retrieval. The EaaS platform 100 can charge the utility for the power storage service, as discussed further elsewhere herein.

[0062] It should be understood that the RPM and kWh values provided above are provided as non-limiting examples only, and that the ESU 150 can be equipped with flywheels 152 capable of storing more or less power depending on the implementation. For example, the weight of the flywheel 152, the materials used for the flywheel 152, the size and configuration of the flywheel 152, the efficiency of the motor 310 and bearings, and the like, can all be adjusted based on usage to provide the required backup power for the node 140. As another example, the flywheel 152 can be made of steel, aluminum, carbon fiber, titanium, any suitable alloy, and / or any other material capable of handling the cycling, vibration, radial and shear stresses and tensions, and other conditions that such a flywheel 152 will be subjected to.

[0063] The power transmission infrastructure 134 includes a power network that couples power-consuming entities (e.g., homes, offices, appliances, etc.) with power facilities that generate power using carbon, nuclear, and / or natural resources. The transmission infrastructure 134 can include intermediate elements, such as step-up transformers, substations, transmission lines, etc., that are interconnected to provide power widely to different geographic areas.

[0064] A power utility (also referred to simply as a utility), which can own and operate one or more power facilities and portions of the transmission infrastructure 134, can operate a utility server configured to execute a utility management application 122. The utility management application 122 can perform various functions, such as load balancing, load management, and grid energy storage, to manage power supply based on real-time demand. However, due to limitations in existing grid technology, power outages, brownouts, and expensive peak power costs remain the norm.

[0065] A user can use an instance of a user application 172 executing on a computing device, such as the user's mobile phone or personal computer, to configure and interact with the ESU(s) 150 that they are authorized to control, such as the ESU 150 installed at their home or company, as discussed further elsewhere herein.

[0066] As Figure 1As shown, the EaaS manager 110, utility server 120, power utility 132, elements of the grid 130, wind turbine system 146, solar power system 144, other sources 148, node(s) 140, regionalized storage cluster 160, user applications 172 and associated computing devices, etc., can be coupled for communication and connected to the network 102 through wireless or wired connections (using network interfaces associated with the computing devices of the aforementioned elements). The network 102 can include any number of networks and / or network types. For example, the network 102 can include one or more local area networks (LANs), wide area networks (WANs) (e.g., the Internet), virtual private networks (VPNs), wireless wide area networks (WWANs), WiMAX® networks, personal area networks (PANs) (e.g., Bluetooth® communication networks), various combinations thereof, and the like. These private and / or public networks can have any number of configurations and / or topologies, and can transmit data via networks using a variety of different communication protocols including, for example, various Internet layer, transport layer, or application layer protocols. For example, data can be transmitted over the network using TCP / IP, UDP, TCP, HTTP, HTTPS, DASH, RTSP, RTP, RTCP, VOIP, FTP, WS, WAP, SMS, MMS, XMS, IMAP, SMTP, POP, WebDAV, or other known protocols.

[0067] The EaaS manager 110, third party server(s), utility server 120, node(s) 140, power utility, and user devices can have computer processors, memory, and other elements that provide them with non-transitory data processing, storage, and communication capabilities. For example, each of the aforementioned elements can include one or more hardware servers, server arrays, storage devices, network interfaces, and / or other computing elements, etc. In some embodiments, one or more of the aforementioned elements can include one or more virtual servers running in a hosted server environment. Other variations are also possible and contemplated.

[0068] It should be understood that Figure 1 the EaaS platform 100 and Figure 2The diagrams shown in the middle are representative of example systems, and various different system environments and configurations are contemplated and within the scope of the present disclosure. For example, various acts and / or functions can move between entities (e.g., from server to client, or from client to server), between servers, data can be consolidated into a single data store or further split into additional data stores, and some embodiments can include additional or fewer computing devices, services, and / or networks, and can implement various functions on the client or server side. Also, various entities of the system can be integrated into a single computing device or system, or partitioned across additional computing devices or systems, etc., without departing from the scope of the present disclosure.

[0069] Third party server(s) 116 are one or more servers or services that provide additional or external information. For example, third party server 116 can be associated with and / or provide interaction with a national weather service, an electric vehicle, a smart EV charger, a smart thermostat, a home automation system, a smart power meter (e.g., an Acrel™ meter), a solar power production service, or various other servers or services. For example, EaaS manager 110 and / or nodes 140 (e.g., controller 254 or the central nervous system therein) can communicate with one or more third party servers 116 to receive power consumption data, power production data, environmental data, etc. In some cases, one or more third party servers 116 can additionally or alternatively allow control of various power production devices or power loads.

[0070] Figure 2 A block diagram showing example components of utility server 120, node(s) 140, and EaaS manager 110, and interaction therebetween is depicted. The utility server includes an instance of utility management application 122 and EaaS interface 124. EaaS manager 110 includes power management application 111, utility API 112, node 140 API 113, and data store 210. Data store 210 can store and provide access to data related to EaaS platform 100, such as cluster data 211, node 140 data 212, user data 213, usage data 214, utility data 214, analytics data 216, and fault data 217.

[0071] In some embodiments, the EaaS manager 110 can include a training engine 114 that receives various data and trains one or more machine learning models that can be used by the nodes 140, the EaaS manager 110, or the utility server 120 to estimate future behavior, such as consumption or production of electricity, as described in further detail below. It should also be noted that while the training engine 114 is shown as included on the EaaS manager 110, it can be executed on the nodes 140, the utility server 120, a third-party server 116, another device, or distributed among multiple devices.

[0072] The nodes 140 of the EaaS platform 100 can include one or more ESUs 150, although chemical or other forms of electrical storage are possible and contemplated herein. The ESU 150 can include an instance of a controller 254. The controller 254 can include a flywheel coupler 255, a flywheel selector 256, and a flywheel monitor 257. The MESU (mechanical energy storage unit) hardware 258 can include a chassis, one or more flywheels 152, magnets and / or bearings, the flywheel coupler 255, and / or the motor-generator 310. The motor-generator 310 can be connected to each flywheel 152 through the flywheel coupler 255. The flywheel coupler 255 can engage and disengage the motor-generator 310 from the flywheel 152, such that each flywheel 152 can freely spin when disengaged, and can be coupled to the motor-generator 310 when engaged, such that the motor-generator 310 can increase the speed of the flywheel 152 (spin the flywheel 152), or the flywheel 152 can spin the generator to generate electricity. Each flywheel 152 can be levitated using magnets to minimize friction caused by the rotation of the flywheel 152. As one example, a magnetic levitation unit can be used to levitate and keep the flywheel 152 spinning.

[0073] In some embodiments, the ESU 150 can additionally or alternatively include battery hardware 259, such as for various other energy storage unit types, such as chemical batteries. For example, one or more chemical batteries, controllers, enclosures, or other configurations can be used.

[0074] Additionally or alternatively, bearings, such as but not limited to ceramic bearings, can be used to support and hold flywheels 152 while rotating. The chassis can house and support the flywheels 152. The flywheels 152 can be arranged horizontally or vertically. In a horizontal orientation, the flywheels 152 can have a wheel-like shape and can be stacked one on top of another in the same chassis, but still configured to rotate independently of one another. In this configuration, a coupler is independently coupled to each flywheel 152, or more than one coupler and motor 310 can be used, depending on the implementation. In a vertical orientation, the flywheels 152 can have a roller-like shape and can be positioned parallel to one another in the chassis. In either orientation, in some implementations, the chassis can include an enclosure that encloses the ESU 150 and provides a vacuum environment in which the components of the ESU 150 can operate. This is advantageous because it can insulate against dust, debris, and factors that cause corrosion and allow the flywheels 152 and other components to operate optimally.

[0075] In some implementations, a node 140 can include one or more ESUs 150 and can act as a manager of the ESU(s), can receive and process information from the EaaS manager 110 of two or more ESUs 150, and can send signals to and receive and process signals from the ESU(s) 150 (e.g., via the controller 254, MESU hardware 258, and / or battery hardware 259) to control the function and operation of the ESU(s) 150. In other implementations, the structure, actions, and / or functions of the controller 254 and the node 140 application 240 and its constituent components can be combined, and the node 140 can represent the ESU(s) 150 itself, to which one or more electrical appliances consuming power can be coupled to receive power. Other variations are also possible and contemplated.

[0076] The utility management application 122, the controller 254, the node 140 application, the node 140 management application, the utility API, the node 140 API, and the ESU API can each include executable hardware and / or software to provide the actions and functions disclosed herein.

[0077] In particular, the utility management application 122 can be executed by a utility server to monitor power generation and distribution for one or more power utilities and transmission infrastructure 134. The utility management application 122 can receive signals from various entities of the EaaS platform, such as the EaaS manager 110, nodes 140, transmission infrastructure 134, other utility management applications associated with other suppliers, and so on. The utility management application 122 can communicate with the EaaS manager 110 through the EaaS interface 124 to access services provided by the EaaS manager 110. In particular, the EaaS interface 124 can interact with a utility API of the EaaS manager 110 to request power reserves, request provision of supplemental power, provide usage, performance, and / or demand data, and so on. In some implementations, the EaaS interface 124 can generate a security request and send the security request to the utility API over a network. The power management application 111 can receive the request via the utility API and process it accordingly.

[0078] In some implementations, the nodes 140 or sites 142 can include one or more local sensors, power meters, weather stations, and / or controllable devices that can be, for example, electrically and / or communicatively coupled with the ESU 150 or other components of the node 140. For example, these sensors and devices can be in direct communication with the controller 254 or with the EaaS manager 110 (directly or via one or more servers, networks, APIs, and so on). Accordingly, the training engine 114 can receive data from the devices 247 or other components of the node 140 (and / or other sources, such as the third-party server(s) 116) to train models, as described below. The training engine 114 can store the models in the node 140 data 212 (e.g., if training for a particular node 140), the cluster data 211 (if training for a cluster of nodes 140), and so on. Accordingly, the power management application 111 can receive or access the models to generate predictions, for example, as described below.

[0079] The power management application 111 can be coupled to the data store 210 to store and retrieve data. Data stored in the data store can be used to organize and query data stored by the data store 210 using any type of data (e.g., cluster ID, user ID, utility ID, node 140 ID, ESU ID, configuration data, and so on). The data store 210 can include a file system, a database, a data table, a document, or other organized collection of data.

[0080] Cluster data 211 can include information about a cluster of two or more nodes 140 (e.g., a regionalized storage cluster), such as the identity of the node(s) 140, the storage capacity of the storage cluster 160, the availability of the storage cluster 160, the operational health of the storage cluster 160 and / or constituent ESU(s) 150, historical performance of the storage cluster 160, etc. Cluster data 211 can include various consumption data, production data, weather data, environmental data, algorithms, equations, cluster attributes, machine learning models trained for the cluster, or other data.

[0081] Node 140 data 212 can include information about a node 140, such as the number of ESUs installed at the node 140, the type of node 140, the operational health of the ESU(s) 150, any limitations or operational parameters of the ESU(s) 150, configuration data of the ESU(s) 150, an identifier of the ESU(s) 150, the ownership of the ESU(s) 150, whether the ESU(s) 150 can be used for grid power storage, whether the ESU(s) 150 have been deactivated, etc.

[0082] Node 140 data 212, for example, can include various consumption data, production data, weather data, environmental data, algorithms, equations, node 140 attributes, machine learning models trained for the node 140, or other data, as described in further detail elsewhere herein.

[0083] User data 213 can include information about users associated with the storage cluster 160, node 140, or ESU 150, including user account information, login information, user preferences for managing ESUs (e.g., schedule data, activation / deactivation data, etc.).

[0084] Usage data 214 can include information about the usage of the cluster and / or ESU(s) 150, such as the rate of rotation of the flywheel 152, the power output level, maintenance cycles, downtime, periods of inactivity, third-party usage (e.g., by utilities or neighboring nodes 140), etc.

[0085] Utility data 215 can include information about utilities that have partnered with the EaaS platform 100, such as utility account information, utility capability information, power storage needs, contract parameters, performance requirements, grid 130 specifications, etc.

[0086] Analytics data 216 can include insights about the EaaS platform 100, such as comparisons of local versus grid generation, aggregated usage data, aggregated performance data, and the like. It should be understood that the EaaS manager 110 can store and process any other data suitable and applicable to the EaaS platform 100. In some cases, analytics data 216 can describe performance, predictions, or other data of machine learning models, as described in further detail elsewhere herein.

[0087] Fault data 217 can include sensor and other data, such as described throughout this disclosure, including faults, alarms, threshold values compared to detect faults, and other data. For example, fault data 217 can include any data described below with respect to methods and graphical user interfaces, such as sensor data, voltage, state of charge, and the like.

[0088] The node 140 application 240 and controller 254 can communicate with the EaaS manager 110 through an EaaS interface 242 configured to interact with a node 140 API 113 presented by the EaaS manager 110. The node 140 API 113 provides methods for accessing data related to the node 140 and ESU(s) 150 associated with the node 140, and performing various functions, such as signaling the unavailability / availability of stored power, requesting a functional upgrade, such as a higher rotational speed of one or more flywheels 152, deactivating a previously active flywheel 152 or activating a previously inactive flywheel 152, reporting usage data and / or status information, and the like.

[0089] In some embodiments, the node 140 application 240 can execute on or communicate with a controller 254, which can be a computing device that controls components of the node 140, such as mechanical batteries (e.g., flywheels), chemical batteries, or various other components. For example, the controller 254 can include a central nervous system (CNS) or computer that receives sensor data, provides instructions to inverters, motors, or other components, or performs other operations. For example, the node 140 application 240 can execute on the controller 254 or CNS to communicate with the node 140 components and / or the EaaS manager 110 or another external component.

[0090] The flywheel manager 244 of the node 140 application 204 can be configured to communicate with the controller 254 to provide operational control signals, such as power storage signals, power extraction signals, rotational speed adjustment signals, flywheel enable / disable signals, and the like. The energy manager 246 is configured to communicate with the flywheel manager 244 and provide control signals to the flywheel manager according to energy demands (generating energy for local use, generating energy for utility use, storing local energy, storing utility-provided energy, and the like).

[0091] Flywheel couplers 255 can be configured to control mechanical coupling of flywheels 152 to motor generators 310, flywheel selectors 256 are configured to select which flywheel 152 to control based on received control signals, flywheel monitors 257 monitor the status of each flywheel 152 for safe operation and performance within defined operating parameters, and can control the function of MESU hardware 258 and shut down, slow down, pause, adjust, optimize, or otherwise control MESU hardware 258 according to the monitored status.

[0092] Figure 3A and Figure 3B An example embodiment of a mechanical energy storage unit (ESU) assembly 302 is shown, which can use flywheels 304 to store energy with rotational momentum. Figure 3A A perspective view of an example ESU assembly 302 is shown, which has an open housing 306 to expose flywheels 304. Figure 3B A perspective view of an example ESU assembly 302 is shown, which has an open housing 306 to expose flywheels 304. Figure 3B Various components are also shown, such as supercapacitors 324 or batteries, vacuum pumps 322, and computing devices 326 (e.g., CNS).

[0093] It should also be noted that for the purposes of this disclosure, flywheels 304 and ESU assemblies 302 are provided as examples only, and other local energy storage devices are also possible and contemplated. In some embodiments, the technology can be applied to chemical or other energy storage, such as chemical batteries, supercapacitors, flywheels, gravity-based batteries, and / or combinations thereof.

[0094] For example, herein, while other embodiments are also possible and contemplated, for example, Figure 3A and Figure 3B An example mechanical energy storage unit (ESU) assembly 302 is shown, which uses flywheels 304 to provide energy storage. As Figure 3A and Figure 3B As shown in example embodiments of FIGS. 3A-3C, ESU assembly 302 can include a flywheel housing 306, which provides support for flywheel bearings 308, which provide support for flywheels 304. Flywheel bearings 308 can suspend flywheels 304 and allow flywheels 304 to rotate within a cavity or space of flywheel housing 306, such as about a central axis of rotation. Motor generators 310 can be coupled or couplable with flywheels 304 through flywheel couplers 312 to exert or receive rotational forces thereon. In some embodiments, ESU assembly 302 can include various other components, such as frames, actuators, electronics, housings, reinforcements, legs 318, etc., described elsewhere herein.

[0095] It should be noted that while certain components and configurations are described herein, other implementations are possible and contemplated herein. For example, the ESU assembly 302 can include fewer, more, or different components. In some implementations, the ESU assembly 302 can have various other configurations, e.g., it can be oriented in various directions, e.g., with the motor 310 below or to the side of the flywheel 304, or otherwise configured.

[0096] In some implementations, while the ESU assembly 302 is shown as a single unit, it can be implemented in other ways. For example, the ESU assembly 302 can include one or more components that are separate from each other, e.g., a motor and a flywheel, or a motor, a flywheel, and a supercapacitor, or other combinations. In some implementations, the ESU assembly 302 can include one or more components that are separate from each other and are connected by a wired or wireless connection, e.g., a wired or wireless connection to a controller, a wired or wireless connection to a power source, a wired or wireless connection to a load, etc. Figure 3A and Figure 3B The ESU assembly 302 can include other components, e.g., inverters, wiring, switches, sensors, transformers, and / or other power conversion or transmission devices, that deliver current from and / or to an external power source, e.g., an electrical service panel, a solar panel system, a power grid, etc., although not shown in the example of FIG. 1. The devices can additionally or alternatively couple the ESU assembly 302 to various loads, e.g., a power grid, an electrical service panel, an electric vehicle charger, etc.

[0097] In some implementations, the ESU assembly 302 can include and / or be coupled to various control devices, e.g., computing devices or other control units that perform various operations, etc. For example, the ESU assembly 302 can be part of the node 140 and coupled with the controller 254 and / or the node 140 application 240. For example, the ESU assembly 302 control unit can represent an implementation of the controller or one of its components. The ESU assembly 302 control unit, etc., as described above, can perform various operations related to the ESU assembly 302, as described in further detail elsewhere herein.

[0098] The example ESU assembly 302 can include one or more chemical batteries, supercapacitors, inverters, motors, or other components, which can be monitored by one or more sensors. For example, the ESU assembly 302 can include temperature, rotation, and acceleration sensors in or near the bearings or shaft of the flywheel. Similarly, temperature sensors can be located near the chemical batteries or other components. The inverters can be coupled with the controller of the ESU assembly 302 and can provide various other information, e.g., current, voltage, etc. Thus, as noted in greater detail elsewhere herein, status or diagnostic data can be collected by the controller and used by the controller (e.g., the controller 254, the node 140 application 240, the CNS, etc.) to identify faults or other events. The controller 254 can perform operations automatically locally and / or communicate messages to a remote server for further processing.

[0099] In some embodiments, all or a portion of the ESU assembly 302 can be placed within an enclosure or enclosure to provide protection for the ESU assembly 302, to prevent potential flywheel structural failure, and / or to vacuum, which increases flywheel efficiency. For example, the vacuum can be permanent or actively maintained using a vacuum pump 322. An example enclosure is described in more detail below.

[0100] For example, as shown in Figure 3B the enclosure 306 can be completely enclosed to house the flywheel 304 therein. The enclosure 306 can include a vacuum pump 322 coupled to a top of the enclosure 306, which can be powered by the motor / generator 310, a supercapacitor 324, a battery (not shown), an external power grid, etc. The pump 322 can maintain a given vacuum pressure within the enclosure 306 in order to reduce drag on the flywheel 304. In some embodiments, the vacuum pump 322 and / or the enclosure 306 can include one or more sensors that indicate a status and / or pressure of the pump 322 or the enclosure 306.

[0101] As shown in the example of Figure 3A the ESU assembly 302 can include a flywheel 304 that includes one or more plates connected to a flywheel bearing 308 at a center axis of rotation, which allows the flywheel 304 to rotate about the center axis. The flywheel 304 can be housed within and supported by a flywheel enclosure 306 (e.g., via the flywheel bearing 308). The ESU assembly 302 can include a motor 310 assembly that includes the motor 310 adapted to convert input current into rotational momentum by rotating the flywheel 304 and / or to convert rotational momentum of the flywheel 304 into output current. The flywheel 304 can be coupled with the motor 310 using a flywheel coupler 312 that exerts rotational force between the motor 310 and the flywheel 304.

[0102] In some cases, the flywheel 304 can be allowed to rotate or freewheel relative to the flywheel enclosure 306, for example, by allowing the motor 310 to freely rotate and / or allowing the flywheel coupler 312 to disengage, as described in further detail below. For example, the ESU assembly 302 can include a motor 310 frame 314 that holds the motor 310 and can allow the motor 310 to move, depending on the embodiment. Additionally or alternatively, the ESU assembly 302 can include a coupler lifter 316 or other mechanism that electrically couples and / or decouples the flywheel coupler 312 and / or the motor 310 via the motor frame, as described in the examples below.

[0103] The flywheel 304 can include a large mass wheel that rotates about a center axis. In Figure 3AIn the example shown, a number of metal discs can be coupled together, such as using bolts through the discs or clamping the discs together. For example, flywheel 304 can include discs, rings, or solid structures.

[0104] In this example, Figure 3A Ten flywheel discs are shown; however, other numbers and configurations are possible and contemplated herein. The thickness, size, shape, and number of discs or plates can vary. For example, the number of discs can be varied to adjust the energy storage amount of the mechanical energy storage unit, with additional discs providing additional storage at minimal additional cost and complexity, without correspondingly increasing the likelihood of structural failure. The discs can be solid plates, have various perforations (e.g., for bolts or hubs), can be circular or other shapes, or have other configurations. Ideally, the discs are symmetrical or balanced to reduce vibration when flywheel 304 is rotating.

[0105] Depending on the implementation, flywheel 304 can be constructed of aluminum, steel, concrete, composite materials, other materials, or combinations thereof. For example, a set of steel flywheel plates or discs coupled together, each flywheel plate or disc can be a quarter inch, half an inch, one inch, or other thickness in thickness. Other implementations, such as combinations of aluminum and composite materials (e.g., carbon fiber, etc.) will be described in further detail below. In some implementations, the discs can include or be reinforced with other materials, such as Kevlar®, fiberglass, or carbon fiber, as described elsewhere herein.

[0106] Flywheel 304 can have various sizes based on the material strength of flywheel 304, the desired rotational speed, and / or the desired storage capacity. For example, to improve manufacturability, reduce the risk of material failure, allow flywheel 304 to be placed in residential or other small-scale applications, the diameter of flywheel 304 can be between 6 inches and 36 inches, although other sizes are possible. For example, flywheel 304 can have a diameter of approximately 25 inches and a thickness of 5-12 inches. As described elsewhere herein, increasing the number of discs can increase the energy storage capacity without increasing the rotational speed.

[0107] Although many other implementations are possible and contemplated herein, flywheels 304 can have a weight ranging from 100-1500 pounds, rotate at 5,000-25,000 RPM, and have a storage capacity of 3-15 kWh, depending on their size and material. For example, flywheel energy capacity can be increased to 15-500 kWh by increasing the diameter or number of plates. These and other examples provided herein are meant to be non-limiting examples, and various sizes, materials, configurations, and storage capacities are possible and contemplated.

[0108] Various radii and rotational speeds can be used to address radial and circumferential stresses. For example, reducing the diameter can reduce the radial stress, but also reduce the angular momentum. As the material strength increases, the rotational speed can be increased, thereby increasing the energy storage accordingly. As described elsewhere herein, the RPM of the flywheel 304 can be monitored by the control unit (e.g., controller 254) based on the speed of the motor 310 or one or more sensors, such that the control unit can determine the current energy storage and keep the rotation within a target, effective, or safe speed.

[0109] In some embodiments, the flywheel 304 can have a hole through its center, in which a hub and / or shaft can be placed, although a through hub is not required. The hub can include a cylinder coupled to a rod-like shaft, which in turn is coupled with the flywheel coupler 312, or directly with the motor 310, gears, bearing assemblies, flywheel bearings 308, or other components. The hub can be bolted, glued, welded, or press fit to the plate. For example, during assembly, the hub and plate can be placed together, expand to different degrees based on temperature or expansion rate, and when the temperature equalizes, contract to create tension and clamping forces. These disks can be disks or rings around the hub, or can be solid in the center, while otherwise connected with the shaft.

[0110] Returning to Figure 3A and Figure 3B The ESU assembly 302 can include a motor 310, which can be coupled with the flywheel(s) 304 through a flywheel coupler 312, for example at a central shaft, hub, or axle. The motor 310 can be housed in a motor housing, with a rotor of the motor 310 located at the central shaft and coupled with the flywheel coupler 312 to rotate with the flywheel 304, although other embodiments can be used, for example using belts, gears, pulleys, or other devices to connect the motor 310 with the flywheel 304. The motor 310 can act as both a motor 310 to drive the flywheel 304, and as a generator to harvest energy from the flywheel 304.

[0111] In some embodiments, the mechanical energy storage unit assembly 302 may include or be coupled to a motor 310, which may be a generator and a motor, and may rotate a flywheel 304 to increase energy and receive energy from the flywheel 304 to send energy to an output. Depending on the number or total mass of the flywheels 304, the target speed of the flywheels 304 or motor 310, the target efficiency, the rated weight, or other implementations, the motor 310 may have various configurations and sizes. The motor 310 may be coupled to various other electronic devices, such as electronic control units that measure electrical inputs or outputs, the speed of the motor 310, system health status, the position of the flywheel connector 312, the position of the lift 316, or other states. The electronic control unit may allow current from an external power source to be input into or output through the motor 310 into the flywheel 304. The motor 310 may also include or be coupled to various other electronic devices, such as inverters, AC converters, transformers, or other electrical equipment.

[0112] An AC or DC motor can be used. For example, motor 310 may include a permanent magnet motor 310, or, to allow motor 310 to rotate freely, motor 310 may be an induction motor 310, which allows motor 310 to rotate freely without applying or receiving current, so that flywheel 304 can rotate freely (e.g., in the case where flywheel coupling 312 is not detachable). Other types and configurations of motors are also possible and foreseeable.

[0113] like Figure 3A and Figure 3B As shown in the example, motor 310 can be mounted to flywheel housing 306 using motor 310 frame 314, which holds motor 310 so that its rotor axis of rotation is aligned with the axis of flywheel 304. In some embodiments, motor 310 frame 314 can be mounted directly to flywheel housing 306 (e.g., as shown in the example). Figure 3B (as shown), or via connector lift 316 (e.g., as shown) Figure 3A As shown, the lifter can move the flywheel connector 312 (e.g., motor assembly) and / or the motor 310 to separate them from the flywheel 304. For example, the motor 310 assembly may include a frame 314, the motor 310, the connector lifter 316, and / or other components supporting the motor 310 and / or the flywheel connector 312.

[0114] The flywheel 304 can be housed in a flywheel enclosure 306, which can be steel, aluminum, glass, plastic, composite, or other enclosure that provides support for the flywheel(s) 304. For example, the flywheel enclosure 306 can include a metal (e.g., aluminum or steel) top plate for the top of the flywheel 304, a metal plate for the bottom of the flywheel 304, various reinforcement members, and an enclosure support for coupling the top plate and the bottom plate. In some embodiments, the top metal plate or other components of the flywheel enclosure 306 proximate to the moving magnets (e.g., the motor 310, the flywheel coupler 312, or the flywheel bearings 308) can be constructed of plexiglass or another non-conductive material to reduce induced eddy currents and related inefficiencies.

[0115] The ESU assembly 302 can include flywheel bearings 308 that are integrated with or connected to the flywheel enclosure 306 and provide vertical and / or horizontal support for the flywheel 304. Depending on the embodiment, the flywheel bearings 308 can include fluid bearings, magnetic levitation bearings, ball bearings (e.g., ceramic bearings or ceramic hybrid bearings), Teflon®, and / or other bearings. For example, the flywheel bearings 308 can use a first type of bearing (e.g., ball bearings) in the horizontal direction and a second type of bearing (e.g., magnetic levitation bearings) in the vertical direction. In other embodiments, the flywheel bearings 308 can be entirely based on magnetic levitation. The number, type, and spacing of the magnets on either side of the magnetic levitation bearings can be based on the total mass of the flywheel(s) 304 and / or other rotating structures.

[0116] As shown by the example Figure 3B The ESU assembly 302 can support a supercapacitor 324 or a chemical battery that is connected to the motor 310 and satisfies the temporary high current demand to start the motor 310 / flywheel 304 movement or to stop the motor 310 / flywheel 304, as shown by the example. The supercapacitor 324 can include sensors and / or can otherwise be in communication with the controller 254.

[0117] As shown by the example Figure 3B The ESU can include a computer enclosure 326 that can support the controller 254 or CNS (e.g., central nervous system), inverter, or various other components, as shown by the example. For example, the CNS can be in communication with the inverter, motor 310, sensors, or various other components to detect states, events, faults, and the like, as described throughout this disclosure.

[0118] Figure 4A is a block diagram of an example management method of an artificial intelligence-based energy storage unit.

[0119] In some embodiments, at 402, the system (e.g., training engine 114) can receive power consumption data for a given node 140, such as a residence having energy consuming devices, energy storage, and / or energy generating devices. For example, a residence can have one or more local computing devices coupled with a solar panel array, an energy storage unit (e.g., a chemical or mechanical battery), and one or more loads. For example, the computing device(s) can track energy usage by communicating with smart devices, a smart electric meter, a smart electrical service panel, and / or one or more circuit current sensors. The power consumption data can be determined over a defined historical time period and time stamped to provide a time-dependent data set. These data can be obtained by computation, collection, aggregation, etc., and have different temporal resolutions, such as every second, 30 seconds, 1 minute, 15 minutes, 1 hour, or other arbitrary length of time.

[0120] For example, the training engine 114 of the EaaS manager 110 can communicate with one or more smart devices, such as the central nervous system or controller 254 of the node 140, in order to collect data as it is delivered. The training engine 114 can also receive data from an electric meter that collects data about how much current is used at a given time. A power meter, such as an Acrel™ meter, can include a smart service panel or a clamp-on meter that detects an electric or magnetic field generated by current in a wire. The training engine 114 can be communicatively coupled with the electric meter or can retrieve its time-stamped data from the controller 254 of the node 140 or from a server associated with the electric meter (e.g., via application programming interface(s)). In some cases, the electric meter can automatically identify devices that use power based on a current profile (e.g., an air conditioner compressor can have a different startup and usage curve), and thus, power usage for the entire home, circuit, or individual devices can be determined by the meter, the training engine 114, or another analytics service.

[0121] In some embodiments, the training engine 114 can also receive or retrieve power consumption data from smart devices, such as an internet-connected refrigerator, thermostat, washer / dryer, HVAC (heating, ventilation, and air conditioning) unit, electric vehicle charger, heater, smart switch or light bulb, home automation controller, or other smart device that can report data (e.g., time-stamped data) about its power consumption. The training engine 114 can receive or retrieve this data directly or via one or more third-party servers 116 associated with the smart device.

[0122] In some embodiments, the training engine 114 can also collect other data points that it can use to further improve the training of the consumption model(s). For example, the training engine 114 can also receive or retrieve sensor data indicative of the internal or external temperature of the premises, weather data from a local power station (e.g., 143) or weather service (e.g., National Weather Service on a third-party server 116), premises occupancy, or other environmental information. This information can be time-stamped and / or otherwise associated with the consumption / usage data of a given node 140.

[0123] Accordingly, the consumption data can be separated into individual consumption / usage elements, values, files, or entries from various sources, and can be associated with categories, flags, environmental data, and can have various resolutions, with the consumption data being collected, received, stored, or processed at various periods (e.g., every second), although other frequencies are possible and contemplated herein.

[0124] In some embodiments, at 404, the system (e.g., training engine 114) can determine one or more baseline power consumptions of the node 140. The baseline power consumption can be the power consumption or electricity usage of the node 140 excluding power loads that can be deferred (or whose usage is shifted / asynchronous in magnitude / time) or turned off, such as lighting, electric vehicle charging stations, electric dryers, etc., or excluding other specified loads. For example, the baseline current can be the current drawn by devices in a standby state. For example, the system can determine the lowest current drawn at a time of day or different time stamps of the day (e.g., can draw more current at certain times). In some cases, the system can subtract the consumption of various devices from the total consumption of the node 140 based on received / determined consumption data. For example, where all power consumption data of the node can be a first set of data, the baseline power consumption can be a subset of that set of data. As described herein, the subset can omit (not include) the power consumption of one or more controllable (directly or indirectly) loads of the node(s) 140.

[0125] It should be noted that the term baseline power consumption or usage can refer to a nominal, regular, consistent, or base power draw of one or more power loads for purposes of illustration. It can be an average, low average, median, or other quantity, and can be stored in a table in association with its timestamp, category(s), label or indicia, source, variability, associated environment, or other details. For example, an average time-dependent power draw of a site can be determined, and controllable, optional, or time-shifted power usage (e.g., due to periodic EV charging, periodic use of an electric oven, etc.) can be subtracted from the average to indicate a nominal draw or baseline consumption of the site, although this is provided by way of example only, and other implementations are possible and contemplated herein as well.

[0126] In some implementations, the training engine 114 can automatically classify data points (e.g., power consumption from various devices) based on device type, instantaneous or total power usage, power usage timing (e.g., day, night, regularity of use, whether use is predictable, etc.) source, frequency, whether the device can be controlled by the EaaS manager 110, whether a user or administrator has set the device to be controllable (or established integration or automation with the device), or based on another defined parameter, such as whether the device is defined or categorized as essential or deferrable. For example, regular nighttime lighting in a house can be classified as baseline power usage, even though it is controllable, while EV charging or laundry can be classified as optional or deferrable usage, as a typical electric vehicle does not need to be charged every day or laundry can be deferred to the next day (or scheduled in the afternoon instead of the morning or evening). These classifications and parameters can be defined by an administrator or the homeowner associated with the node 140, for example.

[0127] In some cases, baseline power consumption can be defined as the total consumption of a site (e.g., all devices or all power draws) minus detectable or controllable power consumption from a defined set of devices or organizations (e.g., from a thermostat, electric vehicle (EV), EV charger, or organization or integration with other devices or services), such as data received or sent via a server (e.g., via an API) of a smart thermostat, EV, EV charger, smart home controller, etc. For example, baseline power consumption can be the fixed power consumption of a home without variable loads, which can be placed above the baseline consumption according to a number of factors, such as settings defined by a homeowner or administrator for optimization of their system. In some implementations, user settings can be explicit, such as explicit selection in a graphical user interface, or implicit, such as by integrating a device (e.g., logging in, providing permission, or otherwise coupling a smart EV charger or smart thermostat with the EaaS manager 110 or training engine 114).

[0128] In some embodiments, there can be intermediate categories of electricity usage, or the categories of electricity usage can change depending on the time of day, day of the week, month, weather, user input or preferences, or other circumstances. For example, lighting can be defined as necessary or nominal consumption in the evening, heating or cooling can be classified as partially time-shiftable, and EV charging can be fully time- shiftable or deferrable. For example, the training engine 114 can weight the power usage of the HVAC to have a partial baseline power draw and a partially deferrable power draw, as it can be reduced or deferred by a small percentage or a short time, but not turned off completely. For example, if the power consumption of the HVAC unit at a given time is defined as reducible to 80% power consumption, 80% of the current can be classified as baseline, and the remainder is considered optional, deferrable, or time-shiftable usage.

[0129] Depending on the embodiment, the baseline power consumption of the node 140 can be the sum of all devices or data points at various time resolutions or increments. For example, the power consumption data can be totaled into“buckets” of time increments (e.g., every second, five seconds, thirty seconds, minutes, fifteen minutes, every hour, or other data resolution) to determine the baseline power consumption (and / or non-baseline power consumption) in each increment. As described above, to determine the data consumption at each time increment, the data points can be classified as baseline or non-baseline. In some embodiments, the data resolution can be increased (e.g., beyond the resolution at which the data is received) or decreased (e.g., total or average for an entire day) by summing, averaging, smoothing, or projecting the data points using recursion.

[0130] In some embodiments, the data points of a data source can be classified as baseline in some circumstances, or non-baseline in other circumstances. For example, the power consumption generated by indoor lighting during the day can be classified as non-baseline (i.e., turnable off or deferred), while the power consumption generated by indoor lighting during the evening is classified as baseline. As another example, a user can indicate power consumption preferences through a graphical user interface of what should or should not be adjusted. For example, the user can indicate that HVAC power usage should be classified as baseline, while EV charging can be turned off, time-shifted, deferred, etc. (e.g., classified as non-baseline usage).

[0131] In some embodiments, at 406, the system can train a machine learning model based on the consumption data and associated data, such as time of day, concurrent weather (e.g., as determined at 408, which can be performed partially or entirely prior to 406, depending on the embodiment, as described above), day of week, occupancy of the premises 142, or other environment. For convenience, this model can be referred to herein as a consumption model. For example, these different environmental factors can be input into a machine learning algorithm that trains the model from historical consumption data. Thus, the system can train a machine learning model that predicts future power consumption based on a given environment based on power consumption data specific to the node 140 (e.g., rather than generalized across a network of many residences or non-specific). Although a machine learning model is described for the consumption model, other models or algorithms, data tables, etc. can also be used.

[0132] The consumption model can be trained by feeding a timeline of consumption data and potentially environmental factors into a machine learning algorithm. The consumption data on which the model is trained can be baseline data, non-baseline data, or a combination thereof. The consumption data, labels or indicia associated with the consumption data, time of day, current weather (e.g., received from a local weather station or weather service), day of week, month, premises occupancy, or other historical data can be fed into a supervised machine learning algorithm or an unsupervised machine learning algorithm. As an example, XG boost or other regressor can be used, other boosting, regression models, or various other models / algorithms can be used.

[0133] The model can represent one or more probabilities and / or patterns that take into account current or past conditions of the system to predict future consumption, e.g., in the next few minutes, hours, day, five days, or other time period. In some cases, the predicted consumption prediction can be discounted or otherwise modified to account for reduced certainty for more distant dates. In some embodiments, the model can generate predicted consumption at various resolutions, e.g., in seconds, minutes, fifteen minutes, half hours, per hour, or other values, depending on management settings, processing power or time, or other factors.

[0134] As described above, data can be trained using various resolutions of data, e.g., second-level, sub-second, minute-level, etc. The consumption model(s) can be trained continuously (e.g., over a rolling time frame) or periodically (e.g., daily, weekly, hourly, etc.) using historical data within a defined time window, such as the previous day, previous month, previous year, or other time.

[0135] In some embodiments, one or more initial models trained based on data of similar sites or groups of sites (e.g., similar in size, usage level, location, etc.) can be used for a reference site. The initial model(s) can then be updated or trained using actual historical data of the reference site to create a consumption model specific to the node or site. Over time, the initial or current consumption model can be updated or retrained. For example, actual consumption data can be input into the training algorithm. The actual data can be compared to the predictions in order to generate an analysis or to improve the training.

[0136] In some embodiments, at 408, the system (e.g., training engine 114) can receive local weather data and forecasts for the node 140. For example, the system can determine a particular geographic location (e.g., based on latitude and longitude stored in a data file associated with the node 140) and can retrieve historical weather data, current weather data, and / or forecasted weather data for that location from one or more third-party sources (e.g., provided by third-party server(s) 118), such as the National Weather Service.

[0137] In some embodiments, the system can additionally or alternatively receive data from a local power generation station 143, such as a Tempest™ or other brand of internet-connected weather station at the location of the node 140. In some cases, historical or current data from a local power generation station 143 can provide correction information, offset information (e.g., indicating that the location is generally warmer, cooler, etc.), or more accurate information than the National Weather Service for a particular node 140. As described elsewhere herein, weather data can be used to train a model or set up an environment that uses a trained model.

[0138] In some embodiments, at 410, the system can receive local power production data from the node 140. For example, if the node 140 includes solar, wind, hydro, gas generator, or another source of energy production, the system can determine power production over time (e.g., with timestamps). It should be noted that this data and other data can be received as a batch of data describing a time period, or can be received in real-time, or otherwise determined in a data stream.

[0139] Similar to consumption data, power production data can be received or acquired from inverters, power meters, smart service panels, or other devices that report power production data, either directly or via other services (e.g., via an API of a server, etc.). Similar to consumption data, power production data can be received, determined, or processed at various resolutions of data (e.g., seconds, sub-seconds, one minute, fifteen minutes, or other resolutions). Power production data can be associated with various metadata (e.g., timestamps, source, environment (e.g., weather), or other data).

[0140] In some embodiments, solar or wind production data can be estimated based on a power production database(s) for the geographic location of the site. Additionally or alternatively, solar power can be determined based on actual production at the node 140 / site. As described below, different data sources can be combined or kept separate when they are used to train the second machine learning model.

[0141] In some embodiments, generic or reference data can be initially used until more local data is generated or received. As more and more data is received, the model(s) can be updated or retrained. Additionally or alternatively, different models can be used or trained using different data sets depending on the amount, consistency, or accuracy of the production data from the site, as described in further detail elsewhere herein.

[0142] In some embodiments, the system can also collect energy storage data associated with the node 140, such as battery charge state, energy capacity, discharge or charge rate, energy storage unit / device properties, etc. For example, the system can determine the current charge state and total energy capacity of a local chemical and / or mechanical battery.

[0143] In some embodiments, at 412, the system can train or otherwise determine a second model (e.g., a machine learning model, although other models are possible and contemplated herein, as described below) based on power production data about its environment for a given node 140 (e.g., based on how much power is produced in a given environment), such that an accurate assessment of a particular node 140 can be determined. For example, the system can combine power production data for a node 140 with weather data for the node 140 over time to generate a solar (or other) prediction model that can be used to predict future solar production for a given environment (e.g., a given weather pattern).

[0144] The system can combine the second model with weather forecast data for the node 140 to determine a prediction of future solar production for a future point in time (e.g., for a predicted weather pattern at the node 140).

[0145] Reference Figure 4B Further details of the operations for determining and / or training the production model at 412 are described, Figure 4B A flowchart showing an example method for determining a production model for a node 140 or site by the system (e.g., by the training engine 114) is shown. For example, the operations for determining the production model can be based on the amount of historical production data for the node 140, the local environment, weather consistency with other nodes 140, or other factors.

[0146] At 442, the system can determine one or more attributes of the node 140. Initially, the attributes can include whether a model has previously been established for the node 140, whether the node 140 has a threshold amount of historical data (e.g., power production data), or other information. In some cases, the attributes of the node 140 can indicate its geographic location, solar (or other power production) system size, whether it has a net metering agreement with a utility, or other, although some of these details can be determined during other operations in process 400. Figure 4B The attributes can be determined by retrieving data from the database 210, receiving user input, or by other means.

[0147] At 444, the system can determine a model type for the node 140 based on the attributes of the node 140. For example, if the node 140 is a new node 140 for which little to no historical power production data is available, a sparse data local model or a global model can be selected. If sufficient historical production data is available for the node 140, a local model can be determined. Other criteria for determining a model are further indicated below, such as based on the predictability of various models, proximity to attributes of other nodes 140, etc.

[0148] For example, at 446, a spatial data local model can be determined for the node 140. A sparse data model can be selected for a new node 140 for which little historical production data, weather data, or other environmental data is available. In some implementations, the system can select from a plurality of types of sparse data models for the node 140. This selection can be performed automatically based on, for example, default values, node 140 attributes, or user input.

[0149] At 448, the system can select a machine learning model that has previously been trained or will be trained for the node 140 using data that is not historical for the node 140 (e.g., because the data can not be available). For example, historical weather data for the geographic location of the node 140 can be collected and compared to non-specific power production data. For example, various services or databases can provide data or algorithms that indicate an estimated solar production for a location or larger area. For example, the system can utilize a database of solar production values that can be an average between a set of nodes 140, an amount defined based on an expected power generation for a time of year, or the solar production values can be based on a mathematical calculator or algorithm (e.g., as at 454 below).

[0150] Accordingly, at 450, the system can determine data that is not historical for the node 140, and at 452, a machine learning model can be trained for the node 140 that can be used to predict future production, as described elsewhere herein.

[0151] At 454, the system can select a physics-based mathematical model for predicting power production. For example, the model can receive inputs or attributes of the node 140, such as topography, angle or orientation of the panel, total solar panel capacity, etc.

[0152] For example, the system can use a National Renewable Energy Laboratory (NREL) algorithm, such as PVWatts™ or other algorithm, which can indicate past or forecast future solar production based on various inputs. An example PVWatts™ algorithm can take inputs such as DC system size, solar cell module type, array type, system losses, array tilt angle, and array azimuth angle. The system can also optimize the model based on DC to AC size array, inverter efficiency, effects of surrounding cover and snow on panels, or other details.

[0153] Additionally or alternatively, the system can use various other algorithms or calculators to calculate the estimated irradiance of the panel. For example, the estimated energy produced by the panel can be represented as , where E is the energy in kilowatt hours (kWh), A is the total area of the panel in square meters, r is the solar panel yield or efficiency percentage, H is the annual average solar radiation on a tilted panel (e.g., based on latitude, weather, etc.), and P is a performance ratio defined, which can be an expected loss constant (e.g., between 0.5 to 0.9, such as 0.75 as a default).

[0154] At 456, when calculating the model and / or predictions of the node 140, the system can determine inputs to the algorithm, equation, or calculator. These inputs include the attributes determined at 442 (one or more), the current state of the node 140 (e.g., weather data from a local weather station, recent or real-time solar production, or other data). In some implementations, the system (e.g., training engine 114) can train a machine learning model for one or more inputs to the mathematical algorithm or calculator in order to improve the accuracy of the defined node 140, set of nodes 140, or overall calculation. Thus, the precision of these algorithms or calculators can improve over time while the system still benefits from the efficiency of the calculator and smaller models for individual inputs.

[0155] In some embodiments, at 458, the system can select a global machine learning model that can be trained on a set of nodes 140 in a certain geographic region or based on other similarities. By using fewer models (e.g., across several or many nodes 140), the system can reduce training time and computation, facilitate cross-learning across nodes 140, more easily scale to additional nodes 140, and can allow for more accurate or easier model correction, although this type of modeling can not perfectly fit the nuances of a particular node 140.

[0156] For example, at 460, the system can determine one or more nodes 140 or a set of nodes 140 that share attributes (e.g., have a threshold similarity) with the reference node 140, and at 462, the system can identify one or more trained power generation models for the similar nodes 140. For example, two models can be trained for a first set of nodes 140 and a second set of nodes 140 in a given geographic region in which the reference node 140 is located. A first model can be trained for nodes 140 that have a net metering agreement, while a second model is trained for nodes 140 that do not have a net metering agreement. Thus, for example, if the reference node 140 has a net metering agreement, the system can select the corresponding machine learning model. It should be noted that although two models based on example attributes are described, other models and attributes are possible.

[0157] Thus, the system can use power production data from multiple nodes 140 to train a model that is then used to predict future power production for each individual node 140 in the set, or the system can be used for similar other nodes 140 (e.g., whose historical data was not used to train the model).

[0158] While other machine learning algorithms and models are possible, XG (eXtreme Gradient) Boost, gradient boosting, random forest, Profit™, or various other algorithms can be used to train the prediction model. The algorithms can use various inputs, such as those described with reference to 456, historical power production data, historical local weather (e.g., from a local weather station), historical regional data (e.g., from a weather service), or other environmental or data.

[0159] At 464, the system can select a local machine learning model to train for a particular node 140. For example, a local model can be trained in the event that other models (e.g., at 446 and 458) are not accurate enough, in the event that the node 140 has a threshold amount of historical power production and / or weather (or other environmental) data, or based on other criteria. For example, in the event that a solar panel array is placed on one side of a hill or on a ridge, local conditions (shade, trees, weather) can be significantly different from other nearby nodes 140, and thus a local machine learning model can be trained for the node 140. This selection can be based on administrator input, or can be automatically selected, e.g., based on reaching a defined amount of historical data for the node 140, or based on other models being inaccurate.

[0160] At 466, the system can aggregate historical local data, such as power production data for the node 140, local weather data, or other local environmental data, as described elsewhere herein. In some cases, the system can also aggregate other non-local data, such as power production calculator output, regional weather, inverter efficiency, etc., and can feed the data into the training algorithm to generate a production model for the node 140.

[0161] In some embodiments, the system can automatically identify missing data, e.g., time periods for which no power production data is recorded or received. The system can automatically match available data (power production data, environmental, weather, etc.) for the missing data time period with past data complete time periods. For example, the system can automatically search for similar time periods, and attribute data from these similar time periods to the missing data field / time period.

[0162] The system can use the local and / or other data to train a model for the node 140. Thus, the model for the node 140 is able to automatically identify more accurate effects of local weather versus regional weather, time of day, time of year, weather, or other factors on power production for the node 140.

[0163] Although other embodiments are possible, at 468, the system can train the local model using a light GBM (Gradient Boosting Model), XB boost, other gradient boosting algorithm, etc. For example, the system can use a random forest regressor for the local model, although other regressors can be used without departing from the scope of the present disclosure.

[0164] At 470, the system can calculate the accuracy of the power production model for any selected model type. For example, the system can compare actual power production for the node(s) 140 for a time period to the predicted values for that time period.

[0165] In some embodiments, based on model accuracy, acquisition of historical data, changing properties of nodes 140 or user settings, the system can select different models for nodes 140. For example, the system can use a global machine learning model by default, but if it determines that the global model is not accurate for node 140, the system can automatically train a node 140 specific model. It should also be understood that the accuracy of the model can change over time as additional data is acquired. For example, as data is input into the training algorithm(s), the local model can become more accurate.

[0166] Returning to Figure 4A In some embodiments, at 414, the system (e.g., the power management application or controller 254 of node 140) can calculate a predicted power difference for node 140 based on predicted power consumption and predicted power production for a given environment (e.g., at a given time, for a predicted weather, etc.). These predictions can be updated in real-time or periodically (e.g., every minute, every hour, every day, etc.) based on additional environmental data received from various data sources, such as updated weather information, updated occupancy or power consumption status of node 140 (e.g., a plugged in EV with a particular capacity and state of charge), etc. Thus, using predicted power consumption (e.g., power consumption dependent on weather and usage schedule) and predicted power production (e.g., weather dependent solar production of node 140), a prediction of power surplus or demand at a future point in time can be determined. The prediction can be determined for any future point in time at any time interval, for example, with decreasing accuracy over time, or increasing reliance on historical statistical data rather than data / analysis of current environment or predicted weather. For example, predictions can be made for fifteen minute time periods over the next five days, although other embodiments are possible and are contemplated herein. This data can be further based on baseline power consumption.

[0167] For example, based on the predicted power difference, mode or other data and calculations, the system can perform one or more automated operations, such as controlling the mode of node(s) 140, controlling consumption of controllable loads, sending or displaying directions to a user, or other operations, such as those described with reference to operations at 416, 418 and 420.

[0168] The predicted power difference can be determined for a particular time period (e.g., one day, five days, one week, etc.) at time intervals (e.g., second, minute, fifteen minute, etc. buckets). By subtracting predicted consumption from predicted production, or vice versa, a series of buckets and / or a differential curve can be generated.

[0169] According to embodiments, the total difference, integral, or area under the curve can be determined to identify production, consumption, storage over a period of time. The total difference over a time block can be compared to a battery capacity (e.g., of a chemical or mechanical battery) or a target battery charge range to determine whether the battery has sufficient available charge / capacity to cover excess power production or consumption over a period of time (e.g., which can be used as described below). The time block for determining power can be fixed or rolling (e.g., a moving window), or other embodiments are possible and contemplated.

[0170] The predicted power difference data is particularly powerful because it is specific to a given node 140, which can have very different consumption or production characteristics than another node 140 or site (e.g., a residence) in the next door, same community, same city, or elsewhere in the state, etc. Thus, as described below, a particular node 140 can be controlled to balance the energy consumption, production, or storage of that node 140. Similarly, many nodes 140 in a group or network of nodes 140 (e.g., a power grid) can be balanced relative to each other and / or relative to power production, storage, or use by a power utility provider. Using these predictions, the system can control how much energy a node 140 outputs, inputs, or stores, as described below.

[0171] In some embodiments, the system can determine a predicted state of charge of an energy storage unit of a node 140 based on a current state of charge of the energy storage unit and predicted power difference data over time. Thus, a future state of charge of the energy storage unit can be predicted. The system can determine a target state of charge of the energy storage unit and adjust a current power output or input of the node 140 based on the predicted power difference data to maintain the target state of charge of the energy storage unit at a future point in time.

[0172] As described in greater detail elsewhere herein, the predicted or target state of charge can be based on a buffer limit (e.g., a minimum or maximum percentage of energy stored), based on patterns or other data. For example, an energy storage unit can be set to a “storm preparedness” mode based on a weather forecast to increase the target state of charge in the event of a power outage. Similarly, the system can actively control power output / input from / to a node 140 / energy storage unit to actively balance power and reduce the “duck curve.”

[0173] It is noted that the energy storage unit can provide an electrical buffer, and the power input or output from / to the node 140 can be controlled by the system by increasing / decreasing consumption at a given time (e.g., by scheduling power consumption activities, such as controlling an EV charger, air conditioner, or refrigerator), increasing / decreasing storage or output of the energy storage unit, increasing / decreasing power production, or other ways.

[0174] Example power production, consumption, and / or difference values are described elsewhere herein. For example, example graphical user interfaces graphically illustrating production, consumption, and / or difference values are illustrated in the figures herein, e.g. Figures 8A to 9 The graphical user interfaces can also allow user interaction, display analytics, or perform other operations.

[0175] In some implementations, at 416, the system (e.g., the EaaS manager 110 or the power management application 111 or other component of the utility server 120) can aggregate predicted power consumption, power production, power difference, state of charge, available state of charge, or other data across multiple nodes 140. For example, the system can provide data and analytics to a power utility provider or other management entity that manages a group of nodes 140 (e.g., a virtual power plant consisting of multiple nodes 140). Thus, the provider can have an understanding of the power that will be needed, remaining, or available in storage at some future time. From this, the provider can determine when to increase or decrease power plants, when and at what rate to buy / sell power to another provider, etc. For example, the provider can control the group of nodes 140 to offset the demand of other customers of the grid, and balance power production over a region (e.g., where weather changes) or time (e.g., to flatten the duck curve).

[0176] The system can compare the predicted consumption data, production data, and / or difference data to actual production data to determine the accuracy of the model. For example, actual difference curves can be compared to predicted difference curves. The comparison data can be provided in one or more graphical user interfaces to inform stakeholders about the accuracy of the predictions. In some cases, the comparison can be used to determine when to retrain or update the model, how long the application of the prediction should be valid for (e.g., whether accuracy drops more than a defined threshold after three days, five days, or seven days), or other. For example, a time period for a node 140 pattern, power consumption, or other factor can be defined based on a determination of a time period of at least one threshold accuracy.

[0177] The data can be analyzed either for a particular node 140, a cluster of nodes 140, a geographic region, or otherwise analyzed in other ways to evaluate predictions, determine power demand across a cluster or utility, e.g., so that power production can be adapted to power surpluses or deficits at determined times. Thus, the utility server can proactively control utility or grid production (or usage across many devices) to charge nodes 140, discharge nodes 140, or otherwise adapt power production or consumption in certain locales, neighborhoods, or regions.

[0178] In some embodiments, at 418, the system (e.g., controller 254 of node 140, power management application 111, EaaS manager 110, etc.) can use the predicted power consumption, power production, power difference, state of charge, storage capacity, power cost, or other factors to control the mode of one or more nodes 140. For example, the mode of a node 140 can include whether the node 140 is in a power consumption or production state (or a value thereof), a state of charge of an energy storage unit, a buffer value or range of an energy storage unit, or other configuration. For example, the timing and amount of data used can be scheduled to minimize grid power used, balance power production / usage, minimize power cost, reach a target state of charge or range, or based on other factors. In cases where a node 140 includes a flywheel, the mode can cause the flywheel to increase or decrease its rotational speed depending on whether energy is being stored or released (e.g., by sending a signal to an inverter to drive or receive current from a motor coupled to the flywheel).

[0179] For example, the mode can define an amount of power to be used from the grid or energy storage, an amount of power from local power production or an energy storage unit to be output from the node 140 to the grid, a target state of charge, etc. The node 140 can be in a power saving mode, a battery charging mode, a storm preparation mode, a maximum power production and usage mode, etc. Thus, for a single mode or multiple nodes 140, the system can control the amount of power being used, stored, received from the grid, or output to the grid. The system can send instructions to an inverter of an energy storage unit to output a certain amount of power to the grid, receive a certain amount of energy from the grid, etc. Thus, the system can control the state of charge of an energy storage unit, etc. to balance energy usage in the grid and maximize energy savings and ecological benefits of the nodes 140. These controls can be based on a baseline power consumption.

[0180] For example, the system can use weather forecast data to predict a storm in two days to modify the power flow to / from a node 140. For example, one or both of the consumption model and production model can use weather forecast information to determine a future power difference, and also determine that at that future point, the node 140 can be placed in a storm mode in which the chemical and / or mechanical battery storage is higher to prevent a power outage. For example, if the node 140 is not capable of matching a target charge level, future consumption, or other, the system can instruct the node 140 to receive power from the grid and charge the battery (or dump power to the grid), e.g., in preparation for the predicted storm.

[0181] In another example, the system can use the predicted difference to predict that there will be excess power storage, production, or consumption at some point in the future. The system can track from the future point to the present or future point to determine when to switch modes of the node 140, e.g., using defined threshold rates of draw from the grid, output to the grid, rate of charging or discharging the battery (e.g., based on inverter capabilities), or other defined rates. Thus, the system can predict and proactively set the mode to change the charging, power input, power output, etc. of the node 140 for the predicted future consumption and / or production.

[0182] In some cases, the system can display a notification to the homeowner, administrator, or other stakeholder on a graphical user interface to indicate a change in mode, predicted excess consumption or production, or other details. In some cases, the user can manually change the mode or other details to change the prediction or behavior of the node 140. For example, the user can request a higher battery charge level, request an additional consumption event (e.g., EV charging, different HVAC settings, etc.) beyond the baseline.

[0183] Although the operations at 420 are described as following 418, the order can be changed or can be performed in parallel. For example, the consumption, production, and mode(s) of the node 140 can be modified in relation to each other in order to better utilize available power or capacity and / or reduce inconvenience.

[0184] In some implementations, at 420, the system (e.g., the controller 254 of the node 140, the power management application 111, the EaaS manager 110, etc.) can instruct power consumption of one or more nodes 140 or related devices based on the prediction or mode, e.g., the predicted difference data, the target and current charge states, etc. For example, due to excess power in the battery and / or grid at the current or predicted future point in time, the system can determine that the node 140 should be in a power consumption mode. Thus, for example, the system can instruct a smart connected device to activate to use the excess power, such as turning on a pool pump or heater, turning on an air conditioner, increasing current in an electric vehicle charger, etc. Thus, the system can provide local optimization of power consumption based on availability of renewable resources being generated, available battery capacity, or available power (e.g., during a power outage).

[0185] For example, controllable devices, schedules, or integrations can be determined, such as for those devices that produce the above-described non-baseline power production. The system can determine that there is excess production at a given time, and schedule the consumption of one or more of these devices to use the excess production at that time. Similarly, for example, the system can determine that there is excess / insufficient production at a given time, and move controllable devices away from that time. As an example, the system can send instructions to the HVAC controller 254 to pre-cool the premises during the afternoon when solar production is highest, in order to shift controllable power consumption events from low production time periods (e.g., at night). Device control can be performed based on predictions according to various thresholds, such as allowing the system to cool the premises to 65 degrees Fahrenheit but not below that temperature, or allowing the system to let the premises reach 80 degrees but not exceed that temperature.

[0186] In some implementations, adjustments to energy consumption can also be accomplished by outputting instructions to the user or requesting user authorization, such as using a graphical user interface indicating "now is a good time to do laundry" or "the system suggests charging your EV between 3 and 6 PM today." Similarly, the system can instruct devices or users to conserve energy at a particular time.

[0187] In some cases, the user can override the system's instructions or suggestions for the mode of the node 140 or power consumption. For example, the user can indicate that they want to charge the EV immediately or to a higher percentage (e.g., 100%) in preparation for a road trip. Or the user can change the HVAC settings to have a different level of comfort, etc.

[0188] Although control of the node 140 and devices is described in terms of power storage and consumption, it should be noted that in some cases the system can also control power production, whether affecting the amount of power received from the grid or power production by local devices (such as wind turbines or generators).

[0189] Figure 5A 、 Figure 5B 、 Figure 5C 、 Figure 5D and Figure 5E Example mobile graphical user interfaces 500a, 500b, 500c, 500d, and 500e are shown, respectively, which can be generated by the techniques described herein. For example, the interface can display forecasted energy consumption, solar production, and smart grid management. The interface can display five-day forecast data adjusted in 15-minute intervals, including: weather data, renewable energy production, home consumption, power rating, forecasted ESU power score, personalized energy use plan for the day, or other data.

[0190] Figure 5AThe example interface 500a shows weather forecasts and solar energy production projections. Figure 5A An example energy forecast for a given residence is shown. Interface 500a displays total forecasted electricity production, analysis scores (e.g., percentage of renewable electricity used, grid energy avoided, etc.) for the day and multiple time periods, as well as forecasted weather data. Figure 5B The example interface 500b displays weather forecasts and production projections for different selected dates. Example interface 500b also displays example scores or other analyses indicating the amount of electricity being used or saved from solar energy, batteries, the grid, or other sources.

[0191] Figure 5C The example interface 500c displays the predicted solar energy production, consumption, and deficit as a graph over time. In some cases, a portion of the graph can be selected to indicate the total production, consumption, or deficit for that period.

[0192] Figure 5C The system displays the predicted electricity production, consumption, and forecast score for the day. Interface 500c can display charts showing forecast weather, electricity production, and usage data. Interface 500c also provides users with options to define a power schedule for dispatching electricity load throughout the day. For example, the system can suggest charging EVs when ESU charging status and / or solar production are at their peak, and / or users can manually define a schedule. In some cases, the system can instruct smart devices, such as EV chargers, refrigerators, or other devices, to conform to the schedule.

[0193] Figure 5D The example interface 500d shows the actual or projected amount of solar energy produced, stored in batteries, and / or transmitted to the grid. For example, this data can be presented as text, line graphs, or bar graphs for different time periods. Figure 5E The example interface 500e displays text data indicating the total current sent to or received from various sources, the current to be processed, or the future current. The interface's colors, shading, or other details can be automatically updated to indicate comparisons of the data with defined thresholds.

[0194] Figure 6 An example mobile graphical user interface 600 that can be generated by the techniques described herein is shown. For example, interface 600 instructs the automatic adjustment and configuration of ESU or node 140 ESU modes using weather and energy forecast data. The system can command and control hardware via node 140, utilize AI algorithms to determine weather and energy forecast data, and enable clustered virtual power plants to monitor multiple nodes 140 or ESUs. Example modes may include self-consumption, battery priority, storm monitoring, off-grid, disconnect, grid sharing, grid stabilization, EV charging network, etc. As described above, modes can be set manually or automatically.

[0195] For example, Figure 6 The example interface 600 shown illustrates an indication of the current mode of the node 140. As shown, the "storm monitoring" mode is being used, during which the battery is being charged to 100% in preparation for a potential outage. As described above, this mode can be automatically selected based on weather forecast data, predicted power consumption, predicted power production, or other data. Another potential mode can be an off-grid mode in which the system uses only power stored in the battery or locally generated power, and in which the system automatically limits consumption of various devices, such as non-baseline loads.

[0196] For example, the interface can indicate that a storm is predicted at the location of the node 140 and request authorization to enter storm monitoring mode. The system can automatically detect an outage and transition to off-grid mode to use power stored in the ESU. In some cases, a notification can be sent to a stakeholder (such as a customer or administrator) that the mode has changed.

[0197] Figure 7 An example mobile graphical user interface 700 that can be generated by the techniques described herein is shown. For example, the interface 700 can indicate the current mode of the node 140 (e.g., the inverter of the node 140), such as self-consumption, battery priority, storm monitoring, auto-switch, EV charging, overcast, etc. Various modes or preferences can be input by a user via the interface 700 and / or automatically selected based on consumption, production, or difference predictions of the node 140, although other embodiments are possible and contemplated herein.

[0198] Figures 8A to 9 A graphical user interface that can be generated by the techniques described herein is shown to present current, past, or future performance of the node 140.

[0199] For example, Figure 8A A graphical user interface 800a is depicted that shows an example graph 802a that indicates current and historical battery storage, grid usage, home consumption, and solar power generated over time, as indicated by the illustrated legend 804. The interface 800a can also indicate that the battery is charging during the day. For example, the interface 800a can display a pop-up window 806 or overlay that indicates the current or predicted mode of the node 140 (e.g., sunny mode - charging from the sun). In some cases, the pop-up window 806 can allow a user to override the automatically determined node 140.

[0200] Figure 8BA graphical user interface 800b is depicted showing an example graph 802b that shows data similar to interface 800a, which can emphasize that there is a storm in the forecast and suggest reducing power consumption to ensure that battery power remains high. For example, an overlay or pop-up window 808 can indicate that a storm is expected and that the system will adjust its mode to prepare for the storm. In some cases, the system can determine and automatically time-shift non-baseline loads. In some cases, interface 800b can provide the user with general or specific suggestions for time-shifting loads (e.g., “defer use of high-power appliances if possible”).

[0201] Figure 8C A graphical user interface 800c is depicted showing an example graph 802c that shows data similar to interface 800a, which can display additional information in an overlay or pop-up window 810. For example, interface 800c shows forecasted solar production, energy consumption, and displays a fraction of how much energy is being used from local production (e.g., total power generated divided by energy consumed). Window 810 can indicate an analysis of these values, which can be a sum for the displayed time period. For example, window 810 can display total solar production, total consumption, and a fraction (e.g., percentage of locally produced power used). In cases where some or all of the displayed data is forecasted (e.g., future), the analysis and / or graph can indicate or include a forecast (e.g., that node 140 will use 75% locally produced power and 25% grid power).

[0202] Figure 8D A graphical user interface 800d is depicted showing an example graph 822 and table 824. Interface 800d can show historical energy usage, consumption, and production over a period of time. Interface 800d also shows forecasted solar production over time, but it can additionally or alternatively show energy / power difference, forecasted and / or target battery state of charge, or other information.

[0203] Table 824 can also depict timestamp information for various time periods to show a fraction or percentage of locally produced energy used, consumption, solar production, power from the grid, power to the grid, and power to storage, although other data points are possible.

[0204] Figure 9A graphical user interface 900 showing example graph 902 is depicted. Based on the operations described above, the graph can show the actual solar production of node 140, overlaid with the predicted solar forecast. In some embodiments, the difference between the actual curve and the predicted curve can be calculated to determine the accuracy of the forecast. In some cases, the difference and / or accuracy can be aggregated across multiple nodes 140 in order to evaluate the forecast model accuracy.

[0205] In the foregoing description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the technology. It will be apparent, however, to one skilled in the art that the technology described herein can be practiced without these specific details.

[0206] Reference in the specification to "one embodiment", "an embodiment", "some embodiments" or "other embodiments" means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the disclosure. The appearances of the phrase "in one or more embodiments" or "in some or other embodiments" in various places in the specification are not necessarily all referring to the same embodiment.

[0207] Furthermore, it is to be understood that variations, combinations, and equivalents of the particular implementations, embodiments, and examples described herein fall within the scope of the present disclosure. Thus, the present disclosure should not be limited by the foregoing description, but only by the scope of the patent and the spirit of the present disclosure.

Claims

1. A computer-implemented method comprising: receiving, by one or more processors, power consumption data for one or more nodes, the one or more nodes comprising one or more meters for determining a set of power consumption data, each of the one or more nodes comprising an energy storage unit, the energy storage unit comprising one or more of a mechanical battery and a chemical battery; determining, by the one or more processors, a subset of the set of power consumption data that does not include power consumption data for one or more controllable loads, the set of power consumption data being determined from the one or more controllable loads; training, by the one or more processors, a first machine learning model to predict future power consumption based on the subset of the set of power consumption data; receiving, by the one or more processors, environmental data for the one or more nodes, the environmental data comprising local weather data and weather forecast data for the one or more nodes; receiving, by the one or more processors, local power production data for the one or more nodes, the local power production data being determined for one or more solar panels electrically coupled to the energy storage unit; training, by the one or more processors, a second machine learning model using the local power production data and the local weather data; calculating, by the one or more processors, a predicted power difference for the one or more nodes at a future time based on the weather forecast data, the first machine learning model, and the second machine learning model; controlling, by the one or more processors, a mode of the one or more nodes based on the predicted power difference at the future time, the mode defining whether the one or more nodes perform one or more of receiving electrical power, storing electrical power, or outputting electrical power; and indicating, by the one or more processors, power consumption of the one or more controllable loads of the one or more nodes based on the predicted power difference at the future time.

2. A computer-implemented method comprising: determining, by one or more processors, a consumption model for a node, the consumption model predicting future power consumption of the node; receiving, by the one or more processors, environmental data for the node, the environmental data comprising weather forecast data for the node; determining, by the one or more processors, a production model for the node, the production model predicting future power production of the node using the weather forecast data for the node; calculating, by the one or more processors, a predicted power difference for the node at a future time based on the predicted power consumption, the predicted power production, and the environmental data for the node; and performing, by the one or more processors, one or more automated operations using the predicted power difference.

3. The computer-implemented method of claim 2, wherein: the consumption model for the node comprises a first machine learning model, the first machine learning model being trained based on power consumption data for one or more loads electrically coupled to an energy storage unit of the node.

4. The computer-implemented method of claim 2, further comprising: ​ receiving, by the one or more processors, power consumption data for the node, the node including one or more meters for determining a set of power consumption data; determining, by the one or more processors, a baseline power consumption for the node using a subset of the set of power consumption data; and training, by the one or more processors, a first machine learning model to predict the future power consumption based on the subset of the set of power consumption data.

5. The computer-implemented method of claim 4, wherein: the subset of the power consumption data does not include one or more controllable loads from which the set of power consumption data is determined.

6. The computer-implemented method of claim 2, wherein: the environmental data includes local weather data for the node received from a local power station, the local weather data informing one or more of the consumption model and the production model for the node.

7. The computer-implemented method of claim 6, further comprising: receiving, by the one or more processors, local power production data for the node; and training, by the one or more processors, a second machine learning model using the local power production data and the local weather data, the production model including the second machine learning model.

8. The computer-implemented method of claim 2, wherein: the production model includes a second machine learning model trained using power production data and environmental data for one or more second nodes having one or more attributes in common with the node.

9. The computer-implemented method of claim 2, further comprising: aggregating, by the one or more processors, predicted power differences for a plurality of nodes, the predicted power differences including the calculated power difference for the node; generating, by the one or more processors, one or more analyses based on the predicted power differences for the plurality of nodes; and providing, by the one or more processors, one or more graphical user interfaces that graphically illustrate the one or more analyses.

10. The computer-implemented method of claim 2, wherein, performing the one or more automated operations using the predicted power difference includes: controlling, by the one or more processors, a mode for the node based on the predicted power difference for a future time, the mode defining whether the node performs one or more of receiving electrical power, storing electrical power, or outputting electrical power.

11. The computer-implemented method of claim 2, wherein, performing the one or more automated operations using the predicted power difference includes: indicating, by the one or more processors, power consumption for one or more controllable loads of the node based on the predicted power difference.

12. A system comprising: an energy storage unit including: a battery that stores energy mechanically or chemically; an inverter coupled with the battery and converts direct current from the battery to alternating current; and a controller communicatively coupled with the inverter, the controller controlling one or more functions of the battery; and one or more processors executing instructions that cause the one or more processors to perform operations comprising: determining a consumption model for a node, the consumption model predicting future power consumption for the node; receiving environmental data for the node, the environmental data including weather forecast data for the node; determining a production model for the node, the production model predicting future power production for the node using the weather forecast data for the node; calculating a predicted power difference for the node at a future time based on the predicted power consumption, the predicted power production, and the environmental data for the node; and performing one or more automated operations using the predicted power difference.

13. The system of claim 12, wherein: the consumption model for the node includes a first machine learning model trained based on power consumption data for one or more loads electrically coupled to an energy storage unit of the node.

14. The system of claim 12, wherein, the operations further include: receiving power consumption data for the node, the node including one or more meters used to determine a set of power consumption data; determining a baseline power consumption for the node using a subset of the set of power consumption data; and training a first machine learning model to predict future power consumption based on the subset of the set of power consumption data.

15. The system of claim 14, wherein: the subset of power consumption data does not include one or more controllable loads from which the set of power consumption data is determined.

16. The system of claim 12, wherein: the environmental data includes local weather data for the node received from a local power station, the local weather data informing one or more of the consumption model and the production model for the node.

17. The system of claim 16, wherein, the operations further include: receiving local power production data for the node; and training a second machine learning model using the local power production data and the local weather data, the production model including the second machine learning model.

18. The system of claim 12, wherein, the operations further include: aggregating predicted power differences for a plurality of nodes, the predicted power differences including the calculated power difference for the node; generating one or more analyses based on the predicted power differences for the plurality of nodes; and providing one or more graphical user interfaces that graphically illustrate the one or more analyses.

19. The system of claim 12, wherein, performing the one or more automated operations using the predicted power difference includes: controlling a mode for the node based on the predicted power difference at a future time, the mode defining whether the node performs one or more of receiving electric power, storing electric power, or outputting electric power.

20. The system of claim 12, wherein, performing the one or more automated operations using the predicted power difference includes: indicating power consumption for one or more controllable loads of the node based on the predicted power difference.

Images