Flags

[MatthiasS]

Das ist schon richtig, alle Fensterkontakte und Licht-Stati werden beim Start ausgelesen.

Nicht gelesen werden Heizungsdaten, die kommen ohnehin.

Ganz wichtig beim Hs ist es, alle die Daten auszulesen, die man in zyklische Archive schreibt, z.B. die Außentemperatur der Wetterstation. Sonst hat man u.U. hässliche Werte mit 0 im Archiv und somit in den Telegrammen.

Bei meine Strommessungen verhindere ich übrigens Einträge von 0 mit einem Filter.

[eibling]

Ich richte im HS die KO ein, die ich beim Starten des HS abgefragt haben möchte (das sind durchaus nicht alle!).

Letztlich sind das doch alle, die
- Du in der Visu korrekt, also auch nach Neustart des HS, angezeigt bekommen möchtest, und
- ihre Daten nicht eh in kurzen Abständen senden?

Mich ärgert zB, daß ich in meiner Visu nach dem Neustart nicht sehe, welche Lichter/Steckdosen an sind - also müßte ich deren Flgs senden.

Dasselbe gilt bei KO's die nur bei sbc senden - solange kein change, kein senden.

Dagegen sendet die Wetterstation (manche) Daten zyklisch, so daß die kurz nach dem Neustart eh frisch eintreffen...

[MatthiasS]

Wie Klaus Gütter schrieb: Entscheidend ist nicht alleine das gesetzte Flag in der ETS, sondern auch, ob das Appliationsprogramm überhaupt darauf achtet.

Ein gesetztes L-Flag bedeutet nicht automatisch, dass du auf Leseanforderung eine korrekte Antwort bekommst.

Da - wie du oben schreibst - die Reihenfolge nicht vorhersehbar ist - kann es durchaus bei falsch gesetztem L-Flag innerhalb einer GA mit verschiedenen KO dazuk ommen, dass als letztes das falsche antwortet und deswegen dieser Wert dann gilt. Das letzte Telegramm siegt. Insofern ist bewußter Umgang mit dem L-Flag sehr sinnvoll.

Ich kann mich nicht erinnern, jemals an anderen Flags als dem L-Flag gedreht zu haben. Ich richte im HS die KO ein, die ich beim Starten des HS abgefragt haben möchte (das sind durchaus nicht alle!). Die Debugseite im HS zeigt dann an, wo Lesefehler auftreten und die werden dann per ETS beseitigt.

[JoeHorn]

@roadflower:
Die Erklärungen sind besser als die im Wiki, sie sollten dort hinein.



Wenn ich das richtig verstehe, würden alle Geräte mit gesetztem L-Flag und gleicher Gruppenadresse versuchen, auf eine Leseanfrage zu antworten. Kollisionen sollten dabei keine auftreten, es könnte nur jedes Gerät etwas anderes antworten. Ist auch bei allen das A-Flag gesetzt hat das letzte Gerät danach dann "gewonnen"?
Wie reagiert das fragende Gerät (meistens eine Visu?) auf diese Antwortflut? Ist das irgendwo definiert? Bei gesetztem A-Flag sollte die letzte Antwort bestimmend sein (ist das so?), aber sonst?
Die Antwortreihenfolge ist vermutlich nicht immer genau vorhersagbar, aber welche ernsthaften Probleme (außer der temporären Buslast) könnten mehrere Antworten auf eine Frage aufwerfen? Ist das Verhalten bei mehreren Antworten überhaupt verbindlich festgelegt worden?

Kann eine Antwort überhaupt zweifelsfrei von einem "normalen" Datentelegramm unterschieden werden, oder muß zur korrekten Erkennung die Anfrage herangezogen werden?
Im ersten Fall: sind Geräte bekannt, die eine Antwort nicht als solche kennzeichnen, so daß andere die Antwort fälschlich als normales Telegramm einstufen (müssen)?

Wenn ich einem Objekt mehrere Gruppen zuweise, sendet es ja nur auf genau einer davon. Wenn jetzt eine der anderen Gruppen abgefragt wird, antwortet es dann nicht, oder sendet es ausnahmweise auf der angefragten, oder sendet es auf der zum Senden vorgegebenen Gruppe, auch wenn die Anfrage einer anderen galt?
Im letzten Fall könnte ich mir dies als eine Problemquelle vorstellen, vor allem, wenn die Antwort nicht von allen als solche eingestuft wird...

Wenn ich mehrere Taster als Umschalter (d.h. sie sollten den aktuellen Status kennen) mit einen Aktorkanal verknüpft habe und dieser ein einenständiges Rückmeldeobjekt hat, wie realisiert man dann am besten die Synchronisation wenn ein oder mehrere Teilnehmer zwischenzeitlich einen Reset machen mußten? Meine Taster können keine Leseanforderungen versenden, jedoch darauf antworten und ihren Status nach einem Reset und/oder zyklisch senden, meine Visu könnte alles (A-Flag ist manchmal nicht aktivierbar), meine Aktoren sind wie meine Taster nutzen aber ein eigenes Rückmeldeobjekt. Ob sie trotzdem Anfragen an das Schaltobjekt beantworten, weiß ich leider nicht (Berker 8/16 fach Jalousie/Schaltaktoren).

Mein "Installateur" hat hier ziemlich kreativ entschieden, ich würde das gerne etwas glatt ziehen, weil teilweise vertauschte Schalt- und Rückmeldegruppen sowie scheinbar willkürlich gesetzte Flags meiner Visu das Leben schwer machen. Die Kommunikation Schalter/Aktoren klappt einigermaßen, da, einfach alle in Frage kommenden Gruppen auf beiden Seiten für alles mögliche eingetragen wurden...

Beispiel:
Taster 1: K,S,Ü
0/1/5 0/1/6
Taster 2: K,S,Ü
0/1/6 0/1/5
Aktor Schaltobjekt: K,S(,L)
0/1/5 0/1/6 0/0/5
Aktor Rückmeldeobjekt: K,Ü(,L)
0/1/6 0/1/5 0/0/5

(teilweise gesetzt)
0/0/5 taucht in vielen Schaltkanälen auf und sollte wohl mal ein Zentralschaltbefehl werden, wird aber bislang von niemandem gesendet...

... für sinnvoll halte ich das aber nicht.
Wie würdet Ihr das konfigurieren?

Sorry für die vielen Fragen hier, aber aus den Beiträgen im Wiki konnte ich das nicht herauslesen.

[Uwe!]

Nein, alle auf L ist gefährlich!

Ich schrieb oben, dass pro GA nur ein KO das L-Flag gesetzt haben darf. Setzt man die schon standardmäßig und man passt nicht auf, dann knirscht es schnell.

Leicht OT:
ds ist z. B. eine der Gründe, warum ich es begrüßen würde auf die EIB.db wie auf eine "normale" Datenbank zugreifen zu können. Da wären solche Auswertugen ein Klacks! Mit der ETS kann ich mcih nur mühevoll durchklickern.
OT Ende

Uwe
PS: und wen jemand drauf Antworten will, dann sollte das in einen eigenen Thread umgezogen werden

[eibling]

Sorry Michel und Matthias,

ich meinte natürlich nicht "immer" im Sinne von "immer" , sondern pro jeder relevanten GA (aber da kommen doch einige zusammen...), aber danke noch mal für die Klarstellung!!

[MatthiasS]

Nein, alle auf L ist gefährlich!

Ich schrieb oben, dass pro GA nur ein KO das L-Flag gesetzt haben darf. Setzt man die schon standardmäßig und man passt nicht auf, dann knirscht es schnell.

[Michel]

So ist es! Aber man beachte Matthias´ Hinweis in Bezug auf das L-Flag weiter oben. Ansonsten könnten ungewollte Ergebnisse auftreten.

[eibling]

Und wie gesagt, Flags erst einmal so hinnehmen, wie sie standardmäßig vorgegeben werden.

Das Lese-Flag ,L'
Das Lese-Flag erlaubt es den Objektwert auszulesen, d. h. aufgrund eines Lesetelegramms wird nur dann ein Antworttelegramm gesendet, wenn das Lese-Flag des Objekts gesetzt ist. Diese Funktion wird bei Visualisierungen, Lichtszenen etc. benötigt, um den aktuellen Objektzustand definiert abzufragen. Das Lese-Flag ist standardmäßig meist nicht gesetzt. Bei manchen Herstellern wird das Lese-Flag bei Statusobjekten gesetzt.

Müßte ich dann nicht jedenfalls immer das L-Flag von Standard "nicht-gesetzt" auf "gesetzt" ändern, damit ich beim Neustart des HS die aktuellen Zustände (Licht, Steckdosen, Temperaturen..) auf die Visu bekomme? Denn sonst muß ich ja warten, bis eine Änderung (Licht schalten, Temp. ändern...) vornehme, oder versteh ich das falsch?

[Klaus Gütter]

D.h. System 1 busankoppler verhalten sich so, als währe bei ihnen das A-Flag gesetzt?

Richtig.

Zum genauen Verständnis: ohne gesetztes Flag

• K sind die anderen egal, weil nichts geht?
• L antworte ich nicht auf Statusabfragen?
• S übernehme ich keinen neuen Status vom Bus?
• Ü sende ich Änderungen meines Status nicht?
• A übernehme ich keine Antworten als neuen Status vom Bus?

Auch richtig.

Was passiert eigentlich, wenn K und A gesetzt sind, L,S und Ü aber nicht?
Übernehme ich den Status dann nur, wenn es eine Antwort auf eine Leseanfrage ist? Macht so etwas Sinn?

Nochmal richtig.

Bedenke aber, dass es vom Applikationsprogramm abhängt, ob die Flag-Einstellungen einen Effekt haben. Es kann also sein, dass z.B. trotz gesetztem Ü-Flag Statusänderungen nicht gesendet werden. Im Zweifelsfall in der Applikationsbeschreibung nachschauen.

Gruß, Klaus

[JoeHorn]

ist das aktualisieren- flag gesetzt, so wird ein antworttelegramm eines lesevorgangs als schreibtelegramm interpretiert, d. H. Der objektstatus der teilnehmer wird eventuell verändert.
...
System 1 busankoppler interpretieren antworttelegramme immer als schreibtelegramme und ändern deshalb eventuell ihren objektstatus.

D.h. System 1 busankoppler verhalten sich so, als währe bei ihnen das A-Flag gesetzt?


Zum genauen Verständnis: ohne gesetztes Flag

• K sind die anderen egal, weil nichts geht?
• L antworte ich nicht auf Statusabfragen?
• S übernehme ich keinen neuen Status vom Bus?
• Ü sende ich Änderungen meines Status nicht?
• A übernehme ich keine Antworten als neuen Status vom Bus?

Was passiert eigentlich, wenn K und A gesetzt sind, L,S und Ü aber nicht?
Übernehme ich den Status dann nur, wenn es eine Antwort auf eine Leseanfrage ist? Macht so etwas Sinn?

[Jürgen2]

Danke für die Erklärung. Denke damit kann ich mir langsam vorstellen, was die Flags bedeuten.

Freu mich schon auf das Programmieren.

Jürgen

[roadflower]

Das Kommunikations-Flag
Das Kommunikations- Flag ist der „Hauptschalter" der Kommunikation, d. h. ist dieses Flag nicht gesetzt, so kann das Objekt keine Telegramme empfangen oder senden, Das Kommunikations-Flag ist standardmaßig bei allen Objekten gesetzt. Es kann sein, dass bei bestimmten Konstellationen, z. B. bei nicht Benutzen des Objektes, es notwendig ist, das Kommunikations-Flag zu löschen. Falls dies notwendig ist, geht dies aus den Applikationsbeschreibungen des Herstellers hervor. Wenn dieses Objekt mit einer Gruppe verbunden ist, wird trotz des gelöschten Kommunikationsflaps ein Acknowledge gesendet!

Das Lese-Flag ,L'
Das Lese-Flag erlaubt es den Objektwert auszulesen, d. h. aufgrund eines Lesetelegramms wird nur dann ein Antworttelegramm gesendet, wenn das Lese-Flag des Objekts gesetzt ist. Diese Funktion wird bei Visualisierungen, Lichtszenen etc. benötigt, um den aktuellen Objektzustand definiert abzufragen. Das Lese-Flag ist standardmaßig meist nicht gesetzt. Bei manchen Herstellern wird das Lese-Flag bei Statusobjekten gesetzt.

Das Schreiben-Frag 'S' Das Schreiben-Flag erlaubt dem Objektzustand über den Bus, aufgrund eines Telegramms, zu andern. (Der Objektstatus kann überschrieben werden.)
D. h. ein Aktor kann nur dann schalten, wenn bei dem Schaltobjekt das Schreiben-Flag gesetzt ist.
Das Schreiben-Flag ist standardmaßig bei allen Schaltobjekten, Wertobjekten (Aktor) sowie bei vielen Tasterobjekten (z.B. wegen der Aktualisierung bei UM- Funktionen) gesetzt.

Das Übertragen-Plag Ü'
Das Übertragen- Plag erlaubt dem Kommunikationsobjekt Telegramme zu senden (Telegramme an den Bus übertragen). Auslöser zum Senden kann z. B. ein Tastendruck, eine Temperatur Veranderung oder auch eine Änderung des Objektstatus sein. Das Telegramm kann aber auch vom Anwendungsprogramm ausgelöst werden.
Das übertragen- Plag ist von der Applikation abhangig und standardmaßig
bei Sensoren gesetzt. Bei Statusobjekten von Aktoren wird das Übertragen- Flag ebenfalls meist standardmaßig gesetzt.

Das Aktualisieren- Flag
Ist das Aktualisieren- Flag gesetzt, so wird ein Antworttelegramm eines Lesevorgangs als Schreibtelegramm interpretiert, d. h. der Objektstatus der Teilnehmer wird eventuell verandert.

Die Anwahl und Auswertung des Aktualisieren- Flag kann nur an System 2, System B und System 7 Busankopplern vorgenommen werden.

System 1 Busankoppler interpretieren Antworttelegramme immer als Schreibtelegramme und andern deshalb eventuell ihren Objektstatus.

[MatthiasS]

Das wird schon Und wie gesagt, Flags erst einmal so hinnehmen, wie sie standardmäßig vorgegeben werden.

[Jürgen2]

Danke schonmal.
Werd nächste Woche wohl meine Steckdosen fertig montieren, und anschließend gehts mit der Programmiererei los.

Denke ich werd dann wohl öfters noch hier ne Frage stellen.

Jürgen