X1: Licht per Zeituhr einschalten, wenn nicht bereits eingeschaltet

[RalfR]

Ich möchte folgendes realisieren: Per Zeitschaltung soll das X1 Licht im Büro einschalten aber nur, wenn es nicht schon eingeschaltet ist. Hintergrund: Es handelt sich um dimmbare Leuchten und ich möchte vermeiden, dass die zeitgesteuerte Einschaltung einen eventuell vorher manuell eingeschalteten Dimmwert überschreibt.

Ich habe dazu die folgende Logik aufgebaut und frage mich ob das a) aus Eurer Sicht funktioniert und b) der "richtige" Weg ist:

LENOVO-X1-RR_Ethernet-2.png

Eingang 1: Variabler, X1-interner Datenpunkt, Binärwert, wird von einer X1 Zeituhr bei Sonnenuntergang auf 1 gesetzt.
Eingang 2: KNX-Datenpunkt. Es handelt sich hier um die Schalt-GA der Lichgruppe 1.
Eingang 3: KNX-Datenpunkt. Es handelt sich hier um die Schalt-GA der Lichtgruppe 2.

Eingang 1 ist typ-konvertiert. Eingang 2 und 3 sind invertiert.

Mein Verständnis: Das UND-Gatter sendet auf dem Ausgang 1 wenn alle Eingänge 1 sind. Da ich Eingang 2 und 3 invertiere, sendet das UND-Gatter also eine 1 wenn a) die Zeitschaltuhr auslöst und b) Eingang 2 und Eingang 3 ausgeschaltet sind (invertiert also 1).

Passt das aus Eurer Sicht?

Ich habe dazu eine weitere Verständnisfrage: Ich habe bei Eingang 2 und Eingang 3 als KNX-Datenpunkt die Schalt-GA verwendet. Eigentlich möchte ich aber wahrscheinlich die Rückmelde-Adresse nutzen, weil darin doch der Status kodiert ist, oder? Nun ist es beim X1 aber so, dass man Rückmelde-Adressen dem Schalt-Datenpunkt zuweist, sie tauchen also eigentlich als eigene Datenpunkte gar nicht auf. Ist die Logik schlau genug, die RM-Adresse aus dem Datenpunkt zu nehmen? Oder muss ich die RM-Adressen als separate Datenpunkte den Datenpunkten des X1 hinzufügen?

[hyman]

Mein Verständnis: Das UND-Gatter sendet auf dem Ausgang 1 wenn alle Eingänge 1 sind. Da ich Eingang 2 und 3 invertiere, sendet das UND-Gatter also eine 1 wenn a) die Zeitschaltuhr auslöst und b) Eingang 2 und Eingang 3 ausgeschaltet sind (invertiert also 1).

... und dann gehen die an, worauf das UND-Gatter zwei Eingänge auf false gesetzt bekommt und sie wieder aus schaltet ... da muss noch ein Filter hin, der das verhindert. Einfacher lässt sich das Ganze vermutlich mit einer Sperre realisieren.

Warum soll das Licht eigentlich an gehen, wenn keiner da ist? Und wie schaltest Du es wieder aus?

Ich habe dazu eine weitere Verständnisfrage: Ich habe bei Eingang 2 und Eingang 3 als KNX-Datenpunkt die Schalt-GA verwendet. Eigentlich möchte ich aber wahrscheinlich die Rückmelde-Adresse nutzen, weil darin doch der Status kodiert ist, oder? Nun ist es beim X1 aber so, dass man Rückmelde-Adressen dem Schalt-Datenpunkt zuweist, sie tauchen also eigentlich als eigene Datenpunkte gar nicht auf. Ist die Logik schlau genug, die RM-Adresse aus dem Datenpunkt zu nehmen? Oder muss ich die RM-Adressen als separate Datenpunkte den Datenpunkten des X1 hinzufügen?

Wenn Du zwei verschiedene Adressen zum Schreiben und Lesen angibst, macht der X1 das auch so: Er schreibt nur auf die eine und liest nur von der anderen.

[RalfR]

... und dann gehen die an, worauf das UND-Gatter zwei Eingänge auf false gesetzt bekommt und sie wieder aus schaltet ... da muss noch ein Filter hin, der das verhindert. Einfacher lässt sich das Ganze vermutlich mit einer Sperre realisieren.

Warum soll das Licht eigentlich an gehen, wenn keiner da ist? Und wie schaltest Du es wieder aus?


Wenn Du zwei verschiedene Adressen zum Schreiben und Lesen angibst, macht der X1 das auch so: Er schreibt nur auf die eine und liest nur von der anderen.

Das habe ich zu spät gelesen. Tatsächlich hatte ich jetzt einen Flip-Flop, der das X1 abstürzen lassen hat. Es gibt beim X1 wohl keine Möglichkeit, Logiken anzuhalten. Es halft nur ein Werks-Reset, da die Inbetriebnahme auch nicht mehr möglich war. Da kann GIRA mal nachbessern.

Hast Du einen Tipp, wie ich das verhindere?

[concept]

Du weisst aber schon, was ein flip-flop ist, ja?

[RalfR]

Du weisst aber schon, was ein flip-flop ist, ja?

Ja klar. Ich hatte erst überlegt den Baustein RS-Flipflop zu nutzen, aber da hätte ich ja genau das gleiche Problem. Ich frage mich, ob ein Trigger am Eingang hilft, vermute aber nicht.

[hyman]

Das habe ich zu spät gelesen. Tatsächlich hatte ich jetzt einen Flip-Flop, der das X1 abstürzen lassen hat. Es gibt beim X1 wohl keine Möglichkeit, Logiken anzuhalten. Es halft nur ein Werks-Reset, da die Inbetriebnahme auch nicht mehr möglich war. Da kann GIRA mal nachbessern.

Nee, ein Flip-Flop ist das nicht, sondern eine Schleife, die schwingt. Meine Empfehlung wäre, wenn man Schleifen in die Logik baut, dass man die vor der Inbetriebnahme mal simuliert. Dabei muss man sich um die Rückkopplung von den Ausgängen auf die Eingänge aber selber kümmern...

Hast Du einen Tipp, wie ich das verhindere?

Steht doch da schon:

... da muss noch ein Filter hin, der das verhindert. Einfacher lässt sich das Ganze vermutlich mit einer Sperre realisieren.

Leztlich geht es Dir doch nur daraum, den Einschaltbefehl von der Schaltuhr dann zu unterdrücken, wenn bereits eingeschaltet ist. Genau das macht eine Sperre, wenn Du sie mit "Licht ist eingeschaltet" (die beiden negierten Eingänge ver-UND-et) aktiv schaltest.

Die Frage bleibt aber: Wie soll das Licht wieder ausgeschaltet werden? Auch mit der Zeitschaltuhr? Dann wird die Sperre das in bestimmten Fällen (nur eins der Lichter an) verhindern ...

[RalfR]

Leztlich geht es Dir doch nur daraum, den Einschaltbefehl von der Schaltuhr dann zu unterdrücken, wenn bereits eingeschaltet ist. Genau das macht eine Sperre, wenn Du sie mit "Licht ist eingeschaltet" aktiv schaltest.

Danke. Ich dachte es gäbe da vielleicht eine Art Sperr-Baustein. Ich würde jetzt einfach einen weiteren internen Datenpunkt quasi als boolsche Variable nutzen.

[Gast1961]

Danke. Ich dachte es gäbe da vielleicht eine Art Sperr-Baustein.

Gibt es auch, unter dem Namen "Sperre". Da kannst du deinen Lichtstatus draufgeben, um weitere Telegramme zu sperren.

[Beleuchtfix]

Hier zeigt sich auch wieder, dass die Grundlogik noch gar nicht durchdefiniert ist (Ein- und Ausschalten in den unterschiedlichsten Zuständen) sehr oft scheitert die Programmierung an den fehlenden Definitionen.
Gruß Florian

[RalfR]

Hier zeigt sich auch wieder, dass die Grundlogik noch gar nicht durchdefiniert ist (Ein- und Ausschalten in den unterschiedlichsten Zuständen) sehr oft scheitert die Programmierung an den fehlenden Definitionen.
Gruß Florian

Florian, Danke für den Hinweis. Kannst Du das ausführen? Was genau meinst Du? Tatsächlich braucht es insgesamt nur sehr wenig Logik. Das Meiste läßt sich mit KNX Grundfunktionen bewerkstelligen. Was genau meinst Du mit fehlenden Definitionen?

[Beleuchtfix]

War eine sehr allgemeine Antwort - heißt nicht zwangsläufig, dass dir das nicht inzwischen klar ist. Wie schon oben beschrieben, was soll passieren:
Einschalten wenn Lampe aus
Einschalten, wenn eine Lampe an
Einschalten, wenn beide Lampe an
Ausschalten manuel,
ausschalten über Zeitsteuerung.

Ich bemerke halt immer wieder, (auch bei mir) dass man meint, alles im Kopf zu haben, aber eben wichtige Variationen dann doch nicht bedenkt.
Gruß
Florian

[RalfR]

War eine sehr allgemeine Antwort - heißt nicht zwangsläufig, dass dir das nicht inzwischen klar ist. Wie schon oben beschrieben, was soll passieren:
Einschalten wenn Lampe aus
Einschalten, wenn eine Lampe an
Einschalten, wenn beide Lampe an
Ausschalten manuel,
ausschalten über Zeitsteuerung.

Ich bemerke halt immer wieder, (auch bei mir) dass man meint, alles im Kopf zu haben, aber eben wichtige Variationen dann doch nicht bedenkt.
Gruß
Florian

Vielen Dank für die Ergänzung und das Verständnis. Im konkreten Fall ist mir schon recht klar, was ich will. :-) Es hapert ein wenig an der Umsetzung, was aber zumindest teilweise auch an der noch immer leider sehr spartanischen Dokumentation von Gira liegt. Der Hilfe zum GPA hätte eine Einführung in Logiken durchaus gut gestanden. Ich meine damit nicht eine Erklärung für absolute Newbies, aber einige technische Fragestellungen könnte Gira einfach auch proaktiv beantworten.

Beispiel: Bausteine mit Trigger reagieren auch auf Telegramme, wenn der Trigger nicht passiert. Sie reagieren quasi nur zusätzlich aktiv, wenn man triggert. Sowas könnte einfach auch in der Hilfe stehen. Ansonsten muss man es erraten.

Ich beschäftige mich jetzt schon recht lange intensiv mit KNX (nicht als Profi oder System Integrator, aber als durchaus ambitionierter Heimanwender mit eigener ETS Pro Lizenz, Gira X1, S1 und HomeServer 3 und 4). Ich bin absoluter Überzeugungstäter finde aber dass die schwergängige Dokumentation dem Ökosystem allgemein nicht gut tun. Böse Zungen behaupten, das sei Strategie, damit die System Integratoren Geld verdienen können, ich halte das aber für Quatsch (in der Sache und auch als Ansatz).

Was auch gar nicht passieren darf: Dass man sich per Konfiguration ein System "abschießt". Dass das X1 in einer durch Logik erzeugten Schleife so unresponsiv wird, dass man selbst mit dem GPA die Logik nicht mehr deaktivieren kann, ist ein echter Bug. Das X1 müsste bei zu viel RAM / CPU Last einfach alle Logiken stoppen und eine entsprechende Warnung ausgeben. Wie gesagt, bei mir ging es nur über: Vom Bus trennen, Factory Reset, alles einmal neu machen. Wäre ich über Fernwartung aufgeschaltet gewesen, hätte ich ein riesiges Problem gehabt.

Anyway: Ich denke mit einer Sperre werde ich mein konkretes Problem lösen.

[Beleuchtfix]

Böse Zungen behaupten, das sei Strategie, damit die System Integratoren Geld verdienen können

Damit könnte man auch gut die SIs vergraulen. Aber Elektriker und auch Programmierer sind selten Schriftsteller. komischer Weise versteht man ja auch meistens, was man da als Programm erschaffen hat und kann sich schwer die Probleme vorstellen, die ein anderer damit haben könnte.
Gruß
Florian