[FHEM-Tablet-UI] WeekdayTimer Widget

Begonnen von svenson08, 24 Januar 2016, 18:39:21

Vorheriges Thema - Nächstes Thema

SamNitro

#405
Hey eki,

wäre es möglich in einem Timer die einzelnen Positionen zu Aktivieren/Deaktivieren?


Edit: Sind die anderen Dateien auch eingecheckt?
(Intel-Nuc Proxmox) (Homematic) (EnOcean) (CUL868) (CUL433) (Zigbee2MQTT) (ESP8266) (Echo) (DUOFERN)

Ulm32b

Wenn ich es richtig sehe, wird eine Condition noch oder wieder fehlerhaft interpretiert. Beim Speichern wird aus

Radio_2 de 5|20:10|on 25|20:30|on 1234560|22:00|on (ReadingsVal("Radio_2_Timer_Hauptschalter", "state", "off") eq "on")

ein

Radio_2 de 5|20:10|on 25|20:30|on 1234560|22:00|on eq (ReadingsVal("Radio_2_Timer_Hauptschalter", "state", "off") "on")

Danach funktioniert der Code nicht mehr. Der Klammerausdruck müsste unangetastet bleiben.

Vgl. auch
https://forum.fhem.de/index.php/topic,48106.msg543328.html#msg543328
und
https://forum.fhem.de/index.php/topic,48106.msg606213.html#msg606213

Ulm32b

Zitat von: Ulm32b am 17 März 2018, 00:58:52
Wenn ich es richtig sehe, wird eine Condition noch oder wieder fehlerhaft interpretiert.

Update: Mit der neuen Version öffnet sich das Widget bei mir nicht. Das war auch vorgestern schon so; danach hatte ich ein FTUI-Update eingespielt, welches dann die neue *.js und *.css gleich wieder überschrieben hat, und deshalb wurde die condition natürlich wieder falsch interpretiert. Es kann also durchaus sein, dass die condition-Problematik gelöst ist. Nur kann ich das derzeit nicht testen, weil sich das Widget (unter verschiedenen Browsern) nicht öffnet.

Den condition-Fehler habe ich in der alten Version mit Bordmitteln fixen können, indem ich die Klammer in eine weitere Klammer (+ Leerzeichen!) eingebettet habe, also:
Radio_2 de 5|20:10|on 5|20:30|off ( (ReadingsVal("Radio_2_Timer_Hauptschalter", "state", "off") eq "on") )
statt
Radio_2 de 5|20:10|on 5|20:30|off (ReadingsVal("Radio_2_Timer_Hauptschalter", "state", "off") eq "on")

Damit ist die Funktionalität hergestellt, das ist die Hauptsache. Etwas mühsam bleibt die Bedienung. Wählt man auf dem Tablet im Dropdown eine neue Zeit aus, wird diese im Fenster nicht übernommen; man muss sofort "Speichern" betätigen; danach schließt sich das Widget, und bei neuerlichem Aufruf wird die Änderung korrekt angezeigt.

eki

Hast Du irgendwelche Fehlermeldungen auf der Browser Konsole?

Ulm32b

Testbericht:
  • fhem-tablet-ui-wdtimer.css liegt im Verzeichnis css
  • widget_wdtimer.js liegt im Verzeichnis js
  • fhem-tablet-ui-codemirror.js liegt im Verzeichnis js
FHEM und FTUI sind auf dem aktuellen Stand.
Toast und Debug sind aktiviert:
<meta name="debug" content="5">
<meta name="toast" content="5">

Der HTML-code lautet:
<div   
data-type="wdtimer"
data-device="Zeitschalter_Radio_1"
data-language="de"
data-theme="dark"
data-style="square nokeyboard noicons"
data-title="Schaltzeiten 1Live" 
data-savecfg="true"
data-timesteps="10"
data-cmdlist='{"An":"on","Aus":"off"}'
data-width="700"
data-height="400"
data-codemirror="true">
<div data-type="button" data-icon="fa-clock-o"></div>
</div>


Mit den per FTUI-Update ausgelieferten Dateien fhem-tablet-ui-wdtimer.css und widget_wdtimer.js öffnet sich das Widget. Mit den neuen Testversionen öffnet sich das Widget nicht. Toast-Meldungen werden nicht ausgegeben. Auch im Firefox-Debugger sehe ich keine Fehlermeldungen. Hm. ???

eki

Kannst Du mal bitte mit einfach die angehängte html Datei in Dein Basisverzeichnis kopieren, dann im Browser aufrufen und schauen, ob sich damit das Fenster öffnet.

Ulm32b

#411
Zitat von: eki am 21 März 2018, 07:56:31
Kannst Du mal bitte mit einfach die angehängte html Datei in Dein Basisverzeichnis kopieren, dann im Browser aufrufen und schauen, ob sich damit das Fenster öffnet.

Hi,

mit Deiner Test.html gab es sofort Fehlermeldungen. Ich glaube aber, dass dies mit Unterschieden bei den Pfadangaben und den longpoll-Einstellungen zusammenhängt. Deshalb habe ich meinen Code weitestgehend zusammengestrichen:
<!DOCTYPE html>
<html>
<head>
<meta name="debug" content="5">
<meta name="toast" content="5">
        <script src="js/fhem-tablet-ui.js" defer></script>
</head>

<body>
<div class="hbox">
<div class="vbox phone-width">
<div class="card lift">
<header>Test</header>
<section>
<div class="row">
<div class="cell-80 left-align right-space">
<div   
data-type="wdtimer"
data-device="Zeitschalter_Radio_1"
data-language="de"
data-theme="dark"
data-style="square nokeyboard noicons"
data-title="Schaltzeiten 1Live"
data-savecfg="true"
data-timesteps="10"
data-cmdlist='{"An":"on","Aus":"off"}'
data-width="700"
data-height="400"
data-codemirror="true">
<div data-type="button" data-icon="fa-clock-o">
</div>
</div>
</div>
</div>
</section>
</div>
</div>
</div>
</body>
</html>


Mit diesem Code (Cache ist jeweils gelöscht worden) öffnet sich das Widget mit der alten Datei widget_wdtimer.js ohne Fehlermeldungen.
Mit der neuen passiert nichts; keine Fehlermeldungen.

Hilft das weiter?

eki

 ???

Ich habe das mit genau Deiner html Datei und einer frischen Installation von FTUI mit dem neuesten Stand ausprobiert und bei mir kommt das Popup. Kannst Du mir mal genau Deine Umgebung beschreiben (welche FHEM Version, welche FTUI Version, welcher Browser, welches Betriebssystem,...).

Ulm32b

#413
Also:

Der Verdacht fiel ja ziemlich eindeutig wieder auf meine Systemumgebung zurück. Deshalb habe ich überall noch einmal genau nachgeschaut. Mit try and error fand ich schließlich heraus, dass in FHEMWEB das Attribut

WEBtablet csrfToken none (vorher Standardeinstellung = random)

den entscheidenden Unterschied ausmacht. Jetzt wird die neue Version des Widgets geladen.  :)

csrfToken ist lt. Beschreibung eine Sicherheitsfunktion. Die Seiteneffekte meines Eingriffes kann ich nicht einschätzen; ein leicht flaues Gefühl bleibt.
Relativ klar ist jedenfalls, dass die Änderungen in widget_wdtimer.js irgendwo einen Zusammenhang mit dem csrfToken aufweisen. Bin ich da wirklich der einzig Betroffene?

Herzlichen Dank jedenfalls für die gewährte Unterstützung.

eki

Danke für den Hinweis, damit hast Du einen Fehler im Widget aufgedeckt. Kannst Du bitte mal mit der anghängten Version und dem wieder eingeschalteten csrfToke Feature testen, ob es jetzt geht.
Ich habe bei mir das csrfToken Feature ausgeschaltet, weil ich mein System nicht nach außen öffne sondern immer über VPN gehe, und da sehe ich wenig Gefahr für einen Cross-Site Angriff.

Ulm32b

#415
Hallo,
wie erwartet funktioniert die neueste Version auch ohne deaktiviertes csrfToken. Das Thema ist damit erledigt. War doch alles in allem eine gute Aktion. 8)

Nachfolgend zwei Bilder, wie es bei mir jetzt aussieht, einmal Android und einmal Firefox. Rein optisch fällt auf, dass bei Android im Fenster der Zeitangabe noch ein Icon stört. Gravierender sind die Unterschiede in der Bedienung: Während man im Firefox (mit der Maus) mittels Dropdown-Menü eine Uhrzeit auswählen kann und diese dann auch sofort in das Fenster übernommen wird, verhält sich Android da etwas eigenwillig: Eine ausgewählte Zeit wird nicht in das Fenster übernommen. Wenn man dann aber speichert, wird die vorher ausgewählte Uhrzeit verwendet. Das ist gewöhnungsbedürftig, jedenfalls nicht intuitiv. Das Widget datetimepicker harmoniert diesbezüglich besser mit Android.

Nett wäre auch, wenn im Dropdown-Menü die vorher ausgewählte Uhrzeit bereits im Fokus stünde.

Relevanz Priorität C: Spracheinstellung ohne erkennbare Auswirkung (erwartet wurde bei "de" die Angabe "Zeit" statt "time").

Ulm32b

Hallo Eki,

mit dem wdtimer gibt es noch ein Problem: Die Animation "Blinken" eines anderen Widgets (an beliebiger Stelle in FTUI) wird in Gegenwart des wdtimers grundsätzlich unterbunden.

Dies läßt sich reproduzierbar z.B. in folgender Testumgebung zeigen:
<!DOCTYPE html>
<html>
<head>
<meta name="debug" content="5">
<meta name="toast" content="5">
  <script src="js/fhem-tablet-ui.js"></script>
</head>

<body>
<div data-type="symbol" data-icon="oa-fts_garage_door_40 blink"></div>

<div   
data-type="wdtimer"
data-device="Zeitschalter_Radio_1"
data-theme="dark"
data-style="square nokeyboard noicons"
data-savecfg="true"
data-timesteps="10"
data-cmdlist='{"An":"on","Aus":"off"}'
data-width="700"
data-height="400"
data-codemirror="true">
<div data-type="button" data-icon="fa-clock-o">
</div>
</div>

</body>
</html>


Nutzt man die neueste Version des wdtimers (23.3.2018; https://forum.fhem.de/index.php/topic,48106.msg785443.html#msg785443), blinkt das Symbol nicht. Mit einer Version aus 2017 (Dateigröße 96.059 Byte) blinkt das Symbol, wie es sein soll.

Ich bin mir nicht sicher, aber gefühlt tritt dieser Effekt erst seit FTUI 2.7 auf.

eki

Hat leider länger gedauert, aber, ich denke ich habe das Problem gefunden (lag am Einbinden von Codemirror für das Context Highlight des Kommandoteils im Widget). Kannst Du bitte mal mit der angehängten Version testen.

Lichti

Hab auch mal etwas rumgespielt.
Funzt super!

Aber ein kleines Problem mit der Darstellung:
- der Papierkorb sitzt etwas zu tief.
- kann man die Felder mit den Häkchen über den Wochentagsnamen ausblenden ?

Ulm32b

Zitat von: eki am 16 Mai 2018, 09:03:48
Hat leider länger gedauert, aber, ich denke ich habe das Problem gefunden (lag am Einbinden von Codemirror für das Context Highlight des Kommandoteils im Widget). Kannst Du bitte mal mit der angehängten Version testen.
:) Der Test in meiner Produktivumgebung verlief positiv: Die Blink-Funktion wird jetzt nicht mehr beeinflusst. Andere unerwünschte Seiteneffekte sind nicht erkennbar. Ich denke, dass diese Version ins FTUI-Update kommen kann (genauso wie Chart). Dann braucht man auch nicht mehr nach FTUI-Updates manuell nachzuarbeiten.

Die Oberfläche sieht aus wie am 23.3. gepostet.
@ Lichti: Hast Du die fhem-tablet-ui-wdtimer.css vom 23.3. benutzt? Bei mir (Andoid 5.0.2 mit Fully) ist der Papierkorb nicht verschoben. Die anderen am 23.3. geschilderten Eigentümlichkeiten sind noch vorhanden. Vorläufig kann ich gut damit leben.
Danke und Gruß