Alarmanlagen-Forum - Alarmforum - Fachforum für Sicherheitstechnik

Normale Version: Zyklenzeit comXline 1516 GSM und 3516 GSM alte FW Version
Sie sehen gerade eine vereinfachte Darstellung unserer Inhalte. Normale Ansicht mit richtiger Formatierung.
Hallo zusammen,

mir ist bei der 19er Firmware der 1516 GSM/3516 GSM bei einer Testanlage aufgefallen, dass die Zyklenzeit in den Anwahlfolgen offenbar ignoriert wird, wenn das Ethernet Link hat, aber über kein Internet verfügt (SIA DC09).

Kann die UEs gerade nicht updaten, da mir die Files gerade nicht vorliegen. Wenn man sich so die Changelogs durchsieht scheint das aber auch nie gefixt worden zu sein?!

Also folgendes Fehlerverhalten:

- UE hat Link (Netzwerkstecker drin) aber keinen Internetzugriff
- Meldung erfolgt: UE wählt 1. Teilnehmer an und meldet erst nach 30 Sekunden (egal ob eine kürzere Zyklenzeit angegeben ist oder nicht): Keine Quittung
- Erst nach den 30 Sekunden wird der nächste Teilnehmer über den nächsten eingestellten Übertragungsweg angewählt


Ergo: Es vergehen 30 Sekunden in denen einfach nichts passiert. Reicht um die Zentrale soweit zu killen dass auch GSM mäßig nichts mehr käme.

Werde es mir die Tage mal ansehen ob das mit der aktuellen Firmware auch so ist. Kann es mir eigentlich nicht vorstellen. Die 19er FW ist ja durchaus schon etwas in die Tage gekommen ;-)


VG
Das was du beschreibst, ist nicht die Zyklenzeit. Die Zyklenzeit greift erst dann ein, wenn ein Zyklus, der über die Anwahlfolge definiert wird, nicht komplett erfolgreich war.

Also du hast in der Anwahlfolge drei Teilnehmer, von denen einer quittieren muss (z.B. 1, 2, 3, Ein Teilnehmer) und keiner von diesen Teilnehmern ist erreichbar, dann erfolgt nach dem letzten Teilnehmer eine Pause, die über die Zyklenzeit definiert wird, ehe wieder beim ersten Teilnehmer begonnen wird.

Das was du beschreibst, ist das ganz normale TCP/UDP-Timeout und ist nicht veränderbar. Um dieses Verhalten zu ändern, benötigst du eine Aufschaltung mit Standleitung oder Standleitungscharakter, so dass ein Verbindungsausfall erkannt werden kann.

Denk dran: Firmwareupdate = neue CompasX-Version
Ah ok. Danke ;-)

War irritiert davon dass exakt diese 30 Sekunden als Standard auch dort drinstehen.

So wirklich sinnvoll gelöst seitens Telenot scheint mir dies aber nicht so ganz.
(24-03-2022 18:19)laalaaa schrieb: [ -> ]So wirklich sinnvoll gelöst seitens Telenot scheint mir dies aber nicht so ganz.

........hat sich aber seit vielen Jahren so bewährt. Wink
Zitat:Das was du beschreibst, ist das ganz normale TCP/UDP-Timeout und ist nicht veränderbar. Um dieses Verhalten zu ändern, benötigst du eine Aufschaltung mit Standleitung oder Standleitungscharakter, so dass ein Verbindungsausfall erkannt werden kann.
Abgesehen davon dass der Timeout eines UDP-Sockets schon einstellbar ist (ich aber fairerweise nicht weiß es ob in den Spezifikationen vorgesehen ist den unter 30 Sekunden zu stellen): Nichts zwingt die Anlage dazu zu warten, bis der Socket getrennt ist? Oder erfodert das verwendete Übertragungsprotokoll das wirklich?

Im Falle von SIA-IP ist es ja bspw. so, dass eine Rückmeldung des Empfängers kommt. Und wenn der nach Zeit X ist nicht da ist, kann die Zentrale ja einfach die Verbindung trennen. Ist das beim hier verwendeten Protokoll nicht so?

Zitat:Ergo: Es vergehen 30 Sekunden in denen einfach nichts passiert. Reicht um die Zentrale soweit zu killen dass auch GSM mäßig nichts mehr käme.
Als ob ein Einbrecher innerhalb der ersten 30 Sekunden nach der ersten Alarmauslösung deine Zentrale findet? Das ist doch bei sinnvollem Montageort der Zentrale völlig unwahrscheinlich.
Bei Telenot ist das UDP/TCP-Timeout es nicht einstellbar, zumindest nicht kunden- oder errichterseitig.

Das kann höchstens Telenot, wohl aber eher NXP als CPU-Hersteller und SDK-Lieferant.

Die ÜE muss halt einfach auch etwas warten. Bei UDP wird einfach ins Internet geblasen, ohne zu Wissen, ob überhaupt irgendwer auf der Gegenstelle ist. Hier ist die ÜE in der Pflicht, sicherzustellen, dass wirklich jemand da ist. In der Regel wird aber eher TCP verwendet und wenn es hier zu keinem Verbindungsaufbau in einer gewissen Zeit (TCP arbeitet normal mit einem Timeout im Minutenbereich) kommt oder der ÜE die Antwort der AE nicht passt, weil die nicht kommt, nicht schnell genug kommt oder fehlerhaft ist, gibt es ein "nicht quittiert". Aber dieser Zeitraum ist nicht einstellbar.

Die einzige Stelle, an der man die Quittierungswartezeit einstellen kann, ist Sprache, SMS und E-Mail in der Quittierungsart "per Rückruf". Also in dem Fall nicht anwendbar.
Ne, ich wollte damit sagen, dass er seitens Telenot einstellbar wäre oder einstellbar gemacht werden könnte.

Aber ich denke auch, dass 30 Sekunden absolut in Ordnung sind. Eine gewisse Wartezeit ist ja sinnvoll und nötig. Man darf nicht vergessen, dass es auch durchaus Internetverbindungen z.B. per geostationären Satellit gibt, bei denen die einfache Paketlaufzeit schon bis zu 5 Sekunden betragen kann. Da wäre man dann schon bei einer reinen Paketlaufzeit von 10 Sekunden.
Referenz-URLs