Hauptmenü

FTUI version 3

Begonnen von Bunnu, 25 Oktober 2020, 09:25:41

Vorheriges Thema - Nächstes Thema

OdfFhem

@eurofinder

Ich habe in der Regel via Samba den gewünschten Serverpfad freigegeben und kann dann auf jedem geeigneten Endgerät editieren - quasi "lokal".

setstate

Zitat von: eurofinder am 24 Januar 2021, 14:39:34
Erst einmal danke für die tolle Weiterentwicklung zur Version 3.

Ich habe mal eine Frage, die nur am Rande etwas mit FTUI 3 selbst zu tun hat. Mich würde mal interessieren, wie ihr die Dateien editiert. Macht ihr das in dafür spezialisierte (Quelltext) Editoren (welche) und übertragt die Dateien dann auf den FHEM-Server oder macht ihr das direkt auf dem Server und ändert dort die Dateien direkt?

Vielleicht stelle ich mich einfach nur zu umständlich an. Meine Vorgehensweise ist derzeit direkt auf dem Server mit MC, finde das aber wenig komfortabel und suche nach Verbesserungspotential. Hat jemand einen Vorschlag für mich, wie ich das optimieren kann?

Gruß und schönes Restwochenende
eurofinder

Ich habe das FHEM Verzeichnis als Samba Share freigeben und dieses dann am Mac eingebunden (Finder > Go > connect to server). Im Visual Studio Code  editiert man somit die Files damit direkt. Beim Speichern sind sie sofort im FHEM aktualisiert. VS Code hat auch gute Plugins für ES Linter, Formatter usw.

RockFan

Hallo,

seit einigen Tagen versuche ich mich auch mit der neue FTUI Version. Echt sehr cool  8)

Auf meiner ersten ganz eifachen Oberfläche soll u.a. von meinem Internetradio der aktuelle Titel angezeigt werden.
Hier habe ich nun ein Problem mit der Aktualität der Anzeige. Das Device wirft genau ein Event, wenn der Titel wechselt. Auf der FTUI-Oberfläche tut sich meist erst einige Titel später wieder etwas. longpoll steht bei mir auf websocket und ich habe auch mal den Wert 1 versucht, was aber keinen Unterschied im Verhalten zeigt.

Ich habe mir das Ganze auch mal mit FTUI 2 angeschaut. Mir ist aufgefallen, dass der Titel dort auch erst nach einem automatischen "Full-Refresh" von FTUI erfolgt. Warum eigentlich?

Dann dachte mir, dass ich in FTUI 3 mal "interval" aus folgendem Post ausprobieren könnte:

Zitat von: setstate am 22 Januar 2021, 08:27:01

Edit: ist jetzt drin: interval="x" x in Sekunden


    <ftui-grid-tile row="4" col="1" height="1" width="1">
      <header>AUTO REFRESH</header>
      <ftui-label
          [text]="AussenTemp:temperature | toInt()"
          unit="°C">
      </ftui-label>
      <ftui-label
          [text]="AussenTemp:temperature:time | toDate() | ago() | timeFormat('mm:ss')"
          [color]="AussenTemp:temperature:time | toDate() | ago() | timeFormat('%MMMMMM') | map('0: blue, 4: warning, 5: alert')"
          unit="&hairsp;min"
          interval="10">
      </ftui-label>
    </ftui-grid-tile>


Wenn ich das mit dem Reading und dem Readinalter wie im Beispiel versuche, bekomme ich tatsächlich alle 10 Sekunden das Alter hochgezählt. Seltsamerweise wir dann auch das Alter weitergezählt, obwohl sich das Reading bereits auf den nächsten gespielten Titel des Radios umgestellt hat und das Reading einen neuen Zeitstempel erhalten hat. Die Anzeige des Titels bleibt auch alt.

interval ganz ohne Alter des Reading, sozusagen einfach nur mit der Textanzeige bewirkt auch keinerlei Änderung.
Hier mein kleiner Codeschnipsel:


          <ftui-label class="size-11" [text]="MedionRadioLAN:infoText" [hidden]="MedionRadioLAN:currentTitle | map('ROCK ANTENNE.*:true, .*:false')" interval="10"></ftui-label>
          <ftui-label class="size-11" [text]="MedionRadioLAN:infoText | part('(.*)gerade läuft:(.*)--- demnächst:.*')" [hidden]="MedionRadioLAN:currentTitle | map('ROCK ANTENNE.*:false, .*:true')" interval="10"></ftui-label>
          <ftui-label class="size-9" [text]="MedionRadioLAN:infoText | part('.*demnächst:(.*)')" [hidden]="MedionRadioLAN:currentTitle | map('ROCK ANTENNE.*:false, .*:true')" interval="10"></ftui-label>


Sollte interval nicht alle 10 Sekunden das Reading neu lesen oder verstehe ich hier etwas grundsätzlich falsch?

Viele Grüße
Dieter
Raspbian (Buster) auf Raspberry Pi 4 /  CUL + RFXTRX + TCM / FS20, FHT 80B, S300TH, Intertechno, DMX, Milight, EnOcean, Homematic, AMAD, Home Connect, MiSmartHome, Yeelight, ...

moonsorrox

@RockFan

das finde ich sehr interessant, würde ich doch glatt bei mir auch einbauen... da du den gleichen Sender hörst wie ich täglich  ;) :D
Intel-NUC i5: FHEM-Server 6.1 :: Perl v5.18.2

Homematic: HM-USB-CFG2,HM-CFG-LAN Adapter, HM-LC-BL1-FM, HM-LC-Sw1PBU-FM, HM-LC-Sw1-PI-2, HM-WDS10-TH-O, HM-CC-TC, HM-LC-SW2-FM

setstate

Mach doch mal im fhem den Eventviewer auf, ob überhaupt ein Event dazu vom device/Reading kommt.

RockFan

Zitat von: setstate am 24 Januar 2021, 15:14:47
Mach doch mal im fhem den Eventviewer auf, ob überhaupt ein Event dazu vom device/Reading kommt.

Ja, Events kommen. Aktuelles Beispiel:

2021-01-24 15:33:55 SIRD MedionRadioLAN infoText: Homepage: www.rockantenne.de --- demnächst: Brunhilde - Where Are You Going
2021-01-24 15:37:25 SIRD MedionRadioLAN infoText: Euer direkter Draht ins Studio: 08000 - 804000 --- demnächst: Bring Me The Horizon - Teardrops
2021-01-24 15:37:34 SIRD MedionRadioLAN infoText: gerade läuft: Bring Me The Horizon - Teardrops --- demnächst: Die Kassierer - Das Schlimmste Ist, Wenn Das Bier Alle Ist

Raspbian (Buster) auf Raspberry Pi 4 /  CUL + RFXTRX + TCM / FS20, FHT 80B, S300TH, Intertechno, DMX, Milight, EnOcean, Homematic, AMAD, Home Connect, MiSmartHome, Yeelight, ...

setstate

Zitat von: RockFan am 24 Januar 2021, 15:11:21
Sollte interval nicht alle 10 Sekunden das Reading neu lesen oder verstehe ich hier etwas grundsätzlich falsch?

Viele Grüße
Dieter

Nein, damit werden nur die lokal vorhanden Daten (value, timestamp) nochmal an die Komponenten geschickt, damit die Zeitdifferenz neu berechnet werden kann.  Neue Daten kommen nur per Websocket oder aller 15min per jsonlisr2 Aufruf. Ich würde in den Entwicklungertools des Browsers nachsehen, ob das Device/Reading mit in dem Websocketaufruf gelistet ist und ob websocktsevents reinkommen

eurofinder

@moonsorrox, grossmaggul, OdfFhem und setstate:
Danke für die Rückmeldungen. Ich werde mal die verschiedenen Varianten probieren, welche für mich am praktikabelsten ist - tendenziell favorisiere ich die Freigabe per NFS oder Samba. Das transferieren per ftp wollte ich ja umgehen:-)

Gruß und weiterhin frohes Schaffen. Man liest sich
eurofinder
RPI3+; Raspbian Buster Lite; RPI-RF-MOD; piVCCU3, HMIP-eTRV-2, HmIP-SWDO, HmIP-SRH, HmIP-STHO, HmIP-SLO

octek0815

#683
Zitat von: eurofinder am 24 Januar 2021, 14:39:34
Erst einmal danke für die tolle Weiterentwicklung zur Version 3.

Ich habe mal eine Frage, die nur am Rande etwas mit FTUI 3 selbst zu tun hat. Mich würde mal interessieren, wie ihr die Dateien editiert. Macht ihr das in dafür spezialisierte (Quelltext) Editoren (welche) und übertragt die Dateien dann auf den FHEM-Server oder macht ihr das direkt auf dem Server und ändert dort die Dateien direkt?

Vielleicht stelle ich mich einfach nur zu umständlich an. Meine Vorgehensweise ist derzeit direkt auf dem Server mit MC, finde das aber wenig komfortabel und suche nach Verbesserungspotential. Hat jemand einen Vorschlag für mich, wie ich das optimieren kann?

Gruß und schönes Restwochenende
eurofinder

Mit Filezilla via sftp und dann mit Notepad++ direkt Editieren.

RockFan

Zitat von: setstate am 24 Januar 2021, 16:04:32
Nein, damit werden nur die lokal vorhanden Daten (value, timestamp) nochmal an die Komponenten geschickt, damit die Zeitdifferenz neu berechnet werden kann.  Neue Daten kommen nur per Websocket oder aller 15min per jsonlisr2 Aufruf. Ich würde in den Entwicklungertools des Browsers nachsehen, ob das Device/Reading mit in dem Websocketaufruf gelistet ist und ob websocktsevents reinkommen

Verstehe die Aussage bzgl interval!

Mit Browserentwicklertools bin ich jetzt nicht so fit. Das Verhalten ist auf allen Browsern (Firefox, Chrome auf meinem PC und Fully auf dem Tablet) identisch.

Meinst du sowas:


ftui.helper.js:101 websockets URL=wss://raspberrypi4:8083/fhem/?XHR=1&inform=type=status;filter=gt_Temperatur,Buderus,Lifetab_klein_alt,MedionRadioLAN,Winamp, temperature OutdoorTemp batteryPercent currentTitle infoText CurrentTitle state powerPlugged;since=1611501919873;fmt=JSON&timestamp=1611502091815

...

fhem.service.js:243 WebSocket connection to 'wss://raspberrypi4:8083/fhem/?XHR=1&inform=type=status;filter=gt_Temperatur,Buderus,Lifetab_klein_alt,MedionRadioLAN,Winamp,%20temperature%20OutdoorTemp%20batteryPercent%20currentTitle%20infoText%20CurrentTitle%20state%20powerPlugged;since=1611501919873;fmt=JSON&timestamp=1611502091815' failed: Invalid frame header
connect @ fhem.service.js:243
(anonymous) @ fhem.service.js:288
ftui.helper.js:101 Error with fhem connection
ftui.helper.js:101 websocket (url=wss://raspberrypi4:8083/fhem/?XHR=1&inform=type=status;filter=gt_Temperatur,Buderus,Lifetab_klein_alt,MedionRadioLAN,Winamp,%20temperature%20OutdoorTemp%20batteryPercent%20currentTitle%20infoText%20CurrentTitle%20state%20powerPlugged;since=1611501919873;fmt=JSON&timestamp=1611502091815) closed!  reason=The connection was closed abnormally, e.g., without sending or receiving a Close control frame

...

ftui.helper.js:101 websockets URL=wss://raspberrypi4:8083/fhem/?XHR=1&inform=type=status;filter=gt_Temperatur,Buderus,Lifetab_klein_alt,MedionRadioLAN,Winamp, temperature OutdoorTemp batteryPercent currentTitle infoText CurrentTitle state powerPlugged;since=1611502091925;fmt=JSON&timestamp=1611502277965
ftui.helper.js:101 ftui-clock-1 -  attributeChangedCallback name=text, oldValue=16:31:17, newValue=16:31:18
​ FhemService.updateReadingItem - update for  MedionRadioLAN-infoText newData= undefined doPublish= true
​ FhemService.updateReadingItem - update for  MedionRadioLAN-infoText newData= undefined doPublish= true
​ FhemService.updateReadingItem - update for  MedionRadioLAN-infoText newData= undefined doPublish= true
​ ftui-clock-1 -  attributeChangedCallback name=text, oldValue=16:31:18, newValue=16:31:19
​ WebSocket connection to 'wss://raspberrypi4:8083/fhem/?XHR=1&inform=type=status;filter=gt_Temperatur,Buderus,Lifetab_klein_alt,MedionRadioLAN,Winamp,%20temperature%20OutdoorTemp%20batteryPercent%20currentTitle%20infoText%20CurrentTitle%20state%20powerPlugged;since=1611502091925;fmt=JSON&timestamp=1611502277965' failed: Invalid frame header
connect @ ​
(anonymous) @ ​
​ Error with fhem connection
​ websocket (url=wss://raspberrypi4:8083/fhem/?XHR=1&inform=type=status;filter=gt_Temperatur,Buderus,Lifetab_klein_alt,MedionRadioLAN,Winamp,%20temperature%20OutdoorTemp%20batteryPercent%20currentTitle%20infoText%20CurrentTitle%20state%20powerPlugged;since=1611502091925;fmt=JSON&timestamp=1611502277965) closed!  reason=The connection was closed abnormally, e.g., without sending or receiving a Close control frame


Mir fällt hier immer wieder "Error with fhem connection" auf.
Raspbian (Buster) auf Raspberry Pi 4 /  CUL + RFXTRX + TCM / FS20, FHT 80B, S300TH, Intertechno, DMX, Milight, EnOcean, Homematic, AMAD, Home Connect, MiSmartHome, Yeelight, ...

OdfFhem

#685
@setstate

Tests in den letzten Tagen haben einige Anregungen/Ungereimtheiten zu Tage gefördert:

***

In ftui.css fehlt der Klasse faded ein Punkt ... "faded {" sollte zu ".faded {" werden.

***

Ich nutze gerne das img-Tag - unter FTUI3 würde ich natürlich lieber ftui-image und seine aktuellen/zukünftigen Möglichkeiten verwenden. Das Aufgeben der Komponenten-css-Datei hat aber dazu geführt, dass scheinbar keinerlei Definitionen mehr aus der eigenen css-Datei bzw. ftui.css angewendet werden können (ein Beispiel wäre .faded). Nimmt man das style-Tag aus der js-Datei der Komponente heraus, funktioniert es wieder - ist dies ein gewolltes Verhalten?

Bei Type- bzw. Attribut-Selektoren bzgl. des innerhalb der Komponente verwendeten img-Tags hat man scheinbar wenig bis gar keine Chance; bei grid-tile z.B. funktioniert dies aber aktuell problemlos ... ??? ...

***

Grundsätzlich scheint das popup-Target ja quasi überall eingesetzt werden zu können, allerdings fehlt bei fast allen Einsatzfällen die pointer-Optik. Wäre es ein Problem, die zugehörige Klasse allgemein bereitzustellen?

***

Wäre es möglich, für die genaue/gewünschte Positionierung eines Popups das top- sowie left-Attribut verfügbar zu machen?

***

Die angebotenen Formen via shape sind schön und ich nutze diese gerne.

Bei der popup-Komponente würde ich - zumindest teilweise - auch gerne die circle-Form verwenden. Anpassen der Komponenten-Datei führt direkt zum Ziel, eigene css-Erweiterungen leider nicht. Könnte diese Form für die popup-Komponente nachgerüstet werden? (header und close können meiner Meinung nach für diese "Spezial"-Form ignoriert werden)

Neben den vorhandenen Formen habe ich auch weitere Formen in meiner eigenen css-Datei ergänzt. Diese können z.B. für die grid-tile-Tags ohne weitere Eingriffe verwendet werden - sehr praktisch.
Es handelt sich dabei um den kreisförmigen grid-tile und um die grid-tile-"Zungen", deren Ankerpunkt eckiges Aussehen hat und in der Rundform endet (s. Testbild mit konstruiertem Beispiel). Die "Zungen" werden fast ausschließlich am äußeren Rand genutzt und stellen am Ankerpunkt quasi einen Titel bereit. Ich bin mir nicht sicher, ob eigene css-Definitionen langfristig überleben können - qualifizieren sich solche Formen für den allgemeinen Einsatz?

***

Das interval-Attribut bzgl. ftui-label setze ich bei allen fraglichen Readings ein. Bei der "Langzeitbeobachtung" ist aufgefallen, dass beim Eintreffen neuer Daten das Intervall nicht zurückgesetzt wird - das alte, angefangene Intervall läuft einfach weiter. Ist jetzt nicht dramatisch, aber die Aussagekraft leidet doch ein wenig.

Beträgt das Intervall z.B. 1 Stunde, dann wird jede Stunde geprüft. Die Oberfläche wird gestartet und das Intervall beginnt quasi mit dem Eintreffen der ersten Daten. Neue Daten kommen zufällig nach z.B. 15 Minuten, dann wird die erste Überschreitung des Stundenintervalls erst nach 1,75 Stunden festgestellt.

Daher wäre ein reset schön, aber ob (so einfach) machbar? Alternativlösung wäre vermutlich ansonsten eine deutliche Verkürzung des Intervalls.

***

setstate

Zitat von: OdfFhem am 24 Januar 2021, 17:28:41
@setstate

Tests in den letzten Tagen haben einige Anregungen/Ungereimtheiten zu Tage gefördert:

***

In ftui.css fehlt der Klasse faded ein Punkt ... "faded {" sollte zu ".faded {" werden.

--> fixed
***

Ich nutze gerne das img-Tag - unter FTUI3 würde ich natürlich lieber ftui-image und seine aktuellen/zukünftigen Möglichkeiten verwenden. Das Aufgeben der Komponenten-css-Datei hat aber dazu geführt, dass scheinbar keinerlei Definitionen mehr aus der eigenen css-Datei bzw. ftui.css angewendet werden können (ein Beispiel wäre .faded). Nimmt man das style-Tag aus der js-Datei der Komponente heraus, funktioniert es wieder - ist dies ein gewolltes Verhalten?

Bei Type- bzw. Attribut-Selektoren bzgl. des innerhalb der Komponente verwendeten img-Tags hat man scheinbar wenig bis gar keine Chance; bei grid-tile z.B. funktioniert dies aber aktuell problemlos ... ??? ...

--> fixed
***

Grundsätzlich scheint das popup-Target ja quasi überall eingesetzt werden zu können, allerdings fehlt bei fast allen Einsatzfällen die pointer-Optik. Wäre es ein Problem, die zugehörige Klasse allgemein bereitzustellen?

--> fixed
***

Wäre es möglich, für die genaue/gewünschte Positionierung eines Popups das top- sowie left-Attribut verfügbar zu machen?

--> done
***

Die angebotenen Formen via shape sind schön und ich nutze diese gerne.

Bei der popup-Komponente würde ich - zumindest teilweise - auch gerne die circle-Form verwenden. Anpassen der Komponenten-Datei führt direkt zum Ziel, eigene css-Erweiterungen leider nicht. Könnte diese Form für die popup-Komponente nachgerüstet werden? (header und close können meiner Meinung nach für diese "Spezial"-Form ignoriert werden)

Neben den vorhandenen Formen habe ich auch weitere Formen in meiner eigenen css-Datei ergänzt. Diese können z.B. für die grid-tile-Tags ohne weitere Eingriffe verwendet werden - sehr praktisch.
Es handelt sich dabei um den kreisförmigen grid-tile und um die grid-tile-"Zungen", deren Ankerpunkt eckiges Aussehen hat und in der Rundform endet (s. Testbild mit konstruiertem Beispiel). Die "Zungen" werden fast ausschließlich am äußeren Rand genutzt und stellen am Ankerpunkt quasi einen Titel bereit. Ich bin mir nicht sicher, ob eigene css-Definitionen langfristig überleben können - qualifizieren sich solche Formen für den allgemeinen Einsatz?

--> schaue ich mir noch an
***

Das interval-Attribut bzgl. ftui-label setze ich bei allen fraglichen Readings ein. Bei der "Langzeitbeobachtung" ist aufgefallen, dass beim Eintreffen neuer Daten das Intervall nicht zurückgesetzt wird - das alte, angefangene Intervall läuft einfach weiter. Ist jetzt nicht dramatisch, aber die Aussagekraft leidet doch ein wenig.

Beträgt das Intervall z.B. 1 Stunde, dann wird jede Stunde geprüft. Die Oberfläche wird gestartet und das Intervall beginnt quasi mit dem Eintreffen der ersten Daten. Neue Daten kommen zufällig nach z.B. 15 Minuten, dann wird die erste Überschreitung des Stundenintervalls erst nach 1,75 Stunden festgestellt.

Daher wäre ein reset schön, aber ob (so einfach) machbar? Alternativlösung wäre vermutlich ansonsten eine deutliche Verkürzung des Intervalls.

--> fixed
***

octek0815

Zitat von: octek0815 am 24 Januar 2021, 11:49:01
Ursprünglich wollte ich das mit <ftui-image> lösen, aber da ich in meine Konfig. alles auf % Angaben umgestellt habe (für unterschiedliche Screengrößen) und <ftui-image> damit nicht umgehen kann, habe

Mit dem neuen Update von setstate ist das nun obsolet, da nun auch style Angaben mit <ftui-image> funktionieren und diese mit interval nur aktualisiert werden, wenn im sichtbaren Bereich.

@setsate: Danke hierfür!

torte

Hallo,

ich hab noch ein Problem mit <ftui-content> wie kann man es schaffen das ftui-content keinen Platz verbraucht wenn das eingeladene Element hidden ist?
Ich könnte das hidden auch an <ftui-content> hängen aber dann muss ich es doppelt machen, oder gibt es dort einen Trick?
Danke

Grüße
Torte


yersinia

#689
Zitat von: eurofinder am 24 Januar 2021, 14:39:34Mich würde mal interessieren, wie ihr die Dateien editiert.
vim direkt in der shell. ;D

Zitat von: moonsorrox am 24 Januar 2021, 14:41:47Es ist auch nicht möglich den button mit align-items="center" in die Mitte zu bekommen. Muss ich etwas beachten oder ist das ein Formatierungsfehler.?
Wo setzt du das align-items? align-items wirkt sich auf die Kinder aus. Eventuell hilft es, sich das mal per CSS Inspektor anzusehen.

Zitat von: torte am 25 Januar 2021, 10:11:05Ich könnte das hidden auch an <ftui-content> hängen aber dann muss ich es doppelt machen, oder gibt es dort einen Trick?
Wieso doppelt? Vererbt sich das hidden nicht auf die Kindelemente?
viele Grüße, yersinia
----
FHEM 6.3 (SVN) on RPi 4B with RasPi OS Bullseye (perl 5.32.1) | FTUI
nanoCUL->2x868(1x ser2net)@tsculfw, 1x433@Sduino | MQTT2 | Tasmota | ESPEasy
VCCU->14xSEC-SCo, 7xCC-RT-DN, 5xLC-Bl1PBU-FM, 3xTC-IT-WM-W-EU, 1xPB-2-WM55, 1xLC-Sw1PBU-FM, 1xES-PMSw1-Pl