Betatester für neues Modul AutoShuttersControl gesucht!

[sledge]

Darüber können wir uns dann gerne zu einem späteren Zeitpunkt unterhalten. Die Idee finde ich gut.
Jetzt baue ich erstmal noch die Brightness Werte pro Rolladen ein und dann testen wir erstmal ausgiebig. Danach wird die Abschattung in Angriff genommen.

Als eifriger Nutzer von Clunis Lösung fällt mir zur Abschattung folgendes ein: Ich selber verwende keine Helligkeitssensoren, ein Abschattung rein basierend auf Azimut und Elevation wäre ein Feature, das ich mir gut vorstellen kann. Als "Basisvariante" sozusagen.

Andere Frage:
Ab wann - so die Frage - lohnt sich denn für einen produktiven Nutzer von Clunis Lösung der Umstieg, um sinnvoll zu den Tests beitragen zu können? Zugegeben verfolge ich den Thread nur mit einem Auge, aber wüsste noch nicht, ob der Umstieg jetzt schon sinnvoll ist.

[CoolTux]

Das kannst eigentlich nur Du selbst wissen.
Wenn alle Features die Du über den Winter brauchst bereits enthalten sind kannst Du gerne mit testen. Abschattung dürfte ja so langsam nicht mehr aktuell sein bis zum Frühling.

[C0mmanda]

Das kannst eigentlich nur Du selbst wissen.
Wenn alle Features die Du über den Winter brauchst bereits enthalten sind kannst Du gerne mit testen. Abschattung dürfte ja so langsam nicht mehr aktuell sein bis zum Frühling.

Würde ich nur bedingt so unterschreiben.
Mein "Arbeitsplatz" liegt am Fenster und die tiefstehende Herbst-/Wintersonne blendet dermaßen das eine Abschattung auch im Winter sinnvoll sein kann.

Andere Frage:
Ab wann - so die Frage - lohnt sich denn für einen produktiven Nutzer von Clunis Lösung der Umstieg, um sinnvoll zu den Tests beitragen zu können? Zugegeben verfolge ich den Thread nur mit einem Auge, aber wüsste noch nicht, ob der Umstieg jetzt schon sinnvoll ist.

Diese Frage kann man sich am Ende immer nur selbst beantworten, ich finde den Stand aktuell aber so fortgeschritten das man es wagen kann.
Ich habe und teste das Modul im Produktiv-Einsatz.
Was kann schlimmstenfalls passieren? Ein Rolladen fährt / fährt nicht wie gewünscht.
Ist aber nur meine Meinung....

Gruß

[sledge]

Das kannst eigentlich nur Du selbst wissen.
Wenn alle Features die Du über den Winter brauchst bereits enthalten sind kannst Du gerne mit testen. Abschattung dürfte ja so langsam nicht mehr aktuell sein bis zum Frühling.

In der Tat ist mit automatisch rauf / runter + Bewohnerstatus schonmal 80% dessen enthalten, was sich in den Tagesablauf so eingeschlichen hat. Ich setze mal ne Testinstanz auf und ziehe einzwei Rolladen rüber.

[CoolTux]

Einfach mal ein paar Entwicklernews am Rande.
Dank der OOP kann ich nun alle versteckten Readings aus den Rolladen Devices entfernen. Ich halte alle Informationen in Objekten fest. Das macht vieles einfacher.
Unter anderem lastPos samt timestamp was sich auf die letzte Position bezieht bevor ASC eine Änderung gemacht hat. Deweiteren habe ich vor so langsam die Rolladen Devices in die NOTIFYDEV mit auf zu nehmen und sobald eine Stellungsänderung der Rolladen stattgefunden hat und diese nicht vom ASC selbst kam die aktuelle Stellung in lastManuPos zu schreiben. Somit haben wir schon mal wichtige Informationen zum Rolladen und seiner Position vor und nachher.



Grüße

[hexenmeister]

Ich halte alle Informationen in Objekten fest. Das macht vieles einfacher.

Stellst Du irgendwie sicher, dass bei einem FHEM-Neustart die Infos nicht verloren gehen?
In Readings sind sie ja automatisch in statefile...

[CoolTux]

Da diese Infos bisher auch nur temporär genutzt wurden da sie immer zurük gesetzt wurden bei einem Neustart ist das erstmal nicht so wichtig.
Bei bedarf kann man gerne darüber nachdenken diese Infos bei einem Neustart weg zu schreiben. So lange FHEM läuft und ein Verweiß auf das Objekt vorhanden ist bleiben die Daten jedenfalls erhalten.

[FunkOdyssey]

Ich habe gestern Abend die ersten Jalousien über die Brightness-Werte gesteuert.
Funktioniert wie es soll. Gefällt mir gut.
Ich würde mir wünschen, wenn man im ASC-Log ein wenig mehr Infos über das hätte, was gerade wirklich passiert.
Man kann nicht wirklich erkennen, dass die Jalousien gerade runtergefahren sind, weil:
- Astro-Zeitpunkt erreicht,
- Feste Uhrzeit erreicht
- oder ein Helligkeitswert erreicht wurde.



Ich habe die (neue) CommandRef gelesen und mich versucht über die ASC_brightnessMinVal und ASC_brightnessMaxVal zu informieren.
Im Quellcode erkenne ich nur Abhängigkeiten zu MinVal. Aber die Jalousien sind beim Unterschreiten von MaxVal heruntergefahren.
Das Hochfahren habe ich aktuell nicht implementiert.

Unabhängig davon sind mir die Unterschiede zwischen den beiden Attributen noch nicht klar.



Ein Brightness-Sensor könnte ja auch kurzzeitig eine Schwelle unter- bzw. überschreiten, falls bspw. eine größere Wolkenfront kommt.
Besteht irgendwie die Möglichkeit, dass erst nach zweifacher Unterschreitung oder nach einem Wartezeitraum von x Sekunden die Jalousien gefahren werden?
Ich glaube zwar, dass es in der Praxis nicht oft passieren wird, aber die Steuerung könnte sonst theoretisch ein wenig sensibel reagieren und auslösen.

[CoolTux]

Ich habe gestern Abend die ersten Jalousien über die Brightness-Werte gesteuert.
Funktioniert wie es soll. Gefällt mir gut.
Ich würde mir wünschen, wenn man im ASC-Log ein wenig mehr Infos über das hätte, was gerade wirklich passiert.
Man kann nicht wirklich erkennen, dass die Jalousien gerade runtergefahren sind, weil:
- Astro-Zeitpunkt erreicht,
- Feste Uhrzeit erreicht
- oder ein Helligkeitswert erreicht wurde.

Es sollte sich eigentlich aus der Logik heraus ergeben, da man nur eines der 3 Trigger wählen kann. Du sagst ja im Attribut
ASC_Down - astro/time/brightness
Kannst also nur eines der 3 Methoden expliziet auswählen.

Ich habe die (neue) CommandRef gelesen und mich versucht über die ASC_brightnessMinVal und ASC_brightnessMaxVal zu informieren.
Im Quellcode erkenne ich nur Abhängigkeiten zu MinVal. Aber die Jalousien sind beim Unterschreiten von MaxVal heruntergefahren.
Das Hochfahren habe ich aktuell nicht implementiert.

Unabhängig davon sind mir die Unterschiede zwischen den beiden Attributen noch nicht klar.

In der derzeitigen Umsetzung wird lediglich MinVal verwendet. Daher würde es mich auch schwer wundern wenn Deine Rollos bei unterschreitung von MaxVal gefahren sind es sei denn die beiden Werte sind gleich oder MaxVal war kleiner wie MinVal

Ein Brightness-Sensor könnte ja auch kurzzeitig eine Schwelle unter- bzw. überschreiten, falls bspw. eine größere Wolkenfront kommt.
Besteht irgendwie die Möglichkeit, dass erst nach zweifacher Unterschreitung oder nach einem Wartezeitraum von x Sekunden die Jalousien gefahren werden?
Ich glaube zwar, dass es in der Praxis nicht oft passieren wird, aber die Steuerung könnte sonst theoretisch ein wenig sensibel reagieren und auslösen.

Über eine Art Schwelle habe ich mir auch schon Gedanken gemacht. Verwendest Du Aussen oder Innensensoren für Brightness?

[hexenmeister]

Da diese Infos bisher auch nur temporär genutzt wurden da sie immer zurük gesetzt wurden bei einem Neustart ist das erstmal nicht so wichtig.
Bei bedarf kann man gerne darüber nachdenken diese Infos bei einem Neustart weg zu schreiben. So lange FHEM läuft und ein Verweiß auf das Objekt vorhanden ist bleiben die Daten jedenfalls erhalten.

In den Fällen, wo man die Daten rekostruieren kann, ist das ja völlig ok.
Es wäre nur wichtig, dass bei einem Restart die Rolladen-Logik genauso weiter bleibt, wie ohne Restart

[hexenmeister]

Bei den Helligkeitswerten müsste man das Problem mit kurzzeitigen Beleuchtung (Autoscheinwerfen etc.) ggf. durch Ermitteln vom Mittelwerden (kurzzeitigen 'Spitzen' ignorieren) und mit einer Hysterese (Wert zum Hochfahren etwas über dem Wert zum Herunterfahren und eine gewisse 'tote Zone' dazwischen) in Griff bekommen können.

[FunkOdyssey]

So ähnlich mache ich das aktuell auch schon.
Ich habe einen Mittelwert verschiedener HM-Bewegungsmelder.
Threshold oder Histerese brauche ich bei den nicht berücksichtigen, da dies bereits in der Hardware abgefangen wird.

[hexenmeister]

Threshold oder Histerese brauche ich bei den nicht berücksichtigen, da dies bereits in der Hardware abgefangen wird.

Im allgemeinverwendbaren Modul wäre dies hingegen schon notwendig

[FunkOdyssey]

In der derzeitigen Umsetzung wird lediglich MinVal verwendet. Daher würde es mich auch schwer wundern wenn Deine Rollos bei unterschreitung von MaxVal gefahren sind es sei denn die beiden Werte sind gleich oder MaxVal war kleiner wie MinVal

Genau so sagt es auch die Programmierung.
Aber dennoch sind die Jalousien gestern bei MaxVal heruntergefahren. Aber: Das scheint ein Zufall zu sein, denn die Astro-Zeit lag auch exakt zu diesem Zeitpunkt. Sehr unwahrscheinlich, aber wahr. Das ist auch der Grund wieso ich nach mehr Infos im Log gefragt habe.

Ich habe nun tatsächlich feststellt, dass meine ASC_Up | ASC_Down Konfiguration wieder überschrieben war. Ich hatte es bewusst von "astro" auf "brightness" gesetzt. Und gerade stand es wieder auf "astro". Vermutlich habe ich irgendetwas nicht gespeichert oder vielleicht durch ne ReadingsGroup wieder überschrieben. Komisch komisch.

Sorry für die Unruhe

[CoolTux]

Lieber einmal mehr Unruhe wie keine Eindeutige Funktion. Von daher alles schick.


Grüße