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

[swantje]

Hallo Emax, Makki, und all Ihr anderen,

hätte eigentlich vorweg gehört, aber hinterher schadet sicher auch nichts:
Ich möchte mich noch an das Lob anschließen, Ich finde es super, dass das Wiregate problemlos läuft und bisher auch immer das getan hat, was es soll. Die Temperatursensoren und die Schnittstelle sind quasi plug&play und kleine Plugins funktionierten auf Anhieb. Die Möglichkeiten sind super und für mich als Perl newbie stellen sich noch viele Fragen - aber dieses Forum hier ist einfach toll, weil man vieles schon beim Suchen findet. Und wenn nicht, immer jemanden der auf die eigenen Fragen antwortet. Großes Lob an alle, die das hier so möglich machen!

Swantje

[hobel]

Hallo Swantje,

die plugins sonne und uhr haben jeweils eine config, die steht im webmin direkt hinter dem .pl und lässt sich separat öffnen (nicht das .pl öffnen!). Nur in den config musst (darfst) du was ändern. Bei sonne.pl musst du nur deine Koordinaten eingeben, sonst nix. Im Uhr-config siehst du die Beispiele, einfach kopieren/einfügen und entsprechend deiner Werte ändern. Auch hat emax sehr schön in der config alle Einstellungsmöglichkeiten erläutert.

Also Finger weg von den plugins, nur in der config "basteln"!

Viel Erfolg!

Andreas

[hobel]

Upps, falscher Fehler.

Deine Koordinaten gibst du natürlich nicht in der Sonne.pl ein, sondern in der config!!!

[swantje]

@hobel: danke für's Mut machen, es funktioniert jetzt. (Das mit der Config war nicht das eigentliche Problem.)

Was mich irritiert hat war die Warnung von emax in der config zu emx_Uhr.pl:
#-----------------------------------------------------------------------------
# ACHTUNG: Variablen duerfen nur im Plugin mit 'my' definiert werden,
# 'my' hier nicht verwenden!
#-----------------------------------------------------------------------------

und dann muss ich ja doch lauter sub's mit my' hineinkopieren...
(oder zumindest hat es so jetzt funktioniert)

Meine Code-Frage habe ich auch gelöst. Schließlich möchte ich auch gerne das hinter den Kulissen verstehen, wenn ich es schon ansehen darf.
Große Hilfe hierbei war http://www.gxy.ch/5efinf/perl/perl-theo-03.pdf, auf das von Makki mal verwiesen wurde. (Es gibt mehrere nummerierte .pdfs)

[swantje]

WireGate Hilfe?

Wie komme ich eigentlich an die WireGate-Hilfe? Wenn ich im WireGate auf "Hilfe .." klicke passiert einfach nichts. Egal in welcher Maske ich mich gerade befinde. Ist das normal - und wenn ja, wo finde ich die immer mal wieder erwähnte Hilfe dann?

[hobel]

Wahrscheinlich hast du den popup Blocker im Browser aktiv.

[emax]

Na dann hat sich ja alles geklärt, ich war gestern nicht am Rechner. :-)

@swantje: Das mit den 'my' Definitionen gilt für den 'globalen Scope', um es mal angsteinflößend zu formulieren.

Vereinfacht ausgedrückt: Innerhalb der Funktionen (also zwischen der jeweils einleitenden und abschließenden, geschweiften Klammer einer Funktion) ist alles für den äusseren Code, also für das Plugin und die conf-Datei, unsichtbar. Eine Funktion ist sozusagen eine Blackbox innerhalb derer neu definierte Namen nur dieser Funktion bekannt sind. Das ist ja (u.a.) auch der Sinn einer Funktion: Verkapselung.

Und weil das so ist, sind auch die 'my' Schlüsselwörter innerhalb einer Funktion nur für die Funktion effektiv, das Plugin "sieht" sie nicht.

Man könnte übrigens auch ausserhalb der Funktionen in der Conf-Datei beliebig 'my' verwenden. Aber wenn man das tut, dann ist die entsprechende Variable für das Plugin nicht mehr sichtbar, weil man sie damit ja neu definiert, anstatt die u.U. bereits im Plugin zuvor definierte Variable zu weiter zu verwenden.

Weil das zu schwer diagnostizierbaren Fehlern führen kann, habe ich also die Warnung hingeschrieben.

Kurzum: Variablen, die im Plugin verwendet werden, müssen auch dort mit 'my' angelegt werden, und nicht in der 'conf' Datei. Variablen, die im Plugin nicht auftauchen, die darf man tatsächlich auch selber mit 'my' neu anlegen, ebenso solche, die nur innerhalb von Funktionen auftauchen.

Die genannte Regel ist tatsächlich eine Vereinfachung die auch Ausnahmen erlaubt, aber eben immer mit Vorsicht.

[swantje]

Danke, emax, das war ja nochmal schön erklärt! Und im Nachhinein betrachtet für jemanden der hauptsächlich c++ kennt auch ganz logisch.
Alles erschließt sich eben doch nicht sofort durch die Betrachtung von Code-Schnipseln und die Beobachtung des Deckenlichts (schaltet es jetzt, oder nicht?)
Das mit dem "and" anstelle der If-Schleife, finde ich immer noch sehr trickreich, aber ich habe dann ja eine Perl-Einführung gefunden, die meine Vermutung bestätigt hat. Vielleicht hätte ich mir doch ein Buch kaufen sollen und ein Entwicklungsumgebung aufbauen - aber eigentlich wollte ich ja gar nicht zum Perl-Profi werden sondern lediglich die Heizungen und Rolläden steuern. Ich dachte, das geht quasi mit copy-paste und dem Anpassen der Adressen. Geht es ja auch - wenn man versteht, was man wohin pastet.
Für mich wäre es praktisch gewesen, wenn in der svn ein config-Beispiel für emx_uhr mit den Sonnen-Werten gestanden hätte. Vielleicht auskommentiert, damit es keine Fehler gibt, wenn emx_sonne nicht läuft. So muß man nicht suchen, was wohin gehört und da beides aus einer Hand kommt, wäre es auch logisch.

Jedenfalls herzlichen Dank für die schönen Plugins, die mich viel gelehrt haben und jetzt super funktionieren!

Swantje

[emax]

Ich dachte, ich hätte das eingecheckt. Das kommt davon, wenn man beruflich jeden Tag svn-commits macht. Ich hol das nach.

PS: Erledigt. Steht jetzt als zusätzliche Konfigurationsdatei mit dem Namen 'emx_uhr.conf.sample2' im svn.

[Hammer69]

Frohe Ostern zusammen,

vielen Dank für das tolle Plugin. Habe sonst die reine Schaltuhr verwendet. Doch beim Lesen, was alles möglich ist, natürlich Lust bekommen mehr damit zu machen und am Wochenende das emx_sonne noch hinzugefügt.
Dies hat auch mal richtig funktioniert. Doch seit heute Nacht um 0 Uhr sendet es bei jeder Ausführung zeitgleich einen "auf" und einen "ab"-Befehl an die Rollläden.
Aber nur bei den Zeilen, die mit variabler Schaltzeit versehen sind.
Könnte mal bitte jemand schauen ob ich mich vertippt habe. Oder wo könnte der Fehler herrühren?

    # Jalousie Badezimmer      
      { Name=>'Bad ZU', Aktiv=>'1', Std=>&sonnUntHH(+30/60), Min=>&sonnUntMM(+30/60), Wert=>'1', DPT=>'1', GA=>'2/2/161', Log=>'1' }, 
      { Name=>'Bad auf Winter WT', Aktiv=>'1', Mon=>'0,1,2,10,11', WTag=>'0-4', Std=>&sonnAufHH(0), Min=>&sonnAufMM(+05/60), Wert=>'0', DPT=>'1', GA=>'2/2/161', Log=>'1' }, 
      { Name=>'Bad auf Winter WE', Aktiv=>'1', Mon=>'0,1,2,10,11', WTag=>'5-6', Std=>&sonnAufHH(0), Min=>&sonnAufMM(+35/60), Wert=>'0', DPT=>'1', GA=>'2/2/161', Log=>'1' }, 
      { Name=>'Bad auf Sommer WT', Aktiv=>'1', Mon=>'3,4,5,6,7,8,9', WTag=>'0-4', Std=>'6', Min=>'25', Wert=>'0', DPT=>'1', GA=>'2/2/161', Log=>'1' }, 
      { Name=>'Bad auf Sommer WE', Aktiv=>'1', Mon=>'3,4,5,6,7,8,9', WTag=>'5-6', Std=>'8', Min=>'00', Wert=>'0', DPT=>'1', GA=>'2/2/161', Log=>'1' }, 
      { Name=>'Bad Lamellen auf Sommer WT', Aktiv=>'1', Mon=>'4-9', WTag=>'0-4', Std=>&sonnAufHH(0), Min=>&sonnAufMM(-30/60), Wert=>'50', DPT=>'5', GA=>'2/2/164', Log=>'1' },

Das emx_uhr Plugin scheint richtig zu laufen, denn die Zeit vom Plugin_info emx_sonne.untHH wird neu und richtig errechnet.

Wünsche einen schönen Sonntag
Stefan

[hobel]

Std=>&sonnUntHH(+30/60), Min=>&sonnUntMM(+30/60)

so wie du es hier richtig eingetragen hast, musst du auch bei den anderen sonnUntHH und sonnUntMM in den Klammern den gleichen Wert eingeben
(bzw bei den sonnAufHH und sonnAufMM).

[emax]

So ist es. Ich kann aus den Werten nicht genau nachvollziehen, was da eigentlich passiert. Aber fest steht, dass die Werte in den Klammern innerhalb der selben Zeile immer gleich sein müssen. Ich hab das hier im Forum (ich glaube sogar in diesem Thread ) schon mal erklärt: Sowohl die Auswertung der Stunde als auch die der Minute ist von den 'Bruchteilen' einer Stunde abgängig.

• Stunde: 16:45 + 30 Minuten ergibt für die Stunde den Wert 17 (17:15 Uhr). Ohne die 30 Minuten Angabe käme hier 16 raus.
• Minute: 16:45 + 30 Minuten ergibt für die Minute den Wert 15 (17:15 Uhr). Ohne die 30 Minuten Angabe käme hier 45 raus.

Wenn da zwei verschiedene Werte stehen, wird das Ergebnis zwar nicht unverhersagbar, aber doch wenigstens unerwartet sein.

Sofern das Problem mit dieser Korrektur behoben ist, wäre eine Rückmeldung ein netter Zug, nicht das da noch ein anderer Grubenhund begraben liegt.


Davon abgesehen: Hab mich heute wieder gefreut, dass Sommer- bzw. Winterzeit as Plugin völlig unbeeindruckt lassen. Die Läden gingen wie erwartet nicht so wie gestern um kurz nach 19:00 Uhr runter, sondern um kurz nach 20:00 Uhr.

Soll heissen: Auch das Plugin hält die Sommer/Winterzeit-Umstellung für überflüssig ;-)

[Hammer69]

Vielen Dank für den Hinweis, werde es nun ändern und hoffentlich heute Nacht ruhe haben.
Schönen Abend
Stefan

[nipponichi]

Da bei jeder Zeitumstellung die Rolladen mit dem astro-perl-Package einen Tag eine Stunde falsch fahren, habe ich mir mal parallel das emex-sonne.pl-Skript installiert. Der berechnete Sonnenauf-/untergang ist mit emex-sonne.pl etwa 8 Minuten später/früher als bei dem astro-Perl-Package, dem Google-Ergebnis "Sonnenaufgang" oder berechnet mit dieser Seite Formel für Sonnenaufgang, Sonnenuntergang und die Zeitgleichung - JavaScript (Ich habe dazu die "Horizonthöhe" 0 statt zu -50' = -0.0145 gesetzt, wie beim astro-Package).
Ich gebe zu, daß ist eher ein akademisches Problem, aber hat einer eine Ahnung, woran das liegt?

[emax]

An der Berechnung. :-)

Ich verwende eine standard-Formel, die so auch für andere Projekte eingesetzt wird. Die Gleichung stammt zwar von hier

Sonnenaufgang berechnen mit perl | Austernkommunikation

meine Referenz auf der ich das nachgeprüft habe ist allerdings hier

Formel für Sonnenaufgang, Sonnenuntergang und die Zeitgleichung

Da kein Fremd-Package verwendet wird, lässt sich im Code sehr genau nachprüfen, dass die betreffenen Konstanten und Formeln exakt implementiert wurden. Die gewählte Formel, das muss man natürlich wissen, liefert die Ergebnisse mit einer Genauigkeit von besser als 5 Minuten, i.e.: kann bis zu fünf Minuten abweichen. Eine höhere Genauigkeit kann diese Formel nicht liefern. Genauere Berechnungsmethoden erfordern mehr Rechenaufwand, der mir zum Preis höheren Ressourcenverbrauchs auf dem Wiregate aber nicht angemessen erscheint: Wir müssen ja keine ISS-Andockmanöver berechnen.

Per heutigem Tag steht in meinem Wiregate für meine Länge und Breite für den Sonnenaufgang 7:02 Uhr, für den Untergang 19:54 Uhr.

Die Berechnung auf dieser Seite

Formel für Sonnenaufgang, Sonnenuntergang und die Zeitgleichung - JavaScript

bestätigt diese Werte für meinen Breitengrad mit der für diese Formel möglichen Genauigkeit. Dabei stimmen die errechneten Werte auf zwei bzw. drei Stellen hinter dem Komma überein, was einer maximalen Abweichung von 3,6 Sekunden entspricht, also 'genau genug' ist.

Die Gründe für die Abweichungen trotz identischer Berechnungsformel liegen in unterschiedlicher Abarbeitung der Werte durch den verwendeten Compiler bzw. Interpreter (in diesem fall Java vs. Perl). float bzw. double Werte sind nun mal per Definition (IEEE 754) ungenau.

Wichtig ist, dass die Eintragungen für Länge und Breite in der conf-Datei richtig sind. Und dann vielleicht mal prüfen, welches Plugin 'näher dran' ist.