Hauptmenü

SVG-FHEM-Widgets

Begonnen von Damian, 13 Oktober 2020, 21:39:34

Vorheriges Thema - Nächstes Thema

Damian

Nachdem ich svg-Anzeigeelemente realisiert habe (https://wiki.fhem.de/wiki/DOIF/uiTable_Schnelleinstieg#SVG-uiTable-Funktionen)

möchte ich entsprechende fhem-Widgets realisieren, mit denen man Werte in fhem setzen kann.

Ich finde alle bisherigen visualisierten Eingaben in fhem etwas stiefmütterlich behandelt. Auch das knob-Widget reicht mir nicht.

Besteht Bedarf nach farbigen skalierbaren slideren, bars etc. oder reichen euch die bisherigen fhem-Widgets aus?
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

Ellert

Für mich sind die FHEM-Widgets ausreichend.

Sany

Hallo Damian,

die meisten widgets sind auch für mich ausreichend. Was mir noch fehlt ist ein senkrechter slider für Dimmer. Das fände ich intuitiver als quer. Der kann auch sehr minimalistisch sein, also fast nur ein senkrechter Strich, als slider dann einen "Knopf" oder waagerechten "Balken" mit runden Ecken. Läßt sich in uiTable verwenden, wenn man mehrere Zellen senkrecht verbindet. Da brauchts auch nicht wirklich was mit Farbverläufen.
Generell sind die zwar ganz hübsch, mir aber eigentlich zu bunt. Ich nutze den Farbverlauf z.Zt nur beim Spritpreis. Da speichere ich den niedrigsten Preis zwischen und die Darstellung des aktuellen Preises wird dann von grün nach rot eingefärbt, zwischen niedrigstem Preis und diesem +10ct. Das ist dann ein "Eyecatcher" für die hohen Preise an der Tanke. Ansonsten verfolge ich eher eine Farbgebung, die die Zustände beschreibt. Also grün für ok, zu etc, orange für z.B. offene Fenster/Türen, etwas in Bewegung, Zwischenstände set_on/set_off, also alles, was zwar in Ordnung ist, aber nicht dem Normalzustand entspricht. Rot steht für Ausfälle von Sensoren,Gateways, Aktoren etc oder vereinzelt auch ein überschrittener Wert. Legenden und Beschreibungen sind in einem leichten grau und Schalter /Taster in einem leichten cyan/blau um kenntlich zu machen, das man drauftippen kann.
Was mir weiterhin fehlt ist eine Eingabemöglichkeit wie der "switch", aber mit einem beliebigen Reading. Switch funktioniert ja nur mit state eines Devices, also ähnlich einem devStateIcon bei z.B. einer Lampe. Mir schwebt eine Lösung vor, mit der ich einen Schalter oder Taster innerhalb eines DOIFs erstellen kann. Beim Taster wird der Switch/das reading per Timer wieder zurückgesetzt, der Schalter sollte auch "von außen" und innerhalb des DOIFs beeinflussbar sein, also "set Device Reading on/off". Versuche mit einem Widget waren auch erfolglos, da dieses nicht "von außen" beeinflussbar war. Ich kann da gerne Beispiele zeigen, brauch aber etwas Zeit.

Gruß
fhem auf Zotac ZBox nano als LXC auf Proxmox, weitere LXC mit ZigBee2MQTT, MariaDB und Grafana. Homematic, FS20, mySensors, MQTT2, Tasmota, Shelly, Z-Wave  ....

Damian

Wenn du switch als uiTable-Funktion meinst, dann funktioniert sie mit beliebigen Readings in uiTable, z. B.

switch([$SELF:bla],"light_wall_2")

setreading <device> bla on verändert den Status des Icons.

Was mich stört bei den Standard-Widgets sind u.a. Sachen (mit F18 getestet) wie:

-fhem-slider: wird ohne Rahmen angezeigt, man weiß nicht wo Anfang und wo Ende ist, man muss draufklicken, damit ein Rahmen angezeigt wird
-fhem-timer: funktioniert nicht richtig innerhalb einer Tabelle, wenn man auf + klickt
-keine senkrechten Slider, Größe nicht direkt einstellbar
-Textfeld: Größe (Anzahl der Eingabezeichen) nicht einstellbar
-es wirkt vieles altbacken

Es geht mir nicht um bunte Darstellung, man kann genauso Graustufen realisieren, allerdings etwas eleganter
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

Sany

Hallo Damian,

stimmt,das geht doch. Es ist schon eine Weile her, dass ich damit rumprobiert habe, irgendwas hat halt nicht funktioniert und da Deine Beispiele aus "DOIF/uiTable Schnelleinstieg" alle mit device:state waren und das auch funktionierte ging ich damals davon aus, es geht nur so. Es gibt nur noch eins, was mir da nicht ganz gefällt: wenn ich den Schalter/Taster per set.... ändere ändert sich zwar das Icon und das Reading, aber wenn ich danach per Icon umschalten will muss ich 2 mal drauftippen, oder zwischendurch die Seite neu laden. Das macht aufm Handy nicht viel aus, aber z.B. bei einem Wandtablet, was immer/meistens an ist, ist das nicht so schön.
defmod di_UI_TasterTest DOIF init {\
set_Reading("bla","off",1);;\
}\
\
Taster {\
if([$SELF:"^blub:.on$"]){set_Exec("tasterOff",3,'set_Reading("blub","off",1)');;\
##wahlweise:\
##if([$SELF:"^blub:.on$"]){set_Exec("tasterOff",3,'fhem_set("$SELF blub off")');;\
   }\
}
attr di_UI_TasterTest readingList bla,blub
attr di_UI_TasterTest setList bla:on,off blub:on,off
attr di_UI_TasterTest uiTable {\
package ui_Table;;\
}\
\
"testSwitch"\
switch([$SELF:bla],"light_wall_2")|\
switch([$SELF:blub],"ios_off_fill\@slategray","ios_on_till_fill\@lime")

zum ausprobieren. setList/readingList braucht man nicht, geht auch ohne. Veränderungen von aussen dann nur per setreading....

ZitatWas mich stört bei den Standard-Widgets sind u.a. Sachen (mit F18 getestet) wie:

-fhem-slider: wird ohne Rahmen angezeigt, man weiß nicht wo Anfang und wo Ende ist, man muss draufklicken, damit ein Rahmen angezeigt wird
-fhem-timer: funktioniert nicht richtig innerhalb einer Tabelle, wenn man auf + klickt
... stört mich ebenso. nutze auch F18-style
Zitat-keine senkrechten Slider, Größe nicht direkt einstellbar
... das fehlt mir auch
Zitat-es wirkt vieles altbacken
.... Zustimmung!
allerdings habe ich nur wenige widgets im Einsatz, somit wäre es im Moment verschmerzbar.

das mit dem bunt war nur wegen Deiner Eingangsfrage "Besteht Bedarf nach farbigen skalierbaren ..". Alles gut.

Viele Grüße

fhem auf Zotac ZBox nano als LXC auf Proxmox, weitere LXC mit ZigBee2MQTT, MariaDB und Grafana. Homematic, FS20, mySensors, MQTT2, Tasmota, Shelly, Z-Wave  ....

Beta-User

Zitat von: Damian am 14 Oktober 2020, 15:02:47
Was mich stört bei den Standard-Widgets sind u.a. Sachen (mit F18 getestet) wie:

-fhem-slider: wird ohne Rahmen angezeigt, man weiß nicht wo Anfang und wo Ende ist, man muss draufklicken, damit ein Rahmen angezeigt wird
[...]
Das ist so ein Punkt, den ich auch schon immer suboptimal finde. Man kann sich zwar irgendwie behelfen, und z.B. den Colorpicker-Helligkeits-Slider für Rollläden nutzen, aber das ist und bleibt halt ein workaround. Genauso wie es umständlich ist, für den knob die Farben hart zu codieren...

Aber ist das ein DOIF-Thema oder könnte man das nicht auch auf der allgemeinen FHEM-Ebene lösen?
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Damian

Zitat von: Beta-User am 15 Oktober 2020, 14:21:16
Das ist so ein Punkt, den ich auch schon immer suboptimal finde. Man kann sich zwar irgendwie behelfen, und z.B. den Colorpicker-Helligkeits-Slider für Rollläden nutzen, aber das ist und bleibt halt ein workaround. Genauso wie es umständlich ist, für den knob die Farben hart zu codieren...

Aber ist das ein DOIF-Thema oder könnte man das nicht auch auf der allgemeinen FHEM-Ebene lösen?

Das könnte man bzw. sollte man. Wenn ich neue Widgets erstellen würde, dann wären es FHEM-Wigets, die man nicht nur im DOIF nutzen würde, da habe ich allerdings etwas andere Ansprüche an Design als die heutigen "FHEM-Standards".

Wird bei mir aber noch etwas dauern, da ich mir die ganzen Mechanismen erst mal klar machen muss und JavaScript ist nicht meiner Muttersprache, ok Perl war es auch nicht :)
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

Damian

Zitat von: Sany am 15 Oktober 2020, 14:06:33
Es gibt nur noch eins, was mir da nicht ganz gefällt: wenn ich den Schalter/Taster per set.... ändere ändert sich zwar das Icon und das Reading, aber wenn ich danach per Icon umschalten will muss ich 2 mal drauftippen, oder zwischendurch die Seite neu laden

ja, das Problem ist mir bekannt, das liegt aber an dem iconSwitch-Widget, welches dahinter steckt, das aber nicht von mir stammt.
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

beaune

Hallo,

ich bin mit dem IconRadioButtons eigentlich ganz zufrieden, da kann man sich vieles per css zurecht stylen. Was mir aber fehlt ist eine Variante, wo die Buttons nicht horizontal sondern vertikal angeordnet sind. Beim Blick in den Quellcode hab ich spontan nicht verstanden, wie sich die Ausrichtung überhaupt ergibt. Daher mal die Frage ins Forum: wie leicht ließe sich die Ausrichtung ändern, ggf. als Parameter voreinstellen? Kann das jemand beantworten?

Ellert

Zitat von: beaune am 17 Januar 2024, 14:15:56wie leicht ließe sich die Ausrichtung ändern, ggf. als Parameter voreinstellen?

Radiobutton ist ist jQuery UI Element https://jqueryui.com/checkboxradio/#no-icons.
Das FHEM-Widget iconRadio (basiert auf uzsuSelectRadio ) bindet das jQuery UI Element ein und realisert die Schnittstelle zu FHEMWEB.

Wenn es eine Möglichkeit gibt die Button senkrecht anzuordnen, dann vermutlich über die jQuery UI Klassen.


beaune

Hallo,

ich bin gerade über dieses bereits bekannte Problem gestolpert:

Zitat15 Oktober 2020, 14:06:33
 Es gibt nur noch eins, was mir da nicht ganz gefällt: wenn ich den Schalter/Taster per set.... ändere ändert sich zwar das Icon und das Reading, aber wenn ich danach per Icon umschalten will muss ich 2 mal drauftippen, oder zwischendurch die Seite neu laden.

Hat sich das schon mal jemand angesehen? Können wir das nicht fixen? Liegt ja wahrscheinlich in der fhemweb_iconSwitch.js...

Ellert

@beaune: Können wir, ich für meinen Teil würde einen funktionierenden Patch einchecken.

beaune

Zitat von: Ellert am 19 März 2024, 17:31:59@beaune: Können wir, ich für meinen Teil würde einen funktionierenden Patch einchecken.
Ok... den müßte nur erstmal jemand erstellen... Also ich will mir das gerne mal ansehen. Allerdings stecke ich nicht wirklich tief in diesen Themen drin und hatte gehofft, dass der ursprüngliche Autor schneller ne Lösung findet also ich ;-)

Wie ist denn überhaupt der Status? Ist das überhaupt schon mal grundsätzlich analysiert worden? Irgendwie scheint es ja so zu sein, dass der Switch das Umsetzen "von innen" zwar mitkriegt und seine Darstellung ändert, aber intern irgendie doch noch auf dem alten Zustand verharrt, und man somit dann zweimal drücken muß, damit der "gemerkte" interne Zustand wieder zur Darstellung passt. Das wär zumindest meine Vermutung. Kann aber auch ganz falsch sein. Daher die Frage: hat sich das überhaupt schon mal jemand angeschaut? Ich wäre zumindest für jeden Tipp dankbar, wo ich suchen muß...

Ellert

@beaune: Ich habe keinen Ansatz und keine Lösung. Für mich ist die Suche nach einer Lösung seit 6 Jahren beendet.

Wenn Du oder jmd. ein getestetes funktionierendes Widget liefert, kann er Maintainer für dieses Widget werden oder ich checke es ein.

beaune

ok...ich muß aber trotzdem nochmal nachfragen, um es zu verstehen. Du hast also schon nach dem Fehler gesucht, aber keine Lösung gefunden und daher aufgegeben? Was hast Du denn schon versucht, bzw. wo siehst Du die Schwierigkeit? Spontan hat man ja eher den Eindruck das muß ne Kleinigkeit sein. Offenbar ist das aber nicht so. Das würde ich gerne verstehen.