Bus-Profi Forum

Bernd, du hast natürlich recht was die Gruppe3 angeht. Die Gruppe hat in der Anlage die Nummer 130, ich wollte in meinem Beispiel (der Einfachkeit halber) neutrale Modul- und Gruppennummern verwenden, und da habe ich ausgerechnet die Gruppe3 erwischt. Also - Zufall und für das Problem bedeutungslos.

Besten Dank trotzdem

Gruss Erich

Also beim Quittungssystem wäre ich jetzt etwas unsicher (vielleicht kann Nils noch eine sichere Antwort beisteuern)

Die "echten Rückmeldungen" betreffen m.E. nur die Statusmeldungen der Ausgänge, eine Quittierung des ausgeführten Befehls wird nicht versendet. Die gibt es nur beim Programmieren des Moduls (dann ja auch im Protokoll sichtbar).
Da hier "für einen Moment" recht viele Befehle und Statusmeldungen entstehen, kann das zur Auslastung des Busses reichen.

Bernd hat natürlich recht, mit "zerschossen" meinte ich einfach und wie auch immer "wech ist wech" (wo auch immer es verlorengeht, wir können es nicht beeinflussen).

Bei Gruppe 130 würde ich aber auch hier den ersten Versuch mit einer kleineren Gruppen-ID machen ... ;-)
Ob der Befehl von einem Modul der Gruppe ausgelöst wird oder nicht, darf dabei keine Rolle spielen.

Gruss, Uwe - dem die Lämpchen auch immer bei höher wertigen Modulen (ID > 50) fehlen

PS: das Prinzip bei meiner ID-Aufteilung verteilt 36 Module auf die IDs 10-65, eine Neuverteilung/Entzerrung braucht da schon (mit allen Lämpchen/Summen etc.) ein paar Stunden mit div. Funktionsausfällen. Da das keinen WAF hat warte ich auf einen Tag, an dem meine Mädels unterwegs sind :-O

Hallo!

Uwe:

Natürlich ist das "sicher": Ausgang 1 schaltet Ausgang 2 ein, der wieder Ausgang 3 usw.
Da passt das Timing auf jeden Fall.

Aber wofür ist dann der Gruppenbefehl gut?

Natürlich geht das *hervorragend* mit einer Gruppe, wenn man einen Befehl nimmt, der einen definierten Zustand auslöst. UM -> ein oder aus? Je nach dem was es vorher war. Wenn ein Modul 7xUM empgängt, ist es etwas anderes als 6x oder 8x... Gruppenbefehle gehen AFAIK als eine Art Broadcast heraus, da das Sendemodul nicht weiß, wer alles Mitglied ist, ist eine "handshake" AFAIK weder vorgesehen noch ohne weiteres möglich.

Würde man man ein definiertes "ein" und ein "aus" an dei Gruppe senden , wäre es kein Problem.

Ich würde noch mal mit einer Lichtszene probieren.

Einfacher: eine ("Haupt")Lampe wird manuell UM geschaltet, alle anderen sind Mitglied in einer Gruppe, die Statussignale der "handgeschalteten" schalten alle die Gruppenmitglieder mit jeweils einem Befehl ein oder aus.

Wenn das die Module nicht mitmachen, ist IMO etwas faul an der Anlage, man könnte als Workaround den gleichen Befehl als 2nd Key (oder sogar mit STV) noch einmal senden - und sich um den Fehler kümmern ;-)

Mit Lämpchenfunktionen würde das auch gehen, aber auch nur komplizierter.

Thomas

Zu dieser von Thomas formulierten Aussage/Erkenntnis

Gruppenbefehle gehen AFAIK als eine Art Broadcast heraus, da das Sendemodul nicht weiß, wer alles Mitglied ist, ist eine "handshake" AFAIK weder vorgesehen noch ohne weiteres möglich.

war ich zwischenzeitlich auch gekommen - insbesondere da das Sendemodul niemals alle Mitglieder einer dynamischen Gruppe kennen kann (oder melden sich alle Mitglieder von Gruppen bei Bus an/ab: "Hallo, ich bin jetzt Mitglied von Gruppe X und Y").
Da der UM-Befehl keinen definierten Zustand(Wert) hat (wie Thomas schön erläutert hat), müsste die Konsequenz doch sein, dass ein UM-Befehl niemals an eine Gruppe gesendet werden sollte, wenn man auf Nummer sicher gehen will .
Mit dem Status eines Ausgangs (oder eines virtuellen Relais) lässt sich immer ein definierter Zustand (AN oder AUS) auch problemlos an eine Gruppe versenden.
Lernt man solche Empfehlungen im LCN-Fortgeschritten-Kurs ?
Vielleicht kommt das Thema auch schon beim LCN-W Kurs zur Sprache, weil man doch ohne Zustand (AN oder AUS) eines Ausgangs nicht visualisieren kann, ob die Leuchte an einem UM-Schalter gerade AN oder AUS ist.
Ist der UM-Befehl also vielleicht ein "Auslaufmodel" (da nicht für Gruppen und Visualisierung geeignet) (?)

Gruss, Martin - der seine Rolladen UM-schaltet und der LCN bevorzugt, weil es so SICHER sein soll.

Lernt man solche Empfehlungen im LCN-Fortgeschritten-Kurs ?

Ist schon länger her bei mir, aber ich kann mich da an eine Kaffeepause erinnern ;-)

In der Visualisierung ist das kein Thema, ein Lämpchen (oder "Button" der W) zeigt immer nur einen Ausgang an. Da sieht man welche an oder aus sind.

Das ist hier keine "dynamische" Gruppe ... das Ergebnis wäre allerdings gleich.
Und: der Bus merkt sich nichts, er überträgt nur Informationen. Die müssten sich die Module merken - und dieses doofe Modul 22 ist einfach nicht daran interressiert in welcher Gruppe Modul 21 mitmacht.

Ich habe versucht, den Fehler bei mir nachzuvollziehen - ohne Erfolg (mein Test lief allerdings auf Modulen mit ID"s im 20er Bereich). 100mal die Gruppe UMschalten wurde 100mal ausgeführt.

Es gibt also mehrere (s.o.) mögliche Ursachen, die am einfachsten mit dem Vorschlag von Thomas zu "beheben" sind.

Gruß, Uwe - der das Timing der Kaffeemaschine auch nicht versteht, immer wenn er davor steht ist das Wasser alle :-O :-O :-O

Hallo Leute,

Äh, uff denk, grübel

Also so ganz verstehe ich das nicht mit dem Ein/Aus/Um

Was heißt hier definierte Zustand und wieso habe ich den bei Ein/Aus ?

Ich bin noch nicht so tief in der Parametrierung der Geschichte,
aber nur mal ein Beispiel ich habe jetzt in der Bauphase einen Taster belegt der alle Rolläden im Haus per Gruppenbefehl hoch oder runter fährt.
Nach 70s sende ich eine STV an die Relais alles abschalten (die Module stehen ja schon auf 70s). D.h nach 70s sind alle Ausgänge und Relais aus, egal ob die Rolläden oben oder unten sind. Nehmen wir mal an der Gruppenbefehl vergißt ein Modul (Rolladen) wie soll ich bitte schön nach 70s einen definierten Zustand erhalten welcher Rollo auf oder zu ist.

Das der Gruppenbefehl ein Broadcast ist merkt man ja schon daran, wenn ein Modul der Gruppe abgeschaltet wurde gibt es vom Bus keinerlei Anstalten dieses Modul unbedingt zu erreichen, oder er es mit einer Fehlermeldung zu quittiert.

Ich denke der Bus muß so fehlertolerant sein das Gruppenbefehle eigentlich nicht untergehen dürfen.
(jedenfalls bei ordnungsgemäßer Verkabelung und Ausführung)
Oder liege ich jetzt total schief


Gruß Ralph

Na ich merke schon (denk, grübel) - der Ralph hat beim Grundkurs - äh - seinen Grundkurs beim Bus-Profi gemacht :-O :-O :-O

Wir schalten einen Ausgang:
EIN - schaltet "ein"
AUS - schaltet "aus"
UM - schaltet "ein" wenn aus ODER "aus" wenn ein
Wenn ich also einen Ausgang garantiert EINschalten will, sollte ich nicht UMschalten (er könnte ja schon EIN sein).

Auch hier noch mal: der Bus ist ein reines Übertragungsmedium, die Intelligenz sitzt im Modul.
JEDES Modul empfängt JEDEN Befehl, (im Normalfall) die meisten werden ihn nicht ausführen, weil die M oder G ID nicht stimmt.
Wenn jetzt hin und wieder Befehle nicht ausgeführt werden, hat das (meistens) Ursache in fehlerhafter Verdrahtung/Verkabelung. SK, IS etc. lassen wir mal außen vor. Ein defekter Sende-/Empfangsbaustein im Modul ist selten, aber nicht unmöglich. Ein "Timing"-Problem kommt schon eher mal vor (so meine Erfahrung), wenn da durch einen Gruppenbefehl gerade sehr viel "Broadcast" (z.B. durch Statusmeldungen/-kommandos) ausgelöst wird.

Lektion für die eigene Anwendung: die Gruppe für die Brandmeldeanlage hat eine kleine ID (und dadurch hohe Priorität) :-O

Wenn du da bei dir ins "Eingemachte" gehtst, werden wir telefonieren. Das ist Aufbaukurs 2.Tag

Ach ja, einen definierten Zustand der Rollos gibt es nur mit BS4 und NUR im Modul (nicht visualisierbar auszulesen), alle anderen fahren einfach den definierten Befehl.

Gruß, Uwe - den dieses ewige rauf und runter klatschverrückt macht :-O :-O :-O

Original von RBausE:
...
> Was heißt hier definierte Zustand und wieso habe ich den bei Ein/Aus ?

ein Ein an die Gruppe: alles ein (egal wie der Ausgangszustand ist)

ein Aus an die Gruppe: alles aus (egal wie der Ausgangszustand ist)

ein Um an die Gruppe: 2 waren ein3, waren aus, danach ist es umgekehrt

> Ich bin noch nicht so tief in der Parametrierung der Geschichte,
> aber nur mal ein Beispiel ich habe jetzt in der Bauphase einen Taster
> belegt der alle Rolläden im Haus per Gruppenbefehl hoch oder runter fährt.
> Nach 70s sende ich eine STV an die Relais alles abschalten (die Module
> stehen ja schon auf 70s). D.h nach 70s sind alle Ausgänge und Relais aus,
> egal ob die Rolläden oben oder unten sind. Nehmen wir mal an der
> Gruppenbefehl vergißt ein Modul (Rolladen) wie soll ich bitte schön nach
> 70s einen definierten Zustand erhalten welcher Rollo auf oder zu ist.


Gute Frage. Man weiß es nicht. Deswegen verwende ich vorzugsweise die Positionierung. Egal ob 3 Rolladen auf 2/3, zwei zu, 1 auf etc. sind, ich sende RelPos 150 an die betr. Gruppe und alle fahren auf (ca.) 75%! (Realisiert habe ich das deutlich komplizierter, aber universeller)

Dummerweise kann man die Position mit normalen Befehlen nicht abfragen und ich konnte bisher noch keinen erweichen mich am Insiderwissen teilzuhaben zu lassen.
...
> Ich denke der Bus muß so fehlertolerant sein das Gruppenbefehle eigentlich
> nicht untergehen dürfen.
> (jedenfalls bei ordnungsgemäßer Verkabelung und Ausführung)
> Oder liege ich jetzt total schief

Teilweise. Dass so etwas verloren geht ist IMO ein Fehler, der behoeb werdne muß, es liegt wahrscheinlich an der nicht ordnungsgemäßen Verdrahtung. Also nicht nur so ein bischen sorglos, sondern ein ziemliches "Ei" in der Anlage.

Ich habe z.B. einen 5fach Serienschalten für meiner Wohnzimmerbeleuchtung. Beteiligt so ca. 5 Module. Geschaltet werden Lichtszenen über Gruppenbefehle. Es gab in so ca. 4 Jahren noch keine Fehlauslösung.

Thomas