Twilight Verständnisprobleme

Begonnen von DerFrickler, 06 Januar 2017, 15:41:30

Vorheriges Thema - Nächstes Thema

DerFrickler

Hallo zusammen,

bei folgender Definition hatte ich heute ein Event bereits um 15:00 Uhr obwohl ss_civil auf 17:22:00 steht:

*{twilight("twilight","ss_civil","15:00","20:00")} setreading twilight inhibitBlindActuator set_on


Laut Definition:
twilight($twilight, $reading, $min, $max)
sind $min und $max optional

Entferne ich jetzt einen der Parameter, bekomme ich folgende Meldung:

the function "twilight("twilight","ss_civil","15:00")" must return a timespec and not Not enough arguments for main::twilight at (eval 159760) line 1, near ""15:00")"


Frage 1: Was hat es mit $min und $max auf sich? Warum löst twilight schon um 15:00 aus?

Frage 2: Was bedeutet hier optional, wenn weglassen dann zu einer Fehlermeldung führt?

Gruß und Danke,
Karsten

Dietmar63

Optional bedeutet, dass du "" übergeben kannst. Dann werden sie nicht berücksichtigt.

Wenn für twilight (... )  wie in deinem Fall zum Zeit min, max geschaltet wird, ist der Wert des Readings ss_civil zum Zeitpunkt der Definition des at ausserhalb von min-max
Das kann bei einem restart beispielsweise der Fall sein, wenn Twilight die Werte noch nicht ermittelt hat, aber der at schon seinen Startzeitpunkt berechnet
Gruß Dietmar
FB7390, CUL, 2 FHT, FS20
modules: 98_WOL.pm, 98_Heating_Control.pm,   98_WeekdayTimer.pm, 98_RandomTimer.pm, 59_Twilight.pm

DerFrickler

#2
Zitat von: Dietmar63 am 06 Januar 2017, 16:21:48
Optional bedeutet, dass du "" übergeben kannst. Dann werden sie nicht berücksichtigt.

Das klappt jetzt, danke!

Zitat von: Dietmar63 am 06 Januar 2017, 16:21:48
Wenn für twilight (... )  wie in deinem Fall zum Zeit min, max geschaltet wird, ist der Wert des Readings ss_civil zum Zeitpunkt der Definition des at ausserhalb von min-max
Das kann bei einem restart beispielsweise der Fall sein, wenn Twilight die Werte noch nicht ermittelt hat, aber der at schon seinen Startzeitpunkt berechnet

Plausible Erklärung, aber da wird es wohl einen anderen Grund geben, denn

Der Schaltvorgang war um exakt 15:00:
2017.01.06 15:00:00 3: device name: structure.blindActuator.terrace.awning.inhibitBlindActuator

und ss_civil wurde gut 15 Stunden zuvor gesetzt:
ss_civil     17:22:00     2017-01-06 00:00:06

letztendlich interessiert der Zeitrahmen von min und max aber auch nicht.

Gruß,
Karsten

--------------------------------------------------------------------------------------------------------------------------------
--------------------------------------------------------------------------------------------------------------------------------
Noch eine Feststellung:

mit
*{twilight("twilight","ss_civil","","")} setreading twilight inhibitBlindActuator set_on


steht der nächste Trigger um Mitternacht an
TRIGGERTIME_FMT     2017-01-07     00:00:00

Dietmar63

{twilight("twilight","ss_civil",undef,undef)}
Gruß Dietmar
FB7390, CUL, 2 FHT, FS20
modules: 98_WOL.pm, 98_Heating_Control.pm,   98_WeekdayTimer.pm, 98_RandomTimer.pm, 59_Twilight.pm

DerFrickler


SofB

Ich hatte ja hier: https://forum.fhem.de/index.php/topic,62336.msg545379.html ein ähnlich gelagertes Problem.
Wie es scheint, werden immer um 0 Uhr die Daten gesetzten. Beim Reboot des FHEM allerdings werden bei meinen ganzen AT Commands die Zeiten nicht ne gesetzt, solange ich diese nicht explizit mit "modify" nochmal abspeichere.
Da ich das Twilight Modul so genial finde, habe ich mittlerweile schon 6-7 AT Commands und DOIFs die alle Twilight nutzen.
Nach jedem Update von FHEM und anschliessendem Restart stehe ich erneut vor dem Problem.
Kann man da iwie Abhilfe schaffen?
Danke!
und DANKE für das tolle Modul!
FHEM auf Debian Jessie VM - ESXi 6.0 Intel Nuc i5 4th Gen
HM-CFG-LAN | HM-CFG-USB | nanoCUL868 | nanoCUL433 | JeeLink868

Dietmar63

Nach jedem Update von FHEM und anschliessendem Restart stehe ich erneut vor dem Problem.
Kann man da iwie Abhilfe schaffen?


Wahrscheinlich liegt es daran, dass beim Start von fhem die at und DOIF vor dem Twilight definiert werden.
Dann steht die Information bei einem Start einfach nicht zur Verfügung.

Versuch mal die Reihenfolge zu ändern.

Mit verbose 4 oder verbose 5 kannst du die Details sehen zu wann geschaltet wird.
Gruß Dietmar
FB7390, CUL, 2 FHT, FS20
modules: 98_WOL.pm, 98_Heating_Control.pm,   98_WeekdayTimer.pm, 98_RandomTimer.pm, 59_Twilight.pm

SofB

In der fhem.cfg ist Twilight eines der ersten Dinge die initialisiert werden. Weit vor dem DOIF und AT.

Das Verbose habe ich hochgesetzt:


2017.01.23 20:33:41 1: usb create starting
2017.01.23 20:33:41 1: usb create end
2017.01.23 20:33:41 3: netatmo: I/O device is WetterNetatmo
2017.01.23 20:33:42 3: Opening squeezeboxServer device 10.0.0.11:9090
2017.01.23 20:33:42 3: SB_SERVER_DoInit(squeezeboxServer): STATE: opened power: ?
2017.01.23 20:33:42 3: SB_SERVER_DoInit(squeezeboxServer): SB-Server is back again.
2017.01.23 20:33:42 3: squeezeboxServer device opened
2017.01.23 20:33:42 2: SecurityCheck:  WEB,WEBphone,WEBtablet has no associated allowed device with basicAuth. telnetPort has no associated allowed device with password/globalpassword.  Restart FHEM for a new check if the problem is fixed, or set the global attribute motd to none to supress this message.
2017.01.23 20:33:42 0: Featurelevel: 5.7
2017.01.23 20:33:42 0: Server started with 271 defined entities (fhem.pl:13142/2017-01-18 perl:5.020002 os:linux user:fhem-user pid:41319)
2017.01.23 20:33:42 4: [TwilightHome] sr_astro   2017-01-23 06:12:21  ( 1/1/-18.0°/0)   ===> sr_naut    06:52:36
2017.01.23 20:33:42 4: [TwilightHome] sr_naut    2017-01-23 06:52:36  ( 2/2/-12.0°/0)   ===> sr_civil   07:34:31
2017.01.23 20:33:42 4: [TwilightHome] sr_civil   2017-01-23 07:34:31  ( 3/3/ -6.0°/0)   ===> sr         08:19:18
2017.01.23 20:33:42 4: [TwilightHome] sr         2017-01-23 08:19:18  ( 4/4/ +0.0°/0)   ===> sr_indoor  08:27:10
2017.01.23 20:33:42 4: [TwilightHome] sr_indoor  2017-01-23 08:27:10  ( 5/5/ +1.0°/0)   ===> sr_weather 08:40:06
2017.01.23 20:33:42 4: [TwilightHome] sr_weather 2017-01-23 08:40:06  ( 6/6/ +2.6°/0)   ===> ss_weather 16:20:45
2017.01.23 20:33:42 4: [TwilightHome] ss_weather 2017-01-23 16:20:45  ( 7/5/ +2.6°/0)   ===> ss_indoor  16:33:41
2017.01.23 20:33:42 4: [TwilightHome] ss_indoor  2017-01-23 16:33:41  ( 8/4/ +1.0°/0)   ===> ss         16:41:33
2017.01.23 20:33:42 4: [TwilightHome] ss         2017-01-23 16:41:33  ( 9/3/ +0.0°/0)   ===> ss_civil   17:26:22
2017.01.23 20:33:42 4: [TwilightHome] ss_civil   2017-01-23 17:26:22  (10/2/ -6.0°/0)   ===> ss_naut    18:08:18
2017.01.23 20:33:42 4: [TwilightHome] ss_naut    2017-01-23 18:08:18  (11/1/-12.0°/0)   ===> ss_astro   18:48:36
2017.01.23 20:33:42 4: [TwilightHome] ss_astro   2017-01-23 18:48:36  (12/0/-18.0°/0)   ===> sr_astro   06:12:21


Was auffällig ist, nur bei jedem 2. oder 3. mal wird TwilightHome so initailisiert.
Dann sind auch meine Timer korrekt initialisiert.
In den anderen Fällen kommt kein Logoutput und die Timer stehen auf den parametrisierten Mindestwerten.
Wird da evtl was im State gecached?
FHEM auf Debian Jessie VM - ESXi 6.0 Intel Nuc i5 4th Gen
HM-CFG-LAN | HM-CFG-USB | nanoCUL868 | nanoCUL433 | JeeLink868

Dietmar63

gecacht wird nichts - aber es kann sein, dass aufgrund der Ermittlung der Wetterdaten mit BlockingGet eine bis zu 10 Sekunden währende Verzögerung  auftritt, die dann auch noch mehrmals wiederholt wird, wenn yahoo nichts liefert.

wie hast du denn die at bzw DOIFs gebaut?
Gruß Dietmar
FB7390, CUL, 2 FHT, FS20
modules: 98_WOL.pm, 98_Heating_Control.pm,   98_WeekdayTimer.pm, 98_RandomTimer.pm, 59_Twilight.pm

SofB

Okay, bei dem Wetter habe ich ab und zu von Problemen mit der Erreichbarkeit von yahoo gelesen.
Kann man das Wetter in Twilight deaktivieren?

[TwilightHome] 3 attempt(s) needed to get valid weather data from yahoo

Beim Start habe entweder den oben gezeigen "Zeitenblock" gesehen, oder die Versuche yahoo zu erreichen. Beides tauchte IMHO zusammen auf.

Ansonsten hier mal ein Beispiel:

*{twilight("TwilightHome","ss_civil","16:00","23:00")} set OfficeLight on
   
und noch eins:

([Residents] eq "home" and [{twilight("TwilightHome","ss_indoor","16:00","23:00")}]) (set WardrobeLight on)
FHEM auf Debian Jessie VM - ESXi 6.0 Intel Nuc i5 4th Gen
HM-CFG-LAN | HM-CFG-USB | nanoCUL868 | nanoCUL433 | JeeLink868

Dietmar63

Wenn du beim Starten Probleme hast musst du den Start mit global verbose 5 durchführen  und prüfen, ob die at auf ein initialized twilight stößt.

Beim DOIF ist es schwieriger. Verbose funktioniert nicht. Und wie es innerlich funktioniert kann ich nicht sagen.
Einerseits funktioniert es wie ein notify mit vielen Bedingungen, aber sonst ???

Die Funktion twilight(...) wirft keine Ereignisse für notify
Gruß Dietmar
FB7390, CUL, 2 FHT, FS20
modules: 98_WOL.pm, 98_Heating_Control.pm,   98_WeekdayTimer.pm, 98_RandomTimer.pm, 59_Twilight.pm

Dietmar63

die folgenden beiden Zeilen haben mich auf die Lösung des Rätsels gebracht:


2017.01.24 19:00:05 4: [TwilightHome] answer={"query":{"count":0,"created":"2017-01-24T18:00:05Z","lang":"en-US","results":null}}
2017.01.24 19:00:05 5: [TwilightHome] setting  Timer: TwilightHome_Midnight 2017-01-24 19:01:05


Yahoo ist im Moment nicht sehr zuverlässig mit der Lieferung der Wetterdaten.
In deinem Fall wurde "results":null geliefert. Dann versucht TW nach Ablauf einer Minute nochmals(zweite Zeile) Daten zu bekommen(bis zu 10 mal). Das ist für den Start deiner timer natürlich doof. Zeitangaben im at werden sofort bei der Definition berechnet.

Der Aufwand einer vernünftigen Synchronisation ist leider hoch.
Du könntest ein notify bauen, das auf das Ereignis Twilight:ss_astro reagiert und per modify die at und DOIFs erneuert.
ss_astro wird immer dann gesetzt, wenn die timer initialisiert werden. Dann würden deine at auch um Mitternacht neu modifyed, wennnämlich die  ss, sr neu berechnet werden.

Oder einfach nicht so oft starten.

mit

define TwilightMessage2      notify Twilight.*:ss_astro:.*                      {Log 3, "Nachricht von $NAME: $EVENT"}

kannst du testen, wann ss_astro neu versorgt wird.

Ein Test bei mir hat sofort zu einer Initialisierung geführt:

2017.01.25 20:17:58 5: [Twilight] setting  Timer: Twilight_sunpos 2017-01-25 20:22:58
2017.01.25 20:17:58 5: [Twilight] removing Timer: Twilight_sunpos
2017.01.25 20:17:58 5: [Twilight] Original weather readings
2017.01.25 20:12:58 5: [Twilight] setting  Timer: Twilight_sunpos 2017-01-25 20:17:58
2017.01.25 20:12:58 5: [Twilight] removing Timer: Twilight_sunpos
2017.01.25 20:12:58 5: [Twilight] Original weather readings
2017.01.25 20:07:58 5: [Twilight] setting  Timer: Twilight_sunpos 2017-01-25 20:12:58
2017.01.25 20:07:58 5: [Twilight] removing Timer: Twilight_sunpos
2017.01.25 20:07:58 5: [Twilight] Original weather readings
2017.01.25 20:03:03 4: [Twilight] ss_astro   2017-01-25 18:54:34  (12/0/-18.0°/0)   ===> sr_astro   06:11:08             
2017.01.25 20:03:03 4: [Twilight] ss_naut    2017-01-25 18:14:20  (11/1/-12.0°/0)   ===> ss_astro   18:54:34             
2017.01.25 20:03:03 4: [Twilight] ss_civil   2017-01-25 17:32:35  (10/2/ -6.0°/0)   ===> ss_naut    18:14:20             
2017.01.25 20:03:03 4: [Twilight] ss         2017-01-25 16:48:09  ( 9/3/ +0.0°/0)   ===> ss_civil   17:32:35             
2017.01.25 20:03:03 4: [Twilight] ss_indoor  2017-01-25 16:48:09  ( 8/4/ +0.0°/0)   ===> ss         16:48:09             
2017.01.25 20:03:03 4: [Twilight] ss_weather 2017-01-25 16:22:42  ( 7/5/ +3.2°/0)   ===> ss_indoor  16:48:09             
2017.01.25 20:03:03 4: [Twilight] sr_weather 2017-01-25 08:42:52  ( 6/6/ +3.2°/0)   ===> ss_weather 16:22:42             
2017.01.25 20:03:03 4: [Twilight] sr_indoor  2017-01-25 08:17:26  ( 5/5/ +0.0°/0)   ===> sr_weather 08:42:52             
2017.01.25 20:03:03 4: [Twilight] sr         2017-01-25 08:17:26  ( 4/4/ +0.0°/0)   ===> sr_indoor  08:17:26             
2017.01.25 20:03:03 4: [Twilight] sr_civil   2017-01-25 07:33:01  ( 3/3/ -6.0°/0)   ===> sr         08:17:26             
2017.01.25 20:03:03 4: [Twilight] sr_naut    2017-01-25 06:51:19  ( 2/2/-12.0°/0)   ===> sr_civil   07:33:01             
2017.01.25 20:03:03 4: [Twilight] sr_astro   2017-01-25 06:11:08  ( 1/1/-18.0°/0)   ===> sr_naut    06:51:19             
2017.01.25 20:03:03 5: [Twilight] setting  Timer: Twilight_Midnight 2017-01-26 00:00:01
2017.01.25 20:03:03 5: [Twilight] removing Timer: Twilight_Midnight
2017.01.25 20:03:03 5: [Twilight] setting  Timer: Twilight_ss_weather 2017-01-25 16:22:42
2017.01.25 20:03:03 5: [Twilight] removing Timer: Twilight_ss_weather
2017.01.25 20:03:03 5: [Twilight] setting  Timer: Twilight_ss_naut 2017-01-25 18:14:20
2017.01.25 20:03:03 5: [Twilight] removing Timer: Twilight_ss_naut
2017.01.25 20:03:03 5: [Twilight] setting  Timer: Twilight_ss_indoor 2017-01-25 16:48:09
2017.01.25 20:03:03 5: [Twilight] removing Timer: Twilight_ss_indoor
2017.01.25 20:03:03 5: [Twilight] setting  Timer: Twilight_ss_civil 2017-01-25 17:32:35
2017.01.25 20:03:03 5: [Twilight] removing Timer: Twilight_ss_civil
2017.01.25 20:03:03 5: [Twilight] setting  Timer: Twilight_ss_astro 2017-01-25 18:54:34
2017.01.25 20:03:03 5: [Twilight] removing Timer: Twilight_ss_astro
2017.01.25 20:03:03 5: [Twilight] setting  Timer: Twilight_ss 2017-01-25 16:48:09
2017.01.25 20:03:03 5: [Twilight] removing Timer: Twilight_ss
2017.01.25 20:03:03 5: [Twilight] setting  Timer: Twilight_sr_weather 2017-01-25 08:42:52
2017.01.25 20:03:03 5: [Twilight] removing Timer: Twilight_sr_weather
2017.01.25 20:03:03 5: [Twilight] setting  Timer: Twilight_sr_naut 2017-01-25 06:51:19
2017.01.25 20:03:03 5: [Twilight] removing Timer: Twilight_sr_naut
2017.01.25 20:03:03 5: [Twilight] setting  Timer: Twilight_sr_indoor 2017-01-25 08:17:26
2017.01.25 20:03:03 5: [Twilight] removing Timer: Twilight_sr_indoor
2017.01.25 20:03:03 5: [Twilight] setting  Timer: Twilight_sr_civil 2017-01-25 07:33:01
2017.01.25 20:03:03 5: [Twilight] removing Timer: Twilight_sr_civil
2017.01.25 20:03:03 5: [Twilight] setting  Timer: Twilight_sr_astro 2017-01-25 06:11:08
2017.01.25 20:03:03 5: [Twilight] removing Timer: Twilight_sr_astro
2017.01.25 20:03:03 5: [Twilight] setting  Timer: Twilight_sr 2017-01-25 08:17:26
2017.01.25 20:03:03 5: [Twilight] removing Timer: Twilight_sr
2017.01.25 20:03:02 4: [Twilight] 27=Mostly Cloudy -1, correction: 3.2°
2017.01.25 20:03:02 4: [Twilight] answer={"query":{"count":1,"created":"2017-01-25T19:03:02Z","lang":"en-US","results":{"channel":{"units":{"distance":"km","pressure":"mb","speed":"km/h","temperature":"C"},"title":"Yahoo! Weather - Burgdorf, NI, DE","link":"http://us.rd.yahoo.com/dailynews/rss/weather/Country__Country/*https://weather.yahoo.com/country/state/city-12833457/","description":"Yahoo! Weather for Burgdorf, NI, DE","language":"en-us","lastBuildDate":"Wed, 25 Jan 2017 08:03 PM CET","ttl":"60","location":{"city":"Burgdorf","country":"Germany","region":" NI"},"wind":{"chill":"21","direction":"100","speed":"17.70"},"atmosphere":{"humidity":"93","pressure":"34710.50","rising":"0","visibility":"21.40"},"astronomy":{"sunrise":"8:11 am","sunset":"4:55 pm"},"image":{"title":"Yahoo! Weather","width":"142","height":"18","link":"http://weather.yahoo.com","url":"http://l.yimg.com/a/i/brand/purplelogo//uh/us/news-wea.gif"},"item":{"title":"Conditions for Burgdorf, NI, DE at 07:00 PM CET","lat":"52.4739","long":"10.01198","link":"http://us.rd.yahoo.com/dailynews/rss/weather/Country__Country/*https://weather.yahoo.com/country/state/city-12833457/","pubDate":"Wed, 25 Jan 2017 07:00 PM CET","condition":{"code":"27","date":"Wed, 25 Jan 2017 07:00 PM CET","temp":"-1","text":"Mostly Cloudy"},"forecast":[{"code":"28","date":"25 Jan 2017","day":"Wed","high":"0","low":"-2","text":"Mostly Cloudy"},{"code":"30","date":"26 Jan 2017","day":"Thu","high":"1","low":"-2","text":"Partly Cloudy"},{"code":"32","date":"27 Jan 2017","day":"Fri","high":"1","low":"-4","text":"Sunny"},{"code":"34","date":"28 Jan 2017","day":"Sat","high":"2","low":"-5","text":"Mostly Sunny"},{"code":"30","date":"29 Jan 2017","day":"Sun","high":"4","low":"-1","text":"Partly Cloudy"},{"code":"28","date":"30 Jan 2017","day":"Mon","high":"4","low":"0","text":"Mostly Cloudy"},{"code":"28","date":"31 Jan 2017","day":"Tue","high":"6","low":"2","text":"Mostly Cloudy"},{"code":"28","date":"01 Feb 2017","day":"Wed","high":"5","low":"2","text":"Mostly Cloudy"},{"code":"28","date":"02 Feb 2017","day":"Thu","high":"4","low":"1","text":"Mostly Cloudy"},{"code":"28","date":"03 Feb 2017","day":"Fri","high":"5","low":"2","text":"Mostly Cloudy"}],"description":"<![CDATA[<img src=\"http://l.yimg.com/a/i/us/we/52/27.gif\"/>\n<BR />\n<b>Current Conditions:</b>\n<BR />Mostly Cloudy\n<BR />\n<BR />\n<b>Forecast:</b>\n<BR /> Wed - Mostly Cloudy. High: 0Low: -2\n<BR /> Thu - Partly Cloudy. High: 1Low: -2\n<BR /> Fri - Sunny. High: 1Low: -4\n<BR /> Sat - Mostly Sunny. High: 2Low: -5\n<BR /> Sun - Partly Cloudy. High: 4Low: -1\n<BR />\n<BR />\n<a href=\"http://us.rd.yahoo.com/dailynews/rss/weather/Country__Country/*https://weather.yahoo.com/country/state/city-12833457/\">Full Forecast at Yahoo! Weather</a>\n<BR />\n<BR />\n(provided by <a href=\"http://www.weather.com\" >The Weather Channel</a>)\n<BR />\n]]>","guid":{"isPermaLink":"false"}}}}}}
2017.01.25 20:03:02 4: [Twilight] got weather info from yahoo for 12833457
2017.01.25 20:03:02 2: HttpUtils http://query.yahooapis.com/v1/public/yql?q=select%20*%20from%20weather.forecast%20where%20woeid=12833457%20and%20u=%27c%27&format=json&env=store%3A%2F%2Fdatatables.org%2Falltableswithkeys: Got data, length: 2882
2017.01.25 20:03:02 2: http://query.yahooapis.com/v1/public/yql?q=select%20*%20from%20weather.forecast%20where%20woeid=12833457%20and%20u=%27c%27&format=json&env=store%3A%2F%2Fdatatables.org%2Falltableswithkeys: HTTP response code 200
2017.01.25 20:02:58 2: HttpUtils url=http://query.yahooapis.com/v1/public/yql?q=select%20*%20from%20weather.forecast%20where%20woeid=12833457%20and%20u=%27c%27&format=json&env=store%3A%2F%2Fdatatables.org%2Falltableswithkeys
2017.01.25 20:02:58 4: [Twilight] url=http://query.yahooapis.com/v1/public/yql?q=select%20*%20from%20weather.forecast%20where%20woeid=12833457%20and%20u=%27c%27&format=json&env=store%3A%2F%2Fdatatables.org%2Falltableswithkeys
2017.01.25 20:02:58 5: [Twilight] setting  Timer: Twilight_sunpos 2017-01-25 20:07:58
2017.01.25 20:02:58 5: [Twilight] removing Timer: Twilight_sunpos
2017.01.25 20:02:58 5: [Twilight] Original weather readings
Gruß Dietmar
FB7390, CUL, 2 FHT, FS20
modules: 98_WOL.pm, 98_Heating_Control.pm,   98_WeekdayTimer.pm, 98_RandomTimer.pm, 59_Twilight.pm

SofB

Hi Dietmar,

danke für Deine Rückmeldung und Erklärung. :)
Ich werde das mit dem Notify mal ausprobieren.

Hast Du Paypal? Ich würde mich ganz gerne mal zumindest mit einem Kaffee oder Bier revanchieren :)
FHEM auf Debian Jessie VM - ESXi 6.0 Intel Nuc i5 4th Gen
HM-CFG-LAN | HM-CFG-USB | nanoCUL868 | nanoCUL433 | JeeLink868

p-body

Sorry, dass ich diese alte Thema rauskrame...

Ich steuere jetzt seit einiger Zeit meine Rollos mit Twilight und versuche nun auch das Problem der ersten Schaltzeitpunkte nach Restart von fhem zu fixen.

Folgender "at" wurde für ein Rollo definiert:

define abends_SZ_Rollos at *{twilight("VD_Twilight","ss_indoor","16:00","22:00")} set SZ_Rollo pct 40


Der Schaltpunkt wird dann nach Neustart allerdings immer mit 16:00Uhr eingetragen...

Ein modify abends_SZ_Rollos *{twilight("VD_Twilight","ss_indoor","16:00","22:00")} set SZ_Rollo pct 40  korrigiert den Schaltpunkt, wenn er z.B. per Telnet ausgeführt wird.

Ein automatisches Auslösen dieses modify ist mir bisher aber leider nicht gelungen.

z.B. folgendes notify wurde erfolglos probiert:
define n_TwilightMessageSZ notify Twilight.*:ss_astro:.*   {fhem('modify abends_SZ_Rollos *{twilight("VD_Twilight","ss_indoor","16:00","22:00")} set SZ_Rollo pct 40')}

Kann mir jemand helfen, das korrekt einzubinden? - Oder ist das schon der komplett falsche Ansatz?
 

MadMax-FHEM

Automatisches Auslösen nach fhem Start geht über ein notify auf global:INITIALIZED


define nFhemRestarted notify global:INITIALIZED modify abends_SZ_Rollos *{twilight("VD_Twilight","ss_indoor","16:00","22:00")} set SZ_Rollo pct 40


Sollte bei jedem fhem Neustart das modify ausführen...

Ist aber nur Symtombekämpfung?

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

Beta-User

Zitat von: MadMax-FHEM am 18 Januar 2022, 08:03:00
Ist aber nur Symtombekämpfung?
Ja, und die "drittbeste" Variante, um das Problem zu lösen...

@p-body:
Vorab mal: Willkommen im FHEM-Forum :) .

a) Twilight ist seit ca. 2020 nicht mehr direkt vergleichbar mit Twilight 2017, jedenfalls, was die Frage angeht, wie es (meistens) rund um die .*_weather-Readings tickt (hier nicht unmittelbar das Thema).

b) Dein Problem mit dem "at" und dem Perl-Code, der auf Readings zugreift ist ein bekanntes - "at" kennt daher ein Attribut "computeAfterInit".

c) Warum das mit dem notify auf "Twilight.*" nicht klappt, ist auch einfach: Du hast es nicht mit dem Event-Monitor angelegt und händisch auf ein Device verwiesen, das es nicht gibt. Geben würde es anscheinend "VD_Twilight".

Die Varianten b) und c) sind mAn. besser als das INITIALIZED-notify, weil man für b) kein zusätzliches Device braucht, und c) von Vorteil wäre, wenn auf die variableren ".*_weather"-Readings reagiert werden soll - diese Zeiten können sich nämlich im Lauf des Tages ggf. mehrfach ändern, je nachdem, wie das Wetter draußen (gemeldet) wird...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

p-body

#16
Vielen Dank für die schnellen Antworten!

Ich habe gleich mal die Varianten b + c getestet - und es funktionieren beide.

Zu c) wie von Beta-User vermutet habe ich das falsche Device genutzt.

(klarer Copy & Paste Fehler  >:( )   

Bei c) wird allerdings bei mir immer ein Config-Change gemeldet - das konnte man doch auch noch irgendwie unterdrücken?!?

Twilight ist wie von Beta-User vermutet als "VD_Twilight" definiert:
define VD_Twilight Twilight 49.063447 8.194783 1 AgroWeather

damit sollte dann in meinem Beispiel das Notify z.B. so angelegt werden:
define n_TwilightMessageSZ notify VD_Twilight.*:ss_astro:.*   {fhem('modify abends_SZ_Rollos *{twilight("VD_Twilight","ss_indoor","16:00","22:00")} set SZ_Rollo pct 40')}
 
(nur falls andere Anfänger wie ich auch danach suchen)

Für meinen Anwendungsfall langt vermutlich schon Lösung b), da ich hauptsächlich bei Dämmerung die Rollos herunterfahren möchte.

also ein
attr abends_SZ_Rollos computeAfterInit 1
führt wie beschrieben zu einer Aktualisierung der Zeit zum Herunterfahren des Rollos nach einem Neustart von fhem.

Kann man eigentlich auch "einfach" eine Neuberechung der ATs anstoßen, ohne ein modify mit der kompletten Definition auszulösen? (vermutlich nicht, sonst hättet ihr es wohl erwähnt?!?)



Beta-User

Zitat von: p-body am 18 Januar 2022, 19:34:02
Bei c) wird allerdings bei mir immer ein Config-Change gemeldet - das konnte man doch auch noch irgendwie unterdrücken?!?
...das war eigentlich etwas anders gemeint: Twilight wirft nicht nur Events, wenn die Readings aktualisiert werden, sondern auch jeweils zum "Eintrittszeitpunkt" eines neuen "state" (ss_astro dürfte "12" entsprechen) - damit kann man die Rollläden auch ohne "at" schalten, nur mit notify (bzw. für morgens: watchdog oder verzögert per sleep + Prüfung, da die "Leiter" uU. nur bei einem Neustart komplett durchlaufen wird, und das morgendliche Hochfahren unversehens sonst auch abends stattfinden könnte...)

Für "unveränderliche" Werte wie ss_astro würde ich immer die Timer-Lösung mit b) bevorzugen.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files