Hauptmenü

FTUI version 3

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

Vorheriges Thema - Nächstes Thema

yersinia

Zitat von: muma am 03 Mai 2022, 11:38:14Kann es sein, dass hierbei generell nur Pfade und keine Objekte aus dem SVG gefärbt werden
und bei den Pfaden generell nur der Innenbereichen und nicht die Kontur?
Ja, denn so liest sich das CSS afaik:
svg {
  width: var(--icon-width, 2.5em);
  height: var(--icon-height, 2.5em);
  fill: currentColor;
}

svg g[fill],
svg g [fill]  {
  fill: inherit;
}

svg path[style],
svg g[style] {
  fill: inherit !important;
}

<svg> bekommt die Eigenschaft fill: currentColor zugewiesen
<svg> <g fill="..."> sowie <svg> <g> <... fill="..."> bekommen fill: inherit
<svg> <path style="..."> sowie <svg> <g style="..."> bekommen fill: inherit !important
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

mr_petz

#2431
Zitat von: muma am 03 Mai 2022, 11:38:14
...
und bei den Pfaden generell nur der Innenbereichen und nicht die Kontur?

Wenn du eine Kontur/Border von svg-Icons färben willst, dann kannst du es mit stroke so in einer user.css oder als Styleattribute definieren.
Bsp.:

ftui-icon {
  stroke-width: 0.5px;
  stroke: red;
  --color-base: green;
}


Das Ergebnis ist wie im Anhang zu sehen.
Es funktioniert mit den meisten Icons aus FTUI3. (In meinem Test wurden die neuen bas-icons nicht mit eingefärbt. Die restlichen weather-icons schon.)

Edit: getestet unter Chrome und FF
so wäre auch ein transparentes Icon mit Kontur möglich:

ftui-icon {
  stroke-width: 0.5px;
  stroke: red;
  --color-base: transparent;
}

Man könnte auch den style des stroke verändern mit einem binding zBsp.:

[style]="dummy | map('yellow:`stroke:yellow`, red:`stroke:red`')"


Edit2: Auch sowas wie im vorletzten Bild wäre mit stroke-dasharray möglich:

  stroke-width: 0.5px;
  stroke: red;
  stroke-dasharray: 1;
  --color-base: transparent;


Edit3: Einen hab ich noch mit 3D Effekt oder halt mit nicht so einen statischen Aussehen...:

  stroke-width: 0.5px;
  stroke: black;
  stroke-opacity: 0.5;
  filter: drop-shadow(2px 2px 1px black);
  --color-base: var(--dark-light);

Die filter Angabe geht mit allen icons und elementen in ftui3...

LG mr_petz

presskopf

Ich habe da mal wieder ein Phänomen. Dabei meine ich, es schon mal gesehen zu haben (hier im Forum), aber ich finde es nicht

Wenn ich mir aus einem Device Unwetterzentrale (UWZ) das Reading "Warn_0_Start" hole und mit todate() konvertiere, dann ist das Ergebnis zwei Stunden zeitversetzt, nämlich die GMT-Zeit.
z.B.:
<ftui-label [text]="UWZ_Ergolding:Warn_0_Start | toDate() | format('DD.MM.YY - hh:mm')"></label>
1652677200 wird zu 16.05.22 - 05:00
Ich hätte aber lieber meine lokale Zeit. Wie bringe ich das dem ftui3 bei?


mr_petz

#2433
Hi presskopf.
In FTUI3 ist die OffsetTime aus einer Unix/GMT-time nicht berücksichtigt:
https://github.com/knowthelist/ftui/blob/master/www/ftui/modules/ftui/ftui.helper.js#L220

Du könntest als Übergangslösung folgendes machen.
Entweder:

<ftui-label [text]="UWZ_Ergolding:Warn_0_Start | add(7200) | prepend(0) | toDate() | format('DD.MM.YY - hh:mm')"></ftui-label>

Oder:

<ftui-label [text]="UWZ_Ergolding:Warn_0_Start | toDate() | o=>o.getTimezoneOffset()*60-text | slice(1) | prepend(0) | toDate() | format('DD.MM.YY - hh:mm')"></ftui-label>

Oder:

<ftui-label [text]="UWZ_Ergolding:Warn_0_Start | toDate() | o=>o.getTimezoneOffset() | slice(1) | o=>o*60+text*1 | prepend(0) | toDate() | format('DD.MM.YY - hh:mm')"></ftui-label>

Beim ersten musst du in der Winterzeit die 7200 in 3600 ändern.
Beim zweiten und dritten läuft alles automatisch.
Das prepent(0) musste ich setzen, da sonst die letzte Null/Zahl nicht übergeben/einbezogen wurde in meiner Testumgebung, ansonsten wurde mir der rote Rahmen angezeigt.
Hier mein Test:

<ftui-button (value)="Device" states="1652677200,1652680800">
<ftui-label [text]="Device | add(7200) | prepend(0) | toDate() | format('DD.MM.YY - hh:mm')"></ftui-label>
<ftui-label [text]="Device | toDate() | o=>o.getTimezoneOffset()*60-text | slice(1) | prepend(0) | toDate() | format('DD.MM.YY - hh:mm')"></ftui-label>
<ftui-label [text]="Device | toDate() | o=>o.getTimezoneOffset() | slice(1) | o=>o*60+text*1 | prepend(0) | toDate() | format('DD.MM.YY - hh:mm')"></ftui-label></ftui-button>

Wenn es bei dir auch ohne geht, dann nimm es wieder raus.

Mich würde auch interessieren wie es noch geht. Ich habe dazu jetzt auf die schnelle auch nichts gefunden...

Edit: nur unter ftui-clock kann man einen offset mit angeben...
oder du biegst das schon unter Fhem gerade...

Edit2: Hinweis:
Ich habe gerade mal auf:
https://feed.alertspro.meteogroup.com/AlertsPro/AlertsProPollService.php?method=getWarning&language=de&areaID=UWZDE46483
getestet. Da werden aber die UnixZeiten in Sommer(DE)zeit angegeben laut:
https://www.unwetterzentrale.de/uwz/getwarning_de.php?plz=46483&uwz=UWZ-DE&land=DE
"dtgStart":1652875200 = 19.05.2022 - 13:00
"dtgEnd":1652994000 = 19.05.2022 - 23:00

auch der Zeitstempel der letzten Aktualisierung passt:
"creation":1652898735 = 18.05.2022 - 20:32

Woher oder was ist das für eine UWZ-Zeit?

Edit3: In Fhem auch nochmal die Zeitzone prüfen für DWD
Zitat
3. FHEM Uhrzeit und Zeitzone: Durch Eingabe von

{localtime()}

in die FHEM-Kommandozeile überprüfen, ob die FHEM-Uhrzeit plausibel ist. Ist dies nicht der Fall sollten die Uhrzeit auf Systemebene überprüft werden und ggf. die Systemeinstellungen angepasst werden. Ermitteln der Bezeichnung der eigenen Zeitzone über die System-Kommandozeile mit

  tzselect

und diese Bezeichnung in die Datei /etc/timezone eintragen und

export TZ=`cat /etc/timezone`

der Datei /etc/profile hinzufügen und dann das System neu starten. Nun muss die Zeitanzeige in FHEM korrekt sein.
Quelle: https://wiki.fhem.de/wiki/DWD_OpenData#Vorbereitung


LG mr_petz

yersinia

@mr_pez: UWZ != DWD - aber der Zeitzonenhinweis ist ein guter Punkt

@presskopf: warum setzt du nicht das Attribut
Zitathumanreadable
Anzeige weiterer Readings Warn_?_Start_Date, Warn_?_Start_Time, Warn_?_End_Date, Warn_?_End_Time. Diese Readings enthalten aus dem Timestamp kalkulierte Datums/Zeit Angaben. Weiterhin werden folgende Readings aktivier: Warn_?_Type_Str und Warn_?_uwzLevel_Str welche den Unwettertyp als auch das Unwetter-Warn-Level als Text ausgeben. (0|1)
commandref: UWZ
und nutzt dann die Readings:
READINGS:
     2022-05-19 07:53:53   Warn_0_End      1652994000
     2022-05-19 07:53:53   Warn_0_End_Date 19.05.2022
     2022-05-19 07:53:53   Warn_0_End_Time 23:00
     2022-05-19 07:53:53   Warn_0_Start    1652958000
     2022-05-19 07:53:53   Warn_0_Start_Date 19.05.2022
     2022-05-19 07:53:53   Warn_0_Start_Time 13:00

entsprechend in FTUI?
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

presskopf

@mr_petz
@yersina

Danke an Euch zwei.
Da habe ich wieder was gelernt. :)

Beim der nächsten UW-Meldung schaue ich mir Eure Lösungen an.

caldir65

Hallo,

ich weiß nicht, ob es schon einmal gefragt wurde - aber ich muß zugeben, bei über 160 Seiten habe ich nicht groß Lust, alles zu lesen, und die Sufu hat leider auch nichts ergeben ...

Kann ich beide FTUI-Versionen zu entwicklungszwecken auch nebeneinander betreiben, so daß z.B. die FTUI2-Oberfläche bis auf Weiteres auf dem Produktiv-Tablet angezeigt wird, während ich auf einem anderen Tablet mit FTUI3 experimentiere?

Gruß, Christoph
Alte Techniker-Regel: "kaum macht man es richtig, funktioniert es auch"
------
Dell Wyse5070 ThinClient 16GBRam, 64GB SSD, Lubuntu 22.04LTS, fhem (aktuell), debmatic, Homematic-Devs, ConBee II und deConz, viele Shellys, Rademacher, NextCloud-Anbindung, FullyKioskBrowser+FUIP uvm.

yersinia

Ja, das geht.
Du könntest sogar auf dem gleichen Tablet (aka Endgerät zur Anzeige) arbeiten.
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

caldir65

Danke, ist entsprechend eingerichtet ...

Gruß, Christoph
Alte Techniker-Regel: "kaum macht man es richtig, funktioniert es auch"
------
Dell Wyse5070 ThinClient 16GBRam, 64GB SSD, Lubuntu 22.04LTS, fhem (aktuell), debmatic, Homematic-Devs, ConBee II und deConz, viele Shellys, Rademacher, NextCloud-Anbindung, FullyKioskBrowser+FUIP uvm.

curt

Ende Februar hatte ich aus beruflichen Gründen meine Umstellung auf FTUI3 eingestellt, seit vorgestern arbeite ich mich wieder ran. Seht mir bitte nach, dass ich auf Anfängerniveau zurückfiel.

Vermutlich ein Update (oder meine Dummheit irgendwann im Februar, keine Ahnung) hat mein Tab-Design verändert. Konket hatten die Kästchenumrandungen eine andere Farbe als der Hintergrund der Kästchen - damit das schön abgesetzt ist - wie bei den Beispielen von @setstate. Aktuell ist das bei mir nun alles einheitlich tiefschwarz - warum auch immer. Ich sehe also keine Abgrenzung dieser Kästchen.

Nun gibt es ja drei Möglichkeiten: Umrandungsfarbe geändert. Globale Hintergrundfarbe geändert. Breite der Kästchenumrandung ist auf 0.

Mal angenommen, ich will die globale Hintergrundfarbe auf blau ändern - wo mache ich das mit welchem Parameter? Und falls ich die Umrandungsfarbe auf -sagen wir rot- ändern will, wo mache ich das? Und spasseshalber die Umrandung auf 10px, wo und mit welcher Variable?

Oder denke ich komplett falsch?
RPI 4 - Jeelink HomeMatic Z-Wave

Konfusius

Noch eine Anfängerfrage dazwischen gehauen:
ich habe mir eine kleine Oberfläche mit 6 Tabs fürs Handy gebastelt.
Wenn ich die Aufrufe, sehe ich links die Tabs, aber die Seite hat nur die Hintergrundfarbe.
Ich muss immer erst einen Tab antippen, damit ich den Inhalt sehe.

Geht das nicht auch so, dass ein Tab automatisch beim Aufrufen der Seite angezeigt wird?


mr_petz

Du musst einen mit Attribute active auf aktiv setzen.
LG

Konfusius

Danke, so einfach isses....

curt

Zitat von: curt am 28 Mai 2022, 03:42:18
Nun gibt es ja drei Möglichkeiten: Umrandungsfarbe geändert.

Ok, die Vordergrundfarbe der Kästchen wird in ftui-grid-tile definiert. Aus

<ftui-grid-tile row="1" col="1" height="5" width="1" color="black">


machte ich

<ftui-grid-tile row="1" col="1" height="5" width="1" color="my_grey3">

Dabei definierte ich my_grey3 in user.css nach meinen Wünschen.

Zitat von: curt am 28 Mai 2022, 03:42:18
Globale Hintergrundfarbe geändert.
Wie ich die globale Hintergrundfarbe (damit die Farbe der Kästchenumrandung) ändere, habe ich leider noch nicht verstanden.
RPI 4 - Jeelink HomeMatic Z-Wave

Konfusius

#2444
Ich brauch noch mal Hilfe.
Ich habe 3 LED Stripes im Einsatz. Alle Wemos D1 Mini mit Tasmota 11. Einer ist RGB als "ARILUX LC01" und die beiden anderen RGBW als "GENERIC TASMOTA" konfiguriert.
Alle 3 kann ich mit der FTUI3 steuern, aber nur der RGB zeigt beim Aufruf des FTUI3 die richtigen Werte an.
Die RGBWs stehen immer ColorWheel Mitte und Slider  Rechtsanschlag.

Auf Seite 79 des Threads las ich:
ZitatWheel- bzw. Slider-Darstellung ist korrekt - Toasts mit Information zu setreading werden aufgeblendet.
iro.js kann hex-Werte verarbeiten, die dem Muster RGB RGBA RRGGBB oder RRGGBBAA entsprechen - mit oder ohne führendem # bzw. 0x.

Ich dachte es liegt am Format des "Color" Wertes: RGB=FFFFFF  und RGBW=FFFFFFFF.
Nach der Aussage sollte das aber nicht sein, oder?

Hier mal die beiden Code Schnipsel, beide identisch:
   
   
     <ftui-label size="6"  color="orange" >Licht1</ftui-label>
           <ftui-colorpicker [hex]="RGB_Stripe:Color" (hex)="replace('#','') | RGB_Stripe:Color"
                          layout="wheel,valueSlider"></ftui-colorpicker>
     
            <ftui-switch [(value)]="RGB_Stripe" texts='I,O'></ftui-switch>     
     
     <ftui-label size="6"  color="orange" >Licht2</ftui-label>
<ftui-colorpicker [hex]=RGBW_Stripe:Color" (hex)="replace('#','') | RGBW_Stripe:Color"
                          layout="wheel,valueSlider"></ftui-colorpicker>
     
                             <ftui-switch [(value)]="RGBW_Stripe" texts='I,O'></ftui-switch>     
     


Wie gesagt steuern geht problemlos, "Color" wie auch "pct" Werte werden ordnungsgemäß vom FTUI3 an FHEM und weiter an Tasmota übermittelt und ausgeführt.
Nur beim Einstieg in die FTUI3 Seite, zeigen die beiden RGBW Stripes Müll an, der RGB alles korrekt.

Lösungsvorschläge die ich hier im Thread fand und probierte lösten mein Problemchen bislang nicht.
Ich habe aber auch noch nicht alle 163 Seiten durch...

EDIT1:
Das liegt doch am Hex Format des RGBW. Ich habe ein UserReading in FHEM erstellt (rgb {(substr(ReadingsVal($name,"Color",0),0,6))})
welches mir die beiden letzten Stellen vom HEX Wert abschneidet und schon zeigt das ColorWheel und der Slider alles richtig an.   (also aus DBFFF3FF  DBFFF3 macht,)

Im FTUI3 noch
<ftui-colorpicker [hex]=RGBW_Stripe:rgb" (hex)="replace('#','') | RGBW_Stripe:Color"
geändert.

Kann ich an den gesendeten Color Wert noch "FF" anhängen lassen, damit mir mein Weiß Wert nicht immer auf 0 gesetzt wird. Der soll immer FF bleiben.
Das ColorWheel sendet mir den Color Wert nur 6 stellig. Der "W" Wert fehlt, weshalb er wohl mit "00" von Tasmota interpretiert wird?