Gira X1

[alorenzen]

Die ETS kennt nur die Geräte-Datenpunkte, aber die sind mir zu umständlich.

Wo es für Linienkoppler relevant ist habe ich die GA auf einen Dummy in der ETS gelegt.

Danke. Dummy Geräte ist natürlich eine Idee.
Haste vielleicht trotzdem mal nen Beispiel dafür, wie ich nen Geräte-Datenpunkt In der ETS sichtbar mache? Die Online Doku ist ja eh mehr als umfassend und bei diesem Punkt insbesondere.
Ich sehe z.B. unter einer Zeitschaltuhr den Punkt "Auslöser", dann natürlich bei den Eigenschaften den Punkt "KNX Integration", Dann kann man noch den Datentyp wählen. Aber was soll dann nach der Inbetriebnahme passieren?

Edit: Ah ich glaub ich habs. Entsprechend der Anzahl der verwendeten Zeitschaltuhren im GPA auf dem X1 in der ETS die Verknüpfungen freischalten. Der Punkt "KNX Integration" sorgt nur dafür, dass der X1 auch auf die entsprechende Gruppenadresse hört.
Bräuchte man also garnicht aktivieren. Man könnte die entsprechenden Verknüpfungen als Dummies ansehen.
Vorteil wäre gegenüber einer einzelnen Dummy Adresse, dass man damit dann auch direkt die Zeitschaltnr. im GPA referenzieren könnte.

[beib]

Hi,

ich exportiere das ETS Projekt komplett und importiere im GPA die Gruppenadressen in die X1 Datenpunkte.
Ich achte auf die Namensgleichheit zw. ETS und X1.

In der ETS habe ich eine Hauptgruppe für Interaktionen mit dem X1 reserviert... Sensoren, Alarm, Status.

Wenn der X1 auf normale Adressen zugreift bzw. schreibt, sieht man das nur in den GPA Datenpunkten.

Bis jetzt finde ich mich noch zurecht.

Die Linienkoppler sind auf "Durchzug" gestellt... im EFH reicht das längst.

Grüße
beib

[Gast1961]

Dabei ist mir dann aufgefallen, dass ich im Gegenteil zum früher verwendeten Logikbaustein die Verwendung im neuen X1 garnicht sehe. Funktionieren tut alles.

Ja, die nur im GPA verknüpften Gruppenadress-Datenpunkte findet man in der ETS nicht.
Die ETS kennt nur die Geräte-Datenpunkte, aber die sind mir zu umständlich.

Wo es für Linienkoppler relevant ist habe ich die GA auf einen Dummy in der ETS gelegt.

[alorenzen]

Leute, ich stehe gerade etwas auf dem Schlauch. Ich bin gerade dabei, meine ETS aufzuräumen und vergangene Sünden zu beseitigen. Dabei ist mir dann aufgefallen, dass ich im Gegenteil zum früher verwendeten Logikbaustein die Verwendung im neuen X1 garnicht sehe. Funktionieren tut alles.
Habe ich was vergessen/übersehen? Wie geht ihr damit um?

[dultaffe]

jaydee73
Du hattest recht. Tor geschlossen wird signalisiert. Danke für alles

[jaydee73]

Also meines Wissens nach (ist schon ein Jahr her als ich das in Betrieb genommen habe) unterscheidet der Output OC zwischen ganz geschlossen und offen. Bei "offen" kann er dann natürlich nicht identifizieren, ob 2cm offen (z. B. Lüftung) oder komplett offen (=oben).

Und das ist auch quasi die Ungenauigkeit meiner Logik. Nehmen wir an, das Tor ist komplett geschlossen und wird dann geöffnet. Dann springt der Status direkt auf 0%, also ganz offen. Du könntest das Auffahren aber direkt nach 2cm wieder stoppen und er würde trotzdem auf 0% bleiben. Er kann halt nur die 0 oder 1 vom Status interpretieren, was ich zu 0% und 100% umgebogen habe.

Aber für mich reicht das. Die für mich wichtigere Info ist "Garage zu" und das kann ich eindeutig auswerten. Bei "Garage auf" ist mir die Genauigkeit nicht wichtig, da ich im Normalfall eh immer komplett öffne.

[dultaffe]

jaydee73
Ich habe die gleiche Konfiguration wie du. Also "Sommer Conex" und "Sommer Output OC". Aber das Output OC gibt mir doch nur ein definiertes "Garage ist auf"-Signal. Sobald der Antrieb aus seiner definierten Endlage herausfährt und das Tor beginnt zu schließen, dann bekommst ich keine Rückmeldung mehr. D.h. um sicher zu sein, dass das Tor wirklich komplett zu und nicht irgendwo hängen geblieben ist bräuchte ich noch einen Reedkontakt der mir sagt "Garage zu". Oder verstehe ich nur das Output OC Modul nicht?

[jaydee73]

Äh, ach so. Nee, das läuft bei mir anders. Ich habe mir zu dem Antrieb die beiden Module "Sommer Conex" und "Sommer Output OC" dazugekauft. Das Conex-Modul ist für die Torsteuerung zuständig und läuft auf zwei Aktorkanäle. Die "normale" Torsteuerung per Fernbedienung läuft natürlich weiterhin. Und das Output OC liefert den Torzustand und geht direkt auf einen Binäreingang. Das ist also sozusagen ein interner Reed-Kontakt des Antriebs.

[dultaffe]

Super. Vielen Dank.

Kann ich dich noch fragen wo du deine Reedkontakte bei deinem Antrieb/Tor installiert und welche Kontakte du verwendet hast?
Das wars jetzt aber mit meinen Fragen.

[jaydee73]

So sieht sie aus. Ist zwar noch nicht Abend, aber du hast bestimmt nix dagegen.

Torsteuerung.JPG

Oben ist der Part für die Auf/Ab-Steuerung. Von links kommt die GA der Rolladenkachel rein. Und rechts gehen dann die Werte für die Torsteuerungs-GAs raus.

Und unten ist der Part für die Status-Anzeige mit Umrechnung auf % und Ausgeben auf den entsprechenden Status-Wert der Rolladenkachel. Da kommt links der Status vom Binäreingang rein und rechts der Status-Wert für die Rolladenkachel raus.

[dultaffe]

jaydee73
Danke schon mal. Bin schon gespannt, wie deine Logik aussieht.

Gruß
dultaffe

[jaydee73]

Ja, der Status hängt bei mir auf einem Binäreingang. Ich habe das dann in der Logik von einem 0/1 des Binäreingangs auf ein 0%/100% umgebogen, damit bediene ich die Status-GA der Rolladenkachel. Damit zeigt mir die Kachel durch den leuchtenden Punkt immer an, ob das Tor zu ist oder auf. Und dazu die Prozentangabe. Zwischen-Stati (z. B. 20% oder so...) gehen so natürlich nicht.

Logik-Screenshot kann ich dir heute Abend reinstellen.

Vorher hatte ich eine Kachel für Auf, eine für Ab und noch eine für den Status. Jetzt ist alles schick auf einer Rolladenkachel.

[dultaffe]

jaydee73
Ja, bei mir ist die Situation genau wie bei dir. Ich habe auch einen Sommer Antrieb und beide reagieren bei 1 mit einem Fahrbefehl.
Kannst du mir bitte mal einen Screenshot deiner Logik machen bzw. im Detail erklären wie du das über eine Logik gelöst hast.
Frägst du den Status des Tors auch ab (auf/zu) und visualisierst dies auch in der X1 Kachel.

Danke schon mal.

[jaydee73]

Für den Fall, dass das nicht wie von beib beschrieben ist, musst du selbst eine Logik dafür bauen.

Bei meinem Antrieb (Sommer) gibt es eine KO für auf und eine weitere für ab, beide reagieren bei 1 mit einem Fahrbefehl. Also nicht so simpel mit einem Objekt lösbar. Dazu kommt noch, dass der Status noch über ein weiteres KO läuft. Dafür gab es kein fertiges Visu-Element. ;-)

Die Herausforderung war also, drei KO auf eine Kachel zu bringen. Dafür habe ich mir eine Logik gebaut und den Ausgang dann auf eine Rolladenkachel gelegt.

[beib]

Ich habe bei mir eine 2-Taster-Lösung installiert. D.h. ein Taster für auf und ein Taster für ab. Diese frage ich natürlich mit 2 Kommunikationsabjekten ab.
Muss ich jetzt wirklich beim X1 zwei seperate Taster in der Visu anlegen, damit ich meine Lösung umsetzten kann?
Oder gibt es dort ein Visu-Element dem ich beide KOs bzw. die Gruppenadressen zuweisen kann und somit nur ein Visu-Element habe?

Danke schon mal für eure Hilfe.

Gruß
dultaffe

Hi ... wenn der Auf-Taster 1 sendet und der AB Taster 0 ... dann reichen 1 Adresse und 1 Objekt in der Visu.

(habe zwar kein el. Garagentor, aber mental sehe ich das wie Rollade und würde sogar einen Jalousieaktor dafür nehmen)

Grüße
beib