openHAB 2.0: Wohin geht die Reise?

[Jockel]

Hallo zusammen,

das erste Alpharelease von openHAB 2.0 habe ich in den letzten Tagen zum Anlass genommen mich mit den geplanten Änderungen zu beschäftigen. Dabei habe ich ein paar Sachen gelesen die mir durchaus Sorgen machen.

Andererseits hab ich auch nur kurze Informationen gefunden, die ich wahrscheinlich auch noch falsch interpretiert und verstanden habe. Vielleicht kann hier ja etwas Klarheit geschaffen werden? Insbesondere geht es mir um die beiden folgenden Punkt:

1. Wegfall von Xbase als Rule-Engine und Einführung einer json basierten Regeldefinition mit einer irgendwie gearteten SW die diese Regeln erstellt, z.B. einem grafischen Editor.

Es muss sicher nicht Xbase sein, aber eine textbasierte, von Menschen zu schreibende Sprache schon. Grafische Programmierung ist mir ein graus seitdem ich vor 15 Jahren mit Labview zu tun hatte und hat in meinen Aufen viele Nachteile sobald es etwas komplexer wird.

2. Wegfall des webapps Ordners und damit z.B. der Greent Oberfläche. Greent hat ja durchaus Nutzer, wie hier auch heute wieder zu lesen war. Persönlich fände ich es aber noch schlimmer, wenn damit dann auch die Unterstützung für die cometVisu entfallen würde.

Die Enschränkungen beim REST API kann ich im Moment nicht einschätzen, scheinen mir aber nicht so dramatisch zu sein.

Die Frage ist also eigentlich, ob ich openHAB in ein paar Jahren noch erkenne und es noch die Eigenschaften hat die Grund für den Wechsel gerade zu openHAB waren.

Vielleicht kann mir hier ja jemand die Sorgen nehmen?!

Vielen Dank schon mal,
Jockel

[Reddick]

Also zunächst ist openHAB 2.0 gerade mal in einem Alpha-Stadium. Da ist nix in Stein gemeißelt. Zudem wird hier ja schon korrekt gesagt:

the rule syntax has slightly changed, you e.g. do not need import statements anymore for the most common classes. At the same time, there is no openHAB Designer anymore, but the Eclipse SmartHome designer can be used.

Da wird nichts davon erwähnt dass man die Möglichkeit Regeln in einer Programmiersprache zu verfassen entfernen will. Vielmehr wird es zu kleinen Änderungen in der Syntax kommen ... das heißt eigentlich dass es diese Möglichkeit auch weiter geben wird. Der aktuell github-Stand enthält daher auch Beispielregeln bei denen man sich das ansehen kann. Hast mich ganz schön erschreckt mit diese Sorge denn auch ich empfinde dies als einen der größten Vorteile von openHAB.

Was Deine zweite Sorge angeht so zitiere ich nochmal die Ausführungen von Kai auf github:

The following restrictions are known (and need to be worked on):
[...]
* GreenT does not work as the webapps folder does not exist anymore
* CometVisu is not yet compatible
* HABmin is not yet compatible
[...]

Dabei sind die Worte "not yet" und "need to to be worked on" wichtig ;-). Man ist sich der aktuellen Limitierungen bewußt und möchte auch dafür gern eine Lösung anbieten aber natürlich hat die Fertigstellung des Kerns erstmal Priorität.

Gut Ding will halt Weile habe. Insbesondere wenn die Leute dies in ihrer Freizeit machen.

[kkreuzer]

Hallo Jockel,

na, dann lass mich mal versuchen, Deine Bedenken zu zerstreuen:

1. Xbase-Regeln wird es weiterhin geben und ich versuche, dies weitestgehend abwärtskompatibel zu openHAB 1.x zu halten. Die interne Architektur wird sich jedoch ändern - und die JSON-Formate sind nur fürs interne Handling, es ist NICHT ein neues Format um Regeln zu schreiben (das wäre mir auch ein Graus). Was die neue Architektur aber zusätzlich erlauben wird:

• Neben Xbase können optional weitere (Script-)Sprachen, z.B. JavaScript unterstützt werden.
• Statt Regeln können auch Templates erstellt werden - die Hoffnung ist, dass wir dann statt https://github.com/openhab/openhab/wiki/Samples-Rules direkt die Templates austauschen können, die dann jeder für sich nur noch passend konfigurieren muss.

Also: Textbasierte Regeln werden bleiben und eher noch mehr erlauben, als bisher. "Textlose" Varianten für Regeln werden für Nutzer ermöglicht, die vor Scripting zurückschrecken und eher sowas wie IFTTT bevorzugen (mit allen Einschränkungen, die das für sie bringt).

2. Der webapps-Ordner in openHAB 1.x ist ein Security-Leck: Evtl. ist Dir schon aufgefallen, dass auf Dateien darin keine Authentication stattfindet, auch wenn Security=ON konfiguriert ist. Aus diesem Grunde habe ich ihn in openHAB 2 entfernt und liefere die Icons und sonstige Dinge nun (sicher) über Servlets aus. Gleiches sollte auch für die CometVisu gemacht werden. Bzgl. GreenT: Das wird vom Entwickler schon seit geraumer Zeit nicht mehr weitergepflegt, so dass ich es für openHAB 2 nicht mehr wirklich als UI sehe. Ich hoffe eher, dass das PaperUI oder das neue HABmin (https://groups.google.com/d/msg/open...Q/LpTioBl3Tz4J) eine adäquate Alternative werden.

Viele Grüße,
Kai

[Jockel]

Danke für die Infos, dass beruhigt mich schon mal sehr, jetzt kann ich wieder besser schlafen !

[NetFritz]

Hallo
Ich finde es durchaus in Ordnung wenn man in Zukunft grafisch Programmieren kann wenn die Scripts (Rules) erhalten bleiben.
Ich programmiere heute meine Codessys SPS auch nur noch grafisch in Blöcken.
Es ist viel einfacher für einen Nachfolger.
Wichtig ist nur wenn man selbst oder jemand anders einen Block grafisch oder als Script erstellt hat ihn immer wieder verwenden kann.
Dann wird die grafisch Programmierung zu einem Kinderspiel.
Gruß NetFritz

[Jockel]

Ich finde es durchaus in Ordnung wenn man in Zukunft grafisch Programmieren kann wenn die Scripts (Rules) erhalten bleiben.

Wenn es eine Möglichkeit von mehreren ist, klar, warum nicht und hat für Einsteiger durchaus Vorteile. Als einzige Möglichkeit wäre es für mich persönlich aber ein absolutes no go!

Ich habe da Erfahrung mit Labview, einer alten SPS (keine Ahnung mehr was es war) und mit der Loxone. In allen Fällen finde ich es deutlich unübersichtlicher und umständlicher sobald es eine gewisse Komplexität erreicht hat. Auch praktische Nachteile gibt es: Der Vergleich von mehreren Versionen mit einem Diff-Tool oder, damit verbunden, das Verwalten in einem RCS nur als Beispiele.

[NetFritz]

Hallo
Wenn für Dich eine Script Programmierung i.O. ist dann ist das ok.
Ich habe in meinen Berufsleben im Kraftwerk die Leittechnik in SPS programmiert.
Da wurde grundsätzlich grafisch programmiert.
Im Störungsfall könnte man sich auf tausende von Seiten gar nicht zurechtfinden.
Gruß NetFritz

[Unita02]

kkreuzer : Beim Umstieg auf OH2 mit PaperUI habe ich folgendes Problem(chen) - vielleicht kannst Du mir da weiterhelfen:
Bei der Konfiguration mit PaperUI werden die Settings ja nicht in die Text-Conf Dateien gespeichert sondern in einer Persistenz-DB...
Frage: kann man PaperUI-Settings aus der DB irgendwie in Text-Conf-Dateien konvertieren - ich suche mir hier 'n Wolf ...
... wäre schön, da ich mit git arbeite und als Text die Diffs natürlich besser (oder überhaupt) zu sehen sind ...
Ansonsten: SamsungTV und KNX läuft (naja, mini), Asterisk ist in Arbeit. Systeme: Win7, Pi3, openSuse