[FHEM-Tablet-UI] WeekdayTimer Widget

Ulm32b · 08 Dezember 2016, 16:08:58

ZitatNoch was, stört mich aber nicht. Beim Chrome bekomme ich immer den "disable" Schalter doppelt nebeneinander angezeigt beim Firefox nicht.

Die doppelten Schalter, genauer gesagt die doppelten Fenster sind bekannt, siehe die Postings Ende November. Es gibt auch eine Lösung, die einen kleinen Eingriff in die js-Datei erfordert, ebenfalls nachzulesen.
Mich würde nun interessieren, ob bei Dir auch ein Effekt auftritt, der bei mir nach wie vor Stand der Dinge ist: Die Felder für die Uhrzeiten sind zu schmal, sodass die Uhrzeit nur unvollständig angezeigt wird; vgl. Bilder in früheren Postings. Die Ursache ist m.W. noch nicht aufgeklärt.

Es wäre schön, wenn es demnächst eine Version gäbe, die auf allen Plattformen einheitlich läuft.

eki · 09 Dezember 2016, 10:32:45

Unter https://forum.fhem.de/index.php/topic,61799.msg536168.html#msg536168 ist eine Version, die auf die neue ftui Version 2.4 angepasst ist, und jetzt hoffentlich auch die Textbreiten richtig und dynamisch setzt.

buchner51 · 12 Dezember 2016, 21:29:42

Hallo,

ich benötige mal etwas Hilfe.

Ich bekomme den WeekdayTimer unter TabletUI nicht zu Gesicht nicht mit dem Firefox IE und Chromium.

Aber übers Handy mit Firefox geht es!!

Woran liegt das??
Beide Firefox sind auf dem Aktuellen Stand, selbst an verschiedenen Rechner ohne Erfolg.

Kennt jemand eine Lösung!?!

Gruß und Danke

eki · 13 Dezember 2016, 09:31:53

Poste mal Deine Konfiguration für FTUI. Das ist leider immer noch ein leidiges Thema, bei dem ich mich schwer tue eine Lösung zu finden, die auf allen OS und Browser Versionen zuverlässig läuft. Eventuell kann helfen den Typ des auslösenden Elements zu verändern. Also "button" statt "switch", "label" statt "symbol" oder umgekehrt (lies mal die vorherigen Beiträge hier im Thread).

Ulm32b · 13 Dezember 2016, 11:36:53

Ich kann bestätigen, dass der WD-Timer nach dem Update vom 9.12. bei mir unter Android 5.0.2 und auf dem PC (verschiedene Browser) nicht mehr startet.

Vorher hatte Eki (der zu dieser Aufgabe kam wie die Jungfrau zum Kind) auf der Basis meiner Reports im Ping-pong eine (100-x)%-Lösung gefunden. Dafür nochmals meine Anerkennung. Irgendwie erinnert mich das aber an Studienzeiten, als man am Abend nochmal in die Uni geradelt ist, erwartungsvoll den Ausdruck aus dem Fach holte, den Syntax Error las, eine neue Lochkarte stanzte ... .

Das entscheidende Feature der Interimslösung in der js-Datei ist wohl wieder wegdiffundiert. Wenn ich es richtig deute, hat Eki keine Windows / Android - Testumgebung. Effektiver dürfte sein, wenn jemand nach dem Rechten schaut, der sofort testen kann. Ich selbst würde das ja machen, wenn ich dazu befähigt wäre. Bis dahin brauche ich noch einige Zeit ...

eki · 13 Dezember 2016, 12:22:52

Falls der Eindruck entstanden ist, dass das alles eher zufällig wieder verloren gegangen ist, so ist der falsch. Ich habe beim Bauen der Version für FTUI 2.4 festgestellt, dass das Problem bezüglich der events, die sich auf allen OS und Browsern irgendwie anders verhalten, von setstate einem Versuch unterzogen wurde, es generisch zu lösen. Darauf habe ich dann die neue Version angepasst. Bei mir unter Windows und iOS hat das auch geklappt, unter anderen Umgebungen scheint es nicht zu klappen. Ich bin grundsätzlich gern bereit das Widget auch weiter zu betreuen, falls jemand mit besserer Testumgebung da schneller zum Ziel kommt, darf das natürlich auch jemand anders übernehmen.

eki · 13 Dezember 2016, 18:26:23

Mir ist jetzt noch ne Idee gekommen, wie das Problem lösbar ist. Es gibt ja nicht nur alle möglichen Browser/OS Kombinationen sondern auch noch alle möglichen Varianten was das auslösende Element betrifft (Switch, Button, Label, Icon, und was den Kollegen hier sonst noch so alles einfällt). Bitte mal unter:
https://forum.fhem.de/index.php/topic,61799.msg539210.html#msg539210
schauen und die dortige Version testen.

Ulm32b · 13 Dezember 2016, 22:50:37

... hatte ich auch schon gelesen und mir für heute Abend vorgenommen.

Das Ergebnis:

1. In der Version von Gestern:

link
button
Switch
Push
Label
Symbol

2. In der neuesten Version (Anhang zu Deinem Posting von heute, 18:21):

link
button
Switch
Push
Label
Symbol

Ich hatte also vorher mit "Link" die Niete gezogen.

Beim Testen hatte ich vorübergehend vermeintlich nicht reproduzierbare Ergebnisse, konnte das dann aber eingrenzen:
Man kann Sunrise/Sunset, A.R.D etc. eingeben und speichern, und in FHEM sieht das dann auch gut aus, z.B.:

Code Auswählen

Radio_1 de 0|{sunrise("10:00")}|on

Wenn ich dann allerdings das Widget neu öffne, kann die Definition wohl nicht richtig gelesen werden. Es erscheint die Fehlermeldung:

Zitat"widget wd_timer.js:400, Type error: Cannot read property, 'replace' of undefined"

Danach öffnet das Widget gar nicht mehr.

Weil ich bis auf Weiteres diese Zusatzfunktionen nicht nutze, spielt das für mich keine Rolle. Ich habe auch die Hinweise gelesen, dass Sunset/Sunrise nicht unterstützt wird. Möglicherweise gilt das nach wie vor.

eki · 15 Dezember 2016, 08:21:44

Schön, dann scheint ja zumindest das Event Thema jetzt erledigt zu sein.

Was Deine Versuche mit den sunrise/sunset Varianten betrifft, so funktioniert das schon. Allerdings gibt es da so viele Varianten (z.B. variable Anzahl der Parameter von sunset/sunrise), dass ich da sicher noch nicht alle möglichen und unmöglichen Eingaben abgefangen habe. In Deinem Fall hast Du nur eine Zeit gesetzt (wahrscheinlich weil Du alle Felder einfach so gelassen hast, wie sie waren und da war eben eine Zeit gesetzt) und aus meiner Sicht sollten entweder beide oder keine Zeit gesetzt sein. Aber da muss ich noch mal in die Details von sunrise/sunset schauen und solche Dinge abfangen (zumindest sollte das widget nicht mit Einstellungen verschwinden, die dann nachher dazu führen dass beim wieder Öffnen Probleme auftreten). Wird aber sicher ein bisschen dauern, bis dahin einfach die Parameter sinnvoll setzen (commandref von sunset/sunrise lesen könnte helfen

).

Ulm32b · 15 Dezember 2016, 19:53:58

Wie korrekt vermutet hatte ich weder FHEM Command Ref noch FHEM-Wiki konsultiert. Die sind auch keine leichte Kost. Ich habe jetzt verstanden, dass Perl-Sunrise/Sunset die Varianten *_rel (=relative Zeit bis zum nächsten Sonnenauf- bzw. -untergang) und *_abs (=absolute Zeit für den aktuellen Tag) kennt. Weitere Parameter sind

Horizont; nur einer der Werte REAL, CIVIL, NAUTIC, ASTRONOMIC (in genau dieser Schreibweise) bzw. HORIZON= ist erlaubt
offset = Sekunden (Ganzzahl), die auf die Zeit addiert werden
min = frühester Zeitpunkt (in Stunden:Minuten - hh:mm)
max = spätester Zeitpunkt (in Stunden:Minuten - hh:mm)

Zur Steigerung des Benutzererlebnisses möchte ich den Vorschlag machen, dass ein Info-Fenster über die möglichen Einstellungen und deren Funktionsweise informiert.

Als Vergleichsbasis kann ich das Jalousiemanagement der Fa. Jung heranziehen, welches seit 15 Jahren zuverlässig und unauffällig bei mir arbeitet. Dessen Benutzerführung ist aus heutiger Sicht natürlich unterirdisch. Interessant ist aber: Dort wird auch eine Zufallsfunktion bei der Zeitverschiebung angeboten. Die erreicht man in FHEM wohl auch via Perl. Der Gelegenheitsnutzer würde sich vermutlich freuen, wenn ihm dies auf dem Silbertablett gereicht wird.

Das ist alles (abgesehen von den erkannten möglichen Fehleingaben im WD-Timer) "Nice-to-have". Faszinierend ist, wie viel "Nice-to-habe" schon in FTUI drinsteckt.

Zum Schluss noch ein Screenshot von Android 5.0.2. Man sieht, dass im Dropdown-Menü (anders als unter Windows-Browsern) die Symbole nicht angezeigt werden. Auch nicht wirklich schlimm.

Und noch etwas: Bei aktuellen (!) Zeitschaltuhren der Fa. Somfy arbeitet die "Cosmic"-Funktion nur mit Sunset, nicht mit Sunrise. Wer hat sich das blos ausgedacht?

eki · 16 Dezember 2016, 08:05:41

Danke für die Info, mal schauen zu was ich bezüglich "nice to have" kommen. Das mit den Erklärungstexten ist ziemlich einfach zu machen. Für das Thema Zufall muss ich mich selbst erst mal schlau machen (fände aber dass es ein gutes Feature wäre). Bin grundsätzlich der Meinung dass eine Benutzeroberfläche so gestaltet sein sollte, dass man "fast" nichts falsch machen kann und alles möglichst intuitiv geht. Bis dahin ist aber noch ein weiter Weg

.
Was die fehlenden Bilder betrifft, das ist bekannt, habe leider noch keine Lösung gefunden (das Thema Pulldown Menus und Bilder ist leider sinnvoll und mit vertretbarem Aufwand fast nur mit zusätzlichen Bibiliotheken zu lösen werde mal sehen was sich machen lässt). Allerdings gibt es einen "würgaround" wenn Du beim Parameter data-style zusätzlich zu dem was du da schon hast "noicons" dazufügst, dann werden keine Bilder sondern Texte dargestellt.

buchner51 · 17 Dezember 2016, 12:34:28

Hallo,

Danke für die Info, war ganz schön verzweifelt.

jetzt funktioniert es auch.

Nochmal Danke an alle.

Ulm32b · 17 Dezember 2016, 23:15:31

Zitat... wenn Du beim Parameter data-style zusätzlich zu dem was du da schon hast "noicons" dazufügst, dann werden keine Bilder sondern Texte dargestellt.

data-style="noicons" finde ich gar nicht so übel, "SUNSET" und "SUNRISE" ist m.E. sogar eindeutiger als die Icons. Die Texte sind allerdings noch nicht in die Sprachdefinition einbezogen.

Jetzt ist mir noch aufgefallen, dass anscheinend "|<condition>" (Parameter des WeekdayTimers) beim Zurückschreiben in FHEM verloren geht. Nun bin ich nicht der Meinung, dass "|<condition>" in das Widget aufgenommen werden sollte. Vielmehr handelt es sich hier um eine eher grundlegende Einstellung, die bei der Definition in FHEM und der Konfiguration von FTUI eine Rolle spielt, nicht jedoch bei der Einstellung von Zeiten. Deshalb möchte ich auf die Request-Liste setzen, dass eine vorhandene <condition> zurückgeschrieben wird. Sie erlaubt bspw. eine einfache Aktiverung/Deaktivierung der Schaltzeiten.

eki · 19 Dezember 2016, 12:34:34

Kannst Du mal ein Beispiel schicken, das sollte nämlich eigenlich gehen (bei meinen Tests hat es funktioniert).

Ulm32b · 19 Dezember 2016, 23:43:06

Ich habe etwas ausführlicher getestet.
Ausgangspunkt war die Definition in FHEM

Code Auswählen

Radio_1 de 1|23:00|on 1|23:01|off (ReadingsVal("Radio_1_Timer_Hauptschalter", "state", "off") eq "on")
Wenn die Bedingung in der Klammer erfüllt war, wurde geschaltet; wenn sie nicht erfüllt war, wurde nicht geschaltet. Soweit alles bestens.

Dann habe ich mit dem WD-Timer die Schaltzeit "1234560|23:20|on" hinzugefügt. Anschließend stand in der FHEM-Definition:

Code Auswählen

Radio_1 de 1|23:00|on 1|23:01|off 1234560|23:20|on eq (ReadingsVal("Radio_1_Timer_Hauptschalter", "state", "off") "on")
Der hintere Ausdruck (ab "eq") wurde dann von FHEM auch nicht mehr als Condition, sondern als Command interpretiert.