Remote openHAB Binding verlinken von Items

[Michdo93]

Hi,

also ich habe da eine Frage, wo ich bisher noch nichts dazu gefunden habe. Und zwar, wie ich die Items am geschicktesten miteinander verlinke. Was ich gemacht habe ist, dass ich auf beiden Instanzen jeweils ein Thing erstellt habe für den "remote Server". Da das Binding bidirektional funktioniert, weiß ich, dass ich nur bei einer von beiden Instanzen über die Trigger Channels dann die Items miteinander verknüpfen muss.

• Bei mehreren tausendenden Items ist dies sehr aufwendig. Gibt es keine Möglichkeit dies zu automatisieren? Also bei mir heißen auf beiden Seiten alle Items, die miteinander verknüpft werden sollen genau gleich. Wäre es denkbar, dass man sagt, sobald ein Items so und so heißt und das Gegenpart dazu existiert, dass das verknüpft wird? Die GUI ist da sehr, sehr langsam und teilweise hängt sich der Browser auf, bis alle Channels erkannt wurden.
• Dann eine weitere Frage, ob ich ein Item auch mehrfachen verlinken kann. Also meinetwegen, dass ich es auf einer Instanz ändere (z.B. an/aus) und 5 weitere Instanzen dies entsprechend berücksichtigen.
• Die letzte Frage, ist für mich sehr wichtig. Ich sehe auf beiden Seiten jeweils einen Trigger-Channel, wie bspw. ein Dimmer. Die Items heißen exakt gleich, aber ich kann dieses Channel nicht mit einem existierendem Item verlinken. Da bin ich verwundert. Auf beiden Seiten würde quasi jeweils von der anderen Seite aus betrachtet der Trigger Channel gefunden werden. Und das Item ist entsprechend vorhanden. Das ist kein Einzelfall. Und ich stelle da mal zwei Annahmen: Erstens ist es vielleicht nicht möglich, dass je nach Itemtyp dieses verlinkt werden kann und zweitens, es ist vielleicht möglich, dass das Binding einfach nicht alle Items erkennen kann. Somit wäre es inpraktikabel.

Auf den letzten Punkt gehe ich noch einmal näher ein. Ich habe bspw. auf beiden Seiten folgende Items:

Code: Alles auswählen

Group gIoT_Hue_Lampe6    "Lampe 6"    <lightbulb>    (gIoT_WandLampen)
Switch iIoT_Hue_Lampe6_Schalter    "Schalter"    <light>    (gIoT_Hue_Lampe6)    {channel="hue:0210:00178825916e:23:color"}
Color iIoT_Hue_Lampe6_Farbe    "Farbe"    <colorwheel>    (gIoT_Hue_Lampe6)    {channel="hue:0210:00178825916e:23:color"}
Dimmer iIoT_Hue_Lampe6_Helligkeit    "Helligkeit"    <light>    (gIoT_Hue_Lampe6)    {channel="hue:0210:00178825916e:23:color"}
Dimmer iIoT_Hue_Lampe6_Farbtemperatur    "Farbtemperatur"    <rgb>    (gIoT_Hue_Lampe6)    {channel="hue:0210:00178825916e:23:color_temperature"}
String iIoT_Hue_Lampe6_Alarm    "Alarm"    <alarm>    (gIoT_Hue_Lampe6)    {channel="hue:0210:00178825916e:23:alert"}
Switch iIoT_Hue_Lampe6_Farbeffekt    "Farbeffekt"    <colorwheel>    (gIoT_Hue_Lampe6)    {channel="hue:0210:00178825916e:23:effect"}

Wenn ich dieses Channel versuche zu verlinken, dann hätte ich:

Code: Alles auswählen

    Item iIoT_Hue_Lampe6_Helligkeit
    remoteopenhab:server:192_168_0_22:iIoT_Hue_Lampe6_Helligkeit (Dimmer)
    Item iIoT_Hue_Lampe6_Helligkeit from the remote server.

Bei Item to link wird mir dann aber nur folgendes als Möglichkeit geliefert:

Code: Alles auswählen

Farbeffekt (iIoT_Hue_Lampe6_Farbeffekt)
Schalter (iIoT_Hue_Lampe6_Schalter)

Ich zeige es mal noch einmal bildlich:





Dies würde mich zu der Annahme kommen lassen, dass ich nur Items vom Typ Switch mit dem Remote openHAB Binding verlinken kann. Ist dies richtig?

Gehe ich den umgekehrten Weg über Items, wähle das Item aus und wähle bei Channels add Channel Links, kann ich zwar das Thing vom Remote openHAB Binding auswählen, darunter dann aber keinen Channel.

Liebe Grüße
Michi

[udo1toni]

Frage vorweg: Was hast Du vor? Es gibt nur wenige Gründe, mehr als eine openHAB Instanz zu betreiben (insbesondere, wenn sich diese Instanzen miteinander unterhalten sollen).

[Michdo93]

Gut,

ich hoffe ich kriege es erklärt. Wir haben für Studentenprojekte in verschiedenen Räumen je eine Raspberry Pi mit openhabian rumstehen. Unter openHAB 2 nutzen wir hierzu noch MQTT. Und dann haben wir einen Linux-Server, wo openHAB installiert ist. Auf diesem Server sind alle Geräte angelernt und konfiguriert. Damit verschiedene Projektgruppen lokal in ihren Räumen arbeiten können, ohne die anderen zu stören, gibt es quasi je Raum eine openHAB-Instanz. Auf dieser werden die Geräte nicht neu angelernt oder hinzugefügt. Das kann man sich klar machen, weil es auch Geräte gibt, die nur eine 1:1-Beziehung aufbauen können. Ändert ein Student in seiner ihm zugewiesenen openHAB-Instanz, so wird an den Server quasi nur dass kommuniziert, was die Geräte in seinem Raum betreffen. Er kann also sämtliche Rules und Programmcodes entwickeln. Hier kann es auch sein, dass er openHAB neustarten muss oder andere Dinge, die sonst für die anderen kritisch wären. Das eigentliche Gesamtsystem bleibt dabei unangetastet. Also es geht gegen null, dass wir den openHAB-Server ebenfalls neustarten müssen. Mal anders gedacht: Müssen ja nicht nur Bugs sein, die stören, es geht auch um die reine Sichtbarkeit. Es können nicht zwei Gruppen dieselben Lichter ein- und ausschalten, sich somit gegenseitig stören. Projekte sind hier ja echt vielfältig. Egal ob Sprachsteuerungen, MagicMirror, VR-Brillen usw.

Vielleicht macht ja ein neuer Aufbau Sinn. Über MQTT war es ja bspw. möglich, dass man wenn ich von einem Roboter aus etwas entwickel, ja direkt die Daten per MQTT abgreife bzw. hinsende. Geht mit REST an für sich genauso gut. Also ein Teil der Projekte würden ja keine weitere openHAB-Instanz benötigen. Die weiteren openHAB-Instanzen benötigen wir ja quasi nur für Projekte, wo Studenten mit openHAB direkt arbeiten. Dies sind Rules, Scripts, anderweitige Programmcodes oder hoffentlich auch bald mal, eigene Bindings.

Zur Vorgehensweise:

Wir haben für jeden Raum eine eigene items-Datei. Auf den jeweiligen Instanzen dann quasi nur die 1:1-Kopie für diesen Raum. Auf dieser Instanz sind dann auch nötige Bindings und Things installiert. Aber dass sind meist sehr wenige. Hätte ich bspw. ein HomeMatic-Gerät, was ich dort steuere, dann brauche ich kein HomeMatic-Binding mehr, weil über den openHAB-Server es schon angebunden ist. Aber ich sollte sämtliche Items zu dem Gerät genauso bedienen, auslesen und nutzen können, wie auf dem Server. Die Sitemap ist quasi genau gleich, bis auf dass andere Räume ebenfalls rausfallen. Und dann ist es eben möglich, quasi eine individuell zugeordnete und eingeschränkte Instanz zu openHAB zu ermöglichen, wo man auf ein Teil des Gesamtsystems Zugriff hat. Man kann aktuell in openHAB 2 dann über MQTT Rules schreiben, die nur den Raum betreffen.

Damit dies mit den Rules natürlich gut funktioniert, reicht es natürlich nicht, dass ich nur ein Switch verlinken und steuern kann. Also ich brauche ja auch Sensorwerte, die evtl. in einer Rule ausgelesen werden. Oder wo man einen Trigger aufgrund eines Schwellwertes erstellen will etc.

Auch versuchen wir so natürlich den Studenten manches einzuschränken. Nur Mitarbeiter sollen neue Geräte konfigurieren oder die Konfigurationen ändern. Hätten die Studenten Zugriff auf das Gesamtsystem so könnten sie absichtlich oder versehentlich ein Binding deinstallieren oder ein Thing löschen. Das geht so dann natürlich nicht. Weil dann müssten wir alle Studenten quasi mit Adminrechten ausstatten. Testen sie neue Geräte, so können sie dies auch lokal auf einer Instanz konfigurieren. Dies geht natürlich. Wird dann in ihrer Rule dann auch berücksichtigt. Aber kann natürlich nur von derer ihrer Instanz aus gesteuert werden und nicht vom Gesamtsystem. So lassen sich auch Szenarien mit neuen Geräten testen. Für mich als Mitarbeiter bedeutet dies, dass nachdem ein Studentenprojekt fertig ist und als sinnvoll erachtet wurde, dass ich dann die vorliegende Konfiguration im Gesamtsystem übernehme, die Regel rüberkopiere usw.

Kann man sich als ein eingeschränktes Benutzerkonto vorstellen. Geht ja nicht nur um openHAB selbst, sondern auch um das Gerät auf dass es läuft. Vom Server geben wir natürlich ebenfalls nicht das Passwort her. Also die Studenten können auch sämtliche Software-Pakete über Git clonen oder über den Apt-Paketmanager herunterladen und so evtl. noch ganz andere neue Ansätze in die Entwicklung einbringen.


Wir selbst reden hier quasi von einer Zwei-Schichten-Architektur, indem wir quasi eine eingeschränkte Schicht für Studenten anbieten.


Ich hoffe man kann mir hier folgen. Da ich die Items aus diesem Auszug mit Dimmer, Color oder String nicht verlinken konnte, funktioniert dieses Vorhaben nicht wie gewünscht.

[udo1toni]

Hatten wir das Thema nicht schon an anderer Stelle?

Ich glaube nicht, dass die Vorgehensweise sinnvoll ist.
Besser wäre es, lokale Systeme zu haben. Hardware wird an die lokalen Instanzen angebunden. Entweder man nutzt direkt Raspberry Systeme oder auch einen zentralen Server mit Docker Containern. Raspberrys können per Netzwerk booten, so dass man über einen zentralen Server die Boot Images bereitstellen kann. Die individuelle Konfiguration kann dann pro Gerät nachgeladen werden, ebenfalls über LAN. Auf diese Weise lassen sich die Systeme sicher gegen Manipulation schützen (schlimmstenfalls wird halt einmal gebootet und alles ist wieder sauber).
Docker Container können ebenfalls so angelegt werden, dass sie immer mit einem bestimmten Stand starten.

Eine zentrale openHAB Instanz kann dann per REST (bzw. über das openHAB Binding) alle dezentralen Instanzen vollständig steuern.

Ich verstehe nicht, wo der Vorteil liegen soll, Hardware zentral zu verwalten, nur um sie dann verschiedenen Systemen exklusiv zur Verfügung zu stellen.

openHAB ist nicht darauf ausgelegt, in dieser Art verwendet zu werden. Es gibt keinen ausreichenden Schutz gegen ein Ausbrechen aus der Sandbox. Dateien, in denen die Items definiert sind, kann man manipulieren, und sei es nur, um zu beweisen, wie schlecht das System dagegen geschützt ist.

[Michdo93]

Mhm, ich weiß nicht, warum, aber es würde jetzt immerhin funktionieren. Nutze jetzt auch items-Dateien, soweit ich da bis jetzt zumindest durch bin. Konnte auch die ersten Regeln schon testen. Sind immerhin 3745 Items. Würde mal tippen, dass ich knapp die Hälfte inzwischen habe.

Ich gebe dir mit deiner Aussage recht. Hatte ich vor ein paar Wochen in den entsprechenden Meetings auch angesprochen. Aber gut, dann mach ich es so, wie gewünscht. (Wäre auch mit Backups leichter, wenn wir den Network Boot nutzen würden. Oder das die Systeme gemeinsam starten, weil nach einem Stromausfall die Raspberry Pi's "zu schnell" starten und dann muss man openHAB noch einmal neustarten, nachdem der Server komplett hochgefahren ist. Da hab ich aber ein Bashscript geschrieben, der nach dem Systemstart dies dann ausgleicht).