Wenn dies dein erster Besuch hier ist, lies bitte zuerst die Hilfe - Häufig gestellte Fragen durch. Du musst dich vermutlich registrieren, bevor du Beiträge verfassen kannst. Klicke oben auf 'Registrieren', um den Registrierungsprozess zu starten. Du kannst auch jetzt schon Beiträge lesen. Suche dir einfach das Forum aus, das dich am meisten interessiert.
Ich kann nicht beurteilen,ob dies für Raffstoren alles perfekt arbeitet, aber wäre es für Rollos nicht besser, zwei bis drei Helligkeits-Schwellen zu definieren, bei denen dann verschiedene (berechnete) Höhen angefahren werden? D.h. großer Lichtstreifen bei geringer Helligkeit, mittlerer Lichtstreifen bei mittlerer Helligkeit und kleiner Lichtstreifen bei kleiner Helligkeit.
Was meinst Du, bzw. die anderen Beta-Tester?
Moin,
das halte ich für eine gute Idee! Ich bin dafür
So, ich habe mich mal im Logikeditor ausgetobt, mit dem Vorschlag, den ich in Post #65 gemacht hatte. (Beschattung mit zwei Schwellen)
Es ist zwar nicht perfekt (keine Verriegelung untereinander, nicht alle Parameter auf LBS-Eingängen), aber die Funktion ist gegeben und ich habe sie derzeit an allen meinen Rolläden laufen.
Die Funktion umfasst (siehe Marierungen im Screenshot):
1. Späteste Uhrzeit am Morgen für "Rolladen hoch"
2. Früheste Uhrzeit am Morgen für "Rolladen hoch" oder Helligkeit
3. Rolladen runter per Helligkeit oder spätestens um x Uhr (für Sommer)
4. Beschattung: Rolladen hoch bei Unterschreitung Helligkeit und Ablauf von x Minuten
5. Beschattung: Rolladen Stufe 1, wenn Fassade in Sonne und Schwelle 1 überschritten (nach Ablauf von x Minuten)
6. Beschattung: Rolladen Stufe 2, wenn Fassade in Sonne und Schwelle 2 überschritten (nach Ablauf von x Minuten)
7. + 8: Hochfahren und Sperren bzw. Entsperren Rolladen beim Öffnen/Schließen des Fensters
habe ihn jetzt mal gestartet und ein wenig gespielt. Fürs erste funktioniert er tadellos, was die Beschattung anbelangt, nur knallt er dutzende Fehler in den Log :-) Auch die Sperre mit Zwangssteuerung funktioniert problemlos! Bis hierhin bin ich unglaublich begeistert.
Der Fehlercode ist nur ein Beispiel. Ist aber immer identisch.
EDIT: Wenn ich für irgendeine zukünftige Version mal einen Wunsch äußern dürfte...Könnte man nicht noch eine Zeitsteuerung einbauen in die Dämmerungssteuerung?! Bei uns ist es so, dass wir in den Wintermonaten ab Dunkelheit schließen, im Sommer aber spätestens um xy. Morgens genau so....Dies könnte sicherlich mit der Übergabe der Zeit an den Baustein mit integriert werden und würde meinen letzten manuellen Teil der Beschattung/Verdunkelung ersetzen :-)
Gar kein Problem, einfach Angewohnheit Fehler per Hardcopy zu übergeben. Werde versuchen dran zu denken beim kommenden Fehler den Text einzufügen
Super, danke. Damit ist nämlich die Fehlersuche einfach viel angenehmer! Der relevante Text kann dann einfach kopiert und danach gesucht werden anstatt erst genau abtippen zu müssen. Man ist ja schreibfaul. Zumindest ich tippe lieber etwas im Code und wenn's nur Kommentare sind...
Würdest du sagen, dass trotz der Altlast der Baustein problemlos funktionieren würde? Dann würde ich den Krempel gleich mal laufen lassen....
Schwierig zu sagen, da ich den Baustein mangels "echten" Rollos nur manuell testen resp. simulieren kann. Eigentlich sollte er fehlerfrei sein, da ich natürlich nicht wissentlich fehlerhaften Code veröffentliche. Aber wie Du oben selbst festgestellt hast, muss das nicht immer auch wirklich so sein. Ich würde mich freuen, wenn Du einen echten Test fahren würdest.
Hoppla, da ist wohl noch eine Altlast drin. Danke für die Info, ich schau's mir an...
PS: Ich werde nie verstehen, wie man Ausschnitte aus den Logs als Screenshot pasten kann!? Wo liegt das Problem, das als echten Text via C&P einzufügen?
Gar kein Problem, einfach Angewohnheit Fehler per Hardcopy zu übergeben. Werde versuchen dran zu denken beim kommenden Fehler den Text einzufügen
Würdest du sagen, dass trotz der Altlast der Baustein problemlos funktionieren würde? Dann würde ich den Krempel gleich mal laufen lassen....
Hab ihn gerade mal komplett bestückt und das Projekt neu aktiviert.
Leider mit unten stehendem Ergebnis :-(
Hoppla, da ist wohl noch eine Altlast drin. Danke für die Info, ich schau's mir an...
PS: Ich werde nie verstehen, wie man Ausschnitte aus den Logs als Screenshot pasten kann!? Wo liegt das Problem, das als echten Text via C&P einzufügen?
nachdem es beim LBS 19000145 - Beschattungssteuerung-NG eine ganze Reihe Umbauten und Verbesserungen gab, habe ich diese nun auch im Rollo-LBS nachgezogen. Hier im Anhang der erste RC der kommenden Version 0.6. Die Changes:
Macht wer jemand noch die Ansteuerung der Rollos über Fensterkontakt und Temp.?
Aktuell nutze ich es um das Rollo auf 80% zu fahren wenn das Rollo komplett geschlossen ist und das Fenster aufgeht.
Die Temp. nutze ich um das Rollo ein wenig aufzufahren wenn die Temp. für Zeit X unter dem Gefrierpunkt ist.
Schaltet ihr das vor den Baustein?
Oder gibt es vielleicht Überlegungen dies in den Baustein zu integrieren?
Wie ganz am Anfang des Threads geschrieben, basiert der Baustein auf dem "grossen" Beschattungs-LBS 19000145. Da wir hier auch noch bei einer 0.x-Version sind, ist der Baustein auch noch recht weit von einem fertig-Zustand weg.
Dieser Baustein hier ist für Rollos und Jalousien und gerade bei letzteren gibt es durchaus eine Durchsichtposition: Wenn diese auf Schlitz gefahrenen werden! Bei Rollos macht das natürlich keinen Sinn, es macht aber noch weniger Sinn, deshalb einen weiteren Baustein zu pflegen. Die nicht benötigten Funktionen können einfach ignoriert werden.
Es ist allerdings durchaus möglich, dass der LBS hier noch völlig falsch arbeitet. Das kann ich mangels entsprechendem Behang leider nur simulieren und in letzter Zeit hatte ich wenig Gelegenheit, mit der Implementierung zu widmen...
Alles gut, ich kann damit leben, dass es diesen Zwischenstatus gibt der zwar bei meinen Rollläden wenig Sinn macht aber auch nicht wirklich problematisch ist
Korrekt, das ist Absicht und wird auch so bleiben. Du kannst beim Änderungen an diesem Eingang den Baustein einfach via E1 triggern und hast das gleiche Resultat.
Das mache ich derzeit auch schon genau so. Wollte mir nur gerne die Klemme am E1 ersparen... ist aber auch so kein Problem
Das gesamte Ein-/Aus-/Sperre-Thema ist gerade in Diskussion und wird sich in einer zukünftigen Version des Bausteins vermutlich ändern. Siehe dazu den 19000145er Thread...
OK, habe mir mal den 145er Thread angesehen. Die Diskussion dort geht schon in die richtige Richtung (vorausgesetzt es geht in Richtung: "Sperre mit Zwangsposition" bzw. bei manuellem Verfahren --> "Sperre ohne Zwangsposition" statt "LBS Aus"; wobei der Baustein in beiden Fällen weiter im Hintergrund "mitrechnen" sollte)
Wieso? Ein/Aus ist ein oder aus und Sperre sperrt den Baustein. Wüsste nicht, was da nicht eindeutig ist...
Die Bezeichnungen der Ex und Ax ist jetzt wirklich nicht das größte Problem
Wenn allerdings "Ein/Aus" --> "Sperre ohne Zwangsposition" wird und die aktuelle "Sperre" --> "Sperre mit Zwangsposition" ist doch alles gut :-)
[*]Wozu dienen bei diesem Baustein die Eingänge E44 bzw. E54? Oder anders herum, sollte diese nicht entfernt werden, da es bei Rollos keine "Durchsichtsposition" gibt?
Wie ganz am Anfang des Threads geschrieben, basiert der Baustein auf dem "grossen" Beschattungs-LBS 19000145. Da wir hier auch noch bei einer 0.x-Version sind, ist der Baustein auch noch recht weit von einem fertig-Zustand weg.
Dieser Baustein hier ist für Rollos und Jalousien und gerade bei letzteren gibt es durchaus eine Durchsichtposition: Wenn diese auf Schlitz gefahrenen werden! Bei Rollos macht das natürlich keinen Sinn, es macht aber noch weniger Sinn, deshalb einen weiteren Baustein zu pflegen. Die nicht benötigten Funktionen können einfach ignoriert werden.
Es ist allerdings durchaus möglich, dass der LBS hier noch völlig falsch arbeitet. Das kann ich mangels entsprechendem Behang leider nur simulieren und in letzter Zeit hatte ich wenig Gelegenheit, mit der Implementierung zu widmen...
[*]Kann es sein, dass bei einer Änderung des Status an E30 (z.B. von 1 --> 0), die Ausgänge nicht refreshed werden (oder nur mit SendByChange)? --> Spricht etwas dagegen, bei einer Änderung an E30 alle Ausgänge (oder zumindest die Behanghöhe A3/A4) zu triggern?
Korrekt, das ist Absicht und wird auch so bleiben. Du kannst beim Änderungen an diesem Eingang den Baustein einfach via E1 triggern und hast das gleiche Resultat.
[*]Kann es sein, dass bei einer Änderung des Status an E11 (z.B. von 0 --> 1), die Ausgänge nicht refreshed werden (oder nur mit SendByChange)? --> Spricht etwas dagegen, bei einer Änderung an E11 alle Ausgänge (oder zumindest die Behanghöhe A3/A4) zu triggern?
Das gesamte Ein-/Aus-/Sperre-Thema ist gerade in Diskussion und wird sich in einer zukünftigen Version des Bausteins vermutlich ändern. Siehe dazu den 19000145er Thread...
[*]Um den Unterschied zwischen Sperre und Baustein ein/aus deutlicher zu machen: spricht etwas dagegen, "Bausteinsperre" in "Zwangsposition" umzubenennen? (E13 müsste dann "Höhe bei Zwangsposition" heißen)
Wieso? Ein/Aus ist ein oder aus und Sperre sperrt den Baustein. Wüsste nicht, was da nicht eindeutig ist...
Wir verarbeiten personenbezogene Daten über die Nutzer unserer Website mithilfe von Cookies und anderen Technologien, um unsere Dienste bereitzustellen. Weitere Informationen findest Du in unserer Datenschutzerklärung.
Indem Du unten auf "ICH stimme zu" klickst, stimmst Du unserer Datenschutzerklärung und unseren persönlichen Datenverarbeitungs- und Cookie-Praktiken zu, wie darin beschrieben. Du erkennst außerdem an, dass dieses Forum möglicherweise außerhalb Deines Landes gehostet wird und bist damit einverstanden, dass Deine Daten in dem Land, in dem dieses Forum gehostet wird, gesammelt, gespeichert und verarbeitet werden.
Einen Kommentar schreiben: