[gelöst] csv-Daten von SD für Dämmerungsphasen nutzen

Allgemeines zur HomeMatic Haussteuerung

Moderator: Co-Administratoren

nimmnenkeks
Beiträge: 187
Registriert: 30.11.2016, 20:24

[gelöst] csv-Daten von SD für Dämmerungsphasen nutzen

Beitrag von nimmnenkeks » 07.02.2017, 12:32

Servus zusammen,

habe versucht über die SuFu etwas zu finden, aber bisher habe ich nur die Möglichkeit gefunden csv-Dateien zu schreiben.

Für die Sonnenstandberechnung gibt es ja die unterschiedlichsten guten Lösungen, die jedoch permanent im x-Minuten-Rhytmus laufen müssen, sobald man nicht zu Sonnenaufgang-, oder Sonnenuntergangszeiten der CCU die Rolläden steuern möchte.
AddOn-frei, oder ohne iO-Brooker o.ä. wäre natürlich die schönste Möglichkeit, ich weiß aber nicht, ob das mit CCU-Mitteln möglich ist.

Sobald man die Dämmerungszeiten mit einbeziehen möchte, kann man ja nicht feste Zeiten zu SA oder SU festlegen, da sich diese von Winter bis Sommer täglich verändern.
Sehr gute Lösungen sind bereits hier vorgestellt worden http://homematic-forum.de/forum/viewtop ... 31&t=17514

Nun kann man jedoch auf http://galupki.de/kalender/sunmoon.php die Daten eines Jahres als csv-Datei herunterladen.
Einziger mir aufgefallener Nachteil, dass man nicht angeben kann in welcher Höhe sich die Koordinaten befinden.
Somit könnte man diese auf die SD-Karte schieben und zu festgelegten Zeiten auslesen, ohne dass man irgendwelche Server im www anzapfen muss, die evtl. nicht erreichbar sind und es schlimmstenfalls grumpft.

Wäre es da nicht sinnvoller, die Daten einmal in der Nacht aus der csv zu lesen und dann in entsprechende Systemvariablen zu aktualisieren?

Ich bin nun wahrlich ein Rookie im Bereich HM, aber wenn ich mir hier so einige Lösungen/Umsetzungen ansehe (vor denen ich allergrößten Respekt habe) könnte das evtl. möglich sein.
Ist hier nicht ganz so einfach, alle Scripte, Script-Schnipsel und Mod-Scripte zu finden, da bsp. alchy "mal eben" (meist sogar blind) Script-Code raushaut/ändert/modifiziert (positiv gemeint), der nicht in den Tips und Tricks zu finden ist.

Kann natürlich sein, dass es schon entsprechende AddOn-freie Umsetzungen gibt und ich sie noch nicht gefunden habe.
Soweit mir bekannt läuft alle paar Minuten ein Script, oder es werden externe Daten täglich von Servern geladen.

Wenn man ähnlich wie BadenPower's genialem Kalender-Script (wobei ich best. noch nicht mal ansatzweise die Möglichkeiten in Betracht gezogen habe) die gewünschten Systemvariablen konfigurieren und füllen könnte, hätte man diese in den entsprechenden Programmen (nicht nur zur Rolladensteuerung) zur pers. Auswahl.

Manche mögen gerne zu Beginn der 'Bürgelichen Dämmerung' z.B. die Rolläden öffnen/schliessen, andere die 'Nautische Dämmerung' wählen um die 'Blaue Stunde' zu nutzen.
Damit man dabei nicht auch wieder an feste Zeiten gebunden ist, wäre mit einer weiteren Möglichkeit wie dieser: http://homematic-forum.de/forum/viewtop ... 65#p268568 innerhalb der unterschiedliche Dämmerungszeiten ganz einfach zu wählen.

Kann natürlich sein, dass es mir an entsprechendem Hintergrund fehlt (bin halt noch nicht entsprechend in HM und Scriptmöglichkeiten eingelesen und habe entsprechende HM-Wissen verinnerlicht), sodass eine solche Umsetzung schlicht unmöglich ist.
Dann tut es mir leid, Euch die Zeit für das Anlesen des Fred's geklaut zu haben.


Gruß Keks
Zuletzt geändert von nimmnenkeks am 20.02.2017, 20:41, insgesamt 1-mal geändert.

Xel66
Beiträge: 4070
Registriert: 08.05.2013, 23:33
Wohnort: Nordwürttemberg

Re: csv-Datei von SD für Sonnenstand einlesen und auswerten

Beitrag von Xel66 » 07.02.2017, 12:58

nimmnenkeks hat geschrieben:AddOn-frei, oder ohne iO-Brooker o.ä. wäre natürlich die schönste Möglichkeit, ich weiß aber nicht, ob das mit CCU-Mitteln möglich ist.
Ist es doch. Die von Dir verlinkte Variante macht dieses.
Wäre es da nicht sinnvoller, die Daten einmal in der Nacht aus der csv zu lesen und dann in entsprechende Systemvariablen zu aktualisieren?
Sinnvoll ja, möglich ja. Der klitzekleine Fehler in der Sache liegt in der Tatsache, dass man mit den Daten in der CCU nichts anfangen kann. Du kannst keine Triggerdaten dynamisch in das Zeitmodul schreiben. Insofern bliebe dann wieder nur die zyklische Triggerung und ein Uhrzeitvergleich mit den hinterlegten Systemvariablen. Da kommst Du dann aus dem Regen in die Traufe. Sicherlich läuft so ein Script schneller als die Berechnung, aber so richtig gewonnen hast Du nichts.

Ein möglicher Ansatz wäre, die entsprechenden Zeitpunkte für die jeweiligen Sonnenwinkel nachts einmalig in einen CUxD-Timer zu schreiben. Dieser würde dann zu dem gewünschten Zeitpunkt auslösen. Somit wäre nur ein Scriptlauf am Tage möglich, die zyklischen Berechnungen könnten entfallen und die CCU wäre somit entlastet. Leider trifft dieses wieder nicht Deinen Wunsch nach Addon-Freiheit.
Manche mögen gerne zu Beginn der 'Bürgelichen Dämmerung' z.B. die Rolläden öffnen/schliessen, andere die 'Nautische Dämmerung' wählen um die 'Blaue Stunde' zu nutzen.
Solche Sachen wären möglich, wenn man die entsprechenden Timer setzt. Von einer Abfrage einer externen Seite durch ein Script halte ich persönlich nicht sehr viel. Was, wenn die Seite nicht erreichbar ist oder umgestellt wurde, Du ein Netzwerk- oder Internetzugangsproblem hast uswusf. Eine lokale Lösung ist auf alle Fälle vorzuziehen. Man kann auch bestimmte Ereignisse von extern triggern oder Systemvariablen beschreiben lassen. Aber das trifft ja ebenfalls nicht Deinen Wunsch.

Du hast nur die drei Möglichkeiten. Von extern triggern (eigene Lösung, die auf einem Raspberry läuft oder eine Lösung a la ioBroker & Co), mit Addon (z.B. die oben beschriebene Variante mit den CUxD-Timern) oder eben den zyklischen Aufruf des Scripts (so wie es jetzt läuft). Vielleicht findet ja jemand (Hallo BadenPower!) einen Weg, die Triggerzeiten im Zeitmodul dynamisch zu beschreiben oder eben vergleichbare Zustände wie die vorhandenen (nachts und tagsüber) im Zeitmodul zu integrieren. Inwieweit letztere Lösung ein Firmwareupdate überleben würde, bleibt dahingestellt.

Gruß Xel66
---------------------------------------------------------------------------------
242 Kanäle in 89 Geräten und 125 CUxD-Kanäle in 23 CUxD-Geräten,
210 Programme, 145 Systemvariablen und 119 Direktverknüpfungen,
RaspberryMatic Version 2.31.25.20180225
---------------------------------------------------------------------------------

alchy
Beiträge: 7632
Registriert: 24.02.2011, 01:34

Re: csv-Datei von SD für Sonnenstand einlesen und auswerten

Beitrag von alchy » 07.02.2017, 13:15

Die Essenz :mrgreen: deines Postes ist, du willst gerne täglich die Daten einer csv Datei in die CCU einlesen und die darin enthaltenen Werte des Tages in jeweiligen Systemvariablen speichern.
WELCHE der Daten hättest du denn gerne?


Alchy

.................... Full
Ignoranz ist die Summe aller Maßnahmen die man ergreift, um bestehende Tatsachen nicht sehen zu müssen.

© Sandra Pulsfort (*1974)

Lies bitte die Logik von WebUI Programmen und die Tipps und Tricks für Anfänger.

Wichtig auch CUxD ersetzt System.exec. Die HM Script Doku (Downloadart Skripte) hilft auch weiter.
Zum Testen von Scripten den >> HomeMatic Script Executor << von Anli benutzen.

Xel66
Beiträge: 4070
Registriert: 08.05.2013, 23:33
Wohnort: Nordwürttemberg

Re: csv-Datei von SD für Sonnenstand einlesen und auswerten

Beitrag von Xel66 » 07.02.2017, 14:25

alchy hat geschrieben:...du willst gerne täglich die Daten einer csv Datei in die CCU einlesen und die darin enthaltenen Werte des Tages in jeweiligen Systemvariablen speichern.
Das wäre die Hälfte der Essenz. Die andere Hälfte wäre eben, in Abhängikeit von den dort hinterlegten Daten (das brauchen ja nur Uhrzeiten für die jeweiligen Dämmerungszustände oder erreichte Sonnenwinkel sein) Programme zu diesen Zeitpunkten zu triggern. Da es aber nicht möglich scheint, diese Triggerzeiten dem Zeitmodul als Programmierung unterzuschieben, ist die erste Hälfte auch wertlos. Ansonsten könnte man ja genau diese Zeiten dem CUxD als Timer mitgeben. Dann braucht man aber wieder die Zwischenspeicherung in csv oder Systemvariablen nicht, denn dieses ließe sich direkt reinschreiben. Aber Addon-Freiheit ist gewünscht. Ein Teufelskreis...

BTW. Die csv ist als Zwischenspeicher genau so wertvoll wie die einmalige Live-Berechnung per Script. Ob ich nun täglich einmal die Daten aus der .csv lese und ein eine Systemvariable schreibe, oder diese täglich berechne und genau so reinschreibe, bleibt letztenendes egal. Es fehlt die Triggermöglichkeit auf diese berechneten/kopierten Daten...

Gruß Xel66
---------------------------------------------------------------------------------
242 Kanäle in 89 Geräten und 125 CUxD-Kanäle in 23 CUxD-Geräten,
210 Programme, 145 Systemvariablen und 119 Direktverknüpfungen,
RaspberryMatic Version 2.31.25.20180225
---------------------------------------------------------------------------------

alchy
Beiträge: 7632
Registriert: 24.02.2011, 01:34

Re: csv-Datei von SD für Sonnenstand einlesen und auswerten

Beitrag von alchy » 07.02.2017, 14:35

Abgesehen von eins nach dem anderen,
hatte BadenPower doch schon mal bewiesen, das das Triggern zu bestimmten Zeitpunkten per Script geht.

Alchy

.................... Full
Ignoranz ist die Summe aller Maßnahmen die man ergreift, um bestehende Tatsachen nicht sehen zu müssen.

© Sandra Pulsfort (*1974)

Lies bitte die Logik von WebUI Programmen und die Tipps und Tricks für Anfänger.

Wichtig auch CUxD ersetzt System.exec. Die HM Script Doku (Downloadart Skripte) hilft auch weiter.
Zum Testen von Scripten den >> HomeMatic Script Executor << von Anli benutzen.

nimmnenkeks
Beiträge: 187
Registriert: 30.11.2016, 20:24

Re: csv-Datei von SD für Sonnenstand einlesen und auswerten

Beitrag von nimmnenkeks » 07.02.2017, 14:37

Danke Dir,

klar macht das bisherige Sonnenstandscript das, aber läuft alle 4-5min.
Auch "jeder Tag ist anders" hilft, bei der Dämmerung zu arbeiten.
Xel66 hat geschrieben:
Wäre es da nicht sinnvoller, die Daten einmal in der Nacht aus der csv zu lesen und dann in entsprechende Systemvariablen zu aktualisieren?
Sinnvoll ja, möglich ja. Der klitzekleine Fehler in der Sache liegt in der Tatsache, dass man mit den Daten in der CCU nichts anfangen kann. Du kannst keine Triggerdaten dynamisch in das Zeitmodul schreiben. Insofern bliebe dann wieder nur die zyklische Triggerung und ein Uhrzeitvergleich mit den hinterlegten Systemvariablen. Da kommst Du dann aus dem Regen in die Traufe. Sicherlich läuft so ein Script schneller als die Berechnung, aber so richtig gewonnen hast Du nichts.
Scuzi,

mis(t)verständlich ausgedrück, ich meinte die Daten einmal in der Nacht zu laufen lassen (Zeitpunkt) und die zu dem Script notwendigen Systemvariablen damit zu aktualisieren.

Im Prinzip die Arbeitsweise von BadenPower's Script(en) http://homematic-forum.de/forum/viewtop ... 65#p268568
Das akualisiert (zumindest in meinem Verständnis) doch die Systeminternen Zeiten SA & SU 1x zu festgelegtem Zeitpunkt (sinnvoll in der Nacht), bzw. wenn der Trigger läuft.

Das entspräche doch der von Dir vorgeschlagenen Vorgenehsweise, hier:
Xel66 hat geschrieben: Ein möglicher Ansatz wäre, die entsprechenden Zeitpunkte für die jeweiligen Sonnenwinkel nachts einmalig in einen CUxD-Timer zu schreiben. Dieser würde dann zu dem gewünschten Zeitpunkt auslösen. Somit wäre nur ein Scriptlauf am Tage möglich, die zyklischen Berechnungen könnten entfallen und die CCU wäre somit entlastet.
Wie schon geschrieben, jeden Tag externe Quellen anzuzapfen, ist auch nicht Meins.
Die von Dir angesprochenen Problematik (wechselnde Server, DownTime, usw., sowie Netzwerksicherheit), sollte wesentlich öfter berücksichtigt werden.
Daher ja die Daten 1x von der Webseite zu laden, Kontrolle der Tabelle in Excel, ab auf die SD der CCU und es muss Nix mehr nachgeladen werden.
Die Daten sind ja statisch und für das ganze Jahr vorhanden, sodass nicht den ganzen Tag über alle x-Minuten etwas aktualisiert werden muss.
Xel66 hat geschrieben: ... Vielleicht findet ja jemand (Hallo BadenPower!) einen Weg, die Triggerzeiten im Zeitmodul dynamisch zu beschreiben oder eben vergleichbare Zustände wie die vorhandenen (nachts und tagsüber) im Zeitmodul zu integrieren. Inwieweit letztere Lösung ein Firmwareupdate überleben würde, bleibt dahingestellt.

Wieso dynamische Aktualisierung?

Das mir noch fehlende Wissen um HM :D ,
doch ich lerne gerne dazu!
Für meine Verständnis bisher, müste vom Prinzip her ja 'NUR' das aktuelle Datum der CCU ausgelesen werden (in der Nacht, bsp. 07.02.2017 00:10 Uhr) und mit dem Datum der csv verglichen werden.

Die zu dem Datum gehörenden Werte Uhrzeiten) werden in die anzulegenden Systemvariablen (Bsp.) Blaue-Stunde-SA, Blaue-Stunde-SU, Bürgeliche Dämmerung-SA, Bürgeliche Dämmerung-SU usw. geschrieben (Zeitpunkt) geschrieben (Bsp. wie in Handhabung von BadenPower's Kalenderscript -IST-Feiertag-Datum "Werteliste") o.ä. um dann als Bedingung im Programm nutzen zu können.
Wer die "'Blaue Stunde" nicht nutzen möchte, legt keine Systemvariable -Blaue-Stunde- an.

Würde man jetzt noch weiter gehen (nachdem das erste Script gelaufen ist), könnte man ja mit einem zweiten Script wie http://homematic-forum.de/forum/viewtop ... 65#p268568 * innerhalb der Dämmerungsperioden feinere Zeiten ansprechen, oder gar in die anderen Dämmerungen gehe können
Dieses Script (s.o.) müsste dann nach dem csv-Auslese-Script laufen und die in den Programmen genutzten Zeiten, entsprechenden zu aktualisieren.

Beipiel:
- Systemvariable -BuergDaem-SA = 07:57 (nach Auslesen der csv-Datei)
- angelegte Systemvariable -BuergDaemm-SA-CB- Werteliste "-15;-10;-5;0;5;10;15

- Im Programm dann:
Systemzustand -> BuergDaem-CB ->Auswahl: 15 nutzen

anschliessend Programm (1x nacht Script 1, auslesen der csv) -TriggerBuergDaem - um 00:30 Uhr ausführen
ergibt nach Aktualisierung ein Ausführzeit von 08:12 Uhr, statt der 07:57 für den entsprechenden Tag nach der csv-Uhrzeit

So könnte man sich in den Zeiten der Bürgelichen bis Sonnenauf-/Sonnenuntergang bewegen ,die ja variieren (länger/kürzer)

Ich hoffe, ich habe nicht allzu viel Unsinn geschrieben

Gruß Keks

Xel66
Beiträge: 4070
Registriert: 08.05.2013, 23:33
Wohnort: Nordwürttemberg

Re: csv-Datei von SD für Sonnenstand einlesen und auswerten

Beitrag von Xel66 » 07.02.2017, 14:42

alchy hat geschrieben:...hatte BadenPower doch schon mal bewiesen,
Hmmmm... ich meine, da ging es um das verzögerte Triggern von Aktionen innerhalb eines Scripts. Aber auch diese Lösung hätte einen Stolperstein. Sie funktioniert nicht, wenn die CCU zwischendurch gebootet wurde. Entweder, weil die Triggerdaten noch nicht berechnet wurden oder weil die laufende Verzögerung einen Reboot nicht überlebt. Insofern muss ein Fallback rein, denn unwahrscheinlich ist es nicht, dass die Daten für den aktuellen Tag nach Mitternacht berechnet wurden und dann im Verlaufe des Tages, die CCU neu gestartet wird. Die Sache sollte sich schon ähnlich der Zeitmodulzustände (tagsüber/nachts) verhalten oder eben einen nachvollziehbaren Trigger zur Verfügung stellen.
nimmnenkeks hat geschrieben:mis(t)verständlich ausgedrück, ich meinte die Daten einmal in der Nacht zu laufen lassen (Zeitpunkt) und die zu dem Script notwendigen Systemvariablen damit zu aktualisieren.
Ne, schon richtig verstanden. So wie die von Dir zitierte Vorgehensweise, wobei es egal ist, ob die Daten nun berechnet oder aus einer Tabelle ausgelesen werden. Das Grundproblem bleibt.
nimmnenkeks hat geschrieben:Wieso dynamische Aktualisierung?
Du kannst im Zeitmodul nur feste Zeiten als Schwellwerte hinterlegen (Uhrzeiten, Tage, Wochen...) Die Zeiten für die verschiedenen Dämmerungszustände ändern sich aber täglich. Es müsste eine Möglichkeit geschaffen werden, diese Uhrzeit täglich auf die jeweilig aktuelle zu ändern. So ähnlich arbeitet die integrierte Funktion für den Sonnenauf- und -untergang.

Es hilft Dir nichts, die jeweilige Uhrzeit oder Datum und Uhrzeit in einer Systemvariable zu haben. Das Zeitmodul kann nicht damit arbeiten, da die Triggerzeiten bei Programmierung fest hinterlegt werden (mit Ausnahme Sonnenauf- und -untergang). BadenPowers Kalenderscript läuft täglich und füllt Systemvariablen, die sich als Zustand in Programmen verarbeiten lassen. Aber es sind nur boolsche Zustände (wahr/falsch) oder Integerzahlen, die sich einmal am Tag ändern. Darauf kann man triggern. Die Abarbeitung eines Programms auf diesen Trigger würde aber zum Zeitpunkt des Programmlaufes oder mit einer festen Verzögerung erfolgen. Die meisten der Daten sind sowieso nicht für die Automation hilfreich, sondern dienen der Visualisierung. Dazu habe ich meine eigene Meinung, die ich schon ausreichend dargelegt habe. Ich betrachte das Thema als beendet. Aber bei der Problematik dieses Threads hilft die Vorgehensweise auch nicht weiter, da es sich nicht mit Uhrzeiten wie im Zeitmodul verknüpfen lässt.
nimmnenkeks hat geschrieben:... innerhalb der Dämmerungsperioden feinere Zeiten ansprechen, oder gar in die anderen Dämmerungen gehe können
Dann bist Du wieder bei zyklischer Triggerung, hast also nichts gewonnen, außer die Abarbeitung zusätzlich verkompliziert.
nimmnenkeks hat geschrieben:Dieses Script (s.o.) müsste dann nach dem csv-Auslese-Script laufen und die in den Programmen genutzten Zeiten, entsprechenden zu aktualisieren.
Und genau das geht nicht. Du kannst auf die in Systemvariablen hinterlegten Uhrzeiten nicht triggern.

Gruß Xel66
---------------------------------------------------------------------------------
242 Kanäle in 89 Geräten und 125 CUxD-Kanäle in 23 CUxD-Geräten,
210 Programme, 145 Systemvariablen und 119 Direktverknüpfungen,
RaspberryMatic Version 2.31.25.20180225
---------------------------------------------------------------------------------

nimmnenkeks
Beiträge: 187
Registriert: 30.11.2016, 20:24

Re: csv-Datei von SD für Sonnenstand einlesen und auswerten

Beitrag von nimmnenkeks » 07.02.2017, 15:03

Scuzi,

war mit der Antwort auf Xel66's Beitrag beschäftigt.
alchy hat geschrieben:Die Essenz :mrgreen: deines Postes ist, du willst gerne täglich die Daten einer csv Datei in die CCU einlesen und die darin enthaltenen Werte des Tages in jeweiligen Systemvariablen speichern.
WELCHE der Daten hättest du denn gerne?
Alchy
Für mein pers. Empfinden würde die Bürgeliche Dämmerung vor SA und die Bürgeliche Dämmerung nach SA völlig ausreichend sein, damit man keinen Depri im Winder wegen Dauerverschluss bekommt.
Da es dann jedoch für jeden nutzbar sein sollte (ich messe dem Punkt, dass NICHT permanent ein Script laufen muss, eine höhere Bedeutung bei) und es selbstverständlich andere Nutzungswünsche der Daten gibt, wären:

- Astronomische Dämmerung SA
- Nautische Dämmerung SA
- Bürgerliche Dämmerung SA
- Bürgerliche Dämmerung SU
- Nautische Dämmerung SU
- Astronomische Dämmerung SU

bestimmt von Vorteil.
Sollte es möglich sein, die Daten über Konfigurations-Systemvariablen (Bsp.: -IST-BuergDaem-SA- o.ä.) zu bekommen, wäre wiederum ein Einparung von NICHT anzulegenden Systemvariablen von Vorteil (werden ja eh immer mehr).
Nicht jeder kann Scripte anpassen um ggf. nicht gewollte Systemvariablen anlegen zu müssen


Wenn ich BadenPower's Script http://homematic-forum.de/forum/viewtop ... 65#p268568 richtig verstanden habe, benötigt man ja 'NUR' noch zusätzlich die Systemvariablen für die ComboBox im Programm

-BuergDaem-SA-CB "Werteliste" somit frei definierbar
-BuergDaem-SU-CB "Werteliste" somit frei definierbar
die der nächtliche Trigger (TriggerBuergDaem) in den Programm(en) nutzt.


@Xel66
werden Veränderungen im Programmbeispiel von BadenPower am Tage vor Nutzung vorgenommen, geht es erst nach erneutem Triggern weiter.

Gruß Keks

nimmnenkeks
Beiträge: 187
Registriert: 30.11.2016, 20:24

Re: csv-Datei von SD für Sonnenstand einlesen und auswerten

Beitrag von nimmnenkeks » 07.02.2017, 15:07

@Xel66

Danke für Deine Geduld und Erklärungen!
Laaaaangsaaaaaam wird es :D
muss das nur noch ein paar mal durchlesen, ist halt völliges Neuland.

Tippen mit nur einer Hand (akuter nPP) dauert im Moment

Gruß Keks

Xel66
Beiträge: 4070
Registriert: 08.05.2013, 23:33
Wohnort: Nordwürttemberg

Re: csv-Datei von SD für Sonnenstand einlesen und auswerten

Beitrag von Xel66 » 07.02.2017, 15:17

Die bürgerliche Dämmerung abends ließe sich mit einem Script bewältigen, welches bei Sonnenuntergang gestartet wird und dann die Zeitdauer berechnet, die entsprechende der aktuellen Geokoordinaten für die 6° benötigt werden. Hier könnte man auf das bewährte Script zurückgreifen. Dieser berechnete Zeitraum ließe sich dann per Script auf eine boolsche Variable mit der berechneten Verzögerung anwenden (natürlich auch für die nautische und astronomische Dämmerung).

EDIT: Ich habe mir gerade mal den Spaß gemacht, und mir diese Daten bei timeanddate.de für die nächste größere Stadt hier im Umkreis angeschaut. Im Winterhalbjahr beträgt der Versatz zwischen Sonnenuntergang bis zum Ende der bürgerlichen Dämmerung etwas mehr als eine halbe Stunde (1.September - 33 Minuten, 21.Dezember - 38 Minuten, 30.April - 36 Minuten). Ich weiß nicht, ob die geringe Varianz einen solchen Aufwand lohnt. Wenn ich den Sonnenuntergang um (die durchschnittlichen) 35 Minuten verzögere, dann bin ich beim gleichen Ergebnis. Im Sommer ist das eher uninteressant.

Nur mit der morgendlichen Dämmerung ist es komplizierter zu handhaben, da ja alle vor dem eigentlichen Sonnenaufgang kommen, und somit der Sonnenaufgang als Trigger ausfällt. Dort könnte man die Vortageswerte nehmen und um 24 Stunden verzögern. Wobei wir aber wieder bei meinen Bedenken bezüglich der laufenden Verzögerungen und einem Reboot der CCU wären. Zumindest wäre hier als Fallback der Sonnenaufgang nutzbar, damit man nicht den ganzen Tag im Dunkeln sitzt.

Etwas ähnliches mache ich mit dem Vorziehen des Sonnenuntergangs im Sommer. Ich starte jeden Tag mit Sonnenuntergang einen 23,5h-CUxD-Timer, um meine Markise ca eine halbe Stunde vor Sonnenuntergang automatisch einzufahren. Ist eben nicht Addon-frei. Aber den Anspruch habe ich nicht. Mir ist CUxD zu mächtig, als dass ich drauf verzichten wollte. Läuft übrigens seit der Einrichtung einwandfrei (natürlich nur, wenn ich im Sommerhalbjahr wetterabhängig die Markise ausgefahren habe). Aber ich triggere darauf auch eine Beleuchtung innerhalb des Hauses und kann daher die Stabilität beurteilen.

Gruß Xel66
---------------------------------------------------------------------------------
242 Kanäle in 89 Geräten und 125 CUxD-Kanäle in 23 CUxD-Geräten,
210 Programme, 145 Systemvariablen und 119 Direktverknüpfungen,
RaspberryMatic Version 2.31.25.20180225
---------------------------------------------------------------------------------

Antworten

Zurück zu „HomeMatic allgemein“