[wiregate] Sonnenaufgang/untergang, ein mal täglich

[emax]

Es gab hier ja schon mehrere Beiträge und Codeschnipsel zum Theme Sonnenauf- und -untergang.

Damit ich das in allen Plugins beliebig verwenden kann, ohne es dann jedesmal berechnen zu müssen, hab ich ein Plugin geschrieben, welches das ein mal am Tag erledigt. Die Werte stehen dann in %plugin_info, und können von jedem Plugin direkt dort abgeholt werden, ohne jedesmal alles neu rechnen zu müssen. Das Script stellt auch gleich jeweils für den Sonnenaufgang und den Sonnenuntergang die diskreten Werte für Stunde und Minute zur Verfügung.

Wie neuerdings üblich, verwendet das Plugin das Konfigurationsverzeichnis ...generic/conf.d, und liest dort aus der zugehörigen .conf Datei den Längen- und Breitengrad. Fehlt diese Datei, wird Berlin angenommen.

Die ausgerechneten Werte in %plugin_info können über das Webinterface des Wiregate kontrolliert werden.

Steht noch nicht im svn. Datei verarbeiten wie bereits analog am Ende dieses Beitrags beschrieben. Rückmeldungen wären nett, damit ich Fehler beheben bzw. es einchecken kann.

[StefanW]

Sehr gute Idee, einmal berechnen und in anderen Plugins verwenden!

Sehr sehr schön!

[Träume] Wenn ich mal träumen dürfte, dann fehlt nur noch das jeweilige Einbinden einer passenden Webmin-Oberfläche um die - in der Config-Datei befindlichen Parameter - zu manipulieren. Dürfte für die meisten dann nochmal einfacher sein, dass zu editieren. Aber das wäre auf der anderen Seite ein großes Stück Arbeit und würde das Erstellen von Plugins stark erschweren, wenn dann noch eine grafische Oberfläche dazu kommen "müsste". Also, lassen wir das wieder. [/Träume]

LG

Stefan

[emax]

Stimmt schon, Stefan, und ich würde das auch sofort machen - wenn ich es denn könnte. Ich habe von Webprogrammierung leider keine Ahnung. HTML, Javascript, Model/View/Controller, ich weiß was das alles ist, und zumindest MVC kenne ich aus der Praxis.

Aber Web-Oberflächen ... ?

[greentux]

Dafür könnte man im einfachsten Fall ein Webminmodul nehmen, was zum editieren von Config Files geeigenet ist.
Text Editor 1.4 oder ähnliches.

[tjakobi]

Ich fände es ja nicht schlecht, wenn man daraus eine Webmin Oberfläche zur verfügung stellt, die nach den grundlegenden Konfigurationseingaben fragt:

..beim sonnenauf-untergang Plugin nur noch lat. und long. Koordinaten eingeben muss und das Plugin zeigt sofort die Variablen an. Dies könnte man für die weiteren Plugins so übernehmen.

..beim Schaltplugin, werden die Zeiten/Datum/GAs/Werte abgefragt und je nachdem wieiviele Schaltzeiten definiert sind, werden diese untereinander angezeigt.

..beim prowl skript bsp. die Eingabe des API Keys...

..beim clean up, die "zu suchenden Asudrücke"

Und für mich, auf das ich schon so lange warte die Möglichkeit, bei THS Multiplatinen die Berechnung der Taupunkt Temperatur. Dies muss einfacher werden und vorallem bietet es dem Endanwender richtig Mehrwert.

Viele Grüße TIm

[emax]

Dafür könnte man im einfachsten Fall ein Webminmodul nehmen, was zum editieren von Config Files geeigenet ist.
Text Editor 1.4 oder ähnliches.

Jou, das wär ne Lösung. Mach mal!

[greentux]

Du meinst jetzt ein Howto, wie man 3rd party module installiert?
Ich werds die Tage mal probieren auf meinem Webmin.

[StefanW]

Und für mich, auf das ich schon so lange warte die Möglichkeit, bei THS Multiplatinen die Berechnung der Taupunkt Temperatur. Dies muss einfacher werden und vorallem bietet es dem Endanwender richtig Mehrwert.

Das ist bereits im Beta und sollte im nächsten Update dann enthalten sein, wenn alles klappt.

[haegar80]

Hallo zusammen,

anfangs war ich total begeistert, einfach nur noch die %plugin_info Werte in den Plugins verwenden zu müssen.

Nachdem ich einmal drüber geschlafen habe, denke ich, daß sowas eigentlich auf eine Gruppenadresse gehört. Dann sind alle Werte an einem Ort und es gibt kein Durcheinander bzw. Redundanzen.

Und ein knxread abzusetzen ist eientlich auch nix anderes, wenn die Werte eh aus dem Cache geholt werden.

Das waren meine 5ct zu dem Thema.
Generell aber ein riesen Dank an emax! Die Plugins sind in den vergangenen Tagen/Wiochen auf ein richtig hohes Niveau gekommen.

Danke
Sascha

[StefanW]

Morgen Sascha,

es ist zwar durchaus richtig gedacht zu sagen, die Zustände eines Hauses gehören auf den KNX, weil dazu ist der Bus ja da.

Andererseits sind die Plugin_info Werte sehr einfach handhabbare Variablen mit geringem Ressourceneinsatz und für die Inter-Plugin-Kommunikation durchaus gut geeignet.

Das Caching der KNX-Telegramme ist ziemlich vermutlich zeitlich begrenzt, wenn nun Dein Rolladen-Plugin alle 5 Minuten die Sonnenaufgangszeit per KNX-Read ließt, dann wird das auch zu realen Leseaufforderungen am Bus führen. Aber so genau kenne ich das Caching des eibd nicht.

Stefan

[emax]

Nachdem ich einmal drüber geschlafen habe, denke ich, daß sowas eigentlich auf eine Gruppenadresse gehört. Dann sind alle Werte an einem Ort und es gibt kein Durcheinander bzw. Redundanzen.

Aus puristischer IT-Sicht nicht: Und der Bus daselbst hat keine Speicherfunktion. Und mir ist auch unklar, wer/wie/was die Daten letztlich aufnehmen sollte: Sich auf den eibd zu verlassen wäre kein guter Rat: Die Daten werden auf der wiregated Seite ermittelt, und sind deshalb auch dort richtig aufgehoben, der eibd ist davon unabhängig. Cross-Modul Abhängigkeiten (wiregated<->eibd) würde ich vermeiden wo sie vermeidbar sind: Sie verkomplizieren die Dinge nur.

KNX ist eben schlicht die 'Haus-Seite' des Gesamtsystems. Gruppenadressen haben eine semantische Funktion, sie sind nicht einfach irgendwelche Speicher. Der knx-read ist überdies viel langsamer als plugin_info.

Die Plugins sind in den vergangenen Tagen/Wiochen auf ein richtig hohes Niveau gekommen.

Das freut mich zu hören, aber es ist immer eine Teamleistung: Die Wiregate-Grundlagen sind ideal, da macht das dann auch Spass. :-)

[greentux]

Was es dann aber fast unmöglich macht, die Daten woanders als im wiregated zu verarbeiten. Beispielsweise im lnknx oder auf einem HS.

Ich fand es damals auch immer komisch, warum alles auf den Bus gehört (Temperaturen etc), wenn man den PI-Regler dann doch wieder auf dem wG laufen hat. Makki hatte es aber sehr einleuchtend erklärt...

Wenn man die "internen" Werte jetzt mal anzeigen möchte (Cometvisu) geht das nun derzeit nicht.

[StefanW]

Man kann das eine tun und braucht das andere nicht zu lassen.

Was es dann aber fast unmöglich macht, die Daten woanders als im wiregated zu verarbeiten. Beispielsweise im lnknx oder auf einem HS.

Das Plugin kann man sich dazu umstricken - oder ein zweites erstellen - dass die einmal täglich errechneten Auf- und Untergangszeiten auch per GA zyklisch sendet bzw, auf eine Leseanforderung hin ausgibt.

It's just up to you, jeder ist Herr über seine Installation.

[greentux]

Mir persönlich ist es egal Ich hatte nur noch Makkis Meinung im Ohr, das alles auf den Bus gehört. Das fand ich dann auch ganz einleuchtend. Eben um die Intelligenz verteilen zu können.
Aber ja, kann jeder machen wie er will. Muss dann auch jeder selber pflegen

[emax]

Was es dann aber fast unmöglich macht, die Daten woanders als im wiregated zu verarbeiten. Beispielsweise im lnknx oder auf einem HS.

Aha, jetzt kommen wir der Sache näher. Aber solche Probleme sind anders zu lösen.

Zunächst muss mal klar gesagt werden, dass ja alleine das Vorhandensein von wiregated, lnknx und HS innerhalb einer knx-Installation schon per se Redundanzen darstellt. Wenn also der wiregated Sachen kann, die die anderen Produkte nicht können, und diese dann zunächst mal in seinem eigenen Umfeld speichert, dann ist das so völlig korrekt. Der Bus als Bindeglied zwischen wiregate, lnknx, HS, das wäre die wahre Krücke.

Wenn auch andere Produkte nicht so nette Sachen wie Perl-Plugins können (sollten?), ist ja das WG dafür nicht verantwortlich. Man könnte aber -großzügigerweise- ;-) diese Werte in einer generalisierten Schnittstelle zur Verfügung stellen, eine simple CSV-Datei zum Beispiel. Und zwar vorzugsweise dann, wenn die anderen Produkte genau das Gleiche tun, und genau die gleiche Schnittstelle bedienen. Denn es könnte ja sein, dass auch mal das WG von lnknx und HS profitieren könnte ... :-)

Wenn aber HS & Co. solche Schnittstellen nicht bedienen können (sollten ?), dann antworte ich knallhart: Pech gehabt. Wer als Hersteller auf proprietären Produkten, Schnittstellen und Protokollen besteht, der hat eben nicht nur die Annehmlichkeiten eines Monopols für seine Plattform, er hat dann eben auch das Pech, von den Möglichkeiten quelloffener Systeme ausgeschlossen zu sein.

Aber vielleicht kann (z.B.) der HS so was ja nutzen bzw. bedienen, dann wäre ja alles bestens :-)