Bridge SML Dependency Resolving Problem

Hallo,

ich arbeite gerade daran ein Smartmeter von einem Netzversorger einzubinden. Dazu hab ich eine neue Bridge angelegt, die SML mit dem Meter sprechen kann. Bei meinen Unit- und Component Tests klappt es schon. Aber wenn ich die Dependencies resovle, komme ich nicht an folgender Fehlermeldung vorbei:

Resolution failed. Capabilities satisfying the following requirements could not be found:
    [<<INITIAL>>]
      ⇒ osgi.identity: (osgi.identity=io.openems.edge.bridge.sml)
          ⇒ [io.openems.edge.bridge.sml version=1.0.0.202209181024]
              ⇒ osgi.service: (objectClass=org.openmuc.jrxtx.SerialPort)
    [osgi.cmpn version=7.0.0.201802012110]
      ⇒ osgi.unresolvable: (&(must.not.resolve=*)(!(must.not.resolve=*)))
    [org.eclipse.jetty.alpn.server version=9.4.44.v20210927]
      ⇒ osgi.wiring.package: (&(osgi.wiring.package=org.eclipse.jetty.alpn)(version>=1.1.3))
    [ch.qos.logback.classic version=1.2.3]
      ⇒ osgi.wiring.package: (&(osgi.wiring.package=ch.qos.logback.core.util)(version>=1.2.0)(!(version>=2.0.0)))

Folgende neuen Einträge hab ich in das pom.xml eingetragen:

		<dependency>
			<groupId>org.openmuc</groupId>
			<artifactId>jsml</artifactId>
			<version>1.1.2</version>
		</dependency>
		<dependency>
			<groupId>org.openmuc</groupId>
			<artifactId>jrxtx</artifactId>
			<version>1.0.1</version>
		</dependency>

Und im bnd file steht folgendes:

Bundle-Name: OpenEMS Edge Bridge SML
Bundle-License: https://opensource.org/licenses/EPL-2.0
Bundle-Version: 1.0.0.${tstamp}

-buildpath: \
	${buildpath},\
	io.openems.common,\
	io.openems.edge.common,\
	org.openmuc.jsml;version='1.1.2',\
	org.openmuc.jrxtx;version='1.0.1',\
	jaxb-api
	
-testpath: \
	${testpath}

Die Native Library die noch benötigt wird, hab ich über die Project Settings schon eingetragen. Denke an der liegt es nicht.
Kann mir jemand weiterhelfen? Liegt das an einer Versions-Inkompatibilität? Ich bin kurz davor jrxtx zu verwerfen und selber einen Serial-Port-Wrapper zu schreiben. Hab leider schon viel Zeit ins debuggen von dem Problem gesteckt. Aber ich kenn mich mit BND-Tools noch nicht gut aus.
Danke schon mal.

Hallo,

Dependencies in Java/OSGi können einem leider manchmal den letzten Nerv kosten. Ich kenne das leider nur zu gut.

@DerStoecki: habt ihr nicht bei Consolinno Smart-Meter über SML eingebunden?

Ich würde nicht so weit gehen, einen eigenen Wrapper zu schreiben. Die Modbus-Bridge bzw. j2mod-Bibliothek verwendet jSerialComm:

Falls du nicht weiter kommst, kannst du gerne deinen Branch öffentlich stellen, dann kann ich es selbst mal versuchen. Gerne als Pull-Request, dann kannst du mir auch Schreibrechte auf den Branch geben.

Gruß,
Stefan

Danke für die Tipps. Ich probier’s mal mit JSerialComm. Melde micht, falls ich nicht weiter komme. Hab mich ehrlich gesagt schon gewundert warum es noch keine SML-Bridge gibt. Sehr viele verbaute Smartmeter basieren doch eigentlich darauf, oder? Vermute, dass wäre für OpenEms schon ein Gewinn, wenn wir die meisten Smartmeter unterstützen könnten.

Hallo Stefan,

ich bin leider nicht weiter gekommen. Mit JSerialComm hatte ich das gleiche Problem. Kannst du es dir mal anschauen: Add Smart Message Language (SML) Serial Bridge by mishbieg · Pull Request #1935 · OpenEMS/openems · GitHub? Ich hab wieder die vorherige Serial Port Library im Code. Die passt einfach besser zu jsml. Wenn es dann hoffentlich läuft, muss ich noch einiges aufräumen. Ich hab einfach die MBus Bridge als Vorlage genommen, da die auch eine Library von OpenMuc verwendet. Der SML String für den Dummy Serial Port ist von einem Iskraemeco MT175 aufgezeichnet und sollte passen. Hatte den auch von Hand geprüft. Wenn alles klappt so wie ich mir das vorstelle, sollte man so auch ohne Hardware gute Simulationswerte für’s Entwickeln haben.

Danke schon mal für die Hilfe.

Gruß,
Michael

Hey Stefan,
Hey Michael,

Sorry, dass ich so spät reagiere.

Also ich habs mir nochmal angesehen und das einzige was ich sehe:

du könntest in deiner BND einfach mal ausprobieren, das genauso zu beschreiben wie bei der mbus Bridge also in deinem Fall:

Bundle-Name: OpenEMS Edge Bridge SML
Bundle-License: https://opensource.org/licenses/EPL-2.0
Bundle-Version: 1.0.0.${tstamp}

-buildpath: \
	${buildpath},\
	io.openems.common,\
	io.openems.edge.common,\
	org.openmuc.jsml;version='1.1.2',\
	org.openmuc.jrxtx;version=1.0
	jaxb-api
	
-testpath: \
	${testpath}

Darüber hinaus könntest du sonst probieren:

in io.openems.wrapper → bnd.bnd

den Punkt

org.openmuc.jrxtx;version='1.0.1'
In den Buildpath anzuhängen

Stefan:
Bezüglich des SML habe ich nochmal geguckt, da sehe ich keine Komponente dazu bei uns, aber vermutlcih hat das jemand über ein kleines Skript außerhalb von OpenEMS gemacht.

Michael:

Falls das nicht helfen sollte, kann ich dir noch den Vorschlag machen nen neuen Wrapper in io.openems.wrapper zu hinterlegen

dazu machst du folgendes:

Dependency kann nicht aufgelöst werden in OpenEMS → Wie beheb ich das?

Vermutlich passiert dieser Fehler wenn es keine MAVEN Dependency ist.

Dann benötigen wir einen Wrapper der die .jar fix einbindet in unser projekt dazu folgende schritte:

  1. gehe in die Pom xml und hinterlege die Dependency
  2. navigiere in den io.openems.wrapper
  3. copy paste eine wrapper datei die eine externe lib einbindet, so wie bspw sdnotify
  4. Include-Resource → ‘@NameDerJar.jar
  5. dsannotations: * , metatypeannotations: *
  6. Export-Package: Hier hinterlege was innerhalb der Jar als erster Name auftaucht (nicht die META-INF)
  7. sources → false
  8. Binde in die Datei die die dependency braucht die wrapper datei ein
  9. EdgeApp.bndrun erhält bei runbundles den wrapper den du erstellt hast

Beispiel → wäre in SDNotify

Bundle-Name: SDNotify
Bundle-Description:  SDNotify implements the systemd notification protocol in Java.
Bundle-DocURL: https://github.com/faljse/SDNotify
Bundle-License: https://opensource.org/licenses/LGPL-2.1
Bundle-Version: 1.3

Include-Resource: @SDNotify-1.3.jar

-dsannotations: *

-metatypeannotations: *

Export-Package: \
    info.faljse.SDNotify
	
-sources: false

Alternativ wenn KEINE Jar → Hier als Beispiel an der paho - mqttv3

Bundle-Name: paho-mqttv3
Bundle-DocURL: https://github.com/eclipse/paho.mqtt.java
Bundle-License: https://opensource.org/licenses/EPL-2.0
Bundle-Version: 1.2.5

Fragment-Host: org.eclipse.paho.client.mqttv3

-dsannotations: *

-metatypeannotations: *

Export-Package: \
	org.eclipse.paho.client.mqttv3,\
	org.eclipse.paho.client.mqttv3.internal,\
	org.eclipse.paho.client.mqttv3.logging,\
	org.eclipse.paho.client.mqttv3.persist,\
	org.eclipse.paho.client.mqttv3.spi,\
	org.eclipse.paho.client.mqttv3.util,\

-sources: false

→ io.openems.wrapper → bnd.bnd
(ausschnitt)

        org.dhatim:fastexcel;version='0.12.13',\
	org.eclipse.paho.client.mqttv3;version='1.2.3',\
	org.eclipse.paho.mqttv5.client;version='1.2.5',\

(Wobei hier natürlich nur der teil mit mqttv3 wichtig ist)

→ EdgeApp.bndrun

org.eclipse.paho.client.mqttv3;version='[1.2.2,1.2.6)',\

Ich hoffe, dass eine der genannten Möglichkeiten dein Problem beheben kann.

LG

Danke schon mal für die ausführlichen Tipps, ich probiere das die nächsten Tage mal aus und melde mich ob einer davon geholfen hat.