Finnish three-phase installation, tips and tricks

Preface

I finally got my IotaWatt a couple of days ago and thought I share my experience setting it up. I did a lot of research before buying it to minimize any unexpected issues, but even so, I ran into a few roadblocks along the way.

A recurring “problem” is that the documentation as well as various anecdotes on the Internet focus solely on the US split-phase power delivery system, which is drastically different from the three-phase system used in Finland. I figured I’d explain the basics of how power delivery works over here before documenting the actual installation.

Power is delivered through a 5-wire system (three phases, one neutral, one protective earth). Apparently these are called 4-wire systems, I’m not sure why. After the main breaker, the three phases are divided evenly among two row of circuit breakers.

Most circuits/appliances use only one phase, but a couple use all three phases; the stove, the “heating central”, the heat pump and the sauna.

Initial setup (mains)

I started by powering up the IotaWatt in order to connect it to my wifi network. I only have 5 GHz, so the IotaWatt couldn’t find it. I solved this by making a separate hidden 2.4 GHz for the IotaWatt.

Next was connecting CTs for the three mains phases (called L1, L2 and L3 over here). I checked “derived three-phase” and configured L1 = A, L2 = B and L3 = C. No problems here, except the IotaWatt had detected all the CTs as being reversed, even though I was sure I had them the right way. Turns out the VT must be plugged in the “right” way. This is sadly not documented at all, but the solution is to either plug it in the opposite way, or check Reversed in the VT configuration.

Initial setup (individual circuits)

I proceeded to connect CTs to the various single-phase circuits I wanted to monitor. This is pretty simple so no issues there.

Initial setup (three-phase circuits)

Measuring the power for the sauna/heat pump etc. yielded some issues. I naively thought that I could just run all three phases through one CT and thus measure the total power, but it doesn’t actually work in practice. The documentation makes it sound like this can be done, but apparently it only works in America where the two phases are aligned (I may be wrong here, I’m no electrician). If you run all three phases through one CT, you will get a power measurement close to 0 watts.

Next up I connected CTs to each individual phase for the sauna, heat pump and heating central. I determined that the sauna has very even phase distribution (my model uses 3x3 kW for a total of 9 kW), the heating central is very similar (it uses 3x1.5 kW to heat the tap water), and the heat pump used around 200 watts more on L3 than the other two phases.

Armed with this knowledge, I decided to measure just L1 for the sauna, L1 for the heating central and L1 + L3 for the heat pump. The total usage can then be deduced as “outputs” in the IotaWatt.

Final setup

Here’s a photo of the panel:

The thick black wire is the mains. The three CTs that have white wires are not related to the IotaWatt (they go to the heating central so it can regulate itself). On the left column near the bottom you can see groups of three circuit breakers which are for three-phase appliances.

Here’s a photo of the smaller panel where the IotaWatt is housed (it’s below the breaker panel):

The wall outlet is on L1, which makes it easier to reason about it since IotaWatt always assigns the phase the VT is on as “phase A”. This is why L1 = A, L2 = B etc. works in my case.

Here’s the inputs and outputs from the IotaWatt status page:

Bastu_Total is “Bastu_L1 * 3”, Jaspi_Total is “Jaspi_L1 * 3”, Moon_Total is “Moon_L1 * 2 + Moon_L3”.

Issue summary

The documentation could mention the following things:

  • The fact that the IotaWatt only has 2.4 GHz wifi
  • That the VT has to have the right polarity, otherwise all CTs are detected as reversed
  • That you can’t measure three-phase by running all three phase wires through a single CT

Feature suggestions

These minor things would not hurt:

  • It would be nice to be able to double or triple the readings from a single CT instead of having to create a separate output
  • The web interface could send CORS header so developing alternative web interfaces could be done without having to upload the files to the IotaWatt and use the built-in web server

Store nitpicks

The main breaker is rated for 3x25 amps, which means I really don’t need the big 100A CTs. Unfortunately it doesn’t seem to be possible to order 14 50A CTs as part of the bundles, the store caps the maximum to 11. Even the 50A CTs are way too big for what we need over here (most phase wires are either 1.5mm2 or 2.5mm2).

2 Likes

Thanks for the case-study. Very nice install and some clever adaptations. I’m sure it will be well read, especially in Euro three-phase settings.

An overwhelming number of IoTaWatt are used in North American split-phase systems, so it should be no surprise that is well documented and the discourse on the forum has a lot of questions and examples. That said, there are is a substantial amount of discussion surrounding three-phase, even including a couple of three-wire situations, I believe in Norway.

Your three-phase is functionally exactly the same as North American three-phase. The primary differences are that the voltages are different (US has 120V/208V light commercial, and 277V/480V industrial), and the distribution in North America uses a three-phase load center where the three phases alternate in turn and circuit breakers are all attached to that backplane.

It’s true that there is a lot of discussion and a specific docs page for US split-phase, however I don’t see that as conflated with the three-phase documentation which has it’s own specific section https://docs.iotawatt.com/en/master/threePhase.html.

The European setup for the circuit-breakers is very similar to how the Australians do it, and that is the second largest market for IoTaWatt.

Hasn’t come up before, but good point. It is in the device specifications on Github but should be in the docs and mentioned somewhere in the stuff store.

I read over the three-phase docs referenced above, and you are right that it does not say that multiple phases cannot be combined in a single input. It is implied by the example where there are three inputs for each phase of the loads, and the phase assignment of the input only allows for specification of one of the phases, leading to the question of which phase were you specifying when all three were going through the CT? Not that it matters, there is no correct answer.

There is additional derived three-phase functionality coming out in the next release. Subsequently, I’ll be producing a new chapter for the documentation that goes into greater detail about three-phase in general, and the various methods that can be used to measure polyphase circuits. This will cover how to measure three-wire and two-wire loads in a four-wire service.

As Tesla pointed out, three-phase is a very elegant way to produce, transmit and use electricity. It is also more complex than single phase and there are a lot of variations on how to employ it. Without a doubt, users in three-phase residential countries have a better understanding.

As an experiment, I think you will find that the current in Amps measured by a CT that has all three phases running through it, should equal the current in Amps of the respective neutral to that load.

If you know that the L3 is always the larger, and always larger by say 220 Watts,you could get away with one CT on L3 using the script:

((L3 - 220) max 0 * 2) + L3

You can double. I try to avoid too many knobs and switches that would be seldom used as they tend to complicate the user interface unnecessarily. Someday, if I ever get to redoing the configuration app (which is a train-wreck), I would probably put in a master switch that allows enhancing the basic interface with “advanced” choices. For now, what you want was always intended to be addressed by the scripting system. There is virtue in keeping the inputs unadulterated and using the outputs script system to develop composite metrics.

The values of the inputs are recorded in the datalog. The values of the outputs are developed when accessed. So in the case I mentioned above of using just an L3 CT and subtracting a constant to get the other two, if you corrected that constant in the output, graphs of historical data would reflect that new value.

It works both ways of course, but on balance, I think that’s the way it should work and has so far proven to be very intuitive, useful, and above all adaptable to evolving capability.

Thanks again for the feedback and case study.

@overeasy thanks for the reply! I hope I didn’t come off as too negative regarding the documentation, it wasn’t meant as criticism, more as a collection of things I wish I’d seen.

You’re right about this, the documentation is pretty clear in this regard.

I think I tried all three at some point, but I always got very similar readings.

This is great!

You’re right, however I wasn’t really sure what the difference is (I think it varies) so I decided to play it safe and measure two out of the three phases.

I saw that checkbox mentioned in the documentation, but it wasn’t there in the web interface. Maybe it only appears when you specify a US CT model? Either way I guess it’s a nitpick, one can just as easily create customized outputs.

I was actually thinking of hacking on a new web interface, at least the status page which is the one I use the most (most people probably do the configuration once and then leave it alone). It’s complicated slightly by the fact that the API the web interface uses doesn’t supply CORS headers, so JavaScript that wants to talk to it has to be uploaded to the IotaWatt for the browser to proceed with the request. It’s not a huge deal, but it makes development a bit more cumbersome.

I was familiar with the CORS restrictions but was not aware of this protocol to allow it. Took a quick look at the wiki and seems pretty straightforward. The ESP webserver does appear a handler for an OPTIONS request, and it would be a simple matter to respond appropriately.

However, what is appropriate does complicate things.

There is the issue of authorization when passwords are set, or even the basic question of whether passwords and authorization should be required for a CORS request.

The authorization method used by IoTaWatt is Digest. I think I can send the authorization header in the response to the OPTIONS response so that the subsequent request by the client can develop a Digest authorization header. If so, it’s easy on the server end. The client will need to be running in an environment that will develop the authorization request header.

As you say, there are several workaround approaches, but I would be willing to add CORS OPTIONS response if you would commit to making your client application open and potentially part of the project.

I’m not sure yet about the other pages, but the status page polls the API using a GET request, which is in CORS parlance a “simple request”, meaning the browser doesn’t send an OPTIONS request beforehand. This means it’s enough to add an “Access-Control-Allow-Origin: *” header unconditionally in the “GET /status” response in order to allow external clients to utilize the API.

In my setup, I get “Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at http://10.110.4.4/status?state=yes&inputs=yes&outputs=yes&stats=yes&datalogs=yes&influx=yes&emon=yes&pvoutput=yes. (Reason: CORS header ‘Access-Control-Allow-Origin’ missing).” when I issue a simple fetch() request from a locally hosted HTML file (opened with file:// in Firefox).

Maybe this could be a good start? It doesn’t require any user interface changes.

Adding a response header is certainly doable, but I don’t fully understand how this works. How does the browser know it’s a simple request and that it should not send an options request? Does it just try it out and if the response doesn’t contain the CORS header, discard the response and tell the application sorry?

I can understand the second and subsequent requests being sent through after an initial options request.

I must have missed something in the wiki explanation. What is the RFC that covers this?

This !

When I installed mine, I had some weird reversed readings. I thought that I just put the CT’s in back-to-front. No biggy, just tick the “reverse” box on the inputs that were backwards.
Thanks to negge, I reversed the VT input, put all of the CT inputs back to “non-reversed” and my status page inputs now look normal !

2 Likes

@overeasy the official spec is https://www.w3.org/TR/cors/, however, it’s pretty hard to read and fully grasp. https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS is a pretty good primer on how it works.

In short, the browser doesn’t send a preflight request for GET requests, unless you manually add some custom HTTP headers to the request.

We could move this discussion to GitHub if you prefer so we don’t pollute this thread?

@speedy glad to be of help! I had pretty much the same experience (all CTs auto-marked as reversed even though I was certain they were correct).

1 Like

To all future readers, who are trying to install derived three-phase (EU). It requires that you strictly follow the documentation to get right: https://docs.iotawatt.com/en/master/threePhase.html#configuring-derived-reference
You can’t just reverse the flow by software, as it won’t produce accurate results.

What do you mean by “reverse the flow by software”?

Sorry for not being accurate. I mean checking the “Reversed” in the VT configuration.

I honestly didn’t try the checkbox because I found out about it after I had physically reversed the VT.