3-phase solar + consumption emoncms input processing

[TrystanLea]

I’ve been setting up a 3-phase solar PV + consumption monitoring setup for a customer today and I thought I would share the input processing that we have ended up with as I realise this isn’t well documented. I will add this to the docs as well, perhaps with some further refinement if there are suggestions about better ways to do this.

We wanted to record both detailed per phase data and totals summed across all three phases.

1. This is what the input processing summary looks like:

• P1, P2 & P3: Solar generation, these are logged to feeds solar_L1, solar_L2, solar_L3 respectively.
• P3: uses ‘+ input’ to calculate a total sum of P1, P2 & P3, the result is published to MQTT topic: emon/sum/solar_total.
• P4, P5 & P6: This is grid import & export, which is first logged to grid_L1, grid_L2, grid_L3 respectively. Then there is a allow positive input process with the result logged to feeds import_L1, import_L2, import_L3 respectively. Each leg is reset to the original value and then the allow negative input process is used followed my a scale by -1 before recording export_L1, export_L2 & export_L3.
• P6: also uses ‘+ input’ to calculate a total sum of P4, P5 & P6, the result is published to MQTT topic: emon/sum/grid_total.

Zooming in on the input processing for P6 (Grid_L3):

A second layer of input processing is then added to these generated inputs:

• grid_total:

• solar_total: just logs the total to a power feed and uses ‘power_to_kwh’ to calculate cumulative solar kWh data as well.

The final result in terms of feeds is:

and MySolar app:

This did get quite complicated for something that should be relatively simple. Recording all the individual phase import/exports etc does add complexity. The use of Publish to MQTT to generate new inputs while a neat simplification for local installs is not something that is available on emoncms.org. Ideally we would have a “write input processing result to new input” option that did not have to go out and back via MQTT…

Some of the above could be simplified with virtual feeds. E.g generating separate import/export power feeds at least from grid import/export feeds. In this particular install we had historic import data but not import/export and so I went down the non virtual feed route. I’ve also been thinking there’s probably a good case for having Emoncms app’s generate daily kWh stats from selected power feeds on the fly rather than require both power and kWh feeds, this could reduce the amount of input processing complexity quite a bit… These are future ideas but the above is one way of getting all the feeds for data analysis using the capabilities of emoncms today.

The overall aim of this monitoring installation is to:

• Calculate the value of the exported electricity
• Work out the value of increasing the size of the solar array
• Work out the value of adding battery storage.

[Greebo]

For what its worth (and I think I’ve posted this before), I’ve been running the following input processing for my 3-phase solar + consumption system for the last (coming up to) 4 years.

I’m interested to understand why you’ve chosen +input for the Power values, as I’ve always understood the advice here was +feed was “better”. Is that no longer the case, or is it very dependent on the source data/inputs?

If there is any interest, I can expand on my screenshot above and explain how it all hangs together as Trystan has done with his post above.

I’m using a python script reading a http “stream” published from my Enphase envoy which pushes all of my input values about once every second or two, and then pushing them into EmonCMS using the http interface. This was all documented at the time in this post here

[TrystanLea]

Thanks for sharing this @Greebo

• What is the condition that you are using on the >?skip and can you describe how you are using them? I’ve always found those a bit difficult to wrap my head around but know a lot of folk use them and find that approach useful.

• I assume GOTO is working for you? I had trouble testing that yesterday and was going to investigate.

• In my mind using +input is better as it’s involves less calculation/processing steps, but the order that you add the inputs is important if the inputs are being populated via the emoncms_mqtt script. E.g if you have an L1, L2 & L3 input, you need to sum these up on the L3 input as that will arrive after the other two. I’m not sure why the advice is for using +feed over +input, but there’s nothing wrong with that approach either.

[Robert.Wall]

@TrystanLea

I’m not sure why the advice is for using +feed over +input, but there’s nothing wrong with that approach either.

My recollection is it comes into play when an input moves for whatever reason.
This might shed some light on the question Copy users on private server, including dashboard, inputs, feeds, graphs, etc? and that makes me think the problem might have been circumvented by the concept of the ID.

[jmhc (JM)]

Hello All and Trystan, who I’d like thank VERY much for his help with the configuration.

I thought it might be useful to add a little more information for context of the installation and configuration that Trystan has made. As Greebo has and everyone else here to of course. I wish I’d noticed Greebo’s contribution awhile ago

Electrical schematic overview.

emonBase, emonTX4, emonVs housed in IP65 enclosure with 4-pole MCB, 4-pole SPD(surge protection device) protected by ceramic fuses. 200A CT’s for mains import & 100A for solar generation. Connected via CAT5e to the LAN…

Overview of the site.

[Greebo]

Since you asked, I’ll go through the logic in case it helps someone else
Here’s the processing for the first two generation (“prod”) inputs:

Basically just logging to a “phase” feed after setting any values under “5” to zero. I found that the Enphase system reports a few W of generation overnight and that didn’t sit well with me, so I filter it out.

Here’s the “main event” for production processing:

1 - 3 are with the same filtering above and logging to a “phase” feed.
4 - 6 add the other two generation feeds and then log that to a Total W feed
7 converts it to kWh and logs that to a generated energy feed
8 - 10 give me a “net power” value by removing the Generation from Consumption
11 checks if net power is positive (importing), and if so we jump to 13. Otherwise (row 12) we jump to 19
13 Logs to my “Import only” power feed - which is 0 if I’m exporting, and positive if I’m importing.
14 gives me an “Import energy” feed from 13
15 - 16 Sets the “Export only” power feed to 0 if I’m importing
17 does the same for my “Export only” energy feed - although looking at that now, I could just use log to feed as I’m converting 0W to 0kWh
18 Jumps to the end (skips over the “Export only” processing I’m about to go through)
19 - 24 are the exact reverse of the above 13 - 17, logging a “positive” value (as per row 19 “x -1”) of the power and energy to the “Export only” feeds and logging 0 to the “Import only” feeds when I’m exporting.
25 is basically a step so I have something to jump to from 18

What I end up with out of that is feeds for:

• Generated Power on phase A, B and C and Total
• Energy Generated
• Power Exported (always positive)
• Energy Exported (always positive)
• Power Imported (always positive)
• Energy Imported (always positive)

The consumption processing is a lot simpler as the “Import only” and "Export Only processing is done above. Some of the feeds below are used above as well. As for generation, I just log two of the phases to a “per phase” power feed, here’s the combined phases processing:

1-4 are just logging this phase to a feed and then adding the other two phases for total power and logging that as Consumed-W.
5 logs consumed energy
6-9 give me a “net power” value, positive while importing and negative while exporting (same as 8-10 in the generation processing, but I just log it “as-is” here)
10 gives me the equivalent cumulative energy

What I end up with out of that is feeds for:

• Consumed Power on phase A, B and C and Total
• Energy Consumed
• Net Power (positive for import, negative for export)
• Net Energy (positive for import, negative for export)

Now that I’ve typed all of that out, I can see two places where I am doing redundant calculations, I guess that is the benefit of looking back at it a few years later!

The “Import only” and “Export only” power and energy feeds are used in my “home dashboard” in that post I linked to above, although it has been updated since then to include “total energy” for the day:

NOTE: It’s just gone 1am here, so there’s been no generation yet today!

From left to right, those kWh totals are total generation, total consumption, total import, and total export, all since midnight. I pull them directly from those feeds I generated above.

EDIT: I also get this sort of graph capability with those “Import Only” and “Export Only” feeds:

[TrystanLea]

Thanks @Greebo!

[davidm (david morrell)]

This what we use for 3 phase with added batteries using virtual feeds.
All good except it breaks MySolarBattery (see previous post)

.

[TrystanLea]

Thanks @davidm!

Are there any features that you or anyone else reading can think of that would make things easier for 3-phase applications in Emoncms?

[TrystanLea]

I’ve fixed a couple of minor but important issues on emoncms.org that help make it possible to use virtual feeds in the MySolar app to help support the approach you outline @davidm, I had been experimenting with similar here.

• the last time and value for the virtual feeds were not being calculated, this is now fixed.

• virtual feeds now fetch meta data (start time, end time and interval) from the source feed. (Interval is approximate if PHPTimeSeries).