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.
OK, Kommando zurück. Ich natürlich auch. Habe mich vorhin gründlich vertan, da ich in einem Test-Setup die %-Ausgänge via Telegram weiterverarbeitet habe und die anderen Ausgänge in diesem Szenario gar nicht verdrahtet sind.
Ich habe sonst keine Probleme mit dem (MDT) Jalousie-Aktor, verwende aber normalerweise auch keine absoluten Positionsbefehle. Es kann also durchaus sein, dass die Winkel-Settings im Aktor noch nicht korrekt sind.
Hi, ich bin mir ziemlich sicher, dass der Großteil deiner Probleme in der obigen Aussage liegen! Ich habe seiner Zeit sehr viel Zeit investiert, bis die absoluten Positionsbefehle endlich korrekt funktioniert haben. Ich empfehle dir dringend, zuerst mal das saubere Verfahren auf vorgegebene Positionen hinzubekommen, bevor du tiefer in Logiken mit dem Baustein einsteigst. Wenn die vom LBS ermittelten Positionen vom Aktor nicht korrekt umgesetzt werden, wirst du auf Kurz oder Lang ständig Probleme bekommen. Die Ab- und Auffahrtszeiten kann man noch relativ einfach mit Stoppuhr messen, bei den Lamellen habe ich da schon länger gebraucht und viel mit Stepanzahl und Lamellenwendungszeiten gespielt, immerhin passen die Werte dann auf die meisten Jalousien, sobald man sie einmal ermittelt hat. Ein sinnvoller Test nach Konfiguration ist dann z.B. die Lamellen auf 20, 40, 60, 80 und wieder auf 20 % zu fahren. Wenn du danach die Lamellen auf 100% fährst, dürfen sie sich nach einem anschließenden Kurzzeit (Schließ-)Befehl gar nicht mehr bewegen. Falls doch, dann einfach weiter mit den Werten spielen...
Hi, ich bin mir ziemlich sicher, dass der Großteil deiner Probleme in der obigen Aussage liegen! Ich habe seiner Zeit sehr viel Zeit investiert, bis die absoluten Positionsbefehle endlich korrekt funktioniert haben. Ich empfehle dir dringend, zuerst mal das saubere Verfahren auf vorgegebene Positionen hinzubekommen, bevor du tiefer in Logiken mit dem Baustein einsteigst. Wenn die vom LBS ermittelten Positionen vom Aktor nicht korrekt umgesetzt werden, wirst du auf Kurz oder Lang ständig Probleme bekommen. Die Ab- und Auffahrtszeiten kann man noch relativ einfach mit Stoppuhr messen, bei den Lamellen habe ich da schon länger gebraucht und viel mit Stepanzahl und Lamellenwendungszeiten gespielt, immerhin passen die Werte dann auf die meisten Jalousien, sobald man sie einmal ermittelt hat. Ein sinnvoller Test nach Konfiguration ist dann z.B. die Lamellen auf 20, 40, 60, 80 und wieder auf 20 % zu fahren. Wenn du danach die Lamellen auf 100% fährst, dürfen sie sich nach einem anschließenden Kurzzeit (Schließ-)Befehl gar nicht mehr bewegen. Falls doch, dann einfach weiter mit den Werten spielen...
Danke für die Infos. Was mich etwas irritiert: Der LBS kann z.B. bei der Dämmerungsschaltung den vorgegebenen Winkel korrekt anfahren. (Auch bei der Beschattung werden die Lamellen in kleinen Schritten nachgefahren.) Nur bei der Sperre gehen die Lamellen direkt in die geschlossene Position, obwohl ich 60% eingestellt habe.
Wahnsinnig viel (bezüglich Winkel) kann man gar nicht im Aktor definieren: ets_parameter.png
Eigentlich sind es nur die beiden gelb markierten Werte. Die anderen Werte habe ich angepasst (Verfahrzeit mit Stoppuhr, Umkehrpause gemäss Datenblatt)
Wie du aber schon geschrieben hast, wie soll man denn exakte Werte im ms-Bereich messen können?? Allein die Lamellenverstellzeit (noch der einfachere Messwert) ist schon schwierig zu messen. Ich hab da Zeiten zwischen 1,42 und 1,15 Sekunden, je nachdem wie schnell mein Finger war. Hab also 1200 (1,2 Sek.) eingegeben.
Gemäss MDT-Anleitung sollte man den (praktisch nicht messbaren) Schrittweiten-Wert aus der Gesamtlamellenverstellzeit berechnen. Dazu muss man eigentlich nur wissen, wieviele MAX Steps der Motor für eine Gesamtverstellung benötigt.
Ich dachte, ich könne dies mit dem Step-Befehl rausfinden, da dieser ja nichts mit % zu tun hat. Aber da ist nach 4 Steps die Lamelle schon zu.
Gebe ich aber in der ETS direkte absoluten Winkel-Prozente an (z.B. 1%, 2%, 3% etc.), dann scheint die Auflösung viel feiner zu sein. Ich komme dann auf ca. 10 Steps für eine komplette Verstellung. (was dann 120 ms pro Schrittweite sein müsste)
Aber selbst, wenn ich dies parametriere, kann ich in der ETS weiterhin nicht höher als 60% angeben. Also von 0-60% (alle 3%) bewegt sich die Lamelle. Dann ist sie zu. Alle Werte >60% bewirken nichts mehr. Schickt man z.B. von Ausgangslage 0% den Wert 70%, dann ist die Lamelle komplett zu.
ABER...im Aktor habe ich schon immer den Wert 70% für Position nach Fahrende gesetzt. D.h. schicke ich den Befehl zum Runterfahren der Jalousie, dann stellt sie sich am Ende automatisch noch auf 70% Winkel. Und das funktioniert! Es entspricht gefühlt einem 70% Winkel (wenn 100% ganz geschlossen wäre).
Schicke ich aber in der ETS 70%, dann ist sie komplett zu.
Wenn du danach die Lamellen auf 100% fährst, dürfen sie sich nach einem anschließenden Kurzzeit (Schließ-)Befehl gar nicht mehr bewegen.
Diesen Satz verstehe ich nicht ganz. Was meinst du mit einem Kurzzeit-Befehl? Einen Step-Befehl?
Problematisch an der ganzen Sache ist ja auch, dass man auch bei völlig geschlossenen oder geöffneten Winkel weiterhin Step-Befehle schicken kann. Dann bewegt sich halt einfach die Jalousie ein Schritt nach oben/unten, obwohl sich der Winkel der Lamelle dabei nicht mehr ändern.
rdeckard Überprüf mal ob die Eingänge und Ausgänge wirklich % oder Byte erwarten.
Ich hab auch ein paar MDT Aktoren aber nur für Rolläden und bin da auch schon drüber gestolpert das die Eingänge/Ausgänge da zum Teil etwas gemixt sind...
Eventuell auch nochmal in ETS prüfen welche DPT konfiguriert ist.
Wie du aber schon geschrieben hast, wie soll man denn exakte Werte im ms-Bereich messen können?? Allein die Lamellenverstellzeit (noch der einfachere Messwert) ist schon schwierig zu messen. Ich hab da Zeiten zwischen 1,42 und 1,15 Sekunden, je nachdem wie schnell mein Finger war. Hab also 1200 (1,2 Sek.) eingegeben.
Ich hab das mit Messen schnell aufgegeben. Einfach mal einen Wert einprogrammieren und dann mittels ETS/EDOMI immer die Werte 0/245 oder bei dir wahrscheinlich 0/95 bis die Lamellen bei 245/95 fast ganz zu sind.
By the way: Vielleicht schickst du die falschen Werte an den Aktor? Musst mal schauen was er an den Eingängen erwartet: 0-100 oder 0-255.
Hier aber was, was mit dem Baustein zu tun hat ;-)
Ich habe im Laufe des Tages den Sperrwinkel bei der Gartensitzplatztür auf 20% gesetzt, damit ich nicht mehr in mein Jalousie-Probleme komme, wo nichts mehr geht.
Habe das schon fast vergessen, bis ich vor 15 Min. gesehen habe, dass die Tür entriegelt war und die Jalousie korrekt auf 40% Höhe und (irgendein flacher Winkel) gesetzt war. Also hatte die Sperre wieder gegriffen (was korrekt war). Da jedoch die Fassade unterdessen nicht mehr im Sonnenbereich lag, waren die anderen Jalousien dieser Fassade bereits wieder hochgefahren. Nur die Sitzplatztür blieb (wegen der Sperre) auf ihrer Position. Soweit alles ok. (Obwohl man sich durchaus Gedanken machen könnte, wie man dies "optimieren" könnte).
Als ich dann die Tür verriegelt habe, hat die Sperraufhebung das erste Mal so funktioniert, wie gewünscht. D.h. die Jalousie ging SOFORT nach oben. Scheinbar haben die 20% Sperrwinkel das Problem gelöst, sodass die Jalousie zumindest wieder fährt. (Bis ich das grundlegende Problem gelöst habe, reicht mir dieser Workaround.)
ABER...als ich dann die Tür wieder geöffnet habe, war ich sehr erstaunt, dass die Sperrposition wieder angefahren wurde. Obwohl eigentlich die Fassade nicht mehr im Sonnenbereich lag und die Lux-Werte auch unterschritten sind.
Hier ein Screenshot, wie die Werte zurzeit aussehen: 1404_1.png
E13 Sperre ist aktiv (klar, wegen Türöffnung)
Die aktuellen Lux-Werte sind jedoch mit ca. 11700 weit unter den Schwellenwert von 30000. (Alle anderen Jalousien dieser Fassade sind längst hochgefahren)
Sollte in diesem Fall nicht die Sperre komplett ignoriert werden?
Die Sperre hat erst nix mit der Beschattung zu tun, die Beschattung wird nur von der Sperre überschrieben. Du musst bei Bedarf ne Eigenene Logik vor die Sperre bauen z.B. mit A2 (Beschattung ja/nein) und einer Sperre vor der Sperre
Hmm...ist die Beschattung aktiv, dann unterbricht die Sperre sie. Das ist doch der Sinn einer Sperre. Wird die Sperre wieder aufgehoben, wird die Beschattung fortgesetzt. Nur, wenn die Beschattung eigentlich bereits inaktiv wurde, weil während der Sperre die Werte unterschritten wurden, dann sollte doch nach der Sperraufhebung nichts mehr passieren (Beschattung ist ja inaktiv). So mein Verständnis.
Könnte es daran liegen, dass während der Sperre A10 aktiv war und dies dann bei E11 als Initialwert mitgegeben wird? Ein Loop sozusagen...oder wird E11 wirklich nur bei Neuaktivierung ausgelesen und nicht beim Zurückkehren aus einer Sperre?
Wird die Sperre wieder aufgehoben, wird die Beschattung fortgesetzt. Nur, wenn die Beschattung eigentlich bereits inaktiv wurde, weil während der Sperre die Werte unterschritten wurden, dann sollte doch nach der Sperraufhebung nichts mehr passieren (Beschattung ist ja inaktiv). So mein Verständnis.
Wie das zusammen hängt und dass das nicht so einfach zu lösen ist, habe ich doch in #315 bereits geschrieben.
Könnte es daran liegen, dass während der Sperre A10 aktiv war und dies dann bei E11 als Initialwert mitgegeben wird? Ein Loop sozusagen...oder wird E11 wirklich nur bei Neuaktivierung ausgelesen und nicht beim Zurückkehren aus einer Sperre?
E11 wird nur bei Neuaktivierung ausgelesen. Aber das ist ein super Hinweis! Ich muss mal überlegen, welche Auswirkungen es hat bzw. haben könnte, wenn man den aktuellen Status immer aus E11 nimmt und nicht intern merkt. Rein theoretisch sollte man dann den Baustein jederzeit in einen beliebigen Status versetzen können, vom welchem beim nächsten Lauf des LBS dann ausgegangen wird. Gute Idee!
Nein, ist es nicht. Der Sinn der Sperre ist, den Baustein zu sperren, egal was dieser gerade macht oder in welchem Zustand er sich befindet.
ok, musste 3x lesen, bis ich den feinen Unterschied zu mir erkannt habe.
D.h. die Sperrposition wird IMMER angefahren, auch wenn der Baustein eigentlich inaktiv ist (keine Beschattung, Jalousien sind hochgefahren). Das ist natürlich (zumindest für mich) sehr doof.
Dass die Sperre auch bei inaktiven Status wirkt, mag ja noch Sinn machen...aber dass die Sperrposition auch dann zieht, ist meiner Meinung nach schade.
Wäre es nicht möglich, über einen Parameter zu definieren, ob die Sperrposition nur bei aktiven Status wirkt?
Oder einfach (um nicht einen weiteren Eingang zu verschwenden)...gibt man die Sperrpositionen und Sperrwinkel als Minuszahlen an, wirken sie NUR bei aktiven Status. Positive Zahlen wirken wie jetzt (auf alle Stati, auch inaktiv). Wäre zumindest eine Idee und gäbe gewisse Flexibilität, ohne den Baustein äusserlich aufzublähen. (Sozusagen ein hidden Feature) ;-)
Dass die Sperre auch bei inaktiven Status wirkt, mag ja noch Sinn machen...aber dass die Sperrposition auch dann zieht, ist meiner Meinung nach schade.
Es gibt keinen "inaktiven" Status, da der LBS sich immer in irgendeinem Status befindet.
Wäre es nicht möglich, über einen Parameter zu definieren, ob die Sperrposition nur bei aktiven Status wirkt?
Oder einfach (um nicht einen weiteren Eingang zu verschwenden)...gibt man die Sperrpositionen und Sperrwinkel als Minuszahlen an, wirken sie NUR bei aktiven Status. Positive Zahlen wirken wie jetzt (auf alle Stati, auch inaktiv). Wäre zumindest eine Idee und gäbe gewisse Flexibilität, ohne den Baustein äusserlich aufzublähen. (Sozusagen ein hidden Feature) ;-)
Nein, das macht in dieser Form überhaupt keinen Sinn und würde die Logik des LBS nur völlig unnötig aufblasen. Ich seh' schon den nächsten kommen, der dann für die Dämmerung wieder anderes Verhalten der Sperre haben will. Nein, das wird es nicht geben.
Der springende Punkt ist, dass der Beschattungs-LBS nicht dafür gedacht ist, sämtliche mehr oder weniger sinnvollen Sonderfälle abzuhandeln. Der Beschattungs-LBS soll und wird sich ausschliesslich um die Steuerung des Behangs kümmern. Das was Du willst wird über Vorschaltbausteine resp. über den noch kommenden Beschattungsparameter-LBS abgehandelt werden können, siehe den entsprechenden Thread hier. Mit einem Vorschalt-LBS werden nun je nach gerade gewünschtem Anwendungsfall die Eingänge des Beschattungs-LBS modifiziert, so dass dieser aus seiner Sicht weiter seine Arbeit verrichten kann.
ich habe Version 3.3 RC3 gleich mal für die Kinderzimmer installiert und muss feststellen, dass das mit der Sperre leider nicht richtig arbeitet:
18:42 Sperre an, die Rollos fahren auf die gewünschte Sperrposition - super!
20:18 Dämmerung - die gesperrten Rollos bleiben wo sie sollen - super!
um 20:49 es kommt bei mir ein Update der Außentemperatur, daraus errechne ich "Beschattung ist nötig = 0" und schreibe auf den Eingang E40 eine 0. Zu diesem Zeitpunkt ist bereits Dämmerung und trotz Sperre sind die Rollos hochgefahren - das ist ungünstig!
Ich sehe folgende Fehler:
- während der Dämmerung darf "Beschattung ein/aus" nichts auslösen
- während der Sperre darf nichts passieren
Ich hoffe das ist genau genug damit man das Problem nachvollziehen kann?
um 20:49 es kommt bei mir ein Update der Außentemperatur, daraus errechne ich "Beschattung ist nötig = 0" und schreibe auf den Eingang E40 eine 0. Zu diesem Zeitpunkt ist bereits Dämmerung und trotz Sperre sind die Rollos hochgefahren - das ist ungünstig!
Mit hochgefahren meinst Du, sie sind auf die Position von E48/E49, also nach Beschattung gefahren, ja? Das ist auf jeden Fall ein Bug, konnte ich eben hier nachstellen.
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.
Kommentar