Hallo,
seit kurzem erscheint auf iPad und iPhone beim Aufrufen von FUIP ein roter Bildschirm mit obiger Meldung. Verschiedene Versuche mit longpoll und reset sind nicht erfolgreich. Auch der Neuaufbau bringt keine Änderung. Auf PC und MacBook gibt es kein Problem. Verschiedene Browser zeigen das gleiche Verhalten. Gibt es zu dem Fehler eine Erklärung/Lösung?
Mit besten Dank
Patrik
Hi,
ich habe vor Kurzem die ganze Verbindung zum "Backend-FHEM" umgestellt. Dadurch hat es zumindest mal bei mir wesentlich zuverlässiger funktioniert. Sorry, wenn das bei Dir (noch) nicht der Fall ist. Jedenfalls sollte es jetzt zumindest einfacher sein, das ganze zu analysieren.
Zitat von: Patrik am 24 November 2019, 11:15:09
seit kurzem erscheint auf iPad und iPhone beim Aufrufen von FUIP ein roter Bildschirm mit obiger Meldung.
Die Meldung bedeutet, dass die FUIP-Seite den Kontakt zum "Backend-FHEM" verliert. Wenn ich das richtig verstehe, dann passiert das bei Dir sofort am Anfang. D.h. die Verbindung kann erst gar nicht hergestellt werden. Möglicherweise unterstützen die Browser auf Deinem iPad/iPhone keine Websockets. Welche(n) Browser hast Du da genau probiert und in welcher Version (Release) genau?
Zitat
Verschiedene Versuche mit longpoll
Was genau meinst Du damit? Bei FUIP (zumindest ab der Version, bei der das rote Overlay das erste mal kommt) kann man gar nicht mehr beeinflussen, wann welches longpoll benutzt wird etc.
Zitat
und reset sind nicht erfolgreich. Auch der Neuaufbau bringt keine Änderung.
Was meinst Du mit "reset" und "Neuaufbau"?
Zitat
Auf PC und MacBook gibt es kein Problem. Verschiedene Browser zeigen das gleiche Verhalten. Gibt es zu dem Fehler eine Erklärung/Lösung?
Womöglich hast Du auf den Mobilgeräten ziemlich alte Browser. Siehe oben: Welche Browser mit welchen Versionen genau?
Natürlich soll das nicht so sein. Um das ganze etwas weiter zu erforschen hätte ich gerne folgendes:
1. Ein "list" des FUIP-Device in FHEM
2. Ein Frontend-Log eines solchen missglückten Seitenaufrufs.
Das Frontend-Log bekommst Du folgendermaßen:
Im FUIP-Device setzt Du die folgenden Attribute:
logareas: base.init,base.poll
logtype: localstorage
loglevel: 3
Dann rufst Du die Seite auf dem/den Geräte(n) auf, auf denen die Probleme auftreten. Mach dort zwei, dreimal einen Page-Refresh (Reload).
Jetzt solltest Du auf dem FHEM-Server im Pfad /opt/fhem/FHEM/lib/FUIP/log ein paar Dateien sehen. Mindestens eine davon sollte im Dateinamen die IP-Adresse des Problematischen iPad/Phone enthalten. Diese Datei hätte ich gerne, von mir aus auch mehrere davon.
Danach schalte das Log am besten wieder aus, indem Du loglevel auf 0 setzt. Die restlichen Attribute kannst Du so lassen, wie sie sind.
Gruß,
Thorsten
Mir ist unter FHEMWEB in FireFox ein ähnliches Problem begegnet, d.h. "Connection lost. Trying to reconnect...". So weit ich aus der Browser-Console erkennen konnte, konnte er keine Verbindung über Websocket aufbauen. Auf den Verbindungsaufbau via ws:// und Connection: Upgrade erfolgte ein Timeout.
Hi,
ich habe es gerade eben mit Firefox ausprobiert und es gab kein Problem. D.h. prinzipiell geht das mit Firefox. Also auch an xenos1984: Da brauche ich ein bisschen mehr Information. Kannst Du das reproduzieren? Wenn ja, dann wie? ...und dann bitte ein "list" des FUIP-Device und ein Frontend-Log. Wie Du das bekommst steht in meinem Beitrag von vorher.
Danke&Gruß,
Thorsten
Also bei mir läuft das mit Firefox 71.0b12 (64-Bit) auch nicht mehr.
Anbei mal eine Logdatei dazu.
Im Moment läuft es bei mir wieder einwandfrei, vielleicht war das nur ein sporadischer Fehler... Ich behalte das mal im Auge und versuche, es mit Frondend-Log zu reproduzieren.
Hi,
@xenos1984: Sorry, ich habe eben erst gesehen, dass sich das von Dir auf FHEMWEB bezieht. Damit bist Du hier im falschen Bereich und das mit dem Frontend-Log passt natürlich auch nicht. Das hat fast nichts miteinander zu tun.
Gruß,
Thorsten
Zitat von: dlehmann69 am 24 November 2019, 17:10:22
Also bei mir läuft das mit Firefox 71.0b12 (64-Bit) auch nicht mehr.
Anbei mal eine Logdatei dazu.
Das Ding versucht, den Websocket mit SSL aufzumachen. (Also wss:// statt ws://.) Hat das bei Dir jemals funktioniert, bzw. funktioniert das mit einem anderen Browser?
Kannst Du es mal ohne SSL versuchen?
Gruß,
Thorsten
Zitat von: Thorsten Pferdekaemper am 24 November 2019, 17:11:53Damit bist Du hier im falschen Bereich und das mit dem Frontend-Log passt natürlich auch nicht. Das hat fast nichts miteinander zu tun.
Sehe ich auch gerade, dass wir hier im TabletUI Forum sind :D Ich hatte den Thread über "ungelesene Beiträge" gefunden und nicht darauf geachtet.
Hi,
falls die Abbrüche in Umgebungen mit reverse Proxy auftreten sollten: Hier gibt's eine Diskussion bezüglich secure websockets mit nginx und Apache:
https://forum.fhem.de/index.php?topic=84343.0
Gruß,
Thorsten
Hallo Thorsten, besten Dank für Deine rasche und ausführliche Antwort.
ZitatMöglicherweise unterstützen die Browser auf Deinem iPad/iPhone keine Websockets. Welche(n) Browser hast Du da genau probiert und in welcher Version (Release) genau?
Ich nutze Safari für die aktuellen Releases von iPadOS und iOS (13.2.3)
ZitatWas genau meinst Du damit? Bei FUIP (zumindest ab der Version, bei der das rote Overlay das erste mal kommt) kann man gar nicht mehr beeinflussen, wann welches longpoll benutzt wird etc.
Was meinst Du mit "reset" und "Neuaufbau"?
Das waren Verzweiflungstaten, um erst mal selber nach einer Lösung zu suchen, bevor ich das Forum bemühe. Neuaufbau meint, das ich das FUIP Komplett gelöscht und dann per define neu erstellt habe. Damit sind dann auch alle Objekte meiner Installation enthalten
ZitatNatürlich soll das nicht so sein. Um das ganze etwas weiter zu erforschen hätte ich gerne folgendes:
1. Ein "list" des FUIP-Device in FHEM
2. Ein Frontend-Log eines solchen missglückten Seitenaufrufs.
Hier das list vom FUIP-Device
Internals:
CFGFN
FUUID 5dda43bb-f33f-c5c4-4178-c9c06be3bb4ac9dc
NAME ui2
NR 322121
STATE ui2
TYPE FUIP
autosave none
editOnly 0
colors:
fhem:
directory ./www/tablet
friendlyname ui2
infix ui2/
pages:
viewtemplates:
Attributes:
DbLogExclude .*
baseHeight 108
baseWidth 142
layout gridster
logareas base.init,base.poll
loglevel 0
logtype localstorage
toastMessages off
und das Log-File:
2019-11-25T07:54:58.702Z
00000001 2019-11-25T07:54:58.702Z 3 base.init Base dir: /fhem/ui2/
00000002 2019-11-25T07:54:59.079Z 1 base.init Filename:
00000003 2019-11-25T07:54:59.080Z 1 base.init FHEM dir: https://XXXX/fhem/
00000004 2019-11-25T07:54:59.082Z 3 base.init dynamic load file:/fhem/ui2/lib/jquery.toast.min.js / async:false
00000005 2019-11-25T07:54:59.163Z 1 base.init Got csrf from FHEM:csrf_367493058493957
00000006 2019-11-25T07:54:59.212Z 2 base.init initPage - area=html
00000007 2019-11-25T07:54:59.226Z 3 base.init dynamic load done:/fhem/ui2/lib/jquery.toast.min.js
00000008 2019-11-25T07:54:59.274Z 1 base.init init templates - Done
00000009 2019-11-25T07:54:59.275Z 2 base.init initWidgets before- area=html
00000010 2019-11-25T07:54:59.275Z 2 base.init
00000011 2019-11-25T07:54:59.275Z 2 base.init initWidgets after removed- area=html
00000012 2019-11-25T07:54:59.276Z 2 base.init
00000013 2019-11-25T07:54:59.280Z 3 base.init dynamic load file:/fhem/ui2/js/widget_link.js / async:true
00000014 2019-11-25T07:54:59.281Z 3 base.init dynamic load file:/fhem/ui2/js/widget_fuip_clock.js / async:true
00000015 2019-11-25T07:54:59.281Z 3 base.init dynamic load file:/fhem/ui2/js/widget_button.js / async:true
00000016 2019-11-25T07:54:59.282Z 3 base.init dynamic load file:/fhem/ui2/js/widget_switch.js / async:true
00000017 2019-11-25T07:54:59.282Z 3 base.init dynamic load file:/fhem/ui2/js/widget_label.js / async:true
00000018 2019-11-25T07:54:59.292Z 3 base.init dynamic load file:/fhem/ui2/js/widget_thermostat.js / async:true
00000019 2019-11-25T07:54:59.294Z 3 base.init dynamic load file:/fhem/ui2/js/widget_symbol.js / async:true
00000020 2019-11-25T07:54:59.347Z 3 base.init dynamic load done:/fhem/ui2/js/widget_link.js
00000021 2019-11-25T07:54:59.424Z 3 base.init dynamic load done:/fhem/ui2/js/widget_fuip_clock.js
00000022 2019-11-25T07:54:59.434Z 3 base.init dynamic load done:/fhem/ui2/js/widget_switch.js
00000023 2019-11-25T07:54:59.435Z 3 base.init dynamic load file:/fhem/ui2/js/widget_famultibutton.js / async:true
00000024 2019-11-25T07:54:59.436Z 3 base.init dynamic load done:/fhem/ui2/js/widget_button.js
00000025 2019-11-25T07:54:59.436Z 3 base.init dynamic load file:/fhem/ui2/js/widget_famultibutton.js / async:true
00000026 2019-11-25T07:54:59.436Z 3 base.init dynamic load not neccesary for:/fhem/ui2/js/widget_famultibutton.js
00000027 2019-11-25T07:54:59.437Z 3 base.init dynamic load done:/fhem/ui2/js/widget_label.js
00000028 2019-11-25T07:54:59.647Z 3 base.init dynamic load done:/fhem/ui2/js/widget_thermostat.js
00000029 2019-11-25T07:54:59.648Z 3 base.init dynamic load file:/fhem/ui2/js/widget_knob.js / async:true
00000030 2019-11-25T07:54:59.650Z 3 base.init dynamic load done:/fhem/ui2/js/widget_symbol.js
00000031 2019-11-25T07:54:59.650Z 3 base.init dynamic load file:/fhem/ui2/js/widget_famultibutton.js / async:true
00000032 2019-11-25T07:54:59.650Z 3 base.init dynamic load not neccesary for:/fhem/ui2/js/widget_famultibutton.js
00000033 2019-11-25T07:54:59.685Z 3 base.init dynamic load done:/fhem/ui2/js/widget_famultibutton.js
00000034 2019-11-25T07:54:59.685Z 3 base.init dynamic load file:/fhem/ui2/lib/fa-multi-button.min.js / async:false
00000035 2019-11-25T07:54:59.687Z 3 base.init dynamic load file:/fhem/ui2/lib/fa-multi-button.min.js / async:false
00000036 2019-11-25T07:54:59.688Z 3 base.init dynamic load not neccesary for:/fhem/ui2/lib/fa-multi-button.min.js
00000037 2019-11-25T07:54:59.690Z 3 base.init dynamic load file:/fhem/ui2/lib/fa-multi-button.min.js / async:false
00000038 2019-11-25T07:54:59.690Z 3 base.init dynamic load not neccesary for:/fhem/ui2/lib/fa-multi-button.min.js
00000039 2019-11-25T07:54:59.706Z 3 base.init dynamic load done:/fhem/ui2/js/widget_knob.js
00000040 2019-11-25T07:54:59.706Z 3 base.init dynamic load file:/fhem/ui2/lib/jquery.knob.mod.min.js / async:false
00000041 2019-11-25T07:54:59.750Z 3 base.init dynamic load done:/fhem/ui2/lib/fa-multi-button.min.js
00000042 2019-11-25T07:54:59.822Z 3 base.init dynamic load done:/fhem/ui2/lib/jquery.knob.mod.min.js
00000043 2019-11-25T07:54:59.982Z 1 base.init initWidgets - Done
00000044 2019-11-25T07:54:59.982Z 1 base.poll Event: initWidgetsDone
00000045 2019-11-25T07:54:59.983Z 1 base.poll DISCONNECTED
00000046 2019-11-25T07:54:59.983Z 1 base.poll CONNECTING
00000047 2019-11-25T07:54:59.984Z 1 base.poll start shortpoll
00000048 2019-11-25T07:55:00.011Z 1 base.init initPage (html): in 799ms
00000049 2019-11-25T07:55:00.096Z 3 base.poll fhemJSON: 0=Arg 1=Results
00000050 2019-11-25T07:55:00.096Z 2 base.poll shortpoll: fhemJSON.Results.length=50
00000051 2019-11-25T07:55:00.272Z 1 base.poll shortPoll: Done
00000052 2019-11-25T07:55:00.368Z 2 base.poll WebSocket creation started
00000053 2019-11-25T07:55:00.368Z 2 base.poll WebSocket URL=wss://XXXX/fhem/?XHR=1&inform=type=status;filter=EG.bz.TH_Climate,EG.wc.TH_Climate,UG.bz.HZ_Clima,UG.mz.HZ_Clima,FHEM.Backup,GH.ga.SD.hal,HM_195D6B,ActionDetector,Brenner,Counter,DbReport,Heizung,LAN,MyGas,Pari,Patrik,XX.par.key,XX.pat.key,batteries,heatingInfo,logdb,system,ESP,ESPEasy_ESP_01_relay,ESPEasy_ESP_02_relay,ESPEasy_ESP_03_relay,ESPEasy_ESP_04_relay,ESPEasy_ESP_05_relay,ESPEasy_ESP_17_T1,ESP_10_4,ESP_11_4,ESP_12_4,ESP_17_4,ESP_17_5,ESP_31_T1,ESP_31_T2,ESP_31_T3,EG.bz.Fn,EG.wc.Fn,EG.wz.TF,Lichterketten,OnkyoReceiver,OnkyoReceiver_2,GH.ga.TF,HeatLook,HeizProfil,XX.op.TW,Garagentor,UG.bz.Fn,UG.wz.TF, desired-temp measured-temp STATE ValvePosition;since=1574668499983;fmt=JSON×tamp=1574668500368
00000054 2019-11-25T07:55:00.476Z 1 base.poll Websocket error
00000055 2019-11-25T07:55:00.479Z 1 base.poll Websocket closed (1006 The connection was closed abnormally, e.g., without sending or receiving a Close control frame), restarting...
00000056 2019-11-25T07:55:00.479Z 1 base.poll DISCONNECTED
00000057 2019-11-25T07:55:00.479Z 1 base.poll CONNECTING
00000058 2019-11-25T07:55:00.479Z 2 base.poll WebSocket creation started
00000059 2019-11-25T07:55:00.479Z 2 base.poll WebSocket URL=wss://XXXX/fhem/?XHR=
Gruß und vielen Dank
Patrik
Hi,
das sieht bei Dir ähnlich aus wie bei dlehmann69. Es ist wahrscheinlich ein SSL-Problem. FHEM ist anscheinend per https angebunden und deshalb versucht FUIP es auch per wss statt ws. Ich habe ein bisschen rumgesucht und es sieht so aus, dass Safari ein Problem mit secure websocket hat, wenn das Zertifikat selbst-signiert ist (self signed certificate). Möglicherweise werden in Zukunft weitere Browser das "sperren".
Könntest Du erst einmal ausprobieren, ob es ohne SSL funktioniert? Ansonsten raten wir hier ja nur rum.
Danach können wir uns dann eine Lösung überlegen. Momentan weiß ich zwar auch nicht so recht, wie die aussehen soll, aber vielleicht ergibt sich ja noch etwas.
Gruß,
Thorsten
Also bei scheint es wirklich ein Problem mit den Websocket über SSL und Reverse Proxy zu sein. Auf jeden Fall hat es bei Zugriff auf FHEM ohne den Proxy mit Zugriff über die IP keine Probleme gegeben.
Ich muss mir jetzt das Thema mit dem Reverse Proxy mal zu Gemute führen.
Hi,
ich habe jetzt von noch einem Problem mit Safari und Websockets erfahren. Anscheinend kann Safari keine Websockets mit Basic Authentication. Verwendest Du das?
Gruß,
Thorsten
Hallo zusammen,
sorry dass ich mich so lange nicht gemeldet habe, aber die Haussteuerung ist nicht meine höchste Priorität.
Es hat ja eine ganze Zeit gut funktioniert. Dann mit dem Wechsel zu iOS 13 trat der Fehler auf. Ich möchte jetzt aber nicht meine ganze mühsam aufgebaute Umgebung umstricken. Dann kann ich eben diese Oberfläche vorerst nicht mehr nutzen.
Mit besten Gruß
Patrik
Hi,
wieso alles "umstricken"? Ich versuche doch nur herauszufinden, was eigentlich das Problem ist, damit wir das lösen können.
Also: Basic Auth oder nicht?
Gruß,
Thorsten
(Siehe auch https://forum.fhem.de/index.php/topic,106206.0.html)
Hi,
im anderen Thread sieht es so aus, dass das Problem nicht mehr auftritt, wenn man im allowed-Device basicAuthExpiry setzt. Wahrscheinlich reicht es aus, wenn man es auf kleine Zahlen setzt, wie z.B. 1 oder 2.
Vielleicht will das hier auch mal jemand ausprobieren.
Gruß,
Thorsten
Hallo,
ich habe gerade mit dem TabletUI/FUIP. Personalisiert habe ich bisher noch nichts. Ich habe nur einmal das UI aufgerufen und die Konfiguration meines FHEM zeigt sich.
Anschliessend wird der Bildschirm direkt rot und zeigt "Disconnected from FHEM, reconneting...
Ohne manuellen Eingriff passiert dann gar nichts mehr , lade ich die Seite neu, so wiederholt sich der Vorgang: zeigt ganz kurz (2 s) meine FHEM konfiguration, anschliessend roter Bildschirm, "disconnected ...".
Das kann ich beliebig oft wiederholen.
Ich habe ein IPAD mit IOS 13.2 und verwende Safari.
Leider kann ich den Hinweis allowed-Device basicAuthExpiry setzt nicht umsetzen, da ich etwas mehr Details benötigt.
Meine Frage: Welche allowed muss ich setzen: Web oder Webtablet? Den Zugriff vom IPAD mache ich über 8085, dies ist WEBtablet zugeordnet. Ich vermute, dass ich damit das allowed-Device allowed_WEBtablet setzen muss.
Korrekt ?
==> habe ich gemacht, basicAuthExpiry auf 1 . Dann save config und shutdown restart.
Leider ohne Veränderung , Fehler weiterhin da.
Ich habe den Zugriff auf mit einem Ipad versucht, das noch unter IOS 12.x läuft. Da tritt das Problem auch auf. Das Thema ist damit nicht IOS 12/13 abhängig.
Hallo, kleiner Nachtrag:
ich habe den Eindruck, dass mit der Firefox Browser (neueste Version) auf IOS 13 das Problem mit disconnect nicht auftritt.
Bitte unterstützt mich aber, dass ich es auf Safari gelöst bekomme. Danke .
Hi,
in diesem Beitrag hier...
https://forum.fhem.de/index.php/topic,105674.msg996064.html#msg996064
...habe ich erklärt, wie man ein Frontend-Log machen kann. Könntest Du das mal machen und die Datei(en) hier dranhängen?
Gruß,
Thorsten
Hallo Thorsten,
ich versuche mal hier deine Fragen gemäss deines Beitrages zu beantworten:
ZitatDie Meldung bedeutet, dass die FUIP-Seite den Kontakt zum "Backend-FHEM" verliert. Wenn ich das richtig verstehe, dann passiert das bei Dir sofort am Anfang. D.h. die Verbindung kann erst gar nicht hergestellt werden. Möglicherweise unterstützen die Browser auf Deinem iPad/iPhone keine Websockets. Welche(n) Browser hast Du da genau probiert und in welcher Version (Release) genau?
Bei mir wird die Verbindung zu FHEM über FUID mit dem IPAD hergestellt, man sieht, wie sich die Zimmer aufbauen und dlie einzelnen Symbole erscheinen. Ich habe den Eindruck, dass die Verbindung abbricht, sobald der Aufbau abgeschlossen ist.
Ich verwende Safari auf IPAD, neueste Version auf IOS 13.3. Zum Test habe ich Firefox auf IOS 13.3 getestet, hier tritt das Problem nicht auf. Auf meinem 2. IPAD mit IOS 12.4.4 tritt das Problem identisch auf.
Womöglich hast Du auf den Mobilgeräten ziemlich alte Browser. Siehe oben: Welche Browser mit welchen Versionen genau?Das FUIP ist jungfäulich, ich beginne aktuell damit, habe aber eine ca. 5 Jahre alte FHEM Basisstruktur mit FHEM. FHEM und Linux sind auf dem aktuellen Stand. Ich habe überall immer die neueste Version der Applikationen (Safari, Firefox), IOS) und Betriebssysteme auf dem IPAD installiert.
ZitatNatürlich soll das nicht so sein. Um das ganze etwas weiter zu erforschen hätte ich gerne folgendes:
1. Ein "list" des FUIP-Device in FHEM
2. Ein Frontend-Log eines solchen missglückten Seitenaufrufs
Internals:
FUUID 5e1d9c1b-f33f-1e06-927e-c36a5471e6027baf
NAME ui
NR 596
STATE ui
TYPE FUIP
autosave none
editOnly 0
colors:
fhem:
directory ./www/tablet
friendlyname ui
infix ui/
pages:
viewtemplates:
Attributes:
DbLogExclude .*
baseHeight 108
baseWidth 142
layout gridster
logareas base.init,base.poll
logtype localstorage
room GERAETE
Ich habe 3 Textdateien mit dem Frontend-Log beigefügt, gemäss deinen Anweisungen.
Ich habe versucht, alles so darzustellen, dass es für dich ok und einfach ist. Vielen Dank für die Unterstützung.
Falls noch etwas fehlt, bitte fragen.
Hi,
die Logs zeigen klar, dass der Versuch, einen Websocket anzulegen, relativ schnell fehlschlägt. Ich kenne das Problem mit der Basic Authentication unter IOS, aber das sollte sich eigentlich mit dem basicAuthExpiry erledigen. Anscheinend funktioniert auch das erst mit IOS 13 oder so.
Könnten wir noch einen Versuch machen? Könntest Du mal die Passwortabfrage ganz abschalten, also z.B. ein FHEMWEB-Device machen, das nur für lokale Zugriffe offen ist, aber halt keine Authentication braucht?
Mich würde interessieren, ob das funktioniert.
Gruß,
Thorsten
Hallo Thorsten,
ZitatAnscheinend funktioniert auch das erst mit IOS 13 oder so.
danke für dein Feedback. Ich habe abers schon IOS13 installiert.
Nun zu deiner Bitte:
ZitatKönntest Du mal die Passwortabfrage ganz abschalten, also z.B. ein FHEMWEB-Device machen, das nur für lokale Zugriffe offen ist, aber halt keine Authentication braucht?
Ich habe ein zusätzliches FHEMWEB eingerichtet.
Internals:
CFGFN
CONNECTS 8
CSRFTOKEN csrf_60981132344754
DEF 8086 global
FD 71
FUUID 5e217b67-f33f-1e06-f5f7-158e94c80e23b45c
NAME WEBUI
NR 2185
NTFY_ORDER 50-WEBUI
PORT 8086
STATE Initialized
TYPE FHEMWEB
READINGS:
2020-01-17 10:16:23 state Initialized
Attributes:
DbLogExclude .*
Wenn ich über diesen Weg das UI anzeige, kommt der Fehler "Disconnected" nicht mehr... zumindest nicht direkt ersichtlich. Das könnte der Weg zu einer Lösung sein.
Ich hoffe, dass ich dir damit und mir geholfen habe.
Mmm... sehr seltsam.
Wie sieht es denn aus, wenn Du auf demselben Gerät FHEMWEB startest? Kommt da die Passwortabfrage jedesmal beim Neustart des Browsers? ...oder wie genau reagiert es da?
Gruß,
Thorsten
Hi,
insbesondere für die Apfelianer habe ich jetzt doch noch eine Ajax-Version (also ohne Websockets) zusammengebastelt. Könnte das mal jemand ausprobieren?
Also mal ein Update machen und dann im FUIP-Device das Attribut "longPollType" auf "ajax" setzen.
Klappt das dann?
Gruß,
Thorsten
Update gemacht, restart, BasicAuthExpiry gelöscht, longPollType auf ajax gesetzt, FUIP aufgerufen: funktioniert einwandfrei mit Safari auf macOS und iOS.
Gegenprobe: ändere ich longPollType auf websockets zurück, bekomme ich wieder einen Disconnect.
Ich werde es am nächsten WE ausführlicher testen...
Vielen Dank fürs Einbauen !!!!!
Zitat von: PeterLustig am 31 Januar 2020, 07:27:39
Ich werde es am nächsten WE ausführlicher testen...
Vielen Dank!
Könntest Du auch mal ausprobieren, wie das ganze darauf reagiert, wenn Du das ganze mit dem Handy aufrufst und es dann über Nacht liegen lässt? Braucht es dann nach dem Aufwachen ein Reload oder geht es einfach so weiter?
Gruß,
Thorsten
Ich habe gestern noch eine FUIP-Seite geöffnet, auf der mir geschlossene Rollläden angezeigt wurden. Beim entsperren des iPhones sah ich heute noch kurz (unter 1 sec) die Symbole für "geschlossen", dann wechselten die Symbole selbständig zu "geöffnet". Die Anzeige hat sich also nach dem Entsperren gleich synchronisiert, ohne dass ich die Seite neu laden musste.
Bisher perfekt, nachher werde ich weiter testen...
Auch auf dem iPad läuft es einwandfrei, es aktualisiert sich ebenfalls gleich nach dem Entsperren selbständig. Seiteneffekte konnte ich nicht feststellen, alle Unterseiten wurden korrekt dargestellt.
Noch einmal Danke für die Berücksichtigung einer Randgruppe :) :)