I am a new user of OpenEMS. Thanks for building such a great piece of software, it works like a charm. Time from deployment to being useful was super-short (after I figured out how to build it). If have only a minor issue where I would like to get advise whether this is a misunderstanding or a bug.
My setup:
OpenEMS 2020.21, using only edge component, build into a Docker container
1 Smartmeter: Discovergy Two Way Meter, connected through the Discovergy API
1 Inverter: SMA Sunny Tripower with Home Manager, connected through Modbus TCP
All data is written into InfluxDB for analytics
My InfluxDB setup is the following: I use Telegraf with an Influx v1 Listener as a Relay. Telegraf forwards all data received into two InfluxDB 2.0 instances (one local, one on InfluxDB Cloud).
I use Grafana with Flux queries against the InfluxDB 2.0 instances to analyze and display data. I mainly use the â_sum/[Consumption|Production|Grid]Active[Power|Energy]â fields right now. Which works nicely most of the time. But today I saw a graph plotting â_sum/ConsumptionActicePowerâ that went negative. My understanding is that our total consumption could not be negative. We are typically drawing a baseline of at least 300 Watts. Is my understanding of this metric wrong or is this a bug?
Of course you are right, that Consumption power should in theory never be negative. But as Consumption is usually not measured directly, it has to be derived from actually measured values - typically those are Grid (buy+sell), Production and Storage (charge+discharge).
In the source code â_sum/ConsumptionActivePowerâ is calculated as:
From your screenshot you have at that point in time
GridActivePower = -3291 W (negative, so itâs sell-to-grid)
ProductionActivePower = 1762 W
EssActivePower = 0 W (no storage)
According to the data you are feeding more power to the grid than you produce. As a result the Consumption is calculated as a negative value.
How can negative Consumption happen?
Unmeasured Producer: there is an additional generating unit in the system that is not measured, like a second PV installation
Timing: the data is not measured at exactly the same time. If e.g. the Discovergy meter is providing data slower than the local SMA inverter. There are internal measures that invalidate old data.
Thanks, Stefan. Very helpful. The Discovery Meters provide an updated reading about every 45-50 seconds on average, but it unfortunately spikes to some minutes (or longer) occassionally. I revied the time elapsed between meter readings for yesterday and saw some of those spikes:
The spikes in the morning were in coincidence with the negative Consumption, so I believe this the root cause of the problem. I rebooted my Internet router which caused this issue in this case (the meter is local, but the used Discovergy API is on the Internet).
Luckily, I use the SMA Inverter with the SMA Home Manager connected to it. The Home Manager sits in my distribution box behind the meter and measures all the energy going through it and sends it to the Inverter. This way the inverter can calculate all relevant parameters like Production, Consumption, Buy/Sell from/to Grid on its own. These measurements are provided locally through Modbus TCP and are updated frequently without being depedent on an internet connection.
The better way than to compute the consumption in my case would be to use the consumption reading from the Inverter. Unfortunately the pvInverter0/ActiveConsumptionEnergy reading is always 0. I will investigate further on the weekend and get back with results.
My readings is:
TotW = Power generated
TotWOut = Power fed into the Grid
TotWIn = Power drawn from the Grid
The the consumption would be: TotW - TotWOut + TotWIn (between 300 to 500W in this example)
TotWOut and TotWIn are provided by the Home Manager. The data is always âin syncâ with the other readings from the Inverter and has a very good time resolution and accuracy. So it would be better to use this data from Inverter than the potentially delayed or non available data from the Discovergy Meter.
The metrics are exposed though Modbus.
Is there a way that OpenEMS can use this data to calculate ConsumptionActivePower, SellToGrid, BuyFromGrid etc. without any dependence on a separated meter reading?
In this case the Home Manager is the best meter I can could imagine and really would like to leverage it. As the data is available through the Modbus interface of the inverter, my naive imagination is that it should be quite simple
Unfortunately the current version of Discovergy meters only has a cloud API. I am very surprised, that it is that slow sometimes. I use the API personally and made good experiences till now. From what I know an upcoming version of the Discovergy meters will also have a local API. I am pinging @zoernert - Thorsten, do you have any updated information on that?
The pvInverter0/ActiveConsumptionEnergy will always be zero for a PV-Inverter. This comes from the fact, that PV-Inverter is inheriting a SymmetricMeter; so ActiveConsumptionEnergy would be the energy that is consumed by a PV-Inverter.
What we need instead is a Meter component in your system that replaces the current Discovergy meter with the SMA grid meter. I do not have experience with SMA Sunny Home Manager, but usually SMA is quite good in implementing standard SunSpec protocols. If you are lucky, the SolarEdge Grid-Meter might work out of the box, as it is also using SunSpec.
If not, maybe you can provide some documentation on the Home Manager Modbus specification?
The Discovergy Smart Meter Gateway is coupled to the actual meter through Wireless M-Bus. This communication canât provide more frequent updates - I have asked this question already to Discovergyâs support team. In general, Iâm quite happy with the functionality of the meter and the API, only the update frequency causes sometimes weird effects on Dashboards/Charts.
I have been succesful in reading the values of the fields âTotWInâ and âTotWOutâ (the bidirectional meter in the Home Manager) from the Modbus interface using OpenHAB with the Modbus Binding. I gathered the required information from the Modbus documentation available on SMAâs website. Here is part for the Home Manager meter (in German):
If somebody could build a meter for the âSMA Sunny Home Manager 2.0â from this information, I would be more than happy to test it.
[Edit: Of cource, I tested the SolarEdge meter and got the error message: â[modbus0] FC3ReadHoldingRegisters [meter1;unitid=1;ref=40000/0x9c40;length=2] execution failed: Transaction failed: Illegal Data Address: Illegal Data Addressâ]
Ok, it was worth a try. But the error message already shows, that the âSMA Sunny Home Manager 2.0â does not seem to support a SunSpec protocol. The SunSpec protocol has a âMarkerâ at register 40000 - which does not seem to be supported as it is throwing an Illegal Data Address error.
Implementing a Meter via Modbus in OpenEMS is very easy. In fact it is even completely documented in the âImplementing a deviceâ guide:
There is an exhaustive list of Modbus documentation at (click on âDownloadsâ, âHintergrundwissenâ)
Okay, you got me - I will tackle this implementation myself. But the last check-in into a public repository has been 20 year ago when git was unknown and cvs ruled the world. I will try my very best not to make a fool of myself, but I may stell need some advice
The code skeleton bascially works. Iâm reading from Modbus register 30865 with the following code
protected ModbusProtocol defineModbusProtocol() {
return new ModbusProtocol(this,
new FC3ReadRegistersTask(30865, Priority.HIGH,
m(SymmetricMeter.ChannelId.ACTIVE_POWER, new SignedDoublewordElement(30865))));
}
The values always seems to be â-1â while OpenHAB with Modbus binding is reading proper values from this adress. There seems to an error of some kind with the above code. The SMA value at this adress is power in Watts, represented as signed, 32 bit integer value, high endian.
Any ideas? Is there a open-source Modbus TCP test utility to debug this?
Strange, the code seems to be fine. But -1 must be the value, that is actually read from the register, otherwise it would be UNDEFINED/null.
Can you share your OpenHAB configuration for the Modbus binding?
Which modbus Unit-ID are you using?
If I understand correctly registers 30867 and 30865 will have to be mapped to positive and negative values of meter0/ActivePower. Weâll work on that once you are able to read proper values.
This is really tough to debug without direct access to the device itself. If none of this works out, we should meet on a Teams-/Teamviewer-session.
The only difference I can find is, that you are using uint32 in OpenHAB wheras s32 should be correct according to the protocol. You could try an UnsignedDoublewordElement in OpenEMS.
Did you have success reading data using QModMaster?
You are right. It is difficult to find the root cause of the problem (OpenEMS reads nicely the values from the SunSpec registers of the inverter and seems to have problems reading other Modbus registers from the same Modbus TCP target).
I have tested QModMaster and it reads the values nicely
(registers 30865/30866, drawing 280W from the grid is accurate right now)
Let me check if I can find the root cause myself first. Thanks for investing so much time to support me.
BTW. This is how I could map the available Modbus Metering Registers to the channels of a SymmetricMeter. Would you suggest to go down that route or would this be more clever to structure as an AsymmetricMeter?
By looking at the code in AbstractReadRask I see a problem:
This should be like FC4ReadInputRegisters [3:30865/0x7891]: value in hex
But it is zero. The right StartAdress seems to get lost, this is why the device returns 0xfffffff all the time.
The code for the Modbus protocol is:
return new ModbusProtocol(this,
new FC3ReadRegistersTask(30865, Priority.HIGH,
m(SymmetricMeter.ChannelId.ACTIVE_POWER, new SignedDoublewordElement(30865))
));
This is indeed very strange. Can you please share the complete file/bundle that you created, so that I can have a look and let it run against a Modbus simulator?
Edit: I donât know what exactly happened. Today the code worked
[modbus0 ] INFO [dbus.api.task.AbstractReadTask] [modbus0] FC3ReadHoldingRegisters [3:30865/0x7891]: 0000 0347
[re.Cycle] INFO [e.controller.debuglog.DebugLog] [ctrlDebugLog0] _sum[State:Ok Grid:839 W Consumption:839 W] meter0[L:839 W]
A manual âgradlew cleanâ removed the problems which seem to be caused by a rookie software engineer in front of the keyboard Can you please advise on the topic âSymmetic vs. Asymmetricâ meter and how to convert Modbus registers available to channels using logic mentioned above?
I used today to check all the values put into Influx. It all looks good and consistent with one exception - this the graph for the last 12 hours for _sum/ConsumptionActiveEnergy
Can you please advise on the topic âSymmetic vs. Asymmetricâ meter and how to convert Modbus registers available to channels using logic mentioned above?
