Hallo,
ich habe als ersten Gehversuch die Unterstützung des Einphasen-Zählers Eastron SDM 120 umgesetzt und funktioniert soweit.
Derzeit habe ich die Umsetzung in io.openems.edge.meter.eastron.sdm120 angesiedelt. Der Zähler ist der kleine Einphasen-Cousin des SDM 630. Seine Modbus-Register sind ein Subset von denen des SDM 630.
Bevor ich die Umsetzung pushe wollte ich fragen, ob die Umsetzung in dem separaten Package unter eastron so ok ist. Rein technisch ist die Umsetzung ja sehr ähnlich zu dem SDM 630.
Ob es einen SDM 120 von microcare gibt, weiss ich gerade nicht. Sehr verbreitet scheint er mir von Eastron zu sein.
Siedelt man den SDM 120 auch unter microcare an, um seine Verwandschaft zu dokumentieren?
Denkbar wäre auch, dass es nur eine Implementierung gibt, die beide unterstützt, was jedoch mit einer Umbenennung einher ginge?
Was ist hier wohl die bessere Vorgehensweise?
Noch eine Frage zum Verständnis. Der Zähler ist derzeit intern als Verbrauchszähler verdrahtet, hängt aber an einer PV-Anlage. Dadurch bekomme ich negative Werte geliefert. Die bleiben auch negativ, unabhängig davon, ob ich den Zähler in OpenEMS als Verbraucher oder Produzenten konfiguriert habe. Ist das so korerekt?
wir versuchen normalerweise schon darauf zu achten, gleichartige Zähler (idealerweise vom selben Hersteller) in einem Bundle zu haben.
Ähnlich zu Janitza oder Socomec
Wenn ich mit der Annahme richtig liege, dass der eigentliche Zähler der selbe ist, müsste wahrscheinlich auch das existierende Paket io.openems.edge.meter.microcare.sdm630 nochmal sinnvoll umbenannt werden und z.B. alles in io.openems.edge.meter.eastron zu finden sein.
Unter Microcare SDM630 findet man tatsächlich auf google keinen eintrag mehr. Wäre eventuell auch darum schon schlauer, das umzubenennen auf Eastron, um eine suchbarkeit zu erleichtern
Wenn ich mit der Annahme richtig liege, dass der eigentliche Zähler der selbe ist, müsste wahrscheinlich auch das existierende Paket io.openems.edge.meter.microcare.sdm630 nochmal sinnvoll umbenannt werden und z.B. alles in io.openems.edge.meter.eastron zu finden sein.
Ja, das wäre sinnvoll. Die Meter-Implementierung von Microcare aus Südafrika (https://microcare.co.za/) war einer der ersten externen Beiträge zu OpenEMS. “Eastron” scheint tatsächlich der geläufigere Inverkehrbringer zu sein - ich finde die Umbenennung und zusammenführung sehr gut und sinnvoll.
Noch eine Frage zum Verständnis. Der Zähler ist derzeit intern als Verbrauchszähler verdrahtet, hängt aber an einer PV-Anlage. Dadurch bekomme ich negative Werte geliefert. Die bleiben auch negativ, unabhängig davon, ob ich den Zähler in OpenEMS als Verbraucher oder Produzenten konfiguriert habe. Ist das so korerekt?
Ich schlage auch vor, das mit einem invert-Setting zu implementieren. Das passiert ja tatsächlich häufig, dass ein Zähler falsch herum eingebaut wird und dann “per Fernwartung” korrigiert werden soll. So geht das elegant und es gibt auch ein paar Beispiele im Code.
Sehr gut. Dann benenne ich das sdm630 Paket um. Die Suche auf der microcare Homepage liefert auch keine Informationen zu dem Zähler. Scheint nicht sehr verbreitet und nicht mehr im Handel zu sein.
Das invert-Setting habe ich schon umgesetzt. War in der Tat nicht aufwändig.
Wie ist dann das weitere Procedere? Lt. Dokumentation Pull Request erzeugen. Allerdings komme ich nicht soweit, da ich nicht pushen darf. Sry für die dumme Frage - habe bisher nur mit einem firmeninternen bitbucket gearbeitet. Github bisher nur lesend.
Ds ist richtig. Ich habe nur gesehen, dass sich das, was ich hochgeladen habe, wegen irgendwelcher Dependency-Probleme nicht übersetzen lässt.,Die Klasse ist aber ok.
Die Korrektur habe ich aber bereits gemacht, muss sie nur noch hochladen und in einen PR kippen.
Der wird aber erst mal nur die Unterstützung des SDM120 enthalten. Sie Umbenennung für den SDM630 folgt dann.
hab schon mal vorgegriffen und den Code hochgeladen incl. der Namensänderung, ich weiss nur nicht, in wie weit es okay ist, den Namen einfach so zu ändern @stefan.feilmeier sollte ja dann ein Breaking Change sein, für diejenigen, die dieses Meter aktuell nutzen, oder?
ok, dann spare ich mir den PR und ziehe mich aus dem Thema raus. Btw. ich hatte noch eine Ergänzung gemacht, dass bei dem Meter die Phase konfigurierbar ist. Ob die Ergänzung in meinem repo auf githib schon liegt, weiß ich gerade nicht. Aber wie ich gesehen habe, ist das in deinem PR ja enthalten.
@stefan.feilmeier Was die Umbenennung angeht - es ist doch keine Seltenheit, das identische Hardware unter verschiedenen Markennamen auf dem Markt ist. Gibt es in OpenEMS Mechanismen, mit denen sich das abbilden lässt bzw. wurde schon mal darüber nachgedacht, qie sich das realisieren ließe?
Hallo @fanass. OSGi identifiziert eine Konfiguration anhand der Factory-ID, also dem Wert, der in der @Component(-Annotation als name angegeben wird. Dieser Wert sollte deshalb in der Regel wirklich niemals abgeändert werden, weil sonst auf jedem System die Konfiguration neu gesetzt werden muss. Dagegen ist es für OSGi irrelevant, wie das Bundle oder Java-Package heißt, in dem diese Component liegt. Man kann also jederzeit Dateien und Ordner verschieben/umbenennen. Solange sich die Factory-ID nicht ändert, ist es kein breaking change.
Wenn Hardware wirklich identisch ist, muss man sich für einen generischen Namen entscheiden. Bei “fast identischer” Hardware erstellen wir dagegen mehrere Komponenten und nutzen z. B. Abstrakte Klassen (=inheritance) oder Delegation um Code wiederzuverwenden.
@Sn0w3y: Ich versuche was ich kann, aber zur Zeit sind es einfach zu viele PRs. Vielleicht kann sonst jemand aus der Community ein erstes Review durchführen?
Den Zähler habe ich nur vorübergehend im Testbetrieb der Anlage
