openhabforum.de

Der Autor des Bindings schreibt hier https://github.com/csowada/openhab2-add ... /README.md :

Binding Configuration

You can add up to three custom configuration files or one bundle file. This allows you to add new eBUS devices without updating this binding. The built-in configurations are always loaded first, the own files are loaded afterwards. These can also overwrite already loaded commands. You must use the URL syntax. For more information see URL on wikipedia.

There are several settings for a binding:

Configuration URL (configurationUrl)
Define a URL to load external configuration files

Configuration URL (configurationUrl2)
Define a second URL to load external configuration files

Configuration URL (configurationUrl3)
Define a third URL to load external configuration files

Configuration Bundle URL (configurationBundleUrl)
Define a bundle URL to load a set of configurations at once.

Example URLs

http://www.mydomain.com/files/custom-configuration.json
file:///etc/openhab/custom-configuration.json

Nur scheibt er nirgentwo, wo denn diese Konfiguration abgelegt wird.Da schlagi eine Fehlermeldung bei laden einer externen Datei kriegt, muß er ja diese Datei irgentwo eingetragen haben. Ich hatte gehofft, daß er sich vielleicht meldet und mir verrät, wo und wie er seine Datei eingtragen hat
Da sich diese Konfiguration auf das Binding und nicht auf irgent ein Thing bezieht, könnte schon eine Datei unter services in frage kommen, nur ist die Frage wo und wie
Ich werde jetzt mal die Version probieren, die schlage benutzt hat, vielleicht hat sich in meiner Version ja was verschlimmbessert

Also, so wie ich das sehe, kannst Du eine gerätespezifische Konfiguration so wie unter dem Link https://github.com/csowada/ebus/blob/ma ... uration.md beschrieben anlegen. Damit die auch zur Verfügung steht, musst Du dann einen Link in einer json Datei hinterlegen. Die muss aber in einem ganz bestimmten Verzeichnis liegen, und so wie ich das verstehe, keinesfalls im conf-Zweig, sondern dort, wo die Originaldateien liegen. Suche also am besten nach einer der mitgelieferten Dateien (z.B. vaillant-vrc700-bundle-configuration.json) und schau Dich dort im Verzichnis um, ob es ein Verzeichnis commands gibt (das wäre dann ein starkes Indiz...)
So wie ich das verstehe, hat der Programmierer dadurch die Möglichkeit, das Addon mit zusätzlichen Funktionen zu versehen, ohne das Addon neu compilieren zu müssen. Die Konfiguration in Richtung openHAB muss aber ganz normal über die Bridge/Thing-Schnittstelle erfolgen, wie in dem verlinkten Dokument ausführlich beschrieben

udo1toni hat geschrieben: ↑11. Jun 2020 14:59 Also, so wie ich das sehe, kannst Du eine gerätespezifische Konfiguration so wie unter dem Link https://github.com/csowada/ebus/blob/ma ... uration.md beschrieben anlegen. Damit die auch zur Verfügung steht, musst Du dann einen Link in einer json Datei hinterlegen. Die muss aber in einem ganz bestimmten Verzeichnis liegen, und so wie ich das verstehe, keinesfalls im conf-Zweig, sondern dort, wo die Originaldateien liegen. Suche also am besten nach einer der mitgelieferten Dateien (z.B. vaillant-vrc700-bundle-configuration.json) und schau Dich dort im Verzichnis um, ob es ein Verzeichnis commands gibt (das wäre dann ein starkes Indiz...)

Im Prinzip war ich auch schon so weit, aber es gibt weder eine Datei in der vaillant im Namen vorkommt, noch irgentwas mit commands das mit dem ebus zu tun hat. Die Gerätespezifischen Dateien liegen alle in einer *.jar-Datei, und da ist natürlich kein Ändern möglich.

Nach meinem Verständniss können in der /services/ebus.cfg Datei bis zu 4 Dateien angegeben werden, in denen eigene Gerätekonfigurationen abgelegt werden können, wo die Dateien nun letzlich liegen, sollte egal sein, solange der Pfad dahin relativ zur Root angegeben wird :
Meine Root : O:/openhab255/ meine URL zu einer der Dateien : file:///conf/ebus/custom.json
Daraus sollte der Gesammtpfad O:/openhab255/conf/ebus/custom.json werden

So wie ich das verstehe, hat der Programmierer dadurch die Möglichkeit, das Addon mit zusätzlichen Funktionen zu versehen, ohne das Addon neu compilieren zu müssen. Die Konfiguration in Richtung openHAB muss aber ganz normal über die Bridge/Thing-Schnittstelle erfolgen, wie in dem verlinkten Dokument ausführlich beschrieben

Im Prinip läuft das Binding ohne Probleme, die Things stehen ( noch ) in der jsondb, die Items hab ich mit Microsoft Code aus der jsondb in normale *.items Dateien extraiert. Es ist nur jämmerlich wenig an Daten, die ich da rauskriege. Ich kriege gerade mal die Daten aus dem Regler und das ist mir natürlich nicht genug. Nichts von den Allgemeinen Daten wird angezeigt, und gerade darauf kommt es mir an, darum auch meine Versuche, eigene *.json-Dateien einzubinden

Alles in allem ist zu sagen, daß die Dokumentation bestenfalls als Lückenhaft zu bezeichnen ist ( Kuck dir mal die Erklärung der Datentypen an :
Typ Länge Beschreibung
data2c 2 DATA2C
ist wenig hilfreich

Ich hab jetzt das Beispiel in eine json-Datei kopiert, diese im Pfad /conf/ebus/custom abgelegt und versuche mal weiter

Ich bleib am Ball

Die einfachste Variante wäre in diesem Fall, den Entwickler zu kontaktieren

udo1toni hat geschrieben: ↑11. Jun 2020 20:09 Die einfachste Variante wäre in diesem Fall, den Entwickler zu kontaktieren

Hab ich vor ca. 2 Stunden getan
Aber ich hab da wenig Hoffnung

Halleluja ( zwar noch icht ganz, aber ein Großer Schritt )
Ich habe im Quelltext nach der Methode gesucht, die bei schlagi den Fehler gemeldet hat : EBusTypeProviderImpl und eine Zeile über der Definition hab ich einen Eintrag gefunden : configurationPid = {"binding.ebus"}
Dann habe ich die Datei unter /services/ebus.cfg umbenannt in /services/binding.ebus.cfg, neu gestartet und nun erhalte ich eine Fehlermeldung :
Das System kann den angegebenen Pfad nicht finden
Damit weiss ich jetzt schonmal wie die Knfigurationsdatei heisst !! Jetzt gehts nur noch darum, die richtige url einzutragen und alles wird gut

Warum, zum Henker steht das nirgentwo bzw. warum wird die Datei nicht automatisch angelegt ?

Tja, das ist halt ein externes Binding... AEG (auf eigene Gefahr)

udo1toni hat geschrieben: ↑12. Jun 2020 22:28 Tja, das ist halt ein externes Binding... AEG (auf eigene Gefahr)

Das interne ebus-Binding ( 1.14..) ist auch äh hat Verbesserungspotential Nach der Installation und der Konfiguration ist im PaperUI genau nichts zu sehen ! Das Binding ist installiert, man sieht die Dateien aber man kann genau gar nichts damit anfangen.

Egal, mein Problem ist gelöst, er findet jetzt den json-File, stellt fest, wenn ein Fehler drin ist und bietet im PaperUI die Möglichkeit, das Zeug als Thing zu übernehmen. Jetzt geht es nur noch darum, den json-File sinnvoll zu füllen

V1 Bindings sind grundsätzlich in Paper UI unsichtbar, das gilt für alle V1 Bindings (also abgesehen von der Anzeige, dass sie installiert sind, natürlich). Das ist übrigens ausführlich in der offiziellen Dokumentation beschrieben.

Leider ist der Prozess, ein Binding in openHAB offiziell verfügbar zu machen, nicht eben einfach. Mit openHAB2 ist das noch wesentlich schwieriger geworden, weil die Maintainer hohe Ansprüche an den Code haben. Auf der anderen Seite macht das die Installation insgesamt zuverlässiger und das Debugging ebenfalls, es gibt also gute Gründe für die strikten Regeln.
Trotzdem wäre es natürlich schöner, wenn neue Bindings (und V2 Ersatz für V1 Bindings) zügiger in openHAB Einzug halten könnten.

udo1toni hat geschrieben: ↑13. Jun 2020 14:43 V1 Bindings sind grundsätzlich in Paper UI unsichtbar, das gilt für alle V1 Bindings (also abgesehen von der Anzeige, dass sie installiert sind, natürlich). Das ist übrigens ausführlich in der offiziellen Dokumentation beschrieben.

Jetzt, wo du das sagst Ich war so daran gewöhnt, das alles mindestens ein Thing hat, daß ich danach beim eBus auch gesucht habe. Aber ich hab nochmal nachgesehen, die FritzBox hat auch keines, egal, das Binding läuft jetzt, die Geräte-Dateien sind meine eigenen ( natürlich z.Z. nur Kopien der Original-Dateien ) und ich kann anfangen, zu experimentieren

Leider ist der Prozess, ein Binding in openHAB offiziell verfügbar zu machen, nicht eben einfach. Mit openHAB2 ist das noch wesentlich schwieriger geworden, weil die Maintainer hohe Ansprüche an den Code haben. Auf der anderen Seite macht das die Installation insgesamt zuverlässiger und das Debugging ebenfalls, es gibt also gute Gründe für die strikten Regeln.

Da bin ich auch recht froh drum