ElectricityMeter - Range of Current Channels

Hi community,

In the description of the ElectricityMeter, it says that the current values can be positive or negative, depending on buy-from-grid or feed-to-grid for a grid meter.

However, we’ve experienced that current values are always positive, irrespective of the direction. We have multiple different meters in use, including some which are part of the public repository, like Siemens PAC and BControl, and they never show negative currents. So I wonder what the best way of dealing with this. Is it best to

a) change the documentation and define the range of the current channels to be positive, or
b) add some logic that applies the sign of the active power to the current?

Any suggestions are welcome.

Best regards,

1 Like

Nothing of it is applicable here. See:

and here:

Hi @Sn0w3y,
Thanks for the quick reply. However, I don’t understand how it answers my question, so maybe I wasn’t clear enough. Let’s illustrate it with a simple example:
Assume you feed 230W into the grid, i.e. the active power of the meter is -230W with a voltage of 230V. Should the current be 1A or -1A now? Most meters will give 1A via modbus and won’t care about the sign of the power. But the description in the javadoc says it should be -1A.

Best regards,

Some additional comment:

Most controllers work on the ActivePowerLx- channels and not on CurrentLx channels. This is why the sign of the CurrentLx channels hasn’t been important so far. We start using CurrentLx channels for charge parks. The CurrentLx sign problematic was raised, because we are working on PV excess charging feature.

Nevertheless the situation is as follows:

  1. The documentation says, that the CURRENT on meters of type grid allows positive and negative values.
  2. Most meters provide positive values, some meter provide positive/negative values.

The electrical formula for Active Power is P = U * I.
P can be negative, U is always positive, therefore I should also be able to be negative. So I would say, the documentation is already correct.

We think of
a) fixing the meters, mostly with a new modbus ElementToChannelConverter. But this may have negative side effects and it does not look very smart.
b) we could handle it in our component. Less sideeffects for other. But it may lead to others struggling on the different current handling of all the meters.

Any other idea or opinion on that topic?

Thank you @tsicking and @c.lehne for discussing this.

The comment
Meaning of positive and negative values for Power and Current depends on…” was meant exactly the way Christian explained.

To stay in line with the electrical formula P = U * I:

  • ActivePowerL1/L2/L3: can be positive or negative
  • CurrentL1/L2/L3: can be positive or negative
  • VoltageL1/L2/L3: is always positive

Therefor I would vote for fixing all meters accordingly. This might also include fixing the invert() config settings in the meters as well, while we already touch them.


Today @tsicking has been looking for a more generic approach. A way of using the e.g. CURRENT_L1.onInit() method to register for active power values and adopting the CURRENT_L1 Channel value accordingly. But unfortunately we do not see how this can work without a helper Channel (which would pollute the ElectricityMeter nature).
Next possible solution: We could provide something like a special ElementToChannel converter when reading via Modbus (advantage: it can be chained with the INVERT_IF_TRUE() converter). This is what we try next. If successful we open a PR as a basis for further discussion.

@stefan.feilmeier There is another point we are disussing right now. Recently we have integrated a CHP by metering it (MeterType.PRODUCTION). The Problem appeared when the CHP goes in standby, because then it produces negative ActivePower. And that distorts the UI live and the history view.
The ElectricityMeter documentation says for MeterType.PRODUCTION:

  • positive: production
  • negative: (undefined)

Wouldn’t it be a good idea to make it

  • positive: production
  • negative: either 0 or null?

Personally I would prefer 0 for a constant UI history view.
The missing consumption power of the CHP is negligible, as it is counted towards the sum.ConsumptionActivePower.

Same can be applied for meter type MeterType.CONSUMPTION.... May be helpful too, as some meters deliver negative consumption, when the measured consumers are off.


Valid points, but I do not think we can solve this technically, but only on an organizational level. I.e. we have to properly document these restrictions (e.g. if MeterType is Production, only positive values are allowed) and then implement them individually in every meter. Predefined ElementToChannel-Converters can help for this, of course.

Documentation would have to be done here → openems/io.openems.edge.meter.api/src/io/openems/edge/meter/api/MeterType.java at develop · OpenEMS/openems · GitHub

Also not every of those MeterTypes is properly supported in UI and _sum currently.