59_Twilight.pm - Funktioniert seit dem 3.1.19 nicht mehr - Yahoo API Umstellung

Begonnen von JoWiemann, 04 Januar 2019, 09:25:53

Vorheriges Thema - Nächstes Thema

Frank_Huber

Zitat von: Christoph Morrison am 08 März 2019, 10:54:24
twilight() ist in diesem Falle letztlich nur ein Wrapper um sunrise() oder sunset() von SUNRISE_EL, allerdings hält Twilight die Werte als Reading vor, SUNRISE_EL berechnet sie immer neu. Den Aufruf von twilight("twilight_device","ss_civil","16:00","22:00") könntest  du auch als  {sunset("CIVIL",0,"16:00","22:00")} schreiben.

Bei mir:
twilight(): 18:50:51
sunset(): 18:50:52

Beide kappen auch die Zeiten entsprechend: Wenn ich beide mit 18:00 statt 22:00 Uhr aufrufe, liefern beide 18:00 zurück.

(Interessant wäre es eher zu wissen, woher die Abweichung von einer Sekunde zwischen beiden Aufrufen kommt)

Ich denke die eine Sekunde kommt von verschiedenen Rundungen.

könnte man die "{twilight()}" Funktion irgendwie retten wenn das Twilight Modul eines Tages ganz aus FHEM rausfällt? eventuell über die myUtils?
Ich nutze das aktuell mit den Readings aus Astro. z.B. {twilight("Astro","CivilTwilightMorning","05:45","07:00")}

Christoph Morrison

Zitat von: Frank_Huber am 08 März 2019, 11:06:14
Ich denke die eine Sekunde kommt von verschiedenen Rundungen.

Das ist sicher eine Möglichkeit über die ich auch schon nachgedacht habe.

Zitat von: Frank_Huber am 08 März 2019, 11:06:14
könnte man die "{twilight()}" Funktion irgendwie retten wenn das Twilight Modul eines Tages ganz aus FHEM rausfällt? eventuell über die myUtils?
Ich nutze das aktuell mit den Readings aus Astro. z.B. {twilight("Astro","CivilTwilightMorning","05:45","07:00")}

Aktuell ist - von meiner Seite aus - kein Lebensende von Twilight geplant. Im Gegenteil, ich bin im Rahmen meiner zeitlichen Möglichkeiten daran, das Modul komplet neu zu schreiben und dabei gleich ein paar Bugs zu tilgen, die bisher dort unerkannt gelauert haben. Hier ist der aktuelle Stand: FHEM-Twilight/in-progress. Im Monatsrückblick haben wir auch darüber geredet.

yersinia

Zitat von: Christoph Morrison am 08 März 2019, 10:54:24
*_indoor und *_weather sind Werte, die nur aus Twilight kommen.
Ja, leider. Könnte man das irgendwie im Astro-Modul nachbauen? Also wenn man zB Bewölkungsgrad von einem Weather-Device bekommen könnte?
Dann wäre mMn das Twilight Modul fast wirklich durch das Astro-Modul ersetzbar.

Zitat von: Christoph Morrison am 08 März 2019, 10:54:24
Den Aufruf von twilight("twilight_device","ss_civil","16:00","22:00") könntest  du auch als  {sunset("CIVIL",0,"16:00","22:00")} schreiben.

Bei mir:
twilight(): 18:50:51
sunset(): 18:50:52

Beide kappen auch die Zeiten entsprechend: Wenn ich beide mit 18:00 statt 22:00 Uhr aufrufe, liefern beide 18:00 zurück.
Danke für den Hinweis, damit könnte ich es ersetzen.

Zitat von: Christoph Morrison am 08 März 2019, 10:54:24
(Interessant wäre es eher zu wissen, woher die Abweichung von einer Sekunde zwischen beiden Aufrufen kommt)
Die Abweichungen von Twilight zum AstroModul sind übrigens Minuten, ist mir aber perönlich egal. Diese Genauigkeit benötige ich zumindestens nicht.
viele Grüße, yersinia
----
FHEM 6.3 (SVN) on RPi 4B with RasPi OS Bullseye (perl 5.32.1) | FTUI
nanoCUL->2x868(1x ser2net)@tsculfw, 1x433@Sduino | MQTT2 | Tasmota | ESPEasy
VCCU->14xSEC-SCo, 7xCC-RT-DN, 5xLC-Bl1PBU-FM, 3xTC-IT-WM-W-EU, 1xPB-2-WM55, 1xLC-Sw1PBU-FM, 1xES-PMSw1-Pl

Christoph Morrison

Zitat von: yersinia am 08 März 2019, 13:51:57
Ja, leider. Könnte man das irgendwie im Astro-Modul nachbauen? Also wenn man zB Bewölkungsgrad von einem Weather-Device bekommen könnte?
Dann wäre mMn das Twilight Modul fast wirklich durch das Astro-Modul ersetzbar.

Es gab diese Diskussion und pah wollte das nicht, was ich im Übrigen auch nachvollziehen kann. Das war aber auch meine erste Idee.

Zitat von: yersinia am 08 März 2019, 13:51:57
Die Abweichungen von Twilight zum AstroModul sind übrigens Minuten, ist mir aber perönlich egal. Diese Genauigkeit benötige ich zumindestens nicht.

Ich weiß. Ist dann hoffentlich auch behoben, wobei ob es da nicht unbedingt ein Bug ist.

buennerbernd

Hallo,

Ich benutze das Reading twilight_weather basierend auf cloudCover vom DarkSkyAPI.
Mit dem Ergebnis bin ich aber unzufrieden, die Auswirkungen der Bewölkung sind zu heftig.
Heute war es bei twilight_weather = 15 noch sehr hell draußen. Ich suche einen guten Wert um die Rollladen runterzufahren.
Kann man da noch eine bessere Feinabstimmung vornehmen?

Gruß, Stefan.
Modulentwickler von KLF200 und KLF200Node

Ellert

Du könntest die Werte der API mit Deiner subjektiven Einschätzung; einem gemessenen Helligkeitswert oder auch bei klarem Wetter mit Azimut und Elevation bewerten und über eine Funktion in Abhängigkeit bringen. Über diese Funktion könntest Du dann ein userReading anlegen, dass die API-Werte in die angepassten Werte umrechnet.

buennerbernd

Zitat von: Ellert am 19 März 2019, 05:24:49
Du könntest die Werte der API mit Deiner subjektiven Einschätzung; einem gemessenen Helligkeitswert oder auch bei klarem Wetter mit Azimut und Elevation bewerten und über eine Funktion in Abhängigkeit bringen. Über diese Funktion könntest Du dann ein userReading anlegen, dass die API-Werte in die angepassten Werte umrechnet.

Danke, das wäre ein Weg. Das blöde ist ja, dass man dieses Feature gerade dann nutzt, wenn man keinen Helligkeitssensor hat.

Ich habe mir im Code mal die Original-Formel angeschaut. Da wundern mich die Ergebnisse nicht:

$twilight_weather = $twilight - int(0.007 * ($extWeatherHorizont ** 2)); ## SCM: 100% clouds => 30% light (rough estimation)


Das heißt, wenn twilight auf 70 ist und die Bewölkung auf 100, dann ist twilight_weather auf 0.
Ich kann das jetzt auf meinen Geschmack anpassen, aber das ist doch eindeutig eine falsche Formel. Der Abzug sollte nicht absolut, sondern in Relation zu $twilight geschehen.

Gruß, Stefan.
Modulentwickler von KLF200 und KLF200Node

CoolTux

Da sich das Modul gerade in der Entwicklung/Neu-Entwicklung befindet, schlage ich vor Du schaust einmal hier
https://github.com/christoph-morrison/FHEM-Twilight

Da kannst Du dann auch sicherlich Deine Erkenntnisse einbringen und ein Request dem Christoph anbieten.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

buennerbernd

Ok, ich werde mal versuchen, eine stimmigere Formel zu finden.
Sollte ich erfolgreich sein, dann werde ich sie Christoph mitteilen.
Dass da was im Argen ist, liest er hier bestimmt auch mit.

Ich bin doch bestimmt nicht der einzige, der twilight_weather verwenden möchte. Haben sich da schon andere einen Kopf gemacht?
Modulentwickler von KLF200 und KLF200Node

Ellert

Zitat von: buennerbernd am 19 März 2019, 10:50:41
Danke, das wäre ein Weg. Das blöde ist ja, dass man dieses Feature gerade dann nutzt, wenn man keinen Helligkeitssensor hat.

Ich habe mir im Code mal die Original-Formel angeschaut. Da wundern mich die Ergebnisse nicht:

$twilight_weather = $twilight - int(0.007 * ($extWeatherHorizont ** 2)); ## SCM: 100% clouds => 30% light (rough estimation)


Das heißt, wenn twilight auf 70 ist und die Bewölkung auf 100, dann ist twilight_weather auf 0.
Ich kann das jetzt auf meinen Geschmack anpassen, aber das ist doch eindeutig eine falsche Formel. Der Abzug sollte nicht absolut, sondern in Relation zu $twilight geschehen.

Gruß, Stefan.
Den Einfluss von cloudcover auf die Helligkeit ist gerade im Bereich des Sonnenaufgangs und des Sonnenuntergangs nicht einfach darzustellen.
Letztlich muss man die Hindernisse auf dem Weg der Sonnenstrahlen kennen und die zusätzliche Strahlung durch Reflektionen berücksichtigen, um zu einer zutreffenden Aussage über die Hellikeit treffen zu können. Ein Bedeckungsgrad reicht sicher nicht aus um zu sicheren Ergebnissen zu kommen.

Die sicherste Methode bleibt die Helligkeitsmessung, z.B. mit einem TSL2561 am RasPi.


r00t2

FHEM 6.0 (Raspberry Pi 2 B | Raspberry Pi OS Lite | Perl 5.28.1 | UZB Z-WAVE.Me | Hue Bridge V1 | SIGNALDuino 433 MHz | FritzBox | Kodi | Pioneer AVR | MQTT | Node-RED | Diverse Google Dienste)

buennerbernd

Zitat von: r00t2 am 22 März 2019, 11:16:26
Klar! Einfach mal den Thread lesen :)

=> https://forum.fhem.de/index.php/topic,95281.msg910946.html#msg910946
=> https://forum.fhem.de/index.php/topic,95281.msg914097.html#msg914097

Stimmt, 3 Seiten rückwärts hätten drin sein können ;)
Diese Plots zusammen mit dem Plot eines Helligkeitssensors wären sehr hilfreich.

Ich sehe drei Stellschrauben an der Formel:

  • Der Abzug vom cloudCover-Einfluss erfolgt absolut und sollte wohl besser relativ von twilight sein.
  • Der Abzug bei cloudCover = 100% ist 70%, das könnte zu viel sein.
  • cloudCover geht quadratisch ein, hier wäre mal zu testen, ob das realistisch ist oder ob linear doch besser ist

Bisher habe ich noch keine neue Formel, sondern abends nur den Himmel angestarrt und darüber nachgedacht, was am Besten passen würde. Nicht so einfach ohne Sensor.
Modulentwickler von KLF200 und KLF200Node

Ellert

Zitat von: buennerbernd am 22 März 2019, 16:22:02
Stimmt, 3 Seiten rückwärts hätten drin sein können ;)
Diese Plots zusammen mit dem Plot eines Helligkeitssensors wären sehr hilfreich.

Ich sehe drei Stellschrauben an der Formel:

  • Der Abzug vom cloudCover-Einfluss erfolgt absolut und sollte wohl besser relativ von twilight sein.
  • Der Abzug bei cloudCover = 100% ist 70%, das könnte zu viel sein.
  • cloudCover geht quadratisch ein, hier wäre mal zu testen, ob das realistisch ist oder ob linear doch besser ist

Bisher habe ich noch keine neue Formel, sondern abends nur den Himmel angestarrt und darüber nachgedacht, was am Besten passen würde. Nicht so einfach ohne Sensor.

Man könnte den Bedeckungsgrad als Maß für die Verschiebung der des Twilightverlaufs sehen.  Der Verlauf bleibt gleich, aber es gibt eine zeitliche Verschiebung in Abhängigkeit des Bedeckungsgrades. Beispiel: Wenn 100% Bedeckung eine Verschiebung von 90 min. bedeutet, dann könnte man bei einem Bedeckungsgrad von 50% Twilight_Weather für die aktuelle Zeit +/- 45 min ermitteln, falls die Abhängigkeit linear ist.

buennerbernd

#163
Um mal etwas voranzukommen habe ich zum Test mal ein userReading twilight_clouds angelegt:


twilight_clouds {
  my ($twilight) = ReadingsVal($name,"twilight",0);
  my ($useExtWeather) = AttrVal($name,"useExtWeather",":");
  my ($extWeatherName, $cloudsReading) = split(/:/, $useExtWeather);
  my ($clouds) = ReadingsVal($extWeatherName,$cloudsReading,0);
  return int($twilight * (1 - 0.005 * $clouds)); }


Volle Bewölkung halbiert die Helligkeit.
Ich bin mir sicher, dass das nicht der schlauste Ansatz ist, denn mittags ist der Wert 50 auch bei voller Bedeckung sicherlich übertrieben wenig. Es ist aber ein Anfang, um einen Eindruck zu gewinnen.

Wer mag, kann ja mittesten.
Voraussetzung ist, dass des Attribut useExtWeather einen gültigen Wert hat.

Gruß, Stefan.
Modulentwickler von KLF200 und KLF200Node

buennerbernd

Oh Mann, strahlender Sonnenschein, keine Wollte am Himmel und DarkSky meldet ein CloudCover von 70.
So wird das schwer.
Modulentwickler von KLF200 und KLF200Node