Rollladensteuerung mit Gira X1

[Beleuchtfix]

So wie ich das sehe, kann hinten nur etwas ankommen, wenn ein Wechsel von 1 uf 0 in der Helligkeit stattfindet, ansonsten hast du kein Send bei Change. Kann es sich da um ein Timingproblem handeln, dass die Sperre noch nicht wieder abgeschaltet hat. Ich würde es jetzt einmal mit einem Signalverzögerer versuchen und den im oberen Strang einbauen. Vielleicht musst du es auch mal im Real Life testen, die Simulation finde ich nicht immer so prickelnd.
Viel Erfolg
Florian

[knxPaul]

habe ich an den Symbolen am Ausgang gesehen ..... das macht man wie?

Das ist der einfache Teil: Auf dem Ausgangspunkt rechte Maustaste drücken und wählen; das geht auch mehrfach.

Was kann man denn da bitte noch falsch machen?

Der Schwellwertschalter ist als Dämmerungsschalter gedacht, bitte in der Simulation zuerst ohne Sperre kontrollieren:

• Wenn es hell ist, also über dem oberen Grenzwert, dann ist der Ausgang '0'
• In der Dämmerung muss der Eingangswert unter die untere Grenze fallen, so dass der Ausgang eine '1' sendet und den Rollo fährt.
• Wenn die Helligkeit schwankt und wieder größer als der unteren Grenzwert wird, passiert nichts
• Erst wenn es wieder Tag wird und die Helligkeit über den oberen Grenzwert steigt, wird der Ausgang '0'.
  Wenn die Raffstores nicht von Hand hochgefahren werden, bleiben sie in meiner Simulation unten.
• Nun ist die Ausgangsbedingung erreicht und es kann wieder Nacht werden. Da wird dann auf 20 % gefahren.

Ja, ich wurde aufgefordert, nicht fertige Lösungen, sondern Hilfe beim Lernen zu bringen - also Geduld 👨🔧👨💻🤴

[HomeHaus]

...kann hinten nur etwas ankommen, wenn ein Wechsel von 1 uf 0 in der Helligkeit stattfindet...

Exakt, so war das gedacht. Nur wenn es dunkel wird, sollen die Rollladen ein Kommando bekommen.

...Ich würde es jetzt einmal mit einem Signalverzögerer versuchen...

Werde ich versuchen, danke für den Tipp. Wenn ich die Sperre manuell aktiviere oder deaktiviere tut sie genau, was sie tun soll. Nur, wenn sie automatisch gesteuert laufen soll, funktioniert es in der Simulation nicht mehr.

Auf dem Ausgangspunkt rechte Maustaste drücken....

Geile Erfindung, diese rechte Maustaste.... 😉, vielen Dank! Auch mein Logikblatt sieht nun schlanker aus. 😎

Der Schwellwertschalter ist als Dämmerungsschalter gedacht, bitte in der Simulation zuerst ohne Sperre kontrollieren

Ohne die Sperre läuft es sowohl in der Simulation als auch in der Realität - nur, dass halt morgens um 5 die Rollläden hochfahren (🙅).
Die Sperre soll das verhindern, so dass morgens alles erst erst nach dem Aufstehen per Sprachkommando - also quasi manuell - passiert.

• Wenn es hell ist, also über dem oberen Grenzwert, dann ist der Ausgang '0'
• In der Dämmerung muss der Eingangswert unter die untere Grenze fallen, so dass der Ausgang eine '1' sendet und den Rollo fährt.
• Wenn die Helligkeit schwankt und wieder größer als der unteren Grenzwert wird, passiert nichts

Wenn ich die Doku richtig verstanden habe, wird erst ein Wert gesendet, wenn der Wechsel von HELL nach DUNKEL erfolgt, oder? Also das Unterschreiten des unteren Schwellwerts, ohne dass der obere nochmal überschritten wird - dann wird eine 0 gesendet, die ich mit dem Inverter in eine 1 umkehre, die dann als Kommando an die Rollläden gegeben wird, um herunterzufahren.

• Erst wenn es wieder Tag wird und die Helligkeit über den oberen Grenzwert steigt, wird der Ausgang '0'.
  Wenn die Raffstores nicht von Hand hochgefahren werden, bleiben sie in meiner Simulation unten.

🤔, genau das ist bei mir eben nicht der Fall. Zumindest nicht in der Simulation. Die Chance das in Produktion zu testen, habe ich heute leider vertan. Es ist dunkel.
Habe ich eine Sperre drin, die von Schwellwertschalter aktiviert bzw. deaktiviert wird, passiert in der Simulation gar nichts. Beim Rollladen-Ausgang am Ende kommt nichts an. Und ....der Ausgang ist bei nur nach dem Inverter '0', oder? Wenn es heller wird, sendet der Schwellwertschalter doch eigentlich eine 1.... meine ich ....

Ich test jetzt mal das mit der Verzögerung.

Ja, ich wurde aufgefordert, nicht fertige Lösungen, sondern Hilfe beim Lernen zu bringen - also Geduld 👨🔧👨💻🤴

Absolut, auch vielen Dank dafür. Die Lösung sollte zwar ein Ergebnis sein, aber das des eigenen Lernens und Verstehens.... bin dabei!

[HomeHaus]

Beleuchtfix also, um Timingprobleme zu verhindern, hatte ich extra die Aktivierung der Sperre nach vorne gezogen und den Wert erst später in die Sperre gegeben - ABER: es scheint wirklich ein Timingproblem zu sein. Jetzt sorgt ein Verzögerer dafür, dass zwischen Aktivierung der Sperre und der Wertübergabe 1s vergeht und in der Simulation scheint es zu funktionieren. Morgen dann mal schauen, was im realen Leben passiert .....
Habe es zu besseren Transparenz jetzt nochmal auseinander gezogen .....

Sperre3.JPG

[knxPaul]

genau das ist bei mir eben nicht der Fall. Zumindest nicht in der Simulation

Wenn Deine und meine Simulation unterschiedliche Ergebnisse bringen, dann ist das kein Zufall, das liegt auch nicht an .....


..... sondern an unterschiedlichen Schaltungen: in #25 gab es einen Wertgenerator ganz am Ende vor dem Ausgang; ich habe immer noch Schaltung #29; aber in #30 ging der Wertgenerator "verloren". Damals habe ich mir nicht viel dabei gedacht, aber jetzt ...

Die Lösung sollte zwar ein Ergebnis sein, aber das des eigenen Lernens und Verstehens.... bin dabei!

Super - dann gleich ein Bonus-Zuschlag:

Es gibt oft mehrere Lösungen: Die Sperre kann auch gegen einen Filter ausgetauscht werden: Ein-Operator := Aus und Aus-Operator := Nichts
damit kann definitiv nur 'Ab' gefahren werden; es fehlt die ursprüngliche 20 % Position.

[HomeHaus]

es fehlt die ursprüngliche 20 % Position.

Die hatte ich erst mal rausgenommen um die Komplexität zu reduzieren, da sie zur Lösung des Problems nicht beigetragen hat.

Jetzt sieht es so aus und zumindest in der Simulation tut es das, was es tun soll🤗. Morgen Abend und übermorgen früh weiß ich dann, wie es in der Praxis aussieht 😉

Sperre4.JPG

[Heiko71]

Oh je, ich war zu langsam 😢
Mit Oder-Gatter wird das Telegramm für das Hochfahren auf beide GAs gesendet; die gewünschte Trennung wird nur mit einem dritten Filter funktionieren:
GPA_Rollo_auf_ab.png

meine Rollladensteuerung Abends bei Unterschreitung einer gewissen Helligkeit runterfahren und morgens bei allen Räumen wo keine Schlafräume sind bei Überschreitung der Helligkeitsschwelle wieder hochfahren. Die Schlafräume werden per Zeitschaltuhr zu unterschiedlichen Zeiten hochgefahren.

Jetzt habe ich aber das Problem, dass sobald ich etwas im X1 geändert habe und ihn aktualisiere beziehungsweise eine Inbetriebnahme vornehme, im Anschluss die Rollläden den ersten Zyklus nicht mitmachen. Sprich ich mach am Tag eine Aktualisierung/Inbetriebnahme und abends fahren die Rollläden nicht runter. Fahre ich sie von Hand runter funktioniert ab dem nächsten morgen alles normal. Lasse ich sie oben fahren die Rollläden welche helligkeitsabhänging (nicht die Schlafräume) hochfahren sollen runter und kurz drauf wieder hoch.

Kann man dies irgendwie umgehen, dass sie quasi am Abend schon das am herunterfahren mitspielen?
Oder woher kommt dies überhaupt?


VG Heiko

[Beleuchtfix]

Wahrscheinlich Fehlt deiner Logik noch ein Eingangsstatus, der erst nach der nächsten Änderung vorhanden ist.
Viel Erfolg, Florian

[knxPaul]

Jetzt habe ich aber das Problem, dass sobald ich etwas im X1 geändert habe und ihn aktualisiere beziehungsweise eine Inbetriebnahme vornehme, im Anschluss die Rollläden den ersten Zyklus nicht mitmachen.

Beim Neustart versucht der X1, alle Eingangswerte durch Leseanfragen am Bus zu initialisieren. Bei der Zeitschaltuhr / Funktionsuhr bekommt das GroupValueRead kein GroupValueResponse, wenn die Uhr nicht am KNX-Bus, sondern im X1 sitzt 😯🤐

Als Abhilfe gibt es bei jedem Datenpunkt bei den Eigenschaften die Einstellmöglichkeit für einen Initialwert:

• Vorgabewert := 'Tag' - in meinem Bild ist das eine '1'

Was ich selbst nicht ausprobiert habe:

• Initialwert := Kein
• Wert beibehalten angehakt

Dann wird der Wert des Datenpunktes X1-intern zwischengespeichert und bleibt auch nach dem Neustart des Gerätes erhalten. Die Anzahl der Speichervorgänge ist aber hardwaremäßig begrenzt und eine übermäßige Nutzung bedeutet eine Verringerung der Lebensdauer des X1.

[Beleuchtfix]

und eine übermäßige Nutzung bedeutet eine Verringerung der Lebensdauer des X1.

Oder zu viel Spielerei am X1
Gruß Florian

[bavarianhias]

Sorry off-topic:

übermäßige Nutzung

zu viel Spielerei

heißt das, der X1 lebt weniger lang, wenn ich oft - egal ob über GPA oder ETS - Applikationsdaten schreibe?

[knxPaul]

Je nachdem, was mit Applikationsdaten gemeint ist:

1. GA Telegramme werden flüchtig gespeichert ohne Einfluss auf die Lebensdauer.
2. Applikationsprogramm von der ETS und Projekt vom GPA geschrieben werden dauerhaft gespeichert, also in Flash.

Einzig das Speichern in Flash-Speicher mit einer begrenzte Lebensdauer zählt. Das gilt für alle Geräte. Die Größenordnung an Lösch- und Speichervorgängen ist größer als 10.000.
Problematisch wird das erst, wenn im Betrieb jede Änderung des Wertes im Datenpunkt remanent gespeichert gespeichert wird. Das macht der X1 so, um jederzeit für den Fall des Spannungsverlustes vorbereitet zu sein.

[bavarianhias]

Sorry,off-topic- Trotzdem Danke für die Aufklärung
Also meine KNX Anlage ist jetzt ein halbes Jahr alt und ich habe nur den X1 als Interface. Habe bestimmt schonn 1000 mal geflasht (GPA und ETS Applikationsdaten geschrieben). Da hab ich die 10.000 bald erreicht. Find ich ein bisschen wenig, wenn ich danach Angst haben muss, dass mein X1 bald den Geist aufgibt.

[knxPaul]

Neuere oder bessere Flash Bausteine schaffen auch 100.000 bis 1.000.000 Zyklen, aber nur Gira weiss, welcher Typ verbaut wurde ... und der kann im Lauf der Zeit ausgetauscht = verbessert werden.

[HomeHaus]

Jetzt sieht es so aus und zumindest in der Simulation tut es das, was es tun soll🤗. Morgen Abend und übermorgen früh weiß ich dann, wie es in der Praxis aussieht 😉

Darf man seinen eigenen Post zitieren? 🤔 Egal, da bin ich wieder. Es hat fast geklappt - und ich bin inzwischen nach zahllosen Versuchen recht ratlos, weshalb nur fast.

Da knxPaul mich so nett ans Händchen genommen hat, stellen sich meine Raffstores nun bei 500lx von waagerecht auf halbgeschlossen und anschließend bei 100lx von halbgeschlossen auf geschlossen. Die Filter verhindern, dass sie morgens mit Sonnenaufgang wieder aufgehen und sie warten auf manuelle Bedienung. 👍

Raffstores.JPG

Dieselbe Logik habe ich nun versucht auf die Rollläden zweier Räume zu übertragen. Nur dass ich dabei nicht die Lamellenneigung einstellen wollte, sondern einmal einen Behangwert von 60% bei 500lx (wie bei den Raffstores) mit anschließendem Zufahren bei 40lx. Das sieht dann so aus:

OG.JPG

Was passiert? Bei 500lx fahren beide Rollläden runter und stoppen bei .... nein, nicht bei 60% (Wert des Wertgenerators), sondern bei.... 70% 😖 - laut Gira App. Nicht nur, dass es hätten 60 sein sollen, der eine hat eine Stellung, die ungefähr 70% entspricht, der andere etwa 75%. Angezeigt werden in der App aber bei beiden 70%. Beide sind nebeneinander. Unterschied etwa 5cm. Quasi jedes Mal - aber mal ist der linke höher, mal der rechte. 😵
Lasse ich sie beide manuelle per App von oben auf 60 oder auch auf 70% fahren sind beide ziemlich gleich.

Woran kann das liegen? Ist der Wert, den der Wertgenerator übergibt vielleicht kein % Wert für den Behangwert?