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

Begonnen von bruece-lee, 28 Dezember 2017, 16:51:26

Vorheriges Thema - Nächstes Thema

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.
Raspberry Pi3B+ (Bullseye) / JeeLink868v3c (LaCrosse), nanoCUL433 (a-culfw V1.24.02), HM-MOD-UART (1.4.1), TEK603, MapleCUL / diverse Sensoren/Sender/Aktoren von Technoline, Intertechno, Shelly, Homematic und MAX!, Froggit Wetterstation, Luftdaten.info / Autor des fhem-skill für Mycroft.ai

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

Zitat von: bruece-lee am 01 Januar 2018, 18:09:15
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...)
Raspberry Pi3B+ (Bullseye) / JeeLink868v3c (LaCrosse), nanoCUL433 (a-culfw V1.24.02), HM-MOD-UART (1.4.1), TEK603, MapleCUL / diverse Sensoren/Sender/Aktoren von Technoline, Intertechno, Shelly, Homematic und MAX!, Froggit Wetterstation, Luftdaten.info / Autor des fhem-skill für Mycroft.ai

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
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

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.

cotecmania

Hallo,

habe ein ähnliches Problem mit einem Acer Iconia 10" Tablet.
Wenn ich den Bildschirm anlasse, dann bleiben die Inhalte aktualisiert.
Sobald der Bildschirm ausgeht ist nach ein paar Minuten die Verbindung weg.
Hab auch schon alles an Einstellungen getestet aber es hat alles nichts gebracht.
So ist das als Wand-Tablet echt unbrauchbar und ich überlege schon, mir ein anderes zuzulegen.

Hat aber vor langer Zeit mal funktioniert ...
FHEM auf RaspberryPI B (buster)
2xCUL868 für MAX/Slow_RF, HM-LAN, JeeLink
MAX!/HM-Thermostate, FS20/HM-Rolladenschalter, FS20-EM, LevelJet-Ölstandsmessung, PCA301, IT, KM271, IPCAM, FireTAB10 FTUI

TheAbalone

Mir ist das Problem auch vor ein paar Tagen aufgefallen. Davor hatte ich das nicht.

Liegt es vielleicht an einem Fullykioskbrowser Update?

Lg Berni

Update: Ich habe eine mögliche Fehlerquelle gefunden. Außerdem habe ich die Remote Möglichkeiten von Fully entdeckt. Hammer!

cotecmania

Zitat von: TheAbalone am 25 Dezember 2018, 22:18:00
Update: Ich habe eine mögliche Fehlerquelle gefunden. Außerdem habe ich die Remote Möglichkeiten von Fully entdeckt. Hammer!

Klasse. Wäre toll wenn Du uns an deine Erkenntnissen und Fehlerquellen auch teilhaben lässt.
So haben wir nix davon ...
FHEM auf RaspberryPI B (buster)
2xCUL868 für MAX/Slow_RF, HM-LAN, JeeLink
MAX!/HM-Thermostate, FS20/HM-Rolladenschalter, FS20-EM, LevelJet-Ölstandsmessung, PCA301, IT, KM271, IPCAM, FireTAB10 FTUI

TheAbalone

Ich hatte gedacht, dass es daran liegt, dass ich meinen FHEM Server in der Nacht abschalte und dadurch ie Websocket Verbindung flöten geht. Aber heute hatte ich das Problem untertags.
Also wieder von Vorne...

Update: Ich habe jetzt die Webview Updates deinstalliert (zurückgefallen von v73 auf v49). Schaut bis jetzt richtig gut aus. Die Daten sind sogar schon aktuell, wenn das Display angeht.

Update2: Läuft immer noch, ohne einen einzigen Aussetzer.

xl:bk

Hallo zusammen,

ich hatte auf meinem Samsung Tab4 an der Wand ähnliche Probleme.
Danke für den Tipp mit dem WebView von Android. Nachdem ich hier die Updates wieder runter geschmissen habe, läuft alles problemlos. Auch bei mir sind die Daten aktuell, wenn das Display angeht.
FHEM auf Raspberry PI 3+, Stribel Eltron THZ 403sol Wärmepumpe

sinus61

Ich habe  gerade beiu meinem neuem Tab mit Android 8 auch das Problem. Da gibt es ja die Webview Komponente so als Extra nicht mehr, sondern es wird direkt die aus Chrome genutzt. Nach Ausschalten des Bildschirms ging beim Einschalten in FTUI erstmal nichts mehr. In Fully hab ich alles probiert, auch unter Android die WLAN und Akku Einstellung angepasst. Die Netzverbindung ist aber anscheinend auch immer da, per AMAD kann ich auf das Tablet zugreifen und auch den Screen einschalten. Eigentlich hilft für FTUI nur der Reload bei Screen On in Fully (ist aber optisch nicht so schön).

Zum Testen hab ich mal das in meine FTUI Seite eingebaut:


<div><div class="inline">Version: </div> <div data-bind="ftui.version" class="inline"></div></div>
<div><div class="inline">SP lastTimestamp: </div> <div data-bind="parseISOLocal(ftui.poll.short.lastTimestamp);" class="inline"></div></div>
<div><div class="inline">SP StatusText: </div> <div data-bind="ftui.poll.short.request.statusText" class="inline"></div></div>
<div><div class="inline">SP Duration: </div> <div data-bind="ftui.poll.short.duration" class="inline"></div></div>

<div><div class="inline">LP lastEventTimestamp: </div> <div data-bind="parseISOLocal(ftui.poll.long.lastEventTimestamp);" class="inline"></div></div>
<div><div class="inline">LP lastUpdateTimestamp: </div> <div data-bind="parseISOLocal(ftui.poll.long.lastUpdateTimestamp);" class="inline"></div></div>
<div><div class="inline">LP longPollType: </div> <div data-bind="ftui.config.longPollType" class="inline"></div></div>
<div><div class="inline">LP lastReading: </div> <div data-bind="ftui.poll.long.lastReading" class="inline"></div></div>


An den Timestamps sieht man schön, dass die FTUI Seite kurz nach Screen Off Shortpoll (also der default 15minütige Refresh aller Readings) und Longpoll (das sofortige aktualisieren der Readings) einstellt.

Also hab ich mal
<meta name="longpoll_type" content="websocket">
auf
<meta name="longpoll_type" content="1">
geändert.

Damit wechselt die Aktualisierung von Websocket auf Ajax. Jetzt funktioniert der longpoll wieder sofort bei Screen On, also ab dem Zeitpunkt kommen wieder Readings rein. Allerdings  sind die Readings die sich in der Screen Off Zeit geändert haben weiterhin nicht aktuell, der Shortpoll startet nicht von selbst wieder.

Zum Testen hab ich mal einen Button eingebaut:


<div data-type="symbol" data-icon="fa-refresh" data-background-icon="fa-circle" data-off-color="#2A2A2A" class="" onclick="ftui.states.lastShortpoll = 0;ftui.shortPoll();ftui.startShortPollInterval();"></div>


Das löst sofort einen Shortpoll aus und startet den Intervall wieder. Nach 2-3 Sekunden sind alle Readings da. Eigentlich müsste ich jetzt nur das Drücken des Buttons automatisieren, dann würde wieder alles gehen.