Hallo, ich möchte gerne einen Sonnenschutz aktivieren in Abhängigkeit von einem Lichtsensor.
Dazu würde ich gerne die Werte des Sensors über die letzten x Minuten sammeln und den Mittelwert berechnen, um den Trigger robuster zu haben.
Ich habe leider überhaupt keinen Ansatz wie man sowas sinnvoll bewerkstelligen kann.
Gibt es Apps die beim Sammeln der Sensordaten und dem Berechnen mit den gesammelten Daten helfen?
Wie würdet ihr das anstellen?
Ich geh mal davon aus, dass du die Reaktion deines Lichtsensors verlangsamen willst, dass dein Sonnenschutz z.B. bei Wolken nicht alle paar Minuten raus- und rein fährt.
Das mit einem Lux Durchschnitt zu machen geht zwar, ist aber kompliziert. So geht es relativ einfach:
Du brauchst die App Chronograph.
Jetzt erstell den 1. Flow:
Wenn:
Die Helligkeit ist größer als xx Lux
Dann:
Starte Chronograph Timer mit der Dauer von xx Minuten
Flow 2:
Wenn der Timer “Beispiel” ist abgelaufen
Und:
Helligkeit ist größer als xx
Dann:
Fahre Markise aus.
Das Gleiche machst du mit “kleiner als” zum wieder Einfahren.
Was passiert jetzt ? Sobald die Helligkeit deine Vorgabe erreicht, wird ein Timer mit der Dauer von deiner Zeitangabe gestartet. Sobald dieser Timer abgelaufen ist, wird nochmal geprüft, ob die Helligkeit immer noch über/unter xx Lux ist und dann erst ein- oder ausgefahren. Hast du dir das so vorgestellt ?
Alternativ kann man sowas auch machen, wenn du beispielsweise über 10 Minuten die durchschnittliche Helligkeit misst. Du lässt dabei jede Minute den Helligkeiswert in eine Variable addieren. In einer zweiten Variable lässt du diesen Wert dann anschließend durch 10 teilen und hast deinen Durchschnitt. Wenn das erledigt ist, musst die die 1. Variable wieder auf 0 setzen, sonst stimmt die Berechnung nicht mehr.
Ich glaube Dirk (@DirkG) macht das mit einer ja/nein Variable, was natürlich auch geht. Ich kau die 2. Variante gerne mit dir durch.
Danke für die Anregung.
Ich erklär mal genauer was ich vorhabe:
Ich möchte an einem bestimmten Zeitpunkt, nämlich kurz bevor die Sonne “um die Ecke kommt” (gesteuert per Azimuth) einmalig pro Tag entscheiden, ob der Sonnenschutz an einem bestimmten Fenster runterfährt oder nicht. Das soll aber von der Sonneneinstrahlung abhängig sein. Und wenn ich dann zu dem Zeitpunkt Lux messe könnte es sein, dass grade eine Wolke vor der Sonne ist oder nicht. Deshalb halte ich es für robuster, wenn ich zB gucke wie die Helligkeit über die letzten 30 min gewesen ist und dann über Mittelwert entscheide. Oder sogar über den Maximalwert innerhalb dieser 30 min. Vor dem Fenster stehen nämlich meine Monitore und das blendet dann ziemlich bei gutem Wetter… auf der anderen Seite guck ich aber gerne raus…
Dein Vorschlag wäre besser als nur einmal zu messen… aber nicht viel besser weil man eben nur 2 mal misst.
Aber trotzdem danke, weil den Chronograph kann ich für eine andere Sache benutzen.
Letztendlich möchte ich einfach nur wissen wie ich mit diesen Logik Funktionen umgehe um ein paar Daten zu sammeln und die auszuwerten.
Ich hab in ein paar anderen Beiträgen gelesen, dass Mittelwerte benutzt wurden, aber nicht wie man sie im homey ermittelt.
Falls keiner da helfen kann und ich nichts weiter dazu finde, würde ich es über zB 10 selbst erstellte Variablen machen. Das halte ich aber für relativ unelegant 
Das ist ne gute Idee!
Den Maximalwert könnte ich mit 1 oder 2 weiteren Variablen auch hinbekommen indem ich jeweils den aktuellen Wert mit dem bisher ermittelten Max-Wert vergleiche und ggf aktuallisiere.
Das Hauptproblem ist, dass du per Azimuth verschiedene Zeiten hast, wo die Helligkeit relevant wird. Das müsstest du dann auf eine halbe Stunde vor der Auslösung (Azimuth) zurück rechnen. Um beispielsweise vor dem eigentlichen Ereignis einen relevanten Wert zu bekommen, solltest du mindestens alle 5 Minuten messen. Das ist zwar alles möglich, aber ich bin nicht überzeugt, dass das Ergebnis den Aufwand rechtfertigt. Du kannst das ja mal versuchen und hier deine Erfahrungen posten. Es gibt vielleicht noch einige Leute, die vor dem gleichen Problem stehen.
Historische Mittel- oder auch Min./Max. Werte kann man glaube ich mit der Homey App Insight Trends Reloaded ermitteln lassen. Allerdings habe ich keine Erfahrungen mit dieser App und kann Dir damit nicht weiterhelfen. Zur App gibt es aber ein entsprechendes App Topic, falls man Hilfe benötigt: [APP][Pro] Insight Trends Reloaded
Bei einem wolkenlosen oder gleichmäßig bewölkten Tag wird Deine Idee funktionieren, aber mit sehr hoher Wahrscheinlichkeit nicht bei wechselnden Lichtverhältnissen.
Was nützt z.B. ein Max.-Wert von 30.000 Lux, oder ein Mittelwert von 15.000 Lux, wenn die Sonne kurz bevor sie “um die Ecke kommt” von einer dicken Wolke bedeckt wird und die Helligkeit dann nur noch bei 5.000 Lux oder weniger liegt.
Warum nutzt Du den Azimuth Trigger nicht direkt in Verbindung mit der Überprüfung der Helligkeit?
Wenn die Helligkeit >= 15.000 Lux, dann Sonnenschutz runter.
Damit der Sonnenschutz nicht bei einer kleinen Wolke dann direkt wieder hoch fährt, würde ich den Vorschlag von @Undertaker in leicht abgewandelter Form nutzen.
Oder, was noch einfacher ist, man nutzt folgende Flow Karte, falls diese für Deinen Sensor vorhanden ist:
Mit dieser Karte ist dann auch keine zusätzliche Timer App mehr notwendig.
Edit
Wenn man das Azimut in Bezug auf Sonnenauf- und Untergang bezieht, dann stimmt das. Aber für den Anwendungszweck von @Fred_Kaputtnik ist der Sonnenauf- und Untergang ja nicht relevant. Die Hausecke, an der die Sonne rum kommt, hat immer den selben Wert.
Die echten Helligkeitswerte die ich hier habe ermittle ich gerade. Dazu lasse ich seit 3 Tagen alle Lux Änderungen in ein Google Spreadsheet mit Timestamp eintragen. So kann ich dann schon in etwa sagen wann es Lux-bezogen nötig ist und wann nicht.
Letztendlich soll ja nur 1 mal am Tag entschieden werden ob der Rolladen halb runterfährt oder nicht. Und da würde ich eher im Zweifel runterfahren; also zb dann bei wechselnden Lichtverhältnissen. Aber das kann ich später ja noch anpassen.
Für mich ist erstmal wichtig, dass ich die benötigten Werkzeuge für meine Daten habe. Wie ich dann umsetze ist noch nicht ganz klar… ist sowieso nur eine Spielerei, aber irgendwie nett
Genau. Der Azimith Wert ist immer der gleiche…
Eigentlich müsste man auch noch Altitude mit einbeziehen, weil im Winter die Sonne gar nicht so hoch kommt um zu blenden…
Das wieder hochfahren des Sonnenschutzes ist auch tricky… da vor dem Fenster ein anderes Haus steht. Im Sommer läuft die Sonne über das Haus und der Schutz muss länger an sein. wenn die Sonne aber gar nicht übers Haus kommt kann der Schutz früher wieder hoch.
Da kann man sich so richtig austoben in diesem Flow 
Im Moment läuft noch die erste Version des Sonnenschutzes: anhand der Bewölkungswerte von der OpenWeather API + UV-Index + Azimuth. Diese Werte kann man auch als Prognose für die nächsten 3 Stunden haben. Dachte eigentlich das wäre ganz clever … aber die Bewölkungswerte von OpenWeather sind leider sehr oft völlig Banane …
Um überhaupt mal einen Überblick über die Helligkeitswerte zu bekommen, kann man diese auch in einer CSV-Datei ganz einfach aus Insights/Einblicke herunterladen. Dabei würde das Messintervall völlig ausreichen, wenn man als Zeitspanne einen Tag (Gestern) auswählen würde:
Das müsste man dann natürlich 1x am Tag händisch machen.
Mit der Homey App Archive Insights könnte man das ganze auch noch automatisieren.
Das nur so am Rande.
Dann würde es doch theoretisch reichen, wenn der Lux-Wert beim Erreichen des Azimut-Wertes einen definierten Wert von X überschreitet.
Als zweiter Flow müsste dann noch den Lux-Wert überprüfen, nachdem der Azimut-Wert bereits überschritten ist.
Damit das ganze einigermaßen gut funktionieren soll, müsste man meiner Meinung nach am Fenster einen entsprechenden Lichtsensor anbringen. Alles andere, insbesondere irgendwelche Wetter Apps, kann man eigentlich vergessen.
Hallo Fred,
ich würde es wie folgt versuchen:
Der obere Teil des Flows reagiert auf Änderungen des Sonnen-Azimuts.
Für diesen Teil werden zwei Zahlenvariablen benötigt: in meinem Fall hell und dunkel.
Diese beiden Variablen dienen als Zähler. hell zählt, wie oft die Helligkeit über dem eingestellten Grenzwert lag. dunkel zählt, wie oft die Helligkeit darunter lag. Der verwendete Grenzwert ist: 50.000 Lux.
Sobald sich der Azimut ändert, prüft der Flow unter anderem, ob der Azimut genau 179° erreicht hat. Wenn ja, werden beide Zähler zurückgesetzt: hell = 0 und dunkel = 0. Damit beginnt eine neue Messphase. Alte Werte vom vorherigen Durchlauf oder vom Vortag werden dadurch gelöscht.
Danach wird im Bereich von 180° bis 189° die Helligkeit ausgewertet. In meinem Fall entspricht das ungefähr diesem Zeitraum: 1° Sonnenbewegung ≈ 4 Minuten → 10° Sonnenbewegung ≈ 40 Minuten. Während dieses Bereichs prüft der Flow bei jeder Azimut-Änderung: Ist die Helligkeit größer als 50.000 Lux?
Wenn ja, wird der Zähler hell um 1 erhöht: hell = hell + 1
Wenn nein, wird der Zähler dunkel um 1 erhöht: dunkel = dunkel + 1
Dadurch wird nicht nur ein einzelner Moment betrachtet, sondern eine kleine Auswertung über mehrere Messpunkte gemacht.
Wenn der Azimut schließlich 190° erreicht, ist die Messphase beendet.
Dann prüft der Flow: Ist hell größer als dunkel?
Wenn also während der Messphase häufiger mehr als 50.000 Lux gemessen wurden als darunter, fährt das Rollo auf 0 %.
Der untere Teil des Flows reagiert auf Änderungen der Sonnen-Altitude. Es wird geprüft, wann die Sonne unter 45° fällt. Der Flow soll nicht einfach nur reagieren, wenn die Altitude kleiner als 45° ist. Das würde sonst bei jeder weiteren Altitude-Änderung erneut auslösen.
Stattdessen soll erkannt werden: Die Sonne war vorher oberhalb von 45°
und fällt jetzt auf 45° oder darunter.
Dafür wird eine zusätzliche Ja/Nein-Variable verwendet: Altitude_war_oberhalb.
Diese Variable merkt sich, ob die Sonne vorher bereits oberhalb der 45°-Grenze war.
Wenn sich die Altitude ändert und der aktuelle Wert größer als 45° ist, setzt der Flow: Altitude_war_oberhalb = Ja.
Der zweite Teil prüft, ob die Altitude entweder: kleiner als 45° oder genau 45° ist.
Zusätzlich wird geprüft: Altitude_war_oberhalb = Ja
Nur wenn diese Variable auf Ja steht, wird die Aktion ausgeführt. Anschließend wird die Variable wieder zurückgesetzt: Altitude_war_oberhalb = Nein. Das Zurücksetzen ist wichtig, damit der Flow nicht bei jeder weiteren Altitude-Änderung erneut auslöst.
Zusammengefasst macht der Flow Folgendes:
- Bei Azimut 179° werden die Zähler
hellunddunkelauf 0 gesetzt. - Zwischen Azimut 180° und 189° wird bei jeder Azimut-Änderung geprüft, ob die Helligkeit über 50.000 Lux liegt.
- Je nach Ergebnis wird entweder
helloderdunkelhochgezählt. - Bei Azimut 190° wird ausgewertet, ob es während der Messphase überwiegend hell war.
- Wenn
hell > dunkel, fährt das Rollo auf 0 %. - Zusätzlich überwacht der Flow die Sonnen-Altitude.
- Sobald die Sonne vorher über 45° war und anschließend auf 45° oder darunter fällt, fährt das Rollo auf 100 %.
- Danach wird der Altitude-Merker zurückgesetzt, damit die Aktion nur einmal pro Durchlauf ausgeführt wird.
Die für für Deinen Fall passenden Werte für Helligkeit und Altitude musst Du individuell ermitteln.
Diese Website ist gut geeignet um den Sonnenverlauf an einem Standort nachzuvollziehen: https://www.sonnenverlauf.de/
In meinem Flow nutze ich die folgenden Homey Apps:
Viele Grüße 
Wieder mal eine wirklich gute Umsetzung und Beschreibung von Dir! Vielen Dank dafür! 
Würde es eine Flow Karte Altitude wird kleiner als geben, könnte man den unteren Flow deutlich verkleinern und man könnte sogar auf die Variable verzichten.
Ich frage bei Marcel Timmermans, dem App Entwickler der App Sonnenereignisse, mal nach, ob er solche Flow Karten ergänzen kann.
Beim unteren Flow gibt es eine unnütze Flow Karte, und zwar die im roten Kästchen:
Erklärung:
Wenn die Sonne im Tagesverlauf die Höhe von über 45° überschreitet, wird die Variable Altitude_war_oberhalb auf Ja gesetzt.
Hat die Sonne ihren höchsten Stand überschritten, dann wird der Höhenwinkel wieder kleiner und erreicht irgendwann den Wert 45. Wenn der Flow dann getriggert wird, werden beide Logik Karten geprüft, wobei die Karte Altitude ist genau 45 bereits als Wahr durchgeht und den Flow weiter laufen lässt. In Verbindung mit der Variable Altitude_war_oberhalb, welche auf Ja steht, wird das Rollo bereits geöffnet und die Ja/Nein Variable auf Nein gesetzt.
Wenn der Flow das nächste Mal getriggert wird, also bei einem Höhenwinkel von 44°, dann läuft der Flow zwar über die Karte Altitude ist kleiner als 45 weiter, wird aber bei der Karte mit der Variable Altitude_war_oberhalb gestoppt, da diese bereits auf Nein gesetzt wurde.
Mit der folgenden Logik Karte kann man übrigens solche Prüfungen wie z.B. ist <= als bzw. ist >= als in nur einer Karte darstellen:
EDIT
@Meerjungfraumann, wie versprochen, habe ich zusätzliche Flow Karten beim App Entwickler angefragt → Feature request: Additional Trigger Flow cards · Issue #124 · magtimmermans/com.cyclone-software.sunevents · GitHub
Mal abwarten, was passiert.
@Meerjungfraumann, gestern wurde bereits eine neue App Version mit den neuen Flow Karten veröffentlicht → Sun Events | Homey
Was ich bei der Anfrage aber völlig übersehen hatte, dass eine Flow Karte “Azimut wird kleiner als” nicht funktioniert bzw. überflüssig ist, da der Wert ständig größer, und nicht kleiner wird… 
Habe den App Entwickler aber bereits informiert.
Ich habe zwar bereits selber Testflows erstellt, aber es wäre gut, wenn Du die neuen Karten auch mal testen könntest.
ziemlich cool eure Ideen, vielen Dank.
In meinem Fall würde ich es leicht abändern… du berechnest, ob das Licht öfter oberhalb oder unterhalb des Grenzwertes ist. Ich möchte aber bereits triggern, wenn der Wert ab und zu innerhalb der Messzeit kurz vor dem Auslösen über dem Grenzwert ist. Einen Außreißer würde ich dabei ignorieren, aber wenn es 2 oder mehr mal passiert reicht mir das aus um den Sonnenschutz zu aktivieren. Damit verhindere ich, dass ich im ungünstigen Fall zu 40% geblendet werde, obwohl es zu 60% dunkel ist
“Sonnenereignisse” verwende ich bisher auch schon für einige Sachen…
