Probleme beim Aufsetzen Edge + Goodwe + BYD

Hallo zusammen,

wie bereits in meinem anderen Post beschrieben, suchen wir nach einer Möglichkeit, Speichersysteme intelligent zu steuern. Hierzu haben wir uns schon Starterkits besorgt, wenn man so möchte. Wir haben bei einem Mitarbeiter einen FENECON Pro Hybrid 10 mit dem Koco Wechselrichter und bei einem anderen einen FENECON Pro Hybrid 10 GW mit Goodwe WR eingebaut. Einbau und Inbetriebnahme ging relativ problemlos und die Steuerung über die original FEMS funktioniert auch.
Nun möchten wir natürlich die volle Power von openEMS testen und haben uns deshalb einen Beaglebone black besorgt, auf dem wir die Software laut der Anleitung installiert haben. Es sei gesagt, dass wir leider keine JAVA-Experten im Haus haben und ich lediglich ein paar Kenntnisse in Python oder JavaScript besitze.
Zunächst soll die Speicherkombination mit BYD und Goodwe getestet werden. Leider gab es aber bei der Konfiguration Probleme, bei denen ich nicht weiter weiß. Ich hoffe deshalb, dass ihr mir helfen könnt :slight_smile:

Text aus dem Log:
Jan 25 09:45:56 openEMS java[2112]: 2021-01-25 09:45:56,749 [modbus0 ] ERROR [s.common.worker.AbstractWorker] Worker error. NoSuchMethodError: java.nio.ByteBuffer.rewind()Ljava/nio/ByteBuffer; Jan 25 09:45:56 openEMS java[2112]: java.lang.NoSuchMethodError: java.nio.ByteBuffer.rewind()Ljava/nio/ByteBuffer; Jan 25 09:45:56 openEMS java[2112]: at io.openems.edge.bridge.modbus.api.element.AbstractDoubleWordElement._setInputRegisters(AbstractDoubleWordElement.java:53) Jan 25 09:45:56 openEMS java[2112]: at io.openems.edge.bridge.modbus.api.element.AbstractModbusRegisterElement.setInputRegisters(AbstractModbusRegisterElement.java:87) Jan 25 09:45:56 openEMS java[2112]: at io.openems.edge.bridge.modbus.api.task.AbstractReadInputRegistersTask.doElementSetInput(AbstractReadInputRegistersTask.java:27) Jan 25 09:45:56 openEMS java[2112]: at io.openems.edge.bridge.modbus.api.task.AbstractReadInputRegistersTask.doElementSetInput(AbstractReadInputRegistersTask.java:1) Jan 25 09:45:56 openEMS java[2112]: at io.openems.edge.bridge.modbus.api.task.AbstractReadTask.fillElements(AbstractReadTask.java:113) Jan 25 09:45:56 openEMS java[2112]: at io.openems.edge.bridge.modbus.api.task.AbstractReadTask._execute(AbstractReadTask.java:68) Jan 25 09:45:56 openEMS java[2112]: at io.openems.edge.bridge.modbus.api.task.AbstractTask.execute(AbstractTask.java:82) Jan 25 09:45:56 openEMS java[2112]: at io.openems.edge.bridge.modbus.api.ModbusWorker.forever(ModbusWorker.java:172) Jan 25 09:45:56 openEMS java[2112]: at io.openems.common.worker.AbstractWorker$1.run(AbstractWorker.java:112) Jan 25 09:45:57 openEMS java[2112]: 2021-01-25 09:45:57,263 [re.Cycle] INFO [ntroller.debuglog.DebugLogImpl] [ctrlDebugLog0] _sum[State:Ok Ess SoC:9 %|L:-24 W Grid:545 W Consumption:521 W] charger0[L:UNDEFINED] charger1[L:UNDEFINED] ess0[SoC:9 %|L:-24 W|On-Grid|Allowed:-10000;10000 W] meter0[L:545 W]

Vielen Dank und schöne Grüße
Felix

Hallo,

der Fehler ist schon einmal aufgetaucht und scheint an unterschiedlichen Java-Version zu liegen:

Welche Ausgabe gibt denn java -version auf dem Beaglebone zurück?

Hier sollte z. B. so etwas in der Art kommen:

root@fems:/home/fems# java -version
openjdk version "1.8.0_275"
OpenJDK Runtime Environment (build 1.8.0_275-8u275-b01-1~deb9u1-b01)
OpenJDK Client VM (build 25.275-b01, mixed mode)

Übrigens kann für ‘die ersten Gehversuche’ das System auch direkt aus der Eclipse-Entwicklungsumgebung heraus angesteuert werden. Dazu hatte ich hier einmal etwas beschrieben:

Gruß,
Stefan

Hallo Stefan,

vielen Dank für deine Antwort. Hier der Output aus dem Terminal:

felix@openEMS:~$ java -version
openjdk version "1.8.0_275"
OpenJDK Runtime Environment (build 1.8.0_275-b01)
OpenJDK Client VM (build 25.275-b01, mixed mode)

Sollte also eigentlich passen oder?

Danke und schöne Grüße
Felix

Hallo Felix,

ja, das wäre richtig. Die Jar-Datei hast du selbst aus Eclipse erstellt? Vermutlich ist das Problem dann, dass OpenEMS Edge mit einer Version ab Java 9 kompiliert wurde. (hier habe ich Hinweise in diese Richtung gefunden: https://stackoverflow.com/a/51223234/4137113)

Leider erstellen wir bei den Releases noch keine automatischen Jar-Dateien. Ich habe jetzt einmal eine Datei manuell erstellt und im letzten Release hinterlegt. Kannst du die bitte mal testen? Diese wurde mit Java 8 erstellt:

https://github.com/OpenEMS/openems/releases/download/2021.1.0/openems-edge-2021.1.0.jar

Gruß,
Stefan

Hallo Stefan,

vielen Dank, das war wirklich das Problem! Mit der Jar-Datei, die mit Java 8 erstellt wurde, hat es auf Anhieb funktioniert. UI habe ich nun auch hinbekommen und alles läuft soweit, wie es sollte :wink:
Nun kann das Testen beginnen!

Vielen Dank noch mal! :wink:

Schöne Grüße
Felix

1 Like

Das Testen läuft bisher ohne Probleme. Ich suche nun aber einen Möglichkeit den Speicher direkt über das Netz zu beladen, wenn die Börsenpreise günstig sind. Bisher kann ich das nur direkt über die PV Master App einstellen. Funktioniert das über openEMS auch direkt? Dieses Feature wäre essenziell für unser nächstes Forschungsprojekt.

Vielen Dank schon mal!

Grüße
Felix

Hallo Felix,

das ist schon mal sehr gut. Der nächste Schritt ist jetzt, dass der Speicher grundsätzlich angesteuert werden kann. Um das zu testen ist der Controller Ess Fix Active Power sehr gut geeignet. Seine Konfiguration benötigt lediglich:

  • ess_id: die Component-ID des Speichers/Batterie-Wechselrichters - z. B. “ess0”
  • power: die gewünschte Be-/Entladeleistung: positiv für Entladung, negativ für Beladung

Wenn das funktioniert, kannst du dich an das Schreiben eines eigenen Controllers setzen, der dann die Börsenpreise abfragt und entsprechend eine Be-/Entladevorgabe setzt.

Die entscheidende Code-Zeile im Controller Ess Fix Active Power ist:

Über die Priorisierung im Scheduler können die Controller auch kombiniert werden - z. B. kann dein Börsenpreis-Controller mit hoher Priorität immer dann eine Leistungsvorgabe (oder Begrenzung über setActivePowerLessThan oder setActivePowerGreaterThan vorgeben, wenn die Preise sehr hoch oder sehr niedrig sind. In der restlichen Zeit gibt er keine Vorgabe, so dass dann der nächste Controller in der Prioriät übernimmt (z. B. Balancing zur Eigenverbrauchsoptimierung bzw. Null-Ausregelung am Netzanschlusspunkt).

Gruß,
Stefan

Hallo Stefan,

ich habe versucht, die neuste Version über Eclipse zu exportieren. Leider funktioniert Eclipse nur noch mit Java 11+, also kann ich auch nicht mit Java 8 die JAR Dateien exportieren. Wie macht ihr das?

Gruß
Felix

Hallo Felix,

ich hatte das gleiche Problem wie folgt gelöst und im Forum gepostet

Vielleicht funktioniert es auch bei dir.

Viele Grüße
Christian

Hallo Christian,

leider hilft mir das nicht weiter, da ich einen Mac verwende und die Programme bzw. Pfade anders aufgebaut sind -.- Habe es zwar analog zu deinem Beispiel versucht, hatte aber keinen Erfolg.

Kleines Update: Habe mir nun eine Windows VM aufgesetzt und Eclipse mit Java 8 installiert. Das Exportieren funktioniert nun und es läuft soweit alles. Ich habe nun nur noch ein ungelöstes Problem, welches ich auch schon auf Github beschreiben habe: Ich bekomme keine Summenwerte in der History angezeigt.

Habe meinen BBB komplett neu aufgesetzt und auch schon neue Releases aufgespielt, aber alles ohne Erfolg. Hat jemand eine Idee, an was das liegen kann?

Danke und schöne Grüße
Felix

Hallo Felix,

ich verweise hier mal auf unsere Diskussion in den Github Issues - mit einer möglichen Lösung für das Problem.

Was die Build-Probleme angeht:

  1. Unser Continuous Integration baut eigentlich jeden Commit automatisch. (openems/build.yml at develop · OpenEMS/openems · GitHub) Die resultierenden Jar-Dateien müsste man theoretisch nur irgendwo als Snapshot-Versionen bereitstellen…
  2. Auch im Embedded-Bereich sind mittlerweile modernere Java Runtimes als v8 verfügbar. Ich denke mittelfristig sollten wir zumindest Version 11 voraussetzen. Spricht da eurerseits was dagegen?

Gruß,
Stefan

Hallo Stefan,

zu 1. vielen wäre wahrscheinlich geholfen, wenn ihr die Jar-Datei direkt mit ins Repository hochladen würdet :wink:
zu 2. ein Upgrade auf eine neuere Version kann auf jeden Fall nicht schaden und vereinfacht auch die Installation bei vielen Systemen, da dort in den Paketmanagern nur neuere Version zur Verfügung stehen und man die alten manuell hinzufügen muss.

Hallo @stefan.feilmeier,

gibts zu diesem Thema eigentlich schon was neues? Bisher sind ja leider keine Jar-Dateien bzw. Snapshots in den Releases dabei.

Habe nun aber auch ein neues Problem: Habe versucht den neusten Release zu installieren, was mir auch mit der Jar geglückt ist. Allerdings komme ich jetzt beim generieren der UI nicht mehr klar. Ich habe zumindest schon mal gemerkt, dass man nicht mehr ng build -c edge nutzen kann, sondern ng build -c openems-edge-dev nutzen muss. Die Daten werden dann auch generiert und ich habe sie auf meinen BBB geladen. Allerdings habe ich festgestellt, dass die Ordner svg und assets nicht mit generiert werden. Es scheint aber noch mehr zu fehlen, denn die im Browser bekomme ich nur eine weiße Seite und folgende Fehlermeldungen:


Die index.html liegt definitiv im Ordner und die PNGs habe ich ebenfalls in den Ordner kopiert.
Kannst du bzw. ihr mir helfen?

Habe es mittlerweile hinbekommen und selbst herausgefunden, dass man den Befehl ng build -c "openems,openems-edge-prod,prod" nutzen muss.

Hallo Felix,

richtig - sorry. Die Änderung wurde mit der Umstellung auf OEM-Fähigkeit des UI eingeführt. Dokumentiert wären die neuen Befehle hier: openems/README.md at develop · OpenEMS/openems · GitHub

Ich arbeite übrigens gerade am Upgrade auf Java Version 11, dann sollten so manche Build-Probleme und -Einschränkungen zukünftig wegfallen. Hier der Pull-Request:

Gruß,
Stefan