Hallo zusammen,
wenn ich mich richtig erinnere, habe ich irgendwo gelesen, dass isday() in der Zeit true zurück liefert, wenn man draußen noch ohne Licht lesen könnte (Voraussetzung: Koordinaten richtig gesetzt). Heute kam ich um kurz nach 18 Uhr nach Hause und ein entsprechendes notify mit !(isday())-Bedingung hat nicht reagiert, obwohl es draußen schon sehr dunkel war.
Wann wechselt isday() den Status?
Bestimmt bei einer der sunset/sunrise-Varianten (real, civil, nautic, ...), oder? Aber welche? Wie kann ich feststellen, wann dies heute bei mir der Fall war oder noch sein wird?
isday richtet sich nach der "bürgerlichen Dämmerung " (Tiefenwinkel 6 Grad) soweit ich weiss, ich meine also, dass du recht hast.
Allerdings rein nach Koordinaten berechnet (die du wohl auch als globale Variablen eingeben musst, sonst wird Frankfurt genommen), und dies unter Annahme von "Flachland".
(oder vielmehr: Horizontentferung wie auf dem Meer)
Die tatsächlichen örtlichen Horizonte und Wetterbedingungen werden nicht berücksichtigt und können zu erheblichen Abweichungen führen.
Wenn der Zeitpunkt richtig wichtig ist, muss man wohl isday durch sunset + offset nutzen oder gar durch das alternative Dämmerungsmodul (das ich allerdings als "overdone" empfinde).
Klar, meine eigenen Koordinaten sind als attr global latitude und longitude definiert. So viele Berge habe ich hier auch nicht um mich herum, eher 2-3 "Hügel" mit 80m über N.N. ;-) Rheinland halt :-)
isday() ist grundsätzlich super praktisch und liefert mir direkt ein true/false zurück. Wenn ich es richtig sehe, müsste ich mir bei sunset() noch selbst eine Funktion o.ä. bauen, in der ich die aktuelle Uhrzeit mit der gelieferten Uhrzeit vergleiche. Hier fehlt sunset() leider ein Offset.
Welches "alternative Dämmerungsmodul" meinst du? Ich war vor ca. 2 Wochen auf der Suche nach einer Quelle im Internet, welche mir die aktuellen Lux-Werte meines Standortes liefert. Die üblichen Wetterdienste liefern ja fast alles, nur leider keine Helligkeitswerte. Diese würde ich z.B. auch gerne nutzen, um zu bestimmen, wann mein Badezimmer-Rollo nach unten fahren soll.
Hallo,
Twilight wäre evtl. sowas.
Ich glaube im Wiki hat es ein oder zwei Beispiele.
Grüße
Zitat von: kossmann schrieb am Di, 05 Februar 2013 20:03um zu bestimmen, wann mein Badezimmer-Rollo nach unten fahren soll.
Sieht bei mir so aus:
define RolloRunter at +*{sunset_rel()} set sz_rollo on
Laut
http://fhem.de/commandref.html#SUNRISE_EL kannst Du dort auch einen Horizon-Wert angeben, um entsprechend etwas früher oder später zu schalten.
Gruß, Uli
ZitatTwilight
Das meinte ich. Musst aber genauso wie mit sunset entweder sowas wie UliM machen oder dir selber eine DUMMY wie "MeinTag" befüllen.
Das bekomme ich so auch verarztet (wobei ich mich frage, warum "on" bei dir "unten" ist)...
define Job_Badezimmer_Rollo_runter at *{sunset(-3600,"16:00","21:00")} set Badezimmer_Rollo unten
Aber gerade im Winter ist es weit vor sunset(-3600) so dunkel, dass man innen das Licht anmacht - und da ist es manchmal schon sinnvoll, wenn das Rollo unten ist. Ich muss/darf mir oft genug die Konturen der 80+ jährigen Nachbarn angucken... und genau dafür/dagegen ist Rollos im Bad ja da (abgesehen von dem Wärmeverlust in der Heizphase).
Das ganze kann man natürlich auch in einer (Wohlfühl-/Stimmungs-) Beleuchtung integrieren - diese sollte auf die Helligkeit außen reagieren. Im Hochsommer können nachmittags auch mal gaaaaanz schwarze Wolken (z.B. bei Gewitter) aufziehen. Da wäre ein Helligkeitswert schon nicht schlecht. Ich befürchte allerdings, dass man hier nicht um die entsprechende Wetterstation herum kommt.
... aber wir weichen etwas vom Thema ab ;-)
Wir weichen vielleicht ab, aber in der Tat habe ich mich schon beim "Twilight"-Modul gefragt, ob nicht ein FS20 Dämmerungssensor langsam unaufwändiger wäre.
Der Funk-Dämmerungssender FS20 SD kostet so um die 45 Euro und wird die gewünschte Helligkeit letztlich immer besser feststellen, als alles Koordinaten-Rumgerechne, Wetterberichtabgefrage, Offesteinrichten etc.
was ist denn das problem twilight nicht zu verwenden ?
schau mal hier http://forum.fhem.de/index.php?t=msg&goto=60924&rid=430#msg_60924 (//forum.fhem.de/index.php?t=msg&goto=60924&rid=430#msg_60924). da ist ein vorschlag wie es sehr einfach ist.
gruss
andre
Twilight nicht zu verwenden ist gar kein Problem ;-)
(Okay, wenn die sozial kompetenteren Teilnehmer dieses Forums diesen kleinen Scherz mitkriegen, krieg ich wieder 4 Minuspunkte in der Reputation. LOL)
Es gibt natürlich kein echtes Problem, Twiglight zu verwenden, das wollte ich auch nicht sagen. Aber der Code eine eigene "IstHell"-Funktion per Dummy und einem Funk-Dämmerungssender FS20 SD zu bauen, ist EINE Zeile lang (na gut, abgesehen von der Definition des Sensors). Und die Präzision und Reaktionsgeschwindigkeit auf das örtliche Helligkeitsbild ist genauer und schneller.
Twilight hingegen sind schon ein paar Zeilen und ein paar Parameter und fragt Wetterdienste ab, deren Aussage stimmen kann oder auch nicht so richtig und man muss ein bisschen mit den Parameter rumspielen.
Und am Ende kommt dann das oben erwähnte Sommergewitter und Twilight wird trotzdem schlechter Ergebnisse liefern als der Dämmerungsensor.
Ich sage aber NICHT, das Twilight nicht gut ist oder der Dämmerungsensor die beste Lösung oder so. Immerhin sind 45 Euro ja auch Geld.
Ich selbst benutze sogar isday und sunset mit offset. Ich meine nur: Wenn einem isday zu ungenau ist, kann es vielleicht sinnvoll sein, gleich zu einer Lösung überzugehen, die den lokalen Helligkeitswert tatsächlich misst.
Das muss schon in der Theorie genauer sein, als den Wert mehr (twilight) oder weniger (isday, sunset) elaboriert zu erraten.
das eine ist halt eine reine software lösung. im anderen fall ist hardware nötig die unter umständen erst gebastelt werden muss.
die diskussionen einen homematic fähigen helligkeitssensor zusammenzubauen füllen z.b. diverse seiten wenn man danach sucht. und dann geht es immer noch nicht ohne software. selbst mit dem sensor soll ja bei gewitter am tag der rolladen nicht runter und am nachmittag nach dem gewitter unter umständen nicht wieder hoch obwohl es wieder hell genug wäre. von daher ist es deutlich mehr als eine zeile. jedenfalls wenn man etwas mehr als wenn dunkel dann sofort runter und wenn hell dann sofort rauf haben möchte.
der hauptunterschied ist in der tat der externe wetterdienst der abgefragt wird. meine bisherigen erfahrungen mit twilight sind gut. ohne das das etwas für die zukunft sagt. ich wuerde es jedenfalls wieder damit machen. es ist guenstiger. es ist kein basteln nötig. aber als informatiker liegt mir die software vielleicht eher :)
gruss
andre
Hi,
nur mal so als Hinweis:
Im ELV-Journal 1/2013 ist in der Vorschau zur Ausgabe 2/2013 ein Artikel über einen "HomeMatic-Funk-Außenbewegungsmelder, ARR-Bausatz" angekündigt.
Zitat: "Da die Helligkeitswerte auch zyklisch gesendet werden, kann man ... auch Verbraucher im Haus abhängig von der Außenhelligkeit steuern."
2/2013 erscheint übrigens am 27.3.2013... also noch etwas Geduld. Dann wird man wohl erfahren, was unter "zyklisch" zu verstehen ist.
Und nein, ich arbeite nicht für ELV ;) , aber das Teil steht schon auf meiner "Nice-to-have-Liste".
Grüßle
Thomas
Hi!
Also ich habe es bei mir mit Twilight und einer TimeOffset-Funktion (diese stammt aus einem Post st hier im Forum).
Damit ist in diesem Beispiel das Schalten der Rollläden um 20min verschoben, da die berechnete Zeit von Twilight etwas zu früh war, aber spätestens um 9:00 gehen die Rolläden auf. Abends ist es syncron genauso gelöst.
Funktioniert bisher prima!!!
in Fhem.cfg:
define myTL Twilight 50.596 12.672 1 12831828
define FileLog_Twilight FileLog /usr/local/FHEM/var/log/Twilight-%Y.log myTL:light.*
attr FileLog_Twilight logtype Twilight:Plot,text
attr FileLog_Twilight room Notifys
define Rolll_Frueh at *{TimeOffset(ReadingsVal("myTL","sr","09:00:00"),+20)} {\
fhem("set Rollladen_EG Auf;;\
set Rollladen_Flur Auf;;\
sleep 10;;set Dimmer_Wozi off;;")}
attr Rolll_Frueh room Notifys
define Rolll_Daemm at *{TimeOffset(ReadingsVal("myTL","ss","17:30:00"),+40)} {\
fhem("set Rollladen_EG 1;;\
set Rollladen_Flur 5;;\
sleep 15;;set Dimmer_Wozi 50;;")}
attr Rolll_Daemm room Notifys
in myUtils.pm:
sub TimeOffset($;$)
{
my $PtimeOrg = shift;
my $Poffset = shift;
$PtimeOrg = "" unless(defined($PtimeOrg));
$Poffset = 0 unless(defined($Poffset));
my ($sec,$min,$hour,$mday,$month,$year,$wday,$yday,$isdst) = localtime;
if ($PtimeOrg !~ /[0-2][0-9]:[0-5][0-9]/ or substr($PtimeOrg,0,2) >= 24) {$PtimeOrg = $hour.":".$min;}
my $TimeP = mktime(0,substr($PtimeOrg,3,2),substr($PtimeOrg,0,2),$mday,$month,$year,$wday,$yday,$isdst);
my $TimePM = $TimeP + $Poffset * 60;
my ($Psec,$Pmin,$Phour,$Pmday,$Pmonth,$Pyear,$Pwday,$Pyday,$Pisdst) = localtime($TimePM);
my $ReturnText = sprintf("%02d:%02d:%02d", $Phour, $Pmin, $Psec);
}
MfG, MisterEltako
der HM-SEC-MDIR macht das auch. und der HM-SEN-MDIR glaube ich auch. nur steht z.b. im handbuch er sollte nicht direkt in der sonne stehen weil es sonst zu fehlauslösungen kommt. und bei beiden ist laut anderer threads das ansprechverhalten eh nicht so besonders. deshalb gibt es ja diese diskussionen mit umbau von thermometer auf hellligkeitssensor.
gruss
andre