Ausblick: neues Attribut stateTable/stateTabletUI webCmdDOIF

[Damian]

Es wird wieder Zeit über neue Features nachzudenken

Die Statusanzeige ist üblicherweise auf eine Zeile begrenzt. Oft möchte man aber mehr Informationen in der Übersicht sehen, als nur das, was in eine Zeile passt.

Mit dem Attribut stateTable (als Erweiterung des state-Attributes zu sehen) soll es möglich sein, eine tabellarische Darstellung aller erdenklichen Informationen im Status eines DOIF-Moduls darzustellen (ähnlich readingsGroup)

Bsp.:

Code Auswählen Erweitern

attr <mein_doif> stateTable
"Temperatur im Wohnzimmer" | [livingroom:temperatur:d2] | "Feuchtigkeit" | [livingroom:humidity:d2]
"offene Fenster" | [@"Fenster":state:"open","keine"] | "Durchschnittstemperatur aller Zimmer" | [#d2:average"Temp":temperature]
"Differenz Vorlauf/Rücklauf"|[Vorlauf:temperature:d2]-[Ruecklauf:temperature:d2] | "aktueller Status des Moduls" | [$SELF:state]
...


Es können beliebig viele Zeilen und beliebig viele Spalten definiert werden, die Breite wird automatisch angepasst (oder definierbar), die Ausrichtung, die Größe der Schrift, Icons, Farbe soll definierbar sein.

Spaltenangaben werden mit | voneinander getrennt. Die Angaben können beliebige Perldefinitionen ergänzt um DOIF-Syntax [ sein. Angaben in eckigen Klammern wirken triggernd und aktualisieren die Tabelle.

Das Attribut ist unabhängig von der sonstigen DOIF-Definition. Wie beim state-Attribut kann ein DOIF-Modul nur aus der Definition des stateTable-Attributs bestehen.

Anregungen, Wünsche bitte hier posten - bevor ich mit der Umsetzung beginne

[the ratman]

kriegserklärung an readingsgroup? *g*

du machst also gesamtbreite/spaltenbreite anpassbar?
da fehlt dann ja nur mehr ein colspan zur vollständigkeit. vielleicht noch (hintergrund)farben wegen überschriften ...
willst du auch grafiken mit einfügbar machen?
wirds schaltbar?

allerdings frag ich mich, ob das nicht eventuell besser als eigenständiges modul wäre und dann per attr einfach ins entsprechende doif eingebunden wird?
so könnte ich mir quasi ne art generalvorlage für mehrere doif's basteln und das doif wäre nicht so proppen voll.
im endeffekt also quasi ne readingsgroup, die sich passgenau in ein doif einfügt.

sprich:
wenns nach mir geht baust du wirklich ne readingsgroup für doif. darf auch gern mehr können als ne rg *g*

[Damian]

kriegserklärung an readingsgroup? *g*

du machst also gesamtbreite/spaltenbreite anpassbar?
da fehlt dann ja nur mehr ein colspan zur vollständigkeit. vielleicht noch (hintergrund)farben wegen überschriften ...
willst du auch grafiken mit einfügbar machen?
wirds schaltbar?

allerdings frag ich mich, ob das nicht eventuell besser als eigenständiges modul wäre und dann per attr einfach ins entsprechende doif eingebunden wird?
so könnte ich mir quasi ne art generalvorlage für mehrere doif's basteln und das doif wäre nicht so proppen voll.
im endeffekt also quasi ne readingsgroup, die sich passgenau in ein doif einfügt.

sprich:
wenns nach mir geht baust du wirklich ne readingsgroup für doif. darf auch gern mehr können als ne rg *g*

Mal schauen wie viele Code es wird. Ich denke nicht dass es eine "Kriegserklärung" für readingsGroup ist. Denn readingsGroup kann z. B. mit einer Definition mehrere Zeilen gleichen Typs aufbauen - DOIF wird es nur durch einzelne Angaben können. Dafür hat man alle Möglichkeiten, die DOIF in eckigen Klammern bietet.
Was man in diese Tabelle reinpackt ist jedem selbst überlassen. Es können spezifische Informationen des eigenen Moduls (dessen Readings) sein oder aber einer Sammlung verstreuter Informationen in FHEM.
Ob man Sachen in der Tabelle bedienbar macht - weiß ich noch nicht.

Und da es reines Perl ist, kann man natürlich auch beliebige Perlfunktionen angeben, die irgendetwas ausgeben, oder eben Perl mit DOIF-Syntax kombinieren:

z. B.

Code Auswählen Erweitern

"Draußen ist es: "| ([Aussen:temperature]<10)? "kalt" : "warm"

[Per]

Nette Idee, aber: warum kein eigenes Modul? Die "DOIF-Syntax" gefällt mir als NichtPerlmitderMuttermilchbekommenhabender. Und außer "$SELF" dürfte nicht viel wegfallen.
OK, auch wenn es kein eigenes Modul wird, werden meine ersten Anwendungen wohl ohne DOIF-Funktionalität entstehen.

[Damian]

Nette Idee, aber: warum kein eigenes Modul? Die "DOIF-Syntax" gefällt mir als NichtPerlmitderMuttermilchbekommenhabender. Und außer "$SELF" dürfte nicht viel wegfallen.
OK, auch wenn es kein eigenes Modul wird, werden meine ersten Anwendungen wohl ohne DOIF-Funktionalität entstehen.

Ich vermute, dass  99 % des Sourcecodes gleich bleiben. Das eine Prozent wird wohl keiner beim Laden merken. Es ist nichts Verwerfliches DOIF nur mit state-Attribut  (demnächst stateTable) zu nutzen. Das ist sogar in der Commandref beschrieben.

Und ich habe keine Lust zwei Module zu pflegen.

[the ratman]

und grad du bist dir sicher, dass es bei "nur" doif bleibt? bei deiner "erweiterungs- und ideenfrequenz" mag ichs irgendwie bezwifeln (nur weiter so *anfeuer*).
also ich an deiner stelle hätte da große angst und würd mir mein "fhem in fhem" so modular wie möglich basteln. man weiß es ja nie ...
irgendwie hab ich den großen verdacht, dass wir in ein paar jahren hier zusammen sitzen werden und gar herzlich drüber lachen, wenn du dein 100stes modul feierst *bg*

[Damian]

und grad du bist dir sicher, dass es bei "nur" doif bleibt? bei deiner "erweiterungs- und ideenfrequenz" mag ichs irgendwie bezwifeln (nur weiter so *anfeuer*).
also ich an deiner stelle hätte da große angst und würd mir mein "fhem in fhem" so modular wie möglich basteln. man weiß es ja nie ...
irgendwie hab ich den großen verdacht, dass wir in ein paar jahren hier zusammen sitzen werden und gar herzlich drüber lachen, wenn du dein 100stes modul feierst *bg*

naja, ich habe noch ein paar Jahre bis zur Rente, es wird sich also bis dahin wohl alles noch im Rahmen halten - es ist nur ein Hobby-Projekt

[Ellert]

Es wird wieder Zeit über neue Features nachzudenken

Die Statusanzeige ist üblicherweise auf eine Zeile begrenzt. Oft möchte man aber mehr Informationen in der Übersicht sehen, als nur das, was in eine Zeile passt.

Mit dem Attribut stateTable (als Erweiterung des state-Attributes zu sehen) soll es möglich sein, eine tabellarische Darstellung aller erdenklichen Informationen im Status eines DOIF-Moduls darzustellen (ähnlich readingsGroup)

Bsp.:

Code Auswählen Erweitern

attr <mein_doif> stateTable
"Temperatur im Wohnzimmer" | [livingroom:temperatur:d2] | "Feuchtigkeit" | [livingroom:humidity:d2]
"offene Fenster" | [@"Fenster":state:"open","keine"] | "Durchschnittstemperatur aller Zimmer" | [#d2:average"Temp":temperature]
"Differenz Vorlauf/Rücklauf"|[Vorlauf:temperature:d2]-[Ruecklauf:temperature:d2] | "aktueller Status des Moduls" | [$SELF:state]
...


Es können beliebig viele Zeilen und beliebig viele Spalten definiert werden, die Breite wird automatisch angepasst (oder definierbar), die Ausrichtung, die Größe der Schrift, Icons, Farbe soll definierbar sein.

Spaltenangaben werden mit | voneinander getrennt. Die Angaben können beliebige Perldefinitionen ergänzt um DOIF-Syntax [ sein. Angaben in eckigen Klammern wirken triggernd und aktualisieren die Tabelle.

Das Attribut ist unabhängig von der sonstigen DOIF-Definition. Wie beim state-Attribut kann ein DOIF-Modul nur aus der Definition des stateTable-Attributs bestehen.

Anregungen, Wünsche bitte hier posten - bevor ich mit der Umsetzung beginne

Im Grunde funktioniert es schon mit dem Attribut state, z.B. mit diesem DOIF (für Raw definition) 

Code Auswählen Erweitern


defmod stateTable DOIF
attr stateTable room 0_Test
attr stateTable state <html><table style='color:grey;;'><tr>\
<td >Broadband</td>\
<td style='color:blue;;'>[TSL2561:broadband]</td></tr>\
<tr><td >Infrared</td>\
<td style='color:red;;'>[TSL2561:ir]</td></tr>\
<tr><td >Luminosity</td>\
<td style='color:yellow;;'>[TSL2561:luminosity]</td>\
</tr></table></html>
attr stateTable widgetOverride state:textField-long


Ich würde mir wünschen, dass man das Attribut webCmd beschriftten könnte und noch wichtiger tabellarisch anordnen könnte.
Ich bastele gerade ein DOIF mit 8 Readings, die über Slider eingestellt werden sollen, die müssten auf mindestens zwei  Zeilen verteilt werden damit sie auf den Bildschirm passen.

[Damian]

Im Grunde funktioniert es schon mit dem Attribut state, z.B. mit diesem DOIF (für Raw definition) 

Code Auswählen Erweitern


defmod stateTable DOIF
attr stateTable room 0_Test
attr stateTable state <html><table style='color:grey;;'><tr>\
<td >Broadband</td>\
<td style='color:blue;;'>[TSL2561:broadband]</td></tr>\
<tr><td >Infrared</td>\
<td style='color:red;;'>[TSL2561:ir]</td></tr>\
<tr><td >Luminosity</td>\
<td style='color:yellow;;'>[TSL2561:luminosity]</td>\
</tr></table></html>
attr stateTable widgetOverride state:textField-long


Ich würde mir wünschen, dass man das Attribut webCmd beschriftten könnte und noch wichtiger tabellarisch anordnen könnte.
Ich bastele gerade ein DOIF mit 8 Readings, die über Slider eingestellt werden sollen, die müssten auf mindestens zwei  Zeilen verteilt werden damit sie auf den Bildschirm passen.

Interessant, dass man jetzt schon so etwas basteln kann. Tja, zu webCmd müsstest du eine Anfrage im developer-Forum stellen. Oder man bastelt sich selber etwas. Ich finde, so langsam könnte man die starre einzeilige Darstellung im Standard-FHEMWEB etwas aufbrechen. Ich werde allerdings erst in den Sommerferien dazu kommen etwas in DOIF einzubauen.

[Ellert]

Interessant, dass man jetzt schon so etwas basteln kann. Tja, zu webCmd müsstest du eine Anfrage im developer-Forum stellen. Oder man bastelt sich selber etwas. Ich finde, so langsam könnte man die starre einzeilige Darstellung im Standard-FHEMWEB etwas aufbrechen. Ich werde allerdings erst in den Sommerferien dazu kommen etwas in DOIF einzubauen.

Ich hätte nicht gedacht, dass HTML-Tags auch für webCmd funktionieren, aber es klappt. Allerdings mit Einschränkungen. das style-Attribut funktioniert nicht weil in der Syntax ein Doppelpunkt vorkommt und das einzelne Cmd muss mit Doppelpunkt vom HTML getrennt werden.
Ist ein bisschen umständlich, aber es funktioniert.

Hier das Attribut webCmd zum Bild:

Code Auswählen Erweitern

<table><tr><td><font color='black'>Helligkeit&nbsp;Ein&nbsp;morgens</font></td><td>:G_HellMorgensO:<td><td><font color='black'>Helligkeit&nbsp;Aus&nbsp;morgens</font></td><td>:G_HellMorgensU:<td></tr><tr><td><font color='black'>Helligkeit&nbsp;Ein&nbsp;tagsüber</font></td><td>:G_HellTagsO:<td><td><font color='black'>Helligkeit&nbsp;Aus&nbsp;tagsüber</font></td><td>:G_HellTagsU:</td></tr></table>

Eine mehrzeilige Darstellung ist auch möglich indem eine moduleigene "detailFn" mit der Deviceline kombiniert wird, wie hier aktuell diskutiert wird https://forum.fhem.de/index.php/topic,71772.0.html

[Damian]

So etwas fände ich ganz nett, DOIF mit TabletUI-Wigets

Ein gefaktes DOIF als Screenshot

[Ellert]

Scheint nicht unmöglich: Tablet-UI gestalten und als I-Frame in die DOIF detailFn einbauen und die Tablet-UI Seite per Attribut angeben.
Oder enfacher, die Tablet-UI Seite über das Attribut state als I-Frame darstellen

[Damian]

Scheint nicht unmöglich: Tablet-UI gestalten und als I-Frame in die DOIF detailFn einbauen und die Tablet-UI Seite per Attribut angeben.
Oder enfacher, die Tablet-UI Seite über das Attribut state als I-Frame darstellen

Gesagt, getan. Diesmal kein Fake sondern echt, also voll funktionsfähig!

Als Schnittstelle könnte man myReadings nutzen.

Die Konfiguration von TabletUI finde ich etwas umständlich. Da müsste ich eine vereinfachte Syntax drüber stülpen.

 

[Per]

kein Fake sondern echt

Nicht das ich dir das nicht glaube, aber könntest du dazu mal den Quellcode zeigen? Zum Aufwand abschätzen und nachspielen?

[Damian]

Nicht das ich dir das nicht glaube, aber könntest du dazu mal den Quellcode zeigen? Zum Aufwand abschätzen und nachspielen?

Ganz einfach.

Mit TabletUI habe ich vorher schon gespielt (es ist eine von mir verbasteltet TabletUI-Demo), daher existierte bereits eine solche Instanz siehe "Tablet Frontend" im Screenshot. Wie man so etwas konfiguriert, findet man im Frontend TabletUI-Bord. Im DOIF-Sourcecode habe ich  nur ergänzt:

Code Auswählen Erweitern

...
  $hash->{FW_detailFn}  = "DOIF_detailFn";
  $hash->{FW_summaryFn}  = "DOIF_detailFn";
}

sub
DOIF_detailFn()
{
  my ($FW_wname, $d, $room, $pageHash) = @_;
  my $hash = $defs{$d};
  return '<iframe src="http://192.168.178.3:8086/fhem/tablet" scrolling="no" height=730 width=1024></iframe>' if (AttrVal($hash->{NAME},'state','') eq "TabletUI");
...

Das ist natürlich nur experimentell.

Was ich mir vorstellen könnte ist eine vereinfachte Syntax im DOIF für das Layout der TabletUI-Darstellung

mit Syntax pro Wiget z. B.:

Eine Zeile pro ein Wiget mit  kommagetrennten Elementen innerhalb des Wigets:

<Größe>:<row><column> <name>:<type>:<Device mit DOIF-Syntax in Perl>,<type><Device mit DOIF-Syntax>,....

z. B.

Code Auswählen Erweitern

attr <mein_DOIF> stateTabletUI

1x1:1:1 TREND:symbol:[mydummy],label:"Status"
1x4:2:1 GARTEN:switch:[GartenLicht],label:"Licht",switch:[dummySwitch|,label...
...

entspreche dann ungefähr in der TabletUI-Syntax:

<

Code Auswählen Erweitern

li data-row="1" data-col="1" data-sizex="1" data-sizey="1">
    <header>TREND</header>
    <div data-type="symbol" data-device="mydummy" data-icons='["fa-arrow-up","fa-arrow-right","fa-arrow-down"]' data-on-colors='["#32a054","#6666cc","#ad3333"]' data-get-on='["Wert1","Wert2","Wert3"]' class=""></div>
    <div data-type="label" class="small narrow darker">Status</div>

</li>
<li data-row="2" data-col="1" data-sizex="1" data-sizey="4">
        <header>GARTEN</header>
        <div data-type="switch" data-device="GartenLicht" class="cell" ></div>
        <div data-type="label" class="cell">Licht</div>
        <div data-type="switch" data-device="dummySwitch" data-on="1" data-off="0" data-set-on="11" data-set-off="10" data-icon="fa-lock" class="cell" ></div>
        <div data-type="label" class="cell">Tür</div>


Bestimmte Sachen würde man dann im TabletUI vorbelegen, um es im DOIF nicht zu komplex zu machen.

Dann wollen mir mal hoffen, dass man beliebig viele Instanzen von TabletUI erzeugen kann

[Damian]

Wer jetzt schon mit TabletUI mit DOIF experimentieren will, der kann einfach im Attribut state den Link zu seinem zuvor definierten TabletUI angeben, z. B.

Code Auswählen Erweitern

attr di_bla state <html><iframe src="http://192.168.178.3:8086/fhem/tablet" scrolling="no" height=730 width=1024></iframe>'</html>

Ich bin mir jetzt schon sicher, dass DOIF mit TabletUI-Wigets mit einfacher Definition (inkl. persönlicher Templates für Layout) ein unschlagbares Team sein werden: Automatisation + vernünftiges Layout sind die unschlagbaren Argumente für jedes smarte Home

[the ratman]

ach schade ...

ich dacht eig., man kann die einzelnen widgets der tablet-ui ins doif einbauen.

[Damian]

ach schade ...

ich dacht eig., man kann die einzelnen widgets der tablet-ui ins doif einbauen.

Kannst du - jetzt noch recht umständlich. Du musst halt für jedes DOIF ein eigenes tabletui definieren (ggf. mit copy und paste). Die Readings, die du da angibst sollten natürlich zu deinem DOIF-passen.

Es ist nur etwas zum Ausprobieren, weil eben zu umständlich. Zukünftig wird es im DOIF, wie bereits angedeutet, eine vereinfachte Syntax im Attribut stateTabletUI geben, mit der dann die wigets automatisch generiert werden, die im jeweiligen DOIF erscheinen.

So schnell kann ich auch nicht programmieren

[Ellert]

Hallo Damian,

ich habe das Attribut "myWebCmd" und die "detailFn" in DOIF eingebaut, es ist die Version aus dem Thema myReadings.

Die Darstellung von "myWebCmd" ist nicht mehr Bestandteil der Gerätezeile, sondern liegt darunter.

Die Beschreibung ergänze ich falls es offiziell wird.

Hier noch mal die Beispieldefinition

Code Auswählen Erweitern

defmod datumsbereich_Labor0 DOIF ([[$SELF:P_bhm,"00:00"]] and [?$SELF:P_byear] == $year and [?$SELF:P_bmon] == $month and [?$SELF:P_bday] == $mday)\
   {Log 1, "Alarmstart"}\
DOELSEIF ([[$SELF:P_ehm,"00:00"]] and [?$SELF:P_eyear] == $year and [?$SELF:P_emon] == $month and [?$SELF:P_eday] == $mday)\
   {Log 1, "Alarmstop"}
attr datumsbereich_Labor0 alias Terminspanne
attr datumsbereich_Labor0 cmdState 1|0
attr datumsbereich_Labor0 comment P_bhm:P_bday:P_bmon:P_byear:P_ehm:P_eday:P_emon:P_eyear
attr datumsbereich_Labor0 group Labor: Datumsbereich von HH:MM dd.mm.yyyy bis HH:MM dd.mm.yyyy ohne datetimepicker Widget
attr datumsbereich_Labor0 icon time_calendar
attr datumsbereich_Labor0 myWebCmd Start: ;Zeit|P_bhm|Tag|P_bday|Monat|P_bmon|Jahr|P_byear\
Ende: ;Zeit|P_ehm|Tag|P_eday|Monat|P_emon|Jahr|P_eyear
attr datumsbereich_Labor0 readingList P_bhm P_bday P_bmon P_byear P_ehm P_eday P_emon P_eyear
attr datumsbereich_Labor0 room DOIF_Labor
attr datumsbereich_Labor0 setList P_bhm:time\
P_bday:1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31 \
P_bmon:slider,1,1,12\
P_byear:2016,2017,2018,2019,2020,2021,2022,2023,2024,2025,2026\
P_ehm:time\
P_eday:1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31\
P_emon:slider,1,1,12\
P_eyear:2016,2017,2018,2019,2020,2021,2022,2023,2024,2025,2026
attr datumsbereich_Labor0 webCmd cmd_1
attr datumsbereich_Labor0 widgetOverride (setList|myWebCmd):textField-long

setstate datumsbereich_Labor0 1
setstate datumsbereich_Labor0 2017-06-11 16:10:28 .eM off
setstate datumsbereich_Labor0 2017-06-11 09:00:14 P_bday 2
setstate datumsbereich_Labor0 2017-06-11 16:45:09 P_bhm 15:05
setstate datumsbereich_Labor0 2017-06-11 16:53:04 P_bmon 3
setstate datumsbereich_Labor0 2017-01-19 11:02:57 P_byear 2017
setstate datumsbereich_Labor0 2017-03-08 19:28:35 P_eday 8
setstate datumsbereich_Labor0 2017-06-09 19:17:29 P_ehm 12:00
setstate datumsbereich_Labor0 2017-03-08 19:28:37 P_emon 3
setstate datumsbereich_Labor0 2017-06-09 18:55:16 P_eyear 2017
setstate datumsbereich_Labor0 2017-06-11 16:45:02 cmd 1
setstate datumsbereich_Labor0 2017-06-11 16:45:02 cmd_event set_cmd_1
setstate datumsbereich_Labor0 2017-06-11 16:45:02 cmd_nr 1
setstate datumsbereich_Labor0 2017-06-11 16:45:02 state 1
setstate datumsbereich_Labor0 2017-06-11 17:38:12 timer_01_c01 12.06.2017 15:05:00
setstate datumsbereich_Labor0 2017-06-11 17:38:12 timer_02_c02 12.06.2017 12:00:00



[Damian]

Hallo Ellert,

ich habe es gerade angetestet - funktioniert.

Wäre man nicht flexibler, wenn man Texte in Anführungszeichen angeben würde, dann wäre man nicht auf die starre <Bezeichner><Reading>-Struktur angewiesen und  könnte z. B. auch tabellarische Darstellung mit Überschrift-Zeile  und darunter Readings vornehmen z. B.

Bezeichnung davor:

Code Auswählen Erweitern

"Start: Zeit"|P_bhm|"Tag"|P_bday|"Monat"|P_bmon|"Jahr"|P_byear\
"Ende: Zeit"|P_ehm|"Tag"|P_eday|"Monat"|P_emon|"Jahr"|P_eyear

oder aber:

Bezeichnungen als Überschrift:

Code Auswählen Erweitern

|"Zeit"|"Tag"|"Monat"|"Jahr"\
"Start: "|P_bhm|P_bday|P_bmon|P_byear\
"Ende: "|P_ehm|P_eday|P_emon|P_eyear


Edit: Beispiele angepasst

[Ellert]

Ich habe myWebCmd in webCmdDOIF geändert, weil es dann in der Attributliste gleich unter webCmd ins Auge fällt und myIrgenwas irgendwie nicht so gut zum DOIF passt.

Bezeichner stehen zwischen ""
Werden Readings nicht in setList gefunden, wird der Text angegeben.

Code Auswählen Erweitern


attr datumsbereich_Labor0 webCmdDOIF ""|"Zeit"|"Tag"|"Monat"|"Jahr"\
"Start"|P_bhm|P_bday|P_bmon|P_byear\
"Ende"|P_ehm|P_eday|P_emon|P_eyear


[Damian]

Ich habe myWebCmd in webCmdDOIF geändert, weil es dann in der Attributliste gleich unter webCmd ins Auge fällt und myIrgenwas irgendwie nicht so gut zum DOIF passt.

Bezeichner stehen zwischen ""
Werden Readings nicht in setList gefunden, wird der Text angegeben.

Code Auswählen Erweitern


attr datumsbereich_Labor0 webCmdDOIF ""|"Zeit"|"Tag"|"Monat"|"Jahr"\
"Start"|P_bhm|P_bday|P_bmon|P_byear\
"Ende"|P_ehm|P_eday|P_emon|P_eyear


schön, damit ist man wesentlich flexibler.

Ich nehme an, dass man Formatierungen per Html-Code einfügen kann. Es wird üblicherweise (DIN 5008) bei Überschriften erste Spalte linksbündig alle anderen zentriert angegeben.

[Ellert]

Es werden Zellen beschrieben, alles, was zwischen <td> und </td> an HTML erlaubt ist, sollte für die Bezeichner funktionieren.

Edit: Die Widgets bringen eine eigene CSS-Klasse mit und sind links ausgerichtet, es wird das ganze <td>-Element ersetzt.
Edit: es wird das <div>-Element mit der Klasse "fhemWidget" durch ein Widget ersetzt.

[Damian]

Es werden Zellen beschrieben, alles, was zwischen <td> und </td> an HTML erlaubt ist, sollte für die Bezeichner funktionieren.

Edit: Die Widgets bringen eine eigene CSS-Klasse mit und sind links ausgerichtet, es wird das ganze <td>-Element ersetzt.
Edit: es wird das <div>-Element mit der Klasse "fhemWidget" durch ein Widget ersetzt.

Könntest du bitte ein paar Beispiele zur Formatierung (Ausrichtung, Farbe, etc.) hier mal aufführen. Das können wir später dann mit in die Doku aufnehmen.

[Ellert]

Hier einige Formatierungen an Hand des bekannten Beispiels

Code Auswählen Erweitern


defmod datumsbereich_Labor0 DOIF ([[$SELF:P_bhm,"00:00"]] and [?$SELF:P_byear] == $year and [?$SELF:P_bmon] == $month and [?$SELF:P_bday] == $mday)\
   {Log 1, "Alarmstart"}\
DOELSEIF ([[$SELF:P_ehm,"00:00"]] and [?$SELF:P_eyear] == $year and [?$SELF:P_emon] == $month and [?$SELF:P_eday] == $mday)\
   {Log 1, "Alarmstop"}
attr datumsbereich_Labor0 alias Terminspanne
attr datumsbereich_Labor0 cmdState 1|0
attr datumsbereich_Labor0 group Labor: Datumsbereich von HH:MM dd.mm.yyyy bis HH:MM dd.mm.yyyy ohne datetimepicker Widget
attr datumsbereich_Labor0 icon time_calendar
attr datumsbereich_Labor0 readingList P_bhm P_bday P_bmon P_byear P_ehm P_eday P_emon P_eyear
attr datumsbereich_Labor0 room DOIF_Labor
attr datumsbereich_Labor0 setList P_bhm:time\
P_bday:1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31 \
P_bmon:slider,1,1,12\
P_byear:2016,2017,2018,2019,2020,2021,2022,2023,2024,2025,2026\
P_ehm:time\
P_eday:1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31\
P_emon:slider,1,1,12\
P_eyear:2016,2017,2018,2019,2020,2021,2022,2023,2024,2025,2026
attr datumsbereich_Labor0 webCmd cmd_1
attr datumsbereich_Labor0 webCmdDOIF ""|"<div style="background-color:Lavender">Zeit</div>"|"<div style="background-color:Lavender">Tag</div>"|"<div style="text-align:center;;background-color:Lavender;;">Monat</div>"|"<div style="background-color:Lavender">Jahr</div>"\
"<div style="color:red;; font-weight:bold">Start<br>oder<br>Beginn</div>"|P_bhm|P_bday|P_bmon|P_byear\
"<div style="color:blue;; font-weight:bold">Ende</div>"|P_ehm|P_eday|P_emon|P_eyear


[Damian]

Hier einige Formatierungen an Hand des bekannten Beispiels

super, das dürfte für die meisten nachvollziehbar sein. Was jetzt noch fehlt, ist bedingte Formatierung z. B. über 30 rot, sonst grün

[Per]

Code Auswählen Erweitern


P_bday:1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31


lässt sich da kein

Code Auswählen Erweitern


P_bday:1-31

draus machen?

[Damian]

lässt sich da kein

Code Auswählen Erweitern


P_bday:1-31

draus machen?

Diese Frage musst du an den Maintainer von setList stellen.

[Damian]

jetzt brauchen wir noch anklickbare Icons, die sich je nach Zustand verändern und Aktionen auslösen, dann kann ich auch stateTabletUI von der todo-Liste streichen, (stateTable habe ich bereits gestrichen)

[Ellert]

jetzt brauchen wir noch anklickbare Icons, die sich je nach Zustand verändern und Aktionen auslösen, dann kann ich auch stateTabletUI von der todo-Liste streichen, (stateTable habe ich bereits gestrichen)

super, das dürfte für die meisten nachvollziehbar sein. Was jetzt noch fehlt, ist bedingte Formatierung z. B. über 30 rot, sonst grün

Ab dieser Komplexität würde ich das mit einer ReadingsGroup lösen, sonst müsste man aus meiner Sicht größere Teile aus FHEMWEB im DOIF doifspezifisch nach bauen und eine doif.js dazu basteln.

Ich habe für das, was geht, die Beschreibung integriert, commandref_join.pl liefert keine Fehler.

Edit:
@Damian
Du könntest ja mal versuchen die TabletUI Widgets als Bezeichner einzubinden, das könnte funktionieren. Es müssen in der Tabelle ja keine Befehle angegeben werden.

[Damian]

Ab dieser Komplexität würde ich das mit einer ReadingsGroup lösen, sonst müsste man aus meiner Sicht größere Teile aus FHEMWEB im DOIF doifspezifisch nach bauen und eine doif.js dazu basteln.

Ich habe für das, was geht, die Beschreibung integriert, commandref_join.pl liefert keine Fehler.

Edit:
@Damian
Du könntest ja mal versuchen die TabletUI Widgets als Bezeichner einzubinden, das könnte funktionieren. Es müssen in der Tabelle ja keine Befehle angegeben werden.

ja, vermutlich aber erst in den Ferien

[Ellert]

Na, ja,

Code Auswählen Erweitern

attr di_bla webCmdDOIF "<iframe src="/fhem/www/tablet2/index.html" scrolling="no" height="120" width="220"></iframe>"

dürfte nicht so zeitintensiv sein 

Die Einbindung von iframes funktioniert grundsätzlich, das Beispiel ist etwas zusammenhanglos.

[Damian]

Na, ja,

Code Auswählen Erweitern

attr di_bla webCmdDOIF "<iframe src="/fhem/www/tablet2/index.html" scrolling="no" height="120" width="220"></iframe>"

dürfte nicht so zeitintensiv sein 

Die Einbindung von iframes funktioniert grundsätzlich, das Beispiel ist etwas zusammenhanglos.

Dass das geht, ist mir schon klar, nur eben mit dem ganzen TabletUI-Overhead und umständlicher html-Konfiguration.

[Ellert]

Wenn bei installiertem Tablet-UI im Attribut JavaScripts des FHEMWEB-Gerätes tablet/js/fhem-tablet-ui.js eingetragen wird, kann man FTUI-Widgets auch in dem Attribut webCmdDOIF direkt angeben.

Erst die Definition erzeugen und dann tablet/js/fhem-tablet-ui.js einbinden.

In dem angepasste Beispiel wird das DOIF mit einem switch-Widget direkt geschaltet:
Erst die Definition erzeugen und dann tablet/js/fhem-tablet-ui.js einbinden.

Code Auswählen Erweitern

defmod datumsbereich_Labor0 DOIF ([[$SELF:P_bhm,"00:00"]] and [?$SELF:P_byear] == $year and [?$SELF:P_bmon] == $month and [?$SELF:P_bday] == $mday)\
   {Log 1, "Alarmstart"}\
DOELSEIF ([[$SELF:P_ehm,"00:00"]] and [?$SELF:P_eyear] == $year and [?$SELF:P_emon] == $month and [?$SELF:P_eday] == $mday)\
   {Log 1, "Alarmstop"}
attr datumsbereich_Labor0 alias Terminspanne
attr datumsbereich_Labor0 cmdState 1|0
attr datumsbereich_Labor0 group Labor: Datumsbereich von HH:MM dd.mm.yyyy bis HH:MM dd.mm.yyyy ohne datetimepicker Widget
attr datumsbereich_Labor0 icon time_calendar
attr datumsbereich_Labor0 readingList P_bhm P_bday P_bmon P_byear P_ehm P_eday P_emon P_eyear
attr datumsbereich_Labor0 room DOIF_Labor
attr datumsbereich_Labor0 setList P_bhm:time\
P_bday:1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31 \
P_bmon:slider,1,1,12\
P_byear:2016,2017,2018,2019,2020,2021,2022,2023,2024,2025,2026\
P_ehm:time\
P_eday:1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31\
P_emon:slider,1,1,12\
P_eyear:2016,2017,2018,2019,2020,2021,2022,2023,2024,2025,2026
attr datumsbereich_Labor0 webCmd cmd_1
attr datumsbereich_Labor0 webCmdDOIF "<div data-type="switch" data-icon="fa-rss" data-device='datumsbereich_Labor0' data-get-on="cmd_1" data-get-off="cmd_2" data-set-on="cmd_1" data-set-off="cmd_2""></div>"


Es gibt allerdings Wechselwirkungen zwischen Tablet-UI und FHEMWEB. daher ist diese Lösung noch nicht alltags tauglich.

[Damian]

Auch nicht schlecht. D. h. jetzt noch ein js basteln, was nur die widgets bedient und einen Preprozessor in DOIF basteln, welcher eine einfache Syntax in webCmdDOIF in den jeweiligen html-Code übersetzt.

[Ellert]

lässt sich da kein

Code Auswählen Erweitern


P_bday:1-31

draus machen?

@Per: Mich stören die Zahlenkolonnen auch.

Mit der anliegenden Datei gibt es ein Widget "selectrange". Die Syntax ist wie beim Slider.

Datei in den Ordner "pgm2" kopieren und Restart durchführen.

Beispiel:

Code Auswählen Erweitern


defmod du5 dummy
attr du5 readingList state
attr du5 room 0_Test
attr du5 setList state:selectrange,0,.2,10,1
attr du5 webCmd state


[Damian]

@Per: Mich stören die Zahlenkolonnen auch.

Mit der anliegenden Datei gibt es ein Widget "selectrange". Die Syntax ist wie beim Slider.

Datei in den Ordner "pgm2" kopieren und Restart durchführen.

Beispiel:

Code Auswählen Erweitern


defmod du5 dummy
attr du5 readingList state
attr du5 room 0_Test
attr du5 setList state:selectrange,0,.2,10,1
attr du5 webCmd state


Vielleicht machst du mal den Vorschlag im FHEMWEB-Board das Script offiziell aufzunehmen, damit alle was davon haben (auch die Nicht-DOIF-Nutzer)

[Ellert]

Vielleicht machst du mal den Vorschlag im FHEMWEB-Board das Script offiziell aufzunehmen, damit alle was davon haben (auch die Nicht-DOIF-Nutzer)

Das war erstmal eine Übung für mich und noch nicht ganz ausgereift, es soll eigentlich auch eine logarithmische Reihe mit rein.

[Ellert]

@Per: Mich stören die Zahlenkolonnen auch.

Mit der anliegenden Datei gibt es ein Widget "selectrange". Die Syntax ist wie beim Slider.

Datei in den Ordner "pgm2" kopieren und Restart durchführen.

Beispiel:

Code Auswählen Erweitern


defmod du5 dummy
attr du5 readingList state
attr du5 room 0_Test
attr du5 setList state:selectrange,0,.2,10,1
attr du5 webCmd state


Es ist mit anderen Namen in fhemweb.js integriert, s. https://forum.fhem.de/index.php/topic,73188.0.html

[Ellert]

Wenn bei installiertem Tablet-UI im Attribut JavaScripts des FHEMWEB-Gerätes tablet/js/fhem-tablet-ui.js eingetragen wird, kann man FTUI-Widgets auch in dem Attribut webCmdDOIF direkt angeben.

Erst die Definition erzeugen und dann tablet/js/fhem-tablet-ui.js einbinden.

In dem angepasste Beispiel wird das DOIF mit einem switch-Widget direkt geschaltet:
Erst die Definition erzeugen und dann tablet/js/fhem-tablet-ui.js einbinden.

Code Auswählen Erweitern

defmod datumsbereich_Labor0 DOIF ([[$SELF:P_bhm,"00:00"]] and [?$SELF:P_byear] == $year and [?$SELF:P_bmon] == $month and [?$SELF:P_bday] == $mday)\
   {Log 1, "Alarmstart"}\
DOELSEIF ([[$SELF:P_ehm,"00:00"]] and [?$SELF:P_eyear] == $year and [?$SELF:P_emon] == $month and [?$SELF:P_eday] == $mday)\
   {Log 1, "Alarmstop"}
attr datumsbereich_Labor0 alias Terminspanne
attr datumsbereich_Labor0 cmdState 1|0
attr datumsbereich_Labor0 group Labor: Datumsbereich von HH:MM dd.mm.yyyy bis HH:MM dd.mm.yyyy ohne datetimepicker Widget
attr datumsbereich_Labor0 icon time_calendar
attr datumsbereich_Labor0 readingList P_bhm P_bday P_bmon P_byear P_ehm P_eday P_emon P_eyear
attr datumsbereich_Labor0 room DOIF_Labor
attr datumsbereich_Labor0 setList P_bhm:time\
P_bday:1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31 \
P_bmon:slider,1,1,12\
P_byear:2016,2017,2018,2019,2020,2021,2022,2023,2024,2025,2026\
P_ehm:time\
P_eday:1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31\
P_emon:slider,1,1,12\
P_eyear:2016,2017,2018,2019,2020,2021,2022,2023,2024,2025,2026
attr datumsbereich_Labor0 webCmd cmd_1
attr datumsbereich_Labor0 webCmdDOIF "<div data-type="switch" data-icon="fa-rss" data-device='datumsbereich_Labor0' data-get-on="cmd_1" data-get-off="cmd_2" data-set-on="cmd_1" data-set-off="cmd_2""></div>"


Es gibt allerdings Wechselwirkungen zwischen Tablet-UI und FHEMWEB. daher ist diese Lösung noch nicht alltags tauglich.

Mit den angepassten Dateien sind die offensichtlichen Wechselwirkungen beseitigt.

Die Datei fhem-tablet-uidi.js muss in den css-Ordner von Tablet-UI.
Die Datei fhem-tablet-uidi.css muss in den js-Ordner von Tablet-UI.

Im entsprechenden FHEMWEM müssen die Dateien im jeweiligen Attribut (CssFiles, JavaScripts ) registriert werden.

In DOIF wurden doppelte Zeilen geschrieben, das ist bereinigt.

Mit dem Beispiel könnte man ohne Behinderung experimentieren.

Code Auswählen Erweitern


defmod tabletDOIF DOIF (#1)\
DOELSEIF (#2)\
DOELSEIF (#3)
attr tabletDOIF readingList schieberegler
attr tabletDOIF room 0_Test
attr tabletDOIF webCmdDOIF "<div data-on-color="red" data-off-color="blue" data-type="switch" data-icon="fa-rss" data-device='tabletDOIF' data-get-on="cmd_1" data-get-off="cmd_2" data-set-on="cmd_1" data-set-off="cmd_2"></div>"|"<div data-type="selector" data-device="tabletDOIF" data-items='["cmd_1","cmd_2","cmd_3"]' data-get="STATE" data-set=""></div>"|"<div><div data-type="slider" data-device='tabletDOIF' data-set='schieberegler' data-get='schieberegler' data-min="10" data-max="90" class="cell" > </div> <div data-device="tabletDOIF" data-get="schieberegler" data-type="label" class="cell">Werte</div></div>"

setstate tabletDOIF cmd_1
setstate tabletDOIF 2017-06-17 09:23:20 .eM off
setstate tabletDOIF 2017-06-17 17:45:05 cmd 1
setstate tabletDOIF 2017-06-17 17:45:05 cmd_event set_cmd_1
setstate tabletDOIF 2017-06-17 17:45:05 cmd_nr 1
setstate tabletDOIF 2017-06-17 17:41:11 schieberegler 52
setstate tabletDOIF 2017-06-17 17:45:05 state cmd_1


Edit: Namen der css und js Datei berichtigt.