hörende Adresse Gira Homeserver internes Kommunikationsobjekt

[mape71]

Hallo zusammen,

vielleicht könnt Ihr mir ja an einer Stelle mit dem Homerserver (4.9) weiterhelfen, wo ich mir aktuell die Zähne ausbeiße. Für die Außenbeleuchtung habe ich zwei Wege des Schaltens - einmal direkt über Taster (also Sensor und Aktor direkt in einer GA verknüpft) und einmal, über diverse Logikfunktionen verknüpft (Zeit, Helligkeit, Bewegungsmelder, etc.), über den Homeserver. Damit möchte ich erreichen, dass auch bei Ausfall des Homeservers auf jeden Fall die Leuchten separat geschaltet werden können - oder sie aber auch die Automatik übersteuern können (z.B. wenn die Automatik die Leuchten einschaltet, kann ich sie immer wieder mit einem Taster ausschalten). Von der grundlegenden Funktion ist das soweit OK - bis auf eine Kleinigkeit.
Ich kann die Leuchten auch über die Visu des HS (Quadclient) schalten. Dazu habe ich als "Schaltauslöser" interne Kommunikationsobjekte eingerichtet. Wenn ich nun die Leuchten über einen Taster schalte, sehe ich dies zwar an der Statusanzeige in der Visu - allerdings bekommen die Buttons der Visu dies nicht mit. Lägen unter den Buttons der Visu EIB Kommunikationsobjekte würde ich mir dort nun den Status der Leuchten als hörende Adresse (Zentraladresse) einrichten und alles wäre OK - bei den internen Kommunikationsobjekten scheint es diese Möglichkeit aber nicht zu geben.

hat dazu jemand eine Idee?

Vielen Dank vorab und viele Grüße

Marko

[vento66]

Lägen unter den Buttons der Visu EIB Kommunikationsobjekte würde ich mir dort nun den Status der Leuchten als hörende Adresse (Zentraladresse) einrichten und alles wäre OK

und warum machst Du es nicht einfach so?

[MrDuFF]

Du kannst ein IKO allerdings umwandeln in ein „KO“

[mape71]

...weil die EIB Kommunikationsobjekte dann die Logik stören würden, da ich diese dann ja sowohl zum direkten Schalten (ETS GA), als auch als Trigger für den Weg über die Logik des HS verwende. Was ich noch nicht versucht habe sind in der ETS "leere" GAs anzulegen, die ich dann im HS als EIB Kommunikationsobjekt verwende. Das würde ich aber als nächstes versuchen, wenn es da nicht einen "eleganteren" Weg gibt...

[mape71]

leere GAs wäre dann ja z.B. auch der Weg IKO zu KO

[EugenDo]

Wieso nimmst du zum Schalten nicht die gleiche GA, wie beim Taster?

[vento66]

Du kannst ja auch beim Eintreffen der Rückmelde GA eine Ausgangsbox setzen mit dem befehl "setze IKO auf Wert von" und da dein IKO auf den Wert der Rückmelde GA setzen (Ist praktisch das selbe wie hörende GA)

[mape71]

...ich kann natürlich nicht ausschließen, dass ich in der Logik des HS etwas falsch gemacht habe - aber das war der Punkt mit dem gegenseitigen Stören. Durch die direkte Verknüpung über eine GA in der ETS und der Verknüpfung über die Logik haben sich diese beiden Wege immer wieder gestört. Wenn ich einen Schaltbefehl am Taster auslöse, hat dies auch gleich die Logik des HS angestoßen - die sollte aber das Licht nur schalten, wenn die entsprechenden Bedingungen des Automatikbetriebes erfüllt sind. Wenn ich alles über den HS laufen lasse, also auch das einfache Schalten, ist das ja auch kein Problem - das möchte der Kunde aber partout nicht.

[mape71]

ah, der Ausgangsbox Weg hört sich gut an - das versuche ich mal, vielen Dank!

[mape71]

...Ausgangsbox könnte doch wieder schwierig sein, da ich damit ja das komplette IKO setze - also auch einen weiteren Schaltbefehl auslöse. Hab's gerade mal versucht, das Licht lässt sich einmal einschalten - und dann nicht mehr aus (oder besser gesagt nur so lange aus, wie der Aktor zum Ausschalten und wieder Einschalten benötigt). Ich habe das setzen des IKO in der Logik mit Auswertung der Schaltflanken getriggert, so dass das IKO auf den Status gesetzt wird, sobald eine positive oder negative Schaltflanke auftaucht - so wäre doch OK, oder?

[mape71]

...hab's jetzt mal mit der Umwandlung IKO zu KO gemacht - finde ich persönlich nicht schön, aber es funktioniert. Dennoch - elegantere Wege sind herzlich willkommen. Ich habe dabei ein wenig Sorge, dass man schnell die Übersicht verliert, wenn es dann mal mehrere KOs dieser Art gibt (aktuell sind es in diesem Projekt nun 4, das sollte ich noch hinbekommen:-)

[DJ.Picasso]

Lägen unter den Buttons der Visu EIB Kommunikationsobjekte würde ich mir dort nun den Status der Leuchten als hörende Adresse (Zentraladresse) einrichten und alles wäre OK

Genau so solltest Du es machen! Auf die Buttons den Status der einzelnen Leuchten legen (hörende Adresse) und bei den Befehlen kannst Du dann weiterhin mit Deinen internen Adresse arbeiten.

[mape71]

...ja genau, habe ich ja auch gemacht. Die Frage war allerdings ob es diese Möglichkeit auch bei den internen Kommunikationsobjekten gibt - dort lässt sich erst einmal keine hörende Adresse anlegen

[DJ.Picasso]

...ja genau, habe ich ja auch gemacht. Die Frage war allerdings ob es diese Möglichkeit auch bei den internen Kommunikationsobjekten gibt - dort lässt sich erst einmal keine hörende Adresse anlegen

... wofür sollte das denn auch gut/notwendig sein. Es geht doch letztendlich nur darum, ob die "Nutzung" einer Adresse den Bus "belastet" indem ein Signal auf den Bus gelegt wird oder nicht.

Da der Status ja sowieso über den Bus gekommen ist, sollte man ihn auch direkt nutzen und nicht noch zusätzlich ein internes Objekt gehen - das ist Doppelt-Gemoppelt (aus meiner Sicht).

[mape71]

Da ist wohl was dran - ich hatte mich halt gescheut Adressen zu verwenden, die ich nur intern benötige, die aber ggf. später auch mal in der ETS belegt werden - und dann ja auch zu einem Konflikt führen könnten