Bei der Suche im Forum bin ich leider nicht fündig geworden.
Ich teste derzeit eine erste Implementierung für das Fronius SmartMeter. Die Werte werden schon korrekt angezeigt.
Jedoch fehlen mir in der History-Ansicht die aufsummierten Werte
für Einspeisung kWh und Bezug kWh (siehe Screenshot).
Woran kann das liegen? Ist das ein reines Konfigurationsproblem oder fehlt in meiner Umsetzung noch etwas?
Hast du einen Timedata Provider laufen? 
Mir ist das auch schon beim Fronius PV-Inverter (bereits bestehendes Modul) aufgefallen…
Grüße !
Timedata Provider läuft.
Und mein Fronius PV-Inverter hat das Problem nicht. 
1 Like
Hmm… Dann weiss ich tatsächlich auch nicht mehr weiter…
BTW: hast du dir meinen Kommentar im PR wegen dem Eastron schon angesehen ?
Trotzdem danke für den Hinweis. Deinen Kommentar habe ich mir angesehen und beantwortet.
1 Like
Ne, den neuen tatsächlich noch nicht
Kann ich jetzt nicht nachvollziehen
Hallo @fanass,
zur ursprünglichen Frage:
Die Kurve zeigt den Wert des Channels ActivePower (-> openems/io.openems.edge.meter.api/src/io/openems/edge/meter/api/ElectricityMeter.java at develop · OpenEMS/openems · GitHub) - der wird also schon mal richtig ausgelesen.
Für die Energiewerte müssen die Channels ActiveProductionEnergy (-> openems/io.openems.edge.meter.api/src/io/openems/edge/meter/api/ElectricityMeter.java at develop · OpenEMS/openems · GitHub) und ActiveConsumptionEnergy (-> openems/io.openems.edge.meter.api/src/io/openems/edge/meter/api/ElectricityMeter.java at develop · OpenEMS/openems · GitHub) richtig gesetzt sein.
Diese sollten eigentlich bei SunSpec auch automatisch gesetzt werden (und zwar hier → openems/io.openems.edge.pvinverter.sunspec/src/io/openems/edge/pvinverter/sunspec/AbstractSunSpecPvInverter.java at develop · OpenEMS/openems · GitHub); falls das nicht klappt, würde ich mal den “Detailed Debug-Log Controller” aktivieren, und mir alle relevanten Datenpunkte im Detail ansehen.
Ist offensichtlich verfügbar, sonst würde auch der Chart nicht funktionieren. 
Standardmäßig wird bei SunSpec-Geräten aber der Energiewert direkt vom Gerät ausgelesen und nicht errechnet, so dass der Timedata-Provider dafür hier nicht benötigt wird.
Gruß,
Stefan
2 Likes
Danke Dir Stefan für die Info. Schaue ich mir mal an.
Allerdings ist meine Umsetzung aktuell nur Modbus und nicht
SunSpec. Ich hatte gesehen, dass die Fronius Inverter Implementierung SunSpec verwendet. Mit SunSpec kenne ich mich nur nicht aus.
Gerne. Das schöne an SunSpec ist eigentlich, dass man sich dann genau um solche Themen nicht kümmern muss.
Du könntest die Implementierung des SolarEdge Netzzählers als Vorlage verwenden → openems/io.openems.edge.solaredge/src/io/openems/edge/solaredge/gridmeter/SolarEdgeGridMeterImpl.java at develop · OpenEMS/openems · GitHub
@stefan.feilmeier
Ich hatte mir die Implementierung des SolarEdge Meters mal angeschaut, aber dann gesehen, dass das Model S213, welches für das Fronius Meter benötigt wird, in DefaultSunSpecModel nicht enthalten ist und bin dann auf Modbus umgeschwenkt.
Wenn ich das richtig verstehe, muss ich mittels SunSpecCodeGenerator DefaultSunSpecModel um das Model erweitern?
Im SunSpecCodeGenerator ist das Model S213 unter IGNORE_FILES gelistet.
Wird das Model ignoriert, weil es noch nicht unterstützt werden kann oder weil
es bisher nicht benötigt wird?
Würde es also genügen, das Model aus IGNORE_FILES herauszunehmen?
Ich beantworte meine Frage gleich selbst. Ich habe das S213 Model aus IGNORE_FILES herausgenommen und mir eine DefaultSunSpecModel erzeugt, die das S213 Model enthält.
Dann habe ich zum Testen den Code des SolarEdgeGridMeters so geändert, dass er das Model
benutzt. Das Ergebnis ist, dass die Werte erfolgreich aus dem Fronius SmartMeter ausgelesen
werden. Auch die Aufsummierung funktioniert jetzt,
Allerdings bin ich jetzt auf ein anderes Problem gestoßen:
In der Klasse AbstractSunSpecMeter erfolgt die Zuordung der SunSpec-Points zu den einzelnen Channels. Hier musste ich für jeden Wert den passenden aus dem S213 Model
hinzufügen.
Allerdings negiert das SolarEdgeGridMeter den Wert für ActivePower. Das führt bei dem Fronius SmartMeter aber dazu, dass Bezug zu Einspeisung wird.
Dies ist der Code dazu:
@Override
protected void onSunSpecInitializationCompleted() {
this.logInfo(this.log, "SunSpec initialization finished. " + this.channels().size() + " Channels available.");
this.mapFirstPointToChannel(//
ElectricityMeter.ChannelId.FREQUENCY, //
SCALE_FACTOR_3, //
S204.HZ, S203.HZ, S202.HZ, S201.HZ, S213.HZ);
this.mapFirstPointToChannel(//
ElectricityMeter.ChannelId.ACTIVE_POWER, //
INVERT, //
S204.W, S203.W, S202.W, S201.W, S213.W);
this.mapFirstPointToChannel(//
ElectricityMeter.ChannelId.REACTIVE_POWER, //
INVERT, //
S204.VAR, S203.VAR, S202.VAR, S201.VAR, S213.VAR);
this.mapFirstPointToChannel(//
Wie gehe ich an der Stelle am besten vor? Die Methode zu überladen scheint mir nicht der richtige Weg zu sein. Eigentlich macht das Mapping in dieser Klasse wenig Sinn, wenn es doch hardware-abhängig erfolgen muss
Danke fürs Testen.
Wir hatten einige “Models” bisher einfach ignoriert, wenn sie z. B. “repeating”-Register hatten; diese haben wir in OpenEMS noch nicht umgesetzt. Aber manchmal geht Probieren über Studieren!
Ok, blöd. Wir haben in vielen Zählern eine invert-Konfigurationseinstellung eingebaut, die z. B. verwendet wird, wenn der Zähler falsch herum eingebaut wurde, oder Verbrauch statt Erzeugung misst.
Wir könnten hier also einfach einen boolean invert über die activate()-Methode übergeben und dann ActivePower umdrehen und die Energy-Channels vertauschen.
Gruß,
Stefan
Das stimmt wohl. Hatten wir zuletzt ja auch bei der Umsetzung für den SDM120. Allerdings würde die Methode dann ziemlich unübersichtlich. Denn es werden zahlreiche Werte für SolarEdge invertiert.
Ich habe mittlerweile den Eindruck, dass die Umsetzung für SolarEdge etwas fragwürdig ist.
Hier ein Beispiel:
this.mapFirstPointToChannel(//
ElectricityMeter.ChannelId.ACTIVE_CONSUMPTION_ENERGY_L1, //
DIRECT_1_TO_1, //
S204.TOT_WH_EXP_PH_A, S203.TOT_WH_EXP_PH_A, S202.TOT_WH_EXP_PH_A, S201.TOT_WH_EXP_PH_A);
Hier wird ein Consumption-Channel mit einem Export-Wert belegt.
Wenn ich das richtig sehe, müsste ich den invert-Wert vergleichsweise weit herunterreichen,
da sich die Stelle in der Finalisierung der SunSpec Initialisierung befindet.
Ich würde mit einer solchen Umsetzung auch zwangsläufig die SolarEdge Meter Implementierung ändern, was ich nicht testen kann.
Du hast sicherlich recht, dass SmartMeter hin und wieder auch falsch herum eingebaut werden, aber ich meine, dass man das bei SunSpec fähigen nicht tun darf. Bei mir hängt das SmartMeter über Modbus am Fronius-Wechselrichter. Meine Wallbox-Steuerung kommt damit klar. Auch meine Wärmepumpe kann über SunSpec gut mit dem SmartMeter kommunizieren. Wenn der falsch herum eingebaut wäre, könnte die Lösung nur in einem Umbau des SmartMeters bestehen.
Ich denke, dass es Szenarien gibt, wo eine Invert-Konfiguration Sinn macht. Der SDM120 wird vermutlich mal als Verbrauchs- und mal als Erzeugungszähler eingesetzt. Bei dem Fronius SmartMeter sehe ich das eher nicht so.
Im Moment favorisiere ich die Methode in meiner Fronius-Implementierung zu überladen. Dann fasse ich die Solaredge Umsetzung nicht an,