Energy Management with Opta™

This application note describes how to implement Opta™ for a domestic energy management system.

Introduction

The Opta™ can be an irreplaceable support for home energy management. Getting information on instantaneous electrical consumption and interacting with the customer’s consumption plan, daily usage statistics, and seasonal forecasts can help in planning and managing electrical devices to optimize energetical efficiency. Always be connected and informed by integrating the Arduino Cloud, and add self-adjustment capability by monitoring and logging electrical statistics along with the option to operate the connected devices on-demand based on pre-set triggers.

As the industry shifts towards Industry 4.0, also known as the Industrial Internet of Things (IIoT), the focus is on improved energy management and the ability to operate devices on-demand within power grids. This transition promises significant cost savings and enhanced production performance. Opta™ prioritizes security, featuring elements that ensure data integrity, encryption, and secure certificate storage. This makes it a suitable IoT node for creating a private and secure IIoT network.

Goals

This application note shows an example of an energy management system, leveraging Opta™ and Arduino Cloud capabilities to perform the following operations:

  • Allow Opta™ to receive and process remote actuation commands from the Arduino Cloud
  • Enable Opta™ to control devices based on the user's energy consumption patterns and the energy available from solar panels or any other power sources
  • Automate the operation of home appliances by considering user demands, power availability, and energy efficiency

Below is a visual representation of the intended application:

Graphical representation of the energy management application
Graphical representation of the energy management application

Hardware and Software Requirements

Hardware Requirements

  • Opta™ PLC with RS-485 support: Opta™ RS485, or Opta™ WiFi (x1)
  • USB-C® cable (x1)
  • 7M.24 Energy meter (x1)
  • Solar panel with respective system (Controller, battery, and inverter) or similar power system
  • Domestic appliances or devices of interest
  • RS-485 connection wire as recommended by the standard specification (x3):
  • STP/UTP 24-18AWG (Unterminated) 100-130 Ω rated
  • STP/UTP 22-16AWG (Terminated) 100-130 Ω rated

Software Requirements

Hardware Setup Overview

The electrical connections of the intended application design are shown in the diagram below:

Electrical connections of the application
Electrical connections of the application

The Opta™ system will access real-time consumption details from the energy meter, using the Modbus RTU over the RS-485 interface. Power from the solar panels undergoes multiple processes before it reaches the energy meter. Household appliances can be managed using the Opta™ system's built-in relay functions. It is also worth noting that other power sources can replace the solar panels.

Opta™ Energy Management Model Description

The main role of Opta™ is to efficiently handle power, using data from the energy meter linked to the solar panel as its basis. It fetches and processes data from the energy meter, estimating real-time consumption based on the meter's thresholds and the current power output of the solar panel.

For this application, we are using the 7M.24 energy meter model from Finder. You can access its datasheet here. This model communicates via the Modbus RTU on the RS-485 interface. The relay functions of Opta™ will operate the relevant household appliances. To gather data and oversee power allocation, Opta™ carries out the following steps:

  • Procure voltage and current readings from the energy meter.
  • Gather three types of power readings from the energy meter: Active Power Total - Pt (
    W
    )
    , Reactive Power Total - Qt (
    var
    )
    , and Apparent Power Total - St (
    VA
    )
    .
  • Organize the collected data on Voltage, Current, and Power (Active, Reactive, and Apparent) into various categories to represent the Actual, Average, Maximum, and Minimum values of each.
  • Access the Energy Counter figures in
    Wh
    and
    varh
    units.
  • Distribute power optimally to regulate selected household appliances, based to the user's energy profile.

While all these processes are handled by Opta™ locally, it is also connected to the Arduino Cloud through Wi-Fi®. This connection allows users to view their energy usage and remotely control connected devices via the Arduino Cloud.

Opta™ Energy Management Example Code

The provided code showcases the capabilities of Opta™ as described earlier. It is worth noting that some code functions are generated by the Arduino Cloud during dashboard configuration. For immediate access to the full example, the files can be downloaded here. We will now delve into key code components to break down how the example code works.

The code requires the inclusion of specific headers. These headers enable the RS-485 interface, the Modbus RTU protocol, the Arduino Cloud connection, and the scheduler. The scheduler oversees data exchange through the RS-485 interface using the Modbus RTU protocol. Moreover, it includes the parameters essential for stable communication, adhering to Modbus RTU standards.

1#include "stm32h7xx_ll_gpio.h"
2#include "thingProperties.h"
3#include <ArduinoModbus.h>
4#include <ArduinoRS485.h>
5#include <Scheduler.h>
6
7#define F7M24 0x21
8#define pause_trigger 15
9
10// Energy Meter Parameters
11float V_actual, V_avg, V_max, V_min;
12float A_actual, A_avg, A_max, A_min;
13float W_actual, W_avg, W_max, W_min;
14float Var_actual;
15float Va_actual, Va_avg, Va_max, Va_min;
16float Wh_packet, Varh_packet, Wh_Abs_packet;
17
18typedef struct uPWR_STRUCT {
19 float uV_code;
20 float uW_code;
21 float uWh_code;
22} PWR_STRUCT;
23PWR_STRUCT user_profile;
24
25/**
26 ======================= IMPORTANT =======================
27 Before using the system, the following parameters MUST be defined:
28
29 - operation_safety_margin: Multiplier indicating safety margin. E.g., 1.1 implies a 10% headroom.
30 - estimated_max_power: Expected maximum power (in Watts) under which the network will operate.
31 - estimated_max_energy: Expected maximum active energy limit (in Wh) for the network.
32 - Device_1_Limiter & Device_2_Limiter: Upper limit current (in Amperes) and power (in Watts) for Device 1 & 2 respectively.
33 - Device_1_CompRef & Device_2_CompRef: Energy meter parameters required for accurate system operation.
34*/
35float operation_safety_margin = 1.1;
36float estimated_max_power = 220;
37float estimated_max_energy = 2880;
38float Device_1_Limiter = 1;
39float Device_2_Limiter = 100;
40float Device_1_CompRef = A_actual;
41float Device_2_CompRef = W_avg;
42/*
43 It is CRUCIAL to set these parameters accurately to ensure safe and correct operation of the system.
44 =========================================================
45*/
46
47constexpr auto baudrate { 19200 };
48
49// Calculate preDelay and postDelay in microseconds as per Modbus RTU Specification
50// MODBUS over serial line specification and implementation guide V1.02
51// Paragraph 2.5.1.1 MODBUS Message RTU Framing
52// https://modbus.org/docs/Modbus_over_serial_line_V1_02.pdf
53constexpr auto bitduration { 1.f / baudrate };
54constexpr auto preDelayBR { bitduration * 9.6f * 3.5f * 1e6 };
55constexpr auto postDelayBR { bitduration * 9.6f * 3.5f * 1e6 };

It is vital to configure the user parameters correctly to ensure appropriate system operation. Such parameters are:

  • operation_safety_margin
    : This is the safety margin multiplier factor. It is expressed in decimal format. For instance, to have a 20% safety buffer, the input should resemble
    1.2
    .

  • estimated_max_power
    : It is the anticipated maximum power (measured in Watts) under which the network will operate. It serves to set a benchmark average power based on user input, which is then compared to the energy meter reading. This helps verify if the network is running in line with the desired electrical attributes set by the user.

  • estimated_max_energy
    : Similar to
    estimated_max_power
    , this parameter marks the forecasted maximum active energy limit (in Wh) for the network. Its role is to ensure that the network remains stable in delivering consistent power to the connected devices.

  • Device_X_Limiter
    : This sets the maximum limit for a chosen parameter for devices 1 & 2. Its definition should align with that of the
    Device_X_CompRef
    .

  • Device_X_CompRef
    : It is the reference value obtained from energy meter used to determine whether the device, considering priority parameter type, can be activated for accurate system operation.

For a deeper understanding of implementing Modbus RTU with Opta™, consider the tutorial Getting Started with Modbus RTU on Opta™.

The method

relay_Trigger()
performs a straightforward comparison between a
desired target
and a
required target
. Based on this comparison, it outputs a signal to activate a relay. It will also help the user know if the system is at stable capacity or having possible electrical disturbances that may cause unstable operation.

The user specifies the

desired target
value, which indicates the optimal threshold limit for the relay's activation to maintain stable operation. On the other hand, the
required target
signifies the current power or other relevant electrical parameter reading introduced as an argument from the user.

It works as a two-flag condition, using the safety margin percentile to ensure electrical headroom is available without putting undue strain on the system. An example metric obtained from the energy meter for this purpose is

W_actual
, which represents the real-time total active power at the time of inquiry.

The

user_profile.uV_code
defines the operational buffer in terms of percentage. This is the safety margin multiplier factor derived from the user's profile. For instance, setting the margin at 10% as
1.1
within the
consumption_profile()
method offers a safety overhead headroom. This method's parameters come preset but can be adjusted later via the Arduino Cloud dashboard.

The

relayTarget
defines the output port prompted under certain activation conditions.

1/**
2 Control the relay output based on the user (consumption) profile input and configured power/energy target.
3
4 @param desired_target Desired resource required to run the connected device on the relay.
5 @param req_target Minimum resource required to run the connected device on the relay.
6 @param relayTarget Relay to activate or deactivate.
7 @return Returns 0 or 1, representing HIGH state for 1 and LOW state for 0.
8*/
9uint8_t relay_Trigger(int desired_target, int req_target, pin_size_t relayTarget) {
10 bool isStable = (desired_target >= req_target) && (desired_target > (req_target * user_profile.uV_code));
11 digitalWrite(relayTarget, isStable ? HIGH : LOW);
12 Serial.print(F("Energy Manager: "));
13 Serial.print(isStable ? F("Stable operation margin") : F("Unstable / possible overload"));
14 Serial.print(F(" - Turning "));
15 Serial.print(isStable ? F("ON: ") : F("OFF: "));
16 Serial.println(relayTarget);
17
18 return isStable ? 1 : 0;
19}
20
21/**
22 Initial user profile setup.
23
24 @param init_OperMargin System operation margin for power budget represented in percentage.
25 @param init_Watt User defined Wattage limit for the system.
26 @param init_WhCon User defined Energy consumption limit for the system.
27 @return none
28*/
29void consumption_profile(uint32_t init_OperMargin, uint32_t init_Watt, uint32_t init_WhCon){
30 uOperMargin = init_OperMargin;
31 user_profile.uV_code = uOperMargin;
32
33 uWatt = init_Watt;
34 user_profile.uW_code = uWatt;
35
36 uWhCon = init_WhCon;
37 user_profile.uWh_code = uWhCon;
38}

The function

energy_distro_ctrl()
uses energy meter data and user inputs from the Arduino Cloud to manage connected devices, offering options to override relay activation and monitor the system's power capacity. Its decisions are mainly based on two conditions related to energy and power.

This ensures that devices operate when energy consumption is within a range that is 10% below the maximum safe operation level. The

handleDevice()
function streamlines parameter adjustments and troubleshooting for each device state, facilitating desired relay activation.

If the average power demand surpasses the predefined user profile threshold, the system will send an alert to the user. This application note takes into account specific data from the devices used, serving as a proof of concept for this scenario.

The

Device #1
is configured for low-power devices that need a consistent current or the existing power to switch on securely. Users also have the option to control it remotely.

The

Device #2
caters to devices with higher power demands. It will begin its operations if the current or average power available meets the specified power requirement.

1/**
2 Handler functions for energy_distro_ctrl() function
3*/
4bool handleDevice(float threshold, float parameter_reference_data, int pin) {
5 bool deviceFlag = relay_Trigger(threshold, parameter_reference_data, pin);
6 if (!deviceFlag) {
7 if (relay_Trigger(threshold, W_actual, pin)) {
8 Serial.println(deviceFlag == Device_1_f ? F("Energy Manager: Secondary condition pass, may be unstable") : F("Energy Manager: Secondary Power condition pass"));
9 } else {
10 Serial.println(F("Energy Manager: Insufficient resource"));
11 digitalWrite(D0, LOW);
12 }
13 } else {
14 Serial.println(F("Energy Manager: Conditions green"));
15 }
16 return deviceFlag;
17}
18
19/**
20 Monitors and uses the user defined profile and retrieved information from Energy meter to manage connected devices of interest.
21
22 @param Wh_packet Retrieved energy information from Energy meter in unit of [Wh].
23 @param Device_#_f Device flag controlled by relay_Trigger() function. # specifies device number or designation.
24 @param directOverride1 Direct override flag for Device #1 controlled via Cloud.
25 @param W_avg Average power information retrieved from Energy meter.
26 @param Device_X_Limiter User defined upper limit value for selected device parameter.
27 @param Device_X_CompRef User selected Energy Meter parameter reading to be compared as a reference for device actuation and system behavior.
28*/
29void energy_distro_ctrl() {
30 if (Wh_packet != 0) {
31 uWhOpta = Wh_packet;
32 } else {
33 Serial.println(F("Energy Manager: Energy information recollection stand-by"));
34 return;
35 }
36
37 if ((Wh_packet * user_profile.uV_code) <= user_profile.uWh_code) {
38 Device_1_f = handleDevice(Device_1_Limiter, Device_1_CompRef, D0);
39 Device_2_f = handleDevice(Device_2_Limiter, Device_2_CompRef, D1);
40 } else {
41 digitalWrite(D0, LOW);
42 digitalWrite(D1, LOW);
43 Serial.println(F("Energy Manager: Energy consumption is high! - Warning"));
44 }
45
46 if (directOverride1) {
47 Serial.println(F("Energy Manager: Direct Override Request Received"));
48 digitalWrite(D0, HIGH);
49 }
50
51 if ((W_avg * user_profile.uV_code) > user_profile.uW_code) {
52 Serial.println(F("Energy Manager: Average Power is above profile limit! - Warning"));
53 Serial.println(W_avg * user_profile.uV_code);
54 }
55}

The energy meter contains multiple register addresses that provide a broad spectrum of electrical data. In this application, we will focus on the following key elements:

  • Voltage (
    V
    )
  • Current (
    A
    )
  • Total Active Power (
    W
    )
  • Total Reactive Power (
    var
    )
  • Total Apparent Power (
    VA
    )
  • Energy measured in both
    Wh
    and
    varh
  • Total Absolute Active Energy (
    Wh
    )

The information will be categorized, if applicable, as:

  • actual
    : Represents the captured real-time data.
  • average
    : Represents the mean data value over the operation duration.
  • maximum
    : Represents the peak data value observed during active operation.
  • minimum
    : Represents the lowest data value detected throughout active operation.
1/**
2 Requests and retrieves actual electrical, and power information from Energy meter over Modbus RTU protocol.
3*/
4void modbus_com_actual(){
5 // Actual Measurements
6 // Voltage (V)
7 V_actual = getT5(F7M24, 30107);
8
9 // Current (A)
10 A_actual = getT5(F7M24, 30126);
11
12 // Active Power Total - Pt (W)
13 W_actual = getT6(F7M24, 30140);
14
15 // Reactive Power Total - Qt (var) (IEEE 754)
16 Var_actual = getT_Float(F7M24, 32544);
17
18 // Apparent Power Total - St (VA)
19 Va_actual = getT5(F7M24, 30156);
20}
1/**
2 Requests and retrieves energy information from Energy meter over Modbus RTU protocol.
3*/
4void modbus_com_energy(){
5 // Energy
6 // Energy (Wh) - n1
7 Wh_packet = getT_Float(F7M24, 32752);
8
9 // Energy (varh) - n4
10 Varh_packet = getT_Float(F7M24, 32758);
11
12 // Total Absolute Active Energy (Wh)
13 Wh_Abs_packet = getT_Float(F7M24, 32760);
14}

To enable Modbus RTU on Opta™, use the

RTU_Setup()
function, which ensures proper initialization of the protocol.

1/**
2 Sets up Modbus RTU protocol configuration.
3*/
4void RTU_Setup(){
5 Serial.println("Energy Management - Modbus RTU Client");
6
7 RS485.setDelays(preDelayBR, postDelayBR);
8
9 // start the Modbus RTU client
10 // 7M.24 Energy meter specifies 19200 of default baudrate and 8N2 frame
11 if (!ModbusRTUClient.begin(baudrate, SERIAL_8N2)) {
12 Serial.println("Failed to start Modbus RTU Client!");
13 while (1)
14 ;
15 }
16}

The provided functions are designed for data retrieval from a target device via the Modbus RTU protocol. Each function is designed to fetch specific data types from the device using distinct register addresses.

By indicating the device and the register address, these functions simplify the process of accessing data from devices that communicate through Modbus RTU. We will employ these functions to extract data from the 7M.24 energy meter.

1/**
2 Obtains T5 data type variable
3
4 @param dev_address Device address.
5 @param base_reg Register address.
6*/
7float getT5(int dev_address, int base_reg) {
8 ModbusRTUClient.requestFrom(dev_address, INPUT_REGISTERS, base_reg - 30000, 2);
9
10 while(!ModbusRTUClient.available()) {}
11
12 uint32_t rawreg = ModbusRTUClient.read() << 16 | ModbusRTUClient.read();
13 int8_t reg_exp = ((uint8_t*)&rawreg)[3];
14 uint32_t reg_base = rawreg & 0x00FFFFFF;
15 float reg = reg_base * pow(10, reg_exp);
16
17 return reg;
18}
19
20/**
21 Obtains T6 data type variable
22
23 @param dev_address Device address.
24 @param base_reg Register address.
25*/
26float getT6(int dev_address, int base_reg) {
27 ModbusRTUClient.requestFrom(dev_address, INPUT_REGISTERS, base_reg - 30000, 2);
28
29 while(!ModbusRTUClient.available()) {}
30
31 uint32_t rawreg = ModbusRTUClient.read() << 16 | ModbusRTUClient.read();
32
33 int8_t reg_exp = ((uint8_t*)&rawreg)[3];
34 int32_t reg_base = (int32_t)rawreg & 0x007FFFFF;
35 if(rawreg & 0x800000) {
36 reg_base = -reg_base;
37 }
38 float reg = reg_base * pow(10, reg_exp);
39
40 return reg;
41}
42
43/**
44 Obtains T2 data type variable
45
46 @param dev_address Device address.
47 @param base_reg Register address.
48*/
49float getT2(int dev_address, int base_reg) {
50 ModbusRTUClient.requestFrom(dev_address, INPUT_REGISTERS, base_reg - 30000, 1);
51 while(!ModbusRTUClient.available()) {}
52
53 int16_t rawreg = ModbusRTUClient.read();
54
55 return (float)rawreg;
56}
57
58/**
59 Obtains T_Float data type variable
60
61 @param dev_address Device address.
62 @param base_reg Register address.
63*/
64float getT_Float(int dev_address, int base_reg) {
65 ModbusRTUClient.requestFrom(dev_address, INPUT_REGISTERS, base_reg - 30000, 2);
66
67 while(!ModbusRTUClient.available()) {}
68
69 uint32_t rawreg = ModbusRTUClient.read() << 16 | ModbusRTUClient.read();
70 float reg;
71 memcpy(&reg, &rawreg, sizeof(float));
72
73 return reg;
74}

These functions aim to fetch and handle data types

T5
,
T6
,
T2
, and
T_float
.

  • T5
    : 32-bit Unsigned Measurement
  • T6
    : 32-bit Signed Measurement
  • T2
    : 16-bit Signed Value
  • T_float
    : 32-bit IEEE754 Floating-Point Single Precision Value

For incorporating or using 7M.24 energy meter parameters with different data types, refer to the Modbus Data Types section on page 19 of the 7M.24 Modbus protocol sheet.

The

iot_cloud_setup()
function serves as the connection bridge between the Arduino Cloud and Opta™. By grouping the processes into one task, the code is streamlined and easier to maintain.

1/**
2 Sets up configuration for Arduino Cloud
3*/
4void iot_cloud_setup(){
5 // Defined in thingProperties.h
6 initProperties();
7
8 // Connect to Arduino Cloud
9 ArduinoCloud.begin(ArduinoIoTPreferredConnection);
10
11 /*
12 The following function allows you to obtain more information
13 related to the state of network and IoT Cloud connection and errors
14 the higher number the more granular information you’ll get.
15 The default is 0 (only errors).
16 Maximum is 4
17 */
18 setDebugMessageLevel(2);
19 ArduinoCloud.printDebugInfo();
20}

The Opta™ will initialize the RS-485 interface and Modbus RTU protocol, the Arduino Cloud connection, and the scheduler to handle Modbus RTU protocol based communication with the 7M.24 energy meter. Analog and Digital I/Os are configured here as well.

The

consumption_profile()
chracterizes the headroom margin for operation, power, and energy limit. The parameters, set through
operation_safety_margin
,
estimated_max_power
, and
estimated_max_energy
, serve as the standard local configuration and can be accessed on the Arduino Cloud dashboard.

1void setup() {
2 // Initial Parameter
3 directOverride1 = false;
4 uWhOpta = 0;
5
6 Serial.begin(9600);
7 delay(1000);
8
9 // Analog/Digital IO Port Configuration
10 analogIO_Setup();
11 digitalIO_Setup();
12
13 // Modbus RTU Configuration
14 RTU_Setup();
15
16 // Status LED configuration;
17 plc_led_Setup();
18
19 // IoT Cloud Setup
20 iot_cloud_setup();
21
22 // Configures user profile and controlled device parameters
23 consumption_profile(operation_safety_margin, estimated_max_power, estimated_max_energy);
24
25 // Only for Device On State flag
26 digitalWrite(LEDG, HIGH);
27
28 // Scheduler -> ModBus
29 Scheduler.startLoop(modbus_line);
30}

The Opta™ will have the main

loop()
to prioritize tasks to communicate with Arduino Cloud and local processes. It will have the job of managing profile data and energy distribution control logic with Arduino Cloud instance updates. While the
modbus_line()
will focus on handling Modbus RTU protocol-based communication over the RS-485 interface.

The

modbus_com_monitor()
serves to display all the essential electrical information obtained via 7M.24 energy meter,

1void loop() {
2 // Cloud exchange
3 consumption_var_container();
4 ArduinoCloud.update();
5
6 // Profile based energy management tasks
7 energy_distro_ctrl();
8
9 // Serial print of the data from the Energy Meter
10 modbus_com_monitor();
11
12 delay(500);
13}
14
15/**
16 Dedicated function for scheduler to retrieve Energy meter's information over Modbus RTU protocol
17*/
18void modbus_line(){
19 modbus_com_actual();
20 modbus_com_avg();
21 modbus_com_max();
22 modbus_com_min();
23 modbus_com_energy();
24}

The header that includes the Arduino Cloud properties is outlined below. This file comes from the Arduino Cloud platform within the sketch's workspace. It requires prior configuration of Opta™. Due to project specifications, these properties are subject to changes.

If Opta™ was configured to use Wi-Fi® connectivity as the network interface, the

thingProperties.h
header will resemble as follows.

1// Code generated by Arduino Cloud, DO NOT EDIT.
2
3#include <ArduinoIoTCloud.h>
4#include <Arduino_ConnectionHandler.h>
5
6const char SSID[] = SECRET_SSID; // Network SSID (name)
7const char PASS[] = SECRET_OPTIONAL_PASS; // Network password (use for WPA, or use as key for WEP)
8
9void onUOperMarginChange();
10void onUWattChange();
11void onUWhConChange();
12void onDirectOverride1Change();
13
14float uOperMargin;
15float uWatt;
16float uWhCon;
17float uWhOpta;
18bool directOverride1;
19
20void initProperties(){
21
22 ArduinoCloud.addProperty(uOperMargin, READWRITE, ON_CHANGE, onUOperMarginChange);
23 ArduinoCloud.addProperty(uWatt, READWRITE, ON_CHANGE, onUWattChange);
24 ArduinoCloud.addProperty(uWhCon, READWRITE, ON_CHANGE, onUWhConChange);
25 ArduinoCloud.addProperty(uWhOpta, READ, ON_CHANGE, NULL);
26 ArduinoCloud.addProperty(directOverride1, READWRITE, ON_CHANGE, onDirectOverride1Change);
27
28}
29
30WiFiConnectionHandler ArduinoIoTPreferredConnection(SSID, PASS);

If Opta™ was configured to use Ethernet as the network interface, the

thingProperties.h
header will resemble as follows.

1#include <ArduinoIoTCloud.h>
2#include <Arduino_ConnectionHandler.h>
3
4const char IP[] = SECRET_OPTIONAL_IP;
5const char DNS[] = SECRET_OPTIONAL_DNS;
6const char GATEWAY[] = SECRET_OPTIONAL_GATEWAY;
7const char NETMASK[] = SECRET_OPTIONAL_NETMASK;
8
9void onUOperMarginChange();
10void onUWattChange();
11void onUWhConChange();
12void onDirectOverride1Change();
13
14float uOperMargin;
15float uWatt;
16float uWhCon;
17float uWhOpta;
18bool directOverride1;
19
20void initProperties(){
21
22 ArduinoCloud.addProperty(uOperMargin, READWRITE, ON_CHANGE, onUOperMarginChange);
23 ArduinoCloud.addProperty(uWatt, READWRITE, ON_CHANGE, onUWattChange);
24 ArduinoCloud.addProperty(uWhCon, READWRITE, ON_CHANGE, onUWhConChange);
25 ArduinoCloud.addProperty(uWhOpta, READ, ON_CHANGE, NULL);
26 ArduinoCloud.addProperty(directOverride1, READWRITE, ON_CHANGE, onDirectOverride1Change);
27
28}
29
30EthernetConnectionHandler ArduinoIoTPreferredConnection(IP, DNS, GATEWAY, NETMASK);

The header, automatically generated by Arduino Cloud based on the defined variables, is best left unedited. Any additions or deletions of variables should be handled directly within the Cloud environment.

The above header is an illustrative example tailored to a demonstration script. This script can either be employed as-is or adjusted to meet different system requirements per your preference.

Connecting Opta™ with Arduino Cloud

For integrating Opta™ with the Cloud platform, visit the Arduino Cloud. If you are new to this, our Getting started with the Arduino Cloud tutorial offers a step-by-step guide on beginning your journey with the Arduino Cloud. For a more comprehensive exploration of tutorials, feel free to navigate the Arduino Cloud documentation page.

Once set up, you will have the opportunity to design an interface resembling the preview below. This serves as an exemplary dashboard to supervise and control relevant parameters.

Opta™ Energy Management Interactive Dashboard on Arduino Cloud
Opta™ Energy Management Interactive Dashboard on Arduino Cloud

Complete Opta™ Energy Management Sketch

Access the complete sketch used in the design of energy management for Opta™ in conjunction with the Arduino Cloud here. The compressed file can be imported directly to Arduino Cloud Web Editor for your convenience.

Conclusion

You have built an Opta™ energy manager adept at monitoring an electrical system, evaluating power availability and consumption, and remotely managing devices prioritized by power or energy via the Arduino Cloud.

Opta™ can help manage the energetical balance in industrial environments: in this example, we have considered a scenario where machines can be operated opportunistically, based on power availability, over a 24/7 span, to improve the overall power efficiency.

With a few tweaks, such as integrating different types of power sources, setting varied conditions for machinery operations, and adjusting power-related parameters, this project can be adapted. This flexibility allows for the creation of tailored solutions, addressing numerous scenarios and optimizing energy distribution effectively.

Next Steps

Setting up an energy management system, whether at home or in a industrial setting, can greatly minimize unneeded power usage. Delve into the potential of energy management harnessing the Arduino Cloud to develop a more energy-conscious environment.

Suggest changes

The content on docs.arduino.cc is facilitated through a public GitHub repository. If you see anything wrong, you can edit this page here.

License

The Arduino documentation is licensed under the Creative Commons Attribution-Share Alike 4.0 license.