emx_uhr.pl: Sonnenauf/untergangs-abhängige Schltungen

[emax]

So kompliziert muss man es nicht machen, es geht einfacher. Drauf gekommen bin ich durch die letzte Änderung, man kann wieder den 'Aktiv' Eintrag dafür missbrauchen. Allerdings kann die Syntax für Nicht-Programmierer dadurch schon etwas fordernder werden, obwohl es im Prinzip einfach ist.

Zunächst der Eintrag für 'Aktiv':

Aktiv=>($plugin_info{'emx_sonne.pl.auf'} >= 6.5)

oder wenn man das in echten Minuten angeben möchte auch

Aktiv=>($plugin_info{'emx_sonne.pl.auf'} >= (6.0 + 30/60))

Nun die Erläuterung, zunächst auf Fachchinesisch: Dieser Term evaluiert zu 'true', wenn der Wert des Hash-Eintrages %plugin_info{'emx_sonne.pl.auf'} größer/gleich 6.5 ist. Andernfalls evaluiert der Ausdruck zu 'false'.

Nun nochmal auf Deutsch:

Der Wert $plugin_info{'emx_sonne.pl.auf'} enthält den Sonnenaufgang als Fliesskommazahl. Der Vergleich $plugin_info{'emx_sonne.pl.auf'} >= 6.5 ergibt nun entweder 'wahr', was als '1' zu verstehen ist, oder 'falsch', was einer Null entspricht. Das Ergebnis landet in 'Aktiv'.

Das geht natürlich ebenso für >= (größer/gleich) Vergleiche wie für <= (kleiner/gleich), für emx_sonne.pl.auf ebenso wie für emx_sonne.pl.unt. Wer sich seine %plugin_info im Wirgate Web-Frontend mal ansieht, wird vielleicht noch mehr interessante Werte finden. Vergleiche auf '==' (ist gleich) sind übrigens kritisch, weil Fließkommazahlen in perl (und fast allen anderen Sprachen) eine unpräzise Sache sind. Da wird zum Beipiel 1.99 intern auch mal als 1.8999999 abgebildet, weshalb ich generell 'weichere' Vergleiche wie >= oder <= empfehle. Wers trotzdem mit 'ist gleich' versuchen möchte, muss zwei (!) ist-gleich Zeichen verwenden.

Viel Erfolg damit, und immer genau nach so gemeinen Dingen wie Kommata, Apostrophen, Klammern geschweifter und runder Art usw. schauen, die pfuschen einem nämlich öfter mal dazwischen


PS: Im vorliegenden Fall 'Rolläden' fährt im Beispiel der Rolladen nur dann hoch, wenn der Sonnenaufgang später oder gleich 6:30 Uhr stattfindet. Ist er früher, bleibt der Rolladen unten. Logischerweise muss im letzteren Fall dann ein zweiter Eintrag her, der das dann irgendwann erledigt.

[Elo]

Vielen Dank für diese Erklärung. Falls ich es richtig verstanden habe, könnte ein mögliches Beispiel dann so aussehen:


# Rolllaeden Z1 ab: 5 Minuten nach Sonnenuntergang, wenn Sonnenuntergang nach 20:00 Uhr, sonst um 20:00 Uhr
{ Name=>'Z1_Roll_Ab', Aktiv=>($plugin_info{'emx_sonne.pl.unt'} <= 20) , Std=>'20', Min=>'0', Wert=>'1', DPT=>'1', GA=>'1/4/55', Log=>'1' },
{ Name=>'EG_Roll_Ab', Aktiv=>($plugin_info{'emx_sonne.pl.unt'} > 20) , Std=>&sonnUntHH(5/60), Min=>&sonnUntMM(5/60), Wert=>'1', DPT=>'1', GA=>'1/4/55', Log=>'1' },


Darf der Wert bei &sonnUntHH(5/60) auch Null sein, also &sonnUntHH(0)? (ebenso bei MM)

[emax]

Vielen Dank für diese Erklärung. Falls ich es richtig verstanden habe, könnte ein mögliches Beispiel dann so aussehen:


# Rolllaeden Z1 ab: 5 Minuten nach Sonnenuntergang, wenn Sonnenuntergang nach 20:00 Uhr, sonst um 20:00 Uhr
{ Name=>'Z1_Roll_Ab', Aktiv=>($plugin_info{'emx_sonne.pl.unt'} <= 20) , Std=>'20', Min=>'0', Wert=>'1', DPT=>'1', GA=>'1/4/55', Log=>'1' },
{ Name=>'EG_Roll_Ab', Aktiv=>($plugin_info{'emx_sonne.pl.unt'} > 20) , Std=>&sonnUntHH(5/60), Min=>&sonnUntMM(5/60), Wert=>'1', DPT=>'1', GA=>'1/4/55', Log=>'1' },

Genau so (wenn ich nichts übersehen habe). Allerdings passiert dann nichts, wenn der Sonnenuntergang um genau 20:00 Uhr ist ;-)

Also besser so $plugin_info{'emx_sonne.pl.unt'} >= 20) machen.

Darf der Wert bei &sonnUntHH(5/60) auch Null sein, also &sonnUntHH(0)? (ebenso bei MM)

Ja, darf er.

[Elo]

Also besser so $plugin_info{'emx_sonne.pl.unt'} >= 20) machen.

Prima, dann werde ich es mal ausprobieren.
">" habe ich genommen, da genau 20:00 ja schon mit "<=" im ersten Fall abgefangen wird.

[Elo]

emx_uhr.pl: Sonnenauf/untergangs-abhängige Schltungen

Leider funktioniert es so nicht, es wird zu der in der ersten der beiden Config-Zeilen angegebenen festen Uhrzeit der Rollladen geschlossen. In den Plugin Debug Infos steht eine Uhrzeit deutlich nach 21 Uhr drin, daran liegt es also nicht.
Was könnte sonst noch falsch sein?

[emax]

Prima, dann werde ich es mal ausprobieren.
">" habe ich genommen, da genau 20:00 ja schon mit "<=" im ersten Fall abgefangen wird.

Stimmt, das habe ich übersehen.

Leider funktioniert es so nicht, es wird zu der in der ersten der beiden Config-Zeilen angegebenen festen Uhrzeit der Rollladen geschlossen.

Dein Beitrag wurde um 19:38 Uhr geschrieben, wie kann dann die gezeigte Konfiguration bereits geschaltet haben? Wenn das aber nicht Deine reale Konfiguration per Cut&Paste ist, dann kann ich natürlich auch nicht sehen, ob irgendwo ein Syntaxfehler o.ä. drin ist.

[Elo]

emx_uhr.pl: Sonnenauf/untergangs-abhängige Schltungen

Ich habe vorhin noch im Editor die Zeit auf 19.00 Uhr geändert, damit ich nicht warten muss. Ansonsten ist es aber so wie hier angegeben.

[emax]

Ich habe eben ein Testprogramm geschrieben, in dem das funktioniert. Ich brauche zur Fehlersuche also Deine komplette emx_uhr.conf, unverändert. Manchmal ist es nur ein Apostroph oder ein Punkt, da ist Perl zickig (bzw. genaugenommen unglaublich vielfältig).

Wenn Du die hier nicht posten willst, dann gerne als PN.

Des weiteren wäre ein Screenshot vom Wirgate hilfreich, mit den Angaben die auf dem angehängten Bild markiert sind. Man findet sie auf der 'Plugins' Seite des Wiregates.


PS: Bitte keine für dieses Problem vermeintlich 'irrelevanten' Zeilen aus der conf Datei löschen. Ich brauche sie wirklich komplett, genau so wie sie bei Dir läuft.

[jensgulow]

@emax:

Erst mal vielen Dank noch mal für Deine plugins emx_uhr und emx_sonne.
Die laufen bei mir sehr zuverlässig seit längerer Zeit.
Allerdings scheint emx_uhr zu einem deutlichen memleak zu führen (s. screenshot). Damit ist es einer der Hauptübeltäter, warum irgendwann der monit zuschlägt und den wiregated neu startet.
Hast du zufällig irgendwelche fixes in petto, welche das reduzieren.

Alternativ evtl. eine Version, welche mit Frys "gepatchtem" wiregated läuft?
Ich hatte mich mal selbst daran versucht aus der emx_uhr.pl eine "kompilierbare Version" zu machen, bin aber bei den subs doch gescheitert und dann in eine fileparse-Fehler-Endlosschleife geraten. Da lass ich jetzt lieber die Finger von. Hast Du evtl. das plugin schon in "kompilierbarer Form"?

Grüße

[emax]

Hallo Jens,

ich hab das gerade mal bei mir nachgesehen, sieht auch bei mir so aus. Allein: Ich weiß nicht warum. In (nicht-OO) Perl gibt es keine expliziten Speicherallozierungen, und ich verwende auch keine OO-Module. Deshalb verstehe ich das zunächst mal nicht. Da ich nichts alloziere, kann ich natürlich auch nichts deallozieren.

Nun ist das m.E. aber nicht akut, weil halt der wiregated irgendwann mal neu startet. Aber ich werde ein Auge drauf haben und demnächst mal drüberschauen, warum das so sein könnte.

Zweiter Punkt: Compilierbar - womit ?

[JuMi2006]

Ich würde mal probieren vorm Beenden des Plugins @Zeiten zu löschen, das könnte schon reichen.

edit:
Evtl. auch mal per "undef &subname" am Ende des Plugins die Subs eleminieren.

[jensgulow]

@ emax: siehe hier

[emax]

Danke JuMi, das werde ich demnächst mal in Angriff nehmen.

@Jens

Interessanter Ansatz, so eine ähnliche Idee hatte ich auch mal angedacht. Wegen der genannten Einschränkungen erschien mir das für den Otto-Normal-Plugin-Schreiber aber nicht durchsetzbar.

Ich muss mir das mal überlegen, denn die Konsequenzen gehen tatäschlich noch ein Stückchen weiter. Ein Gewinn an Geschwindigkeit wird, sofern nicht gerade vollkommen idiotische Programmierung an einer gewissen Langsamkeit schuld ist, grundsätzlich immer mit einem Verlust an anderen Ressourcen erkauft. Und in diesem Fall ist das Hauptspeicher. Um den muss man sich beim Wirgate zwar nicht unbedingt sorgen, aber es entspricht einfach nicht so ganz meiner 'old-school' Provenienz. ;-)

Das Hauptspeicher-Argument klingt angesichts der Memory-Leaks beim derzeitigen Konzept natürlich paradox, aber tatsächlich sind die ja Resultat eines unvollkommenen Perl Garbage-Kollektors und nicht Resultat des grundsätzlichen Konzepts.

Wenn ich also die Memory-Leaks mit JuMis Vorschlägen in den Griff bekomme, wäre das wohl erst mal ausreichend. Ein Plugin als Closure erfordert doch ein paar Änderungen im Code und lässt so manches Feature nicht zu. Das will also gut überlegt sein.


EDIT: Den wiregated starte ich jetzt erst mal neu, mal sehen was dann in einer Woche so los ist. Danach werde ich im Plugin alle Variablen und subs (die eigentlich von Perl freigegeben werden müssten) explizit freigeben, und dann nach einer Woche noch mal schauen, was sich geändert hat. Wenn Ihr in spätestens drei Wochen nichts von mir hört, dann hab ich mich entweder neben dem Wiregate erhängt, oder die Sache vergessen. Dann wäre eine Erinnering per PN, von wem auch immer, für mich durchaus OK.

[jensgulow]

@ emax: Na dann werde ich mir mal einen Erinnerungstermin anlegen

[XueSheng]

Alternativ evtl. eine Version, welche mit Frys "gepatchtem" wiregated läuft?
Ich hatte mich mal selbst daran versucht aus der emx_uhr.pl eine "kompilierbare Version" zu machen, bin aber bei den subs doch gescheitert und dann in eine fileparse-Fehler-Endlosschleife geraten.

Interessanter Ansatz, so eine ähnliche Idee hatte ich auch mal angedacht. Wegen der genannten Einschränkungen erschien mir das für den Otto-Normal-Plugin-Schreiber aber nicht durchsetzbar.

Über die Vor- und Nachteile des COMPILE_PLUGIN wurde glaube ich bereits sehr viel im ursprünglichen Thread diskutiert. Die positiven Effekte überwiegen imho die Einschränkungen. Nicht zuletzt hat StefanW bereits zugesagt, dass COMPILE_PLUGIN im nächsten Firmware-Update zu finden sein wird!

Ich habe emx_uhr.pl nie verwendet, aber eben mal kurz angesehen. Der Code ist sehr sauber geschrieben, großes Lob an emax! Daher sollte es recht einfach sein, das ganze als compiliertes Plugin laufen zu lassen. Wenn ich das richtig sehe, müssen lediglich eine handvoll Variablen als "global" definiert werden, damit diese in den subs verwendet werden können bzw. aus der config geladen werden können. Folgender Patch funktionierte bei mir auf anhieb. Zumindest sieht die Log sehr vielversprechend aus (da ich wie gesagt das Plugin selbst nicht verwende, müssen andere testen, obs wirklich zuverlässig tut).

Daher noch mal ganz explizit: Dieser Patch ist ungetestet und sollte nur von mutigen Testern ausprobiert werden. Voraussetzung ist natürlich COMPILE_PLUGIN von Fry.

--- emx_uhr.pl.orig     2014-01-15 15:29:49.000000000 +0100
+++ emx_uhr.pl  2014-01-15 15:29:15.000000000 +0100
@@ -46,23 +46,25 @@
 #   1  edh  20110807  -----  wg. utf-8 Zirkus Umlaute in ae/ue/oe geaendert
 #   0  edh  20110708  -----  erste Version

+# COMPILE_PLUGIN
+
 use POSIX;
 use Time::Zone;

 #-----------------------------------------------------------------------------
 # konfigurierbare  Werte, siehe conf.d/emx_uhr.conf.sample
 #-----------------------------------------------------------------------------
-my @Zeiten               = ();
-my $LokaleZeitZone       = "CET";  # lokale Zeitzone
-my $LokaleSommerZeitZone = "CEST"; # lokale Zeitzone im Sommer
-my $slotEnd = 3;
+our @Zeiten               = ();
+our $LokaleZeitZone       = "CET";  # lokale Zeitzone
+our $LokaleSommerZeitZone = "CEST"; # lokale Zeitzone im Sommer
+our $slotEnd = 3;

 #-----------------------------------------------------------------------------
 # Aufruf-Zyklus setzen
 # Das script verarbeitet keine Sekunden, weshalb die kleinste
 # Granularitaet ohne zusaetzliche Statusverarbeitung eine Minute ist.
 #-----------------------------------------------------------------------------
-my $cycleTime = 60;
+our $cycleTime = 60;

 #-----------------------------------------------------------------------------
 # Die Versionsnummer is Teil des plugin_info hashes und dient