Tweet
Nee, aber im Ernst - läuft alles tutti hier was Push's angeht.
-
Nee, aber im Ernst - läuft alles tutti hier was Push's angeht.
-
Hey... Also bei mir wird es mit den Push Nachrichten immer schlimmer. Entweder kommen manche Push gar nicht an und wenn dann mit extremer Verzögerung von bis zu 15 min. Habe jetzt schon mehrfach die App mehrfach auf beiden verwendeten Asus Zenfone 6 (Android 11) neu installiert und neu registriert. Weiß nicht wie viele Tickets bei Loxone noch auf gemacht werden müssen? Die Drama mit den Push geht jetzt schon über Jahre und sie bringen es einfach nicht.
GIbt es eine Möglichkeit nach zu sehen wie viele welche Geräte auf'n dem Push-Server(Loxone-Cloud) angemeldet/ registriert sind??Kommentar
-
merhfach? dann wieder ein/ausgestellt oder was bedeutet mehrfach? Und was sagt das def.log? Dort werden Probleme beim Versenden der Pushnachrichten geloggt. Wegen Akku-Optionen am besten mal ein Screenshot einstellen, nicht dass wir aneinander vorbei reden. Ansonsten aufregen nützt nix, das kannst bei Loxone aber hier willst ja vllt Hilfe bekommen
-
Also ich habe jetzt vor ca. 3-4 Wochen meine ganzen push Benachrichtigung und mein Sprechanlage auf einen meiner miniserver der wo am wenigsten ausgelastet ist. Ist ein Gen 2 mit glaub ich 17% auslastung. Und seid her keine Probleme mehr mit Push oder Sprechanlagen Verzögerungen.
Mal schauen ob es auf dauer doch was mit der auslastung zu tun hat. Habe mir auch vom Support sagen lassen das sie inzwischen für sowas immer ein „Hauptgerät“ empfehlen der wo nur dafür zuständig ist.
kann natürlich auch nur eine Verkaufstrategie sein
Kommentar
-
Ich überlege gerade ob ich schon mal ein schwachsinnigere Aussage einer Supportlers gehört habe, und ich habe schon viel Blödsinn von denen gehört.
Nein, habe ich wohl nicht,
Das ist eine ganz normale Netzwerk-Aktion die nun wirklich keine hohe Auslastung erzeugt bzw. sich verzögert wenn man 75% oder höher bei einem MiniServer erzeugt.
Dann wären wohl andere Netzwerk-Aktionen auch langsam/verzögert.
Ich denke Loxone hat da ein Priorisierung-Problem was das angeht.
Kein Support per PN!Kommentar
-
Oder PushOver, etc. verwenden, ging früher auch, als Loxone noch keinen Pushdienst hatte. Also bevor ich mich monatelang ärgern mussKommentar
-
Und bezüglich andere können es alle besser: Heute wieder >1h verspätete Teams Nachrichten bekommen, muss leider damit arbeiten, aber es ist eben bei vielen ein Problem (ganz toll wenn es Alarm-Nachrichten sind, die man schon gelesen hat). Auch ändert z.B. Firebase Push Messaging gern mal etwas (benutzen viele als Gateway für Android und iOS). So haben sie z.B. besondere Vorgaben, wie man mit Fehlern umgehen soll. Wir haben im Betrieb häufiger Fehler mit Firebase und dann muss man nach Google Vorgaben mit Exponential Backoff arbeiten und eben verzögern (= Nachrichten werden später zugestellt). Potentiell gibts da natürlich bessere Systeme (vllt muss man Google Geld zahlen damit sie es besser machen). Und das Thema Akku Optimierung unter Android hatte ja sogar die Corona Warn App lange Zeit unter höchster Beobachtung und Millionen Projekt nicht korrekt umgesetzt und ich kenne noch viele andere die auch damit zu kämpfen haben, natürlich je nach Handy Hersteller unterschiedlich.
Was ich damit sagen will: Es lohnt nicht hier zu pauschalisieren oder direkt zu vergleichen. Und wo konkret die Ursache liegt ist aus der Ferne sowieso sehr schwer zu beurteilen.Kommentar
-
FirebaseCloudMessaging / Google schreibt z.B. selbst, dass sie wichtige Nachrichten mit geringerer Prio verschicken, wenn sie merken, dass der User die Nachrichten selten aufmacht = sie wohl doch nicht so wichtig sind. Oder es gibt noch andere Apps die auch Notifications verschicken und die Quota erreichen:
(https://firebase.google.com/docs/clo...oncept-options)High priority. FCM attempts to deliver high priority messages immediately, allowing the FCM service to wake a sleeping device when necessary and to run some limited processing (including very limited network access). High priority messages generally should result in user interaction with your app or its notifications. If FCM detects a pattern in which they don't, your messages may be de-prioritized. Android P introduced app standby buckets which limit the number of FCM high priority messages you can send to your app that don't result in the user using your app or viewing a notification. If, in response to a high priority message, a notification is displayed in a way that is visible to the user, then your app standby bucket quota will not be consumed by that message.Kommentar
-
Ich habe schon mit den Akku Einstellungen meines Asus und das meiner Frau "herum" probiert und verschiedene Einstellungen ausprobiert etc.....
im Moment läuftvdie die Einstellung siehe Bilder...Kommentar
-
Kommentar
-
Hallo zusammen,
ich hab mir grad die Zeit genommen um die Probleme mit dem Loxone-Push etwas zu analysieren und ich denke mittlerweile, dass die Probleme auf Seiten des Miniservers liegen.
Was habe ich getan?
Ich hab den Netzwerktraffic des Miniservers per tcpdump analysiert. Wenn eine Notification benötigt wird, dann löst der Miniserver erstmals den dns auf push.loxonecloud.com auf. Danach kommuniziert er mit dem Server direkt. Die Verbindung zum Server findet verschlüsselt statt (Port 443). Wenn ich mehrere Push-Notifications auslöse dauert er unterschiedlich lang bis der Miniserver mit dem Server kommuniziert.
Beispiel:
Sekunde 0: Notification ausgelöst
Sekunde 6: Nachricht geht an push.loconecloud.com
Sekunde 7: Push-Notification kommt am iPhone an.
Sekunde 0: Notification ausgelöst
Sekunde 3: Nachricht geht an push.loconecloud.com
Sekunde 4: Push-Notification kommt am iPhone an.
Sekunde 0: Notification ausgelöst
Sekunde 15: Nachricht geht an push.loconecloud.com
Sekunde 16: Push-Notification kommt am iPhone an.
Seht ihr das Muster? Das Problem scheint am Miniserver zu sein.
Erst dachte ich, dass die Verschlüsselung das Problem ist. Die braucht ja doch etwas Leistung. Ich habe einen Miniserver v1, der ~78% ausgelastet ist.
Also hab ich mir als nächstes die Loxone Diagnose angeschaut in der Loxone Config. Da kann man die CPU Auslastung ablesen, die ist bei mir immer so ca. 50%. Man kann sich dort auch Log-Einträge anzeigen lassen und siehe da, man kann da den Fehler auch gut sehen, wenn man sich die Zeit nimmt durch alles durchzuscrollen:
Hier kommt der Request, der den Push auslösen soll.
Dann kommt jede Menge Zeugs (Rasenmäher, Heizung, Lüftung, UDP Message, Medien-Center, etc, etc.), die CPU Last bleibt derweil bei ca. 50%.
Und dann beginnt die Kommunikation mit dem Push-Server:
Man sieht am Timestamp, dass zwischen dem auslösenden Event und dem Aufbau der TCP Verbindung zum Push-Server bereits 10 Sekunden vergehen. Zeitgleich zum Verbindungsaufbau geht die CPU Last für 2-3 Sekunden auf ca. 85% hoch, dann wieder zurück auf die ca. 50%.
Ja, da hat wohl Loxone einen Bug.
Ich vermute trotzdem noch, dass es etwas damit zu tun hat, wie viel Last der Miniserver hat. Ich habe jede Menge Funktionen und nutze den Miniserver ausgiebig. Mein Schwager der grad erst gebaut hat und kaum mehr als Licht und Intercom nutzt und gleichzeitig den Miniserver v2 hat, hat keine Probleme mit verzögerten Benachrichtigungen.
Vielleicht hilft uns diese Erkenntnis weiter, das Problem einzukreisen und hoffentlich irgendwann zu lösen.
Viele Grüße
StephanKommentar
-
Ich hab eben ein Ticket bei Loxone dazu aufgemacht. Mal sehen was sie dazu sagen. -
Update:
Pixi wollte Zugriff auf meinen Miniserver, habe ich eingerichtet, sie haben dann aber scheinbar doch nicht zugegriffen. Aber mir mir zurückgemeldet, dass sie das Problem nicht nachstellen können. Danach hab ich angeboten, das Problem mit ihnen gemeinsam nachzustellen und darauf warte ich jetzt seit zwei Tagen auf Reaktion. -
Schon irgendeine Nachricht von Loxone? Ich bekomm Push Benachrichtigungen auch seit 1-2 Monaten stark verzögert aufs iPhone. Hab vor kurzem Miniserver upgedated auf die akutellste version und seither kommen die Pushbenachrichtigungen total random verzögert. Manchmal gleich, manchmal eine Minute "zu spät", Stichwort Intercom. Uns ist es aufgefallen weil wir eine Benachrichtigung bekommen wenn die Waschmaschine fertig ist. Das ist seit 4 Jahren immer das gleiche (logik dafür wurde nie geändert), aber seit kurzem kommt die Info oft 15 minuten später. Sehr interessant.
-
-
Gibt’s hier schon neue Erkenntnisse? Bei mir ist meistens die Benachrichtigung von doorbird und loxone push mehr oder wenig gleich schnell…2-5 Sekunden. Aber manchmal kommt teilweise entweder doorbird nicht oder loxone nicht…..oder erst wenn man das iPhone entsperrt. Etwas seltsam. Dank doppelter Benachrichtigung noch zu ertragen aber an sich nicht gut!?Loxone: MS Gen1, Audioserver +5 St. Ext, NFC(s), Air, Dimmer, Relais
Sonstiges: Unifi System, Doorbird, PV-Anlage Solaredge + Lg 10H Prime Speicher, NUC iOBroker
KNX: BWM, Glastaster II, div. Schaltaktoren und RGBW DimmerKommentar
-
Ich hab hierzu ein paar Neuigkeiten. Bei mir hat sich das Problem von einem Tag auf den anderen von selbst gelöst. Am MS wurde nichts verändert, allerdings habe ich ein paar falsche DNS Einträge in meiner Fritzbox aufgeräumt und kurz darauf ist mir die Veränderung aufgefallen.
Die DNS-Einträge wurden auch vom MS benutzt (HTTP-Eingang), hatten aber eigentlich nichts direkt mit den Push Nachrichten zu tun. Ob es wirklich dadurch gefixt wurde, kann ich natürlich nicht sagen, aber evtl. hilft es ja dem ein oder anderen mal in dieser Ecke zu suchen.
Bei Eingeschaltenem Handy ist die Push-Nachricht jetzt fast gleichzeitig zu den Durchsagen des MS4H bzw. etwa 2-3 Sekunden später im Vergleich zum Loxone-UI auf dem Tablet (Eco-Modus).Kommentar
-
Die HTTP Eingaenge waren nicht ueberwacht, weshalb es keine Systemmeldung dazu gab, aber ja ich denke es gab Timeouts da es kein Geraet mit der IP-Adresse gab auf den die Eintraege gezeigt haben (Die Fritzbox hat es zwar richtig angezeigt, aber der DNS was anderes ausgeliefert...)
Das mit den begrenzt zur Verfuegung stehenden HTTP Verbindungen klingt fuer mich logisch, allerdings wuerde ich mir dafuer eine Ueberwachung oder Systemmeldung dazu wuenschen...
-
Dann hier nochmal presenter als im Kommentar:
Wie schon als Ursache für Reboots sind Timeouts eine häufige Ursache für Probleme wie auch hier.
Hintergrund: Der Miniserver hat nur begrenzte Ressourcen und kann nur x parallele HTTP Verbindungen aufmachen bzw. Befehle absetzen. Die Pushnachricht wird auch per HTTP rausgeschickt. D.h es kann zu ganz seltsamen Seiteneffekten kommen, auf die man zuerst gar nicht kommt. Wenn dann keine Verbindung mehr zur Verfügung steht, werden Aktionen verzögert ausgeführt.
Also wichtiger Hinweis: Checkt eure HTTP Aktionen, dann wird auch der Frust weniger
Kommentar
-
Man könnte aber auch Loxone fragen ob es möglich ist dass der MS das selbst feststellt und in einem Log ablegt. Würde auch den Supportaufwand reduzieren.Es ist nie zu spät für eine glückliche Kindheit.Kommentar
-
Johannes Bartnitzke
Wie meldet man euch am besten Verbesserungsvorschläge die technisch fundiert sind? Soll heißen, es wurde schon einiges analysiert und die Verbesserungsvorschläge kommen von Leuten, die auch langjährige Erfahrung haben (weil sie es auch sonst nicht analysieren könnten). Dann wäre es natürlich schade, wenn solche Vorschläge gleich an der ersten Hürde Support scheitern, weil dort wird ja nicht alles durchgelassen, und technische Themen wie HTTP-Connection-Pool bestimmt kein Standard-Thema beim Support sein werden.
Einem Entwickler wird der Vorschlag "bessere Kommunikation bei Ressourcenengpass" aber bestimmt gefallen, weil solche Probleme meistens auch zeitintensiv im 2nd/3rd Level Support hängen.Kommentar
Kommentar