Winkel der Sonneneinstrahlung ins Dachflächenfenster

Begonnen von mähschaf, 13 April 2021, 13:44:02

Vorheriges Thema - Nächstes Thema

mähschaf

Hallo,

Ein weiteres meiner Corona-Projekte sieht den Einbau eines Dachflächenfensters vor.


Version 0.2: siehe Post #29

Da ich Hitze nicht mag, möchte ich einen Außenrolladen steuern in Abhängigkeit davon, ob gerade Sonne ins Fenster einfällt oder nicht.

Ich habe bei AutoShuttersControl und auch sonst hier im Forum gesucht, aber leider - außer Anfragen ohne konkret auf das Problem bezogene Lösung - nichts gefunden. Vielleicht habe ich aber auch nicht richtig gesucht. Wie auch immer ... ich denke, meine "Erweiterung" des Twilight-Devices funktioniert:

Internals:
   FVERSION   59_Twilight.pm:0.240520/2021-03-22
   INDOOR_HORIZON 0
   READINGS:
     2021-04-13 13:30:01   RelativerDachwinkel 47.90
     2021-04-13 13:30:01   azimuth         178.78
     2021-04-13 13:30:01   elevation       49.16
Attributes:
   userattr DachKorrekturNord Dachneigung
   DachKorrekturNord -23
   Dachneigung 50
   userReadings RelativerDachwinkel { sprintf("%.2f", atan(tan(AttrVal("myTL","Dachneigung","0") * pi() / 180) * sin((ReadingsNum("myTL","azimuth",0) - 90 - AttrVal("myTL","DachKorrekturNord","0")) * pi() / 180)) / pi() * 180) }


Kurze Erläuterung:
Es gibt ein User-Attribut für die Dachneigung und eines für die Korrektur des Winkels nach Norden in °. Bei mir (Ausrichtung beim Gucken aus dem Fenster nach NNW) sind das -23°.

Sollten die Bedingungen erfüllt sein, dass
a) die Sonne aufgegangen ist und
b) der Winkel myTL:elevation größer ist als myTL:RelativerDachwinkel
dann scheint die Sonne in das Fenster.

Das ganze auch noch mal in hübsch im Anhang.

Ich hoffe es hilft dem einen oder anderen. Garantie gebe ich keine (hab's selber erst gestern ausgeknobelt).

Viel Spaß mit dem Schnipsel,
Martin

edit: Hinweis auf Version 0.2

JF Mennedy

Hi Martin,

hast Du ein Velux? Da gibt es ein Modul KLF200 https://wiki.fhem.de/wiki/Velux_KLF200 Brauchst Du allerdings auch das Gateway für, kostet aber nicht die Welt... Die Steuerung der Velux funktioniert super damit. Sowohl Fenster als auch Rolladen... Werde mal Deine Erweiterung ins TL Modul einbauen und schauen, wie es sich macht ;-)

Gruss Jan

mähschaf

Hi Jan,

Das freut mich, bin schon gespannt, ob es auch bei anderen funktioniert  :D

Im Moment plane ich noch, morgen wird dann voraussichtlich bestellt bzw. beauftragt. In der Tat zusammen mit KLF 200, obwohl man das mit der WLAN/AP/RJ45-Geschichte sicherlich auch nicht ganz so stark auf Handwerker-Freundlichkeit hätte ausrichten müssen, aber was soll's...  ;)

Ich freue mich jedenfalls schon sehr auf das Fenster... Danke für die Aussage, dass das KLF-Modul gut funktioniert, denn das macht mir meine Entscheidungen in jedem Fall leichter...

Schönen Abend und bleibt gesund,
Martin

JF Mennedy

Ich habe das KLF noch an einer schaltbaren Steckdose, da es manchmal die Verbindung verliert. Dann schalte ich kurz über ein DOIF ab und wieder an..

defmod di_KLF200_restart DOIF (\
([Velux] eq "disconnected")  \
)\
(\
set bz_KLF200 off;;\
sleep 5;;\
set bz_KLF200 on;;\
)


Eine Frage noch zu der DachKorrekturNord. Mein Velux ist ca 190° (also fast genau südlich). Gebe ich die Korrektur dann mit 190 an?

Gruss Jan

mähschaf

Danke für den Schnipsel, habe ich mir gleich mal abgespeichert!

Ja genau, genau S müsste eigentlich 180° sein.

Hab's bisher nur mit meine eigene Ausrichtung ausprobiert, aber in der Theorie sollte es - glaube ich - mit jeder Ausrichtung funktionieren.

JF Mennedy

ok super :-) werd ich mir dann morgen mal anschauen ;-) Meine Frau wird sich freuen, wenn ihre Schminke nicht mehr in der Sonne steht  ;D ;D ;D

JF Mennedy

Hier noch das DOIF um den Rooladen dann runterzufahren:

defmod di_KLF200_Rolladen DOIF (\
(\
TL:elevation > TL:RelativerDachwinkel\
)\
(\
set Velux_0 pct 75;;\
) DOELSE(\
set Velux_0 pct 0;;\
)\
)

mähschaf

#7
Ja super, das läuft hier ja wie am Schnürchen.

Ich vermute allerdings (ohne Garantie), dass folgendes noch sicherer wäre:

defmod di_KLF200_Rolladen DOIF (\
(\
TL:elevation > TL:RelativerDachwinkel and TL:elevation > 0\
)\
(\
set Velux_0 pct 75;;\
) DOELSE(\
set Velux_0 pct 0;;\
)\
)


Ansonsten kann es sein, dass fhem denkt, die Sonne scheint ins Fenster, obwohl die Erde "dazwischen" steht. Klingt komisch, ist aber - glaube ich - so... ::)

Ich hoffe, so oder so ähnlich verknüpft man DOIF-Bedingungen...

JF Mennedy


JF Mennedy

#9
Hallo und guten Morgen :-)

Das läuft ganz gut... Hab noch ein wenig die Nordkorrektur und Dachneigung angepasst. Zur Ausrichtung des Gebäudes hab ich folgende Seite benutzt https://www.sunearthtools.com/dp/tools/pos_sun.php?lang=de

Einfach Dein Gebäude als Messpunkt eintragen, Geodreieck drüber und an der blauen Linie den Azimut ablesen.

Die Dachneigung musste ich "einnorden".. Ich habe ein Satteldach mit ca 40° Neigung und das Fenster auf der Südseite. Entsprechend ist die Neigung im Attribut 130°.

Der relative Dachwinkel läuft jetzt noch knapp der Elevation hinterher.. Bin mal gespannt, wann die Rollade runterfährt...

Das DOIF sieht so aus:
(([TL:elevation] < [TL:RelativerDachwinkel]) && ([TL:elevation] > 0)) 
(set Velux_0 pct 75) DOELSE
(set Velux_0 pct 0)


Eventuell noch Twighligt mit einbauen, falls es mal schattiger ist, dann soll das Fenster ja aufbleiben, oder ich nehme den Helligkeitssensor der Wetterstation...

Gruss Jan




mähschaf

Guten Morgen,

Das freut mich sehr!

ZitatDie Dachneigung musste ich "einnorden".. Ich habe ein Satteldach mit ca 40° Neigung und das Fenster auf der Südseite. Entsprechend ist die Neigung im Attribut 140°.
Das war mir so noch gar nicht klar, macht aber natürlich mehr als nur Sinn. Respekt, Du hast offensichtlich ein gutes dreidimensionales Vorstellungsvermögen.
Machst Du eigentlich auch einen SVG-Plot? Würde den nach einem vollen Tag gerne mal sehen... :-)

btw: Benutzt Du das Velux-Fenster über den KLF 200 als Regensensor? Funktioniert das zuverlässig?

Viele Grüße,
Martin

JF Mennedy

Ich nutze grafana statt svg plots.. Müsste ich mal die Daten aufzeichnen lassen und dann in grafana anlegen... Den regensensor vom velux nutze ich nicht. Habe eine Wetterstation von eltako, die da recht zuverlässig funktioniert...

DonJuan

Ich habe zwar kein Dachfenster, lebe aber sogesehen auch auf der Sonnenseite des Lebens. Und damit ich nicht in der Hölle schmorre, habe ich mir folgendes gebastelt. (Mit Hilfe aus dem Forum).

doif ([{sunrise("CIVIL",0,"04:00","09:00")}-{sunset("CIVIL",-900,"16:00","23:00")}]   # normale Auf/Zu Steuerung der Rollos
and ([twilight:elevation] < 20 # Sonne über Horizont (20°)
or [twilight:azimuth] < 80 # Sonnenstand (80°)
or [twilight:azimuth] > 210 # Sonnenstand (210°)
or [HM_AT_Balkon:1.ACTUAL_TEMPERATURE] < 21))
(Set Rollo_1 open)
(Set Rollo_2 open)
(Set Rollo_3 open)
(Set Rollo_4 open)
# Die Rollos gehen auf, wenn die Sonne min. 20° am Himmel steht, aber nicht zwischen 80° und 210° und die Temperatur unter 21° Celsius ist.

DOELSE
(Set Rollo_1 close)
(Set Rollo_2 close)
(Set Rollo_3 close)
(Set Rollo_4 close)
# sonst gehen sie halt zu

Die "genaue" Position kannst du auf  https://www.sonnenverlauf.de/ ermitteln.

Gruss Dennis

Frank_Huber

#13
ein Vorschlag für das UserReading um unabhängig vom Gerätenamen zu sein:
RelativerDachwinkel { sprintf("%.2f", atan(tan(AttrVal($NAME,"Dachneigung","0") * pi() / 180) * sin((ReadingsNum($NAME,"azimuth","0") - 90 - AttrVal($NAME,"DachKorrekturNord","0")) * pi() / 180)) / pi() * 180) }

Und noch eine Zweite Seite zum ermitteln des Winkels: https://www.sonnenverlauf.de/
Hier kann man durch ändern der Uhrzeit den exakten Winkel ermitteln an dem die Sonne senkrecht aufs Dach steht.

BTW: Danke für diese Idee und Ausführung!

satprofi

Zitat von: JF Mennedy am 13 April 2021, 17:48:19
Hi Martin,

hast Du ein Velux? Da gibt es ein Modul KLF200 https://wiki.fhem.de/wiki/Velux_KLF200 Brauchst Du allerdings auch das Gateway für, kostet aber nicht die Welt... Die Steuerung der Velux funktioniert super damit. Sowohl Fenster als auch Rolladen... Werde mal Deine Erweiterung ins TL Modul einbauen und schauen, wie es sich macht ;-)

Gruss Jan
wie steuert das KLF200 nach Sonnenstand? Max. auf/zu .
gruss
-----------------------------------------------------------------------
beelink miniPC - Fhem 6.x CUL 868, FS20, NetIO230 CUL 433
HMLAN, HM-CC-RT-DN,Homematic Actoren,LD382A,Telegram

satprofi

Zitat von: mähschaf am 13 April 2021, 13:44:02
Hallo,



Kurze Erläuterung:
Es gibt ein User-Attribut für die Dachneigung und eines für die Korrektur des Winkels nach Norden in °. Bei mir (Ausrichtung beim Gucken aus dem Fenster nach NNW) sind das -23°.



Viel Spaß mit dem Schnipsel,
Martin

Hallo.
Gehe ich richtig in der Annahme das NNO 23° sind, und S dann 180° ? SO wären somit -135° ?
Verstehe die Vorzeichen gerade nicht.
gruss
-----------------------------------------------------------------------
beelink miniPC - Fhem 6.x CUL 868, FS20, NetIO230 CUL 433
HMLAN, HM-CC-RT-DN,Homematic Actoren,LD382A,Telegram

mähschaf

#16
Hallo,

entschuldigung, ich habe die Frage gar nicht bemerkt.

N = 0°
NNO = 22,5°
NO = 45°
ONO = 67,5°
O = 90°
OSO = 112,5°
SO = 135° ... usw ...

SO wären also 135°. Funktionieren würde auch -225° - ist dasselbe. FHEM rechnet eh mit pi, ich glaube das heißt Bogenmaß oder so (rat, spekulier  ;)) ....

Das Problem mit dem hängenden KLF200 trat bei mir übrigens nach ca. 3 Monaten erstmalig auf. Ich habe es gelöst, indem ich eine AVM-DECT-Steckdose vor die KLF200 gesetzt habe:

Internals:
   DEF        ([Velux] eq "disconnected")
   ( set  FBDECT_KLF200 off) ( set FBDECT_KLF200 on ) ( set telegram message @#FHEM KLF200 disconnected -> restart )
DOELSE
   ( )
   FUUID      61bc4ceb-f33f-2b6d-8957-7e752c7dd73a1b20
   FVERSION   98_DOIF.pm:0.257560/2022-02-28
   MODEL      FHEM
   NAME       df_KLF200_disconnected
   NOTIFYDEV  global,Velux
   NR         494
   NTFY_ORDER 50-df_KLF200_disconnected
   STATE      cmd_2
   TYPE       DOIF
   VERSION    25756 2022-02-28 08:27:14
   Helper:
     DBLOG:
       state:
         logdb:
           TIME       1646485043.41352
           VALUE      cmd_2
   READINGS:
     2022-03-05 13:57:23   Device          Velux
     2022-03-05 13:57:23   cmd             2
     2022-03-05 13:57:23   cmd_event       Velux
     2022-03-05 13:57:23   cmd_nr          2
     2022-03-05 13:57:23   e_Velux_STATE   Logged in
     2021-12-19 19:17:50   mode            enabled
     2022-03-05 13:57:23   state           cmd_2
     2022-03-04 09:39:38   wait_timer      no timer
   Regex:
     accu:
     collect:
     cond:
       Velux:
         0:
           &STATE     ^Velux$
   attr:
     cmdState:
     repeatcmd:
       1800
     repeatsame:
       96
     wait:
       0:
         0
         5
         0
       1:
         0
     waitdel:
   condition:
     0          ::InternalDoIf($hash,'Velux','STATE') eq "disconnected"
   do:
     0:
       0           set  FBDECT_KLF200 off
       1           set FBDECT_KLF200 on
       2           set telegram message @#FHEM KLF200 disconnected -> restart
     1:
       0           
   helper:
     NOTIFYDEV  global,Velux
     event      queueSize: 0
     globalinit 1
     last_timer 0
     sleepdevice Velux
     sleepsubtimer 0
     sleeptimer -1
     timerdev   Velux
     timerevent queueSize: 0
     triggerDev Velux
     DOIF_eventa:
       cmd_nr: 2
       cmd: 2
       cmd_event: Velux
       cmd_2
     DOIF_eventas:
       cmd_nr: 2
       cmd: 2
       cmd_event: Velux
       state: cmd_2
     timerevents:
       queueSize: 0
     timereventsState:
       queueSize: 0
     triggerEvents:
       queueSize: 0
     triggerEventsState:
       queueSize: 0
   internals:
     all         Velux:STATE
   perlblock:
   readings:
   trigger:
   uiState:
   uiTable:
Attributes:
   DbLogExclude .*
   DbLogInclude state
   do         always
   repeatcmd  1800
   repeatsame 96
   room       InputOutput->Velux,Obergeschoss->Arbeitszimmer
   wait       0,5,0:0


Jetzt startet die KLF200 mit jedem Neustart von FHEM ebenfalls neu, das finde ich aber ehrlich gesagt ganz gut.....
Der Vorteil des DOIF aus meiner Sicht: Auch bei längeren Ausfällen (z. B. Sicherung raus oder ähnlich) gibt FHEM nicht auf und startet die KLF200 regelmäßig noch mal neu.

edit: habe jetzt Benachrichtigungen für diesen Fred aktiviert  :-[

satprofi

gruss
-----------------------------------------------------------------------
beelink miniPC - Fhem 6.x CUL 868, FS20, NetIO230 CUL 433
HMLAN, HM-CC-RT-DN,Homematic Actoren,LD382A,Telegram

maci

Sorry, aber ich komme mit dem überhaupt nicht klar.

Ich habe ein Dachfenster mit Ausrichtung von 127 Grad (OSO) und die Dachneigung ist 39 Grad.
Das Modul errechnet bei mir eine relativen Dachwinkel von -38,97 Grad um 11:17 Uhr.

Also wäre der Sonnenschutz jetzt offen. Tatsächlich scheint aber die Sonne intensiv rein.

Was heisst relativer Dachwinkel? Ich finde keine Erklärung dazu.

Fhem auf Dell Thinclient, Fhem auf Raspebrry Pi4,
UniPi Vers. 1.1 mit Raspberry Pi3, 1wire USB Adapter mit OWX
Netatmo Wetterstation + Regenmesser + Netatmo Thermostat
Homematic mit HMLan

mähschaf

Guten Abend maci,

der Codeschnipsel wurde für ein Dach gen Norden geschrieben, für ein Süddach muss der Dachwinkel "eingenordet" werden, siehe Antwort # 9.

ZitatDie Dachneigung musste ich "einnorden".. Ich habe ein Satteldach mit ca 40° Neigung und das Fenster auf der Südseite. Entsprechend ist die Neigung im Attribut 130°.

Geht es so besser aus?

LG,
Martin

maci

Guten Abend,

Wie kann eine Dachneigung eingenordet werden?
Ich kann die Ausrichtung des Fensters einnorden, aber eine Dachneigung kann ich mir schlecht vorstellen.

Mein Fenster ist eher Ostseitig. lt. einer Webseite für Solaranlagen -50 Grad wenn 0 Grad Süden ist.
Mit dieser Webseite habe ich das ermittelt. https://www.rechnerphotovoltaik.de/rechner/dachausrichtung
Wenn ich dann das auf Norden umlege komme ich auf 130 Grad
Wobei ich nicht weiß wo + und - ist. Wenn ich es so mache wie auf der Webseite, wären das -130 Grad.

ich im Netz gesucht, nach einnorden, aber da finde ich nichts, alles ist auf Süden ausgelegt, auch die Sonnenstandsrechner.
Fhem auf Dell Thinclient, Fhem auf Raspebrry Pi4,
UniPi Vers. 1.1 mit Raspberry Pi3, 1wire USB Adapter mit OWX
Netatmo Wetterstation + Regenmesser + Netatmo Thermostat
Homematic mit HMLan

satprofi

Zitat von: mähschaf am 13 April 2021, 18:44:48
Ja super, das läuft hier ja wie am Schnürchen.

Ich vermute allerdings (ohne Garantie), dass folgendes noch sicherer wäre:

defmod di_KLF200_Rolladen DOIF (\
(\
TL:elevation > TL:RelativerDachwinkel and TL:elevation > 0\
)\
(\
set Velux_0 pct 75;;\
) DOELSE(\
set Velux_0 pct 0;;\
)\
)


Ansonsten kann es sein, dass fhem denkt, die Sonne scheint ins Fenster, obwohl die Erde "dazwischen" steht. Klingt komisch, ist aber - glaube ich - so... ::)

Ich hoffe, so oder so ähnlich verknüpft man DOIF-Bedingungen...

Hallo.
also das funktioniert bei mir leider nicht. Fenster nach Süden,  Dachneigung 40°, aber Doelse schlägt um 5:40.zu.
DachkorrekturNord hab ich auf -180
gruss
-----------------------------------------------------------------------
beelink miniPC - Fhem 6.x CUL 868, FS20, NetIO230 CUL 433
HMLAN, HM-CC-RT-DN,Homematic Actoren,LD382A,Telegram

mähschaf

N'abend!

Wenn ich nach dem Urlaub etwas Zeit habe, werde ich unterschiedliche Ausrichtungen (n/o/s/w) mal ausprobieren.

Damian

ZitatTL:elevation > TL:RelativerDachwinkel and TL:elevation > 0\


Was soll das für eine Syntax sein - von DOIF ist sie nicht.
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

mähschaf

Stimmt, das ist natürlich Kappes. Sorry. Fundstelle war mit Hinweis versehen, dass ich zum damaligen Zeitpunkt nicht wusste, wie man DOIF-Bedingungen logisch verknüpft.

Ich verwende aktuell:

(([TL:elevation] - [TL:RelativerDachwinkel] > 5) && ([TL:elevation] > 0)

Da ich bei meinen Fenstern 5° als Grenze erkannt habe, die der Fensterrahmen "auffängt".

satprofi

hallo.
eigentlich fehlt ja die bewölkung, die werde ich von peoplanta noch einarbeiten. weil ohne sinne braucht kein rollo fahren
gruss
-----------------------------------------------------------------------
beelink miniPC - Fhem 6.x CUL 868, FS20, NetIO230 CUL 433
HMLAN, HM-CC-RT-DN,Homematic Actoren,LD382A,Telegram

satprofi

#26
Zitat von: mähschaf am 24 Juli 2022, 23:03:47


Ich verwende aktuell:

(([TL:elevation] - [TL:RelativerDachwinkel] > 5) && ([TL:elevation] > 0)



Hallo. Versteh die Formel nicht.
(Elevation - Dachwinkel)  Summe grösser 5 sollte Rollo runterfahren, oder? Was ist aber  der Rest ? Elevation grösser 0 als Bedingung?

Meine Rolladen fahren nämlich nicht mehr rauf, obwohl Dachwinkel im minus und Elevation auf 27 steht, also um 17:30 immer noch grösser als 5

Update,  19:05 relativer dachwinkel 11,42., elevation 12, jetzt gehen die Rollläden auf. Entweder stimmt meine dachkorrektur (180) nicht,  oder die Formel ist mir zu hoch.
gruss
-----------------------------------------------------------------------
beelink miniPC - Fhem 6.x CUL 868, FS20, NetIO230 CUL 433
HMLAN, HM-CC-RT-DN,Homematic Actoren,LD382A,Telegram

Prof. Dr. Peter Henning

1. Das Modul Astro liefert die genaue Sonnenposition
2. Mit etwas Trigonometrie lässt sich der Einfallswinkel auf jede Fläche berechnen

Bei mir wird aus der Leistung der PV-Anlage und den Winkeln die Einstrahlung berechnet und die Rollläden in allen betroffenen Räumen angepasst.

LG

pah

ch.eick

#28
Zitat von: Prof. Dr. Peter Henning am 31 Juli 2022, 17:02:22
1. Das Modul Astro liefert die genaue Sonnenposition
2. Mit etwas Trigonometrie lässt sich der Einfallswinkel auf jede Fläche berechnen

Bei mir wird aus der Leistung der PV-Anlage und den Winkeln die Einstrahlung berechnet und die Rollläden in allen betroffenen Räumen angepasst.
Dazu gibt es auch bereits ein Funktion für die 99_myutils von Kölnsolar, ich kann sie nur gerade nicht finden :-)

EDIT: Über PV-Anlage Einstrahlung auf Gebäudeteile ermitteln
RPI4; Docker; CUNX; Eltako FSB61NP; SamsungTV H-Serie; Sonos; Vallox; Luxtronik; 3x FB7490; Stromzähler mit DvLIR; wunderground; Plenticore 10 mit BYD; EM410; SMAEM; Modbus TCP
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/ch.eick

mähschaf

#29
Hallo und guten Morgen,

soooo, zurück aus Frankreich *sniff*

Wie versprochen habe ich mich mal noch etwas intensiver mit der Problematik beschäftigt. Die "Version 0.1" war offensichtlich doch nicht so perfekt wie gehofft, weshalb ich die Version 0.2 in Angriff genommen habe.

Dabei habe ich mich erinnert, dass man den Eintrittswinkel von Vektoren und Flächen mathematisch berechnen kann (das wurde in diesem Thread ja auch schon diskutiert). In der Schule hatte ich das mal vor langer Zeit, aber ich bin leider viel zu doof, das mal eben so herzuleiten. Zum Glück gibt es das Internet und hier (https://www.matheboard.de/archive/596587/thread.html) bin ich fündig geworden (Danke an dieser Stelle).

Man kann sich das wohl so vorstellen, dass von einem Punkt auf der Oberfläche des Fensters aus man einen Vektor zur Sonne und einen Vektor im rechten Winkel zur Fläche hat. Entsprechend scheint die Sonne in das Fenster, sobald dieser Winkel < 90° ist (ich habe bei mir 85° genommen, weil Fensterrahmen etc. den Lichteinfall schmälern). Bei > 90° scheint sie eben nicht hinein.

Die Berechnung (wie gesagt, nur abgeschrieben!):

ε = arccos[cos(β) cos(α) sin(γ) cos(δ)+cos(β) sin(α) sin(γ) sin(δ)+sin(β) cos(γ)]

α = azimuth
β = elevation
γ = Dachneigung
δ = KorrekturNord

Das in fhem übersetzt als Erweiterung des Twilight-Modules wäre:

Attributes:
   DachKorrekturNord -23
   Dachneigung 50
   userReadings Einfallswinkel { sprintf("%.2f", acos(cos(ReadingsNum($NAME,"elevation","0") * pi() / 180) * cos(ReadingsNum($NAME,"azimuth","0") * pi() / 180) * sin(AttrVal($NAME,"Dachneigung","0") * pi() / 180) * cos(AttrVal($NAME,"DachKorrekturNord","0") * pi() / 180) + cos(ReadingsNum($NAME,"elevation","0") * pi() / 180) * sin(ReadingsNum($NAME,"azimuth","0") * pi() / 180) * sin(AttrVal($NAME,"Dachneigung","0") * pi() / 180) * sin(AttrVal($NAME,"DachKorrekturNord","0") * pi() / 180) + sin(ReadingsNum($NAME,"elevation","0") * pi() / 180) * cos(AttrVal($NAME,"Dachneigung","0") * pi() / 180)) / pi() * 180 )}
   userattr   DachKorrekturNord Dachneigung


Dabei gilt für die DachKorrekturNord bei entsprechender Ausrichtung des Dachflächenfensters:

N = 0°
NNO = 22,5°
NO = 45°
ONO = 67,5°
O = 90°
OSO = 112,5°
SO = 135° ... usw ...

SO wären also 135°. Funktionieren würde auch -225° - ist dasselbe.

Einnorden etc. ist nicht mehr nötig (das ist aus meiner Sicht der Vorteil der Version 0.2)

Wichtig ist noch, dass die Sonne tatsächlich aufgegangen sein muss (elevation > 0).

Damit kann jeder sich seine Schaltungen bauen, als Beispiel ein DOIF:

DOIF (([myTL:Einfallswinkel] < 85) && ([myTL:elevation] > 0) (set Velux_3 pct 30 SILENT) DOELSEIF ((([myTL:Einfallswinkel] > 85) || ([myTL:elevation] < 0)) (set Velux_3 pct 100 SILENT)

Es ist auch möglich, die Helligkeit/Intensität etc. individuell in die eigenen DOIFs etc. einzubauen. Da muss aber jeder selber gucken, da jeder eine andere Voraussetzung hat. Auf die Anbindung des Velux-KLFs (weiter oben zu finden) möchte ich nicht weiter eingehen, da auch dies ein eigenes Thema darstellt.

Ich freue mich auf Tests und Rückmeldungen zur Version 0.2!

Eienen schönen Tag, schwitzt nicht zu viel und bleibt gesund!  8)
Martin

edit: logischer Fehler im DOIF
edit2: Umstellung in Version 0.2 von RelativerDachwinkel auf Einfallswinkel, siehe Post #38

Prof. Dr. Peter Henning

ZitatZum Glück gibt es das Internet
Man hätte auch mich fragen können... ::)

Eine interessante Frage ist in diesem Zusammenhang die Intensität der Lichteinstrahlung. Wenn im tiefen Winter eine trübe Wintersonne zum Fenster hineinschaut, wird niemand den Rolladen herunterfahren.

Die Globalstrahlung messe ich mit einem geeichten Sensor auf dem Dach. Dividiere ich dies durch den Kosinus des Einfallswinkels, ergibt sich ein gutes Maß für die direkte Sonneneinstrahlung. Je nach Richtung des Rollladens kann ich nun mit derselben Methode ausrechnen, wie der Einfall auf die Fensterfläche ist. Die Beschattungsfunktion wird pro Rollladen aktiviert, wenn für diesen ein Maximalwert überschritten oder ein Minimalwert unterschritten wird (Hysterese)

Jeder einzelne Rollladen (zumindest alle auf einer Seite des Hauses im gleichen Stockwerk) kennt nun als Attribut den Namen einer Perl-Funktion, die - empirisch auf Basis des Sonnenstandes ermittelt - den notwendigen Fahrweg für den Rollladen zurückgibt.

LG

pah

mähschaf

ZitatMan hätte auch mich fragen können... ::)

Ja gut, danke für das Angebot! Ich hatte aber sowieso schon ein schlechtes Gewissen, da in den Codeschnipseln eigentlich nur funktionierender Code stehen sollte. Für Fragen gibt es andere Ecken und dann hätte ich da noch einen neuen Fred starten müssen usw....  ::)

Aber da Du Dich mit der Mathematik auskennst: Stimmen die Formel und meine Adaption denn Deiner Meinung nach?

ZitatDie Globalstrahlung messe ich mit einem geeichten Sensor auf dem Dach. Dividiere ich dies durch den Kosinus des Einfallswinkels, ergibt sich ein gutes Maß für die direkte Sonneneinstrahlung.

Ja, das mache ich in etwa auch so. Da ich den Relativen Dachwinkel aus dem UserAttr benutze, multipliziere ich die gemessene Intensität am eigenen Lichtsensor mit dem Cosinus dieses Winkels. In meinem DOIF benutze ich auch die Average-Funktion, damit ist sichergestellt, dass nicht bei einem kleinen Wolkenloch gleich die Rolläden hin- und herfahren. Da sind viele Quellen und viele individuelle Anforderungen denkbar, z. B. ein eigener Sensor, ein Wetter-Modul, die eigene Photovoltaikanlage usw...

Das würde dann meiner Meinung nach den Rahmen dieses Threads sprengen (funktionierender Code und so, s.o.).

Prof. Dr. Peter Henning

Aber da Du Dich mit der Mathematik auskennst: Stimmen die Formel und meine Adaption denn Deiner Meinung nach?
Auf den ersten Blick sieht das brauchbar aus.

LG

pah

satprofi

Zitat von: mähschaf am 04 August 2022, 09:49:43
Entsprechend scheint die Sonne in das Fenster, sobald dieser Winkel < 90° ist (ich habe bei mir 85° genommen, weil Fensterrahmen etc. den Lichteinfall schmälern). Bei > 90° scheint sie eben nicht hinein.



Hallo.
Danke für Erklärung. Versteh ich das jetzt richtig, <90 Sonne scheint ins Fenster, >90 Sonne steht über Dach und scheint nicht ins Fenster?
gruss
-----------------------------------------------------------------------
beelink miniPC - Fhem 6.x CUL 868, FS20, NetIO230 CUL 433
HMLAN, HM-CC-RT-DN,Homematic Actoren,LD382A,Telegram

mähschaf

Zitat von: satprofi am 05 August 2022, 11:00:50
Hallo.
Danke für Erklärung. Versteh ich das jetzt richtig, <90 Sonne scheint ins Fenster, >90 Sonne steht über Dach und scheint nicht ins Fenster?

Jein.

Du musst Dir Dein Dach als eine bis in die Unendlichkeit verlängerte Fläche vorstellen. Bei Winkel < 90° steht die Sonne "oberhalb", also auf Deiner Seite der Fläche. Bei > 90° ist die Sonne unterhalb dieser Fläche.

Deshalb würde ich bei > 90° nicht sagen, dass die Sonne "über dem Dach" steht, das ist meiner Meinung nach mißverständlich.

Schönes Wochenende!

mähschaf

Zitat von: Prof. Dr. Peter Henning am 05 August 2022, 10:10:02
Aber da Du Dich mit der Mathematik auskennst: Stimmen die Formel und meine Adaption denn Deiner Meinung nach?
Auf den ersten Blick sieht das brauchbar aus.

Danke für's Feedback!

Prof. Dr. Peter Henning

#36
ZitatDeshalb würde ich bei > 90° nicht sagen, dass die Sonne "über dem Dach" steht, das ist meiner Meinung nach mißverständlich.

Ganz im Gegenteil steht bei einem Einfallswinkel > 90° die Sonne unter der Dachebene bzw. Fensterebene, würde PV-Module (oder Fenster) also nur von hinten direkt bestrahlen. Das heißt bei PV nicht: "Null Energie" - ein erheblicher Teil der Sonnenstrahlung erreicht die PV-Module als diffuse Streustrahlung. Ebensowenig heißt das bei Fenstern: "Dunkelheit". Auch da gilt das mit dem Streulicht.

LG

pah




satprofi

Zitat von: Prof. Dr. Peter Henning am 05 August 2022, 17:53:03
Ganz im Gegenteil steht bei einem Einfallswinkel > 90° die Sonne unter der Dachebene, würde PV-Module also nur von hinten direkt bestrahlen. Das heißt nicht: "Null Energie" - ein erheblicher Teil der Sonnenstrahlung erreicht die PV-Module als diffuse Streustrahlung.

LG

pah

versteh nur Bahnhof. ich dachte diese berechnung zielt auf sonnenstand 90° zur fensterfläche,  also direkte
einstrahlung.  wozu die werte dachneigung u.  ausrichtung? wozu sollen die rolladen runterfahren wenn die sonne 45° über dem fenster steht,  was ja meistens mittags im sommer hier in mitteleuropa sache ist.
gäbe es due Erklärung mit bilder?
gruss
-----------------------------------------------------------------------
beelink miniPC - Fhem 6.x CUL 868, FS20, NetIO230 CUL 433
HMLAN, HM-CC-RT-DN,Homematic Actoren,LD382A,Telegram

Prof. Dr. Peter Henning

#38
"Sonne steht über Dach" würde bedeuten senkrecht über dem Fenster. Das gibt es nur am Äquator.

@mähschaf: Folgende Vorschläge noch:

1. Das Ergebnis heißt nicht "Relativer Dachwinkel", sondern Einfallswinkel (sagen wir phi).
2. Man muss gar nicht den Winkel ausrechnen, es reicht der cos(phi). Dieser ist das Skalarprodukt aus dem Normalenvektor des Fensters

N = (cos(delta)sin(gamma),cos(gamma),sin(delta)cos(gamma)

und dem Vektor zur Sonne

S = (cos(alpha)cos(beta),sin(beta),sin(alpha)cos(beta)

Mit anderen Worten; man benötigt die letzte Arcuscosinus-Funktion nicht, es reicht zu schauen, ob cos(phi) größer oder kleiner als Null ist.

LG

pah

Edit: Ein Bild, auf die Schnelle.

mähschaf

#39
Zitat von: Prof. Dr. Peter Henning am 06 August 2022, 16:55:20

@mähschaf: Folgende Vorschläge noch:

1. Das Ergebnis heißt nicht "Relativer Dachwinkel", sondern Einfallswinkel (sagen wir phi).

Danke für den Hinweis, habe die Dokumentation ab Version 0.2 im Post #29 entsprechend angepasst.

Zitat von: Prof. Dr. Peter Henning am 06 August 2022, 16:55:20

@mähschaf: Folgende Vorschläge noch:

2. Man muss gar nicht den Winkel ausrechnen, es reicht der cos(phi). Dieser ist das Skalarprodukt aus dem Normalenvektor des Fensters

Das wäre vorteilhaft für ein boolsches "Sonne scheint rein"/"Sonne scheint nicht rein". Die ursprüngliche Idee war es (und so habe ich es auch gemacht), mit dem Geodreieck zu gucken, bei welchem Einfallswinkel die Sonne in mein Fenster heinein scheint. Die seitlichen Anbauten (Rolladenführung) und die Stärke des Rahmens (ganz schön wuchtig) nimmt einiges an Licht weg.

Auch in der Überschrift geht es um den Winkel, nicht um den Status. Deshalb würde ich das vorerst mal so lassen, aber weiter nachdenken. Wer es benötigt, kann ja aus dem Winkel sehr einfach den Status errechnen.