Hallo zusammen,
mein neues Tablet hat die doofe Angewohnheit, nach 5 Minuten "Bildschirm aus" die Netzwerkverbindung zu verlieren, obwohl es selbst und mit FULLY gegenteilig konfiguriert ist. Und das automatische Reloaden der Seite, wenn der Bildschirm angeht, dauert zu lange. Aber das ist ein anderes Problem. In diesem Zusammenhang ist mir nur aufgefallen, dass unter diesen Umständen kein sauberer Reconnect von FTUI erfolgt. Ich habe etwas tiefer gegraben:
Was passiert: Zunächst fliegt FTUI der Websocket um die Ohren (oder AJAX, spielt keine Rolle), was auch sofort erkannt wird:
Error while Longpoll: undefined;
FTUI is offline
Das heißt, es wird in der Methode setOffline u.A. folgendes gemacht:
ftui.config.doLongPoll = false;
Wenn jetzt beliebig viel später das Netzwerk wieder da ist (in meinem Fall, weil ich über Fully den Bildschirm anschalte), kommt brav
'Page became visible again -> start healthCheck in 3 secondes
und sofort der Healthcheck . Der findet aber kein Fehler und reconnected den Longpoll nicht, denn er prüft folgendes:
if (timeDiff / 1000 > ftui.config.maxLongpollAge &&
ftui.config.maxLongpollAge > 0 &&
!ftui.config.DEMO &&
ftui.config.doLongPoll) { ///// ftui.config.doLongPoll == FALSE -> KANN NICHT WAHR WERDEN!
ftui.log(1, 'Healthcheck: No longpoll event since ' + timeDiff / 1000 + 'secondes -> ftui.setOnline()');
ftui.setOnline();
ftui.restartLongPoll();
}
Mit anderen Worten, der Longpoll wird nicht wieder angeschaltet, egal wielang das letzte Longpollevent her ist, weil ftui.config.doLongPoll in setOffline explizit abgeschaltet wurde ... ich versuche mich mal an einem Fix ...
Edit: OK ich glaube ich hab es jetzt ein Stück weiter verstanden: Nach shortpoll_intervall wird der Reconnect tatsächlich wieder versucht und der Longpoll geht dann auch bei mir wieder ... laut Doku also per Default nach 15 Minuten:
shortpoll_interval 900 Integer Zeitraum in Sekunden, nach dem ein vollständiger Refresh stattfindet
Das Problem ist, dass bei funktionierendem Longpoll dann alle N Sekunden ein Shortpoll passiert. Also wenn ich das auf deutlich kürzer Stelle um schneller zu Reconnecten (sagen wir auf 5 Sekunden) der Load von dem Tablet und FHEM natürlich extrem viel höher wird.
Daher denke ich, wäre es sinnvoll, den Healthcheck zu patchen, damit das in diesem Fall schneller geht ... das habe ich versucht und es klappt prinzipiell:
healthCheck: function () {
ftui.log(1, 'Healthcheck: Starting. ftui.config.maxLongpollAge=' + ftui.config.maxLongpollAge + ", ftui.config.doLongPoll="+ ftui.config.doLongPoll +", ftui.poll.long.lastEventTimestamp=" + ftui.poll.long.lastEventTimestamp.toLocaleString("de-de"));
var timeDiff = new Date() - ftui.poll.long.lastEventTimestamp;
var longpollConfig = $("meta[name='longpoll']").attr("content") || '1';
var shouldDoLongPoll = (longpollConfig != '0');
if (timeDiff / 1000 > ftui.config.maxLongpollAge &&
ftui.config.maxLongpollAge > 0 &&
!ftui.config.DEMO &&
shouldDoLongPoll && !ftui.config.doLongPoll) {
ftui.log(1, 'Healthcheck: No longpoll event since ' + timeDiff / 1000 + 'secondes -> ftui.setOnline()');
ftui.setOnline();
ftui.restartLongPoll();
} else {
ftui.log(1, 'Healthcheck: Finished - no errors found.');
}
},
Allerdings haut der Reconnect der Websockets dann leider trotzdem nicht immer hin (ca. 1/10 mal klappt es nach einer Weile und er aktualisiert wieder), das heißt setOnline() / restartLongPoll müsste noch weiter debuggt werden, was ich leider zeitlich nicht schaffe, aber vielleicht hilft es ja soweit schon jemanden :-)
OK ich habe es aufgegeben das Reconnecten mit FTUI-Mitteln zu versuchen ... mal geht es, mal nicht - alles für einen hohen WAF nicht akzeptabel.
Meine Lösung besteht jetzt im kompletten deaktivieren des FTUI-Healthchecks und einem eigenen kleinen Javascript, das einfach in FULLY einen Seitenreload triggert, wenn keine Longpoll-Events mehr kommen. Das läuft jetzt perfekt. Kann ich bei Interesse gern posten, ist aber fummelig. Was auch noch toll wäre: In FTUI eine offizielle Option zu schaffen, einen Fully-Reload zu triggern. Mehr als
if (typeof fully != 'undefined') {
fully.loadStartUrl();
}an der richtigen Stelle, die ich allerdings nicht sicher identifizieren konnte - vermutlich irgendwie im healthCheck - braucht es dazu auch nicht (geht aber glaub ich nur in der Pro-Version).
An/ausschalten kann ich den Bildschirm vom Tablet allerdings trotzdem nicht spontan (über einen Bewegungsmelder), da die Seite jetzt direkt nach dem Einschalten neu geladen wird, was viel zu lange dauert. Mit dem Fully Screensaver ist es auch nicht viel besser. Abhilfe ist daher jetzt ein schwarzes <div> über den gesamten Bildschirminhalt in Kombination mit gesenkter Bildschirmhelligkeit ... sieht FAST aus wie abgeschaltet ;)
... So ein Gefrickel. Bei meinem alten Tablet und den anderen Tablets lief bzw. läuft das so gut, aber das mit dem neuen - Galaxy Tab A (2016), Android 8.1 - ist echt krampfig.
Hi,
kann es sein, dass das noch nicht repariert ist? Ich glaube, dass ich dasselbe Problem habe. (...und ich glaube mindestens noch Devender in diesem Thread: https://forum.fhem.de/index.php/topic,102567.0.html).
Das Blöde daran ist, dass es ziemlich schwierig bzw. zeitaufwändig ist, das ganze zu analysieren. Ist da schon jemand weiter gekommen?
Gruß,
Thorsten
Ich hatte es aufgegeben, einen sauberen Patch dafür zu bauen, da nichts zuverlässig funktioniert hat. Bei meinem aktuellsten Tablet bricht mir immer noch oft der Websocket weg - ich habe aber bislang keine Systematik gefunden. Mal passiert es nach 5 Minuten, mal erst nach 12 Stunden.
Mein Workaround ist aktuell, dass ich per at einen Dummy in FHEM alle 60 Sekunden auf die aktuelle Uhrzeit setze. Im TabletUI ist für den Dummy ein (unsichtbares) Label, was ich alle 2 Minuten (also per Javascript-Timer, unabhängig von irgendwelchen Events) auf die aktuelle Uhrzeit prüfe. Ist die Uhrzeit im Label zu alt, heißt das, das aus welchem Grund auch immer keine Longpoll Events mehr in der GUI ankommen. Dann wird ein kompletter Page-Reload getriggert (über Fully). Das ist sozusagen ein vollständiger Ende-zu-Ende-Check. Der Reload triggert am Tag auch wirklich immer mindestens 2-3 mal. Dumm nur, dass das Laden ewig dauert und das alles ziemlich gebastelt ist.
Hi,
guck mal da:
https://forum.fhem.de/index.php/topic,102884.0.html
Kannst Du die Korrektur mal ausprobieren?
Gruß,
Thorsten
Klingt vielversprechend, kann ich aber leider grad nicht testen - die Hausautomatisierung ist bei mir momentan komplett deinstalliert zwecks Umzug ;-( Frühestens Ende September spiele ich wieder mit - aber wer anders probiert das doch sicher gern mal aus ^^
Wie genau ist denn das Problem bei euch? Ich habe auch das Problem, dass das Tablet wenn sein Bildschirm aus ist, die Inhalte im Hintergrund nicht aktualisiert. Wenn dann der Bewegungsmelder den Bildschrim einschaltet, dann sieht man erst noch die alten (z.B. Temperatur-)Werte. Dann nach ca. 1 Sekunde wird offenbar aktualisiert und die Werte springen um. Reden wir damit vom selben Problem?
vbs - nein. Symptomatisch ist es bei mir so, dass sich das Tablet irgendwann überhaupt nicht mehr aktualisiert, egal ob Bildschirm an oder nicht. Zumindest nicht in Echtzeit (nur noch Shortpoll). Grund ist das wegbrechen der Sockets und fehlender / klemmender Reconnect. Das geht nur mit schmutzigen Tricks länger als ein paar Stunden.
Also ich hab es nach einigem hin- und her mit dieser App geschafft, dass das Tablet die WLAN-Verbindung dauerhaft aufrecht erhält:
https://play.google.com/store/apps/details?id=pl.mariobile.bestwifikeeper&hl=de
Nur wie gesagt komisch, dass Werte nicht aktualisiert werden (bzw. erst wenn dann auch der Bildschirm an geht). Aber ich kann das Tablet (Galaxy Tab 2) jederzeit per Netzwerk einschalten (also das Display).
Hi,
bei mir kommt es anscheinend darauf an, wie lange das Telefon "schläft". Wenn der Bildschirm ausgeht und ich ihn sofort wieder "aufwecke", dann ist alles ok. Wenn ich aber länger warte (ein paar Minuten), dann dauert es bis zu einer Minute und 10 Sekunden, bis alles wieder aktuell ist. (Ich glaube, dass ich auch schon den Fall hatte, dass es länger als 70 Sekunden gedauert hat, aber das konnte ich nicht sicher nachvollziehen, daher will ich es erstmal dabei belassen bis das nachvollziehbare Problem gelöst ist.)
Wie im anderen Thread beschrieben liegt das bei mir daran, dass der Websocket "zu geht" und FTUI das nicht so richtig mitbekommt. Die Lösung für genau dieses Problem ist auch relativ einfach (siehe den anderen Thread).
Ich habe bisher noch nicht ausprobiert was passiert, wenn man FTUI auf "longpoll/ajax" zwingt. Ich kann mir vorstellen, dass es dann auch wieder besser klappt. Allerdings ist das meiner Meinung nach auch etwas unschön, da Websockets eher die "heutige" Technik sind.
Ich halte auch nicht viel davon, das über irgendwelche "lass die Verbindung offen"-Tricks zu lösen. Meiner Meinung nach kann die Verbindung immer irgendwie abbrechen (z.B. wenn ich nicht zuhause bin und grade nicht immer VPN laufen habe). In dem Fall schlägt der Fehler nämlich auch zu. Außerdem kann ich mir vorstellen, dass es schon seinen Grund hat, solche Verbindungen zu schließen, wie z.B. den Akku zu schonen. (Für stationäre Tablets ist das unter Umständen egal.)
EDIT: Witzig ist auch, dass das ganze passieren kann, wenn ein Widget gar keine Rückmeldung vom Backend braucht. Siehe die "späte Aktualisierung" in.
https://forum.fhem.de/index.php/topic,102885.0.html .
Gruß,
Thorsten
Moin,
ich hab mir jetzt mal alle verwiesenen Threads durchgelesen und bin mir nicht sicher, in welchem ich am besten antworte.
Ich habe mit FTUI folgende Situation: Tablet, Huawei Media Pad T5, Fully Browser. Seite wird einwandfrei angezeigt und ist auch responsiv (wenn ich drauf drücke, schaltet fhem)
Wenn ich morgens runter komme, schaltet Fully via Bewegungserkennung das Display ein, die Werte sind aber deutlich veraltet (z.B. die Sonne knallt, der Wechselrichter lärmt auf Hochtouren, aber das Tablet zeigt "0W". Wenn ich direkt in fhemweb schaue (vom Handy aus z.B.) habe ich die korrekten Werte.
Nach einigen Sekunden scheint die Seite die letzten Werte "nacharbeiten" zu wollen, auf jeden Fall ändern sich die Werte mehrfach in wenigen Sekunden, wild hoch und runter, aber im Bereich dessen, was im normalen Betrieb auftritt.
Meistens verliere ich dann die Geduld und lade die Seite manuell neu, dann funktioniert es sofort wieder. Wenn ich lange genug warte, funktioniert es auch von alleine wieder, das können allerdings deutlich mehr als 2 Minuten sein.
Könnte das hiermit zusammenhängen oder ist das ein anderes Problem?
Grüße,
Stephan
Zitat von: abc2006 am 28 August 2019, 10:22:50
Könnte das hiermit zusammenhängen oder ist das ein anderes Problem?
Ich glaube, dass das auch damit zusammenhängen kann. Soweit ich das verstehe (was nicht unbedingt ganz stimmen muss), holt sich FTUI beim Reconnect unter Umständen alles, was seit dem letzten bekannten Update passiert ist. (Also alle Events der Readings auf der dargestellten Seite seit "gestern Abend".) Je nach Gerät kann da schon was zusammenkommen. Wenn jetzt noch das Widget (oder auch ein anderes Widget auf der Seite) beim Repaint ("update") langsam ist, dann kann es da wohl schon zu Verzögerungen kommen.
Hast Du mal ausprobiert, ob es longpoll vs. websocket einen Unterschied macht?
Gruß,
Thorsten
Zitat von: abc2006 am 28 August 2019, 10:22:50
[...]
Wenn ich morgens runter komme, schaltet Fully via Bewegungserkennung das Display ein, die Werte sind aber deutlich veraltet
[...]
Soweit ich mich erinnere, hatte ich ein ähnliches Problem. Meine Lösung war, den Bildschirm nicht abzuschalten, sondern einen Screensaver mit schwarzem Bild zu aktivieren. Der Stromverbrauch steigt, aber alle Anzeigen sind auf dem aktuellen Stand. Später entwickelte ich das weiter: Sehr dunkles, individuelles Bild, darin in Großbuchstaben eingeblendet: Uhrzeit und Temperatur. Als Screensaver wird quasi eine eigens gestaltete FTUI-Seite mit Hintergrundbild verwendet. Mit dieser Lösung bin ich sehr zufrieden.
Hi Thorsten,
in meiner index.html steht
<meta name="longpoll" content="1"> <!-- 1=longpoll;0=shortpoll every 30sec -->
<meta name="longpoll_type" content="websocket">
<meta name="longpoll_maxage" content="240"><!--wird in diesem Zeitraum kein Longpoll empfangen, wird die seite refreshed -->
ich dachte, websocket IST longpoll ...
Ich hab da vor längerer Zeit mal rumprobiert, auch mit änderungen im FHEMWEB (z.b. attr FHEMWEB longpoll websocket) ist die aktuelle einstellung.
Kannst du bitte nochmal genauer spezifizieren, welchen Unterschied ich testen soll/kann?
Meintest du, ich soll "websocket" auf "ajax" ändern? Muss ich dann im FHEMWEB auch was ändern?
ZitatAls Screensaver wird quasi eine eigens gestaltete FTUI-Seite mit Hintergrundbild verwendet. Mit dieser Lösung bin ich sehr zufrieden.
Wie hast du das technisch umgesetzt? Screensaver mit Uhr und Datum wär natürlich auch cool ...
Danke euch und Grüße,
Stephan
Zitat von: abc2006 am 29 August 2019, 13:44:30
<meta name="longpoll" content="1"> <!-- 1=longpoll;0=shortpoll every 30sec -->
<meta name="longpoll_type" content="websocket">
<meta name="longpoll_maxage" content="240"><!--wird in diesem Zeitraum kein Longpoll empfangen, wird die seite refreshed -->
ich dachte, websocket IST longpoll ...
Das war tatsächlich von mir etwas ungeschickt formuliert. Ich meinte damit den "alten" longpoll, also mit type=ajax.
(Übrigens stimmt Dein Kommentar zum longpoll_maxage meiner Meinung nach nicht: Ein Refresh der Seite gibt's da nicht. FTUI macht dann nur die Verbindung zu und wieder auf. Es wird also ein neuer longpoll gestartet.)
Zitat
Kannst du bitte nochmal genauer spezifizieren, welchen Unterschied ich testen soll/kann?
Meintest du, ich soll "websocket" auf "ajax" ändern?
Ja, genau das.
Zitat
Muss ich dann im FHEMWEB auch was ändern?
Nein. Ich bin mir noch nicht 100%ig sicher, aber ich glaube, dass die Einstellungen in FHEMWEB bezüglich long/shortpoll für FTUI völlig egal sind.
Gruß,
Thorsten
Zitat von: abc2006 am 29 August 2019, 13:44:30
Wie hast du das [Anm.: Screensaver] technisch umgesetzt? Screensaver mit Uhr und Datum wär natürlich auch cool ...
Danke euch und Grüße,
Stephan
Ist eigentlich ziemlich einfach: In Fully gibst Du für den Screensaver die URL zur Datei
index-idle.html ein.
index-idle.html :<!DOCTYPE html>
<html>
<head>
<link rel="stylesheet" href="css/fhem-tablet-ui.css" />
<link rel="stylesheet" href="css/Layout_idle.css" />
<script src="js/fhem-tablet-ui.js" defer></script>
</head>
<body>
<div class="col-1-2 top-align left-align gigantic thin" data-type="label" data-device="WetterProplanta" data-get="temperature" data-fix="0" data-unit="°C" data-color="#555555"></div>
<div class="col-1-2 top-align right-align gigantic thin" data-type="clock" data-format="G:i" style="color: #555555"></div>
</body>
</html>Hierin wird auf
Layout_idle.css referenziert:
Layout_idle.css :/* Hintergrundbild Bildschirmschoner */
body {
background-image: url(../images/<Hintergrundbild>.jpg) !important;
background-repeat: no-repeat;
background-position: right top;
background-attachment: fixed;
} Das Hintergrundbild sollte sehr dunkel sein und an den Stellen, wo die Daten eingeblendet werden, keine störenden Inhalte aufweisen. Es bietet sich an, ein individuelles Bild aus dem persönlichen Umfeld zu nehmen. Ich habe ein solches Motiv mit dem Bildbearbeitungsfilter
Relief verfremdet, sodass es hauptsächlich aus Konturen besteht und überwiegend dunkelgrau ist.
Die angezeigten Inhalte kann man natürlich beliebig erweitern. Ich habe das sehr sparsam gestaltet, denn es soll ja ein Screensaver sein, der bei Bewegungs- oder Geräuscherkennung (je nach Fully-Version und gewählter Konfiguration) ausgeblendet wird.
Zitat von: abc2006 am 29 August 2019, 13:44:30
Meintest du, ich soll "websocket" auf "ajax" ändern? Muss ich dann im FHEMWEB auch was ändern?
So, hab das jetzt ein paar Tage getestet. Gefühlt ist das Problem *besser* geworden, aber nachweislich nicht verschwunden.
Die Aktualisierung scheint nur etwas schneller zu gehen und nicht so oft notwendig zu sein - kann aber auch mit dem Nutzungsprofil zusammenhängen.
Die Auffälligkeit, dass die Werte "nachgearbeitet" werden, ist weiterhin gelegentlich zu beobachen.
Grüße,
Stephan
Hi,
ich glaube, dass ich das für FUIP zumindest gelöst habe. Für FTUI müssen da aber andere ran, da es sozusagen den "Kernel" betrifft.
Das mit dem "Nacharbeiten" verstehe ich nicht so ganz. Meine Vermutung von vorher ist wahrscheinlich falsch. Ich kann mir nur vorstellen, dass das "schlafende" Gerät die Verbindung nicht abbricht und auch von der FHEM-Seite kein Abbruch kommt. Dann staut sich ggf. alles an und es wir beim Aufwachen alles gesendet. Theoretisch müsste da aber eine Seite in den Timeout gehen und die Verbindung abbrechen.
Ich habe mit dem ganzen Kram jetzt ziemlich viel herumexperimentiert und es scheint mir zumindest bei dem mobilen Browsern da kein einheitliches Vorgehen zu geben. Ich glaube, dass ich in FUIP alles abfange, aber sicher bin ich mir da auch nicht. Vielleicht will es jemand ja mal ausprobieren.
Gruß,
Thorsten
Hi Thorsten,
Ich wuerde es sehr gerne teste.
Reicht ein Update oder muss was bezueglich polling geandert werden.
Gruesse,
Dirk
Zitat von: vbs am 11 August 2019, 12:01:51
Wie genau ist denn das Problem bei euch? Ich habe auch das Problem, dass das Tablet wenn sein Bildschirm aus ist, die Inhalte im Hintergrund nicht aktualisiert. Wenn dann der Bewegungsmelder den Bildschrim einschaltet, dann sieht man erst noch die alten (z.B. Temperatur-)Werte. Dann nach ca. 1 Sekunde wird offenbar aktualisiert und die Werte springen um. Reden wir damit vom selben Problem?
Hallo,
gibt es dafür evtl. eine Lösung? Habe genau das gleiche Probleme das die alten Werte erst nacheinander angezeigt werden.
Ich nutze FTUI mit Fully auf einem Lenovo Tab als Anzeige.
Hi,
ich glaube, dass das mit der kurzen Verzögerung der Fall ist, in dem es tatsächlich funktioniert. Mobilgeräte scheinen im "Schlaf" ggf. die Netzwerkverbindungen abzuschalten, um Strom zu sparen. Wenn sie dann aufwachen muss FTUI erstmal die ganzen Daten vom Server holen. In der Regel geht das per Shortpoll, es wird also alles geholt, was auf der Seite sichtbar ist. Mit dem vorherigen Aufbau der Netzwerkverbindung kann das halt ein bisschen dauern.
Gruß,
Thorsten
Zitat von: Thorsten Pferdekaemper am 12 August 2019, 14:56:00
Ich halte auch nicht viel davon, das über irgendwelche "lass die Verbindung offen"-Tricks zu lösen. Meiner Meinung nach kann die Verbindung immer irgendwie abbrechen (z.B. wenn ich nicht zuhause bin und grade nicht immer VPN laufen habe).
Hm, hab ich noch nicht ganz verstanden: Wie weckst du denn das Gerät dann auf, wenn die Verbindung erst einmal weg ist? Ist dein Use-Case ein anderer? Ich hab ein Tablet im Flur, welches aktiviert wird, wenn der Bewegungsmelder feuert. Wenn ich nicht per Trick die Verbindung künstlich offen halte, dann kann ich es einfach nicht erreichen bei Bewegung.
Zitat von: vbs am 07 November 2019, 17:18:21
Hm, hab ich noch nicht ganz verstanden: Wie weckst du denn das Gerät dann auf, wenn die Verbindung erst einmal weg ist? Ist dein Use-Case ein anderer? Ich hab ein Tablet im Flur, welches aktiviert wird, wenn der Bewegungsmelder feuert. Wenn ich nicht per Trick die Verbindung künstlich offen halte, dann kann ich es einfach nicht erreichen bei Bewegung.
Da ist mein Use-Case bzw. mein Problem tatsächlich ein anderes. Ich wecke mein Telefon mit meinen Fingern auf und dann ist die Verbindung in der Regel abgebrochen. Das ist auch ganz gut so, weil die WLan-Verbindung Strom kostet. Ich hätte dann gerne, dass sich das ganze wieder Verbindet, und zwar immer.
Bei Dir ist es ja praktisch anders herum. Du brauchst die Netzwerkverbindung im Prinzip die ganze Zeit.
Gruß,
Thorsten
Hi Thorsten,
Zitat von: Thorsten Pferdekaemper am 04 November 2019, 23:06:39
ich glaube, dass ich das für FUIP zumindest gelöst habe. Für FTUI müssen da aber andere ran, da es sozusagen den "Kernel" betrifft.
Ich habe mir jetzt den ganzen ursprünglichen FUIP-Thread durchgelesen und werde es vermutlich demnächst mal installieren.
Allerdings habe ich bereits mehrere fertige FTUI-Seiten, die meine (aktuellen) Bedürfnisse befriedigen - bis auf die notwendige aktualisierung nach dem aufwachen.
Wenn ich die Infos richtig verstanden habe, besteht dieses Problem mit FUIP nicht. Es legt aber komplett neue Seiten an, die erst neu konfiguriert werden müssten - wenn die von mir verwendeten Widgets schon implementiert sein sollten. Gibt es (mittlerweile) eine Möglichkeit, bereits vorhandene FTUI-Seiten weiter zu benutzen?
Ein echtes Killer-Feature wäre, wenn ich mir die Daten von mehreren Fhem-Instanzen holen könnte - das fehlt mir bei FTUI und erfordert einige zusätzliche FHEM2FHEM-Dummys.
(Ausformuliert: ein FUIP-FHEM, auf dem das FTUI läuft, und dann (z.B.) mit dem attribut fhemwebUrl MEHRERE instanzen angeben, von denen ich Daten holen und senden kann).
Denkst du, deine Änderungen in FUIP bezüglich dem aktualisieren sind für mich ansatzweise nachvollziehbar? Nun ja, ich bin nicht gut in JS, aber vielleicht könnte ich von dem ein oder anderen was in FTUI übernehmen?
Danke und viele Grüße,
Stephan
Zitat von: abc2006 am 07 November 2019, 21:59:43Wenn ich die Infos richtig verstanden habe, besteht dieses Problem mit FUIP nicht.
In der momentanen Version habe ich noch einen Fall, aber der ist mir bekannt und ich bin gerade dabei, das auch zu behandeln.
Zitat
Es legt aber komplett neue Seiten an, die erst neu konfiguriert werden müssten - wenn die von mir verwendeten Widgets schon implementiert sein sollten. Gibt es (mittlerweile) eine Möglichkeit, bereits vorhandene FTUI-Seiten weiter zu benutzen?
Nein, das geht nicht. Ich glaube auch nicht, dass das jemals gehen wird. Vielleicht schaffe ich irgend wann einmal, eine Art Konverter zu schreiben, aber auch dann ist wahrscheinlich viel Nacharbeit notwendig.
Zitat
Ein echtes Killer-Feature wäre, wenn ich mir die Daten von mehreren Fhem-Instanzen holen könnte - das fehlt mir bei FTUI und erfordert einige zusätzliche FHEM2FHEM-Dummys.
Da ich jetzt sowieso auch den "Kernel" (also die fhem-tablet-ui.js) nach FUIP kopiert habe, kam mir die Idee auch schon. Das ist aber gar nicht so einfach, da man dann auch die ganze Behandlung der Verbindungsabbrüche wieder umbauen müsste. Außerdem die ganzen Listen von Devices und Readings etc....
Aber mal sehen, das kann ich mir eher vorstellen als den FTUI-FUIP-Konverter.
Zitat
Denkst du, deine Änderungen in FUIP bezüglich dem aktualisieren sind für mich ansatzweise nachvollziehbar? Nun ja, ich bin nicht gut in JS, aber vielleicht könnte ich von dem ein oder anderen was in FTUI übernehmen?
Du könntest mal versuchen, FUIP zu installieren und dann die Datei /opt/fhem/FHEM/lib/FUIP/js/fuip_tablet_ui.js nach /opt/fhem/www/tablet/fhem-tablet-ui.js zu kopieren. ...und die dann in Deinen FTUI-Seiten zu verwenden. Es kann sein, dass das funktioniert.
Gruß,
Thorsten