Hallo, kann mir jemand sagen ob es möglich ist in einem ftui-code eine Schleife einzubauen. Für ein ftui-content müsste ich ja dennoch für jedes mögliche Element einen Aufruf auf ein Tempate und den jeweiligen Namen angeben.
Es geht um Auflistungen verschiedener Elemente wie z.b. offene Fenster/Türen, wo man im Vorfeld aber nicht weiß wie viele Fenster/Türen geöffnet sind, aber alle gelistet haben möchte.
Am besten wäre ein for-each, so dass man nur einmal den Code schreiben muss.
Hi,
FTUI(3) ist für die Darstellung von Inhalten gedacht. Die Ermittlung der Daten sollte/muss in FHEM erfolgen.
Was Du möchtest, kann mit einem DOIF realisiert werden. Schaue dort einmal nach. Da gibt es Beispiele.
Viele Grüße
Jürgen
ich denke er meinte schon die Darstellung. Es gibt ja viele Sachen, die man gut über Templates darstellen kann, aber diese dann zig mal hintereinander in den code packen muss, wo sich nur der devicename dann zb ändert. sowas per schleife machen zu können wäre daher schon nicht verkehrt um den code schlanker halten zu können. wäre vor allem interessant, für devices mit filter, die eine unbekannten anzahl an treffern liefert
Genau das meinte ich.
Beispiel Batterien, alle sing gleich aufgebaut vom Namen und den Readings, ich weiß aber nicht welche und vor allen Dingen wie viele schlecht/unzureichend sind.
Aktuell müsste ich für jedes Batteriebetriebene Device einen Verweis auf ein Template erstellen und dann wieder künstlich die wo die Batterie noch gut mit hidden ausblenden.
Das ist doch sehr aufwändig und unnötiger Code wenn man eine Schleife bauen könnte.
Na ja, Batterien habe ich über readingsGroup zusammengefasst:
Zitatdefmod rg_battery readingsGroup .*:(battery|batteryVoltage)
Die Auswertung erfolgt einmal täglich über ein at:
define at_Batteriewarnung at *07:10 {\
my @devs = devspec2array("battery=low,batteryPercent<=10");;\
if (@devs) {\
my $string = join(", ",@devs);;\
$string =~ s/_/-/ig;;\
fhem ("set mySignal send \@TabletNorbert \@HandyNorbert Batterie leer: $string");;\
}\
}\
attr at_Batteriewarnung room Batterien
# COMMAND {
# my @devs = devspec2array("battery=low,batteryPercent<=10");
# if (@devs) {
# my $string = join(", ",@devs);
# $string =~ s/_/-/ig;
# fhem ("set mySignal send \@TabletNorbert \@HandyNorbert Batterie leer: $string");
# }
#}
#
# DEF *07:10 {
# my @devs = devspec2array("battery=low,batteryPercent<=10");
# if (@devs) {
# my $string = join(", ",@devs);
# $string =~ s/_/-/ig;
# fhem ("set mySignal send \@TabletNorbert \@HandyNorbert Batterie leer: $string");
# }
#}
#
# FUUID 606946d3-f33f-8873-c575-8aa5bfc616f41840
# FVERSION 90_at.pm:0.287110/2024-03-27
# NAME at_Batteriewarnung
# NR 497
# PERIODIC yes
# RELATIVE no
# REP -1
# STATE Next: 07:10:00
# TIMESPEC 07:10
# TRIGGERTIME 1754889000
# TRIGGERTIME_FMT 2025-08-11 07:10:00
# TYPE at
# READINGS:
# 2025-08-10 07:10:00 state Next: 07:10:00
#
setstate at_Batteriewarnung Next: 07:10:00
setstate at_Batteriewarnung 2025-08-10 07:10:00 state Next: 07:10:00
Zum einen verstehe ich nicht warum bei deinem at dreiviertel auskommentiert sind, zum Anderen löst das ja nicht das Anzeigeproblem in ftui.
Eine ReadingsGroup habe ich auch, aber außer mir hat keiner Zugriff auf FHEM, es läuft ALLES über ftui als Frontend/Bedienung.
Zitat von: Marko1976 am 10 August 2025, 09:48:46Zum einen verstehe ich nicht warum bei deinem at dreiviertel auskommentiert sind
Da ist gar nichts auskommentiert. Schon mal
Copy for forum.fhem.de benutzt?
War ja nur als Anregung gedacht.
Warum schaut Ihr Euch nicht einfach mal die Vorschläge an ::)
Dann würdet ihr auch so etwas sehen O:-)
offene Fenster (https://forum.fhem.de/index.php?topic=139194.msg1320295#msg1320295)
Die gleiche Methode nutze ich auch für leere Batterien ;D
@Nobbynews
Die Raute vorweg ist doch eine auskommentierung oder verwechsel ich hier irgend eine Programmiersprache.
@juermuc
Es entspricht nicht der Fragestellung. Ich hatte gefragt wie man eine Auflistung aller offenen Fenster darstellen kann, nicht nur die Anzahl. Mit der Anzahl agiere ich bereits, doch sie sagt mir eben nicht welche Fenster offen sind/welche Batterien schlecht sind.
Ich möchte eine Anzeige wo drin steht:
Wohnzmmerfenster links: offen
Küchenfenster: offen
Schlafzimmerfenster rechts: offen
Ich weiß dabei vorher nicht welche Fenster offen sind.
Deshalb nochmal: klar kann ich auf jedes Fenster/jede Batterie/jedes xyz einen Content-Eintrag erstellen und dann alles unzutreffende ausblenden. Doch das ist doch unpraktikable und muss bei jeder Veränderung angepasst werden.
Zitat von: Marko1976 am 10 August 2025, 10:35:29@Nobbynews
Die Raute vorweg ist doch eine auskommentierung oder verwechsel ich hier irgend eine Programmiersprache.
Wer hat denn behauptet, dass das vollständige list eines device eine Programmiersprache repräsentiert?
Der Teil, der einer Programmiersprache zuzuordnen ist (unmittelbar hinter der Zeile mit dem
define), ist auch nicht auskommentiert.
Ich habe schon die Fragestellung verstanden. Du willst nur die Lösung nicht haben.
Screenshot 2025-08-10 110635.png
Screenshot 2025-08-10 112044.png
Hier am Beispiel der Steckdosen, die an sind. Und auch Türen und Fenster ;D
Das Coding kann man in eine Content-Datei auslagern und dann mit Parametern aufrufen. Dies dann halt x-mal.
<ftui-content
file="./content/Rollo.html" Rollo="Rollo_Wohnzimmer" Rollo_WT="Rollo_Wohnzimmer_WT" Rollo_pop="rwz_timer">
</ftui-content>
Zitat von: juemuc am 10 August 2025, 11:17:47Das Coding kann man in eine Content-Datei auslagern und dann mit Parametern aufrufen. Dies dann halt x-mal.
du hast die Frage leider nicht richtig verstanden meine ich. Es geht ihm ja gerade drum nicht x-mal ein identisches template include zu machen wo sich nur das device ändert. Es geht drum, dass man eine unbestimmte anzahl an devices identisch darstellen will, wofür eine schleife der code übersichtlichkeit zu gute kommt. insbesondere wenn man ungewünschte einträge hat, müsste man dann die nicht extra mit hidden ausblenden
Nicht nur das, man muss den Code auch nicht jedesmal anpassen wenn sich ein Device ändert/hinzukommt oder wegfällt.
ZitatDas Coding kann man in eine Content-Datei auslagern und dann mit Parametern aufrufen. Dies dann halt x-mal.
Das ist ja genau das was ich selbst gepostet habe und umgehen möchte.
1. Muss ich es dann für jedes Fenster machen, da ich ja nicht weiß ob ein Fenster offen oder nicht ist.
2. Muss dann bei jeden neuen, getauschten oder wegfallendem Device der Code angepasst werden.
Und deine Beispiele zeigen innerhalb von ftui3 nur die Gesamtansicht mit Anzahl. Und wie gesagt sieht außer mir die Fhem-Ansicht niemand, eine derartige Lösung fällt also aus.
Ich versuche es noch ein letztes Mal.
Das DOIF enthält dynamisch nur die Devices, die Du definierts. Also z.B. nur alle offenen Fenster/Türen oder auch nur die Steckdosen, die an sind (und nicht ALLE!).
Wenn Du es richtig machst, musst Du bei neuen, geänderten oder auch gelöschten Devices das Coding im DOIF nicht ändern. Ich verarbeite hier die diversesten Geräte unterschiedlicher Hersteller.
Wie Du das in FTUI3 anzeigst, bleibt Dir überlassen. Ich mache es über ein Popup.
Eine "Schleifen-Funktion" gibt es meines Wissens nicht in FTUI3.
Damit "Over and out".
Das mit dem doif ist klar. Aber woher weis man dann im Vorfeld wieviele Einträge darzustellen sind? Wenn es immer eine feste gleiche Anzahl gäb - ok. Aber das ist ja bei den gewünschten Szenarien nicht gegeben
In dem Du eine generische Abfrage definierst.
Ich habe hier nur Sensoren fest "verdratet", da ich Tür und Fenster unterscheiden wollte und die gleiche Art von Sensoren verwende. Wäre eventuell auch anders gegangen.
Internals:
DEF ## Visualisierung offener Türen und Fenster
FUUID 652ee6da-f33f-a57c-8697-7b3137d7c19e6c3c
MODEL FHEM
NAME di_uiTable_windows
NOTIFYDEV global,.*(0007DF29950D53$).*,di_uiTable_windows,.*(^HMIP|^HM_Sec_RHS|OEQ0424862$).*,.*(HM|HmIP_SRH).*
NR 259
NTFY_ORDER 50-di_uiTable_windows
STATE initialized
TYPE DOIF
VERSION 29460 2024-12-29 20:25:48
eventCount 166
READINGS:
2024-05-09 12:23:24 cmd 0
2025-08-10 17:57:16 count 0
2025-08-10 13:23:42 doors alles zu
2024-05-09 12:23:24 mode enabled
2024-05-09 12:23:24 state initialized
2025-08-10 15:05:00 windows alles zu
Regex:
accu:
bar:
barAvg:
collect:
event_Readings:
:
count:
"HM|HmIP_SRH" HM|HmIP_SRH
doors:
"0007DF29950D53$:^state|OEQ0223456$:^state" 0007DF29950D53$:^state|OEQ0223456$:^state
windows:
"^HMIP|^HM_Sec_RHS|OEQ0424862$:^state" ^HMIP|^HM_Sec_RHS|OEQ0424862$:^state
uiTable:
di_uiTable_windows:
di_uiTable_windows_uiTable_c_0_1_0_0:
windows ^di_uiTable_windows$:^windows:
di_uiTable_windows_uiTable_c_0_2_0_0:
windows ^di_uiTable_windows$:^windows:
di_uiTable_windows_uiTable_c_1_1_0_0:
doors ^di_uiTable_windows$:^doors:
di_uiTable_windows_uiTable_c_1_2_0_0:
doors ^di_uiTable_windows$:^doors:
di_uiTable_windows_uiTable_c_2_1_0_0:
count ^di_uiTable_windows$:^count:
condition:
do:
0:
event_Readings:
count ::AggregateDoIf($hash,'#','HM|HmIP_SRH','state','"open|tilted"','"0"')
doors ::AggregateDoIf($hash,'@as(<br>)','0007DF29950D53$','state','"open|tilted"','"alles zu"')
windows ::AggregateDoIf($hash,'@as(<br>)','^HMIP|^HM_Sec_RHS|OEQ0424862$','state','"open|tilted"','"alles zu"')
helper:
NOTIFYDEV global,.*(0007DF29950D53$).*,di_uiTable_windows,.*(^HMIP|^HM_Sec_RHS|OEQ0424862$).*,.*(HM|HmIP_SRH).*
event 2.POWER: 0.02
globalinit 1
last_timer 0
sleeptimer -1
triggerDev HM_ES_PMSw1_Pl_DN_R1_NEQ1662710
triggerEvents:
2.POWER: 0.02
triggerEventsState:
2.POWER: 0.02
perlblock:
uiState:
uiTable:
dev di_uiTable_windows
header
<table uitabid='DOIF-di_uiTable_windows' class=' block wide uiTabledoif doif-di_uiTable_windows ' style='border-top:none;'>
package package ui_Table;
reading count
table:
0:
0:
0:
0 package ui_Table;"Fenster"
1:
0:
0 package ui_Table;::DOIF_Widget($hash,$reg,'di_uiTable_windows_uiTable_c_0_1_0_0',icon(::ReadingValDoIf($hash,'di_uiTable_windows','windows'),"fts_window_roof_open_2\@red","fts_window_roof\@black",".*","alles zu"),'','di_uiTable_windows','windows')
2:
0:
0 package ui_Table;::DOIF_Widget($hash,$reg,'di_uiTable_windows_uiTable_c_0_2_0_0',::ReadingValDoIf($hash,'di_uiTable_windows','windows'),"")
1:
0:
0:
0 package ui_Table;"Türen"
1:
0:
0 package ui_Table;::DOIF_Widget($hash,$reg,'di_uiTable_windows_uiTable_c_1_1_0_0',icon(::ReadingValDoIf($hash,'di_uiTable_windows','doors'),"fts_door_open\@red","fts_door\@black",".*","alles zu"),'','di_uiTable_windows','doors')
2:
0:
0 package ui_Table;::DOIF_Widget($hash,$reg,'di_uiTable_windows_uiTable_c_1_2_0_0',::ReadingValDoIf($hash,'di_uiTable_windows','doors'),"")
2:
0:
0:
0 package ui_Table;"Anzahl"
1:
0:
0 package ui_Table;::DOIF_Widget($hash,$reg,'di_uiTable_windows_uiTable_c_2_1_0_0',::ReadingValDoIf($hash,'di_uiTable_windows','count'),"")
tc:
1 align='center'
2 align='left'
td:
0:
1:
2:
tr:
Attributes:
addStateEvent 1
alias Fenster- und Türstatus
devStateStyle style="text-align:right"
event-on-change-reading .*
event_Readings windows:[@as(<br>)"^HMIP|^HM_Sec_RHS|OEQ0424862$:^state":state:"open|tilted","alles zu"],
doors:[@as(<br>)"0007DF29950D53$:^state|OEQ0223456$:^state":state:"open|tilted","alles zu"],
count:[#"HM|HmIP_SRH":state:"open|tilted","0"]
group Fenster-/Türkontakte
room Statuszentrale
uiTable {
package ui_Table;
$TC{1}="align='center'";
$TC{2}="align='left'";
}
"Fenster"|icon([$SELF:windows],"fts_window_roof_open_2\@red","fts_window_roof\@black",".*","alles zu")|[$SELF:windows]
"Türen"|icon([$SELF:doors],"fts_door_open\@red","fts_door\@black",".*","alles zu")|[$SELF:doors]
"Anzahl"|[$SELF:count]
Es ist einfach Unsinn, in einer solchen Abfrage alle Türen und Fenster gleich behandeln zu wollen. Beispiel: Bei schlechtem Wetter ist es hoch relevant, ob ein Dachfenster geöffnet ist. Bei einer Sicherheitsabfrage eher nicht.
Der beste Weg ist eine Liste, die jedem Fenster und jeder Tür Attribute zuordnet - z.B. "RS" für "Regen" und "Sicherheit", oder nur "S" für Sicherheit, oder ein "T" darin bei Türen.
Diese Liste kann man entweder in einer Perl-sub fest anlegen - zumindest für den Anfang ist das der richtige Weg. Und dann bei Funktionsfähigkeit des Codes in ein userAttr auslagern. Jedes Fenster "weiß" damit, für welche Abfragen es in Frage kommt.
Natürlich kann man das dann mit einer einzigen Abfrage
list .*:FILTER=usw machen. Allerdings kommt jetzt noch ein Punkt hinzu: Eine Ausgabe als triviale Liste aller Devices ist etwas für Unwissende. Um das in eine lesbare Form umzuwandeln, muss man schon manuell nacharbeiten. Also in jedem Fall eine nette kleine Perl-sub anlegen. Im Bild sieht man einen Ausschnitt aus dem Feld in FTUI3, das ich mit einem Rotor-Device belegt habe.
<ftui-rotor animation="fade" interval="5">
<ftui-cell>
<ftui-label style="font-weight:bold" size="18px">Haus</ftui-label>
<ftui-label [text]="secProfileC:weblink | ftui_linebreaker()" scroll size="15px">
</ftui-label>
</ftui-cell>
<ftui-cell>
<ftui-label style="font-weight:bold" size="18px">System</ftui-label>
<ftui-label [text]="secProfileC:weblink2 | ftui_linebreaker()" scroll size="15px">
</ftui-label>
</ftui-cell>
... mehrere weitere Zellen
</ftui-rotor>Ach ja: die Funktion zum Zeilenumbruch muss man natürlich im FTUI3 auch noch hinzufügen
//-- helper function for linebreak
function linebreaker(lines) {
let linea = lines.split('<br>');
let num = linea.length;
let ret = '<ul style="list-style-type:none;margin-left:0px;">';
for (var i = 0; i < num; i++) {
ret += '<li>' + linea[i] + '</li>';
}
ret += '</ul>';
return ret;
}
LG
pah