FTUI version 3

[rob]

Vielen Dank fürs Testen. Dann verstehe ich es noch weniger, warum es bei mir nicht geht. Ja, mit einem Dummy schon. Mit den echten Devices (habe zwei davon) bei mir leider nicht, trotz korrektem RGB-Wert im Userreading.

Ich habe es in einem frischen Fhem-Docker, per autocreate neu erstellten MQTT-Device + frisches FTUI3 in diesem Container nochmals nachgestellt (nicht das auf dem produktiven etwas vermurkst ist). Ist das selbe.
Fhem und FTUI arbeiten ja mit RGB und setzen das auch so ins Reading Color. Dann wird das Commando an Tasmota ausgelöst und dieses reportet die Farbe zurück - nur halt hinten mit 00 dran. Setzen in Fhem und Feedback durch Tasmota laufen so schnell ab, dass es wirkt, als würde Fhems-Colorpicker-Widget schon die Nullen dran hängen. Macht es aber nicht, das kommt von Tasmota.

Baue ich das in einem Dummy 1:1 nach passt alles. Denn weder Fhem noch FTUI hängen hinten die Null ran. Sogar wenn ich extra ein "setreading dummy color FF00FF00" mache, zieht mein Userreading und im FTUI ist alles super. Nur eben nicht im Zusammenspiel mit Tasmota.

Ich gebe es auf. Tasmota-RGBW und FTUI gehen nicht so einfach zusammen. Dann bleiben die Toasts halt deaktiviert und gut.

Anmerken kann man noch, dass bei "heftigem" Nutzen irgendwann die Kontrolle verloren geht; das Wheel stellt Wertänderungen durch Mausklick, o.ä. korrekt dar, aber es werden keine Werte mehr an FHEM geschickt - evtl. mit debounce lösbar.

Ja, hatte ich beim Testing gemerkt. Störte mich aber nicht weiter. Für neue Tests hatte ich eh die Seite neu geladen.

VG
rob

[Sailor]

Hi Odf

Das Attribut pointRadius folgt in der für Javascript verbreiteten Schreibweise dem "camel case"-Prinzip.
Eigentlich alles Kleinbuchstaben; nur ab dem 2.Wort ist der erste Buchstabe eines Wortes ein Großbuchstabe.

Bei HTML kennt man eher das "kebab case"-Prinzip.
Alles Kleinbuchstaben; Worte werden durch "-" getrennt.

Himmel, da soll mal einer drauf kommen!

Danke, hast mir sehr geholfen!
Ich werde da mal etwas tiefer einsteigen...

Gruß
    Sailor

[OdfFhem]

@rob

Angenommen, Du hast doch noch Lust, den Fehler greifbarer zu machen:
- in der colorpicker-Komponente von iro.min.js auf iro.js umschwenken
- in iro.js die Meldung "('Invalid hex string')" auf "('Invalid hex string' + value)" erweitern, so dass man sieht, was das Problem sein soll

[rob]

Angenommen, Du hast doch noch Lust, den Fehler greifbarer zu machen:

Klaro. Vielen Dank für Deine Geduld.

Hab alles angepasst. Erster Toast

Code Auswählen Erweitern


set MQTT2_RGBW02 Color 00c8ff

und zweiter Toast

Code Auswählen Erweitern


iro.js:582
Error: Invalid hex string#set

Aha! Da kommt gar kein hex an.
Erklärt warum kein Replace usw. wirkte. Tatsächlich steht im Color für 1/2sec "set" und wechselt dann zum Hex-Wert. Fhem ist flink genug, dass dies auch im UserReading so ist.

Das scheint mit der Wirkweise der MQTT-Kommunikation zu tun haben. Schalte ich vom Tasmota-Webif kommt keine Fehlermeldung. Wert "set" steht von Fhem aus drin bis Tasmota geantwortet hat. Nehme ich Tasmota offline, bleibt generell set drin.

Ich müsste also eine Art Verzögerung einbauen (z.B. ins UserReading?). Dann sollte es doch hoffentlich klappen, dass auch der hex-Wert ankommt. Ein kallhartes sleep bringt jedenfalls nix, weil Fhem dann komplett wartet - also auch set zunächst angehalten wird.

Heißt vielleicht auch: Thema betrifft nicht unbedingt RGBW, sondern auch RGB-Teile die MQTT mit Tasmota machen (?).

Vielen Dank und beste Grüße
rob

[mr_petz]

Hi. Kannst auch erstmal mit

Code Auswählen Erweitern


debounce="1000"

oder höher auf der ftui seite testen...
Ist in ms

[OdfFhem]

@rob

Bzgl. Wert vom UserReading würde es vermutlich reichen, einen neuen Tasmota-Wert nur zu übernehmen, wenn die "Quelle" eine gültige Hexzahl zur Verfügung stellt - ansonsten behält man den veralteten, aber noch fehlerfrei darstellbaren Wert.

Ist aber nur eine Idee ...

[rallye]

Guten Morgen,

leider habe ich über mein Anliegen hier im Forum nichts gehört/gelesen. Erleide ich hier ein Einzelschicksal ? Ich kann nur sagen, dass nach mehreren (unterschiedlich oft) refresh des Bildschirms die entsprechenden Icons auftauchen.

Danke für eure Unterstützung

Guten Morgen !

Ich verwende seit mehreren Wochen problemlos "kleinklima". Seit 1-2 Tagen jedoch werden die Icons nur manchmal (kann leider kein Pattern feststellen) angezeigt. Ist da irgendetwas geändert worden was ich beachten muss ?

Danke

[Eisix]

Hallo ralley,

kann bestätigen das ich dieses Problem auch habe.

Gruß
Eisix

[torte]

Hallo Ralley, Eisix,

bei mir ist das auch so, nachvollziehen kann ich das am besten wenn ich über eine FHEMWEB Instanz gehe die OHNE BasicAuth läuft.
Evtl. tritt das Problem bei den anderen ja nicht auf weil sie über einen separaten WEBServer arbeiten hatte aber noch keine Zeit
das mal auszuprobieren.

Grüße
Torte

[rob]

@mr_petz

Code Auswählen Erweitern


debounce="1000"


Danke Dir. Hab ich direkt ausprobiert. Ich muss jedoch zugeben, dass ich keinen Hinweis in den Dokus fand, wie / wo das konkret hin muss. So habe ich es probiert, brachte erstmal keinen Unterschied = meine Anwendung wird falsch sein:

Code Auswählen Erweitern


<ftui-colorpicker [hex]="MQTT2_RGBW02:myRGB" (hex)="replace('#','') | MQTT2_RGBW02:Color" debounce="1000"></ftui-colorpicker>


@OdfFhem

Bzgl. Wert vom UserReading würde es vermutlich reichen, einen neuen Tasmota-Wert nur zu übernehmen, wenn die "Quelle" eine gültige Hexzahl zur Verfügung stellt - ansonsten behält man den veralteten, aber noch fehlerfrei darstellbaren Wert.

Ist aber nur eine Idee ...

Ja, gute Idee. Und das klappt auch. Durch den Wechsel "hoppst" das im Widget kurz, macht aber nix. Keine Fehlermeldung (no red Toast ). Alternativ geht auch ersetzen via replace('set','FFFFFF') - dadurch hoppst er nur zur Mitte (weiß) und dann zur Farbe.
Weiter vertiefen muss ich das hier nicht, da die Ursache, nicht im FTUI liegt und es somit nicht (mehr) in den Fred passen würde.

Eines habe ich in dem Zusammenhang noch beobachtet: wahrscheinlich durch die schnellen Inhaltswechsel im Reading greift das genannte Phänomen:

...dass bei "heftigem" Nutzen irgendwann die Kontrolle verloren geht; das Wheel stellt Wertänderungen durch Mausklick, o.ä. korrekt dar, aber es werden keine Werte mehr an FHEM geschickt - evtl. mit debounce lösbar.

praktisch sofort. Nachdem ich 1x eine Farbe im Wheel auswähle und den "Hoppser" sehe, steht alles korrekt da (FTUI-FHEM-Tasmota). Ein zweites Mal eine andere Farbe auswählen wird jedoch nicht mehr an Fhem übergeben. Es hilft auch kein site reload oder bewusstes Warten zw. 1. und 2. Klick. Nach Seitenreload kann ich also genau 1x eine Farbe setzen.
Also doch mit debounce?

Viele Grüße
rob

[mr_petz]

@rob
Hast du schon richtig plaziert.
Hier im Code der Standardwert zu sehen:
https://github.com/knowthelist/ftui/blob/6d0eda00fe22903757445dfe8bd58e56fdafb88e/www/ftui/components/colorpicker/colorpicker.component.js#L42
Du kannst auch höher gehen mit der Zeit.
Da dauert der set halt länger...
Einen ähnlichen Effekt gibt es beim Slider und Knob.
Ich musste da den debounce auf 2000 setzen...

Gruß Thomas

[rob]

@Thomas
Danke Dir. Mit saftigen debounce="3000" merke sogar ich den Unterschied

Den Color-Wert bekomme ich noch immer nur einmalig übermittelt. Sprich, da ist noch etwas ganz anderes was gestreichelt werden möchte. Ich werde mal die empfohlenen Standardeinstellen FTUI<->Fhem durchchecken. Irgendwo hab ich da ggf. einen Wurm drin.

Viele Grüße
rob

[mr_petz]

@all
Anderes Thema. Ich modde gerade mein PinPad für ftui3.
Habe ein paar Bilder angehangen.
Farben können direkt gesetzt werden oder auch eine transparente Ansicht geht.

Sieht das ganze zu verspielt aus oder schaut so ein "3D" Effekt gut aus.
Ich kann auch noch ein attr für "default" integrieren.
Möchte nur mal euer Feedback hören.
Ich werde noch ein set Befehl mit integrieren um zum Beispiel eine Alarmanlage scharf zu schalten.

Gruß Thomas

[coolice]

@all
Anderes Thema. Ich modde gerade mein PinPad für ftui3.
Habe ein paar Bilder angehangen.
Farben können direkt gesetzt werden oder auch eine transparente Ansicht geht.

Sieht das ganze zu verspielt aus oder schaut so ein "3D" Effekt gut aus.
Ich kann auch noch ein attr für "default" integrieren.
Möchte nur mal euer Feedback hören.
Ich werde noch ein set Befehl mit integrieren um zum Beispiel eine Alarmanlage scharf zu schalten.

Gruß Thomas

Ich finds gut

[rob]

Hi Thomas.

Ja, schaut gut aus  . Verspielt finde ich es nicht.
Um versch. Geschmäckern gerecht zu werden, könnte das ja ggf. konfigurierbar gehalten werden. Z.b. via style-tags, sodass Puristen im flat-style bleiben könnten, sofern es jmd. nicht corporate design genug wäre, weil FTUI3 per default flat ist usw. (Feinheiten auf hohem Niveau ).

Viele Grüße
rob