If you have resistors from red to blue, from blue to yellow and from yellow to red (i.e. a delta formation load) then the power is the sum of the individual line voltages (squared) divided by the individual resistance across each line:
$$P = \frac{V_{RB}^2}{R_{RB}} + \frac{V_{BY}^2}{R_{BY}} + \frac{V_{YR}^2}{R_{YR}}$$
If you have resistors in a star formation this is more difficult unless you have a neutral wire commoning the three resistors. If you do then measure the individual phase voltages and do individual power calculations then add the three powers to give total load power.
If you don't have a neutral then you will have to calculate the star-point voltage relative to red, blue and yellow respectively. Then you'll have three voltages and three resistors and power is the sum of the individual powers.
I believe the OP's OQ has been answered in comments.
I cannot add comments yet, but would like to add a few details about state-machines for anyone that links to this.
This is the minimal (pseudo)code for a running micro-controller:
[Power on]
1: Initialize(); //Clock and other hardware
2: Goto 4; //void Main()
3: "Crash"/unhandled Exception/activate watchdog timer/undefined
4: NOP; //NoOPeration = do nothing; uploaded user code goes here
5: Goto 4; //User code typically runs in an infinite loop
6: Goto 3; //void Main() does not typically ever return
As long as the infinite loop is sustained, the controller is either running user code or "idle". The article the OP linked shows the idle bubble sub-texted with "wait for interrupt". In my experience with micro-controllers, there is no "state" for idle; idle just happens when there is nothing else to do.
The user code may, at any time, detect that it has nothing to do and tell the processor to wait for interrupts and/or go low-power.
WFI(); //Block execution until an interrupt fires
and/or
LOW_POWER_REGISTER &= 0x01; //Physically power-down peripherals and reduce clock speeds
If desired, the user code may enter a custom or specific low-power mode and then, also, WFI(). WFI() has a very high chance of saving power since it suspends the user code, but may also invoke one or more integrated hardware power-saving features.
The interrupt that wakes the controller will be responsible for restoring any power states that leaving WFI() does not automatically restore. Typically, WFI() is used to pause until one or more input pins change. A watched "pin" can be actual solder terminal, or attached, internally, to peripherals like a timer.
I could not define "inherent exploitability," even with Google's help. The real issue with power state transfers taking too long is data loss. If asynchronously-received data is what wakes up the controller, a portion of the packet is lost before the controller is even awake. Sending a do-nothing "wake up" byte from the host before the actual data is light-weight and ensures that any receivers are awake and ready to receive.
Best Answer
Your understanding of P = VI is correct and will be in watts. That gives you the power. Since your interval of measurement is one hour the watt-hours will be the same numerical value.
Assuming the power rises or falls continuously during the experiment (rather than randomly increasing and decreasing) I would use the average power for the interval: \$ P_{n} = \frac {P_{n-1} + P_n}{2} \$ where \$n\$ is the measurement number.