Unglaublich schwieriger Start mit OH2.4

[Wurschtel]

Hallo und ein frohes neues Jahr,

welches aber gleich mit Wirrwar anfängt:

Habe mir OH2.4 auf einen Ubuntu 18.04 gepackt und wollte mit dem knx2- und dem Netzwerkbinding starten.
Soweit - so gut bzw. nicht:

Das Networkbinding sucht sich nen Wolf und findet genau 0 Geräte und mit dem knx2-Binding komme ich keinen Millimeter voran.

Hier erstmal eine ganz generelles Unverständnis:
Alles was ich per PaperUI mache finden keinen Niederschlag in den conf-Verzeichnissen. Die bleiben alle leer - dort findet man nur die jeweiligen readme.txt.
Ist das richtig so?

Gruß
Thomas

[Jockel]

Ja das ist richtig.

Daher verwenden viele, mich selbst eingeschlossen, lieber weiter die config Dateien, die man dann z.B. auch unter Versionsverwaltung stellen kann.

[Julian0o]

Ich nutze auch nur die Dateien. Nur bei meinem Yamaha Plugin hab ich es nicht zum laufen bekommen und nutze das PaperUI. Ist irgendwie übersichtlicher finde ich und wenn mal was nicht läuft wenn man einfach neu installieren.

Achja, ja das ist richtig so. Das PaperUI ist keine Oberfläche um die Config Dateien zu bearbeiten sondern läuft parallel dazu.

[kruegertee]

Welche Schnittstelle verwendest Du, um auf den Bus zugreifen zu können? Ich habe einen IP-Router von MDT im Einsatz und damit keine Probleme.

Beim Networkbinding habe ich auch keine Geräte gefunden. Manuell ging es aber, ich brauchte nur die IP-Adresse des Gerätes angeben.

[udo1toni]

So sieht mein funktionierender Yamaha Receiver aus:

// Yamaha Receiver
Bridge yamahareceiver:yamahaAV:wozi "Yamaha Receiver RX-V575" [host="192.168.178.35"] {
  Thing zone MainZone "Yamaha Main Zone" @ "zuhause" [zone="Main_Zone"]
}

Was das Network Binding betrifft, so hat das mal funktioniert, aber wo ich es gerade in meinr Testinstallation probiere, sieht es so aus, das sich da etwas geändert hat. Als es ging, fand ich es eher nervig, mein Netz hat eine größere Menge Geräte, die Inbox war da ziemlich zugemüllt.
Vielleicht weiß jemand im englischen Forum Näheres.

[sihui]

Vielleicht weiß jemand im englischen Forum Näheres.

https://community.openhab.org/t/netw...265/23?u=sihui

[udo1toni]

Ah. liest sich so, als wäre das nicht beabsichtigt gewesen...

[Wurschtel]

Okayyyyyyyyy .... dann also am besten Finger weg von dieser PaperUI und ganz klassisch auf der Konsole arbeiten.
Bin mal gespannt, ob ich jetzt so mit dem ganzen things-Zeugs wenigstens mal nen connect zum KNX-Bus bekomme.

Die Idee war ja wohl gut ... insbesondere die fetch-option für die knx.devices - hab das so verstanden, daß man damit alle GA auslesen und auf einen Rutsch die entsprechenden items anlegen kann.

Vielleicht noch eben als Einstieg für mich:
in der knx.item steht dann zum Beispiel ganz oben das gateway (in meinem Fall ein Weinzierl 730 im Tunnelmodus) und nachfolgend die knx.devices wie Aktoren, Taster usw mit ihren physikalischen Adressen?

[DiMa]

Welche Fragen genau sind nach Lesen der Dokumentation denn offen? Und nein, "ganz oben" stehen in *.item Dateien weder Bridges, noch Devices/Geräte. Die stehen in *.things Dateien.

[udo1toni]

Okayyyyyyyyy .... dann also am besten Finger weg von dieser PaperUI und ganz klassisch auf der Konsole arbeiten.

Was meinst Du jetzt damit? Paper UI grundsätzlich funktioniert wunderbar. Dass das Network Binding offensichtlich momentan fehlerhaft funktioniert, hat nichts mit Paper UI zu tun. Wenn Du ein Thing manuell definierst, spielt es keine Rolle, ob Du das nun über Paper UI oder über eine *.things Datei erledigst.

Die Idee war ja wohl gut ... insbesondere die fetch-option für die knx.devices - hab das so verstanden, daß man damit alle GA auslesen und auf einen Rutsch die entsprechenden items anlegen kann.

Nein, das hast Du falsch verstanden. fetch=true liest verschidene Informationen aus dem Device aus - weche Informationen das sind, hängt vor allem vom Device ab. Meist bekommst Du die Seriennummer, den Hersteller und die Rom-Maskenversion, bei älteren Geräte vielleicht gar nichts.

in der knx.item

Du meinst die knx.things... (Der exakte Name ist irrelevant, nur die Endung muss zwingend things lauten)

steht dann zum Beispiel ganz oben das gateway (in meinem Fall ein Weinzierl 730 im Tunnelmodus) und nachfolgend die knx.devices wie Aktoren, Taster usw mit ihren physikalischen Adressen?

Der Aufbau der *.things Dateien ist gegliedert, je nach Binding gibt es Things und Channel oder Bridges, Things und Channel. Im Fall von knx gibt es die Bridge, unterhalb der Bridge (das ist das Gateway auf den Bus) dann mindestens ein Thing (das würde dann den gesamten Bus repräsentieren) oder auch mehrere Things (typischerweise eines pro knx Device), unterhalb des/der Things dann Channel pro Kanal, wobei dann je nach Kanal mindestens eine, meist aber mehrere GA angegeben werden, genau wie bei der Item-Definition in knx1. Der Channel wird dann, wie bei allen anderen OH2-Bindings mit einem oder mehreren Items verlinkt.

[Wurschtel]

Ich bin zu doof - bekomme nix auf die Reihe!

- was ich in der PaperUI mache taucht nicht in den config-Dateien auf, irgendwo muß es aber stehen
- will ich was "removen", knallt der mir ständig einen Error 409 conflict rein

alles nur Horror.

Vielleicht kurz zum Umfeld:
- Rechner mit ubuntu 18.04-server
- openhab 2.4 per apt-get installiert, also nicht manuell
- die config-Dateien befinden sich in einem samba-share

Wäre ja schon froh, wenn ich zumindest mal ein Telegramm auf dem Bus auslösen könnte.

[udo1toni]

Ich bin zu doof - bekomme nix auf die Reihe!

Nein, Du hast nur etwas mißverstanden.

- was ich in der PaperUI mache taucht nicht in den config-Dateien auf, irgendwo muß es aber stehen

Doch, nur nicht in denen, an die Du denkst Paper UI schreibt seine Konfiguration in ein json-Datei (oder war es doch xml? egal...), die kann man auch bearbeiten, aber das sollte man tunlichst lassen. Diese Datei ist nicht dazu gedacht, von Hand bearbeitet zu werden, entsprechend muss man schon genau wissen, was man da tut, um kein Unheil anzurichten...

- will ich was "removen", knallt der mir ständig einen Error 409 conflict rein

Vermutlich versuchst Du, Dinge zu löschen, die Du in einer Items-Datei definiert hast Siehe oben. Paper UI hat keine Kenntnis von diesen Dateien.

alles nur Horror.

Wird schon noch...

Vielleicht kurz zum Umfeld:
- Rechner mit ubuntu 18.04-server
- openhab 2.4 per apt-get installiert, also nicht manuell
- die config-Dateien befinden sich in einem samba-share

Wäre ja schon froh, wenn ich zumindest mal ein Telegramm auf dem Bus auslösen könnte.

Grundsätzlich kannst Du OH2.x immer noch ausschließlich über die Textdateien konfigurieren. Im Fall von openHAB2-Bindings gibt es aber keine Bindingkonfiguration, sondern diese Daten werden innerhalb der Bridge oder des Thing definiert. Die openHAB1-Bindings werden nun über getrennte Konfigurationsdateien eingestellt, die im Verzeichnis ./services/ liegen. Leider gibt es einzelne Bindings, die dann doch über die openhab.cfg konfiguriert werden müssen, na ja, Kuddelmuddel halt.

Die Konfiguration über Paper UI ist aber eigentlich recht angenehm, wenn man sich mal eingewöhnt hat. Also vor allem erstmal tief Luft holen, ausatmen und bis zehn zählen.
Zur Konfiguration mit Textdateien empfehle ich Dir VSCode, den offiziellen Ersatz für den Eclipse SmartHome (aka openHAB) Designer, der nicht mehr weiter entwickelt wird. Damit der Komfort nicht zu kurz kommt, gibt es ein openHAB2.x Plugin für diesen openSource Editor von Microsoft (läuft auf allen wichtigen Betriebssystemen, Windows, MacOS, GNU/Linux)
In VSCode wird ähnlich wie im Designer das komplette Konfigurationsverzeichnis ausgewählt, so dass die Struktur direkt sichtbar wird. Wenn Du das Plugin korrekt eingerichtet hast (es muss mindestens die IP des openHAB-Servers eingetragen werden), bietet der Editor Autocompletion, Fehlererkennung und alle erdenklichen Annehmlichkeiten.

In OH2 kommt gegenüber OH1 das Thing Modell hinzu. Things sind die Abstraktion der Hardware. Unter OH1 waren die Definitionen der Items teilweise extrem unterschiedlich, bis hin zu Inkompatibilitäten. Für OH2 Bindings werden nun Things (und evtl. vorher Bridges), die Channel haben. Jedes Thing entspricht einem Gerät (z.B. ein zwave Zwischenstecker), die Channel dann den zugehörigen Eigenschaften (Schaltkanal, vielleicht Spannung und Stromaufnahme...)
In den Items werden nun nur noch Zuordnungen zwischen Items und Channeln definiert.

Der neueste Gimmick ist das Koppeln von Items über Profile (ein Item wird verändert, weil sich ein anderes Item geändert hat).

All diese Konfigurationen kannst Du über Paper UI erledigen oder auch über Textdateien. Was dabei an OH2-Dingen entsteht, kann anschließend in Paper UI betrachtet, aber nicht bearbeitet werden. Trotzdem ist diese "nur-Lesen"-Ansicht sehr gut, um die Zusammenhänge zwischen den einzelnen Parametern zu verstehen, und nicht zuletzt, um genau herauszufinden, wie denn nun der Channel wirklich heißt.


Ach so, fast vergessen...
Falls Du gar nicht mit knx2 zurecht kommst, schick mal ein bisschen Deiner knx1 Konfiguration (den knx-Teil der openhab.cfg und ein paar Items, am besten von jeder verwendeten Sorte ein bis zwei, dann können wir ganz schnell eine funktionierende knx.things Datei erstellen.

[Wurschtel]

Uiiiiiiiiiiii, da hast du dir mordsmäßig viel Mühe gemacht - gaaanz lieben Dank dafür!!!

Dein

Doch, nur nicht in denen, an die Du denkst Paper UI schreibt seine Konfiguration in ein json-Datei (oder war es doch xml? egal...), die kann man auch bearbeiten, aber das sollte man tunlichst lassen. Diese Datei ist nicht dazu gedacht, von Hand bearbeitet zu werden, entsprechend muss man schon genau wissen, was man da tut, um kein Unheil anzurichten...

Zur Bearbeitung der Textdateien in den samba-shares benutzte ich schon den VSCode mit der openHAB-Extension vom PC aus. Das läuft bis auf die Fehlermeldungen im unteren Ausgabefenster soweit auch wohl:

 [Error - 1:23:55 PM] Server initialization failed.
  Message: Internal error.
  Code: -32603
  java.util.concurrent.CompletionException: java.lang.IllegalArgumentException: URI has an authority component
      at java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:292)
      at java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:308)
      at java.util.concurrent.CompletableFuture.uniApply(CompletableFuture.java:593)
      at java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:577)
 usw usw ...

Die sind mir noch unklar.

OH1 möchte ich ganz beiseite gelegt wissen und mich nur noch auf OH2 konzentrieren. (OH1 läuft auf einem kleinen Einplatiner parallel bzw. dann, wenn ich nicht mit OH2 arbeite).

Das ganze Kuddelmuddel mit Dateien, Bridges, Things usw. macht es nicht einfach. Zumindest habe ich große Schwierigkeiten, dies alles der Dokumentation zu entnehmen, gleichwohl die eigentliche Programmierarbeit der Jungs ja atemberaubend ist.
Meines Erachtens wäre es hier sehr sinnvoll mal aufzuzeigen, was man bis zu welchem Status in config-Dateien machen soll und ab wann man dann sinnvollerweiser zu PaperUI wechselt.

Eine weitere Frage ergibt sich in Sachen Sicherung. Händisch bearbeitete Dateien habe ich vor Augen und kann sie irgendwo hinpacken, aber im Nirwana umherschwirrende json-Dateien?

OH2 scheint sich auch nicht um Änderungen in der Datei "runtime.cfg" zu scheren. Dort habe ich im Bereich "LOKALE" mal auf de/DE umgestellt. Juckt OH2 aber nicht, genausowenig wie die entsprechende Änderung in der PaperUI.

Händisch habe ich jetzt mal die knx.things

 Bridge knx:ip:bridge [
  ipAddress="10.1.2.106",
  portNumber=3671,
  localIp="10.1.2.110",
  type="TUNNEL",
  readingPause=50,
  responseTimeout=10,
  readRetriesLimit=3,
  autoReconnectPeriod=1,
  localSourceAddr="0.0.0"
  ] {
  Thing device generic [
  address="1.1.3",
  fetch=true,
  pingInterval=300,
  readInterval=3600
  ] {
  Type switch : demoSwitch "Decke 1" [ ga="1/3/10+<1/3/29" ]
  }
  }

angelegt. Das darin befindliche knx-Ding-device "1.1.3", ist ein ganz normaler Schaltaktor und genau der KannIchNichtLöschenKandidat von oben.

Ein kleines Stückchen bin ich allerdings schon weiter: Ich sehe Lebenszeichen auf'm Bus, wenn ich in der PaperUI unter "Control" nen Knopp drücke (hat der selbst gemacht -> item linking steht auf "simple Mode").

Gruß
Thomas

[fanta2k]

mach einmal die address="1.1.3" beim thing weg, sobald ich da bei mir ne adress definiere, erhalte ich für das device keine updates mehr vom knx->openhab

[manfi55]

Bei VS Code geht bei mir die Fehlererkennung nicht mehr
Autocompletion und Things werden angezeigt und funktionieren

Meine einstellungen

"openhab.host": "192.168.1.xxx",

"files.autoSave": "afterDelay",
"openhab.username": "xxxx",
"openhab.password": "xxxx",
"team.showWelcomeMessage": false,
"terminal.integrated.shell.windows": "C:\\Program Files\\Git\\bin\\bash.exe",

"guides.enabled":true,

"openhab.port": 8080,
"openhab.lspPort": 5007,
"openhab.lspEnabled": true,
"openhab.useRestApi": true,
"workbench.iconTheme": "openhab",
"openhab.karafCommand": "ssh openhab@192.168.1.xxx -p 8101 -t 'log:tail'",
"git.ignoreLegacyWarning": true,
"editor.renderIndentGuides": true,


Sind meine einstellungen richtig oder wo könnte das Problem noch liegen
Gruss manfi