Timeout bei Initscan (bestimmte GA)

[rdeckard]

So, ich habe nach längerer Zeit mal ein Problem, wo ich nicht weiterkomme.

Eine bereits seit längerem existierende GA wollte ich nun für eine einfach Logik verwenden. Wenn ich diese GA auf initscan setze, dann habe ich Probleme bei der Edomi-Initphase. (er quält sich durch die 5 Request-Phasen durch).
Schalte ich initscan bei dieser GA ab, gehts wieder normal.

Im trace.log sehe ich keinen Fehler.

Hier die Angaben:
initscan1.png

initscan2.png

initscan3.png
In der ETS4 ist die GA drin (sie wurde ja von Edomi importiert). Ich nutze sie aber noch nicht. (Ist einem LED eines LED-Display-Panels zugewiesen)

Habe jetzt mal eine weitere (ähnliche) Status-GA erstellt, in Edomi importiert und auf initscan gesetzt. Dort das gleiche Verhalten. Alle anderen GAs (auch mit Initscan) funktionieren seit dem ersten IP-Router Fix einwandfrei.

Eine Idee?

[timberland]

Das Problem hatte ich auch. Hast du bei diesen KO auch das L Flag in der ETS gesetzt.

[rdeckard]

Das Bild von der ETS wollte ich noch hochladen:

initscan4.png

Obwohl ich mit der ETS ja noch nicht so vertraut bin, ist mir das auch aufgefallen, dass das Lese-Flag nicht gesetzt ist. Und Edomi möchte vermutlich beim Initscan den Wert LESEN.
Ich habe aber vorher mal das Flag L gesetzt und in das Device geladen. Jetzt ist es komischerweise wieder weg.

Bisschen KNX-Generell: Die Flags beziehen sich doch auf das KO des Geräts und nicht auf die GA selber.?
Was passiert, wenn ich in der ETS eine GA definiere, aber noch keinem Device zuweise. Kann dann Edomi diese GA auch nicht lesen? (Also klar hat sie keinen Wert, aber ich meine, läuft er dann auch in diese Timeouts? Was ja immer sehr nervend ist, wenn man Projekte aktivieren möchte.)

[timberland]

Hast du nach dem setzten des L Flags auch die Application neu überspielt?

[rdeckard]

ok...habs jetzt nochmals (partiell) reingeschrieben und nun hat ers gefressen. Und Edomi läuft nun durch!

Das heisst aber, dass ich in der ETS GA's immer schon einem Device zuweisen muss (mit L-Flag), damit Edomi korrekt startet? Ich kann also nicht mit einer Dummy-GA arbeiten, weil ich z.B. das entsprechende KNX-Device noch nicht habe? (Gut, ich kann ja in Edomi für diese Zeit ein internes KO verwenden.)

[fisch3009]

Wo soll denn die Antwort herkommen, wenn keinem Gerät die GA mit Lese-Flag zugewiesen wurde?
Das wird ja zwangsläufig immer zu einem Timeout führen. Du kannst ja einfach in Edomi die GA anlegen und das Initscan wegnehmen, dann startet EDOMI normal durch, hast du dann das entsprechende Gerät, musst du dem Gerät in der ETS die GA zuweisen, das Lese-Flag setzen und in Edomi bei der entsprechenden GA das Initscan aktivieren.

[gaert]

Initscan bedeutet, dass alle GAs, die diese Eigenschaft zugewiesen bekommen haben, beim Start abgefragt werden (Read-Request). Wenn keine Antwort kommt, wird entsprechend der Einstellungen in der edomi.ini verfahren (wiederholtes Abfragen, etc.). Das L-Flag muss natürlich gesetzt sein bei der GA und das KNX-Device muss auch in der Lage sein zu antworten. Das ist ja der Sinn der Sache

[rdeckard]

Stimmt...kann ja den Initscan einfach weglassen (bringt ja in diesem Stadium eh nichts, weil in der ETS kein Wert vorhanden). War halt irgendwie so drin, dass ich bei jeder neuen GA, die ich in Edomi verwendete, sicherheitshalber sofort den Initscan aktivierte. Das war jetzt die erste GA, die in der ETS noch nicht fertig konfiguriert war.

Jetzt machts Sinn.

[gaert]

GAs, die keine Antwort auf einen Read-Request senden brauchen/dürfen nicht gescannt werden. Ein weit verbreiteter Irrglaube ist, dass man beim Start mal eben ein "Statusabbild" des Busses erstellt auf diese Weise... Das ist natürlich Quatsch! Eine "Schalt"-GA hat i.d.R. keinen Status - daher ist es egal, ob die GA 0 oder 1 ist. Diese GA empfängt ja quasi nur die Schaltaufforderung. Um einen definierten Zustand beim Start zu erreichen, gibt's ja "Initsend"...

[rdeckard]

Hmm...vorheriges Problem erkannt und gelöst. Jetzt habe ich aber 12 weitere GAs (Fensterkontakte) mühsam in die Visu genommen und jede einzelne natürlich auf Initscan gesetzt. Nun habe ich wieder Timeouts.
Sprich: Eine oder mehrere dieser GA's ist in der ETS nicht auf Lesen gesetzt. Nur, wie finde ich den/die Übeltäter schnell raus?

Bei meinem oberen Beispiel war ja im trace.log auch nichts spezielles bei der betreffenden GA angegeben. Und im error.log stehen ja keine Details.
Im error.log steht zumindest die Anzahl: InitScan (4 GAs / 5 Abfragen / 150 Checks)

Müsste im trace.log nicht die GA drin stehen, von der keine Antwort zurückkommt (Timeout)?

[baumhaus123]

Lies doch mal die GAs über die ETS ob die überhaupt was zurückliefern...

[gaert]

Trace- und Fehlerlog sind der falsche Ansatz. Du musst ins MonitorLog gucken (ggf. erst aktivieren, indem Du das entsprechende System-KO auf 3 setzt). Dort schaust Du dann nach den "Requests" und den dazu fehlenden "Responses"...

[rdeckard]

OK..danke für die Inputs. Habe es aber glücklicherweise selber recht einfach rausgefunden. Dank der Visu wurden die 4 Fensterkontakte neutral angezeigt (wenn weder 0 noch 1 zeige ich einfach ein Bindestrich an.) So wusste ich, welche es waren.
Und der Grund war dann auch schnell gefunden. Das ist ein Fenster (Doppelflügel), welches noch am Binärinterface angehängt ist und deshalb vermutlich in der ETS noch nicht zugewiesen wurde. Habe die vier jetzt wieder aus dem Initscan rausgenommen und kann weiterspielen.

(Schön wäre es, wenn man mit SHIFT/CTRL mehrere KO's markieren könnte und Initscan batchmässig ein/ausschalten. Aber eben...wir sind ja early Adopters und da muss man halt vieles noch von Hand machen. Stichwort: Männer-Visu . Ist also kein Featurewunsch für den Moment, nur eine Feststellung.)

[rdeckard]

Trace- und Fehlerlog sind der falsche Ansatz. Du musst ins MonitorLog gucken (ggf. erst aktivieren, indem Du das entsprechende System-KO auf 3 setzt). Dort schaust Du dann nach den "Requests" und den dazu fehlenden "Responses"...

Christian, ich habe wieder mal eine GA, die beim initscan Probleme macht. Du hast mir mal diesen Tipp gegeben (den ich damals dann nicht mehr benötigte).
Gilt das bei der aktuellen Version immer noch? Wie setze ich dieses System-KO auf 3? Im edomi.ini?
Oder soll ich einfach das debug log aktivieren?

[gaert]

In der KO-Konfiguration einfach das System-KO entsprechend bearbeiten und dann das Projekt aktivieren.