openems icon indicating copy to clipboard operation
openems copied to clipboard

Switch energy assignment and power inversion based on the meter type.

Open phfeustel opened this issue 2 years ago • 2 comments

Following the discussion in https://github.com/OpenEMS/openems/pull/2159#issuecomment-1535870927, we created a fork of the Microcare SDM 630 as the Eastron SDM 630 meter implementation. We decided to create a fork and not change the Microcare meter directly to be able test the effects on the whole OpenEMS thoroughly.

As context please have a look at the following overview diagram: image

When reading energy, power and current values we see two major variables:

  1. What the meter is measuring aka the meter type like GRID, PRODUCTION, CONSUMPTION_METERED.
  2. How the meter is placed between the component to be measured and the EMS. We have established a standard for the Eastron SDM 630 where the load is always connected to the top of the meter. See e.g "7. Wiring Diagram" in "SDM630_Series_Manual.pdf" for layout and connection of incoming/outgoing wires: If the EMS is connected at the bottom and the component which is measured is connected at the top of the meter, this meter is measuring a component which is providing load for the EMS / into the system; i.e. GRID or PRODUCTION. If the EMS is connected at the top and the component at the bottom of the meter, the meter is measuring a component which is consuming load from the EMS / out of the system: i.e. CONSUMPTION. We have seen that sometimes the wiring direction was reversed during the installation (e.g. a gird meter having the EMS connected at top and the grid itself on bottom); that's why be provided a config param to reverse it in software as well.

Please have a close look at the logic at this line where we use the MeterType to decide if a measured component is providing load into the system or is consuming from the system. Based on this we switch channel energy assignments as well as invert power and current values.

Please have a look and I'm happy for any input you have: @tsicking @DerWahreKlinki @sfeilmeier.

phfeustel avatar May 15 '23 13:05 phfeustel

Dear all,

I am still getting up to speed with openEMS and thus by far not an expert :) What I do not really seem to get in this discussion, is why not stick to the Kirchoff Current law (KCL) convention: The openEMS ecosystem is based around a single node network (to my understanding).

KCL: into node is negative, out of node is positive. This means that PV can be considered always negative, and (un)controllable load is by definition positive. (to my knowledge defined in IEC60375 "Conventions concerning electrical circuits") Does this conflict on a code level that I do not (yet) understand?

afbeelding

Again, I am by no means an expert, just an eager (electrical) student so explanation is more than welcome :)

Byonnem avatar May 25 '23 06:05 Byonnem

Dear @Byonnem, thanks for the input.

When we are talking only about the measurement of energy (not power, current, etc) OpenEMS (according to what you find in the code of the CoreSum module) has a very analogous definition compared to KCL. Only the signs are reversed.

System balance =
      Producer Produce + Consumer Produce + ESS Discharge
      - Producer Consume - Consumer Consume - ESS Charge

sell to grid = system balance > 0 ? system balance : last_sell_to_grid_value
buy from grid = system balance < 0 ? system balance : last_buy_from_grid_value

If you take sell to grid or buy from grid into the system balance equation the total system balance will always be 0.

Why the signs are reversed compared to KCL, I cannot tell. Maybe it just feels more "natural" that when producer's production it is positive as well as consumer's consumption is negative and if producer's production > consumer's consumption this leads to a positive "sell to grid" in terms of you are earning money.

phfeustel avatar May 25 '23 08:05 phfeustel

This PR has been automatically marked as stale due to inactivity. It will be closed in 7 days if no further activity occurs.

github-actions[bot] avatar Sep 20 '25 07:09 github-actions[bot]

Closing this PR due to inactivity.

github-actions[bot] avatar Oct 05 '25 11:10 github-actions[bot]