OpenHab 3 Umstieg

[udo1toni]

Also, um das nochmal einzuordnen:

openHAB stable bedeutet: Da wird nix mehr dran geändert, es sei denn, es tauchen schwere Fehler auf
openHAB testing bedeutet: Dieses Build ist gut getestet und sollte keine Probleme bereiten.
openHAB unstable bedeutet: hier sind die neuesten Funktionen integriert, grundsätzlich sollte alles funktionieren, die einzelnen Builds werden aber nicht manuell getestet.

Das bedeutet unterm Strich: openHAB3 kann problemlos produktiv eingesetzt werden. Ob man nun die nightly (aka unstable) Version nimmt oder den milestone (aka testing) ist weitgehend egal. Läuft openHAB, ist alles gut. Bei unstable ist allerdings die Wahrscheinlichkeit höher, dass es Probleme bei der Inbetriebnahme geben könnte.
Wer jetzt neu einsteigt, sollte sich nicht mehr mit openHAB2 aufhalten. Allenfalls, um ein dringend benötigtes Binding zu nutzen, welches nicht mit OH3 kompatibel ist - allerdings will das gut überlegt sein, schließlich müsste man zwei openHAB-Installationen pflegen. Da ist es manchmal sinnvoller, bis zum Erscheinen einer OH3-Version des benötigten Addons auf ein generisches Addon auszuweichen (z.B. http2)

Bei keiner Version (auch nicht bei stable) sollte man einfach ein Update ausführen, nach dem Motto "ist ja getestet", es ist eher wahrscheinlich, dass man nach jedem Update an der einen oder anderen Stelle korrigieren muss.
Bei keiner Version ist es zwingend notwendig, Updates einzuspielen, wenn man eine stabil laufende Installation hat. Natürlich sollte man ab und zu mal aktualisieren, um nicht den Anschluss zu verlieren (und dann vor einem riesen Berg Arbeit zu stehen, wenn doch ein Update ansteht - ich weiß, wovon ich schreibe...), dann ist es aber immer wichtig, zu schauen, was sich seit dem letzten Update geändert hat. Bei den Milestones ist das durch die jeweiligen Postings von Kai im englischen Forum sehr gut handelbar, bei den nightly Builds hat man nur die changelogs zur Verfügung, anhand derer man aber sehen kann, auf welche Dinge man achten muss. Alles, was man selbst nicht nutzt, kann man dabei links liegen lassen (aber Vorsicht, es gibt viele Module, die zum Core gehören und die einem normalen Anwender vielleicht wenig sagen...) Mit der Zeit bekommt man aber ein Gespür dafür

[violine21]

Ich bin mir aber nicht ganz sicher, was du mit der Verknüpfung meinst, deshalb zur Klarstellung: Ich habe eine textbasierte Konfiguration.

Damit meinte ich die Rules.
Ich war der Meinung, Du hast ein produktives System mit einem OH2 und hast Dir zum Test ein OH3 aufgesetzt.
Laufen denn beide Systeme parallel und beeinflussen sich nicht gegenseitig?
Schliesslich will man ja mit dem Testsystem auch mal was testen.

[peter-pan]

Das mit den Rules hängt zum einen davon ab, ob sie auch OH3-kompatibel sind (vor allem Datums-bedingt - Joda-Time) und zum andern natürlich sicherlich auch davon, was die Rule macht(machen soll). Im Grossen und Ganzen kann man ja zur Sicherheit beim Testen einer Rule, bestimmte Dinge ausklammern/auskommentieren (z.B. ein sendCommand).
Was ich mir vorstellen könnte, wären Cron-Trigger, die zur gleichen Zeit auf beiden Systemen eine Rule auslösen. Hier wird aber meistens ja auch noch eine bestimmte Bedingung/Zustand abgefragt. Hier könnte es evtl. Probleme geben, wenn dasTriggern im Millisekundenbereich liegt.

Ich gehe aber grundsätzlich beim Test einer Rule so vor, dass ich einen "Dummy-Switch" als Trigger mit einbaue und so die Rule auslösen kann, wie ich das brauche.

Ich habe aber auch noch ein "Test-System" das auf JSR223-Basis läuft(Python-Scripts statt DSL-Rules) und mein Produktiv-System abbildet. Die hab ich auch schon mal parallel laufen lassen. Das ging(geht) eigentlich ganz gut. Im Normalfall mache ich das aber nicht(mehr), da dieses System ja den gleichen Stand hat wie mein Produktiv-System. Wenn ich mit dem JSR223-System arbeite fahre ich OH auf dem Produktiv-System herunter. Der Pi läuft aber weiter, da hier auch meine Mosquitto-Broker/Server installiert ist.

Und jetzt habe ich halt noch einen dritten Pi, auf dem OH3 installiert ist (und erst 1 -2 Rules).

Aber grundsätzlich würde ich sagen, dass sich zwei Systeme, mal abgesehen von den Rules, nicht gegenseitig stören sollten.

[udo1toni]

Ich habe hier auch mehrere Systeme parallel laufen, eben eines produktiv, die anderen zum Testen. Ich hatte bis letztes Jahr über einen längeren Zaitraum (2 Jahre?) sogar zwei Produktiv-Systeme, eines mit OH1.8, das andere mit OH2. Ich habe die Umstellung auf OH2 immer wieder in kleinen Häppchen vorgenommen, hauptsächlich, weil ich möglichst sofort mit den V2-Addons arbeiten wollte, wo es eines gab.
Die Rules hatte ich lange Zeit gar nicht migriert, dann aber in einer "Hau-Ruck-Aktion" innerhalb weniger Stunden, weil das 1.8-System plötzlich einen derben Schluckauf hatte. Da ich keine Lust hatte, dort noch Fehler zu suchen, habe ich dann halt den letzten Schritt gemacht, den ich vorher aus Bequemlichkeit lange herausgezögert hatte.

Da meine Systeme alle in einer virtuellen Umgebung laufen, spielt z.B. Stromverbrauch für mich nur eine untergeordnete Rolle, eine thin-vm (ohne Desktop) wirkt sich vielleicht mit 0.5 Watt aus, aber auch nur, wenn sie was zu tun hat. Eine Windows-VM zieht im Betrieb dagegen gern mal 10 Watt zusätzlich, weil da ständig große Mengen Daten hin und her wandern, selbst wenn kein Anwender-Programm gestartet ist. Das mag aber auch mit dem Virtualisierer zusammenhängen, da hab ich wenig bis keine Ahnung...

[harteknut]

Hallo zusammen,
ich habe heute morgen mal ne Testinstallation von OH 3.0.0 MS3 auf einem rumliegenden PI4 8GB gemacht.
Das macht nen ganz schön guten Eindruck. Die Oberfläche erinnert stark an die von Home Assistant, was ich vor kurzem mal ausprobiert hatte. Am liebsten würde ich sofort umziehen, hab aber vorher noch zwei Fragen:
- Wie ist denn die Zeitschiene der "offiziellen" Veröffentlichung, also mit Docs usw? Ist nicht mehr lang hin, oder?
- Gibts irgendwo eine Doku für die textbasierte Konfiguaration? Ich habe bei meinem OH2 damals auf eine "Hybridvariante" gesetzt: (Things über GUI, Items über Text). Das würde ich gerne aufräumen (alles nach Text), weiß aber nicht, wie ich meine ca. 50 Things rüberkriege...

[peter-pan]

weiß aber nicht, wie ich meine ca. 50 Things rüberkriege...

Was die die nächsten Schritte sind kannst du im internationalen Forum nachlesen.

Da ich alles textbasiert habe, hab ich Items, Things, Transformations etc. einfach per Copy/Paste übernommen. Nur die Rules nicht. Die werde ich nach und nach einspielen, da es wohl ein paar Unterschiede gibt. Bekannt ist, dass es Joda-Time nicht mehr gibt.

Hast du schon mal überlegt ein Backup von deiner OH2-Installation zurückzuspielen ? Ich weiss nur nicht, wie das mit den Pfaden (openhab2 -> openhab) ist.
Mal 'ne Frage meinerseits. Ich hab gestern auch versucht eine OH3M3 Version mit openhabian 1.6 aufzusetzen. Das hat und hat nicht geklappt. OH3 scheint zwar zu laufen, aber ich kann nichts installieren (Addons, Persistence, Transformation, etc.). Ich erhalte nur eine Fehlermeldung in der UI

Code: Alles auswählen

Installation of add-on transformation-scale failed

Ich hab zwar auch eine OH3Installation mit OH3M2 laufen. Die hatte ich manuell installiert, aber da fehlen halt einige Sachen/Tools, die in "openhabian" halt einfach mit drin sind. Die Darstellung über die BasicUI funktioniert auch genauso wie in OH2. Allerdings habe ich mich mit Models, Pages, Widgets und Co. noch nicht näher befasst. Da fehlt mir noch ein bisschen das Verständnis. Aber vielleicht denk ich hier einfach in die falsche Richtung.

In meiner jetzigen Konfiguration (OH2) gibt es auch schon einen "Raumplan" in dem mein Equipment, sprich Schalter, Thermostate, etc. in den Räumen, angezeigt werden und man weiss auch welcher Raum in welchem Stockwerk ist. Und es gibt auch Gruppierungen nach Typen (Licht, Schalter, Türen, Fenster, etc.) oder Gruppen für Wartung und Instandhaltung/Überwachung und Steuerung (Heizkörper, Temperatur, etc.).

Ein Upgrade meiner OH3M2 auf M3 klappt leider auch nicht, da meckert er immer so was mit einem nicht vorhanden Key an, oder so ähnlich.

Wie hast du denn deine Installation aufgesetzt ?

[harteknut]

Danke für den Link! Vor Weihnachten ist ein super Termin, das wird dann ein spannender Urlaub! *freu*

Ich habe meine M3 auf Ubuntu Server 20.04.1 LTS (64 bit) installiert. Und genau wie Du schreibst, fehlen halt ein paar Dinge, die ich von meiner openhabian-rundum-sorglos-Version gewohnt bin. Daher wollte ich ja wissen, wann ich mit openhabian 3 zu rechnen habe. Aber so wie das läuft, mach ich vielleicht einfach mit Ubuntu weiter...

Auf die Darstellung im BasicUI lege ich kaum Wert, die Sitemaps brauch ich nur für die App. Im wesentlichen gehts mir um die Automatisierungen, und die sieht man ja nicht Und die neue Oberfläche ist m.E. für Wartung und Anpassung super geeignet.

[udo1toni]

Grundsätzlich wird für openHAB vor der 8GByte-Version gewarnt, weil es im Kernel (noch) keine vollständige Unterstützung für 64 bit gibt. Mit Ubuntu Server sollte das allerdings kein Problem sein.

Was Deine Frage betrifft: https://community.openhab.org/t/openhab ... s/106329/3 gibt über den näheren Zeitplan Auskunft. Dokumentation ist bei openHAB traditionell eher ein rolling release wobei die Doku ja schon in Arbeit ist (also der Teil, der sich stark geändert hat, die Addons sind ja schon dokumentiert).

Die Things müsstest Du über die REST API exportieren und im neuen System importieren können. Selbst ausprobiert habe ich das aber noch nicht.

[harteknut]

Stimmt, das mit der REST API geht.
Ich habe gestern aber auch einfach mal meinen LCN-Koppler manuell hinzugefügt und dann die Autodetection laufen lassen, meine LCN-Module (immerhin 41 Stück) sind jetzt schon drin, mit richtigem Namen und allem drum und dran. Bin begeistert!

[udo1toni]

Ja. Die Autodiscovery hat halt den Nachteil, dass man im Zweifel andere UIDs bekommt und diese dann neu mit den Items verlinken muss.