Konfiguration Statusabfrage / Rückmeldung verspätet

[MIT]

Hallo zusammen,

ich habe mal eine generelle Frage zur Performance und ggf. auch zur Konfiguration von Statusabfragen:

Was möchte ich erreichen?
- Eine Übersicht über den Status der geöffneten und geschlossenen Fenster

Wie frage ich diese ab?
- Über 1-Wire Reedkontakte an den Fenstern und der entsprechenden Interfacekarte wird der Wert aufs Wiregate geschickt und dort einem KO zugeordnet

Was geht?
- Zeitnah (d.h. direkte) Anzeige des Zustandes (geöffnet / geschlossen) in der Cometvisu (bei ALLEN Fenstern / Sensoren)

Was möchte ich?
- Genau das (s. o.) auch in edomi

Wo ist nun das Problem?
- Tja, das weiss ich eben auch nicht genau...
Beispiel: Fenster Status HWR oben (s. Screenshots): Dieser wird einfach nicht geliefert; andere schon: bspw. Fenster EZ (rot bedeutet in dem Screenshot: linker Flügel offen / grün: rechter Flügel zu). Generell dauert es sehr lange, bis ein Status in edomi ankommt (ca 1/2 Minute bestimmt); d.h. nach Aktivierung des Projektes sind alle Statusfelder ausgegraut und dann bekomme ich bei manchen einen Status und bei anderen leider nicht.

Also zusammgefasst:
- Performanceproblem bzgl. Statusmeldung
- Fehlende Daten bzgl. Statusmeldung

DANKE!

[SeatSLF]

Hast du mal auf das symbol gedrückt?

Sendet dein WG die Werte zyklisch auf den?

Wenn du in Die Zeile Befehle etwas einfügst musst du das Objekt erst "aktivieren"/draufdrücken,
wenn ich mich den jetzt nicht vertue.

Warum machst du nicht einen InitScan beim Start deines Projektes, da werden die GAs auch abgefragt.

[MIT]

Hast du mal auf das symbol gedrückt?
> Ja ... bringt nichts.

Sendet dein WG die Werte zyklisch auf den?
> Weiss ich grad nicht ...

Wenn du in Die Zeile Befehle etwas einfügst musst du das Objekt erst "aktivieren"/draufdrücken,
wenn ich mich den jetzt nicht vertue.
> d.h. die Zeile kann ich ignorieren für eine Statusabfrage? - Habe das mal rausgelöscht

Warum machst du nicht einen InitScan beim Start deines Projektes, da werden die GAs auch abgefragt.
> das führt dazu, dass meine Visu nicht mehr startet (habe es nur mit einem KO (HWR-Status) probiert)

[MIT]

Die Konfig bei dem KO sieht so aus ...

> s. Screenshot

EDIT: und bei den KO, bei denen es funzt, ist es nicht anders. Also doch irgendwelche Einstellungen im WG?

[magiczambo]

Sendet dein WG die Werte zyklisch auf den?
> Weiss ich grad nicht ...

Das wäre schonmal wichtig zu klären. Wenn nicht, dann bekommt Edomi ja nur mit wenn sich am Status was ändert

[MIT]

Kannst Du mir sagen, wo ich das im WG einstellen kann / muss? => Sorry, wenn hier bei edomi etwas OT

[MIT]

Ach ja: Und interessant in dem Zusammenhang ist ja auch, dass das Problem in der Cometvisu nicht auftritt. Die "horcht" doch auch nur am Bus und nicht an internen 1-Wire.IDs ;-)

[magiczambo]

Habe kein WG. Aber zeigt die Comervisu es auch richtig an, nach einem Neustart?

[MIT]

Ja. Statusänderungen werden sofort registriert. Ein Neustart des WireGate? - Ist seit 2012 nicht notwendig gewesen...

[magiczambo]

Ich meine die Cometvisu, nicht das WG.

[fisch3009]

Naja, wenn du deine Cometvisu / Wiregate nicht neustartest, weiß die CometVisu natürlich welchen Status deine Fenster haben, du wirst sie ja bestimmt seit 2012 schon mal auf/zu gemach thaben.
EDOMI weiß nach jeder Aktivierung nichts mehr von den KNX KOs, es sei denn du machst einen Init-Scan, das geht aber nur, wenn dein Wiregate auch auf einen Read Request antwortet (das tut es anscheinend nicht, sonst würde EDOMI mit aktiviertem Init-Scan normal starten, das probiert es nämlich einfach ziemlich lange (einstellbar in der edomi.ini), nach einer gewissen Zeit würde aber auch bei aktiviertem Init-Scan und nicht antwortendem Wiregate die Visu von EDOMI funktionieren und dir Fehler anzeigen).

[heckmannju]

Das wäre schonmal wichtig zu klären. Wenn nicht, dann bekommt Edomi ja nur mit wenn sich am Status was ändert

Wenn man das einstellt tut es das auch default ist das alle 300s die Sensorwerte rausgeschickt werden. Auch das Abfragen beim Edomi Start sollte funktionieren sofern eine GA beim Sensor eingetragen ist. Das kann man aber alles recht gut mit der ETS mit dem Gruppenmonitor Testen.

[heckmannju]

EDOMI weiß nach jeder Aktivierung nichts mehr von den KNX KOs, es sei denn du machst einen Init-Scan, das geht aber nur, wenn dein Wiregate auch auf einen Read Request antwortet (das tut es anscheinend nicht,

Normalerweise macht es das aber recht zuverlässig. Ich würde das wie schon gesagt einfach mal in der ETS Testen dann weiss man wo man als nächstes hinlagen muss. Wenn die CV das zur Zeit aber zuverlässig macht denke ich das das WG nicht das problem ist.

[gaert]

Beim Start von EDOMI sollten/müssen alle Status-GAs vom Bus abgefragt werden (Initscan). In der Basis-Konfiguration (edomi.ini) kann man zudem einstellen, dass auch auf normale "WRITE"-Telegramme reagiert wird - sprich: Wenn ein Busteilnehmer zufällig während der Init-Phase einen Status per Write sendet, wird dies auch als Antwort interpretiert. Dies nur am Rande.

Die Status-GA-Werte werden bei jedem Start intern gelöscht, KNX-GAs können also nicht remanent sein. Dies ist auch sinnvoll, denn alles andere ist m.E. Blödsinn: Wenn sich ein Status ändert während EDOMI pausiert ist, würde EDOMI dies ja nicht mitbekommen. Beispiel: Fenster ist zu, jetzt wird EDOMI pausiert/neugestartet, während dessen(!) wird das Fenster geöffnet... Würde nun kein Initscan erfolgen, wäre das Fenster für EDOMI natürlich noch immer geschlossen - bis sich dieser Zustand während der Laufzeit ändert.

Jeder halbwegs moderne KNX-Teilnehmer kann seine Status-GAs per Read-Request abfragbar konfigurieren (L-Flag). Parametriert man dies alles sauber und korrekt, dauert die Initscan nur wenige Sekunden (Faustregel ca. 20 Read-Requests pro Sekunde - je nach Telegrammrate). Bei 100 Status-GAs würde der Initscan also rund 5 Sekunden benötigen...

[MIT]

Quintessenz daraus ist also: In der ETS bei allen Status-GA das L-Flag setzen und dann den INITSCAN bei allen Status-KO in Edomi aktivieren, richtig?