- √ - Zeitschaltuhr Plugin?

[haegar80]

OK, sorry, das habe ich irgendwie bei meiner Suche nach einem passenden Thread übersehen.
Dann übe ich mich in Geduld und editiere solange direkt die Datei.

Null Problemo!

Wenn ich denke, wie oft ich hier schon Sachen gefragt habe, die im Nachinein banal waren! Ich kann von Glück reden, daß mich keiner von den Cracks hier gesteinigt hat...

[MicHau]

Schande über mich

das ist ein bekanntes Feature:
https://knx-user-forum.de/forum/supp...wiregate/17158

OK, sorry, das habe ich irgendwie bei meiner Suche nach einem passenden Thread übersehen.
Dann übe ich mich in Geduld und editiere solange direkt die Datei.

[haegar80]

Hi Michael,

das ist ein bekanntes Feature:
https://knx-user-forum.de/forum/supp...wiregate/17158

Gruß
Sascha

[MicHau]

Problem beim Editieren der externen Config

Hallo, weil ich es eben gerade entdeckt habe und es vermutlich thematisch hierhin passt:

Ich wollte das Multi-RTR Plugin von Christian anlegen und schon mal vorab meine Heizungssteuerung damit konfigurieren. Beim Klick auf den Link "config" öffnet sich der Editor. Wenn ich aber etwas eintrage und auf "Speichern" klicke, geht das alles verloren. Beim nächsten Aufruf ist die Konfiguration wieder leer. Es wird auch keine Datei angelegt unter "/etc/wiregate/plugin/generic/conf.d/". Nicht einmal das Verzeichnis "conf.d" ist vorhanden.
Habe ich da einen Bug entdeckt oder mache ich etwas falsch? Muss das conf.d-Verzeichnis erst manuell als root angelegt werden, bevor die Editieren-Links funktionieren?

[makki]

Jep, das meinte ich ja auch und so sollte es auch werden, ist aber irgendwo zwischen Thread lesen und umsetzen verloren gegangen

Makki

[emax]

Hm, tja, ok.

Der Einfachheit halber: Ich finde 'myplugin.conf' angemessen. Wenn das eigentliche script 'myplugin' heißt ebenso wie wenn es 'myplugin.pl' heißt. Ist m.E. einfach und klar, in perl-Sprech eben

basename($plugname '.pl').conf

[makki]

Nun, der Link im Editor ist husch-husch auf conf.d/basename ohne .conf
Deshalb wollte ich das nur nochmal verifizieren bevor ich es korrigiere..

Makki

[emax]

Nachtrag: Die plugin_info Einträge nehmen konsequent den kompletten Namen des Plugins, also inklusive '.pl' oder auch irgendeiner anderen Endung. Hier war es mir zu riskant, 'eigenmächtig' einen andern Key zu basteln, weil das im ungünstigsten Fall ja auch in die Hose gehen kann, wenn ein zweites Plugin mit so einem Namen existiert (gibt ja so Spezialisten, die so was machen).

Dort scheint mir das auch unproblematisch, weil diese Einträge a priori nirgendwo so richtig sichtbar sind.

[emax]

Ähm, irgendwas ist durcheinander.

bei mir heißen die Plugins 'myplugin.pl', aus den gleichen Gründen wie bei Makki: Syntax-highlighting (was aber auch anders ginge), aber eben auch, weil es nun mal perl scripte sind.

Die Konfigurationsdateien heissen 'myplugin.conf'. Sind zwar auch perl-Texte, aber eben keine eigenständigen scripte. Die Namen werden von 'readConf' so ermittelt:

[FONT="Courier New"]my $confFile = '/etc/wiregate/plugin/generic/conf.d/'.basename($plugname,'.pl').'.conf';[/FONT]

was nichts anders heißt, als das es 'readConf' egal ist, ob da 'pl' drin steht oder nicht, es findet immer 'myplugin.conf', egal ob das script selber nun ein '.pl' am Ende hat oder nicht.

Jetzt weiß ich nicht so recht, wo's klemmt?,

[makki]

Ich grabe den Thread jetzt nochmal aus, weil es glaube ich der "initiale" für conf.d von Plugins war:
Also, der Vorschlag von emax war bei nochmaligem lesen dann doch $plugname.pl.conf
Alle meine Plugins heissen aber schon .pl damit sie der jew. Editor mit Syntax-highlighting anzeigt Also hätten wir doppelt-gemoppelt;

Zwei Vorschläge:
- so wie es der Link jetzt PL29 (fälschlicherweise) macht $plugname.conf (egal wie $plugname aussieht, mit oder ohne .irgendwas)
- $plugname + .pl.conf, sofern sie nicht bereits .pl$ heisst, sonst eben $plugname(.pl).conf

Makki

[emax]

Wenn Sonnenuntergang nicht passt ...

Da ich meine Rollläden nicht pünktlich zum Sonnenuntergang herunterfahren möchte, habe ich eine Konfiguration geschrieben, die das eine gewisse Zeit nach dem Sonnenuntergang macht. Es steht trotzdem alles in der emx_uhr.conf. Zunächst habe ich diese beiden Funktionen eingefügt:

[FONT="Courier New"]
sub sonnUntHH()
{
    # Rueckgabe Sonnenuntergangs-Stunde + $1 Std
    my $hhOffset = shift;
    return int($plugin_info{'emx_sonne.pl.unt'} + ($hhOffset ? $hhOffset : 0)) % 24;
}

sub sonnUntMM()
{
    # Rueckgabe Sonnenuntergangs-Minute + $1 Minuten
    my $mmOffset = shift;    
    return ($plugin_info{'emx_sonne.pl.untMM'} + ($mmOffset ? $mmOffset : 0)) % 60;
}
[/FONT]

Und in der Tabelle sieht das dann so aus:

[FONT="Courier New"]@Zeiten = 
    (
     # Rollaeden abends zu: Wert '0'=Auf, '1' => Ab
     { Name=>'ELW_RollWohnFenstAb',   Aktiv=>'1', Std=>&sonnUntHH(0.75),  Min=>&sonnUntMM(45), Wert=>'1', DPT=>'1', GA=>'4/2/91', Log=>'1' }, 
     { Name=>'ELW_RollTerasseAb',     Aktiv=>'1', Std=>&sonnUntHH(46/60), Min=>&sonnUntMM(46), Wert=>'1', DPT=>'1', GA=>'4/2/93', Log=>'1' }, 
     { Name=>'ELW_RollSchlafAb',      Aktiv=>'1', Std=>&sonnUntHH(47/60), Min=>&sonnUntMM(47), Wert=>'1', DPT=>'1', GA=>'4/3/121', Log=>'1' }, 
    );[/FONT]

Erläuterung:
Die Werte für Min und Std werden also erst errechnet, wenn die Tabelle ausgewertet wird. Dabei kann der jeweiligen Funktion ein 'Offset' mitgegeben werden, der die Uhrzeit festlegt. Im o.g. Beispiel sind das nacheinander einmal 45, einmal 46 und einmal 47 Minuten, die Läden schließen also im Abstand von je einer Minute.

Dabei wird der Funktion, die die Stunde errechnet, der Offset in Stunden übergeben, z.B. 0.75. Die Funktion für die Minuten bekommt analog dazu ihren Offset in Minuten, also 45. Da sich ein Stundewert der 46 oder 47 Minuten entspricht nicht so einfach als Kommazahl ausdrücken lässt, habe ich schlicht 46/60 bzw. 47/60 hingeschrieben, was genauso gut geht.

Die Funktionen verwenden die Werte aus dem emx_sonnen.pl Plugin. Da Stunden und Minuten plus Offset immer zu einem Überlauf führen können (also z.B. 75 Minuten, oder 26 Uhr ), wird der Wert als Modulo-Rest zurückgegeben.

Im Gegensatz zur Minuten-Funktion, die direkt den ($plugin_info{'emx_sonne.pl.untMM'} Eintrag verwenden kann, muss die Stundenfunktion den float-Wert aus ($plugin_info{'emx_sonne.pl.unt'} verwenden um die korrekte Stunde zu erhalten.

Wichtig: Da die beiden Funktionen per se unabhängig voneinander sind, müssen auch die Offsets unabhängig übergeben werden, und semantisch selbstredend übereinstimmen: Ein Stundenoffset von 0.75 muss im selben @Zeiten-Tabelleneintrag mit einem Minutenoffset von 45 gepaart sein. Das ist natürlich redundant, aber da beide Funktionen einander agnostisch sind, ist das nur konsequent.

Negative Werte (also vor Sonnenuntergang) habe ich nicht getestet, kann aber gerne mal jemand ausprobieren. Wahrscheinlich müsste für einen 'Unterlauf' unter Null Minuten oder Null Uhr noch was gebastelt werden, aber grundsätzlich könnte man so auch 'vorausschauend' agieren.


PS: eben mit negativen Werten getestet: Scheint auch bei 'Unterlauf'' zu funktionieren, dafür sorgt wohl der Modulo-Operator.

[makki]

@Axel: Das würde zu leichten inkonsistenzen in der Anzeige führen geht aber natürlich irgendwie auch so.

Edit-link (siehe Anhang) gibts im nächsten Update, ungeduldige klicken hier

Ich überlegte gerade noch, ob man die conf.d/$plugname evtl. gleich im Aufruf (im wiregated.pl) mitverarbeitet, also nicht nicht im Plugin extra aufrufen muss ? Bricht natürlich etwas mit dem bisherigen zarten Ansatz (obwohl es nichts macht das 2x zu eval'en) aber das ganz einfache System mit conf.d gefällt mir so gut das es Standard werden sollte Wenn keine Gegenstimme kommt wird das so denke ich(*)
Credit geht da an emax, es ist so einfach und doch so gut, ich mag einfache Dinge

Makki


*: Background: wird dann erneut eval'ed wenn sich plugin oder conf.d/$plugname geändert haben. Aktuell ist das kein Problem aber um vielleicht einen Baum im Regenwald zu retten ist eigentlich geplant die Plugins vorzukompilieren und nur noch erneut zu eval'en (kompilieren) wenn sie sich geändert haben. das wäre dann ein Problem bzw. stark kontraproduktiv wenn das Plugin selbst die conf.d noch selbst eval'ed.
Ausserdem bekommt das Plugin momentan nicht mit wenn sich nur die conf.d ändert, wird also nicht explizit aufgerufen, das sollte es aber IMHO..

[axelp]

Hi,

als Quick&dirty hack habe ich versuchsweise mal das edit_plugins modul um ein paar Zeilen erweitert, so dass es auch die Dateien unter conf.d mit in die Liste aufnimmt:
In der Datei "/usr/share/webmin/wiregate/edit_plugins.cgi" habe ich dazu unter

my @plugins = </etc/wiregate/plugin/generic/*>;
foreach (@plugins) {
    push(@plugin_names, basename($_));
    push(@plugin_dates, (stat($_))[9]);
}

noch

my @AP_plugins = </etc/wiregate/plugin/generic/conf.d/*>;
foreach (@AP_plugins) {
    push(@plugin_names, "conf.d/" . basename($_));
    push(@plugin_dates, (stat($_))[9]);
}

eingefügt.
Wenn ich das richtig verstehe, dürfte das nichts groß ändern, aber das sollte besser jemand kompetenterer beurteilen (Updates von dieser Datei gehen dann natürlich nicht mehr).
Man kann auch Dateien unter conf.d hinzufügen, wenn man bei Pluginname ein conf.d/ voranstellt.

Tschau,
Axel.

[makki]

@Sascha: root-Zugang aktivieren unter Allgemein und dann mit WinSCP; als root anmelden, nicht als user.

UNC (SMB/CIFS) würde theoretisch schon auch gehen, aber das müsste man erst einrichten, da Standardmässig keine Samba-Freigabe existiert (und das auch schnell gefährlich wird wenn man das Root-Filesystem da exportiert.. nicht gut..)

Makki

[emax]

Ich habe die conf.d Version ins svn gestellt.

Wie immer gilt: Erst mal bitte testen, man kann beim Einstellen ins svn immer mal was übersehen.