Wenn dies dein erster Besuch hier ist, lies bitte zuerst die Hilfe - Häufig gestellte Fragen durch. Du musst dich vermutlich registrieren, bevor du Beiträge verfassen kannst. Klicke oben auf 'Registrieren', um den Registrierungsprozess zu starten. Du kannst auch jetzt schon Beiträge lesen. Suche dir einfach das Forum aus, das dich am meisten interessiert.
Ich nehme an, wenn die Helligkeit wieder über 7800Lux steigt aber unter 12kLux bleibt, wird die Durchsichtposition beibehalten? Erst wenn wieder mehr als 12kLux erreicht werden, beginnt der 150s-Timer? Wann wird nun aber der Timer gestoppt? Wenn die Helligkeit unter 12kLux oder unter 7800Lux fällt?
So genau habe ich mir das ehrlich gesagt noch nie angesehen. Ich persönlich würde die Durchsichtposition im Hysteresebereich beibehalten (also immer erst bei mehr als 12kLux wird der Timer zum beschatten gestartet) und den Timer auch nur beenden wenn nochmal unter 7800Lux auftreten. So gelten immer dieselben Grenzwerte in allen Fällen.
Auch wenn ich die Formel nicht explizit nachvollzogen habe, hast Du mit dem Problem vollkommen recht. Habe das bisher vor mir her geschoben, da man das mit dem Winkel-Offset auch recht gut abdecken kann. Ist ein ToDo für eine kommende Version...
ja super! Ich glaube es ist wirklich nur diese eine einfache Korrektur der effektiven lamellenbreite - ich probiere das demnächst mal aus...
Die Handhabung der Dämmerung wurde hier bereits angesprochen und ich habe das auf dem Schirm. Allerdings ist mir gerade nicht so recht klar, was Du mit der Elevation bzgl. Dämmerung bezweckst!?
Ganz einfach - Dämmerung ist definiert als "Sonne ist hinter dem Horizont"
Je nach Anwendung sind das 6, 12 oder 18 Grad (die zivile, nautische oder astronomische Dämmerung führt zu unterschiedlicher Dunkelheit). Es würde daher einfach die Prüfung genügen ob Elevation > xx. Das wäre vom Wetter unabhängig und ganz simpel!
starwarsfan an dieser Stelle einen großen Dank für deine Arbeit! Ich verfolge das mit und dein Baustein ist einer der Gründe, warum ich edomi gerade ernsthaft teste. Noch bin ich von der Beschattung weit weg, aber der Tag wird kommen - und dann eventuell schon mit der neuen Version wäre super. Da ich viel Fensterfläche habe spielt die Temperatur eine entscheidende Rolle.
- Azimuth/Elevation: Meine Wetterstation kann das nicht - ein Hinweis z.B. auf LBS 151 für Eingang E4/E5 wäre hilfreich, mit Geduld gibt es im Thread einen screenshot als Hinweis
Edomi neustart:
Bei mir liegen die Werte für Helligkeit/Elevation usw. nicht sofort vor - wenn ich dann die Berechnung triggere wirken die Standardwerte und alles fährt erst mal hoch. Gibt es einen Weg hier default=leer zu lassen? Die interne Behandlung dieses Sonderfalls wäre dann "nichtstun" bis alle nötigen Werte vorliegen.
Ich würde die entsprechenden KOs remanent machen, dann sind beim Edomi-Neustart die Werte von vor dem Edomi-Neustart vorhanden.
elevation Berechnung
Ich habe 180Grad Lamellen (80mm/70mm) und der LBS berechnet relativ steile Winkel - testweise konnte ich diese aber noch um einiges weiter öffnen. Und dann habe ich angefangen im Code zu blättern. Ich vermute im Code folgenden Fehler in der Berechnung LB_LBSID_calculateShutterAngle():
Die Rechnung berücksichtigt nicht den Azimuth im Bezug zur Fassadenrichtung. Bei 45 Grad wirken die Lamellen eigentlich ungefähr sqrt(2) "größer", im Grenzfall 90 Grad Unterschied genügen völlig geöffnete Lamellen für Schatten.
Zur Vorstellung: Ich lege eine senkrechte Ebene genau in den Lichtstrahl. Bei frontalem Einfall ist die wirksame Lamellenbreite E[9] wie in der jetzigen Rechnung. Schneide ich schräg dazu, dann wird die effektive Lamellenbreite größer. Dies wird
E[9]_eff = E[9] / cos(alpha) mit alpha = E[5] - E[6]
Könnt ihr das nachvollziehen? Oder irre ich mich da?
Auch wenn ich die Formel nicht explizit nachvollzogen habe, hast Du mit dem Problem vollkommen recht. Habe das bisher vor mir her geschoben, da man das mit dem Winkel-Offset auch recht gut abdecken kann. Ist ein ToDo für eine kommende Version...
Dämmerung
Die Dämmerung scheint rein über den Helligkeitswert zu laufen - wäre es nicht hilfreich hier die Elevation zu nutzen?
Ich möchte schließlich auch am Morgen bei Nebel dass die Jalousien rechtzeitig aufgehen.
Also direkt über einen einstellbaren Schwellwert für die Berechnung if (Elevation < -6) then "Bürgerliche Dämmerung" zu verwenden. siehe [https://de.wikipedia.org/wiki/D%C3%A4mmerung]
Die Handhabung der Dämmerung wurde hier bereits angesprochen und ich habe das auf dem Schirm. Allerdings ist mir gerade nicht so recht klar, was Du mit der Elevation bzgl. Dämmerung bezweckst!?
wenig durchdachte Gedanken:
Weiterhin habe ich von meiner MDT Wetterstation ebenfalls ein KO für die genauer gemessene Dämmerungs-Helligkeit, das bis 1000 lux max arbeitet. Einen extra Eingang für die Helligkeit zur Dämmerungsauswertung würde ich nutzen - bei Nutzung der Elevation aber vielleicht auch überflüssig?
Vielleicht wäre Dämmerung auch als Extra-Baustein denkbar, da das für alle Storen rundrum gilt und eigentlich ein einziges KNX KO aus dem Bus genügen würde. Wie man dann aber alles zusammenbringt und die Sperre bei einer geöffneten Türe löst?
Mit einem extra-Baustein habe ich bereits experimentiert. Das war jedoch von weniger Erfolg bekrönt, da sich die beiden immer irgendwie in die Quere kommen bzw. gekommen sind.
Ausblick:
Ich bin aktuell dabei, die ersten Überlegungen zu einer vollständig überarbeiteten Version des Bausteines zu machen. Siehe dazu die Beiträge ab #226 hier in diesem Thread. Das heisst, dass ich am jetzigen Baustein nach Möglichkeit keine grundlegenden Veränderungen mehr vornehmen möchte, solange dieser stabil in dieser Form funktioniert. Der kommende Baustein sollte dann erheblich mehr Funktionalität bieten, gerade hinsichtlich Timern für Beschattung und Dämmerung sowie dem Handling von Temperaturen. Aber das ist alles erst am entstehen und wie das im Detail aussieht im Moment völlig offen.
Beschattungsprogramm mit den drei Verzögerungszeiten (hell=nach der Zeit wird beschattet wenn Luxwert überschritten; Durchsichtsposition nach 15min unter Helligkeitsschwelle (bei mir 100% Höhe mit waagrechten Lamellen) und dann nach weiteren 60min unter Helligkeitsschwelle wird die Jalousie komplett hochgefahren)
Die Helligkeit überschreitet den Wert von "Hell [kLux] = 12"
Wenn Helligkeit über 12kLux bleibt, wird nach "Hell [s] = 150" Sekunden beschattet
Wenn Helligkeit unter 7800Lux bleibt, wird nach "Durchsichtposition [min] = 15" Minuten der Behang waagerecht gestellt
Wenn Helligkeit weiterhin unter 7800Lux bleibt, wird nach "Rückstellung [min] = 60" Minuten der Behang nach oben gefahren, also ganz geöffnet
Ich nehme an, wenn die Helligkeit wieder über 7800Lux steigt aber unter 12kLux bleibt, wird die Durchsichtposition beibehalten? Erst wenn wieder mehr als 12kLux erreicht werden, beginnt der 150s-Timer? Wann wird nun aber der Timer gestoppt? Wenn die Helligkeit unter 12kLux oder unter 7800Lux fällt?
Also - erst mal großes Lob an dieses umfangreiche Modul!
Ich probiere seit ein paar Tagen damit herum und nähere mich langsam der gewünschten Funktion - viel besser als das einfache Verhalten der MDT Wetterstation!
Aber natürlich habe ich Fragen und Anmerkungen:
für mache Sachen sucht man sich nen Wolf, hier wäre der eine oder andere Hinweis in der Doku nützlich:
- Azimuth/Elevation: Meine Wetterstation kann das nicht - ein Hinweis z.B. auf LBS 151 für Eingang E4/E5 wäre hilfreich, mit Geduld gibt es im Thread einen screenshot als Hinweis
- E6 Ausrichtung: Das Beispiel ist nicht eindeutig - ein Hinweis auf Westfassade = 270 Grad wäre nützlich
Edomi neustart:
Bei mir liegen die Werte für Helligkeit/Elevation usw. nicht sofort vor - wenn ich dann die Berechnung triggere wirken die Standardwerte und alles fährt erst mal hoch. Gibt es einen Weg hier default=leer zu lassen? Die interne Behandlung dieses Sonderfalls wäre dann "nichtstun" bis alle nötigen Werte vorliegen.
elevation Berechnung
Ich habe 180Grad Lamellen (80mm/70mm) und der LBS berechnet relativ steile Winkel - testweise konnte ich diese aber noch um einiges weiter öffnen. Und dann habe ich angefangen im Code zu blättern. Ich vermute im Code folgenden Fehler in der Berechnung LB_LBSID_calculateShutterAngle():
Die Rechnung berücksichtigt nicht den Azimuth im Bezug zur Fassadenrichtung. Bei 45 Grad wirken die Lamellen eigentlich ungefähr sqrt(2) "größer", im Grenzfall 90 Grad Unterschied genügen völlig geöffnete Lamellen für Schatten.
Zur Vorstellung: Ich lege eine senkrechte Ebene genau in den Lichtstrahl. Bei frontalem Einfall ist die wirksame Lamellenbreite E[9] wie in der jetzigen Rechnung. Schneide ich schräg dazu, dann wird die effektive Lamellenbreite größer. Dies wird
E[9]_eff = E[9] / cos(alpha) mit alpha = E[5] - E[6]
Könnt ihr das nachvollziehen? Oder irre ich mich da?
Dämmerung
Die Dämmerung scheint rein über den Helligkeitswert zu laufen - wäre es nicht hilfreich hier die Elevation zu nutzen?
Ich möchte schließlich auch am Morgen bei Nebel dass die Jalousien rechtzeitig aufgehen.
Also direkt über einen einstellbaren Schwellwert für die Berechnung if (Elevation < -6) then "Bürgerliche Dämmerung" zu verwenden. siehe [https://de.wikipedia.org/wiki/D%C3%A4mmerung]
wenig durchdachte Gedanken:
Weiterhin habe ich von meiner MDT Wetterstation ebenfalls ein KO für die genauer gemessene Dämmerungs-Helligkeit, das bis 1000 lux max arbeitet. Einen extra Eingang für die Helligkeit zur Dämmerungsauswertung würde ich nutzen - bei Nutzung der Elevation aber vielleicht auch überflüssig?
Vielleicht wäre Dämmerung auch als Extra-Baustein denkbar, da das für alle Storen rundrum gilt und eigentlich ein einziges KNX KO aus dem Bus genügen würde. Wie man dann aber alles zusammenbringt und die Sperre bei einer geöffneten Türe löst?
Hier mal der entsprechende Auszug aus der Online-Hilfe:
HTML-Code:
Dunkel [%] oder niedriger Energieeintrag [%]
Hinweis: Ob die Bezeichnung Dunkel [%] oder niedriger Energieeintrag [%] angezeigt wird hängt von der Wahl der Maßeinheit in der Auswahlliste Auswerten nach ab.
Der Wert für die Rückstellung berechnet sich als prozentualer Wert von dem Grenzwert im Dreh-/Eingabefeld Dunkel [%] oder niedriger Energieeintrag [%]
Beispiel: Der Grenzwert für die Dunkelheit, bei der Alarm ausgelöst wird, beträgt 10 [kLux].
Bei einem Rückstellwert von -20% beträgt die Helligkeit, bei der der Alarm zurückgesetzt wird, 8 [kLux].
Beschattungsprogramm mit den drei Verzögerungszeiten (hell=nach der Zeit wird beschattet wenn Luxwert überschritten; Durchsichtsposition nach 15min unter Helligkeitsschwelle (bei mir 100% Höhe mit waagrechten Lamellen) und dann nach weiteren 60min unter Helligkeitsschwelle wird die Jalousie komplett hochgefahren)
Was hat es mit der Angabe "Dunkel [%]" auf sich? Was bewirken die dort konfigurierten 35%?
Zuletzt geändert von starwarsfan; 29.09.2016, 16:28.
Grund: Removed not working image quote
ach ja, gerne stehe ich natürlich auch für ein Konzeptreview oder -diskussion zur Verfügung, falls das irgendwie helfen sollte... Die Idee mit der Aufteilung in zwei oder mehr Bausteine finde ich auch interessant und gut.
Und: die Konfiguration der Quadra war damals auch eine längere Aktion bis das mal sauber funktionierte... Aber der WAF war riesig und die Heizkosten im Winter sind deutlich reduziert durch die intelligente "Solar"ausnutzung!
Das glaub' ich Dir gerne. Genauso geht es mir auch mit dem Baustein hier. Der "wächst" ja auch und das nicht zu knapp.
ach ja, gerne stehe ich natürlich auch für ein Konzeptreview oder -diskussion zur Verfügung, falls das irgendwie helfen sollte... Die Idee mit der Aufteilung in zwei oder mehr Bausteine finde ich auch interessant und gut.
Und: die Konfiguration der Quadra war damals auch eine längere Aktion bis das mal sauber funktionierte... Aber der WAF war riesig und die Heizkosten im Winter sind deutlich reduziert durch die intelligente "Solar"ausnutzung!
Ergänzt wurde das noch durch eine intelligente, Wettervorhersageabhängige Heizungssteuerung, aber das ist ein anderes Thema...
Kannst Du (oder wer auch immer eine Quadra hat) dazu einige Screenshots machen?
hier mal ein Screenshot vom Beschattungsprogramm mit den drei Verzögerungszeiten (hell=nach der Zeit wird beschattet wenn Luxwert überschritten; Durchsichtsposition nach 15min unter Helligkeitsschwelle (bei mir 100% Höhe mit waagrechten Lamellen) und dann nach weiteren 60min unter Helligkeitsschwelle wird die Jalousie komplett hochgefahren): Beschattungsprogramm_Quadra.PNG
um morgens nicht unnötig oft die Jalousie in der Höhe zu fahren lass ich hier immer die Jalousie erstmal auf 100% Höhe mit waagrechten Lamellen öffnen und aktiviere das Hitzeprogramm (Temperaturprogramm habe ich nicht mehr aktiv). Über das Hitzeprogramm kommt dann die Entscheidung ob ganz geöffnet wird, oder eben beschattet werden soll (und damit bleiben die Jalousien dann alle erstmal auf "Wartestellung" 100% mit waagrechten Lamellen ohne ganz zu öffnen).
ich hab ja schonmal geschrieben daß ich definitiv Interesse daran habe und mit der Beschreibung liest sich das so als ob wir sehr sehr ähnliche Anforderungen haben
Die Hitzeschutzfunktion / Raum- und Außentemperaturtemperaturabhängige Beschattung der Quadra fehlt mir grad schon sehr...
Bei der Quadra nutzte ich das Hitzeprogramm in Verbindung mit einer kleinen Logik im wiregate.
Dazu habe ich im wiregate den mittelwert aus aktuell vorhergesagte Tageshöchsttemperatur und nächtlicher Tiefsttemperatur berechnet um zu entscheiden ob und wie lange beschattet werden soll:
- bei mittleren Temperaturen über 21° wurde morgens die Jalousie nach Dämmerungsprogrammende sofort auf Beschattungsprogramm gestellt (um auch schon bei den ersten Sonnenstrahlen die noch keine hohen Luxwerte liefern schon zu beschatten und die Bude kühl zu halten. Dies habe ich dann so erreicht daß der Grenzwert für die Innentemperatur auf 16°C gesetzt wurde (und damit immer das Hitzeprogramm mit entsprechender Beschattungsauslösung nach Dämmerungsende sofort aktiv war)
- bei niedrigeren Temperaturen habe ich dann schrittweise den zulässigen Raumtemperaturwert angehoben (bei kühlen Tagen unter 12° dann bis auf 24° zulässige Raumtemperatur, so daß immer erstmal solar geheizt wird bis 24°C erreicht sind.
hier mal um das etwwas anschaulicher zu machen mein perl Code des Logikprozessors im wiregate:
Code:
HitzeprogInnenGWNachAngesagterWetterMaxTemp => {receive=>['6/0/25','6/0/36'], transmit=>'6/5/7',
translate=>sub{
my $Tagesmittel = ( $input->[0] + $input->[1] ) / 2;
plugin_log($plugname, "MaxTemp: ".$input->[0]."°C, MinTemp: ".$input->[1]."°C, Tagesmittel: ".$Tagesmittel."°C");
return 16 if $Tagesmittel>21;
return 19 if $Tagesmittel>19;
return 22 if $Tagesmittel>18;
return 23 if $Tagesmittel>15;
return 24 if $Tagesmittel<=12;},
debug=>1, eibd_cache=>48600},
Den Grenzwert für die Außentemperatur habe ich fest auf 15°C gesetzt, der Innengrenzwert wurde über die Logik oben entsprechend berechnet. Somit wurde über das Hitzeprogramm entweder die Jalousie aktiv aufgefahren (zum heizen im Winter) oder eben schon sofort die Beschattung ausgelöst.
Nach dem was ich aus der Beschreibung von Dir lese könnte das so auch recht leicht mit Deinem Baustein funktionieren indem man auf die vorhergesagte Temperatur den Mittelwert gibt und in Abhängigkeit dazu einen Offset auf die Raumsolltemperatur gibt. Genauer sieht man das dann aber mit Deinem Code
Wir verarbeiten personenbezogene Daten über die Nutzer unserer Website mithilfe von Cookies und anderen Technologien, um unsere Dienste bereitzustellen. Weitere Informationen findest Du in unserer Datenschutzerklärung.
Indem Du unten auf "ICH stimme zu" klickst, stimmst Du unserer Datenschutzerklärung und unseren persönlichen Datenverarbeitungs- und Cookie-Praktiken zu, wie darin beschrieben. Du erkennst außerdem an, dass dieses Forum möglicherweise außerhalb Deines Landes gehostet wird und bist damit einverstanden, dass Deine Daten in dem Land, in dem dieses Forum gehostet wird, gesammelt, gespeichert und verarbeitet werden.
- und dann eventuell schon mit der neuen Version wäre super. Da ich viel Fensterfläche habe spielt die Temperatur eine entscheidende Rolle.
Einen Kommentar schreiben: