- √ - Zeitschaltuhr Plugin?

[Linuxer]

Geht natürlich.
Ich hatte es vergessen zu posten, weil du schon selber geschrieben hattest das dies der entscheidende Punkt ist.
Alles schön. Danke für dieses tolle Plugin.

[emax]

Neue Features

Ich habe eine neue Version ins svn gestellt.

Das Plugin beherrscht nun auch Zeitzonen. Die Details sind in der emx_uhr.sample.conf dokumentiert.

Wozu das Ganze?

Beipiel: Eine Aktion soll immer nach der 'guten alten Zeit' ausgeführt werden, und zwar um 12:00 Uhr. "Gute Alte Zeit" soll heissen, dass die Sommerzeit ignoriert werden soll, weil sich die Aktion z.B. nach dem Sonnenstand richtet: Sie soll nämlich immer dann ausgeführt werden, wenn sie im Zenit steht, Und jetzt bitte jetzt keine astronomie-Korinthen kacken, es geht um die Erklärung des Prinzips und nicht um ein paar Minuten. ;-)

Also wäre der Schaltzeitpunkt im Winter um 12:00 lokaler Zeit, im Sommer aber um 13:00 Uhr lokaler Zeit anzugeben.

Das ist nun über die Zeitzone einstellbar:

{ ... Std=>'12', Min=>'0', Zone=>'CET' ... }

Die Angabe 'CET' gibt dabei an, dass die Schaltung nach 'C'entral 'E'uropean 'T'ime durchgeführt werden soll.

Wer zum Beispiel möchte, dass er immer bei Eröffnung der New-Yorker Börse eine Benachrichtigung bekommt, kann das entweder in New-Yorker Zeit oder in lokaler Zeit angeben:

{ Name=>'NYSE_Ortszeit', Std=>'9', Min=>'30', Zone=>'EST' ... }
{ Name=>'NYSE_Berlinerzeit'... Std=>'15', Min=>'30' ... }

Bei der lokalen Zeit muss er dann allerdings schon wieder drüber nachdenken, ob die auch bei Beginn unserer Sommerzeit noch stimmt, oder nicht. Bei Angabe der Zone EST dagegen bekommt er immer den korrekten Zeitpunkt.

Ich bitte um Tests. Fehler bitte hier posten.

Doku ist in der conf.sample

Bei der Gelegenheit möchte ich mal drüber meckern, dass es offensichtlich kaum eine Sau interessiert, um was hier eindringlich gebeten wurde. Ich hebe das noch einmal hervor:

Ich habe mit Makki vereinbart, dass folgende Vorgaben unbedingt einzuhalten sind:

• Ein Plugin muss auch dann fehlerfrei ausführen, wenn keine Konfigurationsdatei gefunden wird. Es muss sich in dieser Hinsicht also tolerant verhalten.
  ...
  
• Jedes Plugin welches das Konzept nutzt, muss mit einer Beispielkonfiguration geliefert werden.
  
• Die Beispieldatei muss den Namen pluginname.conf.sample, haben, denn nur so kann verhindert werden, dass beim Auspacken die original Konfigurationsdatei eines Nutzers überschrieben wird.

Ich bitte die Protagonisten höflichst, das doch gelegentlich nachzuholen. svn erlaubt auch das Umbenennen von Dateien, das ist also keine große Sache. Bei uns im Projekt fliegen auf Dauer auch gute Leute wegen solcher Sachen raus: Wegen 'mangelnder Teamfähigkeit'.

Und jetzt bin ich wieder lieb ;-)

[StefanW]

Hallo emax,

danke sehr für die klaren Worte.

Wenn die Vorgaben nicht eingehalten werden, dann könnte man die betreffenden Plugins aus dem SVN löschen.

Eine gewisse Mindestqualität muss gegeben sein, weil sonst haben die Nutzer nichts davon.

Wünsche ein wunderbares und erholsames Wochenende


glg


Stefan

[JuMi2006]

Darf ich an dieser Stelle mal fragen wie man eine .conf einbindet???
Ich hab ja mittlerweile auch das ein oder andere Plugin geschrieben und da würde mich das mal in "verständlich erklärt" interessieren.
So kann man nämlich auch "verhindern" das hanswurst und nixversteh im plugin an Sachen dreht die dann Support benötigen.

Das scheint auch deutlich unterdokumentiert zu sein. Ich erkläre mich auch bereit das dann mal für User und auch zukünfitge Comitter als kleine Doku zusammen zu fassen (screenshots etc.)
Für mich übrigens auch ein Punkt warum ich die scheinbar guten Plugins von emax noch nicht nutze.

[emax]

Naja, es ist so einfach, dass die Angaben aus dem oben verlinkten Beitrag #73 eigentlich ausreichen.

Schau mal in z.B. das emx_sonne.pl Plugin. Da gibt es die Funktion

sub readConf

die macht das alles. Die muss man sich in sein eigenes Plugin kopieren. Man muss sie dann nur aufrufen, z.B. so:

&readConf();

und danach ist die conf-Datei eingelesen. Bitte beachten: Variablen, die man im Plugin benötigt, müssen dort, also im Plugin selber, vor dem Aufruf von readConf deklariert werden, also z.B. so:

my $pluginVar = "standard Wert";

In der .conf Datei werden sie dann ohne 'my' (!!) einfach verwendet, sie wurden ja bereits im Plugin selber deklariert.

Die rot markierte Initialisierung ist wichtig! Natürlich mit einem für das jeweilige Plugin angepassten Wert, das ist ja nur ein Beispiel. Wenn nämlich keine .conf Datei gefunden wird, hat die besagte Variable wenigstens einen vernünftigen Inhalt, mit dem das Plugin auch ohne eine Konfigurationsdatei korrekt arbeitet.

[lio123]

Ich hab da mal kurz was zusammengestrikt. Ist aber noch ungetestet. Pro Schaltpunkt wird unter Einstellungen einfach die Zeile die mit push beginnt kopiert und angepasst. Damit kann man quasi unendlich viele Schaltpunkte einrichten.

mit diesem schlanken Plugin, war es mir möglich, in kürzester Zeit, die Bewässerungsanlage für den frisch verlegten Rollrasen so zu programmieren, dass beruhigt den 3/4 Tag mit meiner Familie im Schwimmbad verbringen konnte!

Das automatisierte Haus lässt Grüßen und herzlichsten Dank!

Grüße,
Lio

[swiss]

So...

Heute werde ich dann endlich auch mal dazu kommen die wichtigsten Plugins wie das ComfoAir und das Denon-Plugin mit conf.d auszurüsten Sollte ja mit der oben genannten Anleitung kein Problem werden

[emax]

Das finde ich sehr gut.

Wenn Du Fragen hast, nur zu. Ich helfe gerne. :-)

[JuMi2006]

Über die .conf sollte man nochmal sprechen.
Es gibt auch unterschiedlichste Codes hier mit der .conf umzugehen. Mal wird in der .conf deklariert, mal im Plugin.

Wenn eine .conf erforderlich ist und sie nicht existiert sollte das Plugin m.M.n. eher garnichts machen als mit "irgendwelchen" Werten vom Programmierer im fremden Bus "irgendwas" zu machen.

Ist aber eher einen separaten Beitrag wert als hier das Thema zu kapern.

Gruß Mirko

[emax]

Da gibt es eigentlich nichts zu besprechen. Das ist alles genau festgelegt und wurde in diesem Thread mehrfach beschrieben, gerade mal ein paar Beiträge zuvor.

z.B: "Ein Plugin muss auch dann fehlerfrei ausführen, wenn keine Konfigurationsdatei gefunden wird. Es muss sich in dieser Hinsicht also tolerant verhalten."

Und Variablendeklarationen für Variablen des Plugins haben in der .conf nichts zu suchen. Punkt.

[JuMi2006]

Ich sprach nur davon was es gibt ... nagut mach ich nen Haken dran.
Ist ja scheinbar und ganz offensichtlich für jeden zu finden diese Vereinbarung.
Punkt.

[emax]

Ja. Weiter oben fett und in Rot.

Was ist denn unklar?

[JNK]

Vor allem Dein arroganter Tonfall.

[emax]

Ich meinte, ob technisch was unklar ist?

[Fry]

Ich werfe hier mal ein, dass das Perl-Motto eigentlich ist, dass es "a million ways" zum Ziel gibt.

Insofern - lasst den Leuten doch jeweils ihren Weg. Es ist ja nicht so, dass wir in Plugins ertrinken. Das SVN ist sehr spärlich gefüllt. Da sind Ermutigungen an Plugin-Autoren angebracht, nicht Regeln und schon gar kein Polizeiton. Spart euch das auf für die Zeit, wenn es 200 Plugins gibt und davon 150 schlampig geschrieben sind.

Just my 2c,
Fry

PS. Ich erinnere mich an meine ersten Schritte hier im Forum. Da wollten mir einge Foristen weismachen, ein KNX-Testaufbau müsse aus Sicherheitsgründen nach DIN-Normen gebaut werden. Leuchtet mir heute nicht mehr ein als damals... und mein Einwand bleibt der Gleiche: wenn ihr jeden Neuling so begrüßt, könnt ihr den KNX-Hobbybereich bald zumachen, dann wird es nämlich ein sehr elitäres Hobby.