[ASC] Spezieller "Eingriff" in die Beschattung

[flummy1978]

Hallo zusammen,

grundsätzlich hab ich in der Steuerung so ziemlich alles so eingestellt und verbunden wie ich es gern hätte. Einige Sachen könnten etwas schneller reagieren aber dann wäre es in anderen Situationen wieder zu schnell usw....
Aber eine Sache "stört" mich noch ein wenig. Ich habe in meinem Wohnzimmer einen Wintergarten intergriert. Jeder weiß wie schnell das gehen kann, dass die Temperatur ansteigt - Ich hatte im Februar das erste mal 37 ° im Wohnzimmer  - hier war es noch sinnvoll. Im Juli ist das sicher nicht mehr der Fall.

Aus diesem Grund habe ich neben der normalen Beschattung auch eine eigene manuelle Mess- und Rechenmethode "entwickelt" anhand dieser ich noch etwas schneller erkennen kann, dass ich Beschatten muss / soll. Ich habe sie getestet, indem ich mir einen "potentiellen Eingriff" dokumentiert habe und diesen mit eben der automatischen Beschattung verglichen. Diesen Eingriff würde ich gern ASC begreiflich machen und "halb-automatisch" in Beschattung fahren, weil nach der Beschattung alles wieder im Automatikmodus laufen soll - D.h. Abends soll die Markise eben auch wieder einfahren und nicht auf letzter Manueller Position stehen bleiben.

Meine bisherige Idee war lediglich

Code Auswählen Erweitern

ASC_ExternalTrigger - DEVICE:READING VALUEACTIVE:VALUEINACTIVE POSACTIVE:[POSINACTIVE VALUEACTIVE2:POSACTIVE2], Beispiel: "WohnzimmerTV:state on:off 66:100" bedeutet das wenn ein "state:on" Event kommt soll das Rollo in Position 66 fahren, kommt ein "state:off" Event soll es in Position 100 fahren. Es ist möglich die POSINACTIVE weg zu lassen dann fährt das Rollo in LastStatus Position.
zu verwenden. Hierbei hätte ich das Problem, dass sobald meine Überwachung meldet, dass nicht mehr beschattet werden soll die Markise ja erstmal einfahren würde und dann durch die Beschattungskontrolle vom ASC wieder herausfahren würde.

Die eigene Überwachung wird über einen Temperaturantsieg im Raum geregelt. Hier kann ich auch diverse readings setzen oder löschen (falls das hilft)
Kann mir jemand einen Schubs in die richtige Richtung geben, wie ich das Ganze anstellen könnte ?

Würde mich freuen, wenn mir hier jemand weiter helfen könnte

Vielen Dank im voraus
VG
Andreas

[loetmeister]

Hi,

Könnte man nicht einen virtuellen Helligkeitssensor anlegen, den du mit der Markise verknüpfst? In den Sensor kannst du die reellen Helligkeitswerte übernehmen, aber im Fall eines starken Temperaturanstieg im Wintergarten übersteuern und die Beschattung erzwingen. Helligkeitssensoren sind ja frei zuordbar. Auch die Aktualisierungshäufigkeit könntest du anpassen um eine schnelle Steuerung zu erreichen.
Wie man so einen virtuellen Sensor anlegt, der auch Events für ASC generieren kann... Weiß ich leider nicht. 

Gruß,
Thomas

[flummy1978]

Hai Thomas,

vielen Dank für Deinen Vorschlag.... Grundsätzlich klingt die Idee gar nicht so schlecht - Ich würde quasi die Ursache für das Shading manipulieren und hätte nichts mit der eigentlichen Rollo ääähhh Markisenfahrt zu tun *grübel*

Ich war drauf und dran es einzurichten dann kam mir mein AAAAAAaaaaaaber in die Gedanken:
Angenommen es ist etwas sonniger - ASC wäre in der Vorbereitung zu Beschatten  -> Dann geht die Sonne für eine Weile weg -> ASC fängt dann die Beschattungsroutine wieder einen Schritt tiefer an (Was wahrscheinlich zu 99,999 % passt) Nun kommt aber mein Problem:
Die Temperatur bleibt in dem Raum bzw steigt noch kurz weiter -> Mein Eingriff würde jetzt den Helligkeitssensor manipulieren "Beschatten" wollen und genau das geht jetzt eben nicht schneller als wenn jetzt auf einmal die Knüppelsonne rauskommt, weil ASC ja seine Routine wieder eine Stufe darunter fortgesetzt hat.

Das und die Manipulation des Helligkeitssensors würde imho dazu führen, dass ich vielleicht minimal früher beschatten würde aber auch Gefahr laufen würde wieder zu entschatten, wenn es über meine ASC_Shading_waiting_period - Zeit hinaus anhalten würde ;(

Ich habe es aktuell mit einer externen Ansteuerung gelöst, die dann widerum auf die Beschattung reagiert, "Trockentest" scheinen zu funktionieren, mal sehen wie es dann live ist.... aber vielleicht hat ja noch jemand eine Idee

VG
Andreas

[flummy1978]

Hallo zusammen,

schade, dass niemand eine noch bessere Eingriffmethode hat, als meine bisherige. Jedoch habe ich bei meiner noch keinen Nachteil gefunden und sie funktioniert auch:

Ein Notify wird ausgelöst, wenn die Temperatur sich verändert -> danach wird ein neues Reading kontrolliert -> ist es an -> wird der Rest ignroiert -> ist es aus, werden alle anderen Bedingungen geprüft und bei Erfolg irgendwann die Markise manuell auf die shading_pos gefahren (in meinem Fall 90) -> wenn es regnet, greift ASC genauso ein wie wenn die Beschattung begonnen oder beendet wird.

Das Einzige was mich noch ein wenig grübeln lässt, ob ASC_RainProtection von ASC_BlockingTime_afterManual beeiflusst wird, ansonsten dürfte es, nach meinem manuellen Beschatten, eine Stunde lang nicht regnen......
Aber vielleicht kann mir das ja noch jemand beantworten ?

VG
Andreas

[ch.eick]

Hallo Andreas,
ich bin gerade an einer vergleichbaren Problematik. Bei mir blendet es aber nur zu bestimmten Situationen auf meinen Schreibtisch.

Dazu habe ich ein ASC_Brightness (DOIF im Perl Modus) Device angelegt, aus dem ASC dann den Brightness Wert entnimmt.
Dieses Device berechnet mir bei änderung des Sonnenstands (Astro) einen neuen Brightness Wert aus dem Durchnitt von drei wunderground Wetterstationen
mit UV und Radiation Sensoren. Das klappt für die Beschattung bereits seit mehreren Jahren und ich brauche keine Hardware dafür.

Nun habe ich das ganze um die Blendung erweitert. Es wird zu bestimmten Sonnenpositionen und in Abhängigkeit meiner PV-Strings im Osten ein Trigger für das
Blenden gesetzt und damit ASC das mit bekommt wird brightness etwas höher wie Sonnig überschrieben, also die Beschattung gestartet.
Mein Test heute war leider noch nicht so erfolgreich, da ASC zu träge reagiert hat, was ja auch Dein Problem ist.
Das Shading in hat gut 30 Minuten gedauert und ist erst gestartet, als es fast schon zuspät gewesen ist.

EDIT:
   Ich habe jetzt erst mal die Kriterien mit dem Sonnenstand und der PV-Leistung im Osten vor verlegt, sodass ASC für die Beschattung mehr
   Zeit hat die Warte Kette zu durchlaufen und zum Ende hin auch das Entschatten früher einleitet.
   Wie gesagt, ich verwende nur ein Überschreiben des brightness Wertes, damit ASC im automatischen Modus bleibt.

   Ob die Situation, dass eine Blendung direkt in Shading übergeht auftritt kann ich noch nicht sagen. In meinem Fall müssten dann die Schwellwerte für Shading In/Out
   entsprechend verlassen werden.

   Hierbei muss SunAz/SunEl und auch Sunny/Cloudy innerhalb des Bereiches für das Shading im ASC Device liegen. Wenn man mag, dann
   könnte man das natürlich im DOIF ausprogrammieren, aber das wäre ja dann schon ein eigenes Modul


Die Variante mit dem Trigger habe ich noch nicht getestet, was bei mir mit einen normalen Rollo bezüglich des hochfahrens und wieder Beschatten jedoch nicht so schlimm wäre.

Meine bisherige Implementierung verwendete noch ein notify und ein Dummy, was ich jetzt mit dem DOIF zusammen gefasst habe, um dort noch beliebigen Code
unter zu bringen. Auch die Darstellung im FHEMWEB mit uitable finde ich mitlerweile ziemlich attraktiv.

Das ASC_Brighness Device liefert somit generell den brightness Wert für alle Rollos und bisher zusätzlich die Manipulation für das Blenden auf einem Fenster, was jedoch
aufgrund der entsprechenden Konfiguration mit SunAz/SunEl keine Auswirkung auf die anderen Rollos hat. Später könnte man natürlich noch Code für weitere Fenster einfügen,
da man das sehr schön mit uitable erweitern kann. IM DOIF wären auch noch mehrere Blöcke für jedes einzelne Fenster denkbar.

VG
   Christian

[flummy1978]

Hey Christian,

vielen dank für die Vorstellung und Erklärung Deiner Problematik / Vorgehensweise. Ich bin mir sicher, dass hier der ein oder andere eine Lösung für sein Problem finden würde, WENN sie denn mal lesen würden 

nun denn ... in meinem Fall funktioniert meine Vorgehensweise mittlerweile doch sehr gut. Ich hatte auch an einen Eingriff in die Brightness Werte gedacht und damit gespielt, aber genau das Problem, dass mind. 2 ASC_waiting_period vergehen muss, spricht dagegen. Ich habe sonst zu kaum einer Zeit das Problem, dass ich eingreifen muss. Aus diesem Grund würde ich die vorhandenen Zeiten / Einstellungen eben auch nicht umgehen wollen.

An unseren beide Beispielen sieht man jedoch, dass man eben nicht alles ausgrenzen kann, mit einem einzigen Modul. Manchmal muss man eben doch so eingreifen, wie wir es in unserem Fall gemacht haben.

VG
Andreas

[ch.eick]

nun denn ... in meinem Fall funktioniert meine Vorgehensweise mittlerweile doch sehr gut. Ich hatte auch an einen Eingriff in die Brightness Werte gedacht und damit gespielt, aber genau das Problem, dass mind. 2 ASC_waiting_period vergehen muss, spricht dagegen. Ich habe sonst zu kaum einer Zeit das Problem, dass ich eingreifen muss. Aus diesem Grund würde ich die vorhandenen Zeiten / Einstellungen eben auch nicht umgehen wollen.

An unseren beide Beispielen sieht man jedoch, dass man eben nicht alles ausgrenzen kann, mit einem einzigen Modul. Manchmal muss man eben doch so eingreifen, wie wir es in unserem Fall gemacht haben.

Hey Andreas
Welchen Weg hast Du denn nun genommen, den Trigger, oder die Wartezeiten mit Brightness?

Ich habe jetzt gerade auf den Trigger umgestellt, das geht einfach schneller und reagiert sofort. Der erste Test war schon erfolgreich und ich konnte auch eine andere Position wählen als beim Brightness.
Das Blenden betrifft ja nur den Kopf und die Bildschirme.

(@CoolTux)
In Bezug auf Dein Problem mit dem sofortigen zurück fahren müsste man mal Testen, ob ein gleichzeitiges Überschreiben der Brightness im Hintergrund bereits diese Funktion mit allen Wartezeiten aktiviert.
Sollte das klappen müsste das Rollo / die Markiese direkt in die Beschattung fahren. @CoolTux, könntest Du da etwas zu sagen?

VG
    Christian

[flummy1978]

Holla,

irgendwie hatte ich schon geantwortet, aber scheinbar hat mich die Forumssoftware doch nicht so gemocht und es igniert. Daher nochmal in Kürze:

Hey Andreas
Welchen Weg hast Du denn nun genommen, den Trigger, oder die Wartezeiten mit Brightness?

Weder noch - Ich greife "manuell" extern ein. Am Ende meiner eigenen Auswertung über den Temperaturanstieg im Raum folgt also ein:

Code Auswählen Erweitern

fhem ("set Rollo_EG_WZ_MAR_markise pct 90");
Hierdurch fährt die Markise auf meine Beschattungsposition. Damit erreiche ich (für meinen Fall) zwei Vorteile: Ich kann selbst bestimmen (lassen), wann genau die Markise raus fährt, weil es in dem Raum zu warm geworden ist - und durch "blocking_after_manuall" wird verhindert, dass die Markise direkt wieder hoch fährt - auch wenn im ASC grad bsw für Entschattung gesorgt werden würde. Im Normalfall kommt das ASC wenige Minuten hinterher und würde auch beschatten, allerdings ist ein "offener" Wintergarten die Hölle, wenn da 5 min die Sonne direkt drauf steht. Die Beschattungsautomatik vom ASC funktioniert meist gut, außer im Hochsommer - wenn es einfach zu schnell geht, da ist sie für viele andere Fälle und sicher 99%der Nutzer sehr gut - in meinem Fall etwas zu langsam

All das wird verhindert, lediglich rain protection würde eingreifen - und das soll auch so sein

VG
Andreas

[ch.eick]

Holla,

irgendwie hatte ich schon geantwortet, aber scheinbar hat mich die Forumssoftware doch nicht so gemocht und es igniert. Daher nochmal in Kürze:

Weder noch - Ich greife "manuell" extern ein. Am Ende meiner eigenen Auswertung über den Temperaturanstieg im Raum folgt also ein:

Code Auswählen Erweitern

fhem ("set Rollo_EG_WZ_MAR_markise pct 90");
Hierdurch fährt die Markise auf meine Beschattungsposition. Damit erreiche ich (für meinen Fall) zwei Vorteile: Ich kann selbst bestimmen (lassen), wann genau die Markise raus fährt, weil es in dem Raum zu warm geworden ist - und durch "blocking_after_manuall" wird verhindert, dass die Markise direkt wieder hoch fährt - auch wenn im ASC grad bsw für Entschattung gesorgt werden würde. Im Normalfall kommt das ASC wenige Minuten hinterher und würde auch beschatten, allerdings ist ein "offener" Wintergarten die Hölle, wenn da 5 min die Sonne direkt drauf steht. Die Beschattungsautomatik vom ASC funktioniert meist gut, außer im Hochsommer - wenn es einfach zu schnell geht, da ist sie für viele andere Fälle und sicher 99%der Nutzer sehr gut - in meinem Fall etwas zu langsam

All das wird verhindert, lediglich rain protection würde eingreifen - und das soll auch so sein

VG
Andreas

Hallo Andreas,

so wie ich das verstehe wäre das genau der Eingriff mit dem ASC_ExternTrigger, der reagiert sofort und den könntest Du aus einem anderen Device (DOIF) übernehmen. In meinem Fall ist das ein reading, was ich mit meinen Kriterien on/off setze. Der Vorteil ist, dass ASC_keinen manuellen Eingriff als Status erkennt. Natürlich darf das on/off nicht ständig wechseln , sollte also gut ausprogrammiert sein.

Ich Teste noch weiter, wegen Deiner Aussage mit dem Übergang zur Beschattung durch ASC. Gibt es da wirklich eine Überlagerung? Wie verhält es sich, wenn der Trigger weg geht?
Gestern hatte ich die Situation, dass die Beschattung schneller war und durch den Trigger ein Wechsel auf die Blende Position erfolgte. Das fand ich ganz okay so.

VG
   Christian

Im Bild habe ich mal versucht alle Parameter vom Blenden, Beschatten und die Ist Werte zusammen zu tragen.

[eurofinder]

@Christian:
Mich würde interessieren, welchen Style du im Screenshot genutzt hast?
Wärst du so nett und würdest den Quelltext der Anzeige hier einstellen? Ich finde die Art der Darstellung sehr gelungen und übersichtlich.

Gruß
eurofinder

[ch.eick]

@Christian:
Mich würde interessieren, welchen Style du im Screenshot genutzt hast?
Wärst du so nett und würdest den Quelltext der Anzeige hier einstellen? Ich finde die Art der Darstellung sehr gelungen und übersichtlich.

Gruß
eurofinder

Wurde per PN beantwortet, da es hier offtopic ist.

[flummy1978]

so wie ich das verstehe wäre das genau der Eingriff mit dem ASC_ExternTrigger, der reagiert sofort und den könntest Du aus einem anderen Device (DOIF) übernehmen. In meinem Fall ist das ein reading, was ich mit meinen Kriterien on/off setze. Der Vorteil ist, dass ASC_keinen manuellen Eingriff als Status erkennt. Natürlich darf das on/off nicht ständig wechseln , sollte also gut ausprogrammiert sein.

Ich Teste noch weiter, wegen Deiner Aussage mit dem Übergang zur Beschattung durch ASC. Gibt es da wirklich eine Überlagerung? Wie verhält es sich, wenn der Trigger weg geht?
Gestern hatte ich die Situation, dass die Beschattung schneller war und durch den Trigger ein Wechsel auf die Blende Position erfolgte. Das fand ich ganz okay so.

Je länger ich darüber nachdenke umso interessanter könnte es sein..... Ich setze den Trigger ja mit dem Shading_Out zustand vom ASC zurück (in meinem Fall ist es ja die Hitze und nicht das Kurzzeitige Blenden) - Also würde auch das passen. Aber da muss ich Lust / Zeit zu haben - Never touch a running System ist ja nicht von ungefähr 

VG
Andreas