Disconnected from FHEM

Begonnen von Patrik, 24 November 2019, 11:15:09

Vorheriges Thema - Nächstes Thema

Thorsten Pferdekaemper

#15
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)
FUIP

Thorsten Pferdekaemper

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
FUIP

UweUwe

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.





UweUwe

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 .


Thorsten Pferdekaemper

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
FUIP

UweUwe

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.





Thorsten Pferdekaemper

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
FUIP

UweUwe

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.

Thorsten Pferdekaemper

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
FUIP

Thorsten Pferdekaemper

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
FUIP

PeterLustig

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 !!!!!

Thorsten Pferdekaemper

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
FUIP

PeterLustig

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... 

PeterLustig

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  :) :)