[Handbuch] Zusammenspiel openHAB2 mit KNX Binding 1.9, Things und UI

[mepi0011]

Hallo versuche gerade mein Umzug von openHAB 1.8 auf openHAB 2.0 durchzuführen.

Allerdings bin ich noch nicht komplett durchgestiegen.

1. Den genauen Nutzen der Things habe ich noch nicht verstanden, vermutlich weil ich noch nicht soweit vorgedrungen bin. Werden die Things zwingen für die UI / Sitemap benötigt?

2. Für das KNX Binding muss ja leider noch von openHAB 1.9 verwendet werden. So wie ich das sehe funktionieren dadurch die Things für KNX noch nicht und es kann die Paper UI noch nicht verwendet werden. Interpretiere ich das richtig?

Gruß
mepi0011

[udo1toni]

Zu 1.: Nein
Zu 2.: Ja

Längere Antwort :

Things sollen in openHAB die Entsprechung eines kompletten 'physischen' Geräts sein. Wenn man z.B. eine knx-Bridge hat, hängen dahinter meist mehrere Aktoren, und oft sind in einem Aktor mehrere Kanäle verbaut. Damit kann man auch schon sehr gut eines der Probleme erkennen, die sich mit knx auftun. Soll man nun das REG-Modul als Thing nutzen, oder den einzelnen Kanal? Eigentlich eher ersteres, die Begrifflichkeit Channel steht allerdings wieder für diskrete Werte, also beim Dimmer ein Channel für ON/OFF, ein weiterer für die Helligkeit.
Da openHAB1 recht gut für die Abbildung von knx gerüstet ist, sehe ich für dieses Binding zur Zeit keinen zusätzlichen Nutzen für die Verwendung von Things.

Paper UI bietet ja tatsächlich eine Bedienoberfläche, die allerdings nicht für den täglichen Gebrauch gedacht ist.

1. kann man die Administration nicht ausblenden oder deaktivieren.
2. kann man weder Anordnung noch Aussehen der Steuerelemente gut beeinflussen.
3. kann man nur bestimmte Channel überhaupt korrekt beeinflussen (also z.B. schalten).

Das Ganze ist ausschließlich zum schnellen Testen gedacht, insofern schmerzt es auch nur wenig, dass knx dort nicht auftaucht.

An anderer Stelle ist das Thing-Modell aber sehr schön, weil es z.B. beim Astro Binding alle gewünschten Channels als Block zur Verfügung stellt, die Adressen sind hierarchisch aufgebaut, wenn also mehrere Channel als Items Verwendung finden (um sie in der UI sichtbar zu machen), sind Tippfehler besser zu erkennen, die Lesbarkeit ist verbessert, die Konfiguration ist (an dieser Stelle) einheitlicher.

Womit wir wieder beim Negativen angelangt wären... Leider gibt es dafür auf Seiten der Things Kuddelmuddel, falls man (und dafür gibt es gute Gründe) sie mittels Konfigurationsdatei anlegen möchte:
Einmal heißt der Parameter ipAddress (man kann aber genauso einen fqdn eintragen, falls man im LAN Namensauflösung verfügbar hat), bei einem anderen Binding heißt der Parameter mit identischer Funktion hostname, beim dritten Binding muss man HOST schreiben, das vierte Binding will url als Parameter (wobei das ja tatsächlich noch was anderes ist...).
Die Schreibweise ist selbstverständlich exakt einzuhalten, und nein, es gibt im Designer keinen Tipp, wie der Parameter korrekt heißt. Immerhin kann man bei den meisten Bindings in Paper UI nachschauen, wie der Parameter korrekt geschrieben wird, ich habe aber auch schon die karaf Konsole bemühen müssen. Ob das noch korrigiert werden kann? Vielleicht mit openHAB3...

[mepi0011]

Vielen Dank für die Ausführung!

Im Umkehrschluss bedeutet dies, dass zusammen mit dem aktuellen KNX Binding nur die Classic UI übrig bleibt oder kann die Basic UI auch verwendet werden?

Welche UI ist zu empfehlen? Da ich auf openHAB2 umstelle und Zeit investiere, nehme ich mir gerne auch etwas mehr Zeit um die Konfiguration sauber aufzusetzen damit ich für die Zukunft (evtl. Updates) besser gerüstet bin.

[udo1toni]

Bei den UIs ist es eigentlich ganz einfach:
Classic UI und Basic UI verwenden die Sitemap zur Darstellung.
HabPanel verwendet eine eigene Konfiguration, genau wie CometVisu.
Paper UI erzeugt selbst eine Ansicht aller Things, wobei nur verlinkte Channels angezeigt werden, falls ein Thing keine Verlinkung hat, wird auch das Thing nicht gerendert.

Und dann wären da ja noch ein paar UIs für die Mobilgeräte, die eigentlich auch auf die Sitemap setzen (zumindest gilt das für die Standard Apps für iOS und Android).

Falls man die Classic UI einsetzen möchte, muss man eventuell zusätzliche Rules einsetzen, denn es gibt in der Classic UI nach wie vor keine Slider, stattdessen werden dort DOWN/STOP/UP Buttons gerendert (in OH1.8.1 gab es mal kurz echte Slider, da gab es aber Probleme, weshalb das zurückgenommen wurde).
Dafür gab es in der Basic UI das Problem, dass Label nicht vollständig gerendert wurden (also z.B. beim Slider nicht dabei stand, wieviel % eingestellt sind, obwohl im Label [%d %%] mit angegeben war)
Ansonsten gilt eigentlich für alle UIs, dass man alles, was dargestellt werden soll, als Item anlegen muss - im Fall von Things und Channels kann das auch über Paper UI geschehen, man kann das aber genauso gut über *.items-Dateien erledigen.

[thoern]

Das hört sich alles etwas frustrierend an. Bin immer noch bei 1.8. Ich erkenne irgendwie keinen Nutzen um auf OH2 zu migrieren. Funktioniert denn wenigstens habdroid noch mit OH2?

[udo1toni]

Funktioniert denn wenigstens habdroid noch mit OH2?

Soweit ich das bisher getestet habe, ja.

Mein Produktivsystem ist auch noch 1.8, ich will schon seit gefühlten Jahren umsteigen, allein, es tauchen immer wieder kleinere oder auch größere Schwierigkeiten auf...

kommt halt immer darauf an, was man für Hardware (und damit Bindings) einsetzt. Bei knx gibt es wohl nach wie vor ein Problem mit Antworten auf Telegramme, die openHAB eigentlich niemals senden dürfte, es aber wohl trotzdem tut (in meinem Testsystem habe ich knx noch gar nicht in Betrieb...), dann tauchen immer mal wieder Dinge auf, bei denen man raten muss, wie sie über Textdateien konfiguriert werden, weil es keine Möglichkeit gibt, das über die Oberfläche zuverlässig zu sehen. Und es fehlen immer noch einige Bindings, obwohl sie als OH2-kompatibel gemeldet sind (da ich kein Entwickler bin, kann ich auch nicht mal eben die nötigen Schritte gehen, um sie offiziell in OH2 verfügbar zu machen). Natürlich kann ich mit dem händischen Installieren solcher Bindings arbeiten, aber der Updateprozess wird dadurch nicht schöner, ich denke, der bessere Weg wäre gewesen, die Bindings allesamt nach OH2 zu migrieren (also als OH1-Bindings) und bei gehäuften Problemen das Binding entsprechend zu kennzeichnen - dann wäre auch die Weiterentwicklung für OH2 schon einen Schritt weiter.

Aber openHAB2 hat unbestreitbar einige nette Funktionen. mit OH2.1 (oder aktuell schon den Nightly Builds) bekommt man z.B. zusätzliche Trigger, die unter OH1 so nicht zur Verfügung standen, auch kann man inzwischen in Rules prüfen, ob ein Gerät (genauer ein Thing) online ist, das macht vieles einfacher.
Basic UI ist unbestritten wesentlich schicker und bringt mehr Informationen auf gleichem Raum unter, mit OH2.1 ist auch das Problem der unvollständigen Label beseitigt.

Auch der Zugriff auf die Karaf Konsole ist besser gesichert, da passwortgeschützt, die Konsole ist extrem mächtig, vor allem im Vergleich zu OH1.

Alles in Allem ist also der Umstieg auf OH2 sicher sinnvoll, soweit der Umstieg möglich ist.
Leider muss man wieder gewaltig dazulernen, und die Doku ist nach wie vor nur englisch verfügbar (und leider ist es auch erklärter Wille, dass sich daran nichts ändern wird - obwohl eine Übersetzung der Handbuchs, wenn sie vom System direkt unterstützt würde, sicher von einer recht großen Masse Anwendern vorangetrieben werden könnte - im Gegensatz zum Erstellen einer englischen Anleitung, das macht besser jemand mit besseren Skills

[mepi0011]

...
Bei knx gibt es wohl nach wie vor ein Problem mit Antworten auf Telegramme, die openHAB eigentlich niemals senden dürfte, es aber wohl trotzdem tut

Kannst du das Bitte genauer spezifizieren? Ich verwende seit Jahren openHAB als Schnittstelle zu KNX und höre das zum ersten mal.

...
Alles in Allem ist also der Umstieg auf OH2 sicher sinnvoll, soweit der Umstieg möglich ist.

Du machst mir aber Mut!
Ich versuche gerade den Umstieg!

...
Leider muss man wieder gewaltig dazulernen, und die Doku ist nach wie vor nur englisch verfügbar (und leider ist es auch erklärter Wille, dass sich daran nichts ändern wird - obwohl eine Übersetzung der Handbuchs, wenn sie vom System direkt unterstützt würde, sicher von einer recht großen Masse Anwendern vorangetrieben werden könnte - im Gegensatz zum Erstellen einer englischen Anleitung, das macht besser jemand mit besseren Skills

Das kann ich nur bestätigen! Bei der Migration auf openHAB2 komme mir vor wie ein Anfänger!

Meine Erfahrungen mit openHAB2 ergänze ich gerade in der inoffiziellen deutsch Anleitung (https://openhabdoc.readthedocs.io/de/latest/), die ich vor langer Zeit für openHAB 1.x gestartet habe. Sobald bei mir wieder alles läuft wird es hier ein Update geben. Freiwillige ich mich bei der Dokumentation unterstützen möchten sind herzlich eingeladen!

[udo1toni]

Kannst du das Bitte genauer spezifizieren? Ich verwende seit Jahren openHAB als Schnittstelle zu KNX und höre das zum ersten mal.

Das kam mit OH1.9 als Fehlverhalten. Um das Problem zu beseitigen, wurde ein Parameter ignorelocalevents eingeführt, der aber nicht zur Besserung führte. Ich selbst habe das noch nicht (bewusst) gesehen, aber wie schon erwähnt habe ich knx bisher nicht auf OH2 laufen. In einem kurzen Test hatte ich ebenfalls eine extrem erhöhte Buslast, was ich damals auf die doppelte Anbindung Produktivsystem + Testsystem zurückführte, aber ob dies die Ursache war?
der Fehler tritt wohl nur beim Zugriff im TUNNEL Mode auf, und wie schon erwähnt ist wohl nicht jeder betroffen.

[ulistermclane]

Hallo zusammen,

ich habe einen Raspi3 (Debian Jessie) mit OH2 und KNX 1.9 Binding in Zusammenhang mit einem Weinzierl 731 IP Interface (TUNNEL) bei dem das beschriebene Problem auftritt. Buskommandos von openhab werden dabei mehrfach wiederholt. Daneben habe ich noch einen Fujitsu Futro S900 am Laufen (auch mit Debian Jessie und OH2), dort tritt das Problem nicht auf - der Futro ist gefühlt eher langsamer als der Raspi, klingt also nach einem subtilen Timing Problem. Die Konfiguration ist in beiden Fällen gleich (ignorelocalevents=TRUE). Ich würde sehr gern auf den Raspi zurück gehen (der steckt in einem Hutschienengehäuse im Schaltschrank); das ist aber mit dem aktuellen Verhalten nicht möglich. Sollte ich stattdessen auf OH1 zurückgehen?

Gruß

Uli

[mepi0011]

Hallo zusammen,

ich habe einen Raspi3 (Debian Jessie) mit OH2 und KNX 1.9 Binding in Zusammenhang mit einem Weinzierl 731 IP Interface (TUNNEL) bei dem das beschriebene Problem auftritt. Buskommandos von openhab werden dabei mehrfach wiederholt. Daneben habe ich noch einen Fujitsu Futro S900 am Laufen (auch mit Debian Jessie und OH2), dort tritt das Problem nicht auf - der Futro ist gefühlt eher langsamer als der Raspi, klingt also nach einem subtilen Timing Problem. Die Konfiguration ist in beiden Fällen gleich (ignorelocalevents=TRUE). Ich würde sehr gern auf den Raspi zurück gehen (der steckt in einem Hutschienengehäuse im Schaltschrank); das ist aber mit dem aktuellen Verhalten nicht möglich. Sollte ich stattdessen auf OH1 zurückgehen?

Gruß

Uli

Hallo Uli,

kurze Zeit nach der Inbetriebnahme vom openHAB 2.1 ist der Fehler bei mir zum ersten Mal aufgetreten. Das Thema wurde in folgendem Thread diskutiert.


Update: Du hast ja ignorelocalevents bereits auf TRUE gesetzt! Es wird Zeit, dass das KNX Binding auf openHAB 2 portiert wird.

[ulistermclane]

... wenn ich nicht schon so viel Zeit in openhab investiert hätte würde ich es rauswerfen. iBbroker schaut auch sehr interessant aus - gibt es da Erfahrungen?