My official energy grid meter is too far away from my flat, so I‘m using an Z-Wave Aeotec‘s Home Energy Meter Gen 5 (ZW095) with three clamps for the three phases of my flat. Everything works like a charm and energy is measured correctly (three phases individually and, more importantly, the sum of the three phases).
When I installed a plug-in PV inverter on phase I, I noticed odd numbers being reported. After diving into the configuration of the Aeotec meter in openHAB, I learned that I can chose between four energy detection modes (with the default being 1).
So far, the Aeotec, independent from the energy detection mode, reports energy different than the official energy meters in Germany, which is of course a problem, because it leads to different values on the Aeotec as compared with the official meters. This of course defies the entire purpose of having the meter in the first place.
As an example:
On phase 1 I have a plug-in PV module (there are probably 500.000 of them active right now in Germany), that can produce up to 600 Watts peak.
During the time of my test, it produced around 300 Watts…
… while my other appliances at home consumed 45 Watts (on phase 1), 80 Watts (on phase 2) and 30 Watts (on phase 3). this results in -255 Watts (on phase 1) and 80 / 30 Watts (on phase 2 and 3 respectively).
In such a setting, official grid meters in Germany net all three phases, but don’t count “backwards”, meaning: Total consumption on the official meter of my home just goes down to zero (see yellow cell). Assuming this would be the case for an entire year, your invoice would show 0 kWh.
However, the way I see things, there is no energy detection mode available on the Aeotec smart meter to report the same thing (0 Watts for power and no energy consumption for these settings, see green cells).
This means that the Aeotec smart meter will always come up with different values for power compared to the official grid meter, and with different values for energy compared to what I will get billed from my grid company at the end of the year.
Or, in other words: As soon as you have a plug-in PV system that produces more than you consume, the Aeotec smart meter can’t help you anymore.
Therefore my question: Has anyone else experienced the same problem, or am I missing something?
I thought about building a rule that does the netting manually, but you then I’d lose the charm of having a dedicated device (the Aeotec meter) that always sends the most recent value for energy, independent from the openHAB rule working correctly or not (for whatever reason).
I could be wrong but I think the root cause of the problem is that the meter does count backwards below zero. I have this same meter I think (meaning I’m not 100% positive which gen I have, it’s a DSB09) and I don’t see any parameter to stop at zero.
If I’m correct, you’ll need a rule to calculate everything the same as your power company does.
Yes, you are right. I forgot to mention, but that is in fact the main problem.
Yes, I was hoping for a different answer (and proposed this new feature to the Aeotec tech support), but it seems as if the calculation has to be done manually.
What I yet have to figure out: Assuming the calculation is done manually, and (to save database storage) the power meter only submits new values if a threshold is being hit (say, 10% change, which is the default setting, vs „send update every 10 seconds“) then the calculated energy consumption numbers must be off? Or does this imprecision levels itself outperform the course of a day?
There are lots of ways to save on database storage. You don’t have to save every value that comes along for every Item, you can exclude the Item entirely, use rrd4j which is fixed sized no matter how often or not the Item updates, etc.
On my device I have channels to set the threshold at which it reports so if you have a problem with the calculation being off you can adjust the “Percent Change” parameters up or down as necessary.
With the caveat that I don’t have an PVE system to worry about, I have the thresholds set to 5% and at the end of the month the following rule is within pennies of the actual power bill. I don’t know if a PVE system feeding power back would change things that much though. But experimentation (either physically or in a spreadsheet or the like) will give you a good idea of what sort of errors you might see in practice. Errors will only be introduced in the case where the power used goes up and down without breaking that 5% and it’s going up and down around 0. I suspect that’s going to be a relatively rare and short term occurrence.
configuration: {}
triggers:
- id: "1"
configuration:
itemName: HomeEnergyMeter_ElectricmeterkWh
type: core.ItemStateChangeTrigger
- id: "2"
configuration:
itemName: HomeEnergyMeter_Access
type: core.ItemStateChangeTrigger
- id: "3"
configuration:
itemName: HomeEnergyMeter_Rate
type: core.ItemStateChangeTrigger
conditions: []
actions:
- inputs: {}
id: "4"
label: Calculate the power bill and update the Item
configuration:
type: application/javascript
script: >-
var curr = items.HomeEnergyMeter_ElectricmeterkWh.quantityState;
console.debug('curr ' + curr);
var rate = items.HomeEnergyMeter_Rate.quantityState;
console.debug('rate ' + rate);
var access = items.HomeEnergyMeter_Access.quantityState;
console.debug('access ' + access);
var usage = curr.multiply(rate);
console.debug('usage ' + usage);
var estimate = access.add((curr.multiply(rate)));
console.debug('estimate ' + estimate);
items.HomeEnergyMeter_CurrentBillEstimate.postUpdate(estimate);
type: script.ScriptAction
