Benachrichtigung per Anruf stark verzögert

[mike505]

Hallo,
habe mir in der letzten Woche die XT2 Plus zugelegt. Die Anlage funktioniert auch sehr zuverlässig. Allerdings dauert es ungewöhlich lang, bis ich per GSM angerufen werde (ca. 2-3 Minuten!!). Habe eine Telekom Sim aber auch eine Simyo Sim benötigt die gleiche Zeit. Wartezeiten für die Alarmierung sind alle deaktiviert. Empfang ist bei 9, also optimal.
Auch das heutige Firmware-Update brachte keine Besserung.
Kann man noch irgendwo was einstellen?
Oder habe ich was übersehen?

Gruß Mike

[senator]

Hallo! Habe mir gestern auch eine XT2 zugelegt und exakt das gleiche Problem ... locker einer Verzögerung bis zu 20 Minuten! Geht gar nicht! Hat irgendwer schon eine Lösung dafür?

Und ja, habe die neueste FIRMWARE oben ...

lg Martin

[Cursor]

Ist der Anruf denn die erste Benachrichtigung, welche von der Anlage abgesetzt wird oder kommen davor noch weitere?

Beste Grüße

Alex

[esingen]

20 Min. ist aber mal ne Hausnummer!
Hauptsache Push oder E-Mail kommen zumindest schneller an.

[funkistnichtalles]

meine meldet innerhalb von 30 sec. An eine NSL.
Mail braucht länger. SMS nutze ich nicht.
20 min glaube ich nicht. Da läuft was anderes im Argen

[MTRX]

Hab' ja auch schon überlegt, ob ich diesbzgl. mal ein Thema aufmache. Bei mir ist es nämlich genauso: 2-3 min bis ein Anruf oder eine SMS durchkommt.

Wollte das nachts eigentlich als stillen Alarm haben, so dass nur das Smartphone im Schlafzimmer (leise) klingelt. Aber mit der Verzögerung ist mir das zu mutig.

@senator:
Mit den 20 min schließe ich mich funkistnichtalles an. Da stimmt was anderes nicht.

Vielleicht die SIM mal in einem Telefon ausprobieren? Funktionieren SMS über Handys in der Umgebung gut? Evtl. ist zwar der grundsätzliche Empfang gut, trotzdem könnten Interferenzen den SMS-Versand stören und damit dermaßen verzögern.

[Hano217]

Habe gerade eben zweimal eine Test-SMS aus der XT2+ verschickt.

Kamen beide nach ca. 7 -8 Sek. auf dem Smartphone an.

In der XT2+ eine SIM-Karte von Gongstar und im Smartphone Telekom.

Also beides im gleichen Mobilfunknetz.

Kann vielleicht verschiedene Mobilfunknetze ein Grund für die lange Dauer sein?

[senator]

Hi! Also der Kundenservice hat mir geholfen. Schuld war der eintrag vom gateway 1 und 2. der wurde korrigiert und jetzt ist die verzögerung 10sec

Allerdings hab ich jetzt ein anderes problem. Die area2 kann ich nicht editieren. Somit bekomme ich jedesmal beim aktivieren die standardmässige eingangsverzögerung..... hat wer einen rat?

[Torte]

ja, auf ein korrigiertes Firmware Update warten bzw. den Fehler an Lupus melden, siehe http://www.alarmforum.de/Thread-XT2-Firm...1#pid69701

[blattwerk]

Ich muss das Thema hier nochmal ausgraben.

Heute Morgen habe ich einen Probealarm getätigt, also Anlage scharf geschaltet und Kontakt geöffnet.
Die Außen- und Innensirene reagierten wie gewünscht mit Alarm, jedoch blieben die Benachrichtigungen per Telefon, SMS, Push und E-Mail aus.

Nach Alarmauslösung traf
nach ca. 20 Min. die Pushmeldung,
nach ca. 22 Min. die telefonische Benachrichtigung sowie SMS
und nach ca. 1 Stunde die Alarmmeldung per E-Mail ein.

Aufgefallen ist mir dies im Vorfeld bereits, da Pushmeldungen von Arm und Disarm verzögert ankommen sind. Das dieses Problem jedoch auch die telefonische Benachrichtigung und SMS betrifft, verwundert mich sehr.
Komisch ist, dass gesendete Test SMS unverzüglich ankommen (2-3 Sek.). Die Systemlogs zeigen auch keine Auffälligkeiten.

Einige beschreiben hier ähnliche Probleme und haben möglicherweise inzwischen Tipps parat.

[blattwerk]

Bezüglich der Thematik habe ich den Support kontaktiert.
Dieser riet mir, die Batterie auf off zu stellen und die Anlage für 5 Min. vom Strom zu trennen.

Leider brachte dies aber nicht den gewünschten Erfolg.
Die Anrufbenachrichtigungen kommen weiterhin bis zu 30 Minuten verzögert, ebenso die SMS und E-Mail-Benachrichtigungen sowie die Push-Benachrichtigungen.

Ich weiß momentan nicht mehr weiter.
Hat jemand von euch eine Idee?

[funkistnichtalles]

wenn diese Meldungen auch im heimischen Netzwerk verzögert kommen, dann würde ich auf fehlerhafte Einstellungen tippen.
Schreibe mal die Einstellungen auf und stelle auf DHCP um, lasse die Anlage neu booten und beobachte Veränderungen. Im eigenen LAN oder Wlan müssen die innerhalb von 5sec da sein. Extern bist Du stark vom Netzanbieter abhängig, bei gewissen Prepaidkarten kommt es schon mal zu Engpässen, je nach deren Kontigentauslastung. Die grossen Anbieter priorisieren schon ihre eigenen Kunden. da bleibt für die zugekauften oft mal die hintere Reihe übrig.
Welcher Mailserver wird benutzt?

[blattwerk]

Hallo FINA,
dickes D A N K E für deine Hilfe!

Ich bin heute Morgen schier verzweifelt und habe sogar schon meine Fritzbox für die Probleme verantwortlich gemacht

Wie du richtig vermutet hast, lag es tatsächlich an dem Mailserver.
Mein Internetprovider ist die Telekom und der Mailserver läuft über 1und1 IONOS.

Allem Anschein nach gab es mit dem bestehenden 1und1 Postfach Probleme und dies hat den ganzen Systemprozess der Lupus gelähmt.
Nach deinem Tipp hatte ich temporär unsere Telekom E-Mail eingetragen und siehe da, es funktionierte.

Jetzt habe ich ein neues Postfach bei 1&1 IONOS eingerichtet und auch damit funktioniert es.

Möglicherweise haben die Probleme bei 1und1 etwas mit der Umfirmierung zu IONOS zu tun, da beispielsweise der Server von "smtp.1und1.de" zu "smtp.ionos.de" geändert wurde und auch der Port bei SSL wieder 465 ist.

Du hast mir meinen Sonntag gerettet.
Nochmals vielen Dank und liebe Grüße.

[blattwerk]

Zu früh gefreut...

Das Problem der Verzögerung ist nun wieder da.
Aufgefallen ist es mir, dass Pushmeldungen zu periodischen Tests um 30 Min. zeitverzögert ankommen.
Bedeutet: Anlage führt periodischen Test um 11:09 Uhr durch, die Pushmeldung erreicht das I-Phone um 11:41 Uhr.

Damit nicht genug. Das gleiche Fehlerbild tritt bei einem Alarm auf. Zeitverzögert werden dann auch die telefonische Alarmierung sowie die Alarm-SMS zugestellt.

In den Systemereignissen tauchen Fehlermeldungen wie diese auf:

url='apns://0@e4560de344d26d98e0d8b6277442f035211e9f1128cb8d85bb001b519d0111fb/TEXT', ret=-701, reason='ACK-Zeitüberschreitung', event=602, text='Area 0 Zone 0 : Periodischer Test'

Bin wieder mal ratlos.

[bastelheini]

APNS ist der Apple Push Dienst. Zeitüberschreitung sagt hier wohl aus, dass die Anlage nicht innerhalb eines gewissen Zeitraums zum Dienst durchgekommen ist. Das kann mehrere Gründe haben:

a) Routing/FW in deinem Netzwerk -> dann würde es aber nie gehen, wenn du jetzt nicht größere Böcke im Netzwerk krum hast
b) Routing im Internet, Überlastung beim Push-Dienst selbst (schließe ich jetzt mal aus)
c) Ggf. ein Implementierungsfehler in der Lupusec, wenn die Anlage "mehrere Nachrichten in einem gewissen Zeitraum verschicken will"

Der letzte Eintrag heißt folgendes: Apple möchte, dass man möglichst eine offene stehende Verbindung zu deren Push-Dienst aufrecht erhält (Socket-Verbindung), anstatt für jede Nachricht eine neue Verbindung aufzubauen und zu schließen. Bei Google und damals bei Microsoft war das kein Problem... Willst du bzw die Anlage also recht häufig Nachrichten verschicken (ich kann dir da keine Menge noch Zeitraum nennen, denn Apple nennt keine Werte - wir hatten das vor ein paar Jahren mal in einem Dienst implementiert, das ging ziemlich schnell), so wertet Apple das als Angriff (DoS) und macht zu. Ich denke, die Folge sind dann diese Timeouts - die Anlage versucht zu verbinden, aber der Apple Server lässt die Verbindung ins Leere laufen.

Da ich kein Apple Gerät da habe und auch generell kein Push der Anlage nutze (da es im Endeffekt a) eine externe Verbindung ist und b) Interne Nachrichten der Anlage öffentlich ins Netz shared - ich weiß nicht, ob die App da eine Metasprache verwendet, mache das alles über eine eigene App), ist das reine Spekulation, ob das sauber in der Anlage eingebaut ist. Da ich aber einen anderen Bug beim Aufruf von Push-URLs bemerkt und reportet habe (bis heute mE nicht behoben, verursacht auch einen 2-Min Timeout, in der die Anlage keine weiteren Push-URLs antelefoniert), erlaube ich mir mal, zu hinterfragen, ob sie das richtig implementiert haben.

Probier auf jeden Fall mal, die Push-Aktivierungen abzuschalten und auch in deiner App zu deaktiveren und lass es ruhen und schaue, ob die anderen Wege wieder schnell sind. Wäre auch sehr doof, wenn eine hängende Netzwerkverbindung die anderen Prozesse blockieren würde...

Wenn das klappt, mal wieder Push dazu holen für 1-2 Nachrichten und schauen, ob die wieder direkt zeitgenau eingehen. Wenn das klappt, einfach mal eine Push schicken lassen, wenn ein Fenster aufgemacht wird und das ein paar mal durchführen im Minutentakt. Wenn es dann wieder einbricht und Log-Einträge aufkommen, dann sieht es arg nach diesem Problem aus.

https://developer.apple.com/library/arch...4-CH11-SW1
"[..]Keep your connections with APNs open across multiple notifications; do not repeatedly open and close connections. APNs treats rapid connection and disconnection as a denial-of-service attack. You should leave a connection open unless you know it will be idle for an extended period of time—for example, if you only send notifications to your users once a day, it is acceptable practice to use a new connection each day.[..]"

[funkistnichtalles]

viel Text, aber substanziell nicht viel, sorry. Es könnte eine schwierige Erklärung für sein Problem sein, was ich aber nicht vermute. Denn: dann würden auch andere User (mich eingeschlossen, da ich für die Kundschaft sowohl Android als auch IOS vorhalten muss) über Probleme klagen.
In einzelnen und auch vermehrten Fällen haben wir das Phänomen kennengelernt, dass sich das System nicht zwischen IPV6 und IPV4 entscheiden kann.
Abhilfe bringt hier bis jetzt aus der Erfahrung heraus die reine IPV4 Übertragung. Man hört hier aber aus dem Forum, dass nicht alle Anbieter dies zulassen. Somit muss jeder selbst prüfen.
Zur INfo: meine Anschlüsse und die, auf die ich Zugriff habe, stelle ich auf reinen IPV4 Betrieb um, auch im Dual Stack lasse ich das nach Möglichkeit via Hotline umsetzen. Sie wollen meist nicht, aber wenn man sagt, dass da ne Alarmanlage im Spiel ist, knicken sie aber ein.

[bastelheini]

Das IPv4/6 Thema ist idR eigentlich eher ein eingehendes Traffic - Problem, da man vom Provider keine dedizierte IPv4-Adresse bekommt, sondern der Provider für mehrere Kunden eine einzige externe IPv4 vergibt und das dann intern als NAT fährt und damit nur vom eigenen Netz ausgehende Anfragen beantwortet werden.

Oder kannst du mir sagen, was du meinst, was da sonst klemmen könnte. Ob er ausgehen ipv4 oder 6 nimmt, ist eigentlich egal, denn APNS kann beides problemlos.

Dass es andere Kunden vielleicht nicht "merken", könnte eben an der Menge der Nachrichten pro Zeitraum liegen. Wenn da 3x am Tag verteilt Nachrichten rausgehen, passiert halt auch nix, weil 3 Einzel-Verbindungen mit Stunden-Abstand. Bei 5 pro Minute kann es schon sein, dass die eben zumachen. Wir haben das vor Jahren tatsächlich so in der Entwicklung selbst feststellen müssen, dass die sehr zügig zugemacht haben.

Daher einfach mal ausprobieren, was ich schrieb, um das auszuschließen. Andere Lösung wäre den Traffic zu monitoren und via Wireshark auszuwerten, aber ich denke, das fällt hier aus, da als Laie nicht verwertbar.

[funkistnichtalles]

sehe ich nicht so, denn wir haben mehrere Alarmanlagenkunden mit unterschiedlichen Anbietern, jedoch meist Vodafone Kunden, wo es im IPV6 ausgangsseitig in den Protokollen einfach nicht funktioniert. Gerade CID ist da seltsamerweise betroffen, wo das doch am nähesten an der Telefonie bzw. Faxen via Modemtöne ist. Meiner Meinung nach hängt das mit den Übertragungsgeschwindigkeiten zusammen, da die Quittierungen einfach nicht mehr sauber erfolgen. Im normalen Internetverkehr spielt das keine Rolle, da die Anfragen ja via Browser und deren Cookies und Skripten geregelt sind, bei Übertragungsprotokollen und deren Derivaten sehe ich das anders.

[bastelheini]

(08-10-2020 15:22)funkistnichtalles schrieb:  sehe ich nicht so, denn wir haben mehrere Alarmanlagenkunden mit unterschiedlichen Anbietern, jedoch meist Vodafone Kunden, wo es im IPV6 ausgangsseitig in den Protokollen einfach nicht funktioniert. Gerade CID ist da seltsamerweise betroffen, wo das doch am nähesten an der Telefonie bzw. Faxen via Modemtöne ist. Meiner Meinung nach hängt das mit den Übertragungsgeschwindigkeiten zusammen, da die Quittierungen einfach nicht mehr sauber erfolgen. Im normalen Internetverkehr spielt das keine Rolle, da die Anfragen ja via Browser und deren Cookies und Skripten geregelt sind, bei Übertragungsprotokollen und deren Derivaten sehe ich das anders.

Das APNS ist aber im Grunde völlig normaler "Internetverkehr", da ist eigentlich nichts spektakuläres bei. Man connected sich einfach zu einem Server, der über eine Domain (https:://api.push.apple.com:443 oder 2197) erreichbar ist - so wie es im Prinzip auch der Browser tut.

@blattwerk: Wie bist du denn ins Internet angebunden? Welcher Provider, welches Produkt?

[funkistnichtalles]

wenn das "normaler" Internetverkehr ist, warum wird es dann von innen nach aussen blockiert?
Jetzt frage ich dich als IT Käpsele: wo ist die Erklärung!
Ich sehe das so: wenn der Traffic von innen nach aussen vonstatten gehen soll, fängt irgendetwas das blockieren an. Verzeihe meine deutsche Ausdrucksweise, ich hassse Anglizismen.
Der Verkehr, der von der Anlage ausgehen soll, wird also durch irgendeine Funktion des Routers geblockt, sei es durch eine Firewall, sei es durch einen Sprung durch die IPV4 oder IPV6 Welten. Nach meiner Erfahrung will jeder dieser Wege Chef sein, dann kommt der Timeout über den appleacount und es dauert so lange, bis einer seinen Timeout erreicht hat, Genau dann kommt die Meldung durch.
Verzeihe meine diletantische Ausdrucksweise, aber ich kriege das nicht anders hin.
Jedoch: ich kann dieses Phänomen mit dezidierten Kommandos und Strukturen nachstellen.
Deswegen mein Workaround auf reines ipv4 .ö Macht es oder lasst es. Ich komme damit klar und meine Anlagen funktionieren. Ich muss nicht alles im Detail von Apple und Google wissen, sondern ich stehe auf 17.00 Feierabend.
Forumsarbeit ist keine Arbeit, sondern Entspannung und Erweiterung des Horizontes. Wenns zu nix führt, so what. Ich denke, du musst da mehr liefern als deine Angliszismen, deine Fakten sind mehr als dünn und auch nicht mehr als stöbern in der ominösen Cloud.
Siehe meine Signatur.