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