Terminal Touch verändert nach Download/Neustart den Wert (úngewollt)

[confider2]

Egal, was ich dort reinlade, dieses Mistding ändert stets reichlich Werte. Nach jedem Neustart setzt er bsp. das Lichtschaltelegramm eines Raumes auf 1 und es wird hell. Ähnlich bei Jalousien.

Wie stelle ich das ab???

Die Flags stehen in der ETS 3, wie auch in der SW dazu alle auf "ein", was auch logisch ist. Denn nirgendwo habe ich ihm gesagt, setze nach Neustart "eigene" Werte ein und sende sie erstmal.

Wo liegt das Problem?

[Dirk Beyer]

Hast Du die Telegramme währen des bootens mal aufgezeichnet?

Eine gern gemachte Problemursache mit diesem Funktionsbild ist "Statusabfrage EIN" bei den Telegrammen des Tableaus.

Dann scannt das Tableau beim Start.

Wenn Du dann die Grp-Adressen im EIB unglücklich vergeben hast, bekommst Du ein "Response" z.B. vom Taster mit "1", welches von einem Aktor als Befehl interpretiert wird. Da Du alle Flags auf "Ein" hast, ist es wohl auch beim "L" der Fall.

Wenn Du ein solches Bootverhaltren hast, musst Du entweder die Statsusabfrage im Tab löschen (Quick & Dirty) oder die ETS-Programmierung sauber neu aufbauen.



Gruß

Dirk

[Uwe!]

hatte das gleiche (?) Problem und bei mir waren es eindeutig zu viel vergebene L-Flags. Allerdings war das Verhalten auch mit Telegrammaufzeichnung nicht erklärbar oder nachvollziebar. Aber Korrektur der L-Flags behebt das Problem, warum auch immer...

[confider2]

Meint das, ich soll in der ETS3 das Lese-Flag ein lassen und beim Tab Status Aus, Lesen aus, alle anderen ein?

Wenn ich (ETS alle EIN) beim TAB die Statusabfrage aus stelle und alle anderen ein, so hab ich statt 60 "Fehltelegrammen" nur noch ein paar, immerhin. Eine dumme Jalousie bewegt sich aber immer, auch wenn ich die nur via ETS abfrage.

Die ETS ist sehr sauber aufgebaut, heute, die sollte nicht die Ursache sein, aber was sind "unglückliche Gruppenadressen"?

[Dirk Beyer]

Hi,

das ist sehr umfangreich zu beschreiben und sprengt den Rahmen einer kurzen Antwort. Ich versuche mal einige Hinweise zu geben:

1) Zentraladressen als "Schreibende Adressen" im Aktor statt als "lesende"

2) Unnötige L-Flags bei den EIB-Komponenten gesetzt

3) Sensoren mit gesetztem L-Flag sind nicht über den Aktorzustand "informiert"

Tipp: Durchforste Dien EIB-System (Nicht das Tab.) nach unnötigen L-Flags. Dazu die Telegrammaufzeichnung starten und das Tab booten. Alle Geräte die ein "Response" senden haben ein L gesetzt. Das Response kann durchaus schalthandlungen bewirken.

Ob das L nötig ist oder nicht musst Du entscheiden.

Gruß

Dirk

[Meudenbach]

1) Zentraladressen als "Schreibende Adressen" im Aktor statt als "lesende"


setzen, sechs :rolleyes: ...

Zentraladressen, sollten gar nicht erst abgefragt werden !!! Wenn dann reden wir von "sendenden" und "übergeordneten" Adressen. Die sendende Adresse ist die Adresse, die in beiden Richtungen kommuniziert. Ergo, wird auf eine übergeordnete Adresse eine Leseanfrage gesendet, antwortet das Kommunikationsobjekt immer mit der sendenden Adresse. Das Auslösen von Schalthandlungen auf ein Value Response kann durch löschen des "A"-Flags unterbunden werden. Dies geht aber leider nicht bei der BCU1 ...

Grundsätzlich sollten Leseabfragen auf Statusobjekte wirken, dass ist die sauberste Lösung.

Wenn keine Statusobjekte vorhanden, dann eben auf die Schalt oder Wert Objekte der Aktoren..

Sinnlose Abfragen wären zB auf ein 4-bit Dimmobjekt, oder eben Objekte von Jalousieen (Ausnamhe wäre eine Positionsabfrage).

Generelles vorgehen:
Schaue Dir die Adressen in der Gruppenübersicht an. Dort siehst Du die zugehörigen Assoziationen. Du solltest sicherstellen, dass je Gruppenadresse nur 1 assoziiertes Kommunikationsobjekt das L-Flag aktiviert hat. Weiterhin solltest Du die Sinnhaftigkeit prüfen, ob der Wert der Gruppenadresse überhaupt ausgelesen werden soll..

Problematik bei Abfrage mehrfach vergebener Gruppenadressen bzw. Zentralbefehle:

Wie vor bereits erwähnt erfolgt auf ein Value Read ein Value Response. Dies wiederum führt bei Kommunikationen mit gesetztem "A" Flag eine "Syncronisierung" des Wertinhaltes durch. Im Zweifel also eine Schalthandlung. Wenn Du nun eine Zentraladresse abfragst und diese Adresse irgendwo als "sendend" eingetragen wurde, wird in der Antwort ein Wertinhalt mit dieser Adresse übertragen. Alle Objekte, die nun mit dieser Adresse verbunden sind schalten nun auf diesen Wert !!!

Man kann sich natürlich auch die Abfrage über eine Zentraladresse nützlich machen, da ich mit nur einer Lesanfrage (wenn die GA nicht irgendwo sendend gesetzt wurde) sämtliche damit verbundenen Objekte abfragen kann..

ABER!!
Dies führt, je nach Anzahl der zu erwartenden Antworten in der Regel zu sog. Telegrammlawinen und führt zu Störungen in der Kommunikation bzw. zu entsprechenden Telegrammverlusten...

LG

[Dirk Beyer]

setzen, sechs :rolleyes: ...

LG


Hi Mike,

mein Beitrag soll nicht heißen daß er es so machen soll, sondern die eventuelle Fehlerursache darstellen! Ich hatte nicht die Zeit für so eine ausführliche Antwort, wie Du sie eben formuliert hast

Gruß

Dirk

[confider2]

Ersteinmal danke. Dann wäre es so, das das L-Flag an sich "unwichtig" ist.

Kann ich daraus folgern, daß bei nicht gesetztem L-Flag ich gar nie einen Status auslesen kann?

Und kann ich denn insgesamt daraus folgern, daß das Statusabfrage-Flag des Tableaus Vorrang hat vor dem nicht gesetzten L-Flag des Objektes?

Im Beispiel möchte ich via Tableau die Jalousien zentral schalten und abfragen (auf/zu), gleichzeitig aber woanders im Tableau das OG oder auch Einzeljalousien schalten/abfragen. Ist das dann überhaupt möglich?

GA: 1/1/1 (zentral)
Jalousie 1, Flags KLSÜA
Jalousie 2, Flags KLSÜA
Jalousie 3, Flags KLSÜA

GA: 1/1/2 (nur Obergeschoss)
Jalousie 2, Flags KLSÜA
Jalousie 3, Flags KLSÜA

GA: 1/1/3 (Einzeljalousie)
Jalousie 2, Flags KLSÜA

[Meudenbach]

Ersteinmal danke. Dann wäre es so, das das L-Flag an sich "unwichtig" ist.

wenn Du abfragen willst, ist es nicht "unwichtig" und muss besonders beobachtet werden!!


Kann ich daraus folgern, daß bei nicht gesetztem L-Flag ich gar nie einen Status auslesen kann?

Jup, weil die Objekte eben nur antworten, wenn "L" Flag gesetzt...


Und kann ich denn insgesamt daraus folgern, daß das Statusabfrage-Flag des Tableaus Vorrang hat vor dem nicht gesetzten L-Flag des Objektes?

nöö, weil die Folgerung an sich ja unschlüssig ist. Was bringt dir eine "vorrangige" Abfrage, wenn keine Antwort zu erwarten ist ??? Das Statusabfrage-Flag des Tableaus generiert lediglich eine Abfrage... ins "Leere", wenn nicht durch eben dem "L"-Flag am K.-Objekt die "Freigabe" zur Antwort erteilt wurde. Ergo, spar Dir gleich die Abfrage...


Im Beispiel möchte ich via Tableau die Jalousien zentral schalten und abfragen (auf/zu), gleichzeitig aber woanders im Tableau das OG oder auch Einzeljalousien schalten/abfragen. Ist das dann überhaupt möglich?

Möglich ist grundsätzlich alles, die Frage ist der Sinn!! Die Abfrage kommt ja "nur" bei einem Neustart, also "Störfall". Bei Jolusieaktoren kannst Du "plausibel" nur mit einem Statusobjekt arbeiten..

... mache doch einfach mal folgendes. Fahr die Jalousie ab und dann sofort ein Stop... Dann Abfrage auf das "Fahr" Objekt. Antwort wird sein "1" also zu. Jalousie ist aber offen bzw. lediglich ein Stück herabgefahren. Diesen Fall kannst Du nur abfangen, wenn Du zB ein Status "Höhe" auswertest. Feste Buttons für AUF und ZU, als Anzeige dann Höhe in %. Oder Du nimmst zur Anzeige eben Status Objekte der Endlagen (wenn vorhanden).

Alles andere ist Quatsch !!

LG