Zwei openhab systeme

[udo1toni]

Leider hat Marianne Spiller bisher kein weiters Buch über openHAB3 geschrieben. Nicht, dass das openHAB2 Buch schlecht wäre, vieles gilt auch weiterhin, allerdings ist die Oberfläche halt eine komplett andere und es gibt massig Dinge, die in openHAB noch nicht mal ansatzweise vorhanden waren. Die Kopplung mehrerer openHAB Systeme funktionierte unter OH2 mit mqtt.

[zinnik]

Wäre es möglich 2 openhab Systeme Beispiel OH3.1.0 und OH3.4.0 in zwei Dockern mit 2 Unterschiedlichen IP Adressen laufen zulassen?

Zb zum testen Produktivsystem und Testsystem.

Was mir als Problem vorschwebt man müsste ja alles händisch an passen zb influxdb muss ja auch wieder neu eingerichtet werden.

Wie ist das mir den Rulas laufen die dann zweimal.

Problem war ich wollte von 3.1.0 auf 3.4.1 wechseln aber irgendwie hatte ich nur Fehlermeldungen im Log. Meine vorhandenen Rules sind auch nicht wirklich gelaufen. In der Sitemap hatte ich permanent Fehler über Group Widget das sie keine Items haben und vieles mehr nun wollte ich mich langsam rantasten aber ohne das laufende funktionierende 3.1.0 zu verlieren.

Daher die frage nach 2 gleichzeitig laufenden openhabs

[udo1toni]

Bei mir laufen gerne auch mal drei Instanzen nebeneinander, das ist nicht das Problem. Die Schwierigkeiten liegen darin, wenn Du von allen Instanzen aus auf die selbe (!) Hardware zugreifst. Und mit den Rules ist es noch mal kritischer: Die Systeme werden sich bei identischer Bestückung mit Rules einfach ins Gehege kommen, je nach Art der Trigger bis zur kompletten Unbenutzbarkeit aller Instanzen. Wenn Du mehrere Instanzen von openHAB laufen lassen willst, musst Du unbedingt sicherstellen, dass immer nur eine der Instanzen aktiv wird.

Ich habe bei Umstellungsprozessen schon mal alle Rules in der neuen Instanz auskommentiert (einer der Vorteile von Textdateien...) und dann jeweils wenn ich eine Rule aktiviert habe, vorher die im alten System deaktiviert.
Meist ist so was aber gar nicht notwendig.

Zu Deinem Problem mit in Gruppen fehlenden Items: Prüfe bitte alle Items, Channel und Things ob deren IDs (beim Item der Name) mit einer Zahl beginnen. Das war noch nie erlaubt, aber openHAB3.4 setzt dies nun rigoros durch. Es gibt massig Fehlermeldungen bei Leuten, weil die die entsprechenden Erläuterungen nie ernst genommen haben...

Der Sprung von 3.1 zu 3.4 sollte davon abgesehen eigentlich problemlos möglich sein, es gibt aber eventuell ein paar breaking Changes, einige Bindings betreffend. Da müsstest Du in den Changelogs aller stable Versionen seit 3.1 nachschauen, also 3.2, 3.3 und 3.4.

Ansonsten könntest Du natürlich auch ein Backup der Konfiguration ziehen (openhab-cli backup) und dieses auf dem neuen System einspielen (aber wie gesagt... vorher das alte System runterfahren), da sollte eigentlich (bis auf die Sache mit den Namen bzw. IDs) kein Showstopper auftreten.

Ich habe Ende November mein System von 2.5.12 auf 3.3 gehoben und dann nach kurzer Zeit auf 3.4.0, sowie gestern auf 3.4.1, ich hatte dabei allerdings auch das Namensschema meiner Items geändert, was natürlich erheblichen Impact hatte. Mir war dabei egal, dass ich die persistierten Daten verliere, meine InfluxDB habe ich Anfang des Jahres auf 2.6.1 gehoben, da wäre eine Datenübernahme von 1.8.? ohnehin eher schmerzhaft geworden. Letztlich kenne ich meine Daten einigermaßen
MariaDB loggt im Hintergrund auch noch mit, da habe ich für die neue Instanz (wegen der geänderten Itemnamen) aber auch eine neue Datenbank angelegt. Die alte liegt noch eine Weile da, falls ich noch mal was nachschauen muss und in ein paar Monaten wandert sie in den Orkus.

[Mclupo]

Über das „Remote Openhab“ Binding kannst du items von einem Rechner zum anderen übertragen.

[udo1toni]

Über das „Remote Openhab“ Binding kannst du items von einem Rechner zum anderen übertragen.

Ja, das hat aber mit dem beschriebenen Problem nichts zu tun

[Mclupo]

@udo wenn er auf der Sitemap vom NAS seine IO oder Werte vom Raspi sehen will, kann er die doch im NAS spiegeln und auf der Sitemap ansehen und Steuern oder hab ich das Thema falsch verstanden??

[udo1toni]

Nein, es ging um die Ablösung eines bestehenden Altsystems (3.1) mit einem aktuellen System. Außerdem meinte ich den Wunsch nach einer Testplattform für den nächsten Umstieg herauszulesen.

[zinnik]

Hi

Ja genau es geht um die Ablösung eines Altsystems.

Mein Openhab läuft auf einer Qnap im Docker mit einer Statischen IP als nicht mit der IP vom Nas.

Ich habe bei Umstellungsprozessen schon mal alle Rules in der neuen Instanz auskommentiert (einer der Vorteile von Textdateien...) und dann jeweils wenn ich eine Rule aktiviert habe, vorher die im alten System deaktiviert.

Wie hast du alles rules mit einmal auskommiert?

Zu Deinem Problem mit in Gruppen fehlenden Items: Prüfe bitte alle Items, Channel und Things ob deren IDs (beim Item der Name) mit einer Zahl beginnen. Das war noch nie erlaubt, aber openHAB3.4 setzt dies nun rigoros durch. Es gibt massig Fehlermeldungen bei Leuten, weil die die entsprechenden Erläuterungen nie ernst genommen haben...

Ich glaube das neue 3.4.1 hat so was bemängelt

Code: Alles auswählen

Group icon="outdoorlight" label="Weihnachtsbeleuchtung" {
        Switch icon="light" label="Wandprojektion" item=shellyplugsWandprojektion192168180_Betrieb
        Switch icon="light" label="Lichterkette Schuppen" item=shellyplugsLichterkette192168177_Betrieb
        Switch icon="light" label="Rentier Wohnzimmer" item=shellyplugsFensterWeihnachten192168179_Betrieb
    }

Weil Group icon="outdoorlight" label="Weihnachtsbeleuchtung"kein Item hat. Ich glaube du hast dazu schonmal in einem anderen Beitrag erwähnt das man dies eh nicht so macht sondern dafür ein Text Widget nehmen soll, liege ich da richtig?

Der Sprung von 3.1 zu 3.4 sollte davon abgesehen eigentlich problemlos möglich sein, es gibt aber eventuell ein paar breaking Changes, einige Bindings betreffend. Da müsstest Du in den Changelogs aller stable Versionen seit 3.1 nachschauen, also 3.2, 3.3 und 3.4.

Ja zb das Tuya Binding wäre für mich sehr wichtig was es ja nicht offiziell gibt sondern nur von Smarthome/J Add-ons über Repositority.
Für meine Raum Thermostate falls du dich noch erinnern kannst, da hast du mir doch bei diesen tollen rules geholfen (tempget.rules und temset.rules)

Ansonsten könntest Du natürlich auch ein Backup der Konfiguration ziehen (openhab-cli backup) und dieses auf dem neuen System einspielen (aber wie gesagt... vorher das alte System runterfahren), da sollte eigentlich (bis auf die Sache mit den Namen bzw. IDs) kein Showstopper auftreten.

Das Backup mache ich immer indem ich mir einfach die 3 Ordner (userdata,conf und addons)kopiere und dann wieder hineinkopiere ins neue System.

Mir war dabei egal, dass ich die persistierten Daten verliere, meine InfluxDB habe ich Anfang des Jahres auf 2.6.1 gehoben, da wäre eine Datenübernahme von 1.8.? ohnehin eher schmerzhaft geworden. Letztlich kenne ich meine Daten einigermaßen

Ja das ist bei mir auch ein Problem hatte mal die neue DB am Anfang probiert und hatte echt probleme die ans laufen zubekommen damals noch die 2.01 oder so.
Des weiteren komme ich gar nicht mit der neue Sprache (flux) der Datenbank klar.

Ich habe mit der 1.8.2 Version soviel in Grafana visualisiert, Das ich da echt Panik bekomme das alles nochmal zu machen und auch daten zu verlieren.


Und wie du weißt bin leider nicht in diesen Programmiersachen (Datenbanken und Scripte oder Rules schreiben) nicht sehr bewandert.
Und müsste alles wieder im Forum nachfragen.

Mich trotzdem nochmal reizen warum die Rules fast alle nicht gelaufen sind.

Zb die, die wir @udo1toni auch letztens erst zusammen gemacht haben mit der Sockelbeleuchtung Küche und der automatischen Farbänderung

[udo1toni]

Mein Openhab läuft auf einer Qnap im Docker mit einer Statischen IP als nicht mit der IP vom Nas.

Ich hoffe mal außerhalb des DHCP Bereichs Ansonsten ist dagegen nichts einzuwenden, es ist ohnehin sinnvoll, für openHAB das host-Netz zu verwenden, da AVAHI aka ZeroConf nicht über Subnetze hinweg funktioniert (es setzt Multicast voraus; Multicast wird grundsätzlich nicht geroutet).

Wie hast du alles rules mit einmal auskommiert?

Da ich meine Rules mittels Textdateien verfasse, ist es das einfachste, die Dateiendung zu ändern. In einer späteren Phase setze ich am Anfang der Datei ein /* und am Ende der Datei ein */, alles dazwischen ist automatisch auskommentiert (solange man diese Zeichen nicht schon verwendet, was bei mir aus Gründen nicht der Fall ist). Im weiteren Verlauf verschiebe ich das Kommentarzeichen immer weiter, bis alle Rules laufen.

Weil Group icon="outdoorlight" label="Weihnachtsbeleuchtung"kein Item hat

Ja Das Group Widget ist ausdrücklich und ausschließlich dazu gedacht, ein Group Item auszulesen und dessen Member mit dem Default Widget auf einer Tochterseite darzustellen. Wenn Du also das Group Widget ohne Parameter item angibst, ist das ein Verstoß gegen die Konfigurationsregeln, weil item eben nicht optional ist.
Früher hat openHAB gnädig darüber hinweg gesehen, jetzt nicht mehr (gut so).
Wenn Du eine Gruppe Widgets auf einer Tochterseite darstellen willst, so ging das schon immer über das Text Widget. Du musst also lediglich (schon im Altsystem!) überall da, wo Du Group ohne item-Parameter stehen hast, das Wort Group durch Text ersetzen, schon ist die Datei (mindestens in diesem Punkt) regelkonform.
Ansonsten rante ich gerne gegen das Group Widget (selbst wenn es korrekt verwendet wird) weil es nur zu einem gut ist, und das ist der schnelle Erfolg. Man verliert aber jegliche Kontrolle über das Aussehen der Tochterseite, man kann nicht bestimmen, welches Widget zur Darstellung verwendet werden soll, man kann keine besonderen Formatierungen verwenden, keine "richtigen" Unterseiten erstellen, keine Frames nutzen... schlicht, weil es keine Stelle gibt, um die entsprechenden Parameter einzufügen.
Deshalb empfehle ich immer, das Group Widget von vornherein zu meiden, allenfalls für einen kurzen Test zu nutzen, dann aber umgehend die Unterseite komplett auszuformulieren.
Tipp an der Stelle: Wenn man VS Code nutzt, kann man Items in der Sitemap einfügen lassen. Group Items kann man dabei auch als Block einfügen lassen, dabei wird die Gruppe automatisch in Einzelelemente aufgelöst. Anschließend muss man nur noch Anpassungen vornehmen, aber nicht alles von Hand tippen.

Ja zb das Tuya Binding wäre für mich sehr wichtig was es ja nicht offiziell gibt sondern nur von Smarthome/J Add-ons über Repositority.

Das sollte unverändert funktionieren (also abgesehen davon, dass es erneut eingerichtet werden muss - das Repository muss dann als 3rd-Party Repository hinterlegt werden; anschließend stehen alle Bindings daraus auch über die interne Binding-Suche zur Verfügung.
Keine Ahnung, ob sich bei dem Binding etwas grundsätzliches geändert hat, das geht dann aber aus der Doku hervor. Ich bezog mich eher auf Dinge wie die Änderung eiunes Parameter Namens (z.B. host statt ip oder host statt hostname), was dann dazu führt, dass der entsprechende Parameter nicht mehr gesetzt ist. Es gibt zwar Upgrade Routinen, die sich um solche Dinge kümmern sollen, aber die müssen ja nicht unbedingt funktionieren...

Das Backup mache ich immer indem ich mir einfach die 3 Ordner (userdata,conf und addons)kopiere und dann wieder hineinkopiere ins neue System.

Ja, perfekt, das funktioniert ja unter Docker wunderbar.

hatte mal die neue [Influx]DB am Anfang probiert und hatte echt probleme die ans laufen zu bekommen

Inzwischen ist die 2.6.1 draußen. Es gibt fertige Docker Images, das sind drei Klicks, dann läuft das Ding. Wichtig zu wissen: Man legt zwingend einen User an, um sich im System anmelden zu können, der User gehört zwingend einer Organisation an, die also auch angelegt werden muss (die kann aber z.B. "zuhaus" heißen, oder auch "Hurslibarsli", völlig wurscht.
Für die Daten selbst legt man dann ein Bucket an (das entspricht wohl am ehesten den Shards in der alten InfluxDB, denn dort setzt man die Retention Policy).
Und dann legt man Token für den Datenzugriff an, wobei man pro Token definieren kann, welche Buckets verwendet werden dürfen (nur lesen oder lesen und schreiben).
Das Schöne: das geht alles über die UI, welche, wenn man sie mal verstanden hat, einigermaßen intuitiv bedienbar ist.

Des weiteren komme ich gar nicht mit der neue Sprache (flux) der Datenbank klar.

Wie erwähnt bringt InfluxDB eine UI mit, in der Du die notwendigen Abfragen bequem zusammenklicken kannst. Dabei gibt es sogar eine grafische Ansicht des Ergebnisses, als Liste, als Graph usw. Natürlich nicht so komfortabel wie Grafana, aber mehr als ausreichend, um einen ersten Eindruck der Daten zu gewinnen. Auch hier gilt: hat man mal das Prinzip verstanden, lässt es sich intuitiv bedienen. Den fertigen Code kopierst Du dann einfach und fügst ihn in Grafana ein, fertig. Wenn Du Dir ein paar Queries anschaust, die so erzeugt wurden, kommst Du auch schnell dahinter, wie Du diese optimieren kannst.

Mich trotzdem nochmal reizen warum die Rules fast alle nicht gelaufen sind.

Das wird man sich im Detail anschauen müssen. Wie gesagt, Schritt eins wäre, das System mit 3.4.1 zu starten, die Things zum Laufen zu bringen, die Items zu füllen, dann erst die Rules zu übernehmen, wobei Du immer darauf achten musst, dass eine Rule nur auf einem der beiden Systeme arbeitet, da es sonst zu Störungen kommen kann. Und wie erwähnt: Es gibt Bindings, bei denen ein paralleler Zugriff mehrerer Instanzen auf den identischen Bus nicht ohne weiteres möglich ist, selbst wenn der Hersteller etwas anderes suggeriert