Flags

[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.

[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.

[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]

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.