# Proposal: add Power and Energy distribution channels to \`\_sum\` **URL:** \ **Category:** Software-Development\ **Created:** [December 15, 2024, 8:33pm UTC](https://community.openems.io/t/proposal-add-power-and-energy-distribution-channels-to-sum/3283 "2024-12-15T20:33:34Z")\ **Posts on this page:** 14\ **Page:** 1
**Author:** ![stefan.feilmeier](https://community.openems.io/user_avatar/community.openems.io/stefan.feilmeier/32/2585_2.png) [@stefan.feilmeier](https://community.openems.io/u/stefan.feilmeier)\ **Post date:** [December 15, 2024, 8:33pm UTC](https://community.openems.io/t/proposal-add-power-and-energy-distribution-channels-to-sum/3283/1 "2024-12-15T20:33:34Z")
I would like to hear your feedback on the following PR: > > > This PR adds a feature to closely analyze in real-time and for historic values, …how the power and energy distributed between Grid, Production, Energy-Storage-System and Consumption, i.e. how much grid-buy energy was charged to the battery; how much grid-sell energy was discharged from a battery, etc. > > This PR adds new Channels to the \`\_sum\` component, that represent power and energy distribution: > \- \`PRODUCTION\_TO\_CONSUMPTION\_POWER\` / \`PRODUCTION\_TO\_CONSUMPTION\_ENERGY\` > \- \`PRODUCTION\_TO\_GRID\_POWER\` / \`PRODUCTION\_TO\_GRID\_ENERGY\` > \- \`PRODUCTION\_TO\_ESS\_POWER\` / \`PRODUCTION\_TO\_ESS\_ENERGY\` > \- \`GRID\_TO\_CONSUMPTION\_POWER\` / \`GRID\_TO\_CONSUMPTION\_ENERGY\` > \- \`ESS\_TO\_CONSUMPTION\_POWER\` / \`ESS\_TO\_CONSUMPTION\_ENERGY\` > \- \`GRID\_TO\_ESS\_POWER\` / \`GRID\_TO\_ESS\_ENERGY\` / \`ESS\_TO\_GRID\_ENERGY\` > > The unit test in \`PowerDistributionTest.java\` shows some example distributions: > \- Grid Sell \`-1000 W\`, Production \`2000 W\`, ESS Discharge \`500 W\` (Consumption is \`1500 W\` in this case) > - \`1000 W\` Production-to-Consumption > - \`1000 W\` Production-to-Grid > - \`500 W\` ESS-to-Consumption > > These values will be useful in a UI visualization in future. The feature has been successfully tested locally on my private system. > > One downside of the approach with \`CalculateEnergyFromPower\` is, that the resulting energy values might be slightly different to e.g. \`CONSUMPTION\_ACTIVE\_ENERGY\`. It's difficult to overcome this - but in reality a few \`Wh\` difference might not make a difference. > This PR adds a feature to closely analyze in real-time and for historic values, how the power and energy distributed between Grid, Production, Energy-Storage-System and Consumption, i.e. how much grid-buy energy was charged to the battery; how much grid-sell energy was discharged from a battery, etc. > > This PR adds new Channels to the `_sum` component, that represent power and energy distribution: > > - `PRODUCTION_TO_CONSUMPTION_POWER` / `PRODUCTION_TO_CONSUMPTION_ENERGY` > - `PRODUCTION_TO_GRID_POWER` / `PRODUCTION_TO_GRID_ENERGY` > - `PRODUCTION_TO_ESS_POWER` / `PRODUCTION_TO_ESS_ENERGY` > - `GRID_TO_CONSUMPTION_POWER` / `GRID_TO_CONSUMPTION_ENERGY` > - `ESS_TO_CONSUMPTION_POWER` / `ESS_TO_CONSUMPTION_ENERGY` > - `GRID_TO_ESS_POWER` / `GRID_TO_ESS_ENERGY` / `ESS_TO_GRID_ENERGY` > > The unit test in `PowerDistributionTest.java` shows some example distributions: > > - Grid Sell `-1000 W`, Production `2000 W`, ESS Discharge `500 W` (Consumption is `1500 W` in this case) > - `1000 W` Production-to-Consumption > - `1000 W` Production-to-Grid > - `500 W` ESS-to-Consumption > > These values will be useful in a UI visualization in future. The feature has been \> successfully tested locally on my private system. > > One downside of the approach with `CalculateEnergyFromPower` is, that the resulting energy values might be slightly different to e.g. `CONSUMPTION_ACTIVE_ENERGY`. It’s difficult to overcome this - but in reality a few `Wh` difference might not make a difference. @Sn0w3y: What’s you opinion? ---
**Author:** ![Sn0w3y](https://community.openems.io/user_avatar/community.openems.io/sn0w3y/32/636_2.png) [@Sn0w3y](https://community.openems.io/u/Sn0w3y)\ **Post date:** [December 16, 2024, 3:47pm UTC](https://community.openems.io/t/proposal-add-power-and-energy-distribution-channels-to-sum/3283/2 "2024-12-16T15:47:01Z")
Hi @sfeilmeier, Great job on adding the power and energy distribution channels! 🎉 The implementation is clear. In my Opinion it is a great Contribution and Improvement ! If it is merged i would be able to test it locally aswell on my System 🙂 What would be a UI Widget which is suitable maybe on History Tab to show some new Values? Do you have something in your mind? Best, Sn0w3y ---
**Author:** ![stefan.feilmeier](https://community.openems.io/user_avatar/community.openems.io/stefan.feilmeier/32/2585_2.png) [@stefan.feilmeier](https://community.openems.io/u/stefan.feilmeier)\ **Post date:** [December 16, 2024, 4:01pm UTC](https://community.openems.io/t/proposal-add-power-and-energy-distribution-channels-to-sum/3283/3 "2024-12-16T16:01:34Z")
Ok, thanks! I’ll let it run a few more days locally and see if I can identify any flaws. I did not think about visualizations in detail. A suitable visualization could be in the form of a Sankey-Diagram > **[Sankey diagram](https://en.wikipedia.org/wiki/Sankey_diagram)** > > Sankey diagrams are a data visualisation technique or flow diagram that emphasizes flow/movement/change from one state to another or one time to another, in which the width of the arrows is proportional to the flow rate of the depicted extensive property. > Sankey diagrams can also visualize the energy accounts, material flow accounts on a regional or national level, and cost breakdowns. The diagrams are often used in the visualization of material flow analysis. > Sankey diagrams emphasize the majo... > **[GitHub - kurkle/chartjs-chart-sankey: Chart.js module for creating sankey diagrams](https://github.com/kurkle/chartjs-chart-sankey?tab=readme-ov-file#example)** > > Chart.js module for creating sankey diagrams ---
**Author:** ![Sn0w3y](https://community.openems.io/user_avatar/community.openems.io/sn0w3y/32/636_2.png) [@Sn0w3y](https://community.openems.io/u/Sn0w3y)\ **Post date:** [December 16, 2024, 4:29pm UTC](https://community.openems.io/t/proposal-add-power-and-energy-distribution-channels-to-sum/3283/4 "2024-12-16T16:29:10Z")
> [@stefan.feilmeier](#): > > I’ll let it run a few more days locally and see if I can identify any flaws. I will let it run on my Edge aswell 🙂 Just pulled the PR 😛 Will also report if everything works ! 🙂 ---
**Author:** ![stefan.feilmeier](https://community.openems.io/user_avatar/community.openems.io/stefan.feilmeier/32/2585_2.png) [@stefan.feilmeier](https://community.openems.io/u/stefan.feilmeier)\ **Post date:** [December 17, 2024, 7:18am UTC](https://community.openems.io/t/proposal-add-power-and-energy-distribution-channels-to-sum/3283/5 "2024-12-17T07:18:02Z")
What do you think should we do with invalid data? For example negative Production and Consumption. Using them the way they are (so that the sum-equation fulfills) or setting them to zero (breaking the equation). ---
**Author:** ![Sn0w3y](https://community.openems.io/user_avatar/community.openems.io/sn0w3y/32/636_2.png) [@Sn0w3y](https://community.openems.io/u/Sn0w3y)\ **Post date:** [December 17, 2024, 8:21am UTC](https://community.openems.io/t/proposal-add-power-and-energy-distribution-channels-to-sum/3283/6 "2024-12-17T08:21:26Z")
As we’re working on a new version of the channels and focusing on improving the user experience, I believe it would be better, especially for installers who may not be familiar with grid connections, to keep the values at 0 if any values are incorrect. What is your opinion on this approach? Additionally, it might be helpful to display an error in the UI if the values are invalid, so that users can easily identify and correct any issues. What are your thoughts on this? 🙂 ---
**Author:** ![tsicking](https://community.openems.io/user_avatar/community.openems.io/tsicking/32/954_2.png) [@tsicking](https://community.openems.io/u/tsicking)\ **Post date:** [December 17, 2024, 8:28am UTC](https://community.openems.io/t/proposal-add-power-and-energy-distribution-channels-to-sum/3283/7 "2024-12-17T08:28:41Z")
I haven’t had a detailed look at it, but how do you choose the six channel values for the powers? In the example you give, 1500W Production-to-Consumption, 500W Production-to-Grid and 500W ESS-to-Grid would also be valid, wouldn’t it? And anything in between, like 1250W Production-to-Consumption, 750W Production-to-Grid, 250W ESS-to-Consumption and 250W ESS-to-Grid. Mathematically speaking, you have a linear equation system with 6 variables (`Production-to-Consumption` etc.) and only 3 equations (`Production = Production-to-Consumption + Production-to-ESS + Production-to-Grid` etc.), leaving a 3-dimensional solution space, if I’m not mistaken. Okay, you additionally say that most powers are non-negative, which solves it in some cases, but still, how do you determine which of the many solutions you take? Best regards, Thomas ---
**Author:** ![stefan.feilmeier](https://community.openems.io/user_avatar/community.openems.io/stefan.feilmeier/32/2585_2.png) [@stefan.feilmeier](https://community.openems.io/u/stefan.feilmeier)\ **Post date:** [December 17, 2024, 9:59am UTC](https://community.openems.io/t/proposal-add-power-and-energy-distribution-channels-to-sum/3283/8 "2024-12-17T09:59:45Z")
> [@Sn0w3y](#): > > I believe it would be better, especially for installers who may not be familiar with grid connections, to keep the values at 0 if any values are incorrect. What is your opinion on this approach? @Sn0w3y: The problem is, that this would break the [most fundamental formula in OpenEMS](https://github.com/OpenEMS/openems/blob/develop/io.openems.edge.core/src/io/openems/edge/core/sum/SumImpl.java#L402-L403): > `Consumption = Grid + Production + ESS` Showing a Warning is a good idea, but we need to consider corner cases as well. E.g. in my system the grid meter measures electric vehicle charging power before I get the value from the charging station. This leads to a short period of negative consumption as well. * * * Thank you Thomas (@tsicking), this kind of the discussion is the reason why I opened a “Proposal” thread here to discuss this. 👍 Yes indeed, if we want to visualize the distribution, we need to settle on a “priority” on how the energy should flow. Example (based on [JUnit test #3](https://github.com/OpenEMS/openems/blob/5b658f0996edf282ed37ea176552df9e908a1efc/io.openems.edge.core/test/io/openems/edge/core/sum/PowerDistributionTest.java#L37-L45)): **Distribute following power** : - Grid Buy: `1000 W` - Production: `2000 W` - ESS Charge: `500 W` **Solution #1** (as in the test) - Production-to-Consumption: `1000 W` - Production-to-ESS: `500 W` - Grid-to-Consumption: `1000 W` **Solution #2** (equally possible within the linear equation system) - Grid-to-ESS: `500 W` (_might be illegal depending on the legislation_) - Production-to-Consumption: `1500 W` - Grid-to-Consumption: `500 W` In the implementation I chose to distribute **ESS** first, to avoid these legislation pitfalls, that also exist in the _ESS-To-Grid_ direction. But I am very open to discussion. Maybe it helps if we add more examples in the `PowerDistributionTest.java` - including some that break other constraints (like Consumption and Production being negative) ---
**Author:** ![Sn0w3y](https://community.openems.io/user_avatar/community.openems.io/sn0w3y/32/636_2.png) [@Sn0w3y](https://community.openems.io/u/Sn0w3y)\ **Post date:** [December 17, 2024, 10:09am UTC](https://community.openems.io/t/proposal-add-power-and-energy-distribution-channels-to-sum/3283/9 "2024-12-17T10:09:55Z")
> [@stefan.feilmeier](#): > > @Sn0w3y: The problem is, that this would break the [most fundamental formula in OpenEMS](https://github.com/OpenEMS/openems/blob/develop/io.openems.edge.core/src/io/openems/edge/core/sum/SumImpl.java#L402-L403): I think the better approach would be to show a warning when invalid data is detected without altering the core calculations. This would allow users to identify and correct any discrepancies without affecting the equation. > [@stefan.feilmeier](#): > > Showing a Warning is a good idea, but we need to consider corner cases as well. E.g. in my system the grid meter measures electric vehicle charging power before I get the value from the charging station. This leads to a short period of negative consumption as well. Maybe this could be handled with a delay easily ? 🙂 As if the Meter is incorrect it is negative most of the Times and not only a short Period 🙂 ---
**Author:** ![c.lehne](https://community.openems.io/user_avatar/community.openems.io/c.lehne/32/2719_2.png) [@c.lehne](https://community.openems.io/u/c.lehne)\ **Post date:** [December 24, 2024, 11:17am UTC](https://community.openems.io/t/proposal-add-power-and-energy-distribution-channels-to-sum/3283/10 "2024-12-24T11:17:03Z")
> [@stefan.feilmeier](#): > > Showing a Warning is a good idea, but we need to consider corner cases as well. E.g. in my system the **grid meter measures electric vehicle charging power before I get the value** from the charging station. This leads to a short period of negative consumption as well. Unfortunately this is not only a corner case. The idm heatpump measures its own consumption only approx. every 30s. Same for the dachs CHP and there are other components. Therefore we often have short periods of negative consumption. .. > [@stefan.feilmeier](#): > > What do you think should we do with invalid data? For example negative Production and Consumption. Using them the way they are (so that the sum-equation fulfills) or setting them to zero (breaking the equation). I don’t like the idea of setting invalid data to zero. Having negative data has helped us identify other system problems in a lot of systems. If really needed, I prefer to catch this kind of problem within the component that causes it. Unfortunately we still do not have a way to handle this appropriately. E.g. the idm heatpump always breaks the consumption within the UI. That is something we simply live with at the moment: ![image](https://community.openems.io/uploads/default/original/2X/e/e47e8605752560d7ae463d971c59f740a66d09db.png) I thought of a sum component configuration option to set negavtive values to zero in only a few systems. But I also do not like this idea too. > [@Sn0w3y](#): > > Additionally, it might be helpful to display an error in the UI if the values are invalid, so that users can easily identify and correct any issues. > > What are your thoughts on this? 🙂 I don’t think displaying an error will help much here, as we have this components, which provide meter values heavily delayed. ---
**Author:** ![c.lehne](https://community.openems.io/user_avatar/community.openems.io/c.lehne/32/2719_2.png) [@c.lehne](https://community.openems.io/u/c.lehne)\ **Post date:** [December 24, 2024, 11:28am UTC](https://community.openems.io/t/proposal-add-power-and-energy-distribution-channels-to-sum/3283/11 "2024-12-24T11:28:40Z")
First of, I like the idea of breaking down the power and energy values within PR #2923. Regarding > [@stefan.feilmeier](#): > > **Distribute following power** : > > - Grid Buy: `1000 W` > - Production: `2000 W` > - ESS Charge: `500 W` > > **Solution #1** (as in the test) > > - Production-to-Consumption: `1000 W` > - Production-to-ESS: `500 W` > - Grid-to-Consumption: `1000 W` > > **Solution #2** (equally possible within the linear equation system) > > - Grid-to-ESS: `500 W` (_might be illegal depending on the legislation_) > - Production-to-Consumption: `1500 W` > - Grid-to-Consumption: `500 W` > > In the implementation I chose to distribute **ESS** first, to avoid these legislation pitfalls, that also exist in the _ESS-To-Grid_ direction. > > But I am very open to discussion. People buy a battery to store the energy from the PV! Therefore I think the **ESS first** assumption is pragmatic and comes closest to reality of most people. ---
**Author:** ![Sn0w3y](https://community.openems.io/user_avatar/community.openems.io/sn0w3y/32/636_2.png) [@Sn0w3y](https://community.openems.io/u/Sn0w3y)\ **Post date:** [March 7, 2025, 5:26pm UTC](https://community.openems.io/t/proposal-add-power-and-energy-distribution-channels-to-sum/3283/12 "2025-03-07T17:26:24Z")
Hello @stefan.feilmeier should we work together on a new “Tab” beneath the History in the Header so one can see a diagram of the Energy Distribution? Are there already any Approaches? Greetings ---
**Author:** ![stefan.feilmeier](https://community.openems.io/user_avatar/community.openems.io/stefan.feilmeier/32/2585_2.png) [@stefan.feilmeier](https://community.openems.io/u/stefan.feilmeier)\ **Post date:** [March 7, 2025, 9:55pm UTC](https://community.openems.io/t/proposal-add-power-and-energy-distribution-channels-to-sum/3283/13 "2025-03-07T21:55:16Z")
No, we do not have a concrete concept on how to integrate it in the UI. I am still considering something like a Sankey diagram - maybe similar to the EnergyMonitor in Live (i.e. Grid on left, Production on top, Consumption on right and Storage on bottom). I do not think a new Tab in History will be good UI/UX. For now I would just put it in a UI Modal in History maybe. Regards ---
**Author:** ![Sn0w3y](https://community.openems.io/user_avatar/community.openems.io/sn0w3y/32/636_2.png) [@Sn0w3y](https://community.openems.io/u/Sn0w3y)\ **Post date:** [March 8, 2025, 9:58pm UTC](https://community.openems.io/t/proposal-add-power-and-energy-distribution-channels-to-sum/3283/14 "2025-03-08T21:58:02Z")
![image](https://community.openems.io/uploads/default/original/2X/a/a4261c008323f38ea93fe7549c26eef9bef4bcf2.jpeg) I started with an example - if I am honest i am not really good in UI/UX Design 😃