Verhalten des Edomi-Homescreen-Links auf iOS

[ponG]

Hallo zusammen,

kurze Frage: Ich habe die Edomi Visu als Link auf dem Homescreen unser iOS-Devices hinterlegt. Klappt auch soweit, allerdings wird die Visu bei jedem neuen Aufruf der "App" neu geladen, also erst der rotierende große rote Kreis, dann kurz der kleine, dann kommt meine Startseite.

Ist das so weil "ist so" oder kann man über irgendeine Einstellung beeinflussen, dass der Browser die letzte Seite behält? Oder sich halt verhält wie über Popup-Schließzeiten oder Bildschirmschoner gewünscht?

[jonofe]

Ich denke es liegt daran, dass Apple persistente Netzwerkverbindungen im Hintergrund verbietet. Daher wird vermutlich die Websocket-Verbindung zwischen Browser und EDOMI Backend getrennt. Dies führt dann zu dem beobachteten Verhalten. Ist nur eine Vermutung, vielleicht hat ja jemand mit iOS Programmiererfahrung genauere Infos.

[Marha]

Ist bei mir unter iOS auch so. Ich dachte, das ist halt so, sobald der Sperrbildschirm kommt. Ist das bei Android anders?

[jonofe]

Ist das bei Android anders?

Jep, an meinem XORO Tablet erscheint direkt die VISU. Kann aber sein, dass nach einer längeren Zeit im Hintergrund auch hier die Websocket Verbindung getrennt wird. Habe ich noch nicht getestet, da es ein stationäres Display ist, bei dem ich normalerweise nur kurzfristig umschalte und dann auch gleich wieder zurück auf die VISU schalte.

[Hendrik2020]

Aber ist doch eigentlich nicht schlimm, zumindest bei mir hängt das Ipad an der Wand und bleibt ohnehin den ganzen Tag an. Außer bei nem Neustart vom Edomi muss man sich ja nicht neu „einloggen“.

[ponG]

Bei mir ist aber dsa iPhone das primäre Visu-Device

[eric4980]

Ich habe das gleiche Problem :-( Wäre auch sehr an einer Lösung interessiert :-)

Viele Grüsse
Eric

[rdeckard]

Ich habe auch ein iPad an der Wand und nerve mich eigentlich immer wieder an diesem Verhalten. Vorallem, weil es sich früher mal anders verhielt (unter iOS).
Ob das mit einem Edomi Update oder mit einem iOS Update kam, weiss ich nicht mehr. Ich weiss nur, dass es damals in einem anderen Thread ein Thema war, aber niemand eine Lösung kannte. Und soweit ich mich ganz schwach erinnere, lag es nicht an Edomi, sondern geschah plötzlich ab einer neuen iOS-Version. Vielleicht finde ich den Thread nochmals, dann wüssten wir zumindest ungefähr den Zeitpunkt und die iOS Version.

Mein iPad ist übrigens immer an und auch Edomi läuft als Web App. Trotzdem muss man sich nach jedem Standby des iPad diese Start-Prozedur übergehen lassen. Man kann das nicht verhindern. Und wenn man nur schnell was prüfen möchte oder eine Licht-Szene aktivieren möchte, ist diese Wartezeit gefühlt ewig.

[rdeckard]

Hab hier ein Thread gefunden, wo das Thema schon mal besprochen wurde. Der Thread stammt von Ende 2018 !
https://knx-user-forum.de/forum/proj...e-nach-standby

[wintermute]

Unter OSX hilft es wohl (zumindest bei mir) den Befehl "caffeinate" im Hintergrund laufen zu lassen. Was natuerlich keine Loesung fuers iPhone ist, schon klar... wollte das nur erwaehnen

[rdeckard]

Ich habs jetzt noch nicht genauer analysiert (obwohls mich offenbar schon über 2 Jahre ärgert ), aber wenn mein iPad dunkel wird, dann sehe ich in der Edomi Admin Konsole, dass die "Session" verschwindet. Wacht das iPad wieder auf und der grüne Kreis ist durch, dann wird die "Session" wieder angezeigt. Die Login-Zeit ist aber älter, was zeigt, dass der Standby kein Logout verursacht, sondern "nur" ein Unterbruch der Verbindung.

Früher wurde aber offenbar bei solch einem Standby die Netzverbindung im Hintergrund offengelassen, sodass Edomi ohne roter/grüner Kreis sofort wieder da war.

Selbst wenn es ein "caffeinate" auch für iOS gäbe, es wäre nicht unbedingt das, was ich erreichen möchte. Denn dann würde vermutlich das iPad gar nicht mehr in Standby gehen. Aber ich möchte ja nicht, dass es ständig läuft. Zumindest nicht der Bildschirm. Da mein iPad eh am Netz hängt, wärs mir egal, wenn im Hintergrund ständig die WiFi-Verbindung gehalten würde. Solange das Display sich ausschaltet (und nur black ist keine Option, da es in der Nacht wegen dem Backlight immer noch zu hell wäre).

Ich frage mich, ob ein alternativer Browser sich hier evtl. anders verhält bzw. man den so konfigurieren könnte. Ich bezweifle es aber.
Ich bin mir nicht mal sicher, ob eine native iOS App das Display komplett deaktivieren kann, OHNE die WLAN-Verbindung zu trennen. Ansonsten wäre dies die letzte Option, zumindest für die iOS-User. Aber diese App müsste man natürlich auch erst programmieren.

Ich dachte, es wurde hier mal von einem Projekt von einer iOS Browser/Kiosk-App für Edomi gesprochen. Irgendjemand hatte sogar schon eine frühe Alpha-Version. Aber schien irgendwie eingeschlafen zu sein (Standby ).

Ich habe schon native Swift Apps mit Xcode programmiert. Aber eher oberflächlich. Und auch wenn solch eine "Browser"-App theoretisch ganz minimalistisch gehalten werden kann, so kann eben der ganze Energiespar-Kram doch schnell herausfordernd werden. Und ich befürchte, dass ich dazu doch zuwenig Know-How und vorallem auch zuwenig Zeit habe.

[jonofe]

Früher wurde aber offenbar bei solch einem Standby die Netzverbindung im Hintergrund offengelassen, sodass Edomi ohne roter/grüner Kreis sofort wieder da war.

Vermutlich war das vor der Umstellung auf WebSockets. Da war es sehr wahrscheinlich nur eine verbindungslose HTTP Kommunikation.
Mit Einführung der Websocket-Kommunikation kam dann eine verbindungsorientierte Socket Kommunikation hinzu. Wenn die weg ist, kommt wohl der rote Kreis ...

[wintermute]

Aber ich möchte ja nicht, dass es ständig läuft. Zumindest nicht der Bildschirm.

Das ist genau der Grund warum ich es benutze: weil den Softwarejunkies bei Apple aufgrund irgendeiner-was-weiss-ich-Regung die brillante Idee gekommen ist, keine getrennte Einstellung fuer "Bildschirm aus" und "Ruhezustand" mehr zu ermoeglichen. Anders: geht der Bildschirm aus, fliegen auch die Netzwerksessions weg. Mit dem caffienate Kommando kann man genau das verhindern: Bildschirm geht aus, Netzwerk bleibt da. Gaebe es also eine solche App duerfte die ziemlich genau das machen, was du erreichen moechtest

[rdeckard]

Ich habe vorhin ein paar Tests mit meinem iPad gemacht und bin da auf ein interessantes Verhalten gestossen.

Ausgangslage
iPad: iOS 13.4 (aktuell)
Edomi: v1.64
iPad Bildschirmsperre: 2 Min. (dies ist nur die Sperre, gedimmt/dunkel wird es früher, was ja leider nicht konfigurierbar ist)

Standby-Zeiten:

iPad ohne laufende App (Home Screen)
Dimmed: nach 40 Sek.
Schwarz: nach weiteren 20 Sek.

iPad mit laufender App (Edomi Web App)
Dimmed: nach 1 Min. 40 Sek.
Schwarz: nach weiteren 20 Sek.


Edomi Ladezeiten

1) Edomi komplett neu gestartet
Ladezeit: ca. 1-2 Sek. (roter Kreis kaum sichtbar)
Loginzeit auf Edomi: wird aktualisiert

2) Edomi läuft im Vordergrund, iPad geht in Standby (Dimmed)
Ladezeit: keine (Display wird einfach wieder hell)
Loginzeit auf Edomi: wird nicht aktualisiert

3) Edomi läuft im Vordergrund, iPad geht in Standby (Schwarz)
Ladezeit: ca. 5-6 Sek. (ca. 3 Sek. roter Kreis, ca. 2 Sek. grüner Kreis)
Loginzeit auf Edomi: wird nicht aktualisiert (Eintrag/Session verschwindet nach weiteren 6-8 Sek.)

4) Edomi läuft im Vordergrund, Home-Taste gedrückt (Home-Screen < 10 Sek.)
Ladezeit: sofort (kein Kreis)
Loginzeit auf Edomi: wird nicht aktualisiert

5) Edomi läuft im Vordergrund, Home-Taste gedrückt (Home-Screen > 10 Sek.)
Ladezeit: ca. 5-6 Sek. (ca. 3 Sek. roter Kreis, ca. 2 Sek. grüner Kreis)
Loginzeit auf Edomi: wird nicht aktualisiert (Eintrag/Session verschwindet)

6) Edomi läuft im Vordergrund, Wird manuell beendet
Ladezeit: ca. 1-2 Sek. (roter Kreis kaum sichtbar)
Loginzeit auf Edomi: wird aktualisiert

Bei der Loginzeit beziehe ich mich auf diese Angabe:
ipadtest.png

Somit von mir ein (nicht sehr technisches) Zwischenfazit:
Es spielt offenbar keine Rolle, ob das iPad in den Standby-Modus geht, da das Verhalten mit der langen Ladezeit ja auch geschieht, wenn man nur in den Home-Screen wechselt. Dabei ist das iPad ja noch im normalen Modus und das WiFi-Netz ist sicher auch nicht deaktiviert. Wobei man dabei ca. 8-10 Sek. warten muss, bis die Session auf dem Edomi-Server verschwunden ist. (Siehe oben Test 5, unterhalb der ca. 10 Sek. ist Edomi sofort wieder da)
Entgegen meiner Erwartung und sehr überraschend hat man immer dann eine schnelle Ladezeit, wenn die Web App neu gestartet wird und sie sich scheinbar am Edomi-Server anmeldet (weil dann die Login-Zeit aktualisiert wird)!

Oder anders ausgedrückt: Wird die Web App gestoppt (automatisch durch ein Standby-Event oder manuell durch den Wechsel in den Homescreen), so benötigt der Resume jeweils 5-6 Sek., obwohl kein erneuter Login gemacht wird. (Selbst, wenn die Session auf dem Edomi-Server bereits gelöscht wurde)
Wird die Web App jedoch manuell gelöscht (Home-Button und dann nach oben rauswischen), so findet danach logischerweise immer ein Neustart (kein Resume) statt, der extrem schnell ist.

Ob das jemanden hilft, weiss ich aber auch nicht.
Blöde Frage: Könnte man vom Server (Edomi) ein Logout forcieren, sobald eine Session gelöscht wurde, damit beim nächsten Start eine automatische Anmeldung erfolgt?
Ein Drücken auf den Logout-Button hatte nicht den gewünschten Effekt, weil die Session in diesem Fall noch offen ist. Das zwingt nur den Client ins Anmelde-Fenster. Erst wenn ich die Web App lösche und wieder neu starte (mit den hinterlegten Credentials), gehts schnell.
Ich vermute, man müsste den Logout auslösen, nachdem die Session schon verschwunden ist. Falls sowas überhaupt möglich ist.

[rdeckard]

gaert Könntest du mir evtl. mal deine Meinung zu diesem Verhalten mitteilen? Insbesondere der Schlussabsatz. Es scheint ja offenbar ein Unterschied zwischen "Resume" und "Neuaufbau" zu geben. Und dies völlig unabhängig vom Status eines Standbys. (Wie bis jetzt immer angenommen.)
D.h. Edomi müsste erkennen, dass die Session (oder Kommunikation) nicht mehr aktiv ist (da auf dem Edomi-Server der Eintrag verschwindet, scheint das schon der Fall zu sein) und danach aber die Kommunikation komplett beenden, damit der Client zu einem "Neuaufbau" gezwungen wird. Also dasselbe, wie wenn die Web App auf dem Client manuell beendet wird ("rauswischen") und man sie wieder neu startet.
Ob man dieses Verhalten technisch so umsetzen kann (nur vom Server her), weiss ich leider nicht.