- √ - Zeitschaltuhr Plugin?

[makki]

Es sind auch eine Menge Dinge drin, die ich selber (in Perl) noch nie gemacht habe, zum Beispiel Threads. Kühn eben :-)

Ja, den Fehler macht aber auch nur 1x: Jegliches threading in Perl ist nämlich einfach nur substantiell "kaputt" - oder das was man sonst als einen Prozess mit 100% overhead bezeichen würde

PS: Konnte im SVN übrigens nicht commiten. Entweder habe ich nur Leserechte, oder mein SF-User 'e.max' macht Probleme, weil ein Punkt drin ist. Oder vielleicht braucht's fürs SVN einen extra-Usernamen/Passwort ... ?

Nee, das sollte schon alles passen.. aber vielleicht müssen wir da auch noch lernen: wenns morgen nicht geht bitte melden, die rechte sollten passen soweit ich sehe..

Makki

[emax]

Hat geklappt, aber es lag gestern nicht an Euch: Ich habe zwei SF-Accounts, und gestern natürlich das falsche Passwort verwendet ...

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

[makki]

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

Makki

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

[greentux]

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

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

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

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

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]

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]

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]

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.

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

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!