- √ - Zeitschaltuhr Plugin?

[emax]

Hat das denn mal jemand ausprobiert? 18 Downloads ... ?

Ich würde das gerne einchecken :-)

[emax]

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:

[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]

Hier blau dargestellt.

Nun muss man die entsprechenden Funktionen nur noch zur Verfügung stellen, hier eine sehr vereinfachte Version:

[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]

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.

[emax]

Danke Stefan,

da ist noch einiges zu tun, aber das Plugin System ist es wert, gepflegt und verbessert zu werden. Die Doku ist natürlich ein Thema. Ein kleiner Schritt dazu ist, die Beispielkonfigurationen ordentlich zu kommentieren, da sind also alle Mitwirkenden gefragt.

Ansonsten: Tests, bitte!

[StefanW]

Super Klasse !!!

Wow! Sehr schön, sieht gut aus.

Mit der neuen Config-Datei für Plugins eröffnen sich neue Wege der Sauberkeit und Code-Weitergabe.

Bin begeistert!

Und, wenn ich mal träumen darf, in einem weiteren Schritt, könnte man nun damit auch daran denken, eine grafische Oberfläche für die Eingabe / Pflege der Werte schaffen bzw. dies in eine spätere Version der CometVisu einzubinden!

Jetzt müssen wir das alles nur noch dokumentiert bekommen

LG

Stefan

[emax]

Und dann gibt es noch eine Neuerung.

Es wird für die Plugins künftig ein conf.d Verzeichnis geben, das ist mit Makki so abgesprochen:

/etc/wiregate/plugin/generic/conf.d

In diesem Verzeichnis habe ich für das emx_uhr.pl Plugin die Konfigurationsdaten vom Code getrennt, und werde das künftig auch für alle meinen anderen Plugins machen. Ziel ist die Trennung von Daten und Code, denn so muss keiner zwecks persönlicher Anpassung mehr an den Plugins selber rumfummeln, und außerdem erleichtert es die Pflege für die Entwickler: Ich muss meine eigene Konfiguration nun vor dem Checkin nicht mehr aus dem Script schnippeln und durch was anderes ersetzen, denn ich möchte, z.B. beim Decoder-Plugin, ja nicht unbedingt meine Codierung und GA-Daten veröffentlichen.

Bislang nutze ich dieses Konzept nur direkt in emx_uhr.pl codiert. Auf Dauer werde ich die ein oder andere Funktion dazu in einem Package zusammenfassen, damit sich jeder einfach dieser Möglichkeit bedienen kann, z.B. per einfachem Aufruf 'readConfig'.

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.
• Das Verzeichnis für die Konfigurationsdateien ist /etc/wiregate/plugin/generic/conf.d
• Der Name der Konfigurationsdatei ist pluginname.conf, also der Name des Plugins ohne '.pl' plus der Endung '.conf'
• Jedes Plugin welches das Konzept nutzt, muss mit einer Beipielkonfiguration 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.

Als Beispiel ist die neue Version des Uhren-Plugins beigefügt. Sie ist noch nicht im svn, da ich erst gerne ein paar Tests von Euch hätte.

Dieses Beispiel erfüllt alle o.g. Vorgaben. Sofern keine Konfigurationsdatei gefunden wird, tut das Plugin schlicht nichts, und vor allem produziert es dann keinen Fehler. Eine Beipielkonfiguration emx_uhr.conf.sample ist ebenfalls enthalten. Die Kommentare am Ende dieser Datei werden von meinem Editor als Anweisungen zum Editiermodus (nämlich Perl) erkannt, sind also funktional bedeutungslos.

Da hier keine '.tgz' Dateien hochgeladen werden dürfen, und ich '.zip' Dateien nicht leiden kann, heisst das Ding
emx_uhr_conf_d_version_tgz.txt. Es ist trotzdem keine Text-Datei!

Installation:

• Irgend ein Directory anlegen
• Dorthin wechseln
• Datei herunterladen und dort speichern
• Kommando tar xvzf emx_uhr_conf_d_version_tgz.txt ausführen
• Alle entpackten Dateien und das conf.d Verzeichnis nach Bedarf an die entsprechende Stelle im Wiregate kopieren.
• Die emx_uhr.conf.sample Datei in emx_uhr.conf umbenennen oder eine eigene emx_uhr.conf erstellen.
• testen und rückmelden

Viel Spass.

[emax]

Von einem Nutzer weiß ich per PN, dass das nun bei ihm in Ordnung zu sein scheint, er macht noch weitere Tests.

Ich bitte allerdings darum, solche Sachen hier im Thread zu kommunizieren, sowohl Fehler als auch positive Testergebnisse: Das hält die Diskussion lebendig, und ist auch für andere nützlich, die sich vielleicht nicht trauen sich wg. eines Fehlers zu melden.

[emax]

Es gab zwei Rückmeldungen, dass das Plugin nicht alle Einträge korrekt verarbeitet.

Der Fehler lag in der Verarbeitung von Null-Werten. Das sollte nun behoben sein. Ich bitte die Kandidaten, das mal zu testen, und mir eine Rückmeldung zu geben. Bitte auch im Erfolgsfall kurz melden, damit ich den Bug bei mir von der ToDo Liste streichen kann.

Ist im svn.

[emax]

Musste noch eine Aenderung nachschiessen, die Zykluszeiten wurden falsch gesetzt. Jetzt wird bei dynamischer Zyklusanpassung nicht mehr mit 1-Sekunden Leerzyklen hantiert bis es wieder stimmt, sondern die korrekte, nächste Zykluszeit exakt errechnet.

Das bedeutet weniger Systemlast.

Außerdem bereinigt das Script jetzt bei einer neuen Versionsnummer (die kann man im Script frei setzen) alle alten plugin_info Einträge dieses Plugins.

Insgesamt habe ich noch ein paar Sachen vereinfacht.

Ist im svn.



PS: Bitte erst testen, weil ich bei mir natürlich andere Zeittabellen drin habe, und es deshalb nicht exakt übeeinstimmt.

[emax]

Ich habe eine neue Version eingecheckt.

Nur ein kleiner Bugfix:

- der numerische Vergleich in 'sub matches' findet zur Vermeidung von Laufzeitfehlern auf Alphabasis statt. Hatte einer der beiden Werte eine führende Null, und der andere nicht, schlug der Vergleich fehl, also sinngemäß war (7 == 07) unwahr - was natürlich unwahr ist ;-)

Das wurde behoben.

[emax]

Kleines Beispiel für eine Sicherheitsmaßnahme per Schaltuhr:

 [FONT="Courier New"]  # Aussenlicht und Aussensteckdosen zyklisch ausschalten
      { Name=>'ELW_Terrassenlicht',      Aktiv=>'1', Std=>'3,6,9,12,15,18', 
            Min=>'01', Wert=>'0', DPT=>'1', GA=>'1/5/92', Log=>'1' }, 
      { Name=>'ELW_AussenSteckdose',     Aktiv=>'1', Std=>'3,6,9,12,15,18', 
            Min=>'02', Wert=>'0', DPT=>'1', GA=>'2/5/91', Log=>'1' }, 
      { Name=>'KG_WerkstattAussenlicht', Aktiv=>'1', Std=>'3,6,9,12,15,18', 
            Min=>'03', Wert=>'0', DPT=>'1', GA=>'1/5/122', Log=>'1' }, [/FONT]

Die ungeraden Minutenzeiten verwende ich, weil mit der Zeit sonst alle möglichen Dinge genau zur vollen Stunde passieren. Das senkt die Buslast.

Zwischen 18:00 Uhr und 3:00 Uhr morgens passiert nichts, weil das die typische (Party-)zeit ist, in der man ja genau diese Funktionen nicht abgeschaltet haben will.

Wenn ansonsten jemand die Außenlichter oder -steckdosen versehentlich eingeschaltet hat, oder nach Busspannungsausfall die Aktoren nicht das tun, wofür sie programmiert wurden, schalten diese Zeilen die entsprechenden Geräte mehrfach täglich einfach präventiv ab. Besonders nett, wenn man im Urlaub ist, und die vier 500W Panik-Strahler an den Hausecken drei Wochen lang die Stromrechnung strapazieren - weil nach einem Stromausfall die Aktoren spinnen (ich hab zwei solche Kandidaten, die bevorzugte Lage bei Spannungswiederkehr ignorieren die einfach). Und vergessene Außensteckdosen sind eine Freude für jeden Einbrecher.

Für ungetrübte Urlaubsfreuden ließen sich natürlich auch der Herd, die Kaffeemaschine und andere Sorgenkinder einmal oder mehrfach täglich ausschalten:

Sie nach 100 Km Fahrt: "Ojeh, Ich hab die Kaffeemaschine angelassen!"
Er: "Macht nix, die geht in zwei Stunden aus."

Es hat ja schließlich nicht jeder ne Fern-Visu am laufen ...

[makki]

Naja schon eine Schaltuhr mit Perl-Plugin's zu realisieren ist murks aber ein Treppenhausschalter!? Machbar ist es mit Sicherheit und kompliziert ist es auch nicht sonderlich aber der Code wird ein reiner Murx da den Plugins jegliches Multi-Threading fehlt.

Du hast absolut recht, aber ich arbeite aktuelll wieder 2x7 daran.. irgendwann wird das
Das das mit theading in Perl alles Schrott ist, sagt einem halt leider vorher keiner, sonst könnte es schon sei 2008

Makki

P.S: "Inoffiziell" unterstütze ich linknx ja gerne, ist gut, aber das editieren von XML-Files ist nun einfach nicht jedermanns Sache Trotzdem: hier&jetzt ist es da und geht..

[greentux]

Gut, dann ist jetzt der Zeitpunkt gekommen, dochmal linknx anzuwerfen Ich brauch da bissl Motivation.

[swiss]

Trigger GA -> erzeugt Action EIN (DP, GA) für x Sekunden, danach nix oder eben Action AUS (DP, GA).

Naja schon eine Schaltuhr mit Perl-Plugin's zu realisieren ist murks aber ein Treppenhausschalter!? Machbar ist es mit Sicherheit und kompliziert ist es auch nicht sonderlich aber der Code wird ein reiner Murx da den Plugins jegliches Multi-Threading fehlt.

[makki]

Ich bin da leidenschaftslos, solange es im SVN landet damit wir alle es wiederfinden

Makki

[greentux]

Nachdem das Zeitschaltuhrplugin erstmal alles macht, was so anliegt (Mülltonnen, Zirkulationspumpe und anderes), wäre mir noch an einem ebenso flexiblen multplen Treppenlichautomaten gelegen.

Also eine Art:
Trigger GA -> erzeugt Action EIN (DP, GA) für x Sekunden, danach nix oder eben Action AUS (DP, GA).

Neuer Thread oder hier lassen...? Irgenwie wird ja auch zeitabhängig geschaltet...