neue Features: Generalisierung mit Templates

[mumpitzstuff]

Es liegt an der Funktion DOIF_DEF_TPL. Benenne ich diese um und rename DOIF_DEF_TPL_OLD zu DOIF_DEF_TPL, funktioniert alles wieder.

Code Auswählen Erweitern

# parameter: device name, mode (next or prime), channel name (see xml data file), icon name (filename of channel logo)
DEF TPL_TV(showIcon("$4",undef,undef)|substr([$1:$2_$3_000_btime],0,5)|unfold([$1:$2_$3_000_title],[$1:$2_$3_000_stitle]."\n\n".[$1:$2_$3_000_desc])|substr([$1:$2_$3_001_btime],0,5)|unfold([$1:$2_$3_001_title],[$1:$2_$3_001_stitle]."\n\n".[$1:$2_$3_001_desc])|substr([$1:$2_$3_002_btime],0,5)|unfold([$1:$2_$3_002_title],[$1:$2_$3_002_stitle]."\n\n".[$1:$2_$3_002_desc]))

# parameter: device name, mode (next or prime), channel name (see xml data file), icon name (filename of channel logo), device name for set command, command
DEF TPL_TVSET(showIcon("$4","$5","$6")|substr([$1:$2_$3_000_btime],0,5)|unfold([$1:$2_$3_000_title],[$1:$2_$3_000_stitle]."\n\n".[$1:$2_$3_000_desc])|substr([$1:$2_$3_001_btime],0,5)|unfold([$1:$2_$3_001_title],[$1:$2_$3_001_stitle]."\n\n".[$1:$2_$3_001_desc])|substr([$1:$2_$3_002_btime],0,5)|unfold([$1:$2_$3_002_title],[$1:$2_$3_002_stitle]."\n\n".[$1:$2_$3_002_desc]))

Innerhalb der uiTable stört sich DOIF jetzt an den beiden Kommentaren über den DEF Definitionen. Entferne ich beide Kommentare, dann geht es auch mit der unveränderten DOIF Version wieder.

[Ellert]

Kommentare in DOIF Definitionen: https://commandref.fhem.de/commandref_DE.html#DOIF_Lesbarkeit_der_Definitionen

[Damian]

Es liegt an der Funktion DOIF_DEF_TPL. Benenne ich diese um und rename DOIF_DEF_TPL_OLD zu DOIF_DEF_TPL, funktioniert alles wieder.

Code Auswählen Erweitern

# parameter: device name, mode (next or prime), channel name (see xml data file), icon name (filename of channel logo)
DEF TPL_TV(showIcon("$4",undef,undef)|substr([$1:$2_$3_000_btime],0,5)|unfold([$1:$2_$3_000_title],[$1:$2_$3_000_stitle]."\n\n".[$1:$2_$3_000_desc])|substr([$1:$2_$3_001_btime],0,5)|unfold([$1:$2_$3_001_title],[$1:$2_$3_001_stitle]."\n\n".[$1:$2_$3_001_desc])|substr([$1:$2_$3_002_btime],0,5)|unfold([$1:$2_$3_002_title],[$1:$2_$3_002_stitle]."\n\n".[$1:$2_$3_002_desc]))

# parameter: device name, mode (next or prime), channel name (see xml data file), icon name (filename of channel logo), device name for set command, command
DEF TPL_TVSET(showIcon("$4","$5","$6")|substr([$1:$2_$3_000_btime],0,5)|unfold([$1:$2_$3_000_title],[$1:$2_$3_000_stitle]."\n\n".[$1:$2_$3_000_desc])|substr([$1:$2_$3_001_btime],0,5)|unfold([$1:$2_$3_001_title],[$1:$2_$3_001_stitle]."\n\n".[$1:$2_$3_001_desc])|substr([$1:$2_$3_002_btime],0,5)|unfold([$1:$2_$3_002_title],[$1:$2_$3_002_stitle]."\n\n".[$1:$2_$3_002_desc]))

Innerhalb der uiTable stört sich DOIF jetzt an den beiden Kommentaren über den DEF Definitionen. Entferne ich beide Kommentare, dann geht es auch mit der unveränderten DOIF Version wieder.

ja, dann hat es zufällig funktioniert. DOIF-Kommentare immer mit doppelten Hashzeichen ## beginnen, es sei denn man befindet sich in einem Perlblock, dann kümmert sich der Perlinterpreter um die Kommentare, ## stört aber auch dort nicht.

[mumpitzstuff]

Ah cool danke.

[kjmEjfu]

Kann man eigentlich bei den Zeiten auch einen Zufallsaspekt reinbringen?

Wenn ich mir das Beispiel unter https://wiki.fhem.de/wiki/DOIF/Automatisierung#Helligkeitsabh.C3.A4ngige_Zeitsteuerung_f.C3.BCr_mehrere_Szenarien_mit_tabellarischer_.C3.9Cbersicht anschaue, dann sind die Zeiten dort fix.

Aktuell, noch ohne das Template, nutze ich sowas für die Zeit

Code Auswählen Erweitern

[?([06:15]-int(rand(900)))-([22:00]+int(rand(300)))]

Wäre praktisch, wenn man in dem obigen Beispiel sowas auch einfach in der Zeitspanne eintragen könnte

[Damian]

Kann man eigentlich bei den Zeiten auch einen Zufallsaspekt reinbringen?

Wenn ich mir das Beispiel unter https://wiki.fhem.de/wiki/DOIF/Automatisierung#Helligkeitsabh.C3.A4ngige_Zeitsteuerung_f.C3.BCr_mehrere_Szenarien_mit_tabellarischer_.C3.9Cbersicht anschaue, dann sind die Zeiten dort fix.

Aktuell, noch ohne das Template, nutze ich sowas für die Zeit

Code Auswählen Erweitern

[?([06:15]-int(rand(900)))-([22:00]+int(rand(300)))]

Wäre praktisch, wenn man in dem obigen Beispiel sowas auch einfach in der Zeitspanne eintragen könnte

Dann trage es einfach ein:

push (@{$VAR{sc}},[split (/\| +/,q(Erdgeschoss| Daemmerung2| [?([06:15]-int(rand(900)))-([22:00]+int(rand(300)))]| Lampekueche,LampeFlur on| Lampekueche,LampeFlur off| 01-01| 12-31| off| on))]);;\

Du kannst den Funktionsaufruf rand()  auch in die if-Abfrage einbauen und nur die Zeiten übergeben.

[Sany]

Hallo Damian,
ist zwar ein "alter" Thread, aber meine Frage passt trotzdem zum Titel:

ist es möglich, analog zu ui_table, TPL-Definitionen in eine Datei auszulagern? Für ui_table habe ich das schon verwendet, jetzt würde ich gerne für meine 19 Rolladen, von denen jeder ein DOIF hat zur "Zustandsberechnung", dieses so generalisieren, dass ich nur einmal den Code in einer Datei habe und in jedem DOIF dann nur noch die Definitionen für den jeweiligen Aktor, Fensterkontakt etc hinterlegt werden.?
Ich habe z.Zt. 3 verschiedene Aktoren (FS20-RSU, Homematic und Shelly), wobei die FS20-RSU eben "doof" sind und keine Rückmeldiungen geben, die anderen beiden schon, allerdings etwas unterschiedlich. Das, denke ich, bekomme ich per Generalisierung hin, nur müßte ich trotzdem den DEF TPL Teil in allen DOIFs drinhaben, was bei Änderungen aufwendig ist.

Ich hab schon ein wenig rumprobiert, allerdings ohne Erfolg, weshalb ich im Moment davon ausgehe: das geht nicht
(Alle 19 Rollos in einem DOIF möchte ich auch nicht, da ich die Ergebnisse der einzelnen DOIF wiederum zur Anzeige in anderen verwende.)

Danke schon mal.


Sany

[Damian]

Hallo Damian,
ist zwar ein "alter" Thread, aber meine Frage passt trotzdem zum Titel:

ist es möglich, analog zu ui_table, TPL-Definitionen in eine Datei auszulagern? Für ui_table habe ich das schon verwendet, jetzt würde ich gerne für meine 19 Rolladen, von denen jeder ein DOIF hat zur "Zustandsberechnung", dieses so generalisieren, dass ich nur einmal den Code in einer Datei habe und in jedem DOIF dann nur noch die Definitionen für den jeweiligen Aktor, Fensterkontakt etc hinterlegt werden.?
Ich habe z.Zt. 3 verschiedene Aktoren (FS20-RSU, Homematic und Shelly), wobei die FS20-RSU eben "doof" sind und keine Rückmeldiungen geben, die anderen beiden schon, allerdings etwas unterschiedlich. Das, denke ich, bekomme ich per Generalisierung hin, nur müßte ich trotzdem den DEF TPL Teil in allen DOIFs drinhaben, was bei Änderungen aufwendig ist.

Ich hab schon ein wenig rumprobiert, allerdings ohne Erfolg, weshalb ich im Moment davon ausgehe: das geht nicht
(Alle 19 Rollos in einem DOIF möchte ich auch nicht, da ich die Ergebnisse der einzelnen DOIF wiederum zur Anzeige in anderen verwende.)

Danke schon mal.


Sany

Den Import-Befehl gibt es nur bei ui_table.

Poste mal ein Beispiel einer Definition, die du verallgemeinern willst.

[Sany]

Den Import-Befehl gibt es nur bei ui_table.

dann lag ich mit meiner Annahme ja richtig. Macht nix, ich hatte bisher auch den gesamten Code in jedem DOIF, mit entsprechenden Abweichungen. Aber große Teile sind identisch, was ich mit subs{} nutzen kann (die gehen ja auch auszulagern, das müßte ich mal versuchen. Allerdings habe ich in den subs teilweise direkte set_Readings und Variablen, das müßte ich dann per Parameter-Übergabe und Rückgaben lösen.

Andere frage noch, ginge so etwas mittels DEF TPL...

Code Auswählen Erweitern

DEF TPL_irgendwas(

block1{
if($1 eq "FS20"){
if([$2:"pct"]{
mach was für A;
Ausfuehrung();
}
}
}

block2{
if($1 eq "SH25"){
if([$2:"level"]{
mach was für B;
Ausfuehrung();
}
}
}
block3{
if($1 eq "HM"){
if([$2:"pct"]{
mach was für C;
Ausfuehrung();
}
}
}

block99{
irgenwas, was unabhängig vom Gerätetyp immer ausgeführt wird
auch mit Parametern aus der Definition unten
}

) ## end DEF_TPL

subs
{
sub Ausfuehrung
{
...
...
}


} ##end subs

##              Typ   Auslöser
TPL_irgendwas (FS20, TriggerA)

## in einem weiteren DOIF der selbe Code mit
TPL_irgendwas (SH25, TriggerB)
## und im 3ten DOIF dann
TPL_irgendwas (HM, TriggerC)



Das sollten dann 3 DOIFs sein, abhängig von definierten Gerät (FS20/SH25/HM) wird aber nur der jeweilige Block ausgeführt. Bei weiteren  Blöcken müßten diese halt auch ein if($1 eq "xx") drumrum haben. Ich werde das mal so ausprobieren, komme aber nicht sofort dazu.

Fertigen Code gibt es noch nicht. Ich habe zwar alle Rollladen per DOIF gesteuert, das wollte ich aber in nächster Zeit neu auflegen, da ich noch nicht ganz zufrieden bin. Dann halt mit möglichst viel "Generalisierung".

Gruß

Sany

[Damian]

Wenn ich wieder etwas Zeit zum Programmieren finde, dann kann ich versuchen den Import-Befehl einzubauen.

[Sany]

also für mich ist das nicht nötig. Ich glaube, ich komme mit den gegebenen Möglichkeiten zurecht. Wenn Du es allerdings generell nützlich für die Generalisierung siehst dann freue ich, wenn es realisiert wird.

Gruß


Sany

[Damian]

also für mich ist das nicht nötig. Ich glaube, ich komme mit den gegebenen Möglichkeiten zurecht. Wenn Du es allerdings generell nützlich für die Generalisierung siehst dann freue ich, wenn es realisiert wird.

ja, ich würde es dennoch nicht auf mehrere DOIFs verteilen, sondern in einem DOIF realisieren. Das dürfte die Pflege vereinfachen, da nur ein Device alles regelt.

Das Rezept lautet:

1) Man baut sich ein Template für die Steuerung für ein Szenarium in einem DOIF
2) Man definiert ein Array für seine Szenarien
3) Über einen FOR-Befehl wird über das Template für jedes Szenarium mit Hilfe des Arrays automatisch die Steuerung erstellt

Damit kann ein DOIF beliebig viele gleich aufgebaute Steuerungen (Szenarien) bedienen.

Damit man dann noch die Übersicht behält, kann man ebenfalls über einen FOR-Befehl die Visualisierung für alle Szenarien erstellen lassen

Hier habe ich am Beispiel aufgezeigt, wie das geht:

https://wiki.fhem.de/wiki/DOIF/Automatisierung#Helligkeitsabh.C3.A4ngige_Zeitsteuerung_f.C3.BCr_mehrere_Szenarien_mit_tabellarischer_.C3.9Cbersicht