Fully Kiosk Browser für Android

Begonnen von aloz77, 06 Februar 2016, 20:27:54

Vorheriges Thema - Nächstes Thema

juemuc

Zitat von: Tommy82 am 29 November 2020, 18:13:11
Worüber würdest du es aktivieren? Mir ist noch keine variante geglückt

Also bei mir funktioniert:
set DEVICE screen on

Fully startet bei mir automatisch sobald die WLAN-Verbindung aktiv ist.

Das Tablet ist via AMADBridge in FHEM integriert.

Viele Grüße
Jürgen
3x Sonos Play 1, 1x Sonos Arc + Sub, 1 Sonos-One, 1x Sonos Playbar
FB6690 + FB7490 mit 4x Dect 200 und 3 Dect-ULE-Thermostate,  raspberry3B+, HM Funkmodul HM-MOD-RPI-PCB, HM Klingelsensor HM-Sen-DB-PCB, HM (IP) Fensterkontakte und  Amazon Echo Dot,  piVCCU, pi OS (bookworm).

ToM_ToM

Hallo Zusammen,

konnte von euch noch jemand das Phänomen beobachten dass wenn man beispielsweise Motion Detect aktiviert hat und morgens ans Tablet geht, es erst mal einige Zeit braucht um alles zu laden?
Mir ist jetzt mit einer Minimalkonfiguration aufgefallen dass alle Werte die so über Nacht hätten angezeigt werden sollen als der Bildschirm aus war, nun ganz schnell hintereinander geladen und angezeigt werden. Man kann quasi wie in einer Art Zeitraffer die Werte verfolgen.
Hardware: BananaPi, Busmaster CUL, SanDisk 16GB Ultra SD, 16 GB USB-Stick | Software: Armbian, FHEM 5.8

kaihs

Ja, genau das Phänomen habe ich auch.
Als ob die Event-Queue erst abgearbeitet wird wenn der Bildschirm angeht.
Banana Pi, Add-On Board mit 1.8" TFT LCD und IR-Sender, CULFW V1.61, div. Homematic Komponenten, Pollin Funksteckdosen, Selbstbau CUL433 MHz, Jeelink Clone, EC3000
Selbstbau CUL868MHz für Wireless M-Bus, SIGNALduino mit Logilink Temp.-sensoren und Auriol Wetterstation

octek0815

Zitat von: kaihs am 11 Januar 2021, 17:20:50
Ja, genau das Phänomen habe ich auch.
Als ob die Event-Queue erst abgearbeitet wird wenn der Bildschirm angeht.

Kann ich ebenfalls bestätigen.

tomcat.x

#1444
Das dürfte aus meiner Sicht mit dem verwendeten Tablet und/oder dem Android-Release und/oder der WebView-Version zusammen hängen.

Ich hatte das auf meinem Lenovo Tab M10. Nach einem Update (von was konnte ich nicht mehr feststellen) auch mal, dass ohne manuelles Eingreifen gelegentlich gar nicht mehr aktualisiert wurde. Siehe auch weiter oben hier im Thema:

Zitat von: carzl am 02 Oktober 2020, 09:52:23
Bei tomcat und mir ist es das Lenovo Tab M10 mit Android 9. Ich werde deine Tipps mal ausprobieren.

Seit dem Update auf Android 10 funktioniert nun alles wieder. Das wollte ich die ganze Zeit schon mal schreiben (als Hinweis für carzl).
FHEM: 6.3 auf Raspi 3B+, Raspbian (Buster), Perl v5.28.1
Sender/Empfänger: 2 x CULv3, Duofern Stick, HM-MOD-RPI-PCB
Gateways: FRITZ!Box 6591 (OS: 7.57), Trädfri, ConBee 2,  piVCCU, OpenMQTTGateway
Sensoren/Aktoren: FRITZ!DECT, FS20, FHT, HMS, HomeMatic, Trädfri, DuoFern, NetAtmo

ToM_ToM

Ich denke nicht dass das was mit den Android- oder WebView-Versionen zu tun hat, da ich das Phänomen auf 5 verschiedenen Geräten feststellen konnte. Alle haben unterschiedliche Android- und WebView-Versionen im Einsatz (Galaxy S2 [Andorid 10 cusoms rom], Galaxy Tab A, Lenovo Tab 2 A10, Asus ME103K, Virtual Machine) . Also entweder ist das allgemein bei Android/WebView so dass sich der Reload quasi schlafen legt während das Display aus ist, oder es gibt irgendeine Einstellung im Android-System oder Fully mit der man den "Reload wenn Display aus" erzwingen kann. Oder könnte das vielleicht auch an FTUI liegen, dass das evtl. nur einen Reload macht wenn die Website aktiv angezeigt wird?
Hardware: BananaPi, Busmaster CUL, SanDisk 16GB Ultra SD, 16 GB USB-Stick | Software: Armbian, FHEM 5.8

tomcat.x

FTUI nutze ich nicht, das könnte es also sein.

Oder auch eine Einstellung im Android (Stromsparfunktion für alle beteiligten Apps deaktiviert?).

Oder im Fully. Kann sein, dass ich die Option aktiviert habe, aber mit einem der Updates das trotzdem nicht mehr richtig funktioniert hat, erst jetzt mit dem Android Update auf 10 wieder. Definitiv hat das bei mir eine Änderung im Verhalten gebracht. Und bei mir und anderen hatte die WebView Versionen bis 68 am besten funktioniert und danach waren erstmals die Probleme aufgetreten. So schön wie damals funktioniert es immer noch nicht wieder, ich muss "Auto Reload on Screen On" aktivieren, was ich vorher nicht hatte. Da baut sich dann erst die Seite wieder auf, aber der Inhalt ist dann aktuell.
FHEM: 6.3 auf Raspi 3B+, Raspbian (Buster), Perl v5.28.1
Sender/Empfänger: 2 x CULv3, Duofern Stick, HM-MOD-RPI-PCB
Gateways: FRITZ!Box 6591 (OS: 7.57), Trädfri, ConBee 2,  piVCCU, OpenMQTTGateway
Sensoren/Aktoren: FRITZ!DECT, FS20, FHT, HMS, HomeMatic, Trädfri, DuoFern, NetAtmo

neyzen

Hi,
ich hab das Problem das mir ein icon in Fully Browser nur sporadisch angezeigt wird. Es ist das icon "oa-sani_heating_automatic" .Es wird als Rechteck mit einem X angezeigt. Ich habe Android 7.1.2.
Wenn ich aber aus dem Fully Browser rausgehe und z.B die Einstellung im Tablet öffne und dann wieder Fully starte werden die icons angezeigt. Im Browser Internet Explorer habe ich das Problem nicht. Hat mir jemand ein Tip?


neyzen

Hallo,

ich hab gerade ein zweites Tablet mit Fully browser installiert. Bei dem ersten hatte ich die Plus Lizenz. Bei dem zweiten fehlt es das muss man ja dann zusätzlich kaufen.
Jetzt sehe ich aber das bei meinem ersten Tablet ebenfalls eine Meldung in Rot kommt, das Lizenz fehlt. Hat einer eine Idee? Die Lizenz hab ich doch gekauft

coolice

Guten Morgen, habe gestern ein Update von Fully und FTUI3 eingespielt. Jetzt wird das ein oder andere nicht mehr richtig im Fully dargestellt.
Kann das jemand bestätigen? Tablet zu alt? Ist ein Samsung Tab mit Android 8.1.0 (SDK 27)

topfi

Ich bitte um Hilfe.
Seit einiger Zeit blockiert mein FHEM ca. einmal pro Woche und meist nachts um ca. eine Viertelstunde und nichts geht mehr. Alle Netzverbindungen: HMLAN, USV, Harmony gehen offline, selbst sysmon schreibt keine Logs mehr. Die nicht-FHEM-Logs des Rechners füllen sich aber weiter, es handelt sich offensichtlich um einen FHEM-Block.

Warum schreibe ich das hier?

Offensichtlich hat Fully damit zu tun. Seit Januar (vorher gab es das Problem auch nicht) habe ich ein 15"-Android-Tablet, das einen Floorplan anzeigt und den halbstündlich mit reload nachlädt. Diesen Reload-Befehl bekommt es aber über AMAD. Und heute hat freezemon es mal erwischt und mit loglevel 1 Folgendes festgehalten:

=========================================================

[Freezemon] Freezemon: possible freeze starting at 01:30:12, delay is 961.82 possibly caused by: tmr-harmony_ping(Harmony)
2021.06.07 01:30:11.222 4: Connection closed for WEBtablet_192.168.0.76_46256: EOF
2021.06.07 01:30:11.223 5: GET /fhem/images/FPDisplay2/fp_FPDisplay_1080.png HTTP/1.1
Host: 192.168.0.102:18085
Connection: keep-alive
Authorization: Basic ***
User-Agent: Mozilla/5.0 (Linux; Android 8.1.0; TFMTKAW01232 Build/O11019; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/87.0.4280.101 Safari/537.36
Accept: image/webp,image/apng,image/*,*/*;q=0.8
X-Requested-With: de.ozerov.fully
Referer: http://192.168.0.102:18085/fhem/floorplan/FPDisplay2
Accept-Encoding: gzip, deflate
Accept-Language: de-DE,de;q=0.9,en-US;q=0.8,en;q=0.7
2021.06.07 01:30:11.224 4: WEBtablet_192.168.0.76_46257 GET /fhem/images/FPDisplay2/fp_FPDisplay_1080.png; BUFLEN:0

--- log skips   962.586 secs.

2021.06.07 01:46:13.810 4: Connection closed for WEBtablet_192.168.0.76_46255: EOF
2021.06.07 01:46:13.810 5: GET /fhem/pgm2/RSS.js HTTP/1.1
Host: 192.168.0.102:18085
Connection: keep-alive
Authorization: Basic ***
User-Agent: Mozilla/5.0 (Linux; Android 8.1.0; TFMTKAW01232 Build/O11019; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/87.0.4280.101 Safari/537.36
Accept: */*
X-Requested-With: de.ozerov.fully
Referer: http://192.168.0.102:18085/fhem/floorplan/FPDisplay2
Accept-Encoding: gzip, deflate
Accept-Language: de-DE,de;q=0.9,en-US;q=0.8,en;q=0.7
2021.06.07 01:46:13.810 4: WEBtablet_192.168.0.76_46260 GET /fhem/pgm2/RSS.js; BUFLEN:0
2021.06.07 01:46:13.813 5: GET /fhem/pgm2/fhemweb_readingsGroup.js HTTP/1.1
Host: 192.168.0.102:18085
Connection: keep-alive
Authorization: Basic ***
User-Agent: Mozilla/5.0 (Linux; Android 8.1.0; TFMTKAW01232 Build/O11019; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/87.0.4280.101 Safari/537.36
Accept: */*
X-Requested-With: de.ozerov.fully
Referer: http://192.168.0.102:18085/fhem/floorplan/FPDisplay2
Accept-Encoding: gzip, deflate
Accept-Language: de-DE,de;q=0.9,en-US;q=0.8,en;q=0.7
2021.06.07 01:46:13.813 4: WEBtablet_192.168.0.76_46259 GET /fhem/pgm2/fhemweb_readingsGroup.js; BUFLEN:0
2021.06.07 01:46:13.815 5: GET /fhem/images/FPDisplay2/Wecker.Wochenende.png HTTP/1.1
Host: 192.168.0.102:18085
Connection: keep-alive
Authorization: Basic ***
User-Agent: Mozilla/5.0 (Linux; Android 8.1.0; TFMTKAW01232 Build/O11019; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/87.0.4280.101 Safari/537.36
Accept: image/webp,image/apng,image/*,*/*;q=0.8
X-Requested-With: de.ozerov.fully
Referer: http://192.168.0.102:18085/fhem/floorplan/FPDisplay2
Accept-Encoding: gzip, deflate
Accept-Language: de-DE,de;q=0.9,en-US;q=0.8,en;q=0.7
2021.06.07 01:46:13.815 4: WEBtablet_192.168.0.76_46261 GET /fhem/images/FPDisplay2/Wecker.Wochenende.png; BUFLEN:0
2021.06.07 01:46:13.818 4: Harmony: send:
2021.06.07 01:46:13.820 5: [Freezemon] Freezemon: ----------- Starting Freeze handling at 2021.06.07 01:46:13.820 ---------------------
[Freezemon] Freezemon: possible freeze starting at 01:30:12, delay is 961.82 possibly caused by: tmr-harmony_ping(Harmony)

(der BasicAuth-Hash ist ok, ich habe ihn  natürlich hier gelöscht und durch 3 Sternchen ersetzt.)
192.168.0.102 ist FHEM. 192.168.0.76 ist das Tablet mit Fully Plus. Jede halbe Stunde mit aligntime 00:30:10 kommt ein reload. Das Display ist immer an. Nachts und bei Abwesenheit ist die Hintergrundbeleuchtung aus. 
2021.06.07 01:30:11.224 wollte er das Hintergrundbild laden und dann ist FHEM für 961s eingefroren. Danach führt FHEM am Stück alles aus, was in dieser Zeit angefallen wäre.

Was geschieht hier? Insbesondere kann ich mit gzip und deflate an dieser Stelle nichts anfangen. Auf dem Floorplan ist nichts gezipped. Übrigens schließe ich tmr-harmony_ping(Harmony) als Übeltäter aus. das steht immer drin, wenn mal ein seltener zeitkritischer Prozess ein 2-Sekunden freeze bewirkt.

freezemon steht übrigens auf 4 Sekunden und findet sonst tagelang nichts.

hanswerner1

Hallo,

ich habe seit längerem schon das Problem, das sich Fully nach einigen Tagen aber auch mal erst nach 2 Wochen selbständig beendet.  Ich denke es könne an meinen Huawei Tablett liegen, das macht schonmal öfters was es will. Kennt jemand vielleicht eine Android app die überwacht ob eine app (Fully) läuft und wenn nicht, sie startet ?

VG Hw1

tomcat.x

Hallo hanswerner1,

ist nicht direkt eine Antwort auf Deine Frage, aber hast Du in den Einstellungen unter "Other Settings" die beiden Restart-Optionen aktiv?
FHEM: 6.3 auf Raspi 3B+, Raspbian (Buster), Perl v5.28.1
Sender/Empfänger: 2 x CULv3, Duofern Stick, HM-MOD-RPI-PCB
Gateways: FRITZ!Box 6591 (OS: 7.57), Trädfri, ConBee 2,  piVCCU, OpenMQTTGateway
Sensoren/Aktoren: FRITZ!DECT, FS20, FHT, HMS, HomeMatic, Trädfri, DuoFern, NetAtmo

hanswerner1

Hallo tomcat.x,

ja, die habe ich beide aktiviert

neyzen

Zitat von: hanswerner1 am 21 Juni 2021, 15:20:37
Hallo,

ich habe seit längerem schon das Problem, das sich Fully nach einigen Tagen aber auch mal erst nach 2 Wochen selbständig beendet.  Ich denke es könne an meinen Huawei Tablett liegen, das macht schonmal öfters was es will. Kennt jemand vielleicht eine Android app die überwacht ob eine app (Fully) läuft und wenn nicht, sie startet ?

VG Hw1

Hi,
so ein ähnliches Verhalten hab ich bei einem meiner Tablets auch.
Ich habe mich mit folgender DOIF. beholfen.


([FullyBrowserEingang:foregroundapp] eq "com.android.launcher3") (set FullyBrowserEingang foreground)


Das reading "foregroundapp" hat standardmäsig das reading "de.ozerov.fully" wenn es läuft. Wenn es abstürzt wechselt es auf "com.android.launcher3". Damit fange ich es ab und starte fully neu.