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?