Problem: Fully verliert auf Wandtablet mit Tablet UI im Standby die Verbindung

[bruece-lee]

Hallo,

ich habe seit einiger Zeit ein Wandtablet im Einsatz auf dem eine Übersichtsseite mit Tablet UI im "Fully Fullscreen Browser" dargestellt wird. Es handelt sich um ein Samsung Galaxy Tab A (2016) mit aktuellem Android 7.0. Zusätzlich installiert ist AMAD 4.0 mit der App Automagic, um mittels Homematic Bewegungsmelder bei erkannter Bewegung das Display einzuschalten, welches standardmäßig abgeschaltet ist. Der Lockscreen ist deaktiviert, es wird nur der Bildschirm abgeschaltet. Dies funktioniert wunderbar und 100% zuverlässig. Daraus schließe ich, dass die WLAN Verbindung zum Tablet auch im Standby zuverlässig aufrecht erhalten wird.

Was leider nicht funktioniert ist, dass Tablet UI die Verbindung zu FHEM aufrecht erhält und somit dauert es leider relativ lange, bis die Tablet UI Seite nach erneutem Einschalten des Bildschirms wieder aktuell ist. Bei Fully kann man in den Einstellungen die Funktion "Reload on Network reconnect" wählen, damit wird die Seite automatisch neu geladen, aber dies dauert leider relativ lange. Man bekommt auch eine Meldung, wenn die Netzwerkverbindung wiederhergestellt wurde, was eindeutig zeigt, dass Fully bei längerem Stndby die Verbindung zunächst verloren hat.

Hat jemand ähnliche Probleme? Kann dies vielleicht mit dem DozeMode von Android zusammenhängen, sodass Fully irgendwann schlafen gelegt wird? Ich habe schon alle Einstellungen unter Android durchprobiert, von denen ich mir Abhilfe versprochen habe. So habe ich sämtliche Stromsparfunktionen abgeschaltet und auch in Fully die Optionen angewählt, die dazu gedacht sind eine Verbindung aufrecht zu erhalten.

Hat jemand schon ähnliche Probleme gahbt und Lösungen dafür gefunden? Wie gesagt, das Problem besteht nur mit Fully, AMAD scheint die Verbindung zu halten. Es wäre ein riesiger Komfort-Gewinn, wenn sofort die aktuelle Tablet UI Seite angezeigt würde, wenn man vor das Tablet tritt und nicht erst mit 30-40 Sekunden Verzögerung.

Ich bin für jeden Tipp dankbar!

Viele Grüße,
Bruece-Lee

[aloz77]

Hallo, das WLAN-Verhalten im Standby ist bei Android eine große Magie. Und es wird mit jeder Android-Version etwas anders. Bei Android 6 und 7 ist es jedenfalls nicht so, dass die WLAN-Verbindung permanent aufrechterhalten wird. Du kannst z.B. ein Gerät im Standby nicht pingen. Aber irgendwie gelangen die Instant Messages trotzdem zeitnah zum Gerät, manchmal etwas verzögert. Das hat vermutlich mit Doze Mode und Mantainance Frames zu tun.

Fully Kiosk kann Standby verhindern (mit Optionen Keep Screen On oder Set CPU Wakelock). Wenn aber Standby nicht verhindert wird, nimmt Fully Kiosk m.W. keinen Einfluss darauf, was im Standby passiert. Wenn Fully anzeigt, dass die Netzwerk-Verbindung wiederhergestellt wurde, dann war sie m.E. systemweit weg. Wie stellst du fest, dass AMAD die Verbindung noch hält bzw. früher erlangt als Fully?

[dkreutz]

Ich habe auch lange mit Verbindungsabbrüchen gekämpft. Geholfen hat es letztendlich dem Android-Tablet eine feste IP zu geben (in der WLAN-Konfiguration eintragen). Seit dem habe ich keine Verbindungsabbrüche mehr, auch beim aufwachen aus dem Standby. Die feste IP sollte außerhalb der DHCP IP-Range (im Internetrouter konfiguriert) liegen.

[motopi]

Hallo,

ich habe auch ein Tablet(Fire 7 + root, ohne Amazon) mit dem gleichen, ungewünschten Verhalten. Habe Fully so eingestellt, dass er bei jedem Reconnect die Seite neu lädt.

Ich versuche es die Tage mal mit einer festen IP, wundert mich dass das so gehen soll...

Gruß

[bruece-lee]

@aloz77: Ich habe in meinem Fully die beiden Optionen "Set CPU Wakelock" und "Set Wifi Wakelock" aktiviert, aber leider ohne Erfolg. Ich kann feststellen, dass AMAD die Verbindung immer hält, da über AMAD und einen Homematic Bewegungsmelder der Bildschirm des Tablets bei Bewegung eingeschaltet wird. Das funktioniert ohne Verzögerung und sehr zuverlässig.

@dkreutz: Ich habe mal getestet dem Tablet eine feste IP zu geben. Bislang habe die IP, die ursprünglich per DHCP vergeben wurde als feste IP vergeben, um in AMAD und Co. nichts ändern zu müssen. Geholfen hat es leider nicht. Warum sollte die fest vergebene IP außerhalb der DHCP-IP-Range liegen? Gibt es dafür eine Erklärung? Ich nutze eine Fritzbox und wüßte nicht, dass ich eine per DHCP vergebene IP nicht auch als feste setzen kann. Ich hatte in der Fritzbox bereits zuvor eingestellt, dass das Tablet immer die gleiche IP bekommen soll und habe es lediglich jetzt nochmal unter Android eingestellt. Aber wie gesagt löst das leider das Problem noch nicht.

Es gab jetzt jüngst nochmal ein Android Update für das Galaxy Tab A, aber am Verhalten hat dieses nichts geändert. Es ist auch immernoch Android 7.0.

[dkreutz]

Warum sollte die fest vergebene IP außerhalb der DHCP-IP-Range liegen? Gibt es dafür eine Erklärung? Ich nutze eine Fritzbox und wüßte nicht, dass ich eine per DHCP vergebene IP nicht auch als feste setzen kann. Ich hatte in der Fritzbox bereits zuvor eingestellt, dass das Tablet immer die gleiche IP bekommen soll und habe es lediglich jetzt nochmal unter Android eingestellt. Aber wie gesagt löst das leider das Problem noch nicht.

Für mich ist das einfach "best practice". Konfiguriere ich einem Gerät eine feste IP, so nehme ich dafür immer eine außerhalb der DHCP-Range. So kann ich immer identifizieren "woher" die IP kommt.
Vielleicht gibt es dafür auch noch eine technische Begründung irgendwo aus den Untiefen des DHCP-Protokolls und/oder OSI-Layer, die ein Netzwerktechniker erklären kann (ich habe mich während meines Informatik-Studium früh in Richtung Softwareentwicklung orientiert, weshalb ich die Netzwerktechnik-Vorlesung geschwänzt habe...)

[CoolTux]

Natürlich gibt es eine tech. Begründung. Der DHCP Server kann nicht wissen das Du die IP welche in der Rangeliegt fest vergeben hast und vergibt sie an ein anderes Gerät welches eine Anfrage stellt.

Davon mal ab kann man aber einer MAC Adresse eine dauerhafte DHCP IP zuweisen. Dann gibt der DHCP Server dieser MAC immer die selbe IP

[Mave]

Der Router/DHCP Server vergibt aus der IP-Range dynamische IP-Adressen an anfragende Geräte, die auf DHCP eingestellt sind und keine feste IP-Adresse haben.

Ist ein Gerät auf DHCP eingestellt und fragt bei einem Router/DHCP Server nach einer dynamischen IP-Adresse an, bekommt es eine freie IP-Adresse zugeteilt. Diese kann bei jeder Anfrage anders sein.
Möchte man dem Gerät immer dieselbe IP-Adresse zuweisen lassen, kann man im Router/DHCP Server bei diesem Gerät ein Häkchen setzen. Somit bekommt dieses Gerät quasi eine "statische" IP-Adresse.
Der Router/DHCP Server vergibt diese IP-Adresse immer nur an dieses eine Gerät und an kein anderes. Das wird über die eineindeutige MAC-Adresse des Gerätes geregelt.

Von einer statischen IP-Adresse spricht man, wenn ein Gerät nicht über DHCP eine IP-Adresse anfordert, sondern eine eigene IP-Adresse fest eingestellt hat.

Was ich im Moment wirklich nicht weiß, ob ein Router/DHCP Server eine IP-Adresse aus der IP-Range vergibt, wenn es bereits ein Gerät im Netzwerk gibt, das eine statische IP-Adresse verwendet, die innerhalb der IP-Range liegt und diese IP-Adresse vom Router/DHCP Server noch nicht dynamisch vergeben wurde.
Der Router/DHCP Server kennt ja die statische IP-Adresse des Gerätes in "seinem" Netzwerk und sollte schlau genug sein, diese nicht erneut dynamisch zu vergeben. Aber ob er tatsächlich so schlau ist, kann ich nicht beurteilen.

Wo es definitiv knallt, ist, wenn eine IP-Adresse zuerst vom Router/DHCP Server dynamisch vergeben wurde und dann ein Gerät mit der exakt selben statischen IP-Adresse im Netzwerk auftaucht.

Deshalb tut man sehr gut daran, statische IP-Adressen ausserhalb der IP-Range zu verwenden.

[aloz77]

Zum ursprünglichen Problem: Reproduzieren kann ich das nicht. Beim Samsung-Gerät mit Android 7.0 gibt's zwei System-Einstellungen, die relevant sein könnten:

1. Verbindungen -> WLAN -> Erweitert -> WLAN im Standbymodus eingeschaltet lassen -> Immer

2. Gerätewartung -> Akku -> Nicht überwachte Apps -> Hier Fully Kiosk hinzufügen

Beides könnte auf den Akku-Verbrauch schlagen, aber hier hängt das Gerät eh am Strom, oder?

Zu FireOS kann ich nichts sagen. Es ist m.W. auf Android 5.0 basiert und die Problematik dort ist sicherlich eine ganz andere.