Vorhin habe ich mal mal etwas ausprobiert, was der Zeitschaltuhr neue Möglichkeiten eröffnet: Variable Konfigurationseinträge. Dazu muss am Plugin nichts geändert werden, es ist nur eine Frage der Konfigurationsdatei.
Beispiel: Rollläden sollen nicht immer um 17 Uhr runter gefahren werden, sondern jeden Tag um eine andere Uhrzeit. Das sollte problemlos mit der Zeitschaltuhr gehen.
Die Lösung: Anstatt feste Werte in die @Zeiten Tabelle einzutragen, trägt man Codereferenzen ein. Das sieht dann z.B. so aus:
Hier blau dargestellt.
Nun muss man die entsprechenden Funktionen nur noch zur Verfügung stellen, hier eine sehr vereinfachte Version:
Das ist alles.
In den Funktionen wird in diesem Beispiel übrigens auf den Wert eines 'fremden' Plugins zugegriffen: Sun.pl. Das kann ein Plugin sein, welches z.B. ein mal am Tag laufen könnte, um die Sonnen Auf-/Untergangszeiten zu berechnen und in %plugin_info zu speichern. Ich nenne dieses Konzept jetzt mal 'Cross-Plugin-Variablen'. Aber vielleicht wird das woanders ja auch schon gemacht, da habe ich keinen Überblick.
Die Funktionen SunsetHH und SunsetMM müssten natürlich in die Konfigurationsdatei geschrieben werden, und zwar VOR der Tabelle @Zeiten. Auf diese Art kann jeder seine ganz persönlichen Funktionen für variable Tabelleneinträge umsetzen.
PS: Es sollte auch möglich sein, die @Zeiten Tabelle direkt mit plugin_info{...} Referenzen zu besetzen, allerdings hat man dann nicht die Möglichkeit, deren Existenz vorher zu testen um nötigenfalls statt dessen einen Default-Wert zurückzugeben, so wie oben demonstriert.
Beispiel: Rollläden sollen nicht immer um 17 Uhr runter gefahren werden, sondern jeden Tag um eine andere Uhrzeit. Das sollte problemlos mit der Zeitschaltuhr gehen.
Die Lösung: Anstatt feste Werte in die @Zeiten Tabelle einzutragen, trägt man Codereferenzen ein. Das sieht dann z.B. so aus:
Code:
[FONT="Courier New"]
@Zeiten =
(
{ Name=>'RolladenWohnFenstAb', Aktiv=>'1', Std=>[COLOR="Blue"]&SunsetHH[/COLOR], Min=>[COLOR="Blue"]&SunsetMM[/COLOR], Wert=>'1', DPT=>'1', GA=>'3/1/91', Log=>'1' },
{ Name=>'RolladenEsszimmerAb', Aktiv=>'1', Std=>[COLOR="Blue"]&SunsetHH[/COLOR], Min=>[COLOR="Blue"]&SunsetMM[/COLOR], Wert=>'1', DPT=>'1', GA=>'3/1/92', Log=>'1' },
);
[/FONT]
Nun muss man die entsprechenden Funktionen nur noch zur Verfügung stellen, hier eine sehr vereinfachte Version:
Code:
[FONT="Courier New"]
sub SunsetHH
{
(!defined $plugin_info{'[COLOR="Red"]Sun.pl[/COLOR].setHH'}) and return 17;
return $plugin_info{'Sun.pl.setHH'};
}
sub SunsetMM
{
(!defined $plugin_info{'[COLOR="Red"]Sun.pl[/COLOR].setMM'}) and return 30;
return $plugin_info{'[COLOR="Red"]Sun.pl[/COLOR].setMM'};
}
[/FONT]
In den Funktionen wird in diesem Beispiel übrigens auf den Wert eines 'fremden' Plugins zugegriffen: Sun.pl. Das kann ein Plugin sein, welches z.B. ein mal am Tag laufen könnte, um die Sonnen Auf-/Untergangszeiten zu berechnen und in %plugin_info zu speichern. Ich nenne dieses Konzept jetzt mal 'Cross-Plugin-Variablen'. Aber vielleicht wird das woanders ja auch schon gemacht, da habe ich keinen Überblick.
Die Funktionen SunsetHH und SunsetMM müssten natürlich in die Konfigurationsdatei geschrieben werden, und zwar VOR der Tabelle @Zeiten. Auf diese Art kann jeder seine ganz persönlichen Funktionen für variable Tabelleneinträge umsetzen.
PS: Es sollte auch möglich sein, die @Zeiten Tabelle direkt mit plugin_info{...} Referenzen zu besetzen, allerdings hat man dann nicht die Möglichkeit, deren Existenz vorher zu testen um nötigenfalls statt dessen einen Default-Wert zurückzugeben, so wie oben demonstriert.
& 
Kommentar