Bus-Profi Forum

Hi Bernd,

den Kommentar von Philipp unterstütze ich. Den Aufwand für die wenigen direkten Umschaltbefehle würde ich auch nicht treiben.

Das Problem ist, daß ich 4 Rolläden über 4 Summen in einem Modul schalte. D.h. wenn es Nacht wird, lösen alle 4 Summen nacheinander (!!!) den Befehl zum Runterfahren der 4 Rolläden aus.

Wenn ich das richtig verstehe, möchtest du den Fenstergriff (oder den Flügel - je nach Kontaktausführung) logisch mit dem Rolladen verknüpfen. Dann benötigst du in der Tat eine Einzelrolladen-bezogene Steuerung. Ganz schön viel Komfort, wobei ich da schon Schwierigkeiten auf dich zukommen sehe :-O :-O
So stelle ich zum Beispiel im Sommer nachts den Rolladen gerne auf drei Viertel, damit in der Sommerhitze die halbwegs kühle Nachtluft noch reinkommt, ohne daß ich dann morgens um 4 Uhr wach bin, weil mir die Sonne in die Augen scheint. Wenn du das ebenfalls automatisch abbilden möchtest, steigt der Aufwand noch mal beträchtlich an.

Mögliche Lösung: So aus dem Bauch heraus, würde ich dir aber die dynamischen Gruppen ans Herz legen. Dann kannst du nämlich einfach zwei Gruppen dynamisch definieren: Einmal die Rolläden mit geschlossenen Fenstern und einmal jene, wo ein Fenster offen ist. Als Resultat hättest du dann nur noch zwei Befehle für die Rolläden...

Gruß, Johannes

Hallo zusammen,

@Philip: Der Umschalt-Timer ist in der Tat nur einmal vorhanden (was ich von Uwe gelernt habe :-O ). Es kommt schonmal vor, daß mehrere Rolläden einen Richtungswechsel erfahren. Im Wohnzimmer z.B. gibt es einen Taster mit der Bezeichnung "Kino". Wenn man darauf drückt fahren u.a. alle Rolläden im Wohnzimmer runter. Sollte man sich verdrückt haben (was bei W schonmal vorkommt :-) ), dann führt ein anschliessender zweiter Tasten-Druck zum wieder-hochfahren der Rolläden (das sind immerhin 9 Stück) ...

@Niko: Die zeitliche Reihenfolge ist in der Tat nicht garantiert. Deshalb achte ich sehr genau darauf, daß ich als Erstbelegung einer Taste immer (Ent-)Sperr-Befehle ausführe und in der Schattenwelt dann den eigentlichen Befehl. Diese Reihenfolge wird auf dem Bus auf jedenfall eingehalten werden! Es kann ja nicht sein, daß die Kommandos der Erstbelegung und Zweitbelegung unterschiedliche Wege im Bus nehmen, so daß die Zweitbelegung das Ziel zuerst erreicht (ist ja schliesslich kein Internet :-O ).
Das mit der Sperre der D-Tasten wünsche ich mir übrigens auch !!! Da hatte ich mir schonmal die Karten gelegt: Alles schön geplant und schliesslich gemerkt, daß man D-Tasten nicht sperren kann :-( ...
Apropos "im Bus-Protokoll gesehen habe": Das kann ich wohl in meinem Leben nicht mehr analysieren :-( . Wenn ich alle Status-Kommandos wiederhole, ist das Bus-Fenster mit sovielen Meldungen zugemüllt, so daß ich den Baum vor lauter Wäldern nicht sehe (ähh umgekehrt natürlich), obwohl ich interne Befehle nichtmal in den Bus senden lasse!

@Johannes: Du hast leider recht. Drei-viertel-Stellungen sind nicht möglich. Dafür fahren meine Rolläden aber hoch, wenn das Fenster aufgeht und wieder runter beim Schliessen und wieder hoch beim ... :-O Der Komfort ist schon beträchtlich! Halbe Rolladen-Stellungen kann ich bei mir sowieso nur manuell einstellen, da ich keine Stromsensoren besitze. Vermisse ich auch nicht wirklich. Ich bin so ganz zufrieden. Um im Sommer luft rein zu lassen fahren meine Velux-Fenster im am Schlafzimmer angrenzenden Flur-Bereich auf ... da is dann nichts mit "Hell" am Morgen und Luft strömt auch genug rein.

Gruß, Bernd, der immer noch nach einer Lösung sucht ...

Das von Bernd beschriebene Problem, dass ein "Umschalt-Timer ist in der Tat nur einmal vorhanden (was ich von Uwe gelernt habe )" hatten wir im Herbst 2006 schon mal hier http://www.bus-profi.de/Forum/forum-scr ... php?id=513 diskutiert. Anscheinend gibt es dazu noch keinen Firmware-Update, der für jeden Rolladen einen extra Umschalt-Timer in die Module einbaut.

Philipp fragt dazu:

Ist das wirklich so, dass der Umschalttimer bei den Rolläden je Modul nur einmal zur Verfügung steht??
Kann ich fast gar nicht glauben, da sonst so gut wie jeder Gruppenbefehl an Rolläden (an Relais) diese Funktion "aushebeln" würde.

Bei EINEM(!) Befehl an eine Gruppe von Rolläden (an Relais) im gleichen Modul dürfte das kein Problem sein, da dann alle Rollladen gemeinsam die gleiche Umschaltzeit gebrauchen. Aber wenn INNERHALB(!) der Umschaltzeit andere Rollläden (an Relais) des gleichen Moduls einen Umschalt-Befehl erhalten, dann tritt das Problem auf. (Und bei Bernd feuern die vielen Summe KURZ nacheinander solche Umschaltbefehle an das gleiche Modul ab.)

Philipp, wo hast Du dann das her?

wie ich lernen musste ( ) ist eine direkte Umschaltung bei Rolläden wohl nicht problematisch (gabs in einem anderen Thread).

Das wäre mir neu(!) Es mag zwar Rollladen Motoren geben, die die Umschaltzeit intern selber garantieren - aber ansonsten dürfte es genügend Rolladenmotoren geben, die geschädigt würden.

[hr]

Die zeitliche Reihenfolge ist in der Tat nicht garantiert. .... Diese Reihenfolge wird auf dem Bus auf jedenfall eingehalten werden! Es kann ja nicht sein, daß die Kommandos der Erstbelegung und Zweitbelegung unterschiedliche Wege im Bus nehmen, so daß die Zweitbelegung das Ziel zuerst erreicht (ist ja schliesslich kein Internet ).

Bernd, hmm - naja: Ich denke, sobald die LCN-Informationen das Modul verlassen und auf den Bus gehen, ist auch die Reihenfolge von Erst- und Zweitbelegung NICHT mehr garantiert. In 99.9% der Fälle wird es wohl klappen und die Reihenfolge bleiben. Ich denke das Modul wird auch immer zuerst den Befehl der Erstbelegung raus schicken und dann erst die Zweitbelegung. Aber wenn der erste Befehl verloren geht (Signal schlecht oder Kollision auf dem Bus), könnte der zweite Befehl doch zuerst am Zielmodul richtig empfangen/verarbeitet werden. Das Sendemodul wird dann bei fehlender Quittung den ersten Befehl noch mal absenden; so dass er dann als zweites ankommt. ;-) So weit meine Theorie(!) Da müsste eigentlich von der Issendorff Firmware Front die korrekte Aussage geben können.

Wenn ich bei kritischen Abläufen sicher gehen will, dass der 1. Befehl auch zuerst ausgeführt wird, dann würde ich die Abfolge nur innerhalb des Zielmoduls machen oder eine sequentielle Kommunikation zwischen den Modulen machen:
Quelle Taste 1: Quelle an Ziel: Sende Taste1
Ziel Taste 1: Erstbelegung: Ziel an Ziel: 1. Befehl und Zweitbelegung: Ziel an Quelle: Sende Taste2
Quelle Taste 2: Quelle an Ziel: Sende Taste2
Ziel Taste 2: Erstbelegung: Ziel an Ziel: 2. Befehl und Zweitbelegung: Ziel an Quelle: Sende Taste3 ## Quittung

Gruß, Martin - der zur Lüftung bei Fensteröffnung auch gerne "Drei-viertel-Stellungen" pro Rollladen haben möchte (entweder durch LCN virtuelle Relais+Summen oder zur Not als IPS Komfort-Aufsatz)

Die Abarbeitung von Befehlen im Modul ist garantiert ...
1. Tabelle A Taste 1 kurz
2. Tabelle A Taste 1 lang
.
25. Tab.B ... usw. (wir habe das schon mehrfach diskutiert)
es wird IMMER zuerst die Erstbelegung ausgeführt und danach die Zweitbelegung ...

Auch bei den Modulen haben die mit kleinerer ID höhere Priorität (werden zuerst senden).

Wenn jetzt ein Gruppenbefehl einen "Schwall" auslöst, der "kreuz und quer" durch die IDs sendet ....

Wer Sicherheit will, sendet seine Befehle nur an höhere IDs, die werden garantiert danach ausgeführt.

Letzte Taste wäre dann in Modul 254 Taste D8 Los.

Eine derart strukturierte Programmierung wird immer gehen. Ob sich das so konsequent programmieren lässt, wage ich zu bezweifeln.


@Bernd: wenn deine Summen durch Statusmeldungen an Lämpchen gebildet werden, kann es passieren das ein Lämpchen fehlt.
Schalte deine Lämpchen für die Summen mit einem Kommando ... (= Einträge unter "Lämpchen" bleiben leer)
Ich lasse mich von meinem "Verdacht auf Meldungen" nicht abbringen ;-) (eigene Erfahrung mit viel weniger Traffik)

Grüße, Uwe - der bei zeitkritischen Befehlen auch gerne mal mit STV verzögert

Zur Sicherheit bei der Telegrammverarbeitung siehe auch:
http://www.tecplan.de/_lcn_schulung/Auf ... grammv.htm

Im Bus-Konfliktfall gewinnt das sendende Modul mit der kleineren ID.

Gruß, Martin - Nachricht gesendet von Martin (ID=255)

Uwe, die Lämpchen für die Summen werden durch Statusmeldungen gebildet. Die Summen sind teilweise so kompliziert, so daß ich die Lämpchen nicht durch Kommandos einstellen möchte. Dieses macht die Anlage auch noch unübersichtlicher. Ist aber nicht so schlimm, da ich die Meldungen ja periodisch wiederholen lasse ;-) . D.h. also daß die Lämpchen irgendwann schon umschalten werden. Da hab ich dann halt nur "ne kleine zeitliche Verzögerung ...

Martin, ich schätze, daß auch bei fehlerhaften Telegrammen zuerst der nicht gesendete Befehl nochmal gesendet wird. Sollten die Tasten nämlich im Fehlerfall wild durcheinander gesendet werden, würde eine vernünftige (sichere) Programmierung garnicht mehr möglich sein. Auf irgendetwas muß man sich ja verlassen können.
Deine Idee mit den "kritischen Befehlen" ist garnicht so schlecht, allerdings schluckt dies "ne Menge Ressourcen und Programmier-Arbeit. Außerdem wird die Anlage dadurch leider noch unübersichtlicher :-( .

Ich werd mir nochmal das Timing meiner Rolläden zu Gemüte führen vielleicht fällt mir da noch etwas auf.

Gruß, Bernd.

Philipp, wo hast Du dann das her?
Zitat:
wie ich lernen musste ( ) ist eine direkte Umschaltung bei Rolläden wohl nicht problematisch (gabs in einem anderen Thread).

http://www.bus-profi.de/Forum/forum-script/showthread.php?id=840

Gruß Philipp

Philipp, danke. Diese Diskussion endete mit der Aussage:

Aber auch Rademacher sagt nur Hausintern ihre Motoren sind Kurzschluß fest im Waschzettel steht das gleichzeitige bestromen von beiden Laufrichtungen ist verboten.
aber es funktioniert oder wie Uwe sagt es geht.

Gruss, Martin - naja, ich möchte es bei meinen Motoren nicht ausprobieren und bleibe bei 0,5 Sek Umschaltpause.

Hallo Martin,

es geht beim Umschalten auch nicht um gleichzeitiges Bestromen, sondern nur dass von L1 auf L2 ohne Pause umgeschaltet wird.
Da das Relais ja wechselt ist IMO da nicht zu große Gefahr gegeben

Gruß Philipp - oder irre ich

Ich werd mir nochmal das Timing meiner Rolläden zu Gemüte führen vielleicht fällt mir da noch etwas auf.

Damit bist du auf dem richtigen Weg ...

In deinem ersten Post wolltest du eine sichere Funktion - natürlich ist das "je sicherer desto unübersichtlicher" :=(

@Philipp: beim Schalten mit einem Richtungs-Relais hätte ich auch wenig Bedenken, die elektronischen Ausgänge schalten da schon schneller - hier würde ich immer die Umschaltzeit einstellen (auch bei R2U).

Grüße, Uwe