FHEM Forum

Features:

- pro DOIF eine beliebige UI-Tabelle definierbar
- alle FHEMWEB-Widgets nutzbar
- alle FHEM-Icons nutzbar
- DOIF-Syntax verwendbar
- alle Devices und Readings in FHEM direkt darstellbar und ansprechbar
- dynamische Styles (z. B. Temperaturfarbe abhängig vom Temperaturwert)
- es brauchen keine eigenen css- oder js-Datei definiert werden
- Template-Definitionen in Template-Dateien

Im Anhang: ein Statusbildschirm mit ein paar DOIFs, lässt sich gut als weitere WEB-Instanz ohne Logo, Raumauswahl und Eingabezeile auf einem Wandtablet/Smartphone darstellen und bedienen! Für Smartphone kann die Anzeige in der WEB-Instanz per Column-Attribut auf eine Spalte beschränkt werden.

Der Vorteil: einmalige Konfiguration/Pflege - mehrfache Nutzung auf verschiedenen Medien

Edit: letzte DOIF-Version und doif.js wurden eingecheckt
Edit: Statusbildschirm mit aktueller Uhrzeit und Datum
Edit: Statusbildschirm auf verschiedenen Ausgabegeräten
Edit: DOIF-Raw-Definitionen des Statusbildschirms, FHEMWEB-Tablet-RAW-Definition, Darksmallscreenstyle.css für Tablet und Smartphone

Ich habe die erste Dokumentation verfasst. Sie wird im Laufe der Zeit bis zum Einchecken des Moduls hier verfeinert.

Doku

Mit dem Attribut uiTable kann innerhalb eines DOIF-Moduls ein WEB-UI in Form einer Tabelle erstellt werden. Die Definition der Tabelle wird mit Hilfe von Perl sowie FHEM-Widgets kombiniert mit DOIF-Syntax vorgenommen.

Features:

- pro DOIF eine beliebige UI-Tabelle definierbar
- alle FHEM-Widgets nutzbar
- alle FHEM-Icons nutzbar
- DOIF-Syntax verwendbar
- alle Devices und Readings in FHEM direkt darstellbar und ansprechbar
- dynamische Styles (z. B. Temperaturfarbe abhängig vom Temperaturwert)
- es brauchen keine eigenen css- oder js-Datei definiert werden
- Template-Definitionen in Template-Dateien

Die Definiton der Tabelle ist in zwei Bereiche unterteilt. Im ersten Bereich, in geschweiften Klammern, werden Tabellenformatierungen sowie Templates als Zeichenketten und eigene Perlfunktionen definiert. Dieser Bereich ist optional.

Im zweiten Bereich werden die Inhalte der Tabelle definiert. Optional können Template-Methoden zuvor definiert werden.

Beide Bereiche werden aufbereitet und anschließend vom Perlinterpreter übersetzt, daher sind die Definitionsmöglichkeiten sehr vielfältig.

Aufbau des uiTable-Attributs

{
<Definition von Template-Attributen und Zellenformatierungen>
}
<Template-Methoden>

<Tabellendefinition>


Die Tabellendefinition wird über die Definition von Zellen vorgenommen. Die Zellen werden mit | voneinander abgegrenzt.


<Zellendefinition erste Zeile erste Spalte>  | <Zellendefinition erste Zeile zweite Spalte  | ... # Definition der ersten Tabellenzeile
<Zellendefinition zweite Zeile erste Spalte> | <Zellendefinition zweite Zeile zweite Spalte | ... #Definition der zweiten Tabellenzeile
usw.



Die Zellendefinition kann sein:

1) <Perlausdruck mit [DOIF-Syntax]>

2) STY(<Perlausdruck mit [DOIF-Syntax]>,<Style-Definition mit [DOIF-Syntax]>)

3) WID([<DEVICE>:<READING>],<FHEM-Widget definition mit [DOIF-Syntax]>,"<set-/setreading-Kommando optional>")

Die oberen Definitionen können innerhalb einer Zelle mit Punkt bzw. Komma beliebig kombiniert werden. Beim Punkt werden die Ausdrücke aneinandergereiht, bei Komma werden die Ausdrücke mit Zeilenumbruch untereinander innerhalb einer Zelle angeordnet.

Zu 1)

Diese Definition wird verwendet für: Texte, Inhalte von Readings oder Rechenausdrücke. Angaben, die die Zelle aktualisieren sollen, müssen in gewohnte DOIF-Syntax angegeben werden.

Beispiele:

Einfacher Text:

"Status"

Reading:

[Aussen:temperatur]

Berechnung:

([Wohnzimmer:temperature]+[Kinerzimmer:temperature])/2

Perlfunktion:

min([Wohnzimmer:temperature],[Kinerzimmer:temperature])

Mehrere Angaben einer Zelle können mit einem Punkt, wie auch in Perl bei Zeichenketten üblich, konkateniert werden:

"Temperatur: ".[Aussen:temperatur]

"Die maximale Temperatur der Kinderzimmer beträgt: ".max([Kind1:temperature],[Kind2:temperature])

Zu 2)

Über die Funktion STY werden Angaben mit Formatierungen über das HTML-Style Attribut vorgenommen.

Beispiele:

Formatierter Text:

STY("Esszimmer","font-weight:bold;font-size:16pt;color:#0000FF")

Formatiertes Reading:

STY([kuehlschrank:temperature],"color:#0000FF")

Formatiertes Reading mit dynamischer Farbgebung abhängig von der Temperatur

STY([Keller:humidity],"color:".DOIF_hsv([Keller:humidity],50,75,40,264,60,90))

DOIF_hsv ist eine DOIF-Funktion, bei der man den Farbverlauf definieren kann.

Syntax für DOIF_hsv Funktion:

DOIF_hsv(<value>,<min_value>,<max_value>,<min_hsv>,<max_hsv>,<saturation>,<lightness>)

Es wird durch eine feste Vorgabe von saturation und lightness, linear ein Farbton für value errechnet, dabei entspricht min_value min_hsv und max_value max_hsv.

Die gewünschten Werte für <min_hsv>,<max_hsv>,<saturation>,<lightness> können mit Hilfe eines color-Pickers bestimmt werden.

Weiterhin lässt sich ebenfalls jede andere Perlfunktion verwenden, die eine beliebige HTML-Style-Formatierung vornimmt.

Zu 3)

Über die Funktion WID werden FHEM-Widgets definiert. Es können alle in FHEM vorhanden FHEM-Widgets verwendet werden

Beispiele:

Brennericon

WID([Brenner:state],"iconLabel,closed,sani_boiler_temp\@DarkOrange,open,sani_boiler_temp")

Die Widget-Definition entspricht der FHEM-Wigdet-Syntax, siehe: https://wiki.fhem.de/wiki/FHEMWEB/Widgets

Thermostatdefinition mit Hilfe des knob-Widgets:

WID([TH_Bad_HM:desired-temp],"knob,min:17,max:25,width:45,height:40,step:0.5,fgColor:DarkOrange,bgcolor:grey,anglearc:270,angleOffset:225,cursor:10,thickness:.3","set")

Definition von Template-Attributen, Zellenformatierungen und Perl-Funktionen

Im ersten Bereich werden sog. Template-Attribute als Variablen definiert, um wiederholende Zeichenketten in Kurzform anzugeben.

Template-Attribute werden intern als hash-Variablen abgelegt.

Die Syntax lautet

$TPL{<name>}=<Perlsyntax für Zeichenketten>

<name> ist beliebig wählbar.

Bsp.

$TPL{HKnob}="knob,min:17,max:25,width:45,height:40,step:0.5,fgColor:DarkOrange,bgcolor:grey,anglearc:270,angleOffset:225,cursor:10,thickness:.3";

Damit würde die obige Definition des Widgets wie folgt aussehen:

WID([TH_Bad_HM:desired-temp],$TPL{HKnob},"set")

Weiterhin können einzelne Zellen-, Zeilen- oder Spaltenformatierungen definiert werden, dazu werden folgende Bezeichner benutzt:

$TD{<Zellenbereich für Zeilen>}="<HTML-Formatierung der Zellen>"
$TC{<Zellenbereich für Spalten>}="<HTML-Formatierung der Spalten>"
$TR{Zeilenbereich}="<HTML-Formatierung von Zeilen>"

mit

<Zellen/Spalten/Zeilen-Bereich>: Zahl|kommagetrennte Aufzählung|Bereich von..bis

Es können ebenfalls beliebige Perl-Funktionen definiert werden, die innerhalb der Tabellendefinition genutzt werden können. Sie sollten mit FUNC_ beginnen. Damit wird sichergestellt, dass die Funktionen systemweit eindeutig sind.

Bsp. Funktion für temperaturabhängige Farbgebung

sub FUNC_temp
{
  my ($temp)=@_
    return ("font-weight:bold;font-size:12pt;color:".DOIF_hsv ($temp,15,35,210,360,60,90));
}

Template-Methoden

Bei komplizierteren Ausdrücken, die mehrfach verwendet werden sollen, können Template-Methoden vor der Tabellendefinition definiert werden:

Syntax

DEF TPL_<name>(<Definition mit Platzhaltern $1,$2 usw.>)

In der Tabellendefinition können die zuvor definierten Template-Methoden genutzt werden.

Beispiel

DEF TPL_Thermostat(WID($1,$TPL{HKnob},"set"))

Nutzung der Template-Methode in der Tabellendefinition:

"Bad" | TPL_Thermostat([TH_Bad_HM:desired-temp])
"Küche" | TPL_Thermostat([TH_Kueche_HM:desired-temp])
"Wohnzimmer" | TPL_Thermostat([TH_Wohnzimmer_HM:desired-temp])

Die neue DOIF-Version ist im ersten Post angehängt.


Hier meine Beispielkonfiguration (das Layout ist im Anhang zu sehen), bei den Devices handelt es sich um HM-Thermostate und HM-Switche.

Das DOIF hat hier keine Steuerungsaufgabe (1), es demonstriert am Beispiel die Nutzung des uiTable-Attributes. Üblicherweise können DOIF-Definitionen mit ihren Steuerungsaufgaben, wie sie bisher genutzt wurden, mit dem uiTable-Attribut um ein User-Interface für das Darstellen oder Schalten eigener oder fremder Readings bzw. Devices ergänzt werden, um auf die Steuerung des DOIF-Moduls Einfluss zu nehmen.

define ui_Heizung DOIF (1)

attr ui_Heizung uiTable
{
$TPL{HKnob}="knob,min:17,max:25,width:45,height:40,step:0.5,fgColor:DarkOrange,bgcolor:grey,anglearc:270,angleOffset:225,cursor:10,thickness:.3";
$TPL{onoff}="iconLabel,on,control_standby\@DarkOrange,off,control_standby";
#$TPL{swonoff} =  "iconSwitch,on,control_standby,off,control_standby\@DarkOrange";
$TPL{swonoff} =  "iconSwitch,on,fa_off,off,fa_off\@DarkOrange";
$TC{last}="align='center'";
$TC{0}= "style='font-weight:bold;font-size:12pt;'";

sub FUNC_temp
{
  my ($temp)=@_;
    return ("font-weight:bold;font-size:12pt;color:".DOIF_hsv ($temp,15,35,210,360,60,90));
}

sub FUNC_hum
{
    my ($hum)=@_;
    return ("font-weight:bold;font-size:12pt;color:".DOIF_hsv ($hum,50,75,40,264,60,90));
}
}

"Status"|
WID([Brenner:state],"iconLabel,closed,sani_boiler_temp\@DarkOrange,open,sani_boiler_temp") |
WID([Zirkulation:state],"iconSwitch,off,sani_pump\@DarkOrange,on,sani_pump") |
WID([Therme:state],"iconSwitch,off,sani_floor_heating_neutral\@DarkOrange,on,sani_floor_heating_neutral") |
WID([Therme_230V:state],"iconLabel,on,message_socket_on_off\@DarkOrange,off,message_socket_on_off")

"Bad" |
STY([TH_Bad_HM:humidity]." %",FUNC_hum([TH_Bad_HM:humidity])) |
STY([TH_Bad_HM:measured-temp]."°",FUNC_temp([TH_Bad_HM:measured-temp])) |
WID([H_Bad:state],$TPL{swonoff}) |
WID([TH_Bad_HM:desired-temp],$TPL{HKnob},"set"),STY([TH_Bad_HM:measured-temp]."°","font-weight:bold;font-size:9pt;color:".DOIF_hsv ([TH_Bad_HM:measured-temp],15,35,210,360,60,90))

"Kinderz. ost"|
STY([TH_Kz_o_HM:humidity]." %",FUNC_hum([TH_Kz_o_HM:humidity]))|
STY([TH_Kz_o_HM:measured-temp]."°",FUNC_temp([TH_Kz_o_HM:measured-temp])) |
WID([H_Kinderzimmer_o:state],$TPL{swonoff}) |
WID([TH_Kz_o_HM:desired-temp],$TPL{HKnob},"set")

"Kinderz. west"|
STY([TH_Kz_w_HM:humidity]." %",FUNC_hum([TH_Kz_w_HM:humidity])) |
STY([TH_Kz_w_HM:measured-temp]."°",FUNC_temp([TH_Kz_w_HM:measured-temp])) |
WID([H_Kinderzimmer_w:state],$TPL{swonoff}) |
WID([TH_Kz_w_HM:desired-temp],$TPL{HKnob},"set")

"Keller"|
STY([TH_Keller_HM:humidity]." %",FUNC_hum([TH_Keller_HM:humidity])) |
STY([TH_Keller_HM:measured-temp]."°",FUNC_temp([TH_Keller_HM:measured-temp])) |
WID([H_Keller:state],$TPL{swonoff}) |
WID([TH_Keller_HM:desired-temp],$TPL{HKnob},"set")


Sieht sehr cool aus, wohin kommt die doif.js?

LG Patrick

Zitat von: SamNitro am 20 Oktober 2017, 16:41:31
Sieht sehr cool aus, wohin kommt die doif.js?

LG Patrick

steht im ersten Post, ins fhem/www/pgm2 Verzeichnis

Weiteres Bespiel für Statusanzeige:


attr sicherheit uiTable
"Status"|
WID([Alarm_scharf], "iconLabel,closed,building_security\@DarkOrange,open,building_security") |
WID([Anwesenheit], "iconLabel,on,status_available\@DarkOrange,off,status_away_2") |
WID([Garage], "iconLabel,geöffnet,fts_garage_door_10\@DarkOrange,geschlossen,fts_garage_door_100") |
WID([Offene_Fenster], "iconLabel,keine,fts_window_1w,.*,fts_window_1w_open\@DarkOrange")|STY([Offene_Fenster], ([Offene_Fenster] eq "keine" ? "color:white" : "color:DarkOrange"))


[Offene_Fenster] ist Status eines DOIF´s mit [@s(<br>)"Fenster$":state:"open","keine"]

genial ...
jetzt noch mit drag&drop (jo, is a scherz ... oder doch ned?), und meine klicki/bunti welt hat an neuen helden *lach*
wobei a bisserl bös bin ich dir aber schon: immerhin krieg ich jetzt viel arbeit wegen rg-->doif umbaus *bg*

Zitat von: the ratman am 22 Oktober 2017, 15:16:59
genial ...
jetzt noch mit drag&drop (jo, is a scherz ... oder doch ned?), und meine klicki/bunti welt hat an neuen helden *lach*
wobei a bisserl bös bin ich dir aber schon: immerhin krieg ich jetzt viel arbeit wegen rg-->doif umbaus *bg*

Als nächstes ist Beleuchtung und Beschattung dran ;)

Hier mal Beleuchtung-Scene, diesmal mit DOIF-Steuerung:

defmod DI_Licht DOIF (([06:25-08:00|8] or [15:00-23:00]) and [Helligkeit] eq "off")\
  (set Lampeflur on, set Lampekueche on)\
DOELSEIF (([06:25-08:30|8] and [Helligkeit] eq "on") or [08:30] or [23:30])\
  (set Lampekueche off, set Lampeflur off)\

attr DI_Licht cmdState on|off
attr DI_Licht devStateIcon on:status_night off:scene_day
attr DI_Licht group Aktuell
attr DI_Licht icon fa_light_bulb
attr DI_Licht initialize initialized
attr DI_Licht room Licht,Status
attr DI_Licht uiTable WID([Helligkeit],"iconLabel,off,status_night\@DarkOrange,on,light_wall_2") |\
WID([Aussenbeleuchtung],"iconSwitch,off,light_wall_2\@DarkOrange,on,light_wall_2") |\
WID([Wandleuchten_W],"iconSwitch,off,light_wall_3\@DarkOrange,on,light_wall_3") |\
WID([FS20_Couchlampe_W],"iconSwitch,off,hue_room_living\@DarkOrange,on,hue_room_living") |\
#WID([Stehlampe_KZ_W],"iconSwitch,off,fa_light_bulb\@DarkOrange,on,fa_light_bulb") |\
WID([Lampeflur],"iconSwitch,off,hue_room_hallway\@DarkOrange,on,hue_room_hallway") |\
WID([Lampekueche],"iconSwitch,off,hue_room_kitchen\@DarkOrange,on,hue_room_kitchen")


Aktueller Status-Bildschirm siehe Anhang, Rollladen kommt nach dem Urlaub ;)

Schade Rollladen wären auch schon interessant.


Gesendet von iPhone mit Tapatalk

Zitat von: SamNitro am 22 Oktober 2017, 20:30:58
Schade Rollladen wären auch schon interessant.


Gesendet von iPhone mit Tapatalk

Na gut, weil du es bist, hab´mal schnell gehackt ;)

defmod DI_Rollladen DOIF (([Dunkelheit] eq "off" and [06:25-09:00|8]) or [09:00|7]) \
  ((set R_W_S,R_W_W[1-3] on))\
DOELSEIF ([Dunkelheit] eq "on")\
  ((set R_W_S,R_W_W[1-3] off))\
\

attr DI_Rollladen cmdState oben|unten
attr DI_Rollladen devStateIcon unten:status_night oben:scene_day
attr DI_Rollladen do always
attr DI_Rollladen group Aktuell
attr DI_Rollladen initialize init
attr DI_Rollladen room Beschattung,Status
attr DI_Rollladen uiTable {\
  $TPL{shutter}="iconSelectRadio,darkorange,on,fts_shutter_10,30,fts_shutter_30,50,fts_shutter_50,80,fts_shutter_80,off,fts_shutter_100";;\
}\
\
\
"Dachboden"|WID([R_Dachboden],$TPL{shutter})\
"Bad"|WID([R_Bad],$TPL{shutter})\
"KInderz. ost"|WID([R_Kinderzimmer1_O],$TPL{shutter})\
"Kinderz. west1"|WID([R_Kinderzimmer2_W1],$TPL{shutter})\
"Kinderz. west2"|WID([R_Kinderzimmer2_W2],$TPL{shutter})\
"Wohnz. süd"|WID([R_W_S],$TPL{shutter})\
"Wohnz. west1"|WID([R_W_W1],$TPL{shutter})\
"Wohnz. west2"|WID([R_W_W2],$TPL{shutter})\
"Wohnz. west3"|WID([R_W_W3],$TPL{shutter})


Mega geil Danke dir :)


Gesendet von iPhone mit Tapatalk

sag mal ... nur so als dumme idee = ich träume mal vor mich hin:

idee: zellen zusammenlegen, oder besser noch ne tabelle in der zelle einer anderen tabelle. also z.b. mehrere tabellen erstellen, eine haupttabelle und dann weitere tabellen mit namen. namen in eine zelle der haupttabelle, fatitsch is das wunderwerk. vielleicht sogar mit tabellen aus anderen doif's. <-- was für möglichkeiten das gäbe ... ich stell mir grad vor, ich kann tabellen wie alles andere behandeln ... also z.b. in zelle x tabelle a bei ereignis a, tabelle b bei ereignis b. so gingen ganze situationsabhängige interfaces zu basteln. von anzeigen über navigation, und und und ...

oder auch die möglichkeit tabellenränder/zellenränder sichtbar zu machen. <-- das dann nur mehr als fingerübung, damit dir ned zu langweilig wird ;o)

Zitat von: the ratman am 22 Oktober 2017, 22:34:36
sag mal ... nur so als dumme idee = ich träume mal vor mich hin:

idee: zellen zusammenlegen, oder besser noch ne tabelle in der zelle einer anderen tabelle. also z.b. mehrere tabellen erstellen, eine haupttabelle und dann weitere tabellen mit namen. namen in eine zelle der haupttabelle, fatitsch is das wunderwerk. vielleicht sogar mit tabellen aus anderen doif's. <-- was für möglichkeiten das gäbe ...

oder auch die möglichkeit tabellenränder/zellenränder sichtbar zu machen. <-- das dann nur mehr als fingerübung, damit dir ned zu langweilg wird ;o)

Vieles davon geht jetzt schon, wenn man sich mit html/css auskennt. Du kannst in uiTable an beliebiger Stelle HTML-Elemente einbauen.

ZitatDu kannst in uiTable an beliebiger Stelle HTML-Elemente einbauen.

ich hab grad so ein komisches gefühl in der leistengegend *g*
super anfang!

Ich will jetzt keinen abschrecken, aber Ellert hat schon etwas experimentiert:

defmod widgetkombi DOIF (1) ## HMsensor HMdummy
attr widgetkombi room DOIFalone2
attr widgetkombi uiTable {\
$TPL{style2}="text-align:right;;width:23px;;position:absolute;;left:13px;;top:26px;;font-weight:bold;;font-size:12px;;color:#";;\
$TPL{style3}="text-align:right;;width:23px;;position:absolute;;left:13px;;top:13px;;font-weight:bold;;font-size:12px;;color:#";;\
\
$TPL{knob1}="knob,thickness:.4,fgColor:#00A5FF,min:7,max:30,width:50,height:50,step:.5,angleArc:270,angleOffset:225,displayInput:false";;\
$TPL{knob2}="knob,thickness:.3,fgColor:#FFA500,min:7,max:30,width:50,height:50,step:.5,angleArc:270,angleOffset:225,displayInput:false";;\
\
}\
\
"<div style='position:relative;;width:50px;;height:50px'><div style='position:absolute;;left:0px;;top:0px'>".WID([TH_Bad_HM:measured-temp],$TPL{knob1},"set")."</div><div style='position:absolute;;left:0px;;top:0px'>".WID([TH_Bad_HM:desired-temp],$TPL{knob2},"set")."</div>".STY([TH_Bad_HM:measured-temp:d1],$TPL{style2}.DOIF_rgb("3052FF","FF0000",1,25,[TH_Bad_HM:measured-temp])).STY([TH_Bad_HM:desired-temp:d1],$TPL{style3}.DOIF_rgb("3052FF","FF0000",1,25,[TH_Bad_HM:desired-temp]))."</div>"


Das Ergebnis: ein zusammengesetztes Thermostat-Widget siehe Anhang :)

Zitat von: Damian am 22 Oktober 2017, 22:54:37
Ich will jetzt keinen abschrecken, aber Ellert hat schon etwas experimentiert:

Eine Erläuterung gibt es hier: https://wiki.fhem.de/wiki/DOIF/uiTable

Zitat von: Ellert am 23 Oktober 2017, 08:28:01
Eine Erläuterung gibt es hier: https://wiki.fhem.de/wiki/DOIF/uiTable

Version 0.10 im ersten Post

Es lassen sich jetzt Template-Methoden für kompliziertere Widgets erstellen (hier am Beispiel der Template-Methoden: TPL_meins und TPL_Thermo)

Beispiel:

attr Test uiTable {
$SHOWNOSTATE=1;


$TPL{style2}="text-align:right;width:23px;position:absolute;left:13px;top:26px;font-weight:bold;font-size:12px;color:#";
$TPL{style3}="text-align:right;width:23px;position:absolute;left:13px;top:13px;font-weight:bold;font-size:12px;color:#";

$TPL{knob1}="knob,thickness:.4,fgColor:#00A5FF,min:7,max:30,width:50,height:50,step:.5,angleArc:270,angleOffset:225,displayInput:false";
$TPL{knob2}="knob,thickness:.3,fgColor:#FFA500,min:7,max:30,width:50,height:50,step:.5,angleArc:270,angleOffset:225,displayInput:false";


sub FUNC_temp
{
  my ($temp)=@_;
    return ("height:6pt;font-weight:bold;color:".DOIF_hsv ($temp,0,30,110,360,60,90));

}
sub FUNC_hum
{
    my ($hum)=@_;
    return ("height:0pt;font-weight:bold;color:".DOIF_hsv ($hum,50,90,40,264,60,90));
}
}

#Template-Methoden

DEF TPL_meins(STY($1." %",FUNC_hum($1)) ,STY($2."°",FUNC_temp($2)))
DEF TPL_Thermo("<div style='position:relative;;width:50px;;height:50px'><div style='position:absolute;;left:0px;;top:0px'>".WID($1,$TPL{knob1},"set")."</div><div style='position:absolute;;left:0px;;top:0px'>".WID($2,$TPL{knob2},"set")."</div>".STY($1,$TPL{style2}.DOIF_rgb("3052FF","FF0000",1,25,$1)).STY($2,$TPL{style3}.DOIF_rgb("3052FF","FF0000",1,25,$2))."</div>")

#Tabellendefinition

"Status"|
TPL_Thermo([TH_Bad_HM:measured-temp:d1],[TH_Bad_HM:desired-temp:d1]) |
TPL_meins([Aussensensor:humidity],[Aussensensor:temperature])


Edit: Doku im zweiten Post wurde um Template-Methoden erweitert.

Ich habe fertig. Version 0.11 im ersten Post mit Doku zu uiTable.

Wenn hier kein Feedback zur aktuellen Version kommt, werde ich sie in den nächsten Tagen nur nach eigenen Tests einchecken.

Ich habe noch eine Schippe drauf gelegt  (Version 0.13 im ersten Post). Man kann jetzt Templates aus Dateien importieren,  so lassen sich vordefinierte Templates in eigenen Layouts nutzen. Damit ist der Weg geebnet, Kreativität der Nutzer anderen zur Verfügung zu stellen. :)

P.S. doif.js ist inzwischen eingecheckt und muss nicht separat kopiert werden.

Hier mal zur Motivation ein Beispiel für ein Solar-Template. Anforderung: ein selbstfärbendes Icon abhängig von der Solareinstrahlung mit Anzeige der Leistung.

Inhalt von solar.tpl

# Solar-Template
{
sub FUNC_solar_hsv
{
   my ($kw)=@_;
   return (DOIF_hsv ($kw,0,4,0,60,80,90));
}

sub FUNC_KW
{
    my ($kw)=@_;
    return ("font-weight:bold;font-size:10pt;color:".FUNC_solar_hsv($kw));
}
}
#Template-Methode
DEF TPL_solar(FW_makeImage("sani_solar\@".FUNC_solar_hsv($1)).STY($1." KW",FUNC_KW($1)))


Die Nutzung des Templates im uiTable-Attribut ist dann relativ einfach:


#import der Template-Datei
IMPORT ./contrib/DOIF/solar.tpl

#Tabellendefinition
TPL_solar([test_d:state:d1])

test_d ist hier ein Test-Dummy, der die Solar-Leistung beinhaltet (von 0 bis 4 KW).

sag mal: nur aus interesse ...

hast du vor fürs doif ne art bedienoberfläche/vereinfachung/abhängkeitenanzeige zu basteln? jaja, hatte ich schon mal gefragt, aber diesmal ists nicht mehr als spaß, sondern als ernsthafte frage gemeint.
bei dem funktionsumfag und vor allem den vielen, vielen verknüpfungsmöglichkeiten wird das wiki zum doif bald die bibel an seitenzahl übertreffen und ich bin jetzt schon nur mehr am nachschlagen, weil man (oder zumindest ich) sich diese riesige menge an möglickeiten nicht wirklich merken kann.

du weißt: ich bin begeistert von dem, was du da auf die beine gestellt hast. aber langsam krieg ich angst *g*

ja, die Anforderung ist nicht neu. Allerdings wird man immer nur einen Teil des Funktionsumfangs abdecken können. DOIF arbeitet sehr nah an Perl, damit kommt es der Forderung nah, eine Benutzeroberfläche für eine Programmiersprache zu entwickeln.

Nicht umsonst programmieren auch heute noch viele mit Hilfe eines universellen Editors - warum wohl.

Ich habe mich erst mal darauf konzentriert, etwas mehr "Farbe ins Spiel" zu bringen und dabei flexibel zu bleiben. Ich glaube, das ist uns (Ellert war kräftig auf der js-Seite beschäftigt) gelungen, denn es bieten sich jetzt Möglichkeiten an, die man sonst nur mit dem Umstieg auf andere UI´s, die es mittlerweile in FHEM gibt, erreichen kann. Immerhin steckt da jetzt ca. ein halbes Jahr Entwicklung drin seit der Geburt der Idee hier: https://forum.fhem.de/index.php/topic,72072.msg636738.html#msg636738

Für eine DOIF-Bedienoberfläche bräuchten wir da bestimmt ein ganzes Jahr ;)

ZitatAllerdings wird man immer nur einen Teil des Funktionsumfangs abdecken können.

vielleicht gar ned so blöd ...
fürs "grobe designen" und ein bissi hilfe, für die feinheiten dann handbetrieb. würde in meinen augen auch gleich animieren, mal mehr zu lernen und nicht schon beim lesen des wikis schweiß- und panikattacken zu kriegen *g*.

mir geht einfach nicht dieses "puzzlespiel" aus dem kopf. du erinnerst dich? man schiebt quasi teile zusammen. passen sie nicht, gehts auch nicht. wäre für das "grund doif" und tabellenerstellung im doif sicher ne super hilfe. wer mehr will schaltet um auf editior.
das gäbs ja sogar fertig, nur hab ich keinen dunst, wie groß der aufwand ist. ich glaube mich zu erinnern, dass hier mal einer meinte, dass zumindest das ganze fhem damit abzubilden übertriebener aufwand wäre. aber doif ... ?

und nur, damitst mich ned falsch verstehst: das ganze wäre ein "schön wärs". ich bin hier nur am "rumspinnen", sicher nicht am fordern oder unzufrieden sein.

Wollen wir mal erstmal die neuen Features einchecken, dann schauen wir in die Zukunft. Ein paar gute Wiki-Tutorials, können für viele ebenfalls eine gute Starthilfe sein. Dass die Commandref eine vollständige Dokumentation mit Beispielen haben wird, ist ja selbstverständlich.

Der Finish naht. Im Anhang v0.14 mit DOIF_Readings: ressourcenschonend ohne FHEM-Events!

Auszug aus der Doku:

Erzeugen berechneter Readings

Mit Hilfe des Attributes DOIF_Readings können eigene Readings innerhalb des DOIF definiert werden, auf die man im selben DOIF-Moduls zugreifen kann. Die Nutzung ist insbesondere dann sinnvoll, wenn mehrfach die gleichen Berechnungen innerhalb eines DOIF-Modus vorgenommen werden sollen. DOIF_Readings-Berechnungen funktionieren ressourcenschonend ohne Erzeugung FHEM-Events nach außen. Änderungen dieser Readings triggern allerdings das eigene DOIF-Modul.

Syntax

attr <DOIF-Modul> DOIF_Readings <readingname1>:<definiton>, <readingname2>:<definition>,...

<definition>: Beliebiger Perlausdruck ergänzt um DOIF-Syntax in eckigen Klammern. Angaben in eckigen Klammern wirken triggernd und aktualisieren das definierte Reading.

Beispiel: Push-Mitteilung über die durchschnittliche Temperatur aller Zimmer

define di_temp DOIF ([$SELF:temperature]>20) (push "Die Durchschnittstemperatur ist höher als 20 Grad, sie beträgt [$SELF:temperature]")
DOELSE

attr di_temp DOIF_Readings temperature:[#average:d2:"":temperature]

Hierbei wird der aufwändig berechnete Durchschnittswert nur einmal berechnet, statt zwei mal, wenn man die Aggregationsfunktion direkt angeben würde.

Bugfix. V0.15 im ersten Post.

Hat denn jemand schon seine ersten Erfahrung mit den neuen Features gemacht?

Moin,
geht heute noch los (endlich Wochenende und Zeit dafür), ich habe da schon so einige Umstellungen im Kopf und werde mich hier bestimmt nochmal melden. Kurze Frage, muss die .pm im ersten Post noch umbenannt werden und damit dann die exierende überschrieben werden?

Zitat von: ComputerZOO am 03 November 2017, 19:38:17
Moin,
geht heute noch los (endlich Wochenende und Zeit dafür), ich habe da schon so einige Umstellungen im Kopf und werde mich hier bestimmt nochmal melden. Kurze Frage, muss die .pm im ersten Post noch umbenannt werden und damit dann die exierende überschrieben werden?

Klar. Vorher FHEM stoppen und danach neustarten - es haben sich einige Dinge intern geändert.

Version v0.16. Jetzt auch als Floorplan-Alternative

Edit: Bild geändert

das geht auch auf floorplan?
also quasi doif-floorplan auf fhem-floorplan?

wenn ja, dann: DAMIAN FÜR PRÄÄÄSIDENTE!!!

sag als nächstes, dass du das noch als popup/versteckbar machen willst und ich will ein kind von dir *g*.

Zitat von: the ratman am 04 November 2017, 08:33:53
das geht auch auf floorplan?
also quasi doif-floorplan auf fhem-floorplan?

nein, es ist eine Floorplan-Alternative

Hintergrundbild, paar Widgets drauf und fertig:

uiTable
{
  $TABLE = "text-align:center; font-weight:bold;color:red; width:300px; height:300px; background-image:url($FW_ME/www/pgm2/images/Grundriss.jpg); background-size: 300px 300px;";
  $TR{1,3} = "class=''";
  $TPL{switch}="iconSwitch,on,off,off,on";
}

WID([$SELF:SZ],$TPL{switch})|WID([$SELF:Kue],$TPL{switch})|WID([$SELF:Bad],$TPL{switch})
" "|" "|WID([$SELF:Diele],$TPL{switch})
WID([$SELF:WZ1],$TPL{switch})|WID([$SELF:Ki],$TPL{switch})|" "
WID([$SELF:WZ2],$TPL{switch})|WID([$SELF:Balkon],$TPL{switch})|" "

schade - wirst also nicht der trump-nachfolger *fg*

ich seh da keine koordinaten, wie hast den das gelöst, wenn ich fragen darf?
machste das nur mit zellen?

Zitat von: the ratman am 04 November 2017, 08:43:42
schade - wirst also nicht der trump-nachfolger *fg*

ich seh da keine koordinaten, wie hast den das gelöst, wenn ich fragen darf?

siehst im vorherigen Post: Bild plus Tabelle. Man muss sich das Bild als Tabellenraster vorstellen und dann die passende Tabelle definieren.

na dann war ich eh am richtigen weg ... btw das neue bild gfallt ma besser *g*

und das "$FW_ME" ist ne feste variable oder oder hab ich da wieder mal was verpennt?


btw - weißt du, was ich lustig fände, wo ich grad deine lamperl anguck?
könnte man irgendwie in den knob anstelle von zahlen grafiken bauen? knob in knob geht ja auch.
sinn der idee: dimmbare lampen - in der mitte die lampe und rund herum ein knob für die helligkeit - am besten dann noch ein knob für hue usw. ... müßte geil aussehen und schön platz sparen gegenüber den schiebereglern.

Zitat von: the ratman am 04 November 2017, 09:52:15
na dann war ich eh am richtigen weg ... btw das neue bild gfallt ma besser *g*

und das "$FW_ME" ist ne feste variable oder oder hab ich da wieder mal was verpennt?


btw - weißt du, was ich lustig fände, wo ich grad deine lamperl anguck?
könnte man irgendwie in den knob anstelle von zahlen grafiken bauen? knob in knob geht ja auch.
sinn der idee: dimmbare lampen - in der mitte die lampe und rund herum ein knob für die helligkeit - am besten dann noch ein knob für hue usw. ... müßte geil aussehen und schön platz sparen gegenüber den schiebereglern.

$FW_ME ist eine globale FHEM-Variable. Man kann auch relative Pfade angeben ./www/...

Man kann aus den vorhandenen FHEMWEB-Widgets sich etwas (z. B. über Templates) zusammenstellen. Ich denke aber, dass langfristig einige neue Widgets entstehen werden. DOIF ist ja kompatibel zu der FHEMWEB-Schnittstelle.

Zitat von: Damian am 04 November 2017, 10:13:30~~~ snip ~~~
Ich denke aber, dass langfristig einige neue Widgets entstehen werden. DOIF ist ja kompatibel zu der FHEMWEB-Schnittstelle.

naja, bastelkasten fände ich schöner.
z.b. wünscht die meinige sich immer schon einen rgb-slider/knob. der wäre zwar sehr "ungenau", aber für schnelles, ungefähres farb-einstellen für sie ausreichend. glaub nicht, dass sowas noch viele andere wollen würden und somit die wahrscheinlichkeit für ein solches widget doch recht absinkt, denk ich mal.

Zitat von: the ratman am 04 November 2017, 15:44:27
naja, bastelkasten fände ich schöner.
z.b. wünscht die meinige sich immer schon einen rgb-slider/knob. der wäre zwar sehr "ungenau", aber für schnelles, ungefähres farb-einstellen für sie ausreichend. glaub nicht, dass sowas noch viele andere wollen würden und somit die wahrscheinlichkeit für ein solches widget doch recht absinkt, denk ich mal.

So abwegig ist das nicht. Ich fand persönlich die meisten FHEMWEB-Widget bescheiden. Viele hier eingesetzte Widgets sind neu (iconLabel, iconSwitch, iconRadio). Ellert hat sie während der uiTable-Entstehung in Absprache programmiert. Z. Zt. entsteht ein selbst einfärbendes Icon-Widget, da ist ein rgb-Knob nicht mehr weit entfernt ;)

ich bin echt schon neugierig, wie das alles in ein paar monaten aussehen wird.
was mir ja sehr gfallt is, das ihr gruppenarbeit machts ... wenn das schule macht, wirds verdammt mächtige spielsachen geben.

Hier mal ein Beispiel für ein Zisternen-Icon-Template mit Füllstandsanzeige. So etwas lässt sich einfach auf Batterien, Rollläden und andere Icons anpassen, bei denen ein Pegel/Level sichtbar sein soll.

Inhalt der Template-Datei Zisterne.tpl

{
  sub FUNC_zisterne {
    my($val)= @_;
    my $ret= "<div style=\"position:absolute;bottom:-11px;left:6px;width:20px;height:23px;background:linear-gradient(to top, blue, lightblue ".$val."%, rgba(0,0,0,0) ".$val."%);\"></div>";
    return $ret;
  }
}

DEF TPL_Zisterne("<div style='width:32px;height:20px;position:relative;'>".FUNC_zisterne($1)."<div style='position:relative;'>".FW_makeImage('Zisterne')."</div></div>",STY($1."%","font-weight:bold;font-size:8pt;"))

Definition im uiTable-Attribut:

IMPORT ./contrib/DOIF/Zisterne.tpl

TPL_Zisterne([HMdummy_Labor:level])


Ich glaube, DASS wird die Basis für mein Wohnwagen-Fhem :D

Anwendungsfall: Visualisierung Regen-/Leitungswassernutzung

Ausgangssituation:

Abhängig vom Wasserstand in der Zisterne wird zwischen Zisternenwasser (Regenwasser) und Leitungswasser umgeschaltet. Die Umschaltung erfolgt automatisch gesteuert über ein DOIF.

Anforderung der Visualisierung:

Falls Zisternenwasser genutzt wird, soll ein Zisternensymbol mit aktuellem Füllstand angezeigt werden, sonst ein Wasserhahn als Symbol für Leitungswasser

Lösung:

Template:

{
  sub FUNC_zisterne {
    my($val)= @_;
    my $ret= "<div style=\"position:absolute;bottom:4px;left:6px;width:20px;height:23px;background:linear-gradient(to top, darkorange, lightgrey,  ".$val."%, rgba(0,0,0,0) ".$val."%);\"></div>";
    return $ret;
   }
}

DEF TPL_Zisterne    ("<div style='width:32px;height:36px;position:relative;'>". ($2 eq "Zisterne" ? FUNC_zisterne($1):"").
"<div style='position:relative'>".($2 eq  "Zisterne" ? FW_makeImage('Zisterne@darkorange'):FW_makeImage('sani_water_tap@darkorange'))."</div></div>")


Aufruf des Templates:

TPL_Zisterne([Wasserzisterne],[Zisterne])

[Wasserzisterne] enthält den Füllstand der Zisterne in Prozent (0-100)
[Zisterne] enthält den aktuellen Zustand der Schaltung "Leitung"/"Zisterne"

Im Anhang Symboldarstellung für Leitungswasser, Zisternenwasser mit Füllstand 60% und mein aktueller Statusbildschirm mit dem angewandten Template im Bereich "Umwelt" (aktuell: Leitungswasser)

Im FHEM-Wiki gibt es auch einige Beispiele, z.B. eine Ladezustandsanzeige zum ausprobieren.

https://wiki.fhem.de/wiki/DOIF/uiTable#Ladezustand_als_vertikaler.2C_linearer_Gradiend

Anwendungsfall: Visualisierung von Netzbezug/Netzeinspeisung

Ausgangssituation

Im Reading [zaehler:l-momentan] befindet sich die aktuelle Netz-Einspeisung (negative Zahl) bzw. der aktuelle Netz-Bezug (positive Zahl) in KW.

Anforderung

Bei Netzeinspeisung soll ein Blitzsymbol weiß erscheinen und die aktuelle Leistung in einer Farbskalierung von gelb (0 KW) bis grün (4 KW) in KW mit einer Nachkommastelle angezeigt werden.

Bei Netzbezug soll ein Blitzsymbol orange erscheinen und die aktuelle Leistung in einer Farbskalierung von orange (0 KW)  bis rot (-4 KW) in KW als negative Zahl mit einer Nachkommastelle angezeigt werden.


Lösung

Template:

{
sub FUNC_KW
{
    my ($kw)=@_;
    if ($kw > 0) {
      return ("font-weight:bold;font-size:10pt;color:".DOIF_hsv ($kw,0,4,60,120,60,90));
    } else {
      return ("font-weight:bold;font-size:10pt;color:".DOIF_hsv ($kw,-4,0,0,30,100,100));
    }
}
}

DEF TPL_power(STY(-$1." KW",FUNC_KW (-$1)) . FW_makeImage($1 > 0 ? "fa_bolt\@Darkorange":"fa_bolt") )


Aufruf des Templates:

TPL_power([zaehler:l-momentan:d1])

Um den Einstieg in uiTable zu erleichtern, habe ich eine Standard-Template-Datei erstellt. Sie beinhaltet zunächst folgende Templates:

TPL_onoff: on/off-Schalter (bedienbar)
TPL_Therm: Thermostat (bedienbar)
TPL_TempHym: Temperatur/Feuchte-Anzeige
TPL_Roll: Rollladen (bedienbar)
TPL_Wind: Anzeige offene Fenster
TPL_Batt: Anzeige leere Batterien

Die Anwendung der Templates ist denkbar einfach: Angabe des Template-Namens mit Readingangabe als Parameter.

Hier ein kleines Beispiel für die Anwendung der Templates:

attr uiTable
#Import der Templates
IMPORT ./contrib/DOIF/standard.tpl

#Tabellendefinition
"Schalter" | "Thermostat" | "Temperatur/Feuchte"
TPL_onoff ([test_d]) | TPL_Therm ([TH_Kz_o_HM:desired-temp]) | TPL_TempHym ([TH_Bad_HM:measured-temp],[TH_Bad_HM:humidity])
"Rollladen" | "offene Fenster" | "Battery low"
TPL_Roll ([R_Kinderzimmer1_O:pct]) | TPL_Wind ([$SELF:Windows]) | TPL_Batt ([$SELF:Battery])


Readings $SELF:Windows und $SELF:Battery sind im Beispiel über DOIF_Readings als Aggregation definiert:

attr DOIF_Readings Windows:[@s(<br> )"Fenster$":state:"open","keine"], Battery:[@s(<br> )":battery:":battery:"low","keine"]

Die eigentlichen Templates-Definitionen in der Datei standard.tpl sind Einzeiler. Sie können als Ausgangsbasis für eigene Template-Kreationen dienen ;)

Im Anhang: die Templatedatei (standard.tpl) und das Layout der Beispielkonfiguration

Edit: standard.tpl aktualisiert

Hallo Damian,
ich wollte das gerade mal ausprobieren um für meine Lüftung mit WRG ein Bedien und Info Panell zu basteln,
scheitere aber schon bevor es losgeht - die DOIFv0.20.pm einfach in den Modulordner kopieren neustarten und loslegen - oder wie?
die 98_DOIF.pm bleibt unberührt?

Zitat von: der-Lolo am 25 November 2017, 16:40:40
Hallo Damian,
ich wollte das gerade mal ausprobieren um für meine Lüftung mit WRG ein Bedien und Info Panell zu basteln,
scheitere aber schon bevor es losgeht - die DOIFv0.20.pm einfach in den Modulordner kopieren neustarten und loslegen - oder wie?
die 98_DOIF.pm bleibt unberührt?

Die Frage hatten wir schon hier: https://forum.fhem.de/index.php/topic,77690.msg709443.html#msg709443

Oft möchte man ein eine Wiederholung des Schaltens eines DOIFs mit do always provozieren und gleichzeitig zyklisch sendende Sensoren abfragen. Eine umständliche Möglichkeit bestand bisher darin, die Abfrage des zyklischen Sensors in ein separates DOIF ohne do always auszulagern und dessen Zustand im eigentlichen DOIF abzufragen. Dieses Problem lässt sich jetzt elegant mit DOIF_Readings lösen.

Bsp:

DOIF ([Schalter] eq "on" and [aussen:temperature] < 0) (set heizung on) DOELSE (set heizung off)

Nun soll wenn der Zustand von Schalter auf on geht, jedes mal set heizung on oder off ausgeführt werden. Do always ist wegen zyklischer Trigger von aussen:temperature kontraproduktiv.

Dieses Problem kann mit DOIF_Readings wie folgt gelöst werden:

DOIF ([Schalter] eq "on" and [$SELF:frost] eq "on") (set heizung on) DOELSE (set heizung off)
attr do always
attr DOIF_Readings frost:([aussen:temperature] < 0 ? "on" : "off")


In der Version v0.25 (erster Post) triggern DOIF_Readings das eigene Modul nur, wenn sich deren Inhalt ändert.

Mit der Funktion PUP(<Name eines anderen DOIF>,<Icon@Farbe>) wird ein Link erzeugt, der die UI-Table eines anderen DOIF in einem Popup-Fenster aufruft, Beispiel siehe https://wiki.fhem.de/wiki/DOIF/uiTable#Anzeige_der_uiTable_anderer_DOIF_als_Popup-Fenster

muß ich gleich wieder fragen: funzt das auch am floorplan? wäre echt göttlich.

Probier's.

hmm, hab icg scheints noch generelle probleme.

0.25 doif rennt fehlerfrei.
hab dein wiki-bspl eingebaut.
passieren mag aber nix, siehe anhang. ich spühr die ersten krokodilstränen aufsteigen *snief*

muß ich noch was machen, oder reicht das reine vspl. im wiki aus?

aso ... unter web rennts

Wenn Du auf der DOIF-Seite alles richtig gemacht hast und im Floorplan nichts zusehen ist, dann unterstützt Floorplan die Anzeige der FW_detailFn wohl nicht.

Es weihnachtet. Es ist angedacht zu Nikolaus das neue Modul nach langer Testphase einzuchecken. Die Väter sollen zu Weihnachten etwas zum Basteln haben :)
Falls Unstimmigkeiten oder Probleme mit der neuen Version festgestellt wurden, dann bitte melden, ansonsten: der Eincheck-Countdown läuft  :)

Zitat von: the ratman am 29 November 2017, 18:03:08
hmm, hab icg scheints noch generelle probleme.

0.25 doif rennt fehlerfrei.
hab dein wiki-bspl eingebaut.
passieren mag aber nix, siehe anhang. ich spühr die ersten krokodilstränen aufsteigen *snief*

muß ich noch was machen, oder reicht das reine vspl. im wiki aus?

aso ... unter web rennts

Es gibt die Möglichkeit die UI-Tabelle über weblink einzubinden, als Workaround, s. https://wiki.fhem.de/wiki/DOIF/uiTable#Anzeige_einer_uiTable_.C3.BCber_weblink_als_Popup-Fenster

Aktuelle Version wurde eingecheckt und ist ab morgen per Update verfügbar.

Ich habe im ersten Post meinen Statusbildschirm aktualisiert. Diesen nutze ich inzwischen auf einem Wandtablet und meinem Smartphone als weitere WEB-Instanz ohne Logo, ohne Raumauswahlmenü und ohne Eingabezeile. Der Vorteil: einmalige Konfiguration/Pflege für mehrfache Nutzung auf verschiedenen Medien.

Basierend auf diesem Beitrag:  https://forum.fhem.de/index.php/topic,53286.msg449780.html#msg449780

kann man mit einer modifizierten clock.js, die hier als doifanaloguhr.js angehängt ist, die Bahnhofsuhr in uiTable einbinden.

Die Einbindung erfolgt in uiTable z.B. über
"<canvas id='doifanaloguhr' width='50' height='50'>error</canvas>"

doifanaloguhr.js und station-clock.js nach pgm2 kopieren und doifanaloguhr.js über JavaScripts in die FHEMWEB-Instanz einbinden.

station-clock.js gibt es dort: http://3quarks.com/de/Bahnhofsuhr/ , da  ist auch die Konfiguration beschrieben.

Bekomme ich dann die Zeit des Servers oder des Clients? Bei den bisherigen .js-Uhren bekomme ich immer die des Cliens, ich bräuchte aber die des Servers (ja, eigentlich sollten die synchron sein, sind sie bei mir aber leider nicht).

station-clock ist eine bisherige Uhr.

Eine Konfiguration - drei verschiedene Ausgabegeräte. Der Statusbildschirm wird auf einem Smartphone einspaltig ohne Plots dargestellt und ist ohne Zoomen bedienbar :)

Im Anhang ein Vergleichsfoto.

Statusbildschirm mit Anzeige aktueller Uhrzeit (Digital-Uhr) mit Datum im ersten Post aktualisiert.

Und hier die Anleitung zur Umsetzung von Zeit und Datum als Anregung für eigene Umsetzung:

defmod Time DOIF (1)
attr Time uiTable {\
$SHOWNODEVICELINE=".*";;\
}\
\
STY("<div class='doifclock'>error</div>","font-weight:bold;;font-size:18pt;;color:darkorange;;text-align:center;;");;

Und der Inhalt von doifclock.js in www/pgm2

function startTime() {
  var today = new Date();
  var h = today.getHours();
  var m = today.getMinutes();
  var d = today.getDate();
  var mo = today.getMonth()+1;
  var y = today.getFullYear();
  m = checkTime(m);
  $('.doifclock').each(function(){
    $(this).html(h + ":" + m + "&nbsp&nbsp" + d + "." + mo + "." + y);
  });
  var t = setTimeout(startTime,1000);
}
function checkTime(i) {
  if (i < 10) {i = "0" + i};  // add zero in front of numbers < 10
  return i;
}
startTime();

Dann noch doifclock.js in der Instanz von FHEMWEB per Attribut angeben:

attr <WEB> JavaScripts www/pgm2/doifclock.js

Da die Zeitaktualisierung auf der js-Seite läuft, wird FHEM mit der sekundlichen Aktualisierung nicht belastet.

Im Anhang das sichtbare Ergebnis.

Die Idee zur Umsetzung kam von Ellert.

Ich habe das Script etwas erweitert, damit sind zusätzliche Darstellungsweisen möglich, siehe https://wiki.fhem.de/wiki/DOIF/uiTable#Darstellung_von_Zeit_und_Datum

fehlt noch ein Widget für TabletUI damit man das ganze analog zu ReadingGroups dort anzeigen lassen kann:-)

Zitat von: StephanFHEM am 11 Dezember 2017, 21:12:33
fehlt noch ein Widget für TabletUI damit man das ganze analog zu ReadingGroups dort anzeigen lassen kann:-)

Sei so gut und fang schon mal damit an.

ZitatSei so gut und fang schon mal damit an

und glaub mir (unabhängig davon, dass ich den Wink mit der Holzhandlung verstanden habe): wenn ich es könnte würde ich es tun.
Leider reichen meine Kenntnisse dafür nicht aus. Es ist manchmal ganz schön blöd, wenn man selbst nicht die Fähigkeiten hat seine Ideen umzusetzen. Dafür haben alle, die hier ihr Know-how einsetzen und Module bereitstellen meinen tiefsten Respekt!

Ich denke, langfristig werden wir solche js-Erweiterungen sowie Templates für DOIF in contrib\doif ablegen, damit man nicht lange suchen muss.

TabletUI-Unterstützung ist übrigens aus DOIF wieder rausgeflogen. Es ist besser nur auf einer Hochzeit zu tanzen, dafür aber richtig ;)

Für TabletUI gibt es sicherlich eine Uhr mit Datum und noch viele andere Dinge.

Zitat von: StephanFHEM am 11 Dezember 2017, 21:26:04
und glaub mir (unabhängig davon, dass ich den Wink mit der Holzhandlung verstanden habe): wenn ich es könnte würde ich es tun.
Leider reichen meine Kenntnisse dafür nicht aus. Es ist manchmal ganz schön blöd, wenn man selbst nicht die Fähigkeiten hat seine Ideen umzusetzen. Dafür haben alle, die hier ihr Know-how einsetzen und Module bereitstellen meinen tiefsten Respekt!

Wo ein Wille ist ...

Du könntest probieren stateFormat in einem DOIF mit uiTable zu setzen und das dann mit dem Readingsgroup-Widget in Tablet-UI einzubinden.

attr <doifname> stateFormat {DOIF_RegisterEvalAll($defs{<doifname>},"<doifname>","uiTable")}

<doifname> ist durch den tatsächlichen Namen zu ersetzen.

Hallo,

ich bin gerade dabei, mir mit den Beispielen aus dem Wiki ein bisschen die uiTable zu erarbeiten - super Sache!

Aus dem Link-Beispiel wollte ich mir unter Verwendung von Templates eine Liste meiner Raumlinks bauen. Ohne Templates hat's funktioniert, mit Templates stimmt aber irgendwie die CSS-Formatierung nicht. Hier mein Attribut uiTable:

{
  $TD{0}{0..20}="style='position:relative'";
}

DEF TPL_Link("<a target='_self' href='$FW_ME?room=".$1."' title='".$1."'>".FW_makeImage("".$2."\@lightblue")."<div style='position:absolute; left:0px; top:40px; font-size:12px; background-color:lightblue; color:darkred'>".$1."</div></a>");

TPL_Link("Esszimmer","scene_dinner")|TPL_Link("Buero","scene_dinner")

Wo könnte mein Fehler liegen?

Vielen Dank (auch für eure tolle Arbeit!)
Ronny

Wie sah die funktionierende Definition ohne Templates aus?

Du kannst bei Templates ohne Anführungszeichen arbeiten, das macht die Sache einfacher und damit weniger fehleranfällig:

DEF TPL_Link("<a target='_self' href='$FW_ME?room=$1' title='$1'>".FW_makeImage("$2\@lightblue")."<div style='position:absolute; left:0px; top:40px; font-size:12px; background-color:lightblue; color:darkred'>$1</div></a>");

TPL_Link(Esszimmer,scene_dinner)|TPL_Link(Buero,scene_dinner)

Habe den Fehler scheinbar gefunden: anders als im Wiki funktioniert es bei mir, wenn ich das ; am Ende der DEF TPL_Link-Zeile weglasse...

Zitat von: RoBra81 am 13 Dezember 2017, 20:33:13
Habe den Fehler scheinbar gefunden: anders als im Wiki funktioniert es bei mir, wenn ich das ; am Ende der DEF TPL_Link-Zeile weglasse...

An dieser Stelle ist Semikolon auch fehl am Platz. Die werden nur im Perlbereich angegeben.

Guten Morgen,

ich bin am nächsten Wiki-Beispiel angekommen und meine Begeisterung steigt. Nun wollte ich mir einen Grundriss meiner Wohnung anlegen - was soweit funktioniert hat - und statt auf $SELF auf ein anderes Device triggern - woran es gerade scheitert:

defmod Grundriss_Labor DOIF (1)
attr Grundriss_Labor group Labor: uiTable
attr Grundriss_Labor room DOIF_Test
attr Grundriss_Labor uiTable {\
  $ATTRIBUTESFIRST = 1;;\
  $TABLE = "font-size:10pt;;text-align:center;;position:relative;;width:1200px;; height:600px;; background-image:url($FW_ME/images/default/wohnung/OG.svg);; background-size: 1200px 600px;;";;\
  $TR{1,3} = "class=''";;\
  $TPL{switch}="iconSwitch,on,off,off,on";;\
}\
\
DEF TPL_Objekt("<div style='position:absolute;;;; Left:".$1."px;;;; top:".$2."px;;;;'>".$3.WID($4,$TPL{switch})."</div>")\
\
TPL_Objekt("35","25","Schlafen<br>",[$SELF:SZ])|\
TPL_Objekt("145","25","Küche<br>","[Dunkel:state]")|\
TPL_Objekt("225","25","Bad<br>",[$SELF:Bad])|\
TPL_Objekt("145","105","Diele ",[$SELF:Diele])|\
TPL_Objekt("35","160","Wohnen A<br>",[$SELF:WZ1])|\
TPL_Objekt("35","220","Wohnen B<br>",[$SELF:WZ2])|\
TPL_Objekt("145","160","Kind<br>",[$SELF:Ki])|\
TPL_Objekt("145","250","Balkon<br>",[$SELF:Balkon])

setstate Grundriss_Labor initialized
setstate Grundriss_Labor 2017-12-14 09:21:50 Bad off
setstate Grundriss_Labor 2017-12-14 09:21:34 SZ on
setstate Grundriss_Labor 2017-12-14 08:53:02 cmd 0
setstate Grundriss_Labor 2017-12-14 08:53:02 state initialized



Bei "Dunkel" handel es sich um einen S7-Ausgang, welcher die States on und off annehmen kann (habe es auch schon mit einem Homematic-Device probiert). Mit dem oben angegebenen Code wird bei der Küche kein Symbol angezeigt. Wenn ich nun in einem zweiten Browserfenster das Device "Dunkel" schalte, erscheint dort und im Fenster des DOIFs die Fehlermeldungen

fhem?detail=Dunkel line 1:
Uncaught SyntaxError: missing ) after argument list

bzw.

fhem?detail=Grundriss_Labor# line 1:
Uncaught SyntaxError: missing ) after argument list

Wo könnte hier mein Fehler liegen?

Vielen Dank
Ronny

Ich würde meinen Tipp beherzigen, dann hast du weniger Fehler:

ZitatDu kannst bei Templates ohne Anführungszeichen arbeiten, das macht die Sache einfacher und damit weniger fehleranfällig.

Ich habe als Grundlage die Wiki-Beispiele kopiert und da steht es so...
Ich kann es aber gern in meinem Code mal testweise ändern...

Gesendet von meinem SM-G935F mit Tapatalk

Sorry, genau bei dem waren natürlich im Wiki auch keine Leerzeichen [emoji1]

Gesendet von meinem SM-G935F mit Tapatalk

Guten Abend,

gibt es eine Möglichkeit, die Position des Popups festzulegen?

Ronny

Ich möchte eine URL aus einem Reading in einem uiTable als HTML-Link anzeigen.

Versucht habe ich schon die Template und Funktions Variante.


{
  sub FUNC_Link
  {
  my($url) = @_;
  return ("<a target='_blank' href=". $url . ">".FW_makeImage("it_internet")."</a>");
  }
}

DEF TPL_Link ("<a target='_blank' href=$1>".FW_makeImage("it_internet")."</a>")

## RSS_MyDealz
[RSS_MyDealz:n01_title]|Func_Link([RSS_MyDealz:n01_link])
[RSS_MyDealz:n02_title]|TPL_Link([RSS_MyDealz:n02_link])


Wobei in dem Reading folgendes steht:
2017-12-17 14:27:04   n01_link        https://www.mydealz.de/deals/118-pubg-playerunknowns-battlegrounds-gratis-beim-kauf-einer-xbox-one-x-1097339

Beide Ansätze funktionieren leider nicht.

Kann mir jemand einen Tipp geben?

Ludger

Zitat von: LuBeDa am 17 Dezember 2017, 15:23:30
Ich möchte eine URL aus einem Reading in einem uiTable als HTML-Link anzeigen.

Versucht habe ich schon die Template und Funktions Variante.

Code Auswählen Erweitern


{
  sub FUNC_Link
  {
  my($url) = @_;
  return ("<a target='_blank' href=". $url . ">".FW_makeImage("it_internet")."</a>");
  }
}

DEF TPL_Link ("<a target='_blank' href=$1>".FW_makeImage("it_internet")."</a>")

## RSS_MyDealz
[RSS_MyDealz:n01_title]|Func_Link([RSS_MyDealz:n01_link])
[RSS_MyDealz:n02_title]|TPL_Link([RSS_MyDealz:n02_link])


Wobei in dem Reading folgendes steht:

Code Auswählen Erweitern

2017-12-17 14:27:04   n01_link        https://www.mydealz.de/deals/118-pubg-playerunknowns-battlegrounds-gratis-beim-kauf-einer-xbox-one-x-1097339

Beide Ansätze funktionieren leider nicht.

Ich habe TPL_Link mit dem Link über einen Dummy bei mir ausprobiert  - es funktioniert wie erwartet.

Zitat von: RoBra81 am 15 Dezember 2017, 20:36:41
Guten Abend,

gibt es eine Möglichkeit, die Position des Popups festzulegen?

Ronny

Pupup in ein div-Tag einpacken und absolute Position definieren - sollte gehen.

Zitat von: Damian am 17 Dezember 2017, 16:11:08
Ich habe TPL_Link mit dem Link über einen Dummy bei mir ausprobiert  - es funktioniert wie erwartet.

Bei mir erzeugt er das:
<a target="_blank" href="ReadingValDoIf(HASH(0x6c8e340),'RSS_MyDealz','n01_link')"><svg class=>....</svg></a>

Aber wenn ich nur das Reading anzeige ist alles richtig.

Zitat von: LuBeDa am 17 Dezember 2017, 17:11:16
Bei mir erzeugt er das:

Code Auswählen Erweitern

<a target="_blank" href="ReadingValDoIf(HASH(0x6c8e340),'RSS_MyDealz','n01_link')"><svg class=>....</svg></a>

Aber wenn ich nur das Reading anzeige ist alles richtig.

Du hast Recht. Ich habe wohl TPL_Link mit einem festen String getestet, was aber geht ist


{
sub FUNC_Link
{
  my($url) = @_;
  return ("<a target='_blank' href=". $url . ">".FW_makeImage("it_internet")."</a>");
}
}

"Test:" | FUNC_Link([test_d:state])

Zitat von: RoBra81 am 15 Dezember 2017, 20:36:41
Guten Abend,

gibt es eine Möglichkeit, die Position des Popups festzulegen?

Ronny

Ist nicht vorgesehen, nur wenn Du es selbst progammierst. uiTable verwendet FW_okDialog aus fhemweb.js.

Hallo Ihrs,

erstmal wollte ich mich bedanken - für uiTable und für Doif im allgemeinen - ich mache relativ viel mit Doif, weil ich so einfacher und (für mich) logischer zum Erfolg komme.

Hab da aber auch noch eine kleine Frage:

Ich wollte per Slider das Attribut wait ändern, das scheint aber nicht zu funktionieren

"Ausschaltzeit"|WID([$SELF:?wait],"slider,100,50,600,1")

Wo könnte ich evtl einen Fehler haben?

defmod doif.Sonos_Wohnzimmer DOIF ([Sonos_Wohnzimmer:transportState]  =~ "PAUSED_PLAYBACK|STOPPED" and\
[$SELF:aktiviert] eq "An")\
\
(set HM_Steckdose_Wohnzimmer_1 off)
attr doif.Sonos_Wohnzimmer alias Sonos automatisch abschalten
attr doif.Sonos_Wohnzimmer room iPhone,Programme,Wohnzimmer
attr doif.Sonos_Wohnzimmer stateFormat [HM_Steckdose_Wohnzimmer_1:state]
attr doif.Sonos_Wohnzimmer uiTable "Sonos anschalten"|WID([HM_Steckdose_Wohnzimmer_1:state],"uzsuToggle,An,Aus")\
"Aus im Leerlauf"|WID([$SELF:aktiviert],"uzsuToggle,An,Aus")\
"Ausschaltzeit"|WID([$SELF:?wait],"slider,100,50,600,1")
attr doif.Sonos_Wohnzimmer wait 600

setstate doif.Sonos_Wohnzimmer An
setstate doif.Sonos_Wohnzimmer 2017-12-21 12:27:40 aktiviert An
setstate doif.Sonos_Wohnzimmer 2017-12-21 12:29:35 cmd 0
setstate doif.Sonos_Wohnzimmer 2017-12-21 12:29:35 state initialized



Wie kommst du auf das Fragezeichen bei wait?


"Ausschaltzeit"|WID([$SELF:wait],"slider,100,50,600,1")

funktioniert bei mir ohne Probleme

Zitat von: Damian am 21 Dezember 2017, 12:44:37
Wie kommst du auf das Fragezeichen bei wait?

Code Auswählen Erweitern



"Ausschaltzeit"|WID([$SELF:wait],"slider,100,50,600,1")

funktioniert bei mir ohne Probleme

Sorry - da hatte ich nen Knoten im Hirn - du hattest natürlich Recht und ich meine mich erinnern zu können, das es auch bei mir ging. Das Fragezeichen ist irgendwie mit aus der readingsGroup Doku mir im Hirn hängengeblieben - dort wird das ? mit Attribute unterstützt. Deswegen war mir der Fehler nicht sofort aufgefallen  ::) :o :o :o

Edit: Mir ist noch was eingefallen - wie übergebe ich denn einen berechneten Wert? Im Slider möchte ich Minuten eingeben und an wait in Sekunden übergebem

Zitat von: Kai-Alfonso am 21 Dezember 2017, 12:32:35
Hallo Ihrs,

erstmal wollte ich mich bedanken - für uiTable und für Doif im allgemeinen - ich mache relativ viel mit Doif, weil ich so einfacher und (für mich) logischer zum Erfolg komme.

Hab da aber auch noch eine kleine Frage:

Ich wollte per Slider das Attribut wait ändern, das scheint aber nicht zu funktionieren

Code Auswählen Erweitern

"Ausschaltzeit"|WID([$SELF:?wait],"slider,100,50,600,1")

Wo könnte ich evtl einen Fehler haben?

Code Auswählen Erweitern

defmod doif.Sonos_Wohnzimmer DOIF ([Sonos_Wohnzimmer:transportState]  =~ "PAUSED_PLAYBACK|STOPPED" and\
[$SELF:aktiviert] eq "An")\
\
(set HM_Steckdose_Wohnzimmer_1 off)
attr doif.Sonos_Wohnzimmer alias Sonos automatisch abschalten
attr doif.Sonos_Wohnzimmer room iPhone,Programme,Wohnzimmer
attr doif.Sonos_Wohnzimmer stateFormat [HM_Steckdose_Wohnzimmer_1:state]
attr doif.Sonos_Wohnzimmer uiTable "Sonos anschalten"|WID([HM_Steckdose_Wohnzimmer_1:state],"uzsuToggle,An,Aus")\
"Aus im Leerlauf"|WID([$SELF:aktiviert],"uzsuToggle,An,Aus")\
"Ausschaltzeit"|WID([$SELF:?wait],"slider,100,50,600,1")
attr doif.Sonos_Wohnzimmer wait 600

setstate doif.Sonos_Wohnzimmer An
setstate doif.Sonos_Wohnzimmer 2017-12-21 12:27:40 aktiviert An
setstate doif.Sonos_Wohnzimmer 2017-12-21 12:29:35 cmd 0
setstate doif.Sonos_Wohnzimmer 2017-12-21 12:29:35 state initialized



Du musst den Befehl mit setzen:
WID([$SELF:wait],"10,20,30","attr")

Zitat von: Kai-Alfonso am 21 Dezember 2017, 12:59:08
Sorry - da hatte ich nen Knoten im Hirn - du hattest natürlich Recht und ich meine mich erinnern zu können, das es auch bei mir ging. Das Fragezeichen ist irgendwie mit aus der readingsGroup Doku mir im Hirn hängengeblieben - dort wird das ? mit Attribute unterstützt. Deswegen war mir der Fehler nicht sofort aufgefallen  ::) :o :o :o

Edit: Mir ist noch was eingefallen - wie übergebe ich denn einen berechneten Wert? Im Slider möchte ich Minuten eingeben und an wait in Sekunden übergebem

Mit "Ausschaltzeit"|WID([$SELF:wait],"slider,100,50,600,1")
wird nur ein Reading gesetzt, damit kannst du aber das Attribut berechnen

attr wait [$SELF:wait]*60

Zitat von: Damian am 21 Dezember 2017, 13:30:48
Mit

Code Auswählen Erweitern

"Ausschaltzeit"|WID([$SELF:wait],"slider,100,50,600,1")
wird nur ein Reading gesetzt, damit kannst du aber das Attribut berechnen

Code Auswählen Erweitern

attr wait [$SELF:wait]*60

Sorry, aber "Ausschaltzeit"|WID([$SELF:wait],"slider,100,50,600,1") setzt bei mir Reading und Attribut und überschreibt natürlich bei einer Änderung den Inhalt von wait [$SELF:wait]*60

sorry, nach dem Reload des Devices steht da wieder [$SELF:wait]*60 - also geht es - nur beim Ändern des Sliders erscheint da kurzfristig der Wert- Also alles gut und Danke

Mal doof gefragt: sollte das DOIF_Reading im Web-Frontend sichtbar sein? Anlegen über die Attr-Auswahl kann ich es, sehen leider nicht.

Zitat von: Per am 29 Dezember 2017, 10:22:41
Mal doof gefragt: sollte das DOIF_Reading im Web-Frontend sichtbar sein? Anlegen über die Attr-Auswahl kann ich es, sehen leider nicht.

DOIF_Readings erzeugen keine Events, daher werden sie nicht im Browser aktualisiert. Sobald ein Reading aufgrund seiner Definition erzeugt wird, wird es auch dargestellt, allerdings muss man dafür den Browser z. B. per F5 aktualisieren.

Zitat von: Damian am 29 Dezember 2017, 11:29:26
DOIF_Readings erzeugen keine Events

Sicher? Zwar muss ich nach der Neuanlage einmalig aktualisieren, dann werden sie aber rot hervorgehoben und auch im Eveltlog angezeigt.

Was ich nicht hinbekomme, ist das Rechnen innerhalb des DOIF-Readings:
attr myDOIF wind-speed:([#average:d0:"wetter_BW8":windSpeed$]*1.609344)
ergibt 0 :(. Der Durchschnitt wird aber richtig berechnet.

Zitat von: Per am 31 Dezember 2017, 16:34:07
Sicher? Zwar muss ich nach der Neuanlage einmalig aktualisieren, dann werden sie aber rot hervorgehoben und auch im Eveltlog angezeigt.

Was ich nicht hinbekomme, ist das Rechnen innerhalb des DOIF-Readings:
attr myDOIF wind-speed:([#average:d0:"wetter_BW8":windSpeed$]*1.609344)
ergibt 0 :(. Der Durchschnitt wird aber richtig berechnet.

Regex bei Readings geht z. Zt. nicht.

Bei mir funktioniert das Multiplizieren und es werden keine Events erzeugt.

attr testui DOIF_Readings avertemp:[#average:d1:":temperature":temperature]*2

Zitat von: Damian am 31 Dezember 2017, 17:09:21
Regex bei Readings geht z. Zt. nicht.

Hat ne Weile gedauert, aber jetzt habe ich es begriffen. Ja, der Dollar war die Ursache, da hatte ich zwei Sachen gleichzeitig geändert  :-[

Zitat von: Damian am 31 Dezember 2017, 17:09:21und es werden keine Events erzeugt.

Mein DOIF ist
(["wetter_BW8"])
(mehr nicht). Vllt. ist das der Unterschied?!

Hallo,

Erst mal danke, für das Modul und die ständige Weiterentwicklung!

Finde das uiTable Attribut genial und habe jetzt mal ein paat meiner DOIFs damit erweitert.

Wollte nachdem ich jetzt das meiste in FHEM integriert habe endlich mit TabletUI anfangen.
Genau zum richtigen Zeitpunkt bin ich dann auf diesen Thread aufmerksam geworden und würde es jetzt am liebsten so umsetzen wie es Damian im ersten Post auf PC, Tablet und Smartphone umgesetzt hat lösen.

Eventuell bin ich zu blöd zu suchen, aber wie lässt sich das Logo + menü ausblenden? Geht dies auch über hiddenroom Attribut oder geht das nur durch editieren vom css?

Genial wäre ja eine bsp. config vom PC, Tablet, Smartphone Bild im ersten Post!  :)

Danke,
crispyduck

Zitat von: crispyduck am 31 Dezember 2017, 21:36:24
Hallo,

Erst mal danke, für das Modul und die ständige Weiterentwicklung!

Finde das uiTable Attribut genial und habe jetzt mal ein paat meiner DOIFs damit erweitert.

Wollte nachdem ich jetzt das meiste in FHEM integriert habe endlich mit TabletUI anfangen.
Genau zum richtigen Zeitpunkt bin ich dann auf diesen Thread aufmerksam geworden und würde es jetzt am liebsten so umsetzen wie es Damian im ersten Post auf PC, Tablet und Smartphone umgesetzt hat lösen.

Eventuell bin ich zu blöd zu suchen, aber wie lässt sich das Logo + menü ausblenden? Geht dies auch über hiddenroom Attribut oder geht das nur durch editieren vom css?

Genial wäre ja eine bsp. config vom PC, Tablet, Smartphone Bild im ersten Post!  :)

Danke,
crispyduck

Ich habe alle DOIF-Raw-Definitionen des Statusbildschirms sowie Darksmallscreenstyle.css für Tablet und Smartphone im ersten Post angehängt. Viel Spaß damit im neuen Jahr :)

Zitat von: Damian am 01 Januar 2018, 11:27:58
Ich habe alle DOIF-Raw-Definitionen des Statusbildschirms sowie Darksmallscreenstyle.css für Tablet und Smartphone im ersten Post angehängt. Viel Spaß damit im neuen Jahr :)

Danke! Schon runter geladen, muss ich mir gleich ansehen.  :D

Alles gute an Alle für 2018!

Lg, crispyduck

Zitat von: Per am 31 Dezember 2017, 19:14:00Mein DOIF ist

Code Auswählen Erweitern

(["wetter_BW8"])
(mehr nicht). Vllt. ist das der Unterschied?!

So, habe jetzt
(0)
und bekomme trotzdem Events!
Was ich gut finde!

Kann ich eigentlich auch die UZSU Widgets (https://forum.fhem.de/index.php/topic,32660.0.html) für UITable nutzen? Wie ist denn da die Syntax?

Zitat von: Kai-Alfonso am 08 Januar 2018, 14:15:07
Kann ich eigentlich auch die UZSU Widgets (https://forum.fhem.de/index.php/topic,32660.0.html) für UITable nutzen? Wie ist denn da die Syntax?

Man kann alle FHEMWEB-Widgets nutzen, die Parameter des Widgets sind die gleichen.
z. B.:

WID ([$SELF:switch],"uzsuToggle,off,on")  | WID ([$SELF:mode],"uzsuToggle,noboost,boost")

Ach cool - vielen Dank. Ich hab jetzt ziemlich viel auf doif umgestellt und mach jetzt für ein paar Sachen eine Gui. Wollte noch einmal danke sagen für doif. Ich weiß, das einige lieber notify,at + dummy nutzen. Aber so habe ich ein Device plus konfigurierbare Anzeige statt 3 Geräte  ;D

ich muss noch einmal nerven: irgendwie schein in einem doif das DateTimePicker Widget nur "inline" zu funktionieren. Bei einem dummy klickt man auf das Input Feld und der Picker erscheint - oder wenn er per Option inline dargestellt wird, dann auf klick aufs input Feld. Bei uitable scheint nur das Widget inline zu gehen. Kann das mal jemand verifizieren?

defmod doif.MicroServer DOIF (A)(B)
attr doif.MicroServer icon it_nas
attr doif.MicroServer room Dachgeschoß
attr doif.MicroServer setList state:datetime,timepicker:false
attr doif.MicroServer uiTable "Werktag"|WID ([$SELF:Werktag],"datetime,datepicker:false,timepicker:true,format:H:i,inline:false")\


setstate doif.MicroServer initialized
setstate doif.MicroServer 2018-01-09 12:44:16 Werktag 17:00
setstate doif.MicroServer 2018-01-08 13:48:31 cmd 0
setstate doif.MicroServer 2018-01-08 13:48:31 state initialized


Bei mir funktioniert datetime-Picker mit inline:false und inline:true siehe Anhang

Zitat von: Kai-Alfonso am 09 Januar 2018, 12:46:51
ich muss noch einmal nerven: irgendwie schein in einem doif das DateTimePicker Widget nur "inline" zu funktionieren. Bei einem dummy klickt man auf das Input Feld und der Picker erscheint - oder wenn er per Option inline dargestellt wird, dann auf klick aufs input Feld. Bei uitable scheint nur das Widget inline zu gehen. Kann das mal jemand verifizieren?

Code Auswählen Erweitern

defmod doif.MicroServer DOIF (A)(B)
attr doif.MicroServer icon it_nas
attr doif.MicroServer room Dachgeschoß
attr doif.MicroServer setList state:datetime,timepicker:false
attr doif.MicroServer uiTable "Werktag"|WID ([$SELF:Werktag],"datetime,datepicker:false,timepicker:true,format:H:i,inline:false")\


setstate doif.MicroServer initialized
setstate doif.MicroServer 2018-01-09 12:44:16 Werktag 17:00
setstate doif.MicroServer 2018-01-08 13:48:31 cmd 0
setstate doif.MicroServer 2018-01-08 13:48:31 state initialized


Könnte an der Format-Option liegen, nimm sie raus oder stell sie ans Ende.

Zitat von: Ellert am 09 Januar 2018, 16:44:20
Könnte an der Format-Option liegen, nimm sie raus oder stell sie ans Ende.

ich habe uitable mal wie folgt geändert:

"Werktag"|WID ([$SELF:Werktag_Start],"datetime,inline:false")|WID ([$SELF:Werktag_Shutdown],"datetime,inline:false")
"Wochenende"|WID ([$SELF:Wochenende_Start],"datetime,inline:false")|WID ([$SELF:Wochenende_Shutdown],"datetime,inline:false")

Er zeigt mir in den Feldern die Werte für die Readings an, ich kann aber durch klick auf das Input Feld nicht den Kalender hervorholen.

Wenn ich den Aufruf wie folgt änder:

"Werktag"|WID ([$SELF:Werktag_Start],"datetime,inline:true")|WID ([$SELF:Werktag_Shutdown],"datetime,inline:true")
"Wochenende"|WID ([$SELF:Wochenende_Start],"datetime,inline:true")|WID ([$SELF:Wochenende_Shutdown],"datetime,inline:true")

zeigt er die Kalender inline an und er ändert entsprechend die Readings.

Hmmm....

Achja, als Dummy funktioniert es wie beschrieben

Ich kann den Fehler nicht nachstellen, wie bei Damian funktioniert inline true/false bei mir auch, wie es soll.

Zitat von: Ellert am 09 Januar 2018, 17:30:30
Ich kann den Fehler nicht nachstellen, wie bei Damian funktioniert inline true/false bei mir auch, wie es soll.

Hab schon vermutet, das es irgendwie bei mir liegt - hast Du mal die raw definitions eines funktionierenden Test-Device?

Habs hier mit eingebaut:
defmod swapValues_Labor DOIF (1) ## HMsensor_Labor HMdummy_Labor
attr swapValues_Labor group Labor: uiTable
attr swapValues_Labor room DOIF_Labor,DOIFalone
attr swapValues_Labor uiTable "<div class='humchange' >".STY([HMdummy_Labor:level],"font-size:16pt;;font-weight:bold;;color:red;;")." relH%</div>\
<div class='tempchange' >".STY([$SELF:temperature:d1],"font-size:16pt;;font-weight:bold;;color:blue;;")."°C</div>"\
WID([$SELF:datim1],"datetime,theme:default,step:5,inline:false")

setstate swapValues_Labor 2018-01-09 16:40:59 datim1 10.01.2018 16:37
setstate swapValues_Labor 2018-01-03 19:04:51 temperature 20.7



Danke Ellert,

das funktioniert bei mir auch - also liegt das Problem irgendwo bei mir. Vielen Dank

So, ich konnte meinen Fehler nachstellen. Scheint ein Bug (?) zu sein.

Ich habe meine doifs immer so benannt: doif.Funktion - anscheinend kommt da irgendwie der Punk im Namen in die Quere. Benenne ich das doif um nach Funktion, dann geht es - ändere ich den Namen wieder zurück auf doif.Funktion, dann geht es nicht.

Achja, und damit $SELF nach der Umbenennung greift, muss man einmal uitable in codemirror öffnen und wieder schließen bzw einmal das Attribut neu schreiben lassen.

Edit: Bindestrich macht keine Probleme

Zur Namensgebung gibt es einen Hinweis im Wiki https://wiki.fhem.de/wiki/Ger%C3%A4tename#Restriktionen

Den Hinweis kannte ich noch nicht und da ich bis jetzt keine Probleme hatte, hab ich mir da auch noch keinen Kopf drum gemacht. Also dann kein Bug, sondern eher eine Überschreitung der Namenskonventionen ;-)

Ich pass dann mal alle Geräte bei mir an * :o :o :o

Zitat von: Ellert am 10 Januar 2018, 15:24:30
Zur Namensgebung gibt es einen Hinweis im Wiki https://wiki.fhem.de/wiki/Ger%C3%A4tename#Restriktionen

Im gleichen Artikel gibt's aber auch einen link auf einen Vorschlag zur Namenskonvention nach dem ich mich am Anfang (vor einigen Jahren) gerichtet habe und da werden Punkte als Trenner vorgeschlagen - wenn ich bei mir alles umbenennen müsste wäre das ein riesen Aufwand (wobei mich das oben genannte Problem zur Zeit nicht betrifft)

Ronny

Gesendet von meinem SM-G935F mit Tapatalk

Zitat von: Ellert am 10 Januar 2018, 15:24:30
Zur Namensgebung gibt es einen Hinweis im Wiki https://wiki.fhem.de/wiki/Ger%C3%A4tename#Restriktionen

Naja, das Wiki ist nicht bindend. Und die Duiskussion (https://forum.fhem.de/index.php/topic,72153.0.html) bezüglich Punkt im Namen wurde nie weiter geführt, daher ist es aktuell noch erlaubt. Ich nutze zB auch in vielen Namen einen Punkt und für Zugehörigkeiten einen Unterstrich.

Bei anderen Widgets ist das offenbar kein Problem.

So etwas:

WID([bla.bla:status],"iconSwitch,off,Icon_Fisch\@DarkOrange,on,Icon_Fisch")

funktioniert bei mir ohne Problem. bla.bla ist ein Dummy.

Das datetimepicker-Problem ist aber nicht DOIF spezifisch, der Punkt im Namen funktioniert auch beim Dummy nicht

Das funktioniert nicht:
defmod du.test dummy
attr du.test readingList datim1
attr du.test room 0_Test
attr du.test setList datim1:datetime,inline:false
attr du.test webCmd datim1

setstate du.test initialized
setstate du.test 2018-01-10 20:35:53 datim1 10.01.2018 20:21
setstate du.test 2018-01-10 20:26:00 state initialized



dies funktioniert:
defmod du_test dummy
attr du_test readingList datim1
attr du_test room 0_Test
attr du_test setList datim1:datetime,inline:false
attr du_test webCmd datim1

setstate du_test 2018-01-10 20:35:52 datim1 10.01.2018 20:31


Zitat von: Ellert am 10 Januar 2018, 20:37:26
Das datetimepicker-Problem ist aber nicht DOIF spezifisch, der Punkt im Namen funktioniert auch beim Dummy nicht

Das funktioniert nicht:

Code Auswählen Erweitern

defmod du.test dummy
attr du.test readingList datim1
attr du.test room 0_Test
attr du.test setList datim1:datetime,inline:false
attr du.test webCmd datim1

setstate du.test initialized
setstate du.test 2018-01-10 20:35:53 datim1 10.01.2018 20:21
setstate du.test 2018-01-10 20:26:00 state initialized



dies funktioniert:

Code Auswählen Erweitern

defmod du_test dummy
attr du_test readingList datim1
attr du_test room 0_Test
attr du_test setList datim1:datetime,inline:false
attr du_test webCmd datim1

setstate du_test 2018-01-10 20:35:52 datim1 10.01.2018 20:31


ja, das habe ich mir schon gedacht.

Nachdem man jetzt mit dem DOIF so tolle Visualisierungen bauen kann stellt sich mir die Frage, ob es eine einfache Möglichkeit gibt, eine FHEMWEB-Instanz zu gern, welche bei Aufruf über den Details-Link eines DOIF (oder eines Room-Links in dem lediglich das eine DOIF enthalten ist) lediglich die uiTable des DOIF seitenfüllend anzeigt?

Ronny

Gesendet von meinem SM-G935F mit Tapatalk

Zitat von: RoBra81 am 12 Januar 2018, 10:34:23
Nachdem man jetzt mit dem DOIF so tolle Visualisierungen bauen kann stellt sich mir die Frage, ob es eine einfache Möglichkeit gibt, eine FHEMWEB-Instanz zu gern, welche bei Aufruf über den Details-Link eines DOIF (oder eines Room-Links in dem lediglich das eine DOIF enthalten ist) lediglich die uiTable des DOIF seitenfüllend anzeigt?

Ronny

Gesendet von meinem SM-G935F mit Tapatalk

Schau Dir mal den ersten Beitrag an

Zitat von: Ellert am 12 Januar 2018, 10:52:27
Schau Dir mal den ersten Beitrag an

Vielen Dank,

das trifft schon fast meine Vorstellungen - jetzt muss ich nur noch die beiden Rahmen und den Gruppennamen loswerden...

Ronny

Ich habe mal als Anregung mit Hilfe des Abfallmoduls eine Visualisierung mit uiTable vorgenommen.

defmod di_Abfall DOIF (1)
attr di_Abfall DOIF_Readings min:min ([abfall:BioabfallnGelberSackTonne_days],[abfall:BioabfallnGelberSackTonnenGruenschnitt_days],[abfall:BioabfallnGelberSackTonnenWeihnachtsbaeume_days])
attr di_Abfall group Aktuell
attr di_Abfall room Status
attr di_Abfall uiTable {\
  $TC{0..4}="align='center'";;\
  sub FUNC_font {my ($value)=@_;; return ("font-weight:bold;;".($value <=1 ? "color:darkorange":"color:white"));;}\
}\
\
FW_makeImage("Abfalltonne-Recycling-Logo\@yellow")|FW_makeImage("Abfalltonne-Recycling-Logo\@blue")| FW_makeImage("Abfalltonne\@gray")|FW_makeImage("Abfalltonne\@green")|FW_makeImage("Gartenabfall\@green")\
STY ([$SELF:min],FUNC_font([$SELF:min]))|\
STY ([abfall:Altpapier_days],FUNC_font([abfall:Altpapier_days])) |\
STY ([abfall:Restmuell_days],FUNC_font([abfall:Restmuell_days]))|\
STY ([$SELF:min],FUNC_font([$SELF:min]))|\
STY ([abfall:BioabfallnGelberSackTonnenGruenschnitt_days],FUNC_font([abfall:BioabfallnGelberSackTonnenGruenschnitt_days]))

dazu wurde Googlecalender eingebunden mit :

defmod cal Calendar ical url https://calendar.google.com/calendar/ical/..../basic.ics

und das Abfallmodul definiert:

defmod abfall ABFALL cal

Im Anhang das dazugehörige Layout.

Mit Hilfe des neuen Features "Aggregation mit Regex für Readings" konnte ich die Abfallvisualisierung mit Hilfe von DOIF_Readings relativ einfach für meinen Abfallentsorger verallgemeinern:

defmod Abfall DOIF (1)
attr Abfall DOIF_Readings bio:[#min:"^abfall$":"Bioabfall.*_days$"], GelberSack:[#min:"^abfall$":"GelberSack.*_days$"], Gruenschnitt:[#min:"^abfall$":"Gruenschnitt.*_days$"]

attr Abfall uiTable {\
  $TC{0..4}="align='center'";;\
  $SHOWNOSTATE=1;;\
  sub FUNC_font  { my ($value)=@_;; return ("font-weight:bold;;".($value <=1 ? "color:darkorange":"color:white"));; }\
}\
\
FW_makeImage("Abfalltonne-Recycling-Logo\@yellow")|FW_makeImage("Abfalltonne-Recycling-Logo\@blue")| FW_makeImage("Abfalltonne\@gray")|FW_makeImage("Abfalltonne\@green")|FW_makeImage("Gartenabfall\@green")\
STY ([$SELF:bio],FUNC_font([$SELF:bio]))|\
STY ([abfall:Altpapier_days],FUNC_font([abfall:Altpapier_days])) |\
STY ([abfall:Restmuell_days],FUNC_font([abfall:Restmuell_days]))|\
STY ([$SELF:GelberSack],FUNC_font([$SELF:GelberSack]))|\
STY ([$SELF:Gruenschnitt],FUNC_font([$SELF:Gruenschnitt]))

Hi,

ich versuche grade Aufgrund des Beispiels mit dem selbstfärbenden Icons das für mich ein wenig nachzuvollziehen.  Allerdings habe ich über dem Icon jetzt eine Linie (die ist auch, wenn ich das Beispiel nutze)

Woher kommt die und wie werde ich die los?  :o :o :o

Template:

{

sub FUNC_helligkeit_hsv
{
   my ($lux)=@_;
   return (DOIF_hsv ($lux,0,4,0,60,80,90));
}

sub FUNC_lux
{
    my ($lux)=@_;
    return ("font-weight:bold;font-size:10pt;color:".FUNC_helligkeit_hsv($lux));
}
}

DEF TPL_helligkeit(FW_makeImage("message_light_intensity\@".FUNC_helligkeit_hsv($1)).STY($1." lux",FUNC_lux($1)))


uitable:

#import der Template-Datei
IMPORT ./uitable_templates/helligkeit.tpl

TPL_helligkeit([doif_HaustuerLicht:HELLIGKEIT])|"TEST"

Sieht dann aus wie im Screenshot1

Bei der uitable

[code]#import der Template-Datei
IMPORT ./uitable_templates/helligkeit.tpl

TPL_helligkeit([doif_HaustuerLicht:HELLIGKEIT])."TEST"

verschwindet der Text "Test" ganz  - woher kommt denn die Linie?

1. Deine Linie wird wohl vom Style kommen.
Mit Default-Style sieht es bei mir wie im Anhang aus.

2. Pro Zelle ist z. Zt. nur ein Template definierbar ohne Kombination mit anderen Elementen. Wenn du einen Text dranhängen willst, dann kann du den als weiteren Parameter im Template vorsehen und diesen dort dranhängen.

z. B.

TPL_helligkeit([doif_HaustuerLicht:HELLIGKEIT],"TEST")

Danke für deine Erklärung - muss dann wohl vom Style (ios7)  kommen - obwohl er bei anderen doif uitable Elementen keine Probleme hat. Naja, werde ich mal den Chrome Webinspektor anwerfen.

Zitat von: Damian am 19 Januar 2018, 16:02:20


2. Pro Zelle ist z. Zt. nur ein Template definierbar ohne Kombination mit anderen Elementen. Wenn du einen Text dranhängen willst, dann kann du den als weiteren Parameter im Template vorsehen und diesen dort dranhängen.

z. B.

Code Auswählen Erweitern

TPL_helligkeit([doif_HaustuerLicht:HELLIGKEIT],"TEST")

Sorry, das geht bei mir irgendwie nicht  - auch nicht mit default Style

Zitat von: Kai-Alfonso am 19 Januar 2018, 19:38:25
Sorry, das geht bei mir irgendwie nicht  - auch nicht mit default Style

Du musst natürlich dafür dein Template umdefinierten. Wie hast du das gemacht?

ich hab mich an deinem Beispiel gehalten

{

sub FUNC_helligkeit_hsv
{
   my ($lux)=@_;
   return (DOIF_hsv ($lux,0,200,30,60,81,79));
}

sub FUNC_lux
{
    my ($lux)=@_;
    return ("font-weight:bold;font-size:10pt;color:".FUNC_helligkeit_hsv($lux));
}
}

DEF TPL_helligkeit(FW_makeImage("message_light_intensity\@".FUNC_helligkeit_hsv($1)).STY($1." lux",FUNC_lux($1)))



Ich hab noch eine Frage

Bei deinem Beispiel:

#import der Template-Datei
IMPORT ./contrib/DOIF/solar.tpl

#Tabellendefinition
TPL_solar([test_d:state:d1])

wofür steht das d1?

Zitat von: Kai-Alfonso am 19 Januar 2018, 22:29:40
ich hab mich an deinem Beispiel gehalten
...
DEF TPL_helligkeit(FW_makeImage("message_light_intensity\@".FUNC_helligkeit_hsv($1)).STY($1." lux",FUNC_lux($1)))
[/code]

Ich hab noch eine Frage

Bei deinem Beispiel:
...
TPL_solar([test_d:state:d1])[/code]

wofür steht das d1?

ja, wenn du den zweiten Parameter nicht definiert hast, dann kann auch nichts funktionieren.

z. B.

DEF TPL_helligkeit(FW_makeImage("message_light_intensity\@".FUNC_helligkeit_hsv($1)).STY($1." lux",FUNC_lux($1)).$2)


d1 ist hier erklärt: https://fhem.de/commandref_DE.html#DOIF_Filtern_nach_Zahlen

Zitat von: Damian am 19 Januar 2018, 22:48:10
ja, wenn du den zweiten Parameter nicht definiert hast, dann kann auch nichts funktionieren.

z. B.

Code Auswählen Erweitern

DEF TPL_helligkeit(FW_makeImage("message_light_intensity\@".FUNC_helligkeit_hsv($1)).STY($1." lux",FUNC_lux($1)).$2)


d1 ist hier erklärt: https://fhem.de/commandref_DE.html#DOIF_Filtern_nach_Zahlen

Alles klar - jetzt habe ich es verstanden - vielen Dank für die Erklärung

Hallo zusammen,

kann man mit DOIF_Readings auch eigene Timer definieren? Habe es gerade damit versucht
startTime:([ZS_zs_UW_AstroDaten:SunSet_myWeather]+int(rand(900)))

Wollte dann [[$SELF:startTime]] als Timer verwenden und erhalte daraufhin den Fehler, dass es sich nicht um das Format HH:MM:SS oder Perlcode handelt.

Beste Grüße
Torsten

Rechnen mit Zeiten kann man nur in der DOIF-Bedingung. Dort kannst du deine Rechnung allerdings direkt angeben. 

DOIF ([([ZS_zs_UW_AstroDaten:SunSet_myWeather]+rand(900))]) (....)

f18-Style mit uiTable - kein Problem, siehe Anhang

Hallo Damian,

es geht auch um die DOIF-Bedingung. Da ich im DOELSIF den gleichen Timer in Kombination mit einer anderen Bedingung verwende, dachte ich, mit DOIF_Readings liese sich das vereinfachen und übersichtlicher machen, zumal die rand Funktion natürlich in jedem Zweig eine andere Zahl zurückliefert, was ich eigentlich gar nicht brauche...

Aber ich verstehe Deine Antwort jetzt mal so, dass man mit DOIF_Readings keine "Uhrzeit" berechnen kann, die dann als Zeit für den Timer verwendet werden kann.

Danke für die Rückmeldung
Torsten

Zitat von: ToKa am 22 Januar 2018, 21:48:13
Hallo Damian,

es geht auch um die DOIF-Bedingung. Da ich im DOELSIF den gleichen Timer in Kombination mit einer anderen Bedingung verwende, dachte ich, mit DOIF_Readings liese sich das vereinfachen und übersichtlicher machen, zumal die rand Funktion natürlich in jedem Zweig eine andere Zahl zurückliefert, was ich eigentlich gar nicht brauche...

Aber ich verstehe Deine Antwort jetzt mal so, dass man mit DOIF_Readings keine "Uhrzeit" berechnen kann, die dann als Zeit für den Timer verwendet werden kann.

Danke für die Rückmeldung
Torsten

Kann man schon, allerdings muss man dann schon Perl bemühen.

Hallo Damian,

wie müsste das dann aussehen? Der Perl-Ausdruck in runden Klammern oder geschweiften Klammern? Kann dann das Triggern mit den eckigen Klammern trotzdem noch genutzt werden?

Sorry für die Nachfrage, aber ich bin kein Perl-Fachmann... und mit Zeiten rechnen klingt für mich kompliziert.

Gruß
Torsten

Zitat von: ToKa am 22 Januar 2018, 22:13:29
Hallo Damian,

wie müsste das dann aussehen? Der Perl-Ausdruck in runden Klammern oder geschweiften Klammern? Kann dann das Triggern mit den eckigen Klammern trotzdem noch genutzt werden?

Sorry für die Nachfrage, aber ich bin kein Perl-Fachmann... und mit Zeiten rechnen klingt für mich kompliziert.

Gruß
Torsten

Suche mal nach "time_str2num".

DOIF_Readings sind schon Perl, man braucht keine Klammern, DOIF-Angaben in eckigen Klammern triggern und können wie eine Perlfunktion überall eingesetzt werden.

DOIF_Readings <readingname>:<Perl mit [DOIF-Syntax in eckigen Klammern]>

Hallo,

Ich möchte zur Zeit bestimmte Attribute von vielen Devices bearbeiten und suche nach einer bequemen Möglichkeit hierfür. Natürlich kann ich mit regex arbeiten und die Attribute für mehrere Devices setzen, aber nicht alle sind gleich. Da ich viel mit copy und paste arbeite, habe ich oft mindestens zwei Seiten offen zwischen denen ich hin und her wechsele. Optimal wäre eine Tabelle mit den entsprechenden bearbeitbaren Attributen für einige bestimmte Devices. Und daher meine Frage: wäre eine Verwendung von uiTable für dieses Szenario denkbar?

Ronny

Gesendet von meinem SM-G935F mit Tapatalk

Du kannst Widgets an Attribute binden, siehe Antwort #88 und statt $SELF einen beliebigen Gerätenamen verwenden.

Ich habe es jetzt mal so probiert:

WID([OG.ez.HZ.Heizkoerperventil.Clima:T2F_rooms],"textField","attr")

Damit erscheint ein leeres Textfeld und wenn ich reinklicke, wird das Attribut T2F_rooms des Gerätes OG.ez.HZ.Heizkoerperventil.Clima auf 1 gesetzt?! Was muss ich noch machen, damit der Inhalt des Textfeldes korrekt initialisiert wird?

Ronny

Das Binden eines Widgets an ein Attribut ist eher ein Nebeneffekt, die Übernahme des vorhandenen Wertes scheint nicht zu funktionieren.

Da wirst Du uiTable zu dem von Dir gedachten Zweck nicht verwenden können.

Du könntest es über weblink und HTML versuchen. Dabei die Attibut-Schnittstelle von FHEMWEB nachbilden. Wie FHEMWEB  die Attributtabelle aufbaut kannst Du Dir in der Browser-Konsole ansehen, wenn Du Javascript ausschaltest und Dir die Detailseite ansiehst, siehe Beispiel.

Attributauswahl für uiTable

Als Baustein für uiTable habe ich die Funktion
FUNC_attrTable("<kommagetrennte Liste von Gerätenamen>")
erstellt, die für die angegebenen Geräte die Attributauswahl in die uiTable schreibt.
Der Code stammt grösstenteils aus 01_FHEMWEB.pm

Ein Beispiel als "Raw definition" ist angehängt.

Edit: Code bereinigt.

Hallo Damian,

habe schon einige DOIFs mit uiTable programmiert. Eine tolle Erweiterung!

Da ich in der KNX-Welt unterwegs bin, habe ich bei der Umsetzung Probleme. Bei KNX gibt es in der Regel zwei Readings (Gruppenadressen) für Schalten und Status.

Beispiel aus der commandref:
define lamp2 KNX 0/10/12:dpt1:steuern 0/10/13:dpt1.001:status

Nun möchte ich bei meinen Rollladen uiTable anwenden. Allerdings bringt mein DOIF immer den Fehler "invalid value. status-get".

define ui.di.Test DOIF (1)
attr ui.di.Test room Test
attr ui.di.Test uiTable {\
$SHOWNOSTATE=1;;\
$TPL{shutter}='iconRadio,@darkorange,0,fts_shutter_10,30,fts_shutter_30,50,fts_shutter_50,80,fts_shutter_80,100,fts_shutter_100';;\
}\
\
"Arbeiten"|WID([R106M:status-get],$TPL{shutter},"set")


Wie muss ich den set-Teil programmieren? Aus fhem würde der Befehl so lauten:
set R106M position 50

Viele Grüße
Jens

Versuch mal bei dem Fehler

Zitat,"set"

wegzulassen.

Und bei set R106M position 50

Zitat,"set"

verwenden.

Hallo Ellert,

vielen Dank!

Wenn ich das"set" aus dem uiTable weglasse, kommt die Fehlermeldung nicht mehr, allerdings fährt auch (weiterhin) der Rollladen nicht.

Der Befehl
set R106M position 50
fährt den Rollladen in die Position 50%. Es ist nur ein Beispiel für den Syntax bei KNX.

Hier noch das Device des Rolladens.
define R106M KNX 1/1/13:dpt5.001:position 1/4/13:dpt5.001:status

Was könnte ich noch testen?

Gruß Jens

Ich kenne KNX nicht, aber wenn Du die Position mitset R106M position 50 setzt, dann muss es ein Reading "position" geben, das auf den Wert 50 gesetzt wird. Wenn es diesen Readingsnamen nicht gibt, bekommt das Widget keine Rückmeldung, das könnte zu der Fehlermeldung führen.

WID([R106M:position],$TPL{shutter},"set") sollte richtig sein.

Hallo Ellert,

danke für deine Unterstützung!

Habe es jetzt mit
WID([R106M:position],$TPL{shutter},"set")

probiert. Aus fhem heraus kann man den Rollladen jetzt ansteueren, allerdings wird der Rollladen auch außerhalb von Fhem gesteuert. Dann fehlt natürlich die Rückmeldung. Diese kommt bei mir über status/status-get.

Bei KNX gibt es ein Reading zum senden von Befehlen (in meinem Fall "position") und ein Reading zum empfangen von Zuständen (in meinem Fall "status/status-get").

Für die Ansteuerung aus dem uiTable des DOIF müsste mit dem mit dem Drücken eines Buttons (z.B. 50) ein set Befehl abgesetzt werden. Nachdem der Rollladen in die entsprechende Position gefahren ist gibt er die über status-get zurück. Erst jetzt darf der entsprechende Button (in meinem  Fall) orange werden.

Vielleicht hast du ja noch einen Tipp.

Gruß Jens

Dann könntest Du Dir ein userReadings mit dem Namen position anlegen und dort den Inhalt von status/status-get duplizieren

Hallo Ellert,

habe es jetzt erst einmal mit cmdalias gelöst.

define ca.rollladen cmdalias set R.* status-get .* AS set $EVTPART0 position $EVTPART2

Hier wird das reading status-get in position "übersetzt".

Vielleicht gibt es ja doch noch eine Lösung im uiTable.  ;)

Danke erst einmal für deine Denkanstöße ... ;D

Gruß Jens

Es ist auch möglich SVG-Plots in die uiTable einzubinden, mit
SVG_FwFn(<Name der FHEMWEB-Instanz>,"<Name des SVG>","",$pageHash)
Beispiel
my $pH = {}; SVG_FwFn("WEB","SVG_LuxMeter_1","",$pH)
die Zelle muss dann mehrspaltig formatiert werden, z.B.
$TD{9}{0} = "colspan='6'"

Zitat von: Ellert am 28 August 2018, 19:09:02
Es ist auch möglich SVG-Plots in die uiTable einzubinden, mit

Code Auswählen Erweitern

SVG_FwFn(<Name der FHEMWEB-Instanz>,"<Name des SVG>","",$pageHash)
Beispiel

Code Auswählen Erweitern

my $pH = {}; SVG_FwFn("WEB","SVG_LuxMeter_1","",$pH)
die Zelle muss dann mehrspaltig formatiert werden, z.B.

Code Auswählen Erweitern

$TD{9}{0} = "colspan='6'"

Das sieht gut aus, sogar mit Zoom-Icons und Namenslink, die vermisse ich nämlich in meinen gruppierten Plots.

Hi Damian, eine kurze Frage: Das Edit-Feld für UI-Tables ist bei mir immer kleiner als das modale Fenster, was aufgerufen wird (siehe Screenshot). Kann ich das beeinflussen?

lg
Christian

Das sind Mechanismen, die außerhalb von DOIF liegen.

Ich vermute, dass man die Größe von Code-Mirror irgendwo einstellen kann. Das sieht bei mir genauso aus :)

Dem Hinweis mit codemirrorParam bin ich nachgegangen und kann einen Typ geben:

{"height":"auto", "lineWrapping":true }

sorgt dafür, dass eine lange uiTable auch vollständig gezeigt wird im Editorfenster.
In diesem Fall beginnt das Fenster mit einer Zeile, aber mit jedem Return wird die Fläche genutzt.


Danke für den richtungsgebenden Hinweis

Christian

Zitat von: cwagner am 23 Oktober 2018, 22:35:49
Dem Hinweis mit codemirrorParam bin ich nachgegangen und kann einen Typ geben:

Code Auswählen Erweitern


{"height":"auto", "lineWrapping":true }

sorgt dafür, dass eine lange uiTable auch vollständig gezeigt wird im Editorfenster.
In diesem Fall beginnt das Fenster mit einer Zeile, aber mit jedem Return wird die Fläche genutzt.


Danke für den richtungsgebenden Hinweis

Christian

Na dann, weißt du schon mehr als ich :)

Hallo Damian,

Frage zu den DOIF_Readings: Ich habe ein DOIF mal umgestellt: Ein Powermeter wird ausgelesen, abhängig vom Wert "triggern" verschiedene DOIF_Readings. Das funktioniert prima, macht das DOIF an sich übersichtlicher. Was mir dabei aufgefallen ist: Das Powermeter-Reading, welches vorher im DOIF Teil stand und jetzt ausschließlich in der DOIF-Readings Definition, verschwindet aus der Liste "Probably associated with". Mir fehlt aber diese Angabe, das Reading/Device ist ja mit dem DOIF assoziiert. Ist es möglich das (irgendwann) noch einzubauen?

Vielen Dank schon mal; und auch für die geniale Modul!

Sany

Zitat von: Sany am 26 Oktober 2018, 22:00:15
Hallo Damian,

Frage zu den DOIF_Readings: Ich habe ein DOIF mal umgestellt: Ein Powermeter wird ausgelesen, abhängig vom Wert "triggern" verschiedene DOIF_Readings. Das funktioniert prima, macht das DOIF an sich übersichtlicher. Was mir dabei aufgefallen ist: Das Powermeter-Reading, welches vorher im DOIF Teil stand und jetzt ausschließlich in der DOIF-Readings Definition, verschwindet aus der Liste "Probably associated with". Mir fehlt aber diese Angabe, das Reading/Device ist ja mit dem DOIF assoziiert. Ist es möglich das (irgendwann) noch einzubauen?

Vielen Dank schon mal; und auch für die geniale Modul!

Sany

Leider habe ich da keinen Einfluss darauf, das ist ne Sache von FHEMWEB.

ZitatLeider habe ich da keinen Einfluss darauf, das ist ne Sache von FHEMWEB.

Alles klar. Habe aber einen funktionierenden Workaround entdeckt: einfach das Device:reading als Kommentar in die def reinschreiben, schon ist es wieder in der Liste.
## Device:reading

Gruß

Sany

Zitat von: Sany am 27 Oktober 2018, 13:59:47
Alles klar. Habe aber einen funktionierenden Workaround entdeckt: einfach das Device:reading als Kommentar in die def reinschreiben, schon ist es wieder in der Liste.

Code Auswählen Erweitern

## Device:reading

Gruß

Sany

Es reicht die Angabe des Gerätenamen.

Zitat von: cwagner am 23 Oktober 2018, 10:59:21
Hi Damian, eine kurze Frage: Das Edit-Feld für UI-Tables ist bei mir immer kleiner als das modale Fenster, was aufgerufen wird (siehe Screenshot). Kann ich das beeinflussen?

lg
Christian

Mit

Zitat{"height":"auto", "lineWrapping":true }

kann es trotzdem vorkommen, dass das Editorfenster breiter ist als das Dialogfenster, d.h. man muss nach rechts scrollen.
Dieses Verhalten tritt auf, weil das Dialogfenster in fhemweb.js auf 3/4 der Fensterbreite festgelegt wird.

Ich hatte hier versucht, das zu ändern: https://forum.fhem.de/index.php/topic,74992.0.html
Es hat sich niemand gemeldet, den es auch gestört hat, daher ist die Fensterbreite nicht einstellbar und auf 3/4 der Fensterbreite geblieben.

Insofern ist jeder Unterstützer wilkommen, der das im angegebenen Thread kund tut.

Man kann es auch selbst in der fhemweb.js ändern, bis zum nächsten Update.

In Zeile 1410, je nach Revision, den Faktor ändern.

Zitat{ modal:true, closeOnEscape:true, width:$(window).width()*3/4,

Vielen Dank, @Ellert, sobald ich wieder Zeit habe, werde ich das mal checken und gegebenenfalls mich Deiner "Petition" anschließen.

Christian

Zitat von: Ellert am 11 Dezember 2017, 20:53:39
Ich habe das Script etwas erweitert, damit sind zusätzliche Darstellungsweisen möglich, siehe https://wiki.fhem.de/wiki/DOIF/uiTable#Darstellung_von_Zeit_und_Datum

Sehr schönes Script - kann ich mir die Daten auch irgendwie in die UserReadings meines DOIFs oder eines Dummys importieren?

Zitat von: Pete37 am 18 Februar 2019, 01:11:38
Sehr schönes Script - kann ich mir die Daten auch irgendwie in die UserReadings meines DOIFs oder eines Dummys importieren?

Im Prinzip ja.
Welche Daten und mit welchem Ziel? Würdest Du das näher erläutern?

Zitat von: Ellert am 18 Februar 2019, 09:08:44
Im Prinzip ja.
Welche Daten und mit welchem Ziel? Würdest Du das näher erläutern?

Ja, klar: Ich suche immer noch nach einer eleganten und ressourcenschonenden Variante meine Uhrdarstellung im FLOORPLAN mit frischer Zeit zu füllen. Ich benutze Text für Datum und Uhrzeit und Graphikelemente für Wochentag und Sekunden. Ich kann also nicht so einfach die uiTable-Darstellung verwenden.

Dein Skript scheint keine sonderliche Belastung für mein Fhem darzustellen, obwohl es jede Sekunde aktualisiert. Das erscheint mir vielversprechend! Ich brauche eine Art Sekundenzeiger (derzeit bei mir im 3-Sekunden-Takt), als Lebenszähler und zur Anzeige, dass das System noch läuft und insbesondere die Displays nicht schon wieder stehen geblieben sind.

Alternativ experimentiere ich grad mit dem für mich neu entdeckten Perl-Modus der DOIFs rum, um ein Uhr-DOIF-Modul zu erstellen, was hoffentlich ähnlich ressourcenschonend ist.

Das Uhrenscript läuft im Browser, deshalb wird FHEM nicht belastet und nur dann, wenn  der Browser geöffnet ist, also nur wenn z.B. der Floorplan angezeigt wird.
Falls der Browser immer aktiv ist könnte man das ein Javascript schreiben, dass über FW_cmd alle 3 Sekunden mit einem setreading-Befehl ein Reading gesetzt wird, dann überwachst Du, ob das Script im Browser läuft, ob dadurch auch überwacht wird, dass die Anzeige nicht eingefroren ist, müsstest Du ausprobieren.
Im Florplan muss fhemweb.js und das Javascript geladen werden.
https://wiki.fhem.de/wiki/DevelopmentFHEMWEB-API#FW_cmd

Mit dem anliegenden Script hast Du einen Startpunkt und kannst testen, ob eine eingefrorene Anzeige auch das Script einfrieren lässt.

Du müsstest einen Dummy anlegen.
defmod device_alive dummy
devicealive.js in dem entsprechenden Floorplanordner speichern
Den Dummy in Floorplan einbinden.
Die Scripte devicealive.js und fhemweb.js in Floorplan einbinden, oder FW_cmd im Floorplan verfügbar machen.

Alternativ zu Floorplan zum Testen, devicealive.js in einer FHEMWEB-Instanz einbinden und devicealive.js vorher nach pgm2 kopieren.
attr WEB JavaScripts pgm2/devicealive.js
und den Dummy im Tablet anzeigen. Wenn die Anzeige einfriert und der Dummy nicht mehr alle 3 Sekunden aktualisiert, könntest Du dieses Prinzip als watchdog verwenden.

Interessant! Muss ich mir in Ruhe ansehen - danke schon mal!!

Ich bekomme Warnungen beim Auslösen von event_Readings

Zitat2019.04.28 16:29:03.022 1: PERL WARNING: Use of uninitialized value $dev in string eq at ./FHEM/98_DOIF.pm line 914, <GEN10> line 11.
2019.04.28 16:29:03.023 3: etvR: warning in event_Readings: test

Das kann ich nachstellen mit
defmod etvR DOIF {# bla}
attr etvR event_Readings test:{[bla:"x\d+"]?"on":"off"}

defmod bla dummy

setstate bla 2019-04-28 16:25:38 x123 999


Die erste Warnung erscheint einmal, die Zweite bei jedem Auslösen des Readings, z.B. mit dem Befehl
setreading bla x123 9

Zitat von: Ellert am 28 April 2019, 16:38:44
Ich bekomme Warnungen beim Auslösen von event_Readings
Das kann ich nachstellen mit

Code Auswählen Erweitern

defmod etvR DOIF {# bla}
attr etvR event_Readings test:{[bla:"x\d+"]?"on":"off"}

defmod bla dummy

setstate bla 2019-04-28 16:25:38 x123 999


Die erste Warnung erscheint einmal, die Zweite bei jedem Auslösen des Readings, z.B. mit dem Befehl

Code Auswählen Erweitern

setreading bla x123 9

Ich habe die aktuelle Version gepatcht.  Ich habe es in meinem produktiven System getestet. Teste es auch mal bei dir.

Zu bedenken ist, dass DOIF_Readings bzw. event_Readings, beim Definieren dieser Attribute schon ausgewertet werden, ebenso bei defmod des DOIF-Gerätes im laufenden Betrieb. In diesen Fällen gibt es natürlich keine FHEM-Events, die Abfrage ist nicht wahr, in deinem Beispiel wird dann das definiertes Reading "test" auf off gesetzt.

Sieht gut aus, bisher sind keine Warnungen aufgetaucht.

Zitat von: Ellert am 28 April 2019, 19:42:08
Sieht gut aus, bisher sind keine Warnungen aufgetaucht.

Ok. Ich lasse es bei mir im Live-System zur Sicherheit noch einen Tag laufen, bis ich es einchecke.

Neue korrigierte Version wurde eingecheckt.

Ich habe auch das Inhaltsverzeichnis im Perl-Modus mit Links überarbeitet:

ZitatInhaltsübersicht Perl-Modus

Eigene Funktionen - subs-Block
Eigene Funktionen mit Parametern
Eigener_Namensraum
Spezifische Perl-Funktionen im Perl-Modus:  fhem_set  set_Event  set_State  get_State  set_Reading  get_Reading  set_Reading_Update
Ausführungstimer:  set_Exec  get_Exec  del_Exec
Initialisierung - init-Block
Device-Variablen
Blockierende Funktionsaufrufe
Attribute im Perl-Modus
Anwendungsbeispiele im Perl-Modus

Ich habe die Möglichkeiten der Definition einer uiTable erweitert.

Es ist jetzt möglich mit gekapselten Perl-Funktionen für die Definition des Layouts zu arbeiten (eigenes package). Man ist nicht mehr an bestimmte Namensgebung von Funktionen (bisher FUNC_...) gebunden. Die Angabe der Funktion STY kann wegfallen. Die genutzte Perlfunktion für die formatierte Ausgabe kann ein oder zwei Elemente zurückgeben. Der erste Rückgabewert ist der anzuzeigender Wert selbst, der zweite optionale Wert ist das dazugehörige Style (wie bei STY).

Bsp: Farbige Anzeige von Temperatur und Feuchtigkeit mit Hilfe der importierten Perlfunktionen: temp(<temperatur>,<größe>) und hum(<feuchtigkeit>,<größe>)

defmod temperature DOIF ##
attr temperature uiTable {\
package $SELF;;\
$TC{0}="align='center'";;\
}\
\
## Hier werden die benötigten Perlfunktionen importiert\
IMPORT contrib/DOIF/temp_hum.tpl\
\
## Definition der ui-Tabelle\
temp([Aussensensor:temperature],36),hum([Aussensensor:humidity],18)\


Der Inhalt von temp_hum.tpl mit der Definition von temp und hum sieht so aus:

{
package $SELF;
sub temp
{
   my ($temp,$size)=@_;
   return(::FW_makeImage('temp_temperature').$temp."°C","font-weight:bold;font-size:".$size."pt;".temp_style($temp));
}

sub temp_style
{
     my ($temp)=@_;
     if ($temp >=30) {
   return ("color:".::DOIF_hsv ($temp,30,50,20,0,90,95));
     } elsif ($temp >= 10) {
       return ("color:".::DOIF_hsv ($temp,10,30,73,20,80,95)); 
} elsif ($temp >= 0) {
   return ("color:".::DOIF_hsv ($temp,0,10,211,73,60,95));
} elsif ($temp >= -20) {
   return ("color:".::DOIF_hsv ($temp,-20,0,277,211,50,95));
}
}

sub hum
{
    my ($hum,$size)=@_;
    return(::FW_makeImage('temperature_humidity').$hum." %","font-weight:bold;font-size:".$size."pt;color:".::DOIF_hsv ($hum,30,100,30,260,60,90));
}
}


Die Farbgebung orientiert sich am Wert der Temperatur bzw. der Feuchtigkeit, als zweiter Übergabeparameter von temp und hum wird hier im Beispiel die Größe der Anzeige angegeben.

Im Anhang: Anzeige der obigen Definition, neue DOIF-Version zum Testen - sie ist abwärtskompatibel zur bisherigen,und die Definitionsdatei der beiden benutzten Funktionen temp und hum.

Edit: Version eingecheckt

Hier ein Beispiel wie man mit der neuen DOIF-Version die Definition einer farbig anpassbaren Feuchtigkeitsanzeige vereinfachen kann:

bisher:

defmod humidity DOIF ##
attr humidity uiTable {\
sub FUNC_hum\
{\
    my ($hum)=@_;;\
    return ("font-weight:bold;;font-size:12pt;;color:".::DOIF_hsv ($hum,30,100,30,260,60,90));;\
}\
}\
## Anzeige der Feuchtigkeit\
\
STY([TH_DG_HM:humidity]." %",FUNC_hum([TH_DG_HM:humidity]))

Die Vereinfachung der Ausgabe könnte man ggf. nur über ein zusätzliches Template bewerkstelligen.

neu:

defmod humidity DOIF ##
attr humidity uiTable {\
package $SELF;;\
sub hum\
{\
    my ($hum)=@_;;\
    return ($hum." %","font-weight:bold;;font-size:12pt;;color:".::DOIF_hsv ($hum,30,100,30,260,60,90));;\
}\
}\
## Anzeige der Feuchtigkeit \
\
hum([TH_DG_HM:humidity])


Jetzt lässt sich die Ausgabe der formatierten Feuchtigkeit vereinfacht direkt mit Hilfe einer Perlfunktion angeben, hier mit hum(<Feuchtigkeit-Reading>)

Version v0.2 im Post #176 kann nun neben Styles (STY) auch Widgets (WID) über Perlfunktionen abbilden. Dadurch lässt sich die Definitionen von uiTable weiter vereinfachen. Der Einsteiger kann nun vordefinierte Perlfunktionen mit seinem Reading aufrufen, um bedienbare Elemente anzuzeigen. Das dürfte die Hemmschwelle der Nutzung von FHEM-Widgets in uiTable reduzieren.

In der angehängten Datei uiTable.tpl sind folgende Funktionen definiert:

hum (<reading>,<größe>)
temp (<reading>,<größe>)
knob (<reading>)
shutter (<reading>)
switch(<reading>,<icon>)
label (<reading>,<icon>);

Es handelt sich um reine Perlfunktionen ohne spezielle DOIF-Syntax. Sie lassen sich für eigene Bedürfnisse abändern bzw. erweitern. Sie werden über den IMPORT-Befehl importiert und sind innerhalb des benutzten DOIF-Devices in einem package gekapselt. Dadurch kann die Namensgebung der Funktionen kurz gehalten werden, da sie nicht mit anderen Perlfunktionen in FHEM kollidieren können.

Nutzung der obigen Perl-Funktionen in uiTable:

defmod uiTest DOIF ##
attr uiTest room Test
attr uiTest uiTable IMPORT contrib/DOIF/uiTable.tpl\
\
"Feuchtigkeit (dynamische Farbgebung)",hum([TH_DG_HM:humidity],14)\
"Temperatur (dynamische Farbgebung)",temp([TH_DG_HM:measured-temp],24)\
"Temperaturvorgabe (knob - schaltbar)",knob([TH_DG_HM:desired-temp])\
"R_Keller (shutter - schaltbar)",shutter([R_Keller:pct])\
"Aussenbeleuchtung (switch - schaltbar)",switch ([Aussenbeleuchtung],"light_wall_2")\
"Garage (label - nur Anzeige)",label([Garage],"fts_garage_door")\

Mit der neuen DOIF-Version lässt sich die Rollladensteuerung inkl. GUI (Zustand der Rollläden und manuelles Schalten) recht simpel erstellen. So sieht meine Version z. Zt. aus:

defmod DI_Rollladen DOIF (([Dunkelheit] eq "off" and [06:25-09:00|8]) or [09:00|7]) \
  ((set R_W_S,R_W_W[1-3] on))\
DOELSEIF ([Dunkelheit] eq "on")\
  ##((set R_W_S,R_W_W[1-3] off))
attr DI_Rollladen cmdState oben|unten
attr DI_Rollladen devStateIcon unten:status_night oben:scene_day
attr DI_Rollladen icon fts_shutter_automatic
attr DI_Rollladen uiTable IMPORT contrib/DOIF/uiTable.tpl\
\
"Dachgeschoss"|""\
"R_Dachboden"|shutter([R_Dachboden])\
"erstes Geschoss"|""\
"R_Bad"|shutter([R_Bad:pct])\
"R_Kinderzimmer1_O"|shutter([R_Kinderzimmer1_O:pct])\
"R_Kinderzimmer1_S"|shutter([R_Kinderzimmer1_S:pct])\
"R_Kinderzimmer2_S"|shutter ([R_Kinderzimmer2_S:pct])\
"R_Kinderzimmer2_W1"|shutter ([R_Kinderzimmer2_W1:pct])\
"R_Kinderzimmer2_W2"|shutter ([R_Kinderzimmer2_W2:pct])\
"Erdgeschoss"|""\
"R_Kueche"|shutter([R_Kueche:pct])\
"R_W_S"|shutter([R_W_S:pct])\
"R_W_W1"|shutter([R_W_W1:pct])\
"R_W_W2"|shutter ([R_W_W2:pct])\
"R_W_W3"|shutter ([R_W_W3:pct])\
"Keller"|""\
"R_Keller"|shutter ([R_Keller:pct])


Im Anhang das Ergebnis.

Die vorbereitete uiTable.tpl ist eine schöne Vereinfachung für die Benutzer von DOIF. Hier als Anregung eine verdichtete Anzeige meiner Raumregler, der die Farbgebung nutzt für eine schnelle Info. Abweichend verwende ich den HKnob aus dem FTUI-Projekt.

Beisteuern könnte ich eine Anpassung für einen hochpräzisen CO2-Sensor, mit dem ich im Abluftstrom die notwendige Luftmenge unserer kontrollierten Gebäudelüftung steuere. Sie passt sich dann automatisch der Personenzahl an...

sub FUNC_CO2 {return ("font-weight:bold;font-size:11pt;color:".DOIF_hsv ($_[0],600,1000,122,0,60,90));

Christian

Ich arbeite bereits an weiteren Vereinfachungen. Es wird viele vereinfachte Funktionen bereits im DOIF geben, die man nur noch aufrufen muss, ohne sie importieren zu müssen.


Übrigens, die beschriebenen neuen uiTable-Features sind bereits in der eingecheckten Version drin.

Sehe ich es richtig, dass ich je DOIF im Attribut uiTable genau eine *.TPL importieren kann?

Die Idee war, Deine tpl unangetastet zu lassen und in einer eigenen zweiten TPL die eigenen Anpassungen oder Ergänzungen zu versammeln. Das fände ich praktisch sobald die uiTable.tpl ins SVN eingecheckt würde. Schließlich muss man ja bei einem solch ideenreichen Entwickler immer damit rechnen, dass er noch tolle Erweiterungen hinzufügt und könnte so die eigenen Gehversuche vor Überschreiben durch Updates schützen.

Christian

Zitat von: cwagner am 17 September 2019, 14:55:33
Sehe ich es richtig, dass ich je DOIF im Attribut uiTable genau eine *.TPL importieren kann?

Die Idee war, Deine tpl unangetastet zu lassen und in einer eigenen zweiten TPL die eigenen Anpassungen oder Ergänzungen zu versammeln. Das fände ich praktisch sobald die uiTable.tpl ins SVN eingecheckt würde. Schließlich muss man ja bei einem solch ideenreichen Entwickler immer damit rechnen, dass er noch tolle Erweiterungen hinzufügt und könnte so die eigenen Gehversuche vor Überschreiben durch Updates schützen.

Christian

Es ist möglich auch mehrere TPL-Files zu importieren. Man kann auch in einem TPL-File ein weiteres TPL-File importieren. Was aber in die nächste Version kommen wird, sind Funktionen, die sich jetzt noch im anhängten tpl-File befinden und zukünftig direkt im DOIF Modul verfügbar sein werden.

Mit der Möglichkeit komplexere Perlfunktionen in uiTable zu nutzen, möchte ich einen Pool von allgemein gültigen Funktionen im DOIF bereitstellen, die in der Commandref sauber dokumentiert sind und ohne TPL-Import nutzbar sein werden.

Diese Funktionen werden im package DOIF_uiTable verfügbar sein. Man muss dann im Attribut uiTable nur noch am Anfang package DOIF_uiTable; definieren und schon wird man sie alle nutzen können.

Interessant! Allerdings komme ich nicht vorwärts:


Ich habe eine zweite tpl erzeugt, die aktuell nur noch dies enthält, nach meinem Dafürhalten also "nichts":
{
# package $SELF;
# cw's angepasste Styles

#Styles

}

Wenn ich also im uiTable jetzt als erste Zeilen eintrage:
IMPORT contrib/DOIF/uiTable.tpl
IMPORT contrib/DOIF/uiTable_cw.tpl
{

erhalte ich als Fehlermeldung im DOIF

error Bareword "tpl" not allowed while "strict subs" in use at (eval 5578) line 1. in expression: tpl
error Missing right curly or square bracket at (eval 5579) line 1, at end of line syntax error at (eval 5579) line 1, at EOF in expression: {

Viele Grüße

Christian

Ich habe weitere Vereinfachungen in uiTable vorgenommen. Mit den neuen Möglichkeiten lassen sich recht einfach, ohne tiefere HTML/CSS-Kenntnisse, eigene Übersichten definieren, die sich auch bedienen lassen.

1. Im Package ui_Table habe ich neue Perl-Funktionen definiert, die innerhalb von uiTable nutzbar sind.

2. Desweiteren sind Templates nicht mehr auf ein Widget beschränkt; Damit können auch komplexere Definitionen vorgenommen werden, die sich mehrfach nutzen lassen, siehe unten.

neue Version wurde eingecheckt

hier geht es weiter im neuen Thread: https://forum.fhem.de/index.php/topic,106059.0.html