Erfahrung mit openHAB2

[thoern]

Hallo,

hat von euch schon mal jemand openHAB2 ausprobiert. Denkt ihr schon an einen Umstieg oder macht das noch keinen Sinn?
Ein KNX-Binding gibt es ja scheinbar noch nicht, aber soweit mir bekannt, soll auch das Binding aus der 1-er Version funktionieren.

Was meint ihr?

Gruß,
thoern

[g4s3]

mal aus dem Distro Repository zitiert:

openHAB 1 Add-ons: Add-ons developed for openHAB 1.x. Most of them are working smoothly on the openHAB 2 runtime and thus they are packaged within the distribution.

[klayer]

Ich habe einen Portierungsversuch gestartet.
Die derzeitige Version erfordert sehr viel Arbeit und nach ca. einem Tag habe ich erstmal aufgehört.
Ich habe viele Fehlermeldung bekommen, die ich nur sehr mühseelig zu "dekodieren" und zu fixen waren.
Heute würde OH2 schlicht als inkompatibel zu OH1 bezeichnen.

Außerdem fehlen mir noch einige Bindings, die ich benötige.

Was noch ziemlich unausgegohren ist, ist die Mischung aus Einstellungen, die zum Teil im WebUI gemacht werden und dann teilweise wieder Text Files.
Teilweise muss das WebUI verwendet werden, teilweise wieder die Textfiles. Das ist ein ziemliches Durcheinander und ich finde das suboptimal und die konsequente Nutzung von Textfiles, wie bei OH 1.x war besser. Auch der Backup und Update Prozess wird dadurch sehr intransparent. Hier ist noch sehr viel zu tun und es erscheint mir, dass hier noch Lücken im Konzept existieren.

Nach wie vor muss man sich auch mit Xtext und dieser suboptimalen DSL herumschlagen. Jython funktioniert (noch) nicht.
Es gibt jetzt einige Bindings, die Autodiscovery unterstützen. Nice to have meiner Meinung nach. Steigert meine Produktivität kaum, weil die Item Definitionen immer relativ einfach waren und schnell erledigt war.
Die meiste Zeit habe ich immer damit verbraten, die Befehlssequenzen für die schlecht dokumentierten Klassen und der DSL zu finden. Das wird leider nicht besser.
Es scheint die langfristige Vision hinter einigen Entwicklungen zu stehen, dass der User nicht mehr programmieren sollte, sondern sich die Apps dann kauft. Da die DT ein Sponsor ist, kann man diese Vision schon bei QiVICon sehen. Ob allen das gefällt, dürfte fraglich sein. Mir jedenfalls nicht.

Es gibt jetzt die Paper UI, die ungefähr das kann was GreenT konnte (leider wurde GreenT eingestellt).
Das ist ein (kleiner) Fortschritt, aber noch kein Grund jetzt zu wechseln.

Ich sehe für mich leider noch nicht das eine Feature, was mich wirklich neugierig auf OH 2 macht.

[hmerk]

Es scheint die langfristige Vision hinter einigen Entwicklungen zu stehen, dass der User nicht mehr programmieren sollte, sondern sich die Apps dann kauft.

Das ist nicht korrekt. openhab ist und wird auch in der Version 2.x OpenSource bleiben. Es gibt keine kommerziellen Ansätze.
Wir sind gerade dabei die openHAB UG in einen gemeinnützigen Verein zu wandeln, der diesen Ansatz auch festschreibt.

Ob Qivicon oder andere auf Eclipse SmartHome (ESH) basierende komerzielle Produkte andere Ansätze verfolgen, hat damit nichts zu tun. Das ist Sache der Firmen.
Und der Einsatz der Telekom beis ESH kommt auch openHAB zu gute.

Aus Entwicklersicht ist Version 2.0 noch nicht für den produktiven Einsatz geeignet, das wird auch immer wieder betont. Es existieren aber durchaus Instalationen, die auch schon produktiv eingesetzt werden. Das sind für uns sehr wichtige Quellen zur Fehlererkennung, -beseitigung und Weiterentwicklung.

[udo1toni]

Aus Entwicklersicht ist Version 2.0 noch nicht für den produktiven Einsatz geeignet, das wird auch immer wieder betont. Es existieren aber durchaus Instalationen, die auch schon produktiv eingesetzt werden. Das sind für uns sehr wichtige Quellen zur Fehlererkennung, -beseitigung und Weiterentwicklung.

Danke für diese Klarstellung!

[klayer]

@hmerk
Klar wird Openhab Opensource bleiben und es wird auch noch eine Programmiermöglichkeit geben.
Aber wenn man sich die Hauptweitentwicklungen ansieht, dann sieht man klar wo der Weg hingegen soll.

1. Es sollen möglichst viele Binding existieren und damit eine Unabhängigkeit von Herstellerprotokollen. Das ist ok.

2. Der Nutzer soll möglichst nur mit einer Web Ui arbeiten. Das kommt bei vielen Leuten natürlich nicht gut an und es wird zurzeit ein großer Aufwand betrieben, um textuelle und WebUi Konfiguration unter einen Hut zu bringen. Ein Aufwand, der völlig überflüssig ist, wenn man sich von dem aus meiner Sicht sinnlosen WebUI verabschieden würde.
Weil aber Unterstützer der Platform eine andere Agenda haben, wird in diese Richtung weiterentwickelt.

3. Die Situation für den NICHT- professionellen Entwickler hingegen wird überhaupt nicht verbessert. Dabei gäbe es hier eine Menge zu tun.
- Designer funktioniert nicht vernünftig
- die DSL ist eine Katastrophe und sollte umgehend durch eine Standardprogrammiersprache ersetzt werden. Warum greift man nicht den vielversprechenden Ansatz jython von OH 1.2 auf.
- die ganzen JavaClassen sind nicht dokumentiert. Wenn man sich das englische Forum anschaut, stellt man fest, dass die Nicht Java Programmierer überfordert sind.
Und das soll wohl auch so bleiben.
- Das ganze Thema Debugging ist noch total unterentwickelt.
- Die Visualisierung mit Sitemaps ist schwach. Es wäre gut, wenn man die diversen divergierenden Ansatze versucht, einzufangen und unter einen Hut zu bekommen.

War vorher eine Abhängigkeit vom Hersteller der Geräte, werden wir in Zukunft eine Abhängigkeit von der Platform und entsprechenden Apps und Services bekommen und die Community bereitet den Weg.
Programmierung soll ein Vorrecht von Professionells bleiben und nicht vereinfacht werden.

[udo1toni]

klayer Ich denke, da ist Dein Blick etwas negativ

Punkt 2 Web UI: Es geht gar nicht darum, dass möglichst nur mit der UI gearbeitet werden soll. Der Punkt ist, dass gerade Neulinge das Gefühl haben, mit einer schicken UI besser programmieren zu können (was natürlich Quatsch ist, das ändert aber nichts am Gefühl der Leute). Du kannst aber die OH1-Konfiguration (fast) 1:1 übernehmen und weiterhin komplett ohne WebUI arbeiten, und soweit ich das verstanden habe, soll sich daran auch nichts ändern.
Autokonfiguration (geht natürlich nur in den Grenzen, in denen die verschiedenen Protokolle das unterstützen) ist aus meiner Sicht eine feine Sache, die auch manche Anfängerfehler vermeiden hilft. Dafür ist halt eine interaktive Schnittstelle sinnvoll, und da bietet sich eine WebUI an.
Mit dem Things- und Channel-Modell bin ich bisher aber nicht warm geworden, was bei mir natürlich auch daran liegt, dass ich viel knx in Betrieb habe. knx verfolgt einen anderen Ansatz, der mit dem openHAB Things-Modell (bisher) nicht gut korreliert. Ob das besser wird? Ich kann es mir momentan nicht vorstellen, aber wer weiß. Momentan sind Things und Channels für mich nur zwei zusätzliche Abstraktionsebenen, die das Arbeiten unnötig erschweren - ich muss es ja doch auf Items runter brechen.

Punkt 3, Designer: Es wurde schon an anderer Stelle von Kai erläutert, dass der Entwicklungsschwerpunkt momentan ganz eindeutig auf OH2 liegt, und zwar auf der Server-Seite. Wenn OH2 aus dem Betastadium kommt, werden auch der Designer und die Dokumentation wieder mehr Aufmerksamkeit erfahren.

Punkt 3, DSL: Es stimmt, dass es keine vernünftige Dokumentation gibt (im Sinne von vollständig und an einem Platz), eine Katastrophe ist die DSL aber nicht, sie hat sich mir (im Gegensatz zu jython!!!) sofort erschlossen. Ich bin an vielen Stellen immer wieder beeindruckt, wie viel in den Rules geht, obwohl das doch alles so schrecklich beschränkt erscheint. Ich nutze einen überschaubaren Satz an Automationsregeln, und ehrlich gesagt ist es mit ziemlich egal, ob ich eine Rule zehnmal identisch da liegen habe, solange es funktioniert. Klar wäre es schöner, man hätte da mehr Möglichkeiten und elegantere Ansätze. Elegant ist für mich aber nicht, wenn ich 50 oder 100 Zeilen Overhead habe, um vier Zeilen Code nicht mehrfach einfügen zu müssen Habe ich schon erwähnt, dass mir jython suspekt ist?

Punkt 3, Java Klassen: Die sind im Allgemeinen hervorragend dokumentiert, nur halt nicht in openHAB, sondern in der einschlägigen Java Doku. Abgesehen davon ist es ja kein Java, sondern XTend Da ich weder das eine noch das andere vorher genutzt habe, musste ich ohnehin lernen, was ich brauche.

Ich finde es immer wieder lustig, wie hoch die Latte gelegt wird, wo man ein kostenloses Stück Software nutzt, und das mit einer meinen Erfahrungen nach sehr hilfsbereiten Community - sowohl in deutschen als auch im englischen Forum. Ich habe auch schon die eine oder andere HA-Software ausprobiert - auch solche, die nur mit billiger Hardware, aber für 2000 EUR verkauft wird - bis auf einige wenige Fehler, mit denen ich gut leben kann, gefällt mir openHAB mit Abstand am besten (wobei ich natürlich nur eine sehr unvollständige Sicht habe)

[thoern]

Hallo!

Ich danke euch schon mal für die bisherigen Meinungen und Sichtweisen. Bei uns wird OH schon intensivst genutzt. Nahezu meine gesamte KNX-Installation ist darin abgebildet. Selbiges gilt für Heizung samt Wärmepumpe. Und dann noch die netten Kleinigkeiten, wie Türöffnung mittels Handy, Müllabholungsinfo per Android-Notification, Spritpreise und Staumeldungen meiner "Lieblingsautobahn", Hausklimainfo mit Lüftungsinformation, Alarmanlage, Automatismen und, und, und....

Ich würde schon gerne nach OH2 migrieren, möchte aber keine Tage oder Wochen investieren, um dann festzustellen, dass doch noch vieles nicht funktionert was jetzt schon reibungslos in meiner aktuellen OH1-Installation/Konfiguration läuft. Designer und Autokonfigurationsfeatures sind mir nahezu egal. Ich schreibe alles in Textfiles manuell - auch die Rules


Dann werde ich wohl noch eine zeitlang warten, bevor ich mich mit OH2 beschäftige.

BTW: Das mit den Thingies habe ich auch noch nicht so recht verstanden. Meine Vorstellung in Bezug auf KNX wäre ungefähr so:
Ein Thing ist beispielsweise ein Aktor, ein Item - wie jetzt auch schon - ein logisches Objekt, bestehend aus einer oder mehrere GA's, das eine entsprechende Funktionalität abbildet. Kann man das so sagen?

Gruß,
thoern

[hmerk]

klayer

Da habe ich - als NICHT-professioneller Entwickler eine ganz andere Sicht.
Vielleicht erst einmal etwas zu meinem Hintergrund:
Bis 2013 hatte ich keinerlei Programmierkenntnisse und bin über openHAB zu Java gekommen. Inzwischen zählen zu openHAB 1.x drei Bindings von mir, wobei ich das WeMo Binding auch als Eclipse SmartHome (ESH) Binding und damit für openHAB 2.x entwickelt habe und weiterentwickle.

2. Der Nutzer soll möglichst nur mit einer Web Ui arbeiten. Das kommt bei vielen Leuten natürlich nicht gut an und es wird zurzeit ein großer Aufwand betrieben, um textuelle und WebUi Konfiguration unter einen Hut zu bringen.

Dass die WebUI zur Konfiguration nicht gut ankomme, kann ich nicht bestätigen, im Gegenteil, habmin - als eine Möglichkeit dazu - erfreut sich sehr großer Beliebtheit, insbesondere auch der Ansatz, Rules graphisch zu erstellen.

3. Die Situation für den NICHT- professionellen Entwickler hingegen wird überhaupt nicht verbessert. Dabei gäbe es hier eine Menge zu tun.

Wie oben bereits beschrieben, bin ich ein NICHT-professioneller Entwickler und kann mich über den Support nicht beklagen, ganz im Gegenteil. Von daher sehe ich nicht, was an der Situation schlecht sein sollte.

- die DSL ist eine Katastrophe und sollte umgehend durch eine Standardprogrammiersprache ersetzt werden. Warum greift man nicht den vielversprechenden Ansatz jython von OH 1.2 auf.

Änderungen hierzu sind beabsichtigt, allerdings kann noch keiner etwas zum Zeithorizont sagen.

- die ganzen JavaClassen sind nicht dokumentiert. Wenn man sich das englische Forum anschaut, stellt man fest, dass die Nicht Java Programmierer überfordert sind.
Und das soll wohl auch so bleiben.

Kann ich nicht nachvollziehen, aus meiner Wahrnehmung sind die Klassen gut dokumentiert. Ich verstehe nicht ganz, worauf Du Dich bei Deiner angenommenen Überforderung der Nicht Java Programmierer beziehst.

- Die Visualisierung mit Sitemaps ist schwach. Es wäre gut, wenn man die diversen divergierenden Ansatze versucht, einzufangen und unter einen Hut zu bekommen.

Das liegt aber schwerpunktmäßig an den Entwicklern selbst. Vorstöße, die Urheber der inzwischen diversen Android-Apps zur Zusammenarbeit zu bewegen, sind bisher gescheitert. Gerade die neueste App - Rotini - sieht dabei sehr vielversprechend aus. Noch ist nicht klar, ob der Entwickler diese später kostenpflichtig anbieten wird, aber das ist schließlich seine Entscheidung. Aber es gibt auch weitere Möglichkeiten, eine für die eigenen Zwecke geeignete Visualisierung zu erstellen - Dashing, CometVisu.

Programmierung soll ein Vorrecht von Professionells bleiben und nicht vereinfacht werden.

Ganz und Gar nicht, es wird immer mehr Arbeit in die Dokumentation gesteckt, um den Entwicklern Hilfestellungen zu geben.

Gruß
Hans-Jörg

[udo1toni]

Das mit den Thingies habe ich auch noch nicht so recht verstanden. Meine Vorstellung in Bezug auf KNX wäre ungefähr so:
Ein Thing ist beispielsweise ein Aktor, ein Item - wie jetzt auch schon - ein logisches Objekt, bestehend aus einer oder mehrere GA's, das eine entsprechende Funktionalität abbildet. Kann man das so sagen?

So stelle ich mir das auch vor, aber bei der Menge Aktoren (und Sensoren) alleine in der knx-Welt... Es gibt zwar eine Grundmenge, die im Prinzip von jedem gleichartigen Aktor abgedeckt wird, aber im Detail unterscheiden sich die Aktoren teilweise erheblich voneinander, und da reicht sogar schon eine andere Firmware bei ansonsten identischen Geräten. Das wird ja noch nichtmal von der ETS vollständig abgebildet (allenfalls mit Plugins der Hersteller), wie soll das in openHAB funktionieren? Die einzig sinnvolle Variante wäre also, die Things in openHAB händisch anzulegen, aber wozu das denn, wenn ich anschließend einzelne Eigenschaften der Things über Items nutze?
Einzig könnten die Anwender diese Things erstellen und mit Herstellerinformation in eine Datenbank eintragen, ähnlich wie schon für Z-Wave, dann könnte jeder sich dort bedienen. Allerdings sind die meisten knx Geräte in weiten Teilen unterschiedlich konfigurierbar, also nicht nur die GA, sondern auch die konkret nutzbaren Funktionen betreffend. Man müsste also quasi die ETS Produktdatenbanken einlesen (die sind aber leider verschlüsselt...) und natürlich die hinterlegte Konfiguration aus der ETS auslesen (auch die ist verschlüsselt). Weiterhin ist eine GA in knx sehr oft mehreren Geräten zugeordnet, manchmal sogar verschiedenen Funktionen. Alles nicht so einfach

An anderer Stelle ist das Modell natürlich höchst sinnvoll, beispielsweise Mediensteuerung, egal ob kodi, vdr, squeezebox usw, dort gibt es für jedes eingesetzte Gerät eine ziemlich genaue Definition, was das Gerät kann, da werden dann alle möglichen Kommunikationsobjekte in einem Block zusammengefasst, in den meisten Fällen gibt es pro Binding sogar genau ein Gerät oder zumindest eine Geräteklasse mit (nahezu) identischem Befehlssatz.

[teichsta]

Hi,

BTW: Das mit den Thingies habe ich auch noch nicht so recht verstanden. Meine Vorstellung in Bezug auf KNX wäre ungefähr so:
Ein Thing ist beispielsweise ein Aktor, ein Item - wie jetzt auch schon - ein logisches Objekt, bestehend aus einer oder mehrere GA's, das eine entsprechende Funktionalität abbildet.

hierzu gibt es übrigens schon eine ausführliche Diskussion in https://github.com/openhab/openhab2-addons/pull/21.

Gruß,

Thomas E.-E.