openhabforum.de

Hallo liebes Forum!
Ich habe viel recherchiert und bin auf nix brauchbares gestoßen. Das kann doch eigentlich auch nicht so schwierig sein. Die RF Bridge ist als Thing angemeldet wird auch korrekt über MQTT.fx erkannt.
Habe Ansätze mittels Transformation über Jsonpath verfolgt. Aber das führte zu nichts. Konnte auch leider keine Logbucheinträge (im Logviewer auf der :9001) damit erzeugen. Wäre ja elegant gewesen.
Channels für die einzelnen RFKeys kann man für die RF Bridge auch nicht erzeugen. Diese dann zu verlinken oder per Rule mit einem Switch zu verbinden wäre ja ein einfacher Ansatz.

Ein Konkretes Beispiel wäre die Einrichtung einer Lampen-Schaltung über einen Sonoff RF433 Funktaster. Ein Druck, Lampe an, noch ein Druck, Lampe wieder aus. Am besten natürlich über einen RFKey. Das war in OH2-Rules schön einfach.

Und warum eigentlich OH3??? Was macht es wirklich besser? Läuft es schneller, stabiler zuverlässiger? Ist es übersichtlicher zu programmieren?

Ich brauche dringend Input!!!!

Vielen Dank schon mal im Voraus

Gruß
Frank

Fragen hierzu:

1. Ist die RF Bridge mit Tasmopta geflasht?
2. hattest Du eine funktionierende RF Bridge unter openHAB2?

Ich nutze selbst keine RF Bridge, aber grundsätzlich funktioniert das genau wie unter openHAB2 (wenn man dort schon mqtt2 genutzt hat).

Warum openHAB3? Also, im Vergleich zu openHAB2? Ich könnte als Gegenfrage stellen: Warum nicht bei openHAB1 bleiben? Und da käme vermutlich recht schnell eine Antwort, nämlich, dass es nicht mehr herunterzuladen ist. Und das gleiche Schicksal wird auch openHAB2 (.5.12) ereilen, und wenn es noch Jahre dauern sollte.
Die Option für openHAB2 besteht ohnehin ausschließlich aus einem Grund, nämlich, dass es ein paar Bindings gibt, welche nur unter openHAB1 verfügbar waren. Die laufen auch unter openHAB2 (mit dem compatibility Layer) und openHAB3 kann mit dem Remote openHAB Binding die openHAB2-Instanz steuern. Um sie nativ unter openHAB3 laufen zu lassen müssen sie aber neu entwickelt werden, wenn auch Teile des vorhandenen Codes wiederverwendet werden können. Das Problem dabei ist, wer steckt da Arbeit rein, wenn am Ende des Tages weltweit vielleicht zehn Leute das nutzen? Eine entsprechende Umfrage im englischen Forum hat das recht genau erfasst, und auch wenn man mit Recht davon ausgehen kann, dass es nicht eben Wenige gibt, die nichts davon mitbekommen haben, weil sie vielleicht nie im englischen Forum unterwegs sind, so ist aber die Statistik dadurch nicht unbedingt falsch.
Also: irgendwann wird openHAB2 einfach nicht mehr gepflegt werden (im Grunde ist das schon seit über zwei Jahren so), und es wird dann auch keine Bugfixes mehr geben (die log4j2-Lücke wurde z.B. auch noch für openHAB2.5.12 gefixt, wobei der Fix halt auch "einfach" war).
Also, wenn Du ein System haben willst, welches aktiv gepflegt wird, musst Du zyklisch updaten, und es empfiehlt sich, vor einem neuen Major Release immer auf die letzte verfügbare Version upzudaten, um beim Übergang, auch wenn man ihn vielleicht erst nach einem Jahr vollzieht, einigermaßen gewappnet zu sein.

Ansonsten ist natürlich zu bemerken, dass es diverse neue Funktionen nur in der aktuellen Version gibt, auch eine ganze Menge Bindings ist ausschließlich für die jeweils aktuelle Version verfügbar.
Im Hintergrund kommt dann noch die Java Engine ins Spiel. openHAB1 lief auf Java 6 (?), openHAB2 verlangte Java 8, openHAB3 benötigt Java 11, openHAB4 wird Java 17 voraussetzen.
Diese Versionen sind allesamt Longterm Versionen, sie werden über einen langen Zeitraum gepflegt, aber irgendwann sind auch sie End of Life, dann gibt es auch dort immer mehr bekannte und ungefixte Lecks, so das die betreffenden Systeme dann nicht mehr mit dem Netzwerk verbunden sein dürften - und das bei einem System, welches von IP lebt...

Aber außerdem: Ja, openHAB startet wesentlich schneller, es ist genügsamer, was die Ressourcen betrifft (immer vorausgesetzt, man vergleicht zwei identisch konfigurierte Systeme) und die Main UI ist - nun ja, noch nicht feature complete, aber zumindest weit dichter dran als Paper UI.

Das Wichtigste aber: Solange man nur mit Things, Items, Rules und Sitemaps arbeitet, kann man praktisch unverändert mit der alten Konfiguration weiter arbeiten, bis auf die Umstellung von Joda Time auf JavaTime (ja, die hat es dafür in sich) gibt es keine großen Änderungen, die Auswirkungen hätten (also, in der Praxis wesentliche Änderungen - unter der Haube wurde da schon einiges geändert). Du kannst Dein Backup von openHAB2 einfach in openHAB3 einspielen und "nur" die Änderungen vornehmen, welche sich aus Umstellung OH1-Binding->OH3-Binding und den Änderungen am Rule Code ergeben, das ist mit überschaubarem Aufwand verbunden.
Ich habe das z.B. im November durchgezogen, da hatte ich ein paar Tage am Stück Zeit, die eigentliche Umstellung habe ich aber tatsächlich in einem Tag geschafft, kleinere Nacharbeiten waren dann noch auf ein paar weitere Tage verteilt, an denen ich aber immer nur jeweils wenige Minuten gefixt habe - eben, was so auffiel. Ich haeb ca. 1000 Items und etwa 1200 Zeilen Rules, und ich habe beim Umstieg viele Itemnamen angepasst (Dank dateiübergreifendem Ersetzen in VSCode mit Konfiguration über Textdateien kein Problem)