# "Split" Output Calculation for an EV Charger

Just sharing an interesting use case in case it inspires ideas for anybody else, or in case anybody has ideas for me on better ways to accomplish this

## TL;DR

I’m identifying when my hybrid car is charging and creating a pair of “split” outputs that isolates (approximately!) how much power is used by the charger versus the rest of the branch circuit it’s sharing.

## Backstory

I’ve recently bought a plug-in hybrid Volvo, and am charging it (very, very slowly) using a standard 110V branch circuit in my garage (I’m in the USA). I’ve monitored my garage branch as a unique Input in the past since there’s also a freezer installed out there. Now with the hybrid EV charger, I’d like to get a rough estimate of how much energy is being consumed by the charger vs the rest of the branch circuit. Note that this solution is approximate only, but it gets me close and demonstrates a neat “thresholding” math trick in the Output calculator. A true/accurate measurement would require a dedicated circuit or separate power measurement equipment for that single load… neither of which I have today

## Split Output Calculations

Here’s my “pure IoTaWatt” approximation to “split” this single circuit:

• Input `Garage` (blue): branch circuit
• Output `Volvo_Charge` (green): If power draw is over 900W, then attribute all power up to a max of 1360W to the charger:
`Watts = (Garage min 1360) x ((((Garage - 900) max 0) min 0.01) x 100)`
• Output `Garage_Net` (red): The rest, after removing the charger: `Garage` - `Volvo_Charge`
`Watts = Garage - ((Garage min 1360) x ((((Garage - 900) max 0) min 0.01) x 100))`

Note: even that “glitch” in the middle confirms the calculation approach… Zooming in, we can see that during this gap, the charger temporarily tripped off, and the `Garage_Net` line continues showing a fairly consistent power draw through the whole period:

### How It Works

This approach deeply relies on the charger having a very consistent power draw that’s significantly larger than anything else on the circuit, so that I can sense it by the presence of high consumption, and then approximate it as a constant load.

In my case, I measured a few initial charge cycles and found that:

• Over the duration of the charge, the charger consistently draws 1370-1385 watts, and varies… but it only rarely dips below 1360 watts.
• At the end of the charge, the charger ramps down its power usage over approximately 30 minutes, and then turns off completely. Over this ramp period, the power draw remains above 900 watts. (Or at least in the charges I measured… Looking at the specific cycle in the graph above, it looks like I should nudge that threshold down just a bit.)

IoTaWatt does not do logic functions (e.g. “if less than X”), but it does offer `min` and `max`, which allow me to do some ad hoc thresholding. Breaking down the `Volvo_Charge` Output formula:

``````(Garage min 1360) x ((((Garage - 900) max 0) min 0.01) x 100)
``````
1. The right half of the multiplication will compute either `0` or `1` depending on whether the total power is greater than `900`:
1. First, we subtract off the threshold (900W), and take the `max` with `0`. For any value less than the threshold, this will be `max(negative number, 0)`, i.e. evaluate to `0`. For any value greater than the threshold, this will be some positive number showing how many more watts are being drawn.
2. Then, we take that the `min` of that value and `0.01`. This leaves `0` as `0`, but cuts any “power used over 900W” value down to `0.01`.
3. Finally, multiply the result by `100`, leaving either `0` or `1` (or in the unlikely (impossible?) event that the raw value was 900.005 or something, we’d end up with an intermediate value of `50` and a slight error for this data point in my math. I’m happy to ignore that minor edge case )
2. The left half of the equation: `min(actual value, 1360)` measures “all power up to and including 1360W, but no more”.
3. Multiply these together to get the “filtered” charger signal: (the charger’s attribution) * (1 or 0), based on whether the charger was on. This creates a resulting signal that consumes all power up to 1360W, but only if the power drawn is > the 900W threshold. Else it consumes 0.

For the `Garage_Net` output, just compute the difference:

``````Garage - ((Garage min 1360) x ((((Garage - 900) max 0) min 0.01) x 100))
i.e.:
Garage - Volvo_Charge
``````

## Ideas?

Let me know if anyone has ideas on how to further improve this method! It’s working pretty well at the moment but is obviously a bit fragile and dependent on specific values for my specific circuit and EVSE.

1 Like

I use Tasmota and (typically) Sonoff devices to control and measure power.

This is their latest one:

I haven’t used that one, but have used the prior two versions.

This one also has Tasmota support:

Or, you can use the code that comes with it.

Clever use of what’s available in the Scripts. I’ve resisted extending the capabilities because it’s a slippery slope. On the other hand I cringe when I see the convoluted expressions needed to accomplish something like this.

You seem to understand the limitations of the algorithm. As a practical matter you should be aware that this will probably not work as well with intervals longer than a day and become more unreliable with a week, month etc. An integrator would resolve that but I don’t recommend maintaining more than a couple of them.

Nice - I had not seen the POW Elite before. I’ve got a dozen or more S31’s around the house, but given their 16A rating I was hesitant to use one for this charger. A 20A rating would give me more confidence on running a sustained (10+ hours) 13A load. I will have to consider the POW Elite down the road…

Become unreliable in that the hardcoded values here are subject to drift, throwing off the measurement accuracy? Or become unreliable in that the extra computation might degrade performance of the data logging? I may have misunderstood how the output scripts worked and be using them dangerously here, versus simply “unconventionally”. I was targeting monotonic power values (modulo rounding errors), to avoid the need for an integrator (which I understood to be necessary only if power consumption could be negative?)

As I had understood it, output scripts are computed from the input samples and recorded alongside as additional values… given the comment about intervals, though, perhaps that’s incorrect? Are outputs actually computed on-the-fly / just-in-time, and it’s only the integrators which are computed in band with data logging?

Recording outputs at 5 second intervals would require a massive amount of storage. Moreover, changes to a script would only be effective going forward. They are computed as required and, most importantly, against the data in context. That means that for a given interval, be it 5 seconds (1 Hour graph), 2 minutes (one day), or 20 minutes (one week), the values that are being compared are the average for the interval. So if the charger ran for 10 minutes out of a 20 minute interval, its average Watts would be half operational Watts.

To see it graphically (I know you already get it), just plot your output for the garage for last week. You will see the begin and end of a charge cycle is not that sharp increase. If down the road you were to wonder how much your car charged in the last year (24 hour intervals), you may find that it hardly charged at all.

What you have done is fine for looking at a day, and with the long duration of charge, even up to a week should be within your margin of error. But longer term you would need to have been running an integrator to capture the result of your output applied to 5 second intervals. With that, it won’t matter if you look at 1 day or a year, the result will be exactly the same.

BTW/ this characteristic of the datalog and scripts are why I don’t encourage trying to use the IoTaWatt as an analytic engine. Its best to upload to a database with far better capabilities and fast storage.

Ah ha… thank you @overeasy! I definitely was thinking of that entire mechanism incorrectly. Makes perfect sense now.

And indeed, zooming out to a week or month starts to show the cracks in what I was doing there… slopes get less steep and the error on the margins increases. Looking at the otherwise regular on/off cycles of the freezer shows the story even more clearly - flat plateaus becoming sharp spikes:

Fair point! I think I will pursue that direction instead, and long term work on a dedicated measurement option, whether that’s a meter for the load or installing a new dedicated circuit to monitor with IoTaWatt.

Thanks again for the corrections