Change energy channel assignment based on meter type

phfeustel · May 22, 2023, 3:07pm

Hi Community,
in our installations we use Eastron SDM 630 meters as grid, production as well as consumption meters.
We have installed them according to the manufacturers wiring diagrams where “incoming” energy e.g from grid/production flows from top of the meter through into the EMS being a the bottom of the meter. While on the other hand side the energy from EMS at the top of the consumption meter is flowing down to the consumer which is connected at the bottom of the meter.

At first we used the already existent Microcare SDM 630 meter component in OpenEMS. The Microcare is constructed identical to the Eastron afaik.
But we noticed that the energy readings where going in the wrong direction; consumption instead of production an vice versa.
In other meters we have seen an “inverted” flag which sometimes inverts only energy (which would help) but sometimes also inverts power and current.

Sometimes there could also be a “wrong” wiring in the installation like where a consumer is connected to the top of the meter. To avoid further confusion, we think the existing inversion functionalities should be restricted to this case only.
After further studies and discussion we came to the conclusion that the energy channel assignments should be generally “inverted” only based on the meter type.

For better demonstration and discussion we created this overview diagram:

Additionally, to demonstrate this in code we created this PR: Switch energy assignment and power inversion based on the meter type. by phfeustel · Pull Request #2176 · OpenEMS/openems · GitHub

My question to the community are:

Does the switch of energy, power and current channel assignments based on the meter type make sense?
Is a “wiring direction reversed” flag helpful to “fix” wrongly installed meters? If yes, should we move this functionality to a higher level like the AsymmetricMeter/SymmetricMeter or the new ElectricityMeter?
If 1. and 2. are correct, should all meters be adapted to a common standard to avoid feature confusion?

Related topics:

hornbartho · May 22, 2023, 6:58pm

Hi,

That is a very good question and something to think about. From my experience, “faulty” wiring can very easily cause issues with installs and it is very handy to have an “inverted” option in the driver to ensure power/energy is flowing in the correct direction. Usually the cause of the fault is either flipped CTs or in some other cases swopped phases, so what fields you actually invert (in the driver) will depend on this. This seems to me like a driver issue and should be handled there. Don’t know if this answers 2), but would be keen to hear some to the other’s thoughts.

Coming back to 1), I think your demonstration shows the correct way of how the hardware is to be connected. Ie, switch the polarity of the load meter connection. If you hardware is connected correctly, you do not need to do any software tricks, since all is well already. If the hardware is incorrectly connected, it would be nice to correct for it that using 2). So I do not think it makes sense to make any change in the direction of power between meter types.

This is just my opinion, so take it with a grain of salt.

Regards,
Bart

phfeustel · May 23, 2023, 6:49am

Hi Bart,
thanks a lot for your feedback and insights into your experience.

True, if one switches even phases that’s much harder to fix in software and should be corrected in the hardware installation preferably; in our installations we have seen the case much more often where all phases are just connected to the wrong side of the meter. That’s why we also provide the “isWiringDirectionReversed” flag in the config of the meter component.

Regarding 1): If we use the Microcare SDM 630 as an consumption meter and connect the EMS at top and the consumers at bottom as it is advised by the meter manufacturer the energy readings in OpenEMS are wrong (while they are correct for production and grid meter).
That lead me to the conclusion that the assignment of modbus registers to OpenEMS channels need to be switch based on the meter type.

We might also use the “isWiringDirectionReversed” flag in OpenEMS config for this use case but this has two major drawbacks:

It is just not consistent to what the meter manufacturer advised.
According to the version control history of the meter software implementation in OpenEMS there multiple ideas/thoughts about what needs to be switched: only energy, also power and/or current. So, there is a lot of back and forth “fixing” of channel assignments in OpenEMS.
My interpretation of this is that it is caused by two different use cases: A) Installations which are not wired according to meter manufacturer. B) Different installation types as grid, production or consumption meter. And maybe even installations which have both.

So to come to a more comprehensive solution solution and stop the back and forth fixing, my proposal is to separate both use cases more clearly in the software implementation.

hornbartho · May 23, 2023, 9:40am

Hi,

Ah ok, thanks for the detailed explanation. My experience with Openems is fairly limited, so was not aware of the “flipped” interpretation of the consumption meter within Openems. Definitely something to think about and to look out for in future implementations.

In general I am in favor having as little post processing of raw device data as possible, so in theory it would make sense to me to have the consumption meter defined as you have in your diagram.

Would be interested to hear the Openems team’s thoughts. Sure they have reasons for choosing the current configuration.

Cheers

stefan.feilmeier · May 29, 2023, 9:00pm

HI Philipp,

Thanks for starting this discussion and for the in-depth analysis and explanation. It’s definitely true, that some things feel mixed up and implementations are not always consistent throughout the code. Clear and better definition of Channels will definitely help here.

To answer the question on how power flows are interpreted in OpenEMS, you are completely right. In SymmetricMeter we state “Range: negative values for Consumption (power that is ‘leaving the system’, e.g. feed-to-grid); positive for Production (power that is ‘entering the system’)”. This definition is unfortunately quite misleading (or even wrong) for meters that actually measure Consumption.

The idea for power flow was - just like you (and @tsicking in #2159) described - to think ‘from the middle’. This can best be seen and followed in the _sum calculations for Energy and Power.
We always assumed positive ActivePower to relate with ProductionActiveEnergy and negative ActivePower to relate with ConsumptionActiveEnergy. See e.g. this calculation in GoodWeGridMeterImpl:

github.com

OpenEMS/openems/blob/develop/io.openems.edge.goodwe/src/io/openems/edge/goodwe/gridmeter/GoodWeGridMeterImpl.java#L176-L195


      
          	/**
          	 * Calculate the Energy values from ActivePower.
          	 */
          	private void calculateEnergy() {
          		// Calculate Energy
          		var activePower = this.getActivePower().get();
          		if (activePower == null) {
          			// Not available
          			this.calculateProductionEnergy.update(null);
          			this.calculateConsumptionEnergy.update(null);
          		} else if (activePower > 0) {
          			// Buy-From-Grid
          			this.calculateProductionEnergy.update(activePower);
          			this.calculateConsumptionEnergy.update(0);
          		} else {
          			// Sell-To-Grid
          			this.calculateProductionEnergy.update(0);
          			this.calculateConsumptionEnergy.update(activePower * -1);
          		}
          	}

This same approach is used also in the CONSUMPTION_METERED GoodWeEmergencyPowerMeterImpl. Consequently in the UI History chart we also show ActiveProductionEnergy for consumption energy and not ActiveConsumptionEnergy.

Additionally as you found, for many meters we have a invert configuration option, that inverts ActivePower and should consequently also invert all related fields. But from your findings it seems this is not the case everywhere.

I understand that all of this is confusing; on the other side it is also currently working in production with thousands of systems. As you alread assumed, we are just using the ‘invert’ configuration in these cases to ‘fix’ consumption meters.

So as always, the complicated part is to improve the code (by refactoring or documentation) and still stay as backwards-compatible as possible. Especially as this issue relates also to historic data in a timeseries database we as FENECON and others who use this will have big issues fixing it.

From my point of view it could be sufficient to fix the invert configuration option in all meters and make it invert everything (Power, Current, Energy) and document in the READMEs, that if a meter is used as Consumption meter (and it is wired according to the manual), the invert configuration has to be set.

Additionally it might make sense to rename the Energy channels. I’ve read e.g. “ImportEnergy” and “ExportEnergy” in the past in Modbus protocols. Some research might help here to find a suitable name.

On the other side, if the Community agrees that a real proper solution would be to introduce a isWiringDirectionReversed configuration option everywhere, I will also support it. For the moment I am unsure on what the best solution is.

Regards,
Stefan

phfeustel · May 31, 2023, 12:07pm

Hi Stefan,
thank you very much for your elaborate answer and all the additional information and examples.

First, I guess, it would be beneficial for the community if we document these findings not only in meter specific docs but in a more general overview. I could offer to write an article as a chapter like “Meter Installation and Configuration Hints” in Core concepts & terminology :: Open Energy Management System.
What do you think?

For this I would use a (corrected) version of my diagram above plus the following overview table I prepared. Would you(@stefan.feilmeier) and maybe @tsicking check if this is correct?

Some notes and observations (see bold markups in the table):

Cases 1-4: According to the table the current mapping from Microcare/Eastron SDM 630 registers to OpenEMS values is incorrect: See @tsicking PR bugfix/meter-microcare by tsicking · Pull Request #2175 · OpenEMS/openems · GitHub
Cases 1-2: Naturally, it is confusing that for a grid meter ActiveProductionEnergy is mapped to BuyFromGrid and ActiveConsumptionEnergy is SellToGrid. But it is consistent when you think about the perspective form inside the EMS.
Case 5: A consumption meter installed according to the manufacturer’s instructions measures positive (!) power flow and attributes it to ActiveProductionEnergy in OpenEMS while the flow of power is actually out of the EMS. That’s why the History UI also maps ActiveProductionEnergy to Consumption. But positive power / ActiveProductionEnergy should always be into the EMS and not outwards; so, it is contradicting “the first rule” you gave. What I don’t understand is your comment:

“we are just using the ‘invert’ configuration in these cases to ‘fix’ consumption meters.”

If a consumption meter is installed according to the (Eastron) installation instructions, there is no need for inversion (if the mapping is correctly implemented see case 5 above); could you please elaborate on this @stefan.feilmeier ?

Case 8: In our first installations we thought that a CONSUMPTION_METERED meter should report to ActiveConsumptionEnergy; that’s why we inverted the meter via config but this lead a) to negative power and also b) to the consumption not being shown in the History UI. Therefore, I created Fix/UI consumption energy display by phfeustel · Pull Request #2160 · OpenEMS/openems · GitHub but as I understood this would break all installations which have consumption meters reporting to ActiveProductionEnergy; that’s why I guess we should not go this way.
All cases: It is important to follow the installation/wiring directions given by the manufacturer. One could use an invert functionality to fix it afterwards.

A way forward could be parallel use of different energy value channels with the downside of duplicating the data in transit as well as in the historical DB as well as dealing with code branches handling the new and the old way.

Using terms like “import” or “export” is always - as you also noted - dependent on your viewpoint; see also the terminology for the registers from the Eastron meter. I think this should also be noted more prominently in the documentation (and not only in the SymmetricMeter component code).

If we assume that we are thinking from inside the EMS the terms import and export are working great for grid, production meters as well as ESS. You import/discharge into EMS and you export/charge from EMS to the outside.

While for the consumption part, I see three options which all would break historical data and need a change in the UI components, queries etc.:

A of now it would be using ImportEnergy for energy that is “imported” by the consumer but leaving the EMS (see case 5). Which is still strange inside the OpenEMS terminology and does not make things really better.
We change the mapping to be like register “30073 - Total Import kWh” maps to ExportEnergy in OpenEMS. This looks like a weird mapping in the meter implementation but would bring consistency inside the rest of the OpenEMS code (this is basically what I proposed in my two MRs Switch energy assignment and power inversion based on the meter type. by phfeustel · Pull Request #2176 · OpenEMS/openems · GitHub and Fix/UI consumption energy display by phfeustel · Pull Request #2160 · OpenEMS/openems · GitHub)
We switch to reverse hardware installations or use the inversion functionality like in case 8. “Out of EMS” would correspond to “30075 - Total Export kWh” and to ExportEnergy which would keep everything in sync on the software side but would “violate” the installation instructions from Eastron.

Summing this up, I don’t know if we want to invest these efforts and enter a potential never ending code branching phase for the sake of consistency in terminology. Maybe it is just enough to:

Bring the used terminology, models and concepts as well as their relation to meter installation/configuration instructions to a more central place like the “Core Concepts” page as I proposed above.
Point out the flaws of the model regarding consumption meters together with instructions how to get around it (either inverted installation or using the invert config).
Instead of using an abstract term “invert” either we add a more specific one like “isWiringDirectionReversed” to the meter configs and make sure that all relevant parameters (power, current, energy) are inverted consistently.
Change all the meters to one model and terminology as well as streamline their inversion functions to one consistent approach.

What do you think?

klinki · September 10, 2023, 9:50am

Hi,

I´m struggeling too with the different perspective to display energy flow in consumption meters. Like @phfeustel said it complicates things if we take terms like import/export as they might be vendor specific.

I`ve made the mistake in mapping the consumption/production energy registers the wrong way in my Eastrons. Talking in the way of an electrician there is a clear way of wiring the meter and consumption is (for me) the energy that goes through the meter (export) to the consumer.

Anyway - I don´t want to mix things more up… my problem is, that I do not want to loose my historic data in UI as consumptionEnergy was fed.
So, maybe a bit naiv but: is there really a problem if we change data display only in UI? So maybe a switch in the config page says: ‘reverse energy in UI’.

I`ll check @phfeustel´s approach within the next days.

The last months I didn´t really care about the historic view in UI as power was alsway more interesting than energy. But the current development in aggregating data seems to be very nice!

Anyway - if everything is decided I can help changing the mappings in meters. We have Eastron, Janitza and EMH in use.

regards
Klinki

klinki · September 11, 2023, 4:29pm

as an approach to my own needs (for now) I`ve made a switch for the SDM630 which flips ActiveConsumptionEnergy and ActiveProductionEnergy (overall and each phase).
This seems to work well now and summaries are displayed in the historic UI view.

Not to lose my historic data causes a lot of work. I´ve I got it right I have to rename ActiveConsumptionEnergy ↔ ActiveProductionEnergy in influx. Unfortunatly you can´t do this because changing “_field” values is not supported - you can´t even delete by field-values.
The only way seems to be to copy all your influx data with changed field values in a new bucket, like so:

   curl "http://MyInfluxIP:8086/api/v2/query?org=MyOrg" -H "Authorization: Token MyToken"  -H "Accept: application/csv"   -H "Content-type: application/vnd.flux" -d '  from(bucket: "ems") |> range(start: 1970-01-01T00:00:00Z, stop: 2100-01-01T00:00:00Z) |> filter(fn: (r) => r._measurement == "data" and r._field == "Allgemein/ActiveConsumptionEnergyL2") |> map(fn: (r) => ({r with _field: "Allgemein/ActiveProductionEnergyL2"}))  |> rename(columns: {_field: "_field"})  |> to(bucket: "test", org: "MyOrg")'

Copying data took about 3 hours and there are more than 800 field names in my installation…

Regards
Klinki