Anbei die erste testbare Version des Moduls YAAHM - Yet Another Auto Home Module.
Geschaffen habe ich das aus diversen Routinen, die bei mir seit Jahren laufen:
- Ein Tagesprofil, das an jedem Tag zu verschiedenen Zeiten (z.B. zu Sonnenaufgang) bestimmte Dinge ausführt
- Mehrere Wochenprofile, z.B. für das tägliche Wecken (unterschiedlich je Wochentag), die ebenfalls definierbare Aktionen ausführen.
Monats- und Jahresprofile fehlen noch.
Die Device-Darstellung gibt es in einer so genannten short table, die man in beliebige Räume einbinden kann (als Weblink definiert), und als long table mit voller Einstellbarkeit in einem eigenen Raum, der auch das Device enthält.
Der eingebaute Wecker ist schon so "smart", dass man mit einem einfachen Befehl "set <device> manualnext <timername> <zeit>" die Weckzeit ändern kann -. bei mir geht das auch über Sprachsteuerung. Die Zeiten für Sonnenaufgang etc. werden aus dem Astro-Modul ermittelt. Ferientage und Feiertage werden aus (konfigurierbaren) Kalender-Devices abgeholt.
Achtung: Die Javascript-Datei yaahm.js muss nach www/pgm2 installiert werden.
Und bitte nicht über die Dokumentation mäkeln - irgendwann in den nächsten Wochen werde ich eine Wiki-Seite dafür schreiben, bisher gibt es nur die Commandref.
LG
pah
So, hier der erste Start der entsprechenden Wiki-.Seite
https://wiki.fhem.de/wiki/Modul_YAAHM
LG
pah
Super Teil, Danke.
Bin zwar noch nicht ganz durchgestiegen, aber langsam kommt's.
Gruß
Uwe
Sag Bescheid, wo es klemmt - möglicherweise ist die Doku noch zu rudimentär.
LG
pah
Die Idee ist gut. Aber DOIF kommt mir nicht ins Haus. Auch nicht durch so eine Hintertür.
Schade.
Mach mal langsam.
Erstens verwendet das Modul jetzt schon interne Timer - und es ist in der Tat angedacht, das als Option auswählbar zu machen, weil ich DOIF auch nicht so sehr mag.
Zweitens sind die Codeblöcke zur Erzeugung der externen Timer gerade mal jeweils 30 Zeilen lang - bei einem Gesamtumfang von fast 3000 Zeilen. Das kann man mit der linken Hand auf "at" umschreiben, vielleicht mach ich das sogar aus sportlichen Gründen.
LG
pah
hi,
ich hab mir das ganze jetzt auch mal eingebunden.
Was ich noch nicht ganz verstehe ist, was das setzen vom Attribut timeHelper bewirkt. Klar dann werden die Aktionen gefüllt. Aber wie bearbeite ich das Template?! und ist es egal auf welchen Funktionsnamen ich timeHelper setze?
Gruß Michael
ZitatAber wie bearbeite ich das Template?!
In die eigene 99_myUtils (o.ä) kopieren und dort anpassen.
Zitatund ist es egal auf welchen Funktionsnamen ich timeHelper setze?
Ja.
LG
pah
Hallo pah,
im Wiki steht:
ZitatDie Aktionsfelder enthalten jeweils eine komma-getrennte List von FHEM-Befehlen, die bei Eintreten des Timer-Events abgearbeitet wird.
Auf welche Art und Weise ich es auch versuche, es wird immer nur der erste Befehl ausgeführt. Wie muss ein korrekter Eintrag in ein Aktionsfeld aussehen?
So:
}elsif( $event eq "evening" ){
fhem "set NXT_USB cmd dim=20","set Aktor3 gpio 1"
ja offenbar nicht. Aber auch mit Klammer usw. habe ich keinen Erfolg.
Gruß
Uwe
Hallo Uwe, wenn man sich klarmacht, dass "fhem" in Wirklichkeit ein Funktionsaufruf ist, dann wird auch klar, dass man für zwei Befehle die Funktion zweimal verwenden sollte.
}elsif( $event eq "evening" ){ fhem("set NXT_USB cmd dim=20"); fhem("set Aktor3 gpio 1") }
(ungetestet)
Danke Udo, so funktioniert es :)
Gruß
Uwe
Moin,
ich habe noch ein Problem mit den einzelnen Zeiten. Wie ich nun im Astro-Thread erfahren habe, holt sich YAAHM seine Zeiten für Sonnenauf und -untergang aus dem Modul Astro. Dabei habe ich aber Differenzen. Astro meint, SunRise ist um 6:08 und SunSet um 20:37, YAAHM dagegen meint, das wäre 5:41 und 21:08.
Die Aktion, die bei SunRise ausgeführt wird, schlägt dagegen um 5:49 im Log zu Buche.
Die "Astro"-Meldungen im Log, die ich hatte, sind seit der Definition der Koordinaten weg, dafür habe ich nun diese hier:
2017.08.20 00:00:33 1: PERL WARNING: Argument "Datum 20.08.0017 12:00:00 \nJulianisches Datum 1727486.9..." isn't numeric in array element at ./FHEM/95_YAAHM.pm line 1827.
2017.08.20 00:00:33 1: PERL WARNING: Argument "Datum 21.08.0017 12:00:00 \nJulianisches Datum 1727487.9..." isn't numeric in array element at ./FHEM/95_YAAHM.pm line 1828.
Woher kommen diese Differenzen?
Gruß
Uwe
EDIT: Eine Sache kann ich noch nachliefern. Ich weiß, warum das eigentliche Schalt-Event um 5:49 (und das seit Tagen...) ausgeführt wird.
In der Definition von YAAHM taucht diese Zeit auf, und zwar als "s_sunrise". Dieser Wert wurde seit dem 17.08. nicht mehr aktualisiert.
Na, dann versuch mal diese Version.
Achtung: Erfordert ggf. einen restart von FHEM, damit alles sauber angezeigt wird.
LG
pah
Hmmm...keine Änderung (ja, ich habe neu gestartet)
Sieht so aus, als ob Astro.pm keinen Sonnenaufgang liefern kann. Ruf mal mauell auf
{YAAHM_GetDayStatus($defs{'<devicename für das yaahm-Device>'})}
LG
pah
Da passiert nix. Astro aber hat den korrekten Sonnenaufgang:
setstate Astro 2017-08-20 19:54:31 AstroTwilightEvening 23:05
setstate Astro 2017-08-20 19:54:31 AstroTwilightMorning 03:38
setstate Astro 2017-08-20 19:54:31 CivilTwilightEvening 21:15
setstate Astro 2017-08-20 19:54:31 CivilTwilightMorning 05:29
setstate Astro 2017-08-20 19:54:31 MoonAge 346.4
setstate Astro 2017-08-20 19:54:31 MoonAlt 0
setstate Astro 2017-08-20 19:54:31 MoonAz 296.3
setstate Astro 2017-08-20 19:54:31 MoonDec 14.9
setstate Astro 2017-08-20 19:54:31 MoonDiameter 32.2
setstate Astro 2017-08-20 19:54:31 MoonDistance 371174
setstate Astro 2017-08-20 19:54:31 MoonDistanceObserver 371288
setstate Astro 2017-08-20 19:54:31 MoonLat -0.8
setstate Astro 2017-08-20 19:54:31 MoonLon 134.3
setstate Astro 2017-08-20 19:54:31 MoonPhaseN 0.01
setstate Astro 2017-08-20 19:54:31 MoonPhaseS Abnehmende Sichel
setstate Astro 2017-08-20 19:54:31 MoonRa 9.1
setstate Astro 2017-08-20 19:54:31 MoonRise 04:13
setstate Astro 2017-08-20 19:54:31 MoonSet 19:58
setstate Astro 2017-08-20 19:54:31 MoonSign Löwe
setstate Astro 2017-08-20 19:54:31 MoonTransit 12:11
setstate Astro 2017-08-20 19:54:31 NauticTwilightEvening 22:05
setstate Astro 2017-08-20 19:54:31 NauticTwilightMorning 04:39
setstate Astro 2017-08-20 19:54:31 ObsAlt 10
setstate Astro 2017-08-20 19:54:31 ObsDate 20.08.2017
setstate Astro 2017-08-20 19:54:31 ObsDayofyear 232
setstate Astro 2017-08-20 19:54:31 ObsGMST 15:51:32
setstate Astro 2017-08-20 19:54:31 ObsJD 2457986.25
setstate Astro 2017-08-20 19:54:31 ObsLMST 16:31:31
setstate Astro 2017-08-20 19:54:31 ObsLat 53.551085
setstate Astro 2017-08-20 19:54:31 ObsLon 9.993682
setstate Astro 2017-08-20 19:54:31 ObsSeason Sommer
setstate Astro 2017-08-20 19:54:31 ObsTime 19:54:31
setstate Astro 2017-08-20 19:54:31 ObsTimezone 2
setstate Astro 2017-08-20 19:54:31 SunAlt 5.7
setstate Astro 2017-08-20 19:54:31 SunAz 283.5
setstate Astro 2017-08-20 19:54:31 SunDec 12.2
setstate Astro 2017-08-20 19:54:31 SunDiameter 31.6
setstate Astro 2017-08-20 19:54:31 SunDistance 151341929
setstate Astro 2017-08-20 19:54:31 SunDistanceObserver 151341354
setstate Astro 2017-08-20 19:54:31 SunLon 147.9
setstate Astro 2017-08-20 19:54:31 SunRa 10
setstate Astro 2017-08-20 19:54:31 SunRise 06:08
setstate Astro 2017-08-20 19:54:31 SunSet 20:37
setstate Astro 2017-08-20 19:54:31 SunSign Löwe
setstate Astro 2017-08-20 19:54:31 SunTransit 13:23
setstate Astro 2017-08-20 18:53:22 state Initialized
OK, sieht so aus, als ob ich mich da selber ausgetrickst habe: Wenn ein Astro-Device definiert ist, habe ich das nicht sauber abgefragt.
Hier erst einmal ein temporärer Fix.
LG
pah
Kann leider noch keinen Erfolg melden. Astro's SunRise ist 6:08, YAAHM 5:51. Version 0.15 und Neustart...
Ich hatte YAAHM zeitlich vor Astro eingerichtet.
Bitte noch einmal GetDayStatus ausführen - oder ·Mitternacht abwarten.
LG
pah
Weder das Eine noch das Andere hatte Erfolg. Ich habe nun sogar YAAHM rausgeworfen und dann neu installiert...nix. Selbst dann übernimmt YAAHM nicht die aktuellen Daten für Sonnenauf und -untergang. Irgendwo holt sich das Modul 5:43 und 21:06 statt (heute) 6:09 und 20:35.
Gruß
Uwe
Ich sags ja ungerne, aber das kann gar nicht so sein.
1.Bitte mal die Readings posten.
2. Mit dem Code
{Astro_Get($defs{'HIER_DEVICENAME_DES_YAAHM-DEVICE'},"dummy","text", "SunRise",strftime('%4y-%2m-%2d', localtime(time)))}
kann man die Abfrage direkt in der FHEM-Commandline ausführen. Mach mal bitte.
LG
pah
Zitat von: Prof. Dr. Peter Henning am 21 August 2017, 19:42:55
Ich sags ja ungerne, aber das kann gar nicht so sein.
Würde ich an Deiner Stelle auch sagen, aber ich hab's so vor mir... ;)
Zitat
1.Bitte mal die Readings posten.
TYPE YAAHM
VERSION 0.14
DATA:
DD:
HASH(0xab43d2c)
HASH(0xab43c78)
WT:
HASH(0xab43c14)
HASH(0xab43c00)
HASH(0xb14cff8)
HASH(0xb7bd7a0)
HASH(0xbac5d68)
HASH(0xb93c298)
READINGS:
2017-08-12 17:10:45 housemode normal
2017-08-21 20:23:00 housephase daytime
2017-08-21 20:23:00 housetime beforesunset
2017-08-12 17:08:22 lockstate unlocked
2017-08-21 20:23:00 next_housetime sunset
2017-08-12 17:10:45 prev_housemode absence
2017-08-21 20:23:00 prev_housetime evening
2017-08-21 17:11:57 ring_0 05:30
2017-08-21 17:11:57 ring_0_1 05:30
2017-08-21 17:11:57 ring_1 22:30
2017-08-21 17:11:57 ring_1_1 22:30
2017-08-21 17:11:57 ring_2 05:30
2017-08-21 17:11:57 ring_2_1 05:30
2017-08-21 17:11:57 ring_3 05:40
2017-08-21 17:11:57 ring_3_1 05:40
2017-08-21 17:11:57 ring_4 07:00
2017-08-21 17:11:57 ring_4_1 07:00
2017-08-21 17:11:57 ring_5 08:00
2017-08-21 17:11:57 ring_5_1 08:00
2017-08-20 20:01:38 s_aftermidnight 00:01
2017-08-20 20:01:38 s_afternoon 14:00
2017-08-20 20:01:38 s_aftersunrise 06:41
2017-08-20 20:01:38 s_aftersunset 22:08
2017-08-20 20:01:38 s_beforemidnight 23:55
2017-08-20 20:01:38 s_beforesunrise 04:41
2017-08-20 20:01:38 s_beforesunset 20:23
2017-08-20 20:01:38 s_evening 18:30
2017-08-20 20:01:38 s_morning 08:00
2017-08-20 20:01:38 s_night 22:00
2017-08-20 20:01:38 s_noon 13:00
2017-08-20 20:01:38 s_sunrise 05:41
2017-08-20 20:01:38 s_sunset 21:08
2017-08-20 18:53:21 state Initialized
2017-08-20 20:01:38 t_aftermidnight 00:01
2017-08-20 20:01:38 t_aftersunrise 01:00
2017-08-20 20:01:38 t_aftersunset 01:00
2017-08-20 20:01:38 t_beforemidnight 00:05
2017-08-20 20:01:38 t_beforesunrise 01:00
2017-08-20 20:01:38 t_beforesunset 00:45
2017-08-12 17:08:12 todayDesc --
2017-08-21 00:00:33 todayType workday
2017-08-21 17:11:57 today_0 05:30
2017-08-21 17:11:57 today_1 22:30
2017-08-21 17:11:57 today_2 05:30
2017-08-21 17:11:57 today_3 05:40
2017-08-21 17:11:57 today_4 07:00
2017-08-21 17:11:57 today_5 08:00
2017-08-12 17:08:12 tomorrowDesc --
2017-08-20 00:00:33 tomorrowType workday
2017-08-21 17:11:57 tomorrow_0 05:30
2017-08-21 17:11:57 tomorrow_1 22:30
2017-08-21 17:11:57 tomorrow_2 05:30
2017-08-21 17:11:57 tomorrow_3 05:40
2017-08-21 17:11:57 tomorrow_4 07:00
2017-08-21 17:11:57 tomorrow_5 08:00
2017-08-12 17:10:45 tr_housemode Normal
2017-08-21 20:23:00 tr_housephase Tageszeit
2017-08-21 20:23:00 tr_housetime Vor Sonnenuntergang
2017-08-21 00:00:33 tr_todayType Arbeitstag
2017-08-20 00:00:33 tr_tomorrowType Arbeitstag
NAME Astro
NR 405
STATE Initialized
TYPE Astro
VERSION 1.31
READINGS:
2017-08-21 19:54:31 AstroTwilightEvening 23:01
2017-08-21 19:54:31 AstroTwilightMorning 03:41
2017-08-21 19:54:31 CivilTwilightEvening 21:13
2017-08-21 19:54:31 CivilTwilightMorning 05:31
2017-08-21 19:54:31 MoonAge 359.7
2017-08-21 19:54:31 MoonAlt 4.7
2017-08-21 19:54:31 MoonAz 283.8
2017-08-21 19:54:31 MoonDec 11.6
2017-08-21 19:54:31 MoonDiameter 31.8
2017-08-21 19:54:31 MoonDistance 375395
2017-08-21 19:54:31 MoonDistanceObserver 374980
2017-08-21 19:54:31 MoonLat 0.4
2017-08-21 19:54:31 MoonLon 148.5
2017-08-21 19:54:31 MoonPhaseN 0
2017-08-21 19:54:31 MoonPhaseS Neumond
2017-08-21 19:54:31 MoonRa 10
2017-08-21 19:54:31 MoonRise 05:29
2017-08-21 19:54:31 MoonSet 20:31
2017-08-21 19:54:31 MoonSign Löwe
2017-08-21 19:54:31 MoonTransit 13:07
2017-08-21 19:54:31 NauticTwilightEvening 22:02
2017-08-21 19:54:31 NauticTwilightMorning 04:41
2017-08-21 19:54:31 ObsAlt 10
2017-08-21 19:54:31 ObsDate 21.08.2017
2017-08-21 19:54:31 ObsDayofyear 233
2017-08-21 19:54:31 ObsGMST 15:55:29
2017-08-21 19:54:31 ObsJD 2457987.25
2017-08-21 19:54:31 ObsLMST 16:35:27
2017-08-21 19:54:31 ObsLat 53.551085
2017-08-21 19:54:31 ObsLon 9.993682
2017-08-21 19:54:31 ObsSeason Sommer
2017-08-21 19:54:31 ObsTime 19:54:31
2017-08-21 19:54:31 ObsTimezone 2
2017-08-21 19:54:31 SunAlt 5.4
2017-08-21 19:54:31 SunAz 283.4
2017-08-21 19:54:31 SunDec 11.9
2017-08-21 19:54:31 SunDiameter 31.6
2017-08-21 19:54:31 SunDistance 151311200
2017-08-21 19:54:31 SunDistanceObserver 151310659
2017-08-21 19:54:31 SunLon 148.8
2017-08-21 19:54:31 SunRa 10.1
2017-08-21 19:54:31 SunRise 06:09
2017-08-21 19:54:31 SunSet 20:35
2017-08-21 19:54:31 SunSign Löwe
2017-08-21 19:54:31 SunTransit 13:23
2017-08-20 18:53:22 state Initialized
Zitat
2. Mit dem Code
{Astro_Get($defs{'HIER_DEVICENAME_DES_YAAHM-DEVICE'},"dummy","text", "SunRise",strftime('%4y-%2m-%2d', localtime(time)))}
kann man die Abfrage direkt in der FHEM-Commandline ausführen. Mach mal bitte.
Dann sagt er mir die falsche Zeit 5:43
Rätselhaft. Nimm mal statt "SunRise" einfach ""
{Astro_Get($defs{'HIER_DEVICENAME_DES_YAAHM-DEVICE'},"dummy","text", "",strftime('%4y-%2m-%2d', localtime(time)))}
Isses denn zu fassen, hier taucht die 5:43 auf.
Folgende Ausgabe:
Datum 21.08.0017 12:00:00
Julianisches Datum 1727487.92 Tage, 233 Tag d. Jahres
Jahreszeit Sommer, Zeitzone 2
Koordinaten 9.99368° Länge, 53.55109° Breite, 10m Höhe ü.M.
Lokale Sternzeit 07:42:35
Sonne
Aufgang 05:43 Untergang 21:06 Kulmination 13:25
Bürgerliche Dämmerung 05:00 - 21:48
Nautische Dämmerung 04:02 - 22:45
Astronomische Dämmerung 02:37 - 00:08
Entfernung: 151713740km z. Erdmittelpunkt (151708887km z. Beobachter)
Position: Eklipt. Länge 134.5°, Rektaszension 9.10h, Deklination 16.7°; Azimut 147.5°, Horizontwinkel 49.5°
Durchmesser 31.5', Tierkreiszeichen Löwe
Mond
Aufgang 03:46 Untergang 20:37 Kulmination 12:22
Entfernung: 372615km z. Erdmittelpunkt (367286km z. Beobachter)
Position: Eklipt. Länge 118.8°, Eklipt. Breite 0.7°; Rektaszension 8.10h, Deklination 20.8°; Azimut 170.4°, Horizontwinkel 57.0°
Durchmesser 32.1', Alter 344.3°, Phase 0.02 = Abnehmende Sichel, Tierkreiszeichen Krebs
Und das Beste ist, das passiert sowohl auf meiner Testmaschine als auch auf dem Liveserver.
Wieso ist das Datum 0017 definiert?
Zitat von: sweethome am 21 August 2017, 21:45:02
Wieso ist das Datum 0017 definiert?
Sehr gut beobachtet, das ist auf beiden Maschinen so. Trotzdem stimmen aber in Astro die Zeiten
Wenn ich diesen Code in meinen System eingebe
{Astro_Get($defs{'Aktionen'},"dummy","text", "",strftime('2017-%2m-%2d', localtime(time)))}
dann stimmen bei mir die Zeiten in YAAHM.
Dann wird auch bei mir 2017 angezeigt, Sonnenaufgang und Sonnenuntergang passen aber trotzdem nicht.
bei mir stimmen die Zeiten in YAAHM auch nicht. Im ASTRO-Modul stimmen die Zeitangaben.
Wenn ich jedoch das Datum 2017 direkt eingebe habe ich dann in ASTRO und im YAAMH die gleichen ordnungsgemäßen Zeiten.
Datum 21.08.0017 12:00:00
Julianisches Datum 1727487.92 Tage, 233 Tag d. Jahres
Jahreszeit Sommer, Zeitzone 2
Koordinaten 1x.xxxxx° Länge, 4x.xxxxx° Breite, 386m Höhe ü.M.
Lokale Sternzeit 07:49:54
Sonne
Aufgang 05:50 Untergang 20:45 Kulmination 13:18
Bürgerliche Dämmerung 05:12 - 21:22
Nautische Dämmerung 04:24 - 22:09
Astronomische Dämmerung 03:25 - 23:08
Entfernung: 151713740km z. Erdmittelpunkt (151708608km z. Beobachter)
Position: Eklipt. Länge 134.5°, Rektaszension 9.10h, Deklination 16.7°; Azimut 147.4°, Horizontwinkel 53.6°
Durchmesser 31.5', Tierkreiszeichen Löwe
Mond
Aufgang 04:00 Untergang 20:12 Kulmination 12:15
Entfernung: 372615km z. Erdmittelpunkt (367039km z. Beobachter)
Position: Eklipt. Länge 118.8°, Eklipt. Breite 0.7°; Rektaszension 8.10h, Deklination 20.8°; Azimut 172.7°, Horizontwinkel 61.2°
Durchmesser 32.1', Alter 344.3°, Phase 0.02 = Abnehmende Sichel, Tierkreiszeichen Krebs
Datum 21.08.2017 12:00:00
Julianisches Datum 2457986.92 Tage, 233 Tag d. Jahres
Jahreszeit Sommer, Zeitzone 2
Koordinaten 1x.xxxxx° Länge, 4x.xxxxx° Breite, 386m Höhe ü.M.
Lokale Sternzeit 08:46:57
Sonne
Aufgang 06:12 Untergang 20:17 Kulmination 13:15
Bürgerliche Dämmerung 05:37 - 20:52
Nautische Dämmerung 04:54 - 21:35
Astronomische Dämmerung 04:05 - 22:23
Entfernung: 151321382km z. Erdmittelpunkt (151316538km z. Beobachter)
Position: Eklipt. Länge 148.5°, Rektaszension 10.00h, Deklination 12.0°; Azimut 150.8°, Horizontwinkel 49.4°
Durchmesser 31.6', Tierkreiszeichen Löwe
Mond
Aufgang 05:34 Untergang 20:14 Kulmination 12:59
Entfernung: 373939km z. Erdmittelpunkt (368962km z. Beobachter)
Position: Eklipt. Länge 143.9°, Eklipt. Breite 0.0°; Rektaszension 9.80h, Deklination 13.0°; Azimut 156.7°, Horizontwinkel 51.6°
Durchmesser 32.0', Alter 355.4°, Phase 0.00 = Neumond, Tierkreiszeichen Löwe
Sieh an, damit haben wir den Fehler gefunden - danke für die Unterstützung. Es muss nämlich heißen
strftime('%4Y-%2m-%2d', localtime(time))
mit großem Y. Ist in der anliegenden Version behoben. Ist mir bisher nicht einmal in der eigenen Installation aufgefallen, weil erst jetzt die Resultate merklich voneinander abweichen.
LG
pah
EDIT: OHA, ich habe ein paar y zuviel in Y geändert - als Folge davon liest die hier gepostete Version leider die calendar-Devices nicht mehr sauber ein. Also werde ich das jetzt hier löschen, und heute abend eine saubere Version von YAAHM in das normale Repository einchecken.
LG
pah
Hallo pah,
dat löppt, wie man hier so schön sagt. Passt wieder.
Danke und Gruß
Uwe
Wieder einmal Probleme mit dem SVN - und diesmal gibt es noch nicht einmal eine sinnvolle Fehlermeldung. :-X :-X :-X
Also hier die letzten Versionen, jetzt umgetauft nach 1.0.
WIki und CommandRef auf dem aktuellen Stand.
LG
pah
EDIT: Hat jetzt geklappt, die Dinger werden per Update verteilt.
ZitatWieder einmal Probleme mit dem SVN...
und ich suche schon den halben Nachmittag nach dem Modul ;)
VG
Frank
Kommando zurück, nix passt.
Heute ist wieder (nachdem es gestern gestimmt hatte) der Sonnenaufgang angeblich um 5:41 und der Sonnenuntergang um 21:08 - wie seit ein paar Tagen schon...siehe Screenshot. Auch die selbstdefinierten Wochentimer waren dann heute verschwunden. Ob das heute morgen schon war, kann ich nicht sagen. Hab das Dilemma eben erst bemerkt, als meine Rollos wieder zu zeitig runtergefahren sind. YAAHM kennt nun aber die korrekten Zeiten, holt sich zum Schalten aber immer noch die falschen Zeitangaben.
Ist das denn nur bei mir so?
Gruß
Uwe
Selbstverständlich musst Du den Tagestimer neu starten !
LG
pah
Hatte ich. Gestern abend hat es ja auch funktioniert. Heute morgen war dann die erste Schaltzeit wieder falsch. Ich setz das morgen noch mal neu auf.
Gruß
Uwe
Moin moin,
nachdem heute morgen die selbst erstellten Wochentimer wieder verschwunden waren, habe ich jetzt erst mal alles platt gemacht und wieder neu angelegt. Neues Spiel...
Was mir aufgefallen ist...vielleicht habe ich es auch überlesen...bei den Wochentimern kann ich die Haken bei Ferien und Feiertagen nicht dauerhaft entfernen. Nach dem Neustart der Timer sind die Haken wieder da.
Gruß
Uwe
Ich habe das Device gestern mal angelegt (nur define, sonst nix) und gleich einige Fehlermeldungen im Log:
2017.08.25 11:07:10 1: [YAAHM_updater] on device YAAHM called for this day
2017.08.25 11:07:11 1: PERL WARNING: Argument "Datum 25.08.2017 12" isn't numeric in sprintf at ./FHEM/95_YAAHM.pm line 2087.
2017.08.25 11:07:11 1: PERL WARNING: Argument "Datum 25.08.2017 12:00:00 \nJulianisches Datum 2457990.9..." isn't numeric in array element at ./FHEM/95_YAAHM.pm line 2093.
2017.08.25 11:07:11 1: PERL WARNING: Argument "Datum 26.08.2017 12:00:00 \nJulianisches Datum 2457991.9..." isn't numeric in array element at ./FHEM/95_YAAHM.pm line 2094.
2017.08.25 11:07:11 1: PERL WARNING: Use of uninitialized value $nga in substitution (s///) at ./FHEM/95_YAAHM.pm line 1561.
2017.08.25 11:07:11 1: PERL WARNING: Use of uninitialized value $nga in string eq at ./FHEM/95_YAAHM.pm line 1565.
2017.08.25 11:07:11 1: PERL WARNING: Use of uninitialized value $nga in string eq at ./FHEM/95_YAAHM.pm line 1571.
Ich werde es erstmal wieder deaktivieren.
Hallo Zusammen,
Sehe auch einige Meldungen:
PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/95_YAAHM.pm line 2492.
PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/95_YAAHM.pm line 2526.
PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/95_YAAHM.pm line 2541.
Des weiteren sehe ich, dass nach einem Fhem Reboot sämtliche Commands aus der Übersicht verschwinden.
Das DOIF bleibt in der Config stehen, allerdings lässt sich ohne Aufwand nicht nachvollziehen was eingestellt wurde noch Anpassungen vorzunehmen.
VG
Sooooo....nun läufts. Einmal komplett neu...aber egal. Irgendwo gab's einen Hänger...
Viel interessanter ist, dass ich meine Beobachtung mit dem Verschwinden der Wochentimer verifizieren konnte. Die sind nach einem shutdown wech...und zwar aus der Übersicht der Wochenprofile. In den Readings von YAAHM sind sie noch vorhanden und schalten auch. Wie lange sie da überleben, kann ich nicht sagen. Mal testen...
Gruß
Uwe
Ich habe da noch was...eine in den Wochentimern deaktivierte Schaltzeit mit "off" führt zu dieser Meldung im dazugehörigen DOIF:
timer_01_c02 error: Wrong timespec off: either HH:MM:SS or {perlcode}
Gruß
Uwe
Hallo pah,
ich glaube, ich verstehe was am Ablauf nicht. Die Schaltzeiten für Sunrise und Sunset bleiben auf dem Wert des Tages stehen, an dem ich den Timer gestartet habe (Screenshot). Starte ich den Tages-Timer neu, sind die Zeiten auf dem aktuellen Stand. Aber es ist doch sicher nicht gewünscht, den Tages-Timer täglich neu zu starten...Wenn ich das richtig verstanden habe, soll YAAHM um Mitternacht die Zeiten aktualisieren.
Gruß
Uwe
So sollte es sein, dazu gibt es einen speziellen internen Timer. Bei mir geht das auch problemlos. Kann mich Deines Problems erst wieder in einer Woche annehmen.
LG
pah
Zitat von: Prof. Dr. Peter Henning am 01 September 2017, 17:51:21
Kann mich Deines Problems erst wieder in einer Woche annehmen.
Kein Problem, Danke
Gruß
Uwe
So,
wieder auf Deck.
Wenn YAAHM richtig gestartet wurde, wird automatisch um kurz nach Mitternacht eine Routine gestartet, die das Update der Tagesdaten (eben auch Sonnenauf- und Untergang) durchführt.
Es muss also einen Logeintrag geben, etwa
Zitat2017.09.12 00:00:34 1: [YAAHM_updater] on device YYY called for this day
LG
pah
Hallo pah,
den Logeintrag gibt es nicht. In der ersten Version von YAAHM hat das noch funktioniert, nach dem ersten Update dann nicht mehr. Und das auf zwei FHEM-Installationen.
Kann man denn YAAHM falsch starten?
Gruß
Uwe
Eigentlich nicht, wundert mich.
Versuch mal die angehängte Version 1.03 - da gibt es einen noch undokumentiertes "set initialize", das diesen Timer manuell neu startet.
LG
pah
OK, Danke, ich teste.
Gruß
Uwe
Hall pah,
leider keine Änderung bzw. zumindest diese Logeinträge:
2017.09.14 00:00:33 1: [YAAHM_updater] on device Timer called for this day
2017.09.14 00:00:33 1: PERL WARNING: Argument "Datum 14.09.2017 12:00:00 \nJulianisches Datum 2458010.9..." isn't numeric in array element at ./FHEM/95_YAAHM.pm line 2100.
2017.09.14 00:00:33 1: PERL WARNING: Argument "Datum 15.09.2017 12:00:00 \nJulianisches Datum 2458011.9..." isn't numeric in array element at ./FHEM/95_YAAHM.pm line 2101.
2017.09.14 00:00:33 1: PERL WARNING: Use of uninitialized value $nga in substitution (s///) at ./FHEM/95_YAAHM.pm line 1566.
2017.09.14 00:00:33 1: PERL WARNING: Use of uninitialized value $nga in string eq at ./FHEM/95_YAAHM.pm line 1570.
2017.09.14 00:00:33 1: PERL WARNING: Use of uninitialized value $nga in string eq at ./FHEM/95_YAAHM.pm line 1576.
Letztes manuelles Update auf der einen Maschine am 11.09.:
Gruß
Uwe
Wundert mich nicht wirklich, die Ergänzung ist nämlich funktionslos geblieben... :-[
Hier jetzt die korrekte Fassung
LG
pah
OK, habs eingespielt und werde morgen berichten.
2017.09.14 20:26:51 1: [YAAHM_updater] on device Timer called for this day
2017.09.14 20:26:51 1: PERL WARNING: Argument "Datum 14.09.2017 12:00:00 \nJulianisches Datum 2458010.9..." isn't numeric in array element at ./FHEM/95_YAAHM.pm line 2096.
2017.09.14 20:26:51 1: PERL WARNING: Argument "Datum 15.09.2017 12:00:00 \nJulianisches Datum 2458011.9..." isn't numeric in array element at ./FHEM/95_YAAHM.pm line 2097.
2017.09.14 20:26:51 1: PERL WARNING: Use of uninitialized value $nga in substitution (s///) at ./FHEM/95_YAAHM.pm line 1562.
2017.09.14 20:26:51 1: PERL WARNING: Use of uninitialized value $nga in string eq at ./FHEM/95_YAAHM.pm line 1566.
2017.09.14 20:26:51 1: PERL WARNING: Use of uninitialized value $nga in string eq at ./FHEM/95_YAAHM.pm line 1572.
Gruß
Uwe
Moin,
heute wieder der gleiche Logeintrag
2017.09.14 00:00:33 1: [YAAHM_updater] on device House called for this day
2017.09.14 00:00:33 1: PERL WARNING: Argument "Datum 14.09.2017 12:00:00 \nJulianisches Datum 2458010.9..." isn't numeric in array element at ./FHEM/95_YAAHM.pm line 2100.
2017.09.14 00:00:33 1: PERL WARNING: Argument "Datum 15.09.2017 12:00:00 \nJulianisches Datum 2458011.9..." isn't numeric in array element at ./FHEM/95_YAAHM.pm line 2101.
2017.09.14 00:00:33 1: PERL WARNING: Use of uninitialized value $nga in substitution (s///) at ./FHEM/95_YAAHM.pm line 1566.
2017.09.14 00:00:33 1: PERL WARNING: Use of uninitialized value $nga in string eq at ./FHEM/95_YAAHM.pm line 1570.
2017.09.14 00:00:33 1: PERL WARNING: Use of uninitialized value $nga in string eq at ./FHEM/95_YAAHM.pm line 1576.
aber keine Aktualisierung.
Die Zeiten in der Eventübersicht sind korrekt, im YAAHM-Modul stimmen sie nicht.
Gruß
Uwe
Ich glaubs nicht ganz.
In Zeile 2100 und Zeile 2101 der gestern hier hochgeladenen Datei kommt dieser String gar nicht vor, Zeilen 1570 und 1576 sind Kommentarzeilen.
Ganz sicher, dass das die richtige Datei ist ?
Die Variable $nga wird aus nächsten Weckzeit berechnet. Das kann schiefgehen, wenn die nicht richtig gesetzt wurde. Nachstehende Version hat da eine zusätzliche Sicherheitsabfrage.
Diese Warnungsmeldung kann aber NICHT dazu führen, dass die Zeiten für Sonnenauf- und Untergang inkorrekt sind.
DIe Funktion YAAHM_updater ruft nur YAAHM_GetDayStatus auf - und das geschieht ja ganz korrekt um 00:00:33
In der nachstehenden Version habe ich da drei weitere Logausgaben (temporär) eingebaut.
Bitte einspielen, und GLEICH "set House initialize" ausführen.
LG
pah
OK, mach ich gleich mal.
Aber hier:
Nach dem Einspielen und reload wird folgender Eintrag erzeugt:
2017.09.15 08:54:19 1: [YAAHM_updater] on device House called for this day
An den Zeiten hat sich nichts geändert, daher mal vorsichtshalber einen restart und daraufhin diese Einträge:
2017.09.15 08:56:33 1: [YAAHM_updater] on device House called for this day
2017.09.15 08:56:33 1: PERL WARNING: Argument "Datum 15.09.2017 12" isn't numeric in sprintf at ./FHEM/95_YAAHM.pm line 2090.
2017.09.15 08:56:33 1: PERL WARNING: Argument "Datum 15.09.2017 12:00:00 \nJulianisches Datum 2458011.9..." isn't numeric in array element at ./FHEM/95_YAAHM.pm line 2096.
2017.09.15 08:56:33 1: PERL WARNING: Argument "Datum 16.09.2017 12:00:00 \nJulianisches Datum 2458012.9..." isn't numeric in array element at ./FHEM/95_YAAHM.pm line 2097.
2017.09.15 08:56:33 1: PERL WARNING: Use of uninitialized value $nga in substitution (s///) at ./FHEM/95_YAAHM.pm line 1562.
2017.09.15 08:56:33 1: PERL WARNING: Use of uninitialized value $nga in string eq at ./FHEM/95_YAAHM.pm line 1566.
2017.09.15 08:56:33 1: PERL WARNING: Use of uninitialized value $nga in string eq at ./FHEM/95_YAAHM.pm line 1572.
Bei den Weckzeiten gibt's von Anfang an das Problem, dass selbst erstellte Timer nach einem restart aus der Übersicht verschwinden, im Modul unter "Probably associated with" aber noch existieren.
Gruß
Uwe
Sieh an, sieh an.
Das hat irgendetwas mit den internen Calls von Perl zu tun, mutmaßlich mit dem localtime-Aufruf. Wenn ich YAAHM an der Stelle um 10 Millisekunden bremse, ist das Problem WEG.
Anbei die Version, in der das nicht mehr auftreten sollte.
Betreffend die Timer: Wenn man nach der Definition der eigenen Timer den Befehl "set <YAAHMDevice> save" aufruft, und nach dem Neustart ein "set <YAAHMDevice> restore", ist das Alles wieder da. Hängt damit zusammen, dass die recht komplexe Struktur mit allen YAAHM_Daten nicht in der normalen FHEM-Syve-Datei steht, sondern separat gesichert wird. Leider habe ich noch nicht implementiert, dass YAAHM beim Start auf das Vorhandensein einer solchen Datei schaut und sie automatisch lädt.
LG
pah
OK, ich teste wieder :)
Hallo pah,
irgendwie klappt das noch nicht so ganz. Auf "set ...initialize" bekam ich eben folgende Antwort:
1505545710.49086
s_sunrise und s_sunset sind immer noch auf dem Stand des letzten manuellen Timerstarts (14.09., 18:03).
Im Log um Mitternacht diese Einträge:
2017.09.16 00:00:33 1: [YAAHM_updater] on device House called for this day
2017.09.16 00:00:33 1: PERL WARNING: Argument "Datum 16.09.2017 12:00:00 \nJulianisches Datum 2458012.9..." isn't numeric in array element at ./FHEM/95_YAAHM.pm line 2087.
2017.09.16 00:00:33 1: PERL WARNING: Argument "Datum 17.09.2017 12:00:00 \nJulianisches Datum 2458013.9..." isn't numeric in array element at ./FHEM/95_YAAHM.pm line 2103.
Starte ich den Tages-Timer manuell, werden "s_sunrise", "s_sunset" usw. auf die korrekten Zeiten aktualisiert.
Brauchst Du noch mehr und andere Daten?
Gruß
Uwe
Den da hab ich noch. Das dürfte die Weckzeit "off" für den heutigen Tag sein.
2017.09.16 09:38:06 4: House.wtimer_0.IF timer_01_c02 error: Wrong timespec off: either HH:MM:SS or {perlcode}
OK, der Fehler ist zumindest eingegrenzt: Das Modul verhält sich anders, wenn ein Astro-Device definiert ist, als wenn nur das Astro-Modul dazugeladen wird.
Darum ist es auch in meinem Hauptsystem nicht aufgetreten, sondern nur in einem meiner FHEM-Systeme mit Spezialaufgaben.
Ich bin an der Sache dran.
LG
pah
OK, ich hab schon an mir gezweifelt...
Vorerst habe ich mir mit einem at geholfen, welches um Mitternacht die Funktion "YAAHM_startDayTimer" aufruft.
Gruß
Uwe
Ich habe übrigens die gleichen Probleme, das Astromodul wird bei mir auch von YAAHM nachgeladen...
2017.09.18 22:56:24 1: PERL WARNING: Argument "Datum 18.09.2017 12" isn't numeric in sprintf at ./FHEM/95_YAAHM.pm line 2087.
2017.09.18 22:56:24 1: PERL WARNING: Argument "Datum 18.09.2017 12:00:00 \nJulianisches Datum 2458014.9..." isn't numeric in array element at ./FHEM/95_YAAHM.pm line 2093.
2017.09.18 22:56:24 1: PERL WARNING: Argument "Datum 19.09.2017 12:00:00 \nJulianisches Datum 2458015.9..." isn't numeric in array element at ./FHEM/95_YAAHM.pm line 2094.
2017.09.18 22:56:24 1: PERL WARNING: Use of uninitialized value $nga in substitution (s///) at ./FHEM/95_YAAHM.pm line 1561.
2017.09.18 22:56:24 1: PERL WARNING: Use of uninitialized value $nga in string eq at ./FHEM/95_YAAHM.pm line 1565.
2017.09.18 22:56:24 1: PERL WARNING: Use of uninitialized value $nga in string eq at ./FHEM/95_YAAHM.pm line 1571.
Das scheint bei meiner kleinen Testanwendung aber keine Rolle zu spielen.
VG Guido
Hallo pah,
eine Sache noch...an einer Stelle stehe ich völlig auf dem Schlauch und komme da ohne konkretes Beispiel nicht weiter.
Auszug aus dem Wiki:
ZitatholidayDevices, vacationDevices und specialDevices sind attribute, die jeweils eine kommagetrennte Liste von FHEM-Devices enthalten. Diese dürfen vom Typ holiday oder vom Typ calendar sein.
holidayDevices enthält die Liste der Feiertage (=höchste Tagespriorität)
vacationDevices enthält die Liste der Schulferien (=dritthöchste Tagespriorität)
specialDevices enthält eine Liste von Einzelterminen (z.B. der Müllabfuhr)
Was ist Typ holiday und Typ calendar? Muss man für die Feiertage und die Müllabfuhr eine extra Liste anlegen? Die schon vorhandenen Module/Dateien ABFALL und ...holiday können nicht verwendet werden?
Oder ist das alles ganz anders und ich hab Watte im Kopf?
Gruß
Uwe
"holiday" und "calendar" sind FHEM-Devices, diese geifen jeweils auf die entsprechenden Dateien zu. "calendar" verlangt Dateien im ical-Format, "holiday" hat eine vom Entwickler selbst erfundene Textnotation
"ABFALL" ist nicht in der Distribution, insofern habe ich keinen Anlass gehabt, das auch einzubinden.
YAAHM greift also nicht auf die Dateien mit den Terminen zu - sondern auf existierende Devices, die wiederum diese Dateien laden.
LG
pah
Halllo Uwe,
zu
Zitat
Was ist Typ holiday und Typ calendar? Muss man für die Feiertage und die Müllabfuhr eine extra Liste anlegen? Die schon vorhandenen Module/Dateien ABFALL und ...holiday können nicht verwendet werden?
Oder ist das alles ganz anders und ich hab Watte im Kopf?
Da ich diese Rollladensteuerung verwende https://forum.fhem.de/index.php/topic,73964.0.html (https://forum.fhem.de/index.php/topic,73964.0.html) habe ich die Dummies für Ferien und Feiertage wiederverwendet.
Viele Grüße
Guido
@pah: Danke, das macht es klarer. Damit komme ich weiter.
@fettgu: Mit Dummies habe ich zwischenzeitlich auch schon experimentiert. Mal sehen, ob ich das weiter verfolge.
Danke Euch für die Tipps und Hinweise.
Gruß
Uwe
So, das Problem ist gelöst - Readings und Zeiten werden jetzt korrekt aktualisiert.
Neue Version 1.07 ist eingecheckt. ACHTUNG: auch das File yaahm.js hat eine kleine Änderung erfahren, muss unbedingt mit installiert werden.
LG
pah
Guten Morgen, bin gerade mit großer Freude auf YAAHM gestossen, weil ich den Eindruck habe, dass ich mit diesem Modul das eine oder andere zentral und vereinfacht machen kann.
Eine Frage / Bitte / Vorschlag hätte ich aber noch. Ich verwende zur "Aktivierung" von bewegungsgesteuertem Einschalten von Licht das Modul Twilight, das ja neben den diversen Arten von Sonnenauf- und untergang auch eine Berücksichtigung der Wetterlage und damit der Sonneneinstrahlung in Abhängigkeit der Bewölkung beinhaltet. Das funktioniert so gut, dass in dem Augenblick in dem ich das Licht anschalten würde, dieses von alleine angeht. Könnte der wetterabhängige Sonnenauf- und untergang vielleicht auch noch implementiert werden?
Zitat von: Prof. Dr. Peter Henning am 20 September 2017, 07:25:25
So, das Problem ist gelöst - Readings und Zeiten werden jetzt korrekt aktualisiert.
Danke, wird getestet.
Gruß
Uwe
Jein.
Die Idee, einen abweichenden Horizontwinkel für Auf- und Untergang einzusetzen, ist leicht umsetzbar. Allerdings zunächst einmal im Modul 95_Astro.pm Erst danach könnte ich das in YAAHM einbauen - bin mir aber noch nicht sicher, ob ich das möchte.
Vor allem aber will ich mich aus prinzipiellen Gründen nicht an Yahoo Weather binden - eher schon an einen Messwert.
LG
pah
Moin Moin,
diesmal kann ich mit positiven Nachrichten kommen. Läuft.
War aber auch gestern schon daran erkennbar, dass ein "set initialize" die Zeiten korrekt aktualisiert hat. Das war ja vorher nicht so.
Danke und Gruß
Uwe
Guten Abend,
ich habe eine Frage zur Funktion: ich konnte die Readings t_aftersunset und s_aftersunset meines YAAHM devices per setreading aktualisieren und der Funktionsbaustein wird auch aufgerufen und abgearbeitet.
Leider zeigt die Oberfläche immer noch den Standardoffset an - ignoriert also die Aktualisierung.
Wie kann ich das anpassen?
Viele Grüße
Guido Fett
Hallo,
leider aktualisiert sich das reading daytime nicht mehr.
In den Logs erhalte ich nach jedem FHEM restart folgendes:
2017.10.21 20:54:42 3: [YAAHM_WINTERFELL V1.09] Weblink YAAHM_WINTERFELL_weblink created
2017.10.21 20:54:42 3: [YAAHM_WINTERFELL V1.09] Weblink YAAHM_WINTERFELL_shortlink created
2017.10.21 20:54:42 3: [YAAHM_WINTERFELL V1.09] Added hidden room 'ProfileRoom' to WEB_10.10.20.101_58865
2017.10.21 20:54:45 1: [YAAHM_updater] on device YAAHM_WINTERFELL called for this day
2017.10.21 20:54:45 1: PERL WARNING: Argument "Date 21.10.2017 12" isn't numeric in sprintf at ./FHEM/95_YAAHM.pm line 2155.
2017.10.21 20:54:45 1: PERL WARNING: Use of uninitialized value in string comparison (cmp) at ./FHEM/95_YAAHM.pm line 247.
2017.10.21 20:59:55 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/95_YAAHM.pm line 2544.
2017.10.21 20:59:55 3: eval: {YAAHM_Longtable("YAAHM_WINTERFELL")}
2017.10.21 20:59:55 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/95_YAAHM.pm line 2595.
2017.10.21 20:59:55 3: eval: {YAAHM_Longtable("YAAHM_WINTERFELL")}
Hat da jemand eine Idee?
Viele Grüße
Ersteres wundert mich nicht - ein Reading "daytime" gibt es nämlich gar nicht. ::)
Die Fehlermeldung kommt nur bei Neustart, weil das Astro-Modul noch nicht richtig initialisiert ist. Ist in der aktuell eingecheckten Version 1.10 behoben.
Diese Version enthält auch eine Korrektur für den Bug in der SVG-Engine von Firefox, die zu einer verzerrten Darstellung im Time Widget führte.
LG
pah
Danke, sorry für die Verwirrung.
Besteht die Möglichkeit, dass YAAHM nach einem Fhem Restart, die hinterlegten Befehle wieder beim Profil anzeigt? Nach jedem Reboot verliert die Profilanzeige die Action Befehle.
Viele Grüße
Dafür gibt es die Befehle "save" und "restore". Das funktioniert derzeit noch nicht automatisch.
LG
pah
Hallo zusammen,
mache gerade die ersten Gehversuche mit dem Modul, weil ich den Ansatz, alles zentral in einem Modul zu automatisieren, sehr gut finde. Nach dem heutigen Update, habe ich folgende Fehlermeldung im Log:
PERL WARNING: Use of uninitialized value in string comparison (cmp) at ./FHEM/95_YAAHM.pm line 247.
Des weiteren würde mich interessieren, mit welchem Browser bzw. welchem fhem style Ihr z.B. die Profilseite anzeigt? Ich nutze Chrome und ios6 als Style. Habe aber auch die anderen schon ausprobiert und bei keiner gefällt mir die Profilseite wirklich gut. So sind z.B. bei den Wochenprofilen die Checkboxen versetzt.
Beste Grüße
Torsten
Ich habe gestern abend eine neue Version eingecheckt, mit deutlicher Komfortsteigerung bei der Anzeige der Weckzeiten und der Möglichkeit, die nächste Weckzeit in einem für Sprachausgabe geeigneten Format zu erhalten.
Außerdem einem neuen Hausmode donotdisturb
LG
pah
Prima, wird getestet.
Danke
Den neuen Housemode finde ich gut... :D
Gruß
Uwe
Hallo,
bei get YYY template gab es ein fehlerhaftes Template mit einigen Syntax-Fehler. Hier die bereinigte Version:
sub HouseTimeHelper(@){
my ($event,$param1,$param2) = @_;
Log 1,"[HouseTimeHelper] event=$event";
my $time = ReadingsVal("Wochenplaner","housetime","");
my $phase = ReadingsVal("Wochenplaner","housephase","");
my $state = ReadingsVal("Wochenplaner","housestate","");
my $party = (ReadingsVal("Wochenplaner","housemode","") eq "party") ? 1 : 0;
my $absence = (ReadingsVal("Wochenplaner","housemode","") eq "absence") ? 1 : 0;
my $todaytype = ReadingsVal("Wochenplaner","tr_todayType","");
my $todaydesc = ReadingsVal("Wochenplaner","todayDesc","");
my $tomorrowtype = ReadingsVal("Wochenplaner","tr_tomorrowType","");
my $tomorrowdesc = ReadingsVal("Wochenplaner","tomorrowDesc","");
if( $event eq "aftermidnight" ){
#---------------------------------------------------------------------
}elsif( $event eq "sunset" ){
#---------------------------------------------------------------------
}elsif( $event eq "beforesunrise" ){
#---------------------------------------------------------------------
}elsif( $event eq "beforesunset" ){
#---------------------------------------------------------------------
}elsif( $event eq "aftersunrise" ){
#---------------------------------------------------------------------
}elsif( $event eq "beforemidnight" ){
#---------------------------------------------------------------------
}elsif( $event eq "midnight" ){
#---------------------------------------------------------------------
}elsif( $event eq "aftersunset" ){
#---------------------------------------------------------------------
}elsif( $event eq "sunrise" ){
#---------------------------------------------------------------------
}elsif( $event eq "wakeup" ){
#---------------------------------------------------------------------
}elsif( $event eq "morning" ){
#---------------------------------------------------------------------
}elsif( $event eq "noon" ){
#---------------------------------------------------------------------
}elsif( $event eq "afternoon" ){
#---------------------------------------------------------------------
}elsif( $event eq "evening" ){
#---------------------------------------------------------------------
}elsif( $event eq "night" ){
#---------------------------------------------------------------------
}elsif( $event eq "sleep" ){
}
}
sub HouseStateHelper(@){
my ($event,$param1,$param2) = @_;
Log 1,"[HouseStateHelper] event=$event";
my $time = ReadingsVal("Wochenplaner","housetime","");
my $phase = ReadingsVal("Wochenplaner","housephase","");
my $state = ReadingsVal("Wochenplaner","housestate","");
my $party = (ReadingsVal("Wochenplaner","housemode","") eq "party") ? 1 : 0;
my $absence = (ReadingsVal("Wochenplaner","housemode","") eq "absence") ? 1 : 0;
#---------------------------------------------------------------------
if( $event eq "unsecured" ){
#---------------------------------------------------------------------
}elsif( $event eq "secured" ){
#---------------------------------------------------------------------
}elsif( $event eq "protected" ){
#---------------------------------------------------------------------
}elsif( $event eq "guarded" ){
}
}
Bitte künftig besser einfach mitteilen, wo die Syntaxfehler sind.
Ist behoben und bei einem der nächsten Updates dabei.
LG
pah
Bekommen eine Fehlermeldung seit dem Update heute:
2017.11.12 12:30:22 1: [YAAHM_Define] data hash restored from save file with date Sun Nov 12 12:30:22 2017
2017.11.12 12:30:22 1: [YAAHM] finds 1 Astro devices, module not loaded separately
2017-11-12_12:30:22 global DEFINED Wochenplaner
Can't use an undefined value as an ARRAY reference at ./FHEM/95_YAAHM.pm line 863.
Bitte genauer mit get..version.
"Seit dem heuitigen Update" ist nichts, mit dem ich etwas anfangen kann.
Außerdem kann das sicher nicht beim Start kommen, sondern nur bei einem fehlerhaften get-Befehl.
LG
pah
Der Fehler kam nach dem heutigen Update nachdem ich mein YAAHM Device (Version 1.16) neu angelegt hatte.
Die Fehlermeldung hing wahrscheinlich mit der Datei YAAHMFILE (Größe: 1 Byte) zusammen. Die wahrscheinich meinen Versuchen mit der Version 1.15 übrig geblieben ist.
Nach dem ich diese Datei löschte startete FHEM auch wieder.
Hallo,
auf meinem Host
Linux opi 3.4.113-sun8i #18 SMP PREEMPT Thu Jun 15 02:16:06 CEST 2017 armv7l GNU/Linux
funktioniert das speichern der Konfiguration mit dem save Befehl nicht. Es wird immer nur eine ein Byte große YAAHMFILE Datei angelegt. Nach einem FHEM neustart crashed FHEM dann weil der automatische Restore aus der Datei nicht funktioniert.
Selbst mit verbose 5 wird bei speichern kein Fehler angezeigt.
Ich habe gerade alle Perl-Module auf dem Host aktualisiert. Hat keine Verbeserung gebracht.
Ludger
Bitte im Unterprogramm YAAHM_save das Kommentarzeichen vor dem Log-befehl entfernen
sub YAAHM_save($) {
my ($hash) = @_;
$hash->{DATA}{"savedate"} = localtime(time);
readingsSingleUpdate( $hash, "savedate", $hash->{DATA}{"savedate"}, 1 );
my $json = JSON->new->utf8;
my $jhash0 = eval{ $json->encode( $hash->{DATA} ) };
my $error = FileWrite("YAAHMFILE",$jhash0);
Log 1,"[YAAHM_save] error=$error";
return;
}
LG
pah
Ich war so frei und habe noch ein weiteres Log eingefügt. Also dieser Programabschnitt erzeugt untenstehendes Log.
Prog:
sub YAAHM_save($) {
my ($hash) = @_;
$hash->{DATA}{"savedate"} = localtime(time);
readingsSingleUpdate( $hash, "savedate", $hash->{DATA}{"savedate"}, 1 );
my $json = JSON->new->utf8;
Log 1,"[YAAHM_json] json=$json";
my $jhash0 = eval{ $json->encode( $hash->{DATA} ) };
my $error = FileWrite("YAAHMFILE",$jhash0);
Log 1,"[YAAHM_save] error=$error";
return;
}
Logs:
2017.11.15 16:38:48 1: [YAAHM_json] json=JSON=SCALAR(0x80bf730)
2017.11.15 16:38:48 1: PERL WARNING: Use of uninitialized value $error in concatenation (.) or string at ./FHEM/95_YAAHM.pm line 886.
2017.11.15 16:38:48 1: [YAAHM_save] error=
Ist der eval Befehl überhaupt notwendig?
1. Der erste "ich bin so frei" Log-Befehl wird natürlich nur Müll liefern, $json ist kein Text.
2. Dass $error keinen Wert hat, ist auch ok - es liegt eben kein Fehler beim Schreiben vor.
3. Der Fehler passiert im Aufruf der "encode"-Methode. Und aus genau dem Grund braucht es die eval{}-Klammer.
Ich tippe mal auf ein nicht ordnungsgemäß installiertes JSON-Modul.
LG
pah
Ich bin ein wenig überwältigt von den verschiedenen Möglichkeiten der Automatisierung, neben dem HOMEMODE Modul schaue ich mir deshalb auch YAAHM an.
Beim installieren "auf der grünen Wiese" bekam ich mit der Version 1.17 gleich folgende Fehlermeldung
define AutoHome YAAHM
--- snip ---
2017.11.18 11:39:49 1: PERL WARNING: Subroutine YAAHM_restore redefined at ./FHEM/95_YAAHM.pm line 897.
2017.11.18 11:39:49 1: PERL WARNING: Subroutine YAAHM_sayWeeklyTime redefined at ./FHEM/95_YAAHM.pm line 1771.
2017.11.18 11:39:50 1: [YAAHM_restore] read error=Can't open YAAHMFILE: No such file or directory
2017.11.18 11:39:50 1: [YAAHM_Define] data hash is initialized
2017.11.18 11:39:50 1: [YAAHM] does not find an Astro device, loading module Astro separately
2017.11.18 11:39:50 1: PERL WARNING: "my" variable $radius masks earlier declaration in same scope at FHEM/95_Astro.pm line 1223.
2017.11.18 11:39:50 1: PERL WARNING: "my" variable $axis masks earlier declaration in same scope at FHEM/95_Astro.pm line 1224.
2017.11.18 11:39:58 1: [YAAHM_updater] on device AutoHome called for this day
2017.11.18 11:39:58 1: [YAAHM_sun] Error, no proper sunrise today return from Astro module in 5 attempts
2017.11.18 11:39:58 1: PERL WARNING: Argument "[Astro_Get] AutoHome has improper time specification, us..." isn't numeric in sprintf at ./FHEM/95_YAAHM.pm line 2437.
2017.11.18 11:39:58 1: PERL WARNING: Argument "MM" isn't numeric in sprintf at ./FHEM/95_YAAHM.pm line 2437.
2017.11.18 11:39:58 1: PERL WARNING: Argument "[Astro_Get] AutoHome has improper time specification, us..." isn't numeric in array or hash lookup at ./FHEM/95_YAAHM.pm line 2440.
2017.11.18 11:39:58 1: [YAAHM_sun] Error, no proper sunrise tomorrow return from Astro module in 5 attempts
2017.11.18 11:39:58 1: PERL WARNING: Argument "[Astro_Get] AutoHome has improper time specification, us..." isn't numeric in sprintf at ./FHEM/95_YAAHM.pm line 2461.
2017.11.18 11:39:58 1: PERL WARNING: Argument "MM" isn't numeric in sprintf at ./FHEM/95_YAAHM.pm line 2461.
2017.11.18 11:39:58 1: PERL WARNING: Argument "[Astro_Get] AutoHome has improper time specification, us..." isn't numeric in array or hash lookup at ./FHEM/95_YAAHM.pm line 2464.
2017.11.18 11:39:58 1: PERL WARNING: Use of uninitialized value in string comparison (cmp) at ./FHEM/95_YAAHM.pm line 259.
2017.11.18 11:39:58 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/95_YAAHM.pm line 1650.
2017.11.18 11:39:58 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/95_YAAHM.pm line 1669.
2017.11.18 11:39:59 1: PERL WARNING: Use of uninitialized value $ton in pattern match (m//) at ./FHEM/95_YAAHM.pm line 1796.
Undefined subroutine &main::tolower called at ./FHEM/95_YAAHM.pm line 1812.
Zunächst beendet sich FHEM wegen der fehlenden Routine "tolower", was ich über ein Ersetzen beheben konnte:
perl -pi -e 's/tolower/lc/g' FHEM/95_YAAHM.pm
Dann scheint aber auch die Abhängigkeit zu einem Astro-Modul zu fehlen... Mein Sonnenuntergang ist momentan um 23:00 (für Berlin Mitte November!!!). Die global Koordinaten sind richtig gesetzt - ich benutze für meine Notifys schon eine Weile isday("REAL").
Bin gespannt, was diese vielversprechende Modul so alles kann...
Alex
Das interessiert mich nun doch. Was für ein Betriebssystem ist das ?
1. "tolower" sollte nämlich eigentlich vorhanden sein - das kann ich aber problemlos durch lc ersetzen.
2. Das Modul 95_Astro.pm liegt normalen FHEM-Ordner wird beim Update mit verteilt - und wird hier auch korrekt dazugeladen. Aber irgendetwas stört die Zeitaufrufe, kann ebenfalls durch eine noch nicht komplett behobene Betriebssystemabhängigkeit hervorgerufen werden.
Bitte die beiden anliegenden Module für einen Test verwenden.
LG
pah
OK, ich konnte die Fehler jetzt auf die Benutzung der POSIX Funktionen (tolower, strftime) zurückführen.
FHEM läuft unter uClibc-0.9.33 auf einem MIPS 34Kc (Fritz!Box 7490) mit Perl-5.26.1.
Ich bitte den unqualifizierten Beitrag zu entschuldigen und recherchiere mal ein wenig zu Perl, POSIX und cross-kompilieren.
Alex
Sag ich doch, Betriebssystemfrage...
Was liefert jeweils der Aufruf (geht in der FHEM-Commandline):
{strftime('%H:%M', localtime(time)))}
{strftime('%2m-%2d', localtime(time))}
{strftime('%2d.%2m.%2Y', localtime(time))}
{strftime('%w', localtime(time))}
{strftime('%u', localtime(time))}
{strftime('%4Y-%2m-%2d', localtime(time))}
LG
pah
Hmm merkwürdig... offensichtlich werden nur die Präfix-Formate (2Y, 4Y) nicht unterstützt:
{strftime('%H:%M', localtime(time))} - 16:39
{strftime('%2m-%2d', localtime(time))} - %2m-%2d
{strftime('%2d.%2m.%2Y', localtime(time))} - %2d.%2m.%2Y
{strftime('%w', localtime(time))} - 6
{strftime('%u', localtime(time))} - 6
{strftime('%4Y-%2m-%2d', localtime(time))} - %4Y-%2m-%2d
1. Gibt es dafür irgendeine Übersichtsdoku ? Ich habe wenig Lust, das per Trial and Error herauszufinden.
LG
pah
hmm, ich finde gerade keine Definition mit vorangestellten Zahlen...
http://man7.org/linux/man-pages/man3/strftime.3.html
Alex
>:( >:(
Ich will keinen Link auf eine allgemeine Linux-Doku, die kenne ich auswendig.
Sondern eine Zusammenfassung der strftime-Funktion in der uClibc-0.9.33 - so wie hier z.B. für Windows:http://www.perlmonks.org/?node_id=434177
Sonst werde ich keinen Workaround bauen, die Zeit habe ich nicht.
pah
Weiter oben habe ich mein Problem mit dem restore der YAAHMFILE beschrieben. Ursache ist scheinbar meine Perl-Installation. Trotzdem wäre es schön wenn es eine Plausikontrolle vor dem Import (Größe über 100 Byte o.ä.) oder eine inhaltliche Kontrolle nach dem Import der Datei stattfinden könnte.
Danke
Sicher.
pah
Zitat von: Prof. Dr. Peter Henning am 19 November 2017, 04:35:54
>:( >:(
Ich will keinen Link auf eine allgemeine Linux-Doku, die kenne ich auswendig.
Sondern eine Zusammenfassung der strftime-Funktion in der uClibc-0.9.33 - so wie hier z.B. für Windows:http://www.perlmonks.org/?node_id=434177
Sehr geehrter pah,
ich wollte damit eigentlich nur darauf hinweisen, dass ein Zahlen-Präfix vor den Platzhaltern nicht spezifiziert (falsch?!) ist.
Eine GLIBC2.x die Zahl ignoriert diese Angabe, die uClib ist wohl nicht so gnädig...
Korrekt müsste es so lauten:
%4Y => %Y
%2Y => %y
Alex
Hallo Peter,
habe dieses Modul im Einsatz, die geplanten Wochen/Tagesprofil funktioniert soweit, habe noch weitere Readings zugefügt (Resident-Status, Helligkeit/Dunkelheit - Status für Beleuchtung). Das nächste wird noch das Einbinden der Kalender werden.
Bin aber über folgendes gestolpert und konnte mir nicht weiterhelfen, da ich die Funktion der Abläufe / Statusübergänge noch nicht ganz verstandenhabe:
- Ich möchte den Status "sleep" verschieben, wenn z.b. der Fernseher noch läuft. Wie kann man so etwas lösen?
Grüße Peter
Das steht doch in der Commandref unter set manualnext.
pah
Hallo,
zunächst einmal vielen dank für das tolle Modul welches nun nach und nach auch bei mir Einsatz findet.
Ein paar Sachen sind mir jedoch aufgefallen:
- Die Simulation funktioniert (bei mir?) nicht. Trotz gesetzem Attribut "simulation" werden die Kommandos in den Aktionsfeldern ausgeführt.
- wenn ich die Auswahlfelder der Wochentimer einstelle (siehe Bild yaahm1) und die Wochentimer neu starte dann wird anschließend wieder die Auswahl wie im Bild yaahm2 zu sehen angezeigt. Die DOIF-Timer wurden aber korrekt eingestellt (siehe Bild yaahm3)
- Einträge aus meinem Google-Kalender welcher mit dem Calendar-Device ausgelesen werden werden nicht im YAAHM-Modul (in specialDevices eingetragen) angezeigt. In welchem "Format" müssen Termine im Kalender vorliegen damit YAAHM sie erkennt (ganztägig, spezielle Uhrzeit, Eintrag...)
Das war es erst einmal.
Beste Grüße
Manuel
Zu 1: Kein Bug, sondern ein Feature. "Simulation" wirkt nur auf die "Set ..." Kommandos direkt am Device, nicht auf die Button-Klicks von der interaktiven Oberfläche. Ich habe die Commandref an dieser Stelle etwas präzisiert.
Zu 2: Kann ich nicht nachvollziehen, ist bei mir nicht so.
Zu 3: Kein spezielles Format - möglicherweise liefert das Calendar-Device etwas Seltsames aus dem Google-Calendar. Muss ich überprüfen, kann aber ein paar Wochen dauern.
LG
pah
Hallo pha,
vielen Dank für die schnelle Antwort.
zu 1.: das erklärt es dann ;-)
zu 2.: UweH hatte auch schon mal sowas beobachtet https://forum.fhem.de/index.php/topic,75206.msg676534.html#msg676534 (https://forum.fhem.de/index.php/topic,75206.msg676534.html#msg676534) evtl hat er eine Lösung gefunden
zu 3.: sowas in der Art dachte ich auch, ich forsche in diese Richtung auch mal weiter.
Danke
Gruß
Manuel
Hallo,
ich glaube ich habe das Problem mit den Kalender-Einträgen gefunden zu haben.
{strftime('%2d.%2m.%2Y', localtime(time))}
liefert mir: 25.11.2017
Ich habe mir erlaubt im Yaahm-Modul ein paar Logeinträge zu ergänzen und dabei kam folgendes raus:
2017.11.25 19:10:24 5: [YAAHM] found Calendar-Device
2017.11.25 19:10:24 5: [YAAHM] found Calendar-Device line: 25.11.17 00:00 TestUrlaub 26.11.17 00:00 TestUrlaub2
2017.11.25 19:10:24 5: [YAAHM] found Calendar-Device date: 25.11.17
2017.11.25 19:10:24 5: [YAAHM] found Calendar-Device date today: 25.11.2017
2017.11.25 19:10:24 5: [YAAHM] found Calendar-Device date: 26.11.17
2017.11.25 19:10:24 5: [YAAHM] found Calendar-Device date today: 25.11.2017
Der anschließende Vergleich ob das ausgelesene Datum dem heutigen entspricht fällt deshalb immer durch. Es wird somit kein Eintrag im Yaahm-Device erzeugt.
Ich habe schon über das Problem mit der Jahreszahl gelesen.
Konnte diesbezüglich schon mehr in Erfahrung gebracht werden?
zur Info, ein:
{strftime('%d.%m.%y', localtime(time))}
liefert bei mir das gewünschte Datumsformat.
Gruß
Manuel
Betriebssystem, welche Version ?
LG
pah
Zitat von: MaMi7880 am 25 November 2017, 16:44:35
Hallo,
zunächst einmal vielen dank für das tolle Modul welches nun nach und nach auch bei mir Einsatz findet.
Ein paar Sachen sind mir jedoch aufgefallen:
- Die Simulation funktioniert (bei mir?) nicht. Trotz gesetzem Attribut "simulation" werden die Kommandos in den Aktionsfeldern ausgeführt.
- wenn ich die Auswahlfelder der Wochentimer einstelle (siehe Bild yaahm1) und die Wochentimer neu starte dann wird anschließend wieder die Auswahl wie im Bild yaahm2 zu sehen angezeigt. Die DOIF-Timer wurden aber korrekt eingestellt (siehe Bild yaahm3)
- Einträge aus meinem Google-Kalender welcher mit dem Calendar-Device ausgelesen werden werden nicht im YAAHM-Modul (in specialDevices eingetragen) angezeigt. In welchem "Format" müssen Termine im Kalender vorliegen damit YAAHM sie erkennt (ganztägig, spezielle Uhrzeit, Eintrag...)
Das war es erst einmal.
Beste Grüße
Manuel
Nochmal ich,
ich glaube den Fehler für den zweiten Punkt gefunden zu haben. Wenn ich die Zeile 3186
$acc = $profday[$i];
in
$acc = $profday[$j];
ändere ($i nach $j) , funktioniert es.
Gruß
Manuel
Ah, das hatte ich nur mit profmode ausprobiert. Ist tatsächlich ein Tippfehler gewesen. Ist gefixt und eingecheckt.
Das Problem mit dem Google-Kalender habe ich ebenfalls gefixt - die liefern zwei chunks weniger.
LG
pah
Hallo Peter,
Folgende Voraussetzung ist gegeben: Die Schlafenszeit ist auf 22:00 eingestellt.
Wenn der TV läuft, soll sich automatisch die Schlafenszeit verlängern und erst wenn der TV ausgeschalten wird, dann nach z.b. 10min in den Sleep-Mode wechseln.
Es ist richtig, dass mit dem Befehl
set xy manualnext 1 23:00
das Reading next_1 verändern werden kann. Damit
hat man folgende Nachteile:
1) Die Zeit bleibt eingetragen für den kommenden Tag. Besser wäre, dass die Zeit nur temporär gehalten wird und nach dem Verschieben dann wieder den voreingestellten Wert bekommt.
2) Aus Punkt 1) resultiert, dass a) die geplante Zeit zwischen gespeichert werden muss und nur nach dem Ausschalten des TV's dann dem next_1 wieder zugewiesen werden muss. b) wird der TV abgeschalten muss neu errechnete Zeit dem wieder über manualnext incl. Mehrminuten zugewiesen werden
3) Der housetime steht auf sleep und stellt sich nicht auf vorigen Wert, wenn die Zeit verschoben wird. Damit kann dieser Wert nicht als Status für andere Aktionen verwendet werden.
Besser wäre solche Abhängigkeiten bereits im Modul zu unterstützen:
z.b. so etwas: Event sleep erst dann auslösen, wenn [TV-Status=off][...],
Zusätzliches Attribut: sleep-Verzögerung = 10min.
Ähnliches würde mir auch z.b. für die Beleuchtung nützlich sein:
Ich habe verschiedene on-for-timer Werte in Abhängigkeit der housetime eingestellt. z.b.
früh, werktag soll das Flurlicht 15min eingeschalten bleiben, wegen Anziehen
abends, täglich nur 90sec zwecks Durchgehen
früh, WE nur 30sec zwecks Durchgehen - da ist man noch im Schlafmodus ;)
Grüße Peter
ZitatBesser wäre
Prima. Es steht jedem frei, sein eigenes Modul zu schreiben.
pah
Zitat von: Prof. Dr. Peter Henning am 26 November 2017, 05:05:59
Ah, das hatte ich nur mit profmode ausprobiert. Ist tatsächlich ein Tippfehler gewesen. Ist gefixt und eingecheckt.
Das Problem mit dem Google-Kalender habe ich ebenfalls gefixt - die liefern zwei chunks weniger.
LG
pah
Super, vielen lieben Dank und schönen Sonntag noch
BG
Manuel
Hallo,
nach eine paar Tagen ausführlichen Tests ist mir noch folgendes aufgefallen:
- trägt man eine manuelle Weckzeit für den nächsten Tag ein (im Bild z.B. 8:00 Uhr für den Timer "Wecken" und ist der Timer für den aktuellen Tag "off" dann wir in der letzen Spalte "8:00 heute" statt "8:00 morgen" angezeigt (siehe im Bild gelbe Markierung).
Beste Grüße
Manuel
Edit: Version 1.21
Habe ich gerade heute auch festgestellt und 19:52 gefixt und eingecheckt. War nur ein Fehler in der Anzeige.
LG
pah
Hallo zusammen,
mal ne kurze Frage:
Ich habe das Widget im FHEMweb gegen das Bildchen getauscht, besteht die Möglichkeit das Widget automatisch zu aktualisieren, so dass die Uhrzeit immer aktuell dargestellt wird?
Danke für Euer Feedback.
Sicher. Ungefähr 8 Stunden Arbeit, das zu realisieren. Derzeit im Plan für 2031 - mache ich gegen Honorar gerne sofort.
LG
pah
Zitat von: Prof. Dr. Peter Henning am 03 Dezember 2017, 05:41:49
Habe ich gerade heute auch festgestellt und 19:52 gefixt und eingecheckt. War nur ein Fehler in der Anzeige.
LG
pah
Vielen Dank...
Zitat von: Prof. Dr. Peter Henning am 03 Dezember 2017, 16:01:08
Sicher. Ungefähr 8 Stunden Arbeit, das zu realisieren. Derzeit im Plan für 2031 - mache ich gegen Honorar gerne sofort.
LG
pah
web refresh tuts auch, danke
Das ist aber etwas Anderes, als ein animiertes Widget ::)
LG
pah
Neue Version, mit diversen Fixes und animierten Widgets für Housemode und Housestate
LG
pah
Hallo pah,
ich habe auch nach dem Update noch den Effekt, dass die Offsets für Aftersunrise etc. trotz "save" und "restore" nicht aktuell sind. Werden die Offsets nicht mit gespeichert?
Gruß
Uwe
Doch, eigentlich sollten sie das.
LG
pah
Wo wird YAAHMFILE gespeichert? Entweder finde ich es nicht oder es wird nicht angelegt.
Noch was anderes: Ich habe mal zwei neue WeeklyTimer angelegt, beim Klick auf "Profile" in der Menüleiste bekomme ich die Meldung aus dem ersten Screenshot (WeeklyTimer).
Nach dem Bearbeiten der Wochentimer und "Start Wochen-Timer" dann die andere Meldung.
Version von YAAHM ist 1.31, yaahm.js ist 1.30
Nach ein paar Minuten bekomme ich dann auch noch die dritte Meldung "blinking" zu sehen...
Brauchst Du noch Infos?
Gruß
Uwe
EDIT: Sobald ich die Timer wieder lösche, sind die Meldungen auch weg...
1. Wenn Du configdb verwendest, wir YAAHMfile in der Datenbank gespeichert.
2. Habe den Fehler gefunden, es fehlte ein Backslash im dynamisch erzeugten Javascript. Ist eingescheckt, zusätzlich aktuelle Version anbei.
LG
pah
Guten morgen,
was kann ich gegen diese Logeinträge unternehmen?:
2017.12.11 08:54:03 1: [YAAHM_updater] on device YAAHM called for this day
2017.12.11 08:54:03 1: PERL WARNING: Use of uninitialized value in string comparison (cmp) at ./FHEM/95_YAAHM.pm line 265.
2017.12.11 08:54:03 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/95_YAAHM.pm line 1715.
2017.12.11 08:54:03 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/95_YAAHM.pm line 1734.
Danke schon mal im Voraus und viele Grüße.
Nun, z.B. sie zu löschen ?
LG
pah
Zitat von: Prof. Dr. Peter Henning am 10 Dezember 2017, 19:40:02
1. Wenn Du configdb verwendest, wir YAAHMfile in der Datenbank gespeichert.
So ist es, Danke
Zitat2. Habe den Fehler gefunden, es fehlte ein Backslash im dynamisch erzeugten Javascript. Ist eingescheckt, zusätzlich aktuelle Version anbei
Läuft :)
Danke und Gruß
Uwe
Guten Morgen,
ich habe auch das Problem, dass das Tagesprofil inklusive Offsets nach dem Neustart leer ist. Ich habe also heute morgen ein Update gemacht, anschließend das Tagesprofil neu angelegt und gespeichert. Nach einem erneuten Neustart war wieder alles weg :-(
Sollte der Fehler nicht behoben sein? Ich nutze ebenfalls configdb
Vielen Dank
Ronny
Sorry, aber ich kann es nicht nachvollziehen. Habe eben genau dasselbe gemacht, und bei mir tritt das nicht auf. Im Übrigen kann man sich auch bei Verwendung der configdb die von YAAHm gespeicherten Daten jederzeit ansehen, indem man in die FHEM-Kommandozeile eingibt: {(FileRead("YAAHMFILE"))[1]}
LG
pah
Hallo,
mit
{(FileRead("YAAHMFILE"))[1]}
passiert bei mir gar nichts, sprich er springt wieder auf die Startseite von FHEM.
Ronny
Hmm...
Und wenn man nacheinander
{FileWrite("TESTFILE","abcdef")}
und
{(FileRead("TESTFILE"))[1]}
eingibt ? Beim zweiten Mal sollte dann "abcdef" als Antwort kommen.
LG
pah
Ja, das funktioniert.
Gesendet von meinem SM-G935F mit Tapatalk
Das verstehe ich nicht, denn der Save-Befehl erzeugt eben ein nicht-leeres YAAHMFile, das auch wieder eingelesen werden kann.
LG
pah
Also mit
configdb filelist
sehe ich sowohl das TESTFILE als auch das YAAHMFILE. Ein
configdb fileshow TESTFILE
zeigt mit
abcdef
wohingegen
configdb fileshow YAAHMFILE
mir
Error on reading YAAHMFILE from database!
zeigt.
EDIT: Wenn ich mit
{FileWrite("YAAHMFILE","abcdef")}
etwas rein schreibe, kann ich mir auch das YAAHMFILE ansehen...
EDIT2: Wenn ich ein Save im Profile mache, kommt beim Lesen wieder der Fehler...
Hier mal ein List von meinem Zeitprofile:
Internals:
CFGFN
NAME Zeitprofile
NOTIFYDEV global,Zeitprofile
NR 745
STATE Initialized
TYPE YAAHM
VERSION 1.32
DATA:
DD:
HASH(0xbd4bd478)
HASH(0xbd896928)
DT:
aftermidnight:
00:01
00:01
undef
;
afternoon:
14:00
undef
undef
;
aftersunrise:
undef
00:30
setreading AU.ho.MS.Multisensor brightness 100, set Dunkel off
;
aftersunset:
undef
01:00
undef
;
beforemidnight:
undef
00:05
undef
;
beforesunrise:
undef
01:00
undef
;
beforesunset:
undef
00:30
setreading AU.ho.MS.Multisensor brightness 0, set Dunkel on
;
evening:
18:30
undef
undef
;
morning:
05:30
undef
set ......WB..* on
;
night:
22:00
undef
set ......WB..* off
;
noon:
13:00
undef
undef
;
sleep:
22:30
undef
undef
undef
sunrise:
undef
undef
set ......WB..* off
;
sunset:
undef
undef
set ......WB..* on
;
wakeup:
06:15
undef
undef
undef
HSM:
WT:
HASH(0xbd7c17e8)
HASH(0xbd7c5930)
READINGS:
2017-12-12 12:02:11 housephase daytime
2017-12-12 08:58:00 housetime aftersunrise
2017-11-26 08:07:15 lockstate 0
2017-12-12 12:00:48 next_0
2017-12-12 12:00:49 next_1
2017-12-12 08:58:00 next_housetime aftersunrise
2017-12-12 08:58:00 prev_housetime
2017-12-12 12:00:48 ring_0 06:15
2017-12-12 12:00:48 ring_0_1 06:15
2017-12-12 12:00:49 ring_1 22:30
2017-12-12 12:00:49 ring_1_1 22:30
2017-12-08 07:07:58 ring_2 06:15
2017-12-08 07:07:58 ring_2_1 off
2017-12-12 12:00:48 s_aftermidnight 00:01
2017-12-12 12:00:48 s_afternoon 14:00
2017-12-12 12:00:48 s_aftersunrise 08:28
2017-12-12 12:00:48 s_aftersunset 16:55
2017-12-12 12:00:48 s_beforemidnight 23:55
2017-12-12 12:00:48 s_beforesunrise 06:58
2017-12-12 12:00:48 s_beforesunset 15:25
2017-12-12 12:00:48 s_evening 18:30
2017-12-12 12:00:48 s_morning 05:30
2017-12-12 12:00:48 s_night 22:00
2017-12-12 12:00:48 s_noon 13:00
2017-12-12 12:00:48 s_sleep 22:30
2017-12-12 12:00:48 s_sunrise 07:58
2017-12-12 12:00:48 s_sunset 15:55
2017-12-12 12:00:48 s_wakeup 06:15
2017-12-12 12:02:13 savedate Tue Dec 12 12:02:13 2017
2017-12-12 09:18:13 state Initialized
2017-11-26 08:04:45 todayDesc --
2017-12-11 00:00:33 todayType workday
2017-12-12 12:00:48 today_0 06:15
2017-12-12 12:00:48 today_0_e enabled
2017-12-12 12:00:49 today_1 22:30
2017-12-12 12:00:49 today_1_e enabled
2017-12-08 07:07:58 today_2 06:15
2017-12-08 07:07:58 today_2_e enabled
2017-11-26 08:04:45 tomorrowDesc --
2017-12-10 00:00:33 tomorrowType workday
2017-12-12 12:00:48 tomorrow_0 06:15
2017-12-12 12:00:48 tomorrow_0_e enabled
2017-12-12 12:00:49 tomorrow_1 22:30
2017-12-12 12:00:49 tomorrow_1_e enabled
2017-12-08 07:07:58 tomorrow_2 off
2017-12-08 07:07:58 tomorrow_2_e enabled
2017-12-12 12:02:11 tr_housephase Tageszeit
2017-12-12 08:58:00 tr_housetime Nach Sonnenaufgang
2017-12-11 00:00:33 tr_todayType Arbeitstag
2017-12-10 00:00:33 tr_tomorrowType Arbeitstag
2017-12-12 12:00:49 tr_wake_0 6:15 morgen
2017-12-12 12:00:49 tr_wake_1 22:30 heute
2017-12-08 07:07:58 tr_wake_2 off morgen
TIMER:
Zeitprofile_aftermidnight:
HASH Zeitprofile
MODIFIER aftermidnight
NAME Zeitprofile_aftermidnight
Zeitprofile_check:
HASH Zeitprofile
MODIFIER check
NAME Zeitprofile_check
Zeitprofile_daytime:
HASH Zeitprofile
MODIFIER daytime
NAME Zeitprofile_daytime
Zeitprofile_nighttime:
HASH Zeitprofile
MODIFIER nighttime
NAME Zeitprofile_nighttime
Attributes:
room ProfileRoom
Wer hat denn danach gefragt ::) ?
Was ist der Wert des Readings savedate ?
Bitte mal die Routine YAAHM_save ersetzen durch
#########################################################################################
#
# YAAHM_save
#
# Parameter hash = hash of the YAAHM device
#
#########################################################################################
sub YAAHM_save($) {
my ($hash) = @_;
$hash->{DATA}{"savedate"} = localtime(time);
readingsSingleUpdate( $hash, "savedate", $hash->{DATA}{"savedate"}, 1 );
my $json = JSON->new->utf8;
my $jhash0 = eval{ $json->encode( $hash->{DATA} ) };
Log 1, "===========> JSON data is ".Dumper($jhash0);
my $error = FileWrite("YAAHMFILE",$jhash0);
Log 1,"[YAAHM_save] error=$error";
return;
}
und den Log-Output posten.
LG
pah
Bei mir funktioniert es jetzt übrigens mit der Version 1.32. Auch nach einem restart ist alles wieder da. :)
Gruß
Uwe
Der Unterschied zwischen 1.31 und 1.32 hat aber damit gar nichts zu tun...
LG
pah
Die Antwort habe ich bereits befürchtet, als ich es geschrieben habe. War schon in der Schule so... :(
Es ist aber nun so, dass es bei mir auf einer FHEM-Installation (raspbian) seit dem Update funktioniert (warum nun auch immer), auf einer anderen Installation (Ubuntu) nicht. Da wird nach dem Befehl
Zitat{(FileRead("YAAHMFILE"))[1]}
lediglich die aktuelle Seite refresht. Das war's. Die Geschichte mit dem Testfile funktioniert aber.
Gruß
Uwe
Wie sagte Odoaker zu Wulfila im Film "Die letzte Legion":
ZitatFalsche Antwort. Bring ihn weg und schneid ihm die Kehle durch.
Es ist nicht der Lesebefehl, der nicht funktioniert - sondern offenbar geht der Schreibbefehl in die Hose. Mit
configDB fileshow YAAHMFile
kann man sich auch ohne "FileRead" die Datei anzeigen lassen. Mit
configDB info
kann man sehen, wie groß die eigene configdb ist, und
configDB
alleine zeigt noch ein paar weitere Möglichkeiten.
Ersetz doch bitte mal die Schreibroutine YAAHM_save durch die oben gepostete Version, und setz bei dem YAAHM-Device verbose auf 5. Ich tippe auf irgendein Problem mit der JSON-Erzeugung aus dem Datenhash.
LG
pah
Moin,
Danke erst mal für die Tipps, komme leider erst morgen oder am Wochenende dazu.
Gruß
Uwe
Zitat von: Prof. Dr. Peter Henning am 12 Dezember 2017, 13:59:39
Wer hat denn danach gefragt ::) ?
Da die Frage im Forum des öfteren kommt, habe ich einfach mal im vorauseilendem Gehorsam gepostet...
Zitat von: Prof. Dr. Peter Henning am 12 Dezember 2017, 13:59:39
und den Log-Output posten.
Hier der Output:
2017.12.13 09:56:57.306 1: [YAAHM_save] error=
2017.12.13 09:56:57.305 1: PERL WARNING: Use of uninitialized value $error in concatenation (.) or string at ./FHEM/95_YAAHM.pm line 957.
2017.12.13 09:56:57.290 1: ===========> JSON data is $VAR1 = undef;
Ronny
So, hab's doch heute noch geschafft. Bei mir sieht es aus ähnlich aus wie bei RoBra81:
save:
2017.12.13 16:13:24 1: ===========> JSON data is undef
2017.12.13 16:13:24 1: PERL WARNING: Use of uninitialized value $error in concatenation (.) or string at ./FHEM/95_YAAHM.pm line 957.
2017.12.13 16:13:24 1: [YAAHM_save] error=
restore:
2017.12.13 16:16:27 1: [YAAHM_restore] read error=Error on reading YAAHMFILE from database!
JSON ist die aktuelle Version.
Gruß
Uwe
Was steht denn beim Systemstart im Log ?
ZitatYAAHM_Define] data hash restored from save file with date ...
oder
Zitat[YAAHM_Define] data hash is initialized
?
LG
pah
Beim letzten restart habe ich folgenden Eintrag gefunden:
2017.12.10 12:21:55 1: [YAAHM_restore] read error=Error on reading YAAHMFILE from database!
2017.12.10 12:21:55 1: [YAAHM_Define] data hash is initialized
Gruß
Uwe
So sollte es ja auch sein. Es ist mir deshalb schleierhaft, wieso die JSON-Erzeugung aus dem Hash fehlschlägt. Bitte noch eine weitere Logzeile in die Save-Funktion einbauen, also insgesamt
sub YAAHM_save($) {
my ($hash) = @_;
$hash->{DATA}{"savedate"} = localtime(time);
readingsSingleUpdate( $hash, "savedate", $hash->{DATA}{"savedate"}, 1 );
my $json = JSON->new->utf8;
my $jhash0 = eval{ $json->encode( $hash->{DATA} ) };
Log 1, "===========> hash data is ".Dumper($hash->{DATA});
Log 1, "===========> JSON data is ".Dumper($jhash0);
my $error = FileWrite("YAAHMFILE",$jhash0);
Log 1,"[YAAHM_save] error=$error";
return;
}
LG
pah
Hallo pah,
damit wird dann diese Logausgabe generiert.
Gruß
Uwe
EDIT: Übrigens wird YAAHMFILE in der configdb angelegt...gelesen wird's aber wohl nicht.
Sieh mal einer an.
Denn in den Hash-Daten ist etwas auffällig: Der letzte Teil davon, da wird statt eines Datums ein Datumsobjekt eingetragen (Beginnt mit bless( ... und endet mit der Klassenbezeichnung Time::Piece). Die JSON-Erzeugung geht dann in die Hose.
Was liefert auf diesem System denn das Kommando "{localtime(time)}" ?
LG
pah
Zitat von: Prof. Dr. Peter Henning am 15 Dezember 2017, 06:47:42
Was liefert auf diesem System denn das Kommando "{localtime(time)}" ?
Fri Dec 15 09:34:10 2017
Ronny
Bei mir auch...
Fri Dec 15 15:52:06 2017
Und warum steht dieser Wert nicht im Hash, sondern das Objekt ? Schleierhaft.
LG
pah
Und Bonusfrage: welches JSON Backend läuft denn ?
http://search.cpan.org/~makamaka/JSON-2.53/lib/JSON.pm#BACKEND_MODULE_DECISION
Ähm...ja... :-[
Keine Ausreden ! ;)
Zitat
JSON::XS-compatible backend modules don't encode blessed objects by default (except for their boolean values, which are typically blessed JSON::PP::Boolean objects). If you need to encode a data structure that may contain objects, you usually need to look into the structure and replace objects with alternative non-blessed values, or enable convert_blessed and provide a TO_JSON method for each object's (base) class that may be found in the structure, in order to let the methods replace the objects with whatever scalar values the methods return.
fhem cmd line:
{JSON->new->backend()}
vg
joerg
aus RAMBO XII:
ZitatJSON is a silly beast!
OOOOOkaayyyy...
JSON::XS
Interpretieren kann ich das nicht. Ist das jetzt gut oder schlecht?
Wobei: Auf einer Maschine funktioniert's, auf der anderen nicht und beide haben die gleiche JSON-Version.
Gruß
Uwe
weder noch, das erklärt das Verhalten.
Ich kenne das modul (YAAHM) nicht, daher weiß ich nicht ob wie das object in den hash kommt. Wenn es "user code" ist müsst ihr aktiv werden, sonst pah.
Die Lösung ist es die Zeit als string reinzuschreiben, zb mit 'POSIX::strftime("%m/%d/%Y %H:%M:%S\n", localtime)'. Natürlich so formatiert das es beim lesen wieder stimmt.
Zitat von: UweH am 16 Dezember 2017, 12:26:24
Wobei: Auf einer Maschine funktioniert's, auf der anderen nicht und beide haben die gleiche JSON-Version.
eben nicht. Das BACKEND wird sich unterscheiden, (PP vs XS vs Tiny und/oder Version). Die Lösung (post darüber) beseitigt die Abhängigkeit.
insider: oder 10sec Festplattentausch :D
Zitat von: herrmannj am 16 Dezember 2017, 12:34:27
insider: oder 10sec Festplattentausch :D
Daran arbeite ich noch... ;)
Der erste Knackpunkt ist hier: strftime ist auch betriebssystemabhängig, das will ich deshalb vermeiden.
Der zweite Knackpunkt: So wie das Modul geschrieben wurde, sollte dort nur ein String auftauchen. Leicht irre, dass dort offenbar das Objekt behalten wird.
Ich habe mal etwas ausprobiert, nämlich den Zeitstring vor der Eintragung in das Hash noch per sprintf explizit konvertiert.
Bitte mal austesten
sub YAAHM_save($) {
my ($hash) = @_;
$hash->{DATA}{"savedate"} = sprintf("%s",localtime(time));
readingsSingleUpdate( $hash, "savedate", $hash->{DATA}{"savedate"}, 1 );
my $json = JSON->new->utf8;
my $jhash0 = eval{ $json->encode( $hash->{DATA} ) };
Log 1, "===========> hash data is ".Dumper($hash->{DATA});
Log 1, "===========> JSON data is ".Dumper($jhash0);
my $error = FileWrite("YAAHMFILE",$jhash0);
Log 1,"[YAAHM_save] error=$error";
return;
}
Zitat von: Prof. Dr. Peter Henning am 16 Dezember 2017, 18:21:20
Bitte mal austesten
Getestet. Funktioniert :) :) :)
Danke und Gruß
Uwe
Klasse,
damit ist mein Problem (Post vom 9 November 2017, 10:01:36) auch behoben. Endlich kann ich das Modul auch nutzen.
Ich verstehe es zwar immer noch nicht ganz, weil der Kontext von localtime immer ein String sein sollte. Aber gut. Habe das Ding jetzt mit dieser Korrektur eingecheckt.
LG
pah
Hallo und ein Frohes Fest in die Runde,
nachdem ich mal wieder mir Zeit nehme an meinem fhem zu arbeiten, wollte ich mich in YAAHM einarbeiten. Ein Update heute morgen gezogen, Astro-device angelegt und parametrisiert (longitude, latidute, altidude). Aber jedes Mal, wenn ich ein 'define MyYAAHM YAAHM' durchführe stürzt fhem mit folgender Fehlermeldung im log ab:
2017.12.26 09:39:38.997 1: PERL WARNING: Subroutine YAAHM_restore redefined at ./FHEM/95_YAAHM.pm line 968.
2017.12.26 09:39:39.001 1: PERL WARNING: Subroutine YAAHM_sayWeeklyTime redefined at ./FHEM/95_YAAHM.pm line 1855.
2017.12.26 09:39:39.018 1: [YAAHM_Define] data hash restored from save file with date Tue Dec 26 09:39:39 2017
2017.12.26 09:39:39.018 1: [YAAHM] finds 1 Astro devices, module not loaded separately
Can't use an undefined value as an ARRAY reference at ./FHEM/95_YAAHM.pm line 934.
Versionen:
Habe den Thread schon mehrmals durchsucht ohne jedoch eine Idee zu bekommen, wie ich zu einer Lösung kommen kann.
Hat jemand auch dieses Problem? Vielleicht eine Idee von einer Lösung?
Ciao Walter
Hallo,
ich habe eine Sub, die am Abend meine Rollos schließt. Den Aufruf der Sub hab ich jetzt von einem at umgestellt und in die Liste der Aktionen beim YAAHM Tagesprofil eingetragen. Soweit so gut, der Aufruf funktioniert und die Rollos werden geschlossen.
Zu meinem Problem: Die Sub erwartet als Parameter "$month", den ich natürlich beim Aufruf übergebe. Wenn ich dann auf "Start Daily Timer" klicke wird aus der Variable $month eine Zahl, nämlich die des aktuellen Monats und diese ändert sich leider beim Wechsel in den nächsten Monat auch nicht.
Gibt es eine Möglichkeit an dieser Stelle solche Variablen von FHEM an eine Sub zu übergeben?
Danke schon mal für die Aufklärung.
Viele Grüße
Flo
Natürlich. Ich würde erstens diesen Wert gar nicht übergeben, sondern in der Prozedur selbst erzeugen. Und zweitens kann man in den bei YAAHM eingetragenen Kommandos natürlich einen ReadingsVal oder einen weiteren Perl-Aufruf statt des festen Wertes eintragen.
LG
pah
Zitat von: Prof. Dr. Peter Henning am 18 Februar 2018, 13:03:14
Ich würde erstens diesen Wert gar nicht übergeben, sondern in der Prozedur selbst erzeugen.
Dann schau ich mir mal an wie das funktioniert
Danke für die schnelle Antwort.
Gruß
Flo
Hallo pah,
zwei kurze Fragen zu YAAHM:
- was für eine Funktion hat das Kommando set <name> checkstate ? (habe ich weder im Wiki noch in der CommandRef gefunden)
- sind die Attribute event-on-[change|update]-reading geplant?
Mein Logfile füllt sich minütlich:
...
2018-02-18_20:15:58 myHA sec_housestate: secure
2018-02-18_20:16:58 myHA sec_housestate: secure
2018-02-18_20:17:58 myHA sec_housestate: secure
2018-02-18_20:18:58 myHA sec_housestate: secure
2018-02-18_20:19:58 myHA sec_housestate: secure
...
Gruß,
Tobias
Stimmt nicht - checkstate und das neue correctstate sind in der CommandRef beschrieben, im Wiki muss ich das noch nachziehen. Und nein, ich habe keine Ahnung, warum das im Log auftaucht.
Die automatisch ablaufende Prozedur YAAHM_checkstate() überprüft in einstellbaren Intervallen (Attribute stateInterval), ob tatsächlich alle stateDevices im richtigen Zustand sind. Wenn ja, wird das Attribut sec_housestate auf "secure" gesetzt, sonst auf "insecure". Wenn ein Device nicht im richtigen Zustand ist, wird die Perl-Funktion aufgerufen, die im Attribut stateWarning festgelegt ist.
Der Befehl set <name> checkstate ruft entweder sofort, oder mit einer Verzögerung von 5 oder 10 Sekunden auch diese Prüfung auf.
Der Befehl set <name> correctstate versucht, einen als "insecure" erkannten housestate zu korrigieren:
Beispiel für die Anwendung: Die beiden Türen "Hoftuer" und "Haustuer" sind als stateDevices definiert, sie müssen im housestate "secured" = "Gesichert" auf "locked" stehen. Irgendjemand hat aber die Haustür aufgesperrt und nicht wieder verschlossen. Dann wird bei der Überprüfung durch checkstate festgestellt, dass dies nicht stimmt, und eine Warnung ausgegeben. Oder direkt correctstate aufgerufen, das set dann einen Befehl "set Haustuer locked" ab.
Allerdings ist in der Version 1.48 (gestern eingecheckt) ein fehler drin, der Defaultwert für stateInterval soll nämlich 60 Minuten sein, nicht 60 Sekunden.
Ändere ich umgehend.
LG
pah
Hallo,
ich mag das Modul und nutze die Tagesplabung für Rollos.
Der Wochenplan will mir jedoch nicht gelingen.
Ich habe bei Aktionen
set Service.DeutscheBahn.NeckarsulmHbf.HeilbronnHbf off
eingesetzt, ein Befehl der kn der FHEM-Zeile funktioniert.
Der Wochenplan ist aktiv, das generische DOIF sieht gut aus:
([Service.YAAHM:ring_3] eq "off")
()
DOELSEIF
(([[Service.YAAHM:ring_3]])
and ([Service.YAAHM:housemode] =~ "(normal)")
and ([Service.YAAHM:todayType] =~ "(workday)|(weekend)"))
(set Service.DeutscheBahn.NeckarsulmHbf.HeilbronnHbf off)
Aber irgendwie Wilkes nicht schalten, auch im Event Monitor kommt kein Ereignis an.
Sieht jemand meinen Fehler?
Hallo,
erst mal vielen Dank für das tolle Modul. Zusammen mit den Calendar-Modulen und entsprechenden Funktionen in den "Helpern" hat es schon weitgehend meine bisherigen Funktionen ersetzt.
Seit einiger Zeit, leider kann ich nicht mehr genau sagen seit wann genau, erhalte ich folgende Meldungen im Log.
Scheinbar nicht weiter problematisch... Ich gehe auch davon aus, dass es was mit der Konfiguration meines Raspi-Pis zu tun hat, diesen musste ich vor einiger Zeit neu aufsetzten.
[Wed Apr 11 17:55:51 2018] fhem.pl: Subroutine YAAHM_restore redefined at ./FHEM/95_YAAHM.pm line 973, <$fh> line 4072.
[Wed Apr 11 17:55:51 2018] fhem.pl: Subroutine YAAHM_setWeeklyTime redefined at ./FHEM/95_YAAHM.pm line 1755, <$fh> line 4072.
2018.04.11 17:55:51 1: [YAAHM_Define] data hash restored from save file with date 2018-03-27 11:09:04
2018.04.11 17:55:51 1: [YAAHM] finds 1 Astro devices, module not loaded separately
2018.04.11 17:55:51 1: Including /media/usb0/log/fhem.save
[Wed Apr 11 17:55:52 2018] fhem.pl: Use of uninitialized value $n in hash element at fhem.pl line 4217.
[Wed Apr 11 17:55:52 2018] fhem.pl: Use of uninitialized value $n in hash element at fhem.pl line 4217.
[Wed Apr 11 17:55:52 2018] fhem.pl: Use of uninitialized value $n in hash element at fhem.pl line 4217.
[Wed Apr 11 17:55:52 2018] fhem.pl: Use of uninitialized value $n in hash element at fhem.pl line 4217.
[Wed Apr 11 17:55:52 2018] fhem.pl: Use of uninitialized value $n in hash element at fhem.pl line 4217.
[Wed Apr 11 17:55:52 2018] fhem.pl: Use of uninitialized value $n in hash element at fhem.pl line 4217.
[Wed Apr 11 17:55:52 2018] fhem.pl: Use of uninitialized value $n in hash element at fhem.pl line 4217.
[Wed Apr 11 17:55:52 2018] fhem.pl: Use of uninitialized value $n in hash element at fhem.pl line 4217.
[Wed Apr 11 17:55:52 2018] fhem.pl: Use of uninitialized value $n in hash element at fhem.pl line 4217.
[Wed Apr 11 17:55:52 2018] fhem.pl: Use of uninitialized value $n in hash element at fhem.pl line 4217.
[Wed Apr 11 17:55:52 2018] fhem.pl: Use of uninitialized value $n in hash element at fhem.pl line 4217.
[Wed Apr 11 17:55:52 2018] fhem.pl: Use of uninitialized value $n in hash element at fhem.pl line 4217.
[Wed Apr 11 17:55:52 2018] fhem.pl: Use of uninitialized value $n in hash element at fhem.pl line 4217.
[Wed Apr 11 17:55:52 2018] fhem.pl: Use of uninitialized value $n in hash element at fhem.pl line 4217.
[Wed Apr 11 17:55:52 2018] fhem.pl: Use of uninitialized value $n in hash element at fhem.pl line 4217.
2018.04.11 17:55:59 0: Featurelevel: 5.8
2018.04.11 17:55:59 0: Server started with 387 defined entities (fhem.pl:16569/2018-04-08 perl:5.024001 os:linux user:fhem pid:2713)
2018.04.11 17:56:03 1: [YAAHM_updater] on device myYAAHM called for this day
[Wed Apr 11 17:56:03 2018] fhem.pl: Use of uninitialized value in string comparison (cmp) at ./FHEM/95_YAAHM.pm line 266.
[Wed Apr 11 17:56:03 2018] fhem.pl: Use of uninitialized value in string comparison (cmp) at ./FHEM/95_YAAHM.pm line 266.
[Wed Apr 11 17:56:03 2018] fhem.pl: Use of uninitialized value in string comparison (cmp) at ./FHEM/95_YAAHM.pm line 266.
[Wed Apr 11 17:56:03 2018] fhem.pl: Use of uninitialized value in string comparison (cmp) at ./FHEM/95_YAAHM.pm line 266.
[Wed Apr 11 17:56:03 2018] fhem.pl: Use of uninitialized value in string comparison (cmp) at ./FHEM/95_YAAHM.pm line 266.
[Wed Apr 11 17:56:03 2018] fhem.pl: Use of uninitialized value in string comparison (cmp) at ./FHEM/95_YAAHM.pm line 266.
[Wed Apr 11 17:56:03 2018] fhem.pl: Use of uninitialized value in string comparison (cmp) at ./FHEM/95_YAAHM.pm line 266.
[Wed Apr 11 17:56:03 2018] fhem.pl: Use of uninitialized value in string comparison (cmp) at ./FHEM/95_YAAHM.pm line 266.
[Wed Apr 11 17:56:03 2018] fhem.pl: Use of uninitialized value in string comparison (cmp) at ./FHEM/95_YAAHM.pm line 266.
[Wed Apr 11 17:56:03 2018] fhem.pl: Use of uninitialized value in string comparison (cmp) at ./FHEM/95_YAAHM.pm line 266.
[Wed Apr 11 17:56:03 2018] fhem.pl: Use of uninitialized value in string comparison (cmp) at ./FHEM/95_YAAHM.pm line 266.
[Wed Apr 11 17:56:03 2018] fhem.pl: Use of uninitialized value in string comparison (cmp) at ./FHEM/95_YAAHM.pm line 266.
[Wed Apr 11 17:56:03 2018] fhem.pl: Use of uninitialized value in string comparison (cmp) at ./FHEM/95_YAAHM.pm line 266.
[Wed Apr 11 17:56:03 2018] fhem.pl: Use of uninitialized value in string comparison (cmp) at ./FHEM/95_YAAHM.pm line 266.
[Wed Apr 11 17:56:03 2018] fhem.pl: Use of uninitialized value in string comparison (cmp) at ./FHEM/95_YAAHM.pm line 266.
[Wed Apr 11 17:56:03 2018] fhem.pl: Use of uninitialized value in string comparison (cmp) at ./FHEM/95_YAAHM.pm line 266.
[Wed Apr 11 17:56:03 2018] fhem.pl: Use of uninitialized value in string comparison (cmp) at ./FHEM/95_YAAHM.pm line 266.
[Wed Apr 11 17:56:03 2018] fhem.pl: Use of uninitialized value in string comparison (cmp) at ./FHEM/95_YAAHM.pm line 266.
[Wed Apr 11 17:56:03 2018] fhem.pl: Use of uninitialized value in string comparison (cmp) at ./FHEM/95_YAAHM.pm line 266.
[Wed Apr 11 17:56:03 2018] fhem.pl: Use of uninitialized value in string comparison (cmp) at ./FHEM/95_YAAHM.pm line 266.
[Wed Apr 11 17:56:03 2018] fhem.pl: Use of uninitialized value in string comparison (cmp) at ./FHEM/95_YAAHM.pm line 266.
[Wed Apr 11 17:56:03 2018] fhem.pl: Use of uninitialized value in string comparison (cmp) at ./FHEM/95_YAAHM.pm line 266.
[Wed Apr 11 17:56:03 2018] fhem.pl: Use of uninitialized value in string comparison (cmp) at ./FHEM/95_YAAHM.pm line 266.
[Wed Apr 11 17:56:03 2018] fhem.pl: Use of uninitialized value in string comparison (cmp) at ./FHEM/95_YAAHM.pm line 266.
[Wed Apr 11 17:56:03 2018] fhem.pl: Use of uninitialized value in string comparison (cmp) at ./FHEM/95_YAAHM.pm line 266.
[Wed Apr 11 17:56:03 2018] fhem.pl: Use of uninitialized value in string comparison (cmp) at ./FHEM/95_YAAHM.pm line 266.
[Wed Apr 11 17:56:03 2018] fhem.pl: Use of uninitialized value in string comparison (cmp) at ./FHEM/95_YAAHM.pm line 266.
[Wed Apr 11 17:56:03 2018] fhem.pl: Use of uninitialized value in string comparison (cmp) at ./FHEM/95_YAAHM.pm line 266.
[Wed Apr 11 17:56:03 2018] fhem.pl: Use of uninitialized value in string comparison (cmp) at ./FHEM/95_YAAHM.pm line 266.
[Wed Apr 11 17:56:03 2018] fhem.pl: Use of uninitialized value in string comparison (cmp) at ./FHEM/95_YAAHM.pm line 266.
[Wed Apr 11 17:56:03 2018] fhem.pl: Use of uninitialized value in string comparison (cmp) at ./FHEM/95_YAAHM.pm line 266.
[Wed Apr 11 17:56:03 2018] fhem.pl: Use of uninitialized value in string comparison (cmp) at ./FHEM/95_YAAHM.pm line 266.
[Wed Apr 11 17:56:03 2018] fhem.pl: Use of uninitialized value in string comparison (cmp) at ./FHEM/95_YAAHM.pm line 266.
[Wed Apr 11 17:56:03 2018] fhem.pl: Use of uninitialized value in string comparison (cmp) at ./FHEM/95_YAAHM.pm line 266.
[Wed Apr 11 17:56:03 2018] fhem.pl: Use of uninitialized value in string comparison (cmp) at ./FHEM/95_YAAHM.pm line 266.
[Wed Apr 11 17:56:03 2018] fhem.pl: Use of uninitialized value in string comparison (cmp) at ./FHEM/95_YAAHM.pm line 266.
[Wed Apr 11 17:56:03 2018] fhem.pl: Use of uninitialized value in string comparison (cmp) at ./FHEM/95_YAAHM.pm line 266.
[Wed Apr 11 17:56:03 2018] fhem.pl: Use of uninitialized value in string comparison (cmp) at ./FHEM/95_YAAHM.pm line 266.
[Wed Apr 11 17:56:03 2018] fhem.pl: Use of uninitialized value in string comparison (cmp) at ./FHEM/95_YAAHM.pm line 266.
[Wed Apr 11 17:56:03 2018] fhem.pl: Use of uninitialized value in string comparison (cmp) at ./FHEM/95_YAAHM.pm line 266.
[Wed Apr 11 17:56:03 2018] fhem.pl: Use of uninitialized value in string comparison (cmp) at ./FHEM/95_YAAHM.pm line 266.
[Wed Apr 11 17:56:03 2018] fhem.pl: Use of uninitialized value in string comparison (cmp) at ./FHEM/95_YAAHM.pm line 266.
[Wed Apr 11 17:56:03 2018] fhem.pl: Use of uninitialized value in string comparison (cmp) at ./FHEM/95_YAAHM.pm line 266.
[Wed Apr 11 17:56:03 2018] fhem.pl: Use of uninitialized value in string comparison (cmp) at ./FHEM/95_YAAHM.pm line 266.
[Wed Apr 11 17:56:03 2018] fhem.pl: Use of uninitialized value in string comparison (cmp) at ./FHEM/95_YAAHM.pm line 266.
[Wed Apr 11 17:56:03 2018] fhem.pl: Use of uninitialized value in string comparison (cmp) at ./FHEM/95_YAAHM.pm line 266.
[Wed Apr 11 17:56:03 2018] fhem.pl: Use of uninitialized value in string comparison (cmp) at ./FHEM/95_YAAHM.pm line 266.
[Wed Apr 11 17:56:03 2018] fhem.pl: Use of uninitialized value in string comparison (cmp) at ./FHEM/95_YAAHM.pm line 266.
[Wed Apr 11 17:56:03 2018] fhem.pl: Use of uninitialized value in string comparison (cmp) at ./FHEM/95_YAAHM.pm line 266.
[Wed Apr 11 17:56:03 2018] fhem.pl: Use of uninitialized value in string comparison (cmp) at ./FHEM/95_YAAHM.pm line 266.
[Wed Apr 11 17:56:03 2018] fhem.pl: Use of uninitialized value in string comparison (cmp) at ./FHEM/95_YAAHM.pm line 266.
[Wed Apr 11 17:56:03 2018] fhem.pl: Use of uninitialized value in string comparison (cmp) at ./FHEM/95_YAAHM.pm line 266.
[Wed Apr 11 17:56:03 2018] fhem.pl: Use of uninitialized value in string comparison (cmp) at ./FHEM/95_YAAHM.pm line 266.
[Wed Apr 11 17:56:03 2018] fhem.pl: Use of uninitialized value in string comparison (cmp) at ./FHEM/95_YAAHM.pm line 266.
[Wed Apr 11 17:56:03 2018] fhem.pl: Use of uninitialized value in string comparison (cmp) at ./FHEM/95_YAAHM.pm line 266.
[Wed Apr 11 17:56:03 2018] fhem.pl: Use of uninitialized value in string comparison (cmp) at ./FHEM/95_YAAHM.pm line 266.
[Wed Apr 11 17:56:03 2018] fhem.pl: Use of uninitialized value in string comparison (cmp) at ./FHEM/95_YAAHM.pm line 266.
.
.
.
.
.
2018.04.11 17:56:09 0: NTFY_SERVER_STARTED
[Wed Apr 11 17:59:22 2018] fhem.pl: Use of uninitialized value in concatenation (.) or string at ./FHEM/95_YAAHM.pm line 3316.
[Wed Apr 11 17:59:22 2018] fhem.pl: Use of uninitialized value in concatenation (.) or string at ./FHEM/95_YAAHM.pm line 3316.
[Wed Apr 11 17:59:23 2018] fhem.pl: Use of uninitialized value in concatenation (.) or string at ./FHEM/95_YAAHM.pm line 3316.
[Wed Apr 11 17:59:23 2018] fhem.pl: Use of uninitialized value in concatenation (.) or string at ./FHEM/95_YAAHM.pm line 3316.
Die Meldungen kommen neben einen Neustart mal mehr oder weniger auch über den Tag verteilt vor.
Bis dahin, wenn noch weitere Informationen benötigt werden einfach melden.
Beste Grüße
Ma.
Ich tippe auf eine YAAHFile-Datei mit Macken. Leider bin ich erstens noch nicht dazu gekommen, und habe zweitens auch noch keine ganz clevere Idee, wie man solche Macken abstellen kann.
Vorschlag: Backup von YAAHMFile, und dann ein neues "save" im YAAHM_Device machen.
LG
pah
Zitat von: Prof. Dr. Peter Henning am 12 April 2018, 17:36:56
Ich tippe auf eine YAAHFile-Datei mit Macken. Leider bin ich erstens noch nicht dazu gekommen, und habe zweitens auch noch keine ganz clevere Idee, wie man solche Macken abstellen kann.
Vorschlag: Backup von YAAHMFile, und dann ein neues "save" im YAAHM_Device machen.
LG
pah
Das war es.
Wenn man es weiß kann man es ja mit einem neuen "save" abstellen, und es scheint ja auch nur in Ausnahmefällen vorzukommen.
Vielen lieben Dank
Gruß
Ma.
Hallo pah,
habe bemerkt, daß mein YAAHM Device trotz gepflegten Kalenders für Feiertage heute den Tagestyp Arbeitstag statt korrekt Feiertag ( Christi Himmelfahrt ) ermittelt hat.
Hier ein Auszug aus dem YAAHM Log:
2018-03-19_00:00:33 myHA tr_todayType: Arbeitstag
2018-03-24_00:00:33 myHA tr_todayType: Wochenende
2018-03-26_00:00:33 myHA tr_todayType: Ferientag
2018-03-31_00:00:33 myHA tr_todayType: Wochenende
2018-04-02_00:00:33 myHA tr_todayType: Ferientag
2018-04-04_12:41:50 myHA tr_todayType: Arbeitstag
2018-04-07_00:00:33 myHA tr_todayType: Wochenende
2018-04-09_00:00:33 myHA tr_todayType: Arbeitstag
2018-04-14_00:00:33 myHA tr_todayType: Wochenende
2018-04-16_00:00:34 myHA tr_todayType: Arbeitstag
2018-04-21_00:00:33 myHA tr_todayType: Wochenende
2018-04-23_00:00:33 myHA tr_todayType: Arbeitstag
2018-04-28_00:00:33 myHA tr_todayType: Wochenende
2018-04-30_00:00:33 myHA tr_todayType: Arbeitstag
2018-05-05_00:00:34 myHA tr_todayType: Wochenende
2018-05-07_00:00:33 myHA tr_todayType: Arbeitstag
Bis auf Feiertage wird der Tagestyp also stets korrekt ermittelt.
List des Feiertage Kalenders von heute ( Christi Himmelfahrt ):
list Feiertage
Internals:
DEF ical file feiertage_BY.ics 86400
NAME Feiertage
NOTIFYDEV global
NR 109
NTFY_ORDER 50-Feiertage
STATE triggered
TYPE Calendar
READINGS:
2018-05-10 23:06:47 lastUpdate 2018-05-10 23:06:47
2017-07-21 14:47:31 modeAlarm
2018-05-10 00:00:00 modeAlarmOrStart ChristiHimmelfahrt20180510schulferieneu
2017-07-21 14:47:31 modeAlarmed
2018-05-10 03:17:49 modeChanged
2018-05-10 23:06:47 modeEnd TagderArbeit20180501schulferieneu;Ostermontag20180402schulferieneu;HeiligeDreiKoenige20180106schulferieneu;Karfreitag20180330schulferieneu;Neujahr20180101schulferieneu;Ostersonntag20180401schulferieneu
2018-05-02 03:18:43 modeEnded
2018-05-10 00:00:00 modeStart ChristiHimmelfahrt20180510schulferieneu
2018-05-10 03:17:49 modeStarted
2018-05-10 23:06:47 modeUpcoming Pfingstsonntag20180520schulferieneu;TagderdeutschenEinheit20181003schulferieneu;SilvesterBankfeiertag20181231schulferieneu;Pfingstmontag20180521schulferieneu;Allerheiligen20181101schulferieneu;Fronleichnam20180531schulferieneu;MariaeHimmelfahrt20180815schulferieneu;1Weihnachtsfeiertag20181225schulferieneu;HeiligerAbendBankfeiertag20181224schulferieneu;2Weihnachtsfeiertag20181226schulferieneu
2018-05-10 23:06:47 nextUpdate 2018-05-11 23:06:47
2018-05-10 23:06:47 nextWakeup 2018-05-11 00:00:00
2018-05-10 23:06:47 state triggered
Attributes:
room Kontrollraum
Und hier noch der List des YAAHM:
list myHA
Internals:
NAME myHA
NOTIFYDEV global,myHA
NR 132
STATE Initialized
TYPE YAAHM
VERSION 1.50
DATA:
savedate 35
DD:
HASH(0x37cc5d0)
HASH(0x37cc258)
DT:
aftermidnight:
00:01
00:01
undef
undef
afternoon:
14:00
undef
undef
undef
aftersunrise:
06:41
01:00
undef
undef
aftersunset:
21:39
01:00
undef
undef
beforemidnight:
23:55
00:05
undef
undef
beforesunrise:
04:41
01:00
undef
undef
beforesunset:
19:39
01:00
undef
undef
evening:
18:30
undef
undef
undef
morning:
08:00
undef
undef
undef
night:
22:00
undef
undef
undef
noon:
13:00
undef
undef
undef
sleep:
22:30
undef
undef
undef
sunrise:
05:41
undef
undef
undef
sunset:
20:39
undef
undef
undef
wakeup:
06:15
undef
undef
undef
HSM:
mode normal
state secured
time sleep
WT:
HASH(0x37e2420)
HASH(0x37cb428)
HASH(0x37e1778)
HASH(0x37dd6c0)
HASH(0x37e16b8)
READINGS:
2017-10-29 12:47:52 housemode normal
2018-05-10 22:30:00 housephase nighttime
2018-05-10 22:30:00 housestate secured
2018-05-10 22:30:00 housetime sleep
2017-10-29 12:10:31 lockstate 0
2018-05-10 23:11:52 next_0
2018-05-10 23:11:52 next_1
2018-05-10 23:11:52 next_2
2018-05-10 23:11:52 next_3
2018-05-10 23:11:52 next_4
2018-05-10 22:30:00 next_housetime morning
2017-10-29 12:47:52 prev_housemode absence
2018-05-10 22:30:00 prev_housestate unsecured
2018-05-10 22:30:00 prev_housetime wakeup
2018-05-10 23:11:52 ring_0 06:15
2018-05-10 23:11:52 ring_0_1 06:15
2018-05-10 23:11:52 ring_0_1x 06:15
2018-05-10 23:11:52 ring_0x 06:15
2018-05-10 23:11:52 ring_1 22:30
2018-05-10 23:11:52 ring_1_1 23:00
2018-05-10 23:11:52 ring_1_1x 23:00
2018-05-10 23:11:52 ring_1x 22:30
2018-05-10 23:11:52 ring_2 07:15
2018-05-10 23:11:52 ring_2_1 07:15
2018-05-10 23:11:52 ring_2_1x 07:15
2018-05-10 23:11:52 ring_2x 07:15
2018-05-10 23:11:52 ring_3 07:30
2018-05-10 23:11:52 ring_3_1 07:30
2018-05-10 23:11:52 ring_3_1x 07:30
2018-05-10 23:11:52 ring_3x 07:30
2018-05-10 23:11:52 ring_4 07:30
2018-05-10 23:11:52 ring_4_1 08:30
2018-05-10 23:11:52 ring_4_1x 08:30
2018-05-10 23:11:52 ring_4x 07:30
2018-05-10 23:11:52 s_aftermidnight 00:01
2018-05-10 23:11:52 s_afternoon 14:00
2018-05-10 23:11:52 s_aftersunrise 06:41
2018-05-10 23:11:52 s_aftersunset 21:39
2018-05-10 23:11:52 s_beforemidnight 23:55
2018-05-10 23:11:52 s_beforesunrise 04:41
2018-05-10 23:11:52 s_beforesunset 19:39
2018-05-10 23:11:52 s_evening 18:30
2018-05-10 23:11:52 s_morning 08:00
2018-05-10 23:11:52 s_night 22:00
2018-05-10 23:11:52 s_noon 13:00
2018-05-10 23:11:52 s_sleep 22:30
2018-05-10 23:11:52 s_sunrise 05:41
2018-05-10 23:11:52 s_sunset 20:39
2018-05-10 23:11:52 s_wakeup 06:15
2018-05-10 03:17:40 savedate 35
2018-05-10 23:30:30 sdev_housestate <html><table><tr><td style="text-align:left;padding:5px">door_SC</td><td style="text-align:left;padding:5px"><div style="color:green">OK</div></td><td></td></tr></table></html>
2018-05-10 23:30:30 sec_housestate secure
2018-05-10 03:17:40 state Initialized
2018-05-10 23:30:30 sym_housestate <html><div style="color:green">✓</div></html>
2017-10-30 00:00:33 t_aftermidnight 00:01
2017-10-30 00:00:33 t_aftersunrise 01:00
2017-10-30 00:00:33 t_aftersunset 01:00
2017-10-30 00:00:33 t_beforemidnight 00:05
2017-10-30 00:00:33 t_beforesunrise 01:00
2017-10-30 00:00:33 t_beforesunset 01:00
2018-04-04 12:41:50 todayDesc --
2018-05-07 00:00:33 todayType workday
2018-05-10 23:11:52 today_0 06:15
2018-05-10 23:11:52 today_0_e enabled
2018-05-10 23:11:52 today_1 22:30
2018-05-10 23:11:52 today_1_e enabled
2018-05-10 23:11:52 today_2 07:15
2018-05-10 23:11:52 today_2_e enabled
2018-05-10 23:11:52 today_3 07:30
2018-05-10 23:11:52 today_3_e enabled
2018-05-10 23:11:52 today_4 07:30
2018-05-10 23:11:52 today_4_e enabled
2018-04-04 12:41:50 tomorrowDesc --
2018-05-06 00:00:33 tomorrowType workday
2018-05-10 23:11:52 tomorrow_0 06:15
2018-05-10 23:11:52 tomorrow_0_e enabled
2018-05-10 23:11:52 tomorrow_1 23:00
2018-05-10 23:11:52 tomorrow_1_e enabled
2018-05-10 23:11:52 tomorrow_2 07:15
2018-05-10 23:11:52 tomorrow_2_e enabled
2018-05-10 23:11:52 tomorrow_3 07:30
2018-05-10 23:11:52 tomorrow_3_e enabled
2018-05-10 23:11:52 tomorrow_4 08:30
2018-05-10 23:11:52 tomorrow_4_e enabled
2018-05-10 22:30:00 tr_errmsg
2017-10-29 12:47:52 tr_housemode Normal
2018-05-10 22:30:00 tr_housephase Nachtzeit
2018-05-10 22:30:00 tr_housestate Gesichert
2018-05-10 22:30:00 tr_housetime Schlafen
2018-05-07 00:00:33 tr_todayType Arbeitstag
2018-05-06 00:00:33 tr_tomorrowType Arbeitstag
2018-05-10 23:11:52 tr_wake_0 6:15 morgen
2018-05-10 23:11:52 tr_wake_1 23:00 morgen
2018-05-10 23:11:52 tr_wake_2 7:15 morgen
2018-05-10 23:11:52 tr_wake_3 7:30 morgen
2018-05-10 23:11:52 tr_wake_4 8:30 morgen
TIMER:
myHA_aftermidnight:
HASH myHA
MODIFIER aftermidnight
NAME myHA_aftermidnight
myHA_check:
HASH myHA
MODIFIER check
NAME myHA_check
Attributes:
holidayDevices Feiertage
room ProfileRoom
stateAuto 1
stateDevices door_SC::closed:closed:closed
vacationDevices Ferien
Gruß
Tobias
Soll ich das zwischen 23:49 Uhr und Mitternacht überprüfen ?
Witzbold
LG
pah
Zitat von: Prof. Dr. Peter Henning am 11 Mai 2018, 07:29:56
Soll ich das zwischen 23:49 Uhr und Mitternacht überprüfen ?
Natürlich nicht. Ich erwarte gar keinen adhoc-Support, schon gar nicht am Feiertag...
Eine Idee, um das Problem einzugrenzen, wäre schön. Demnächst kommt mit dem Pfingstmontag ja wieder eine Möglichkeit zum Testen.
Laut Log oben war das gestern kein Einzelfall. Auch die Osterfeiertage wurden nicht erkannt sondern als Ferientag deklariert, obwohl Feiertag laut Wiki die höchste Priorität haben soll.
Das Feiertage Calendar Device hat um Punkt 00:00 den Status "ChristiHimmelfahrt..." gesetzt.
2018-05-10 00:00:00 modeAlarmOrStart ChristiHimmelfahrt20180510schulferieneu
2017-07-21 14:47:31 modeAlarmed
2018-05-10 03:17:49 modeChanged
2018-05-10 23:06:47 modeEnd TagderArbeit20180501schulferieneu;Ostermontag20180402schulferieneu;HeiligeDreiKoenige20180106schulferieneu;Karfreitag20180330schulferieneu;Neujahr20180101schulferieneu;Ostersonntag20180401schulferieneu
2018-05-02 03:18:43 modeEnded
2018-05-10 00:00:00 modeStart ChristiHimmelfahrt20180510schulferieneu
YAAHM ermittelt den tr_todayType doch erst etwa 30 Sekunden später.
Noch etwas. Auf dem gleichen System habe ich u.a. noch die "alte" Routine getDayStatus() von https://forum.fhem.de/index.php/topic,36244.msg299631.html#msg299631 (https://forum.fhem.de/index.php/topic,36244.msg299631.html#msg299631) im Einsatz. Diese arbeitet auf dem gleichen Feiertage Kalender hat gestern den Tagestyp korrekt auf "Feiertag" gestellt.
Gruß
Tobias
Problem gelöst - wie schon mehrfach eines von strftime, in diesem Falle einfach der Unterschied zwischen "18" und "2018". Ist eingecheckt.
LG
pah
Hallo zusammen,
Ich habe mich heute daran gemacht dieses Modul zu installieren und einzurichten.
Vielen Dank für die Bereitstellung!
Ich möchte damit meine Rollo Steuerung und Kameraüberwachung bei Abwesenheit usw. realisieren.
Ich würde gerne auch die HouseTimeHelper sub Module nutzen und habe mir mit get YYY Template die Beispiele anzeigen lassen.
Nun scheine ich Tomaten auf den Augen zu haben, denn ich weiß nicht genau wo ich diese definieren soll.
Ich hatte diese in 99_myUtils.pm gesetzt aber da scheint es nicht richtig zu sein denn im Log-File ist zur entsprechende auslösezeit ein Fehler zu lesen der sub Routine nicht findet.
Internals:
NAME YYY
NOTIFYDEV global,YYY
NR 22
STATE Initialized
TYPE YAAHM
VERSION 1.54
DATA:
savedate 2018-05-18 15:43:43
DD:
HASH(0x2ba4be0)
HASH(0x2ba4d60)
HASH(0x2de5998)
DT:
aftermidnight:
00:01
00:01
{HouseTimeHelper('aftermidnight')}
;
afternoon:
14:00
undef
{HouseTimeHelper('afternoon')}
;
aftersunrise:
06:38
01:00
{HouseTimeHelper('aftersunrise')}
;
aftersunset:
22:01
01:00
{HouseTimeHelper('aftersunset')}
;
beforemidnight:
23:55
00:05
{HouseTimeHelper('beforemidnight')}
;
beforesunrise:
04:38
01:00
{HouseTimeHelper('beforesunrise')}
;
beforesunset:
20:01
01:00
{HouseTimeHelper('beforesunset')}
;
evening:
18:30
undef
{HouseTimeHelper('evening')}
;
morning:
08:00
undef
{HouseTimeHelper('morning')}
;
night:
22:00
undef
{HouseTimeHelper('night')}
;
noon:
13:00
undef
{HouseTimeHelper('noon')}
;
sleep:
22:30
undef
undef
undef
sunrise:
05:38
undef
{HouseTimeHelper('sunrise')}
;
sunset:
21:01
undef
{HouseTimeHelper('sunset')}
;
wakeup:
06:15
undef
undef
undef
HSM:
mode normal
state unsecured
time afternoon
WT:
HASH(0x2ba4bb0)
HASH(0x2ba4b98)
OLDREADINGS:
READINGS:
2018-05-18 15:43:24 housemode normal
2018-05-18 15:43:42 housephase daytime
2018-05-18 15:43:13 housestate unsecured
2018-05-18 15:37:00 housetime afternoon
2018-05-17 22:50:10 lockstate 0
2018-05-18 15:37:00 next_housetime afternoon
2018-05-18 15:43:24 prev_housemode party
2018-05-18 15:43:13 prev_housestate unsecured
2018-05-18 15:37:00 prev_housetime
2018-05-18 15:43:46 ring_0 06:15
2018-05-18 15:43:46 ring_0_1 off
2018-05-18 15:43:46 ring_0_1x off
2018-05-18 15:43:46 ring_0x 06:15
2018-05-18 15:43:46 ring_1 23:00
2018-05-18 15:43:46 ring_1_1 23:00
2018-05-18 15:43:46 ring_1_1x 23:00
2018-05-18 15:43:46 ring_1x 23:00
2018-05-18 15:43:46 s_aftermidnight 00:01
2018-05-18 15:43:46 s_afternoon 14:00
2018-05-18 15:43:46 s_aftersunrise 06:38
2018-05-18 15:43:46 s_aftersunset 22:01
2018-05-18 15:43:46 s_beforemidnight 23:55
2018-05-18 15:43:46 s_beforesunrise 04:38
2018-05-18 15:43:46 s_beforesunset 20:01
2018-05-18 15:43:46 s_evening 18:30
2018-05-18 15:43:46 s_morning 08:00
2018-05-18 15:43:46 s_night 22:00
2018-05-18 15:43:46 s_noon 13:00
2018-05-18 15:43:46 s_sleep 22:30
2018-05-18 15:43:46 s_sunrise 05:38
2018-05-18 15:43:46 s_sunset 21:01
2018-05-18 15:43:46 s_wakeup 06:15
2018-05-18 15:43:43 savedate 2018-05-18 15:43:43
2018-05-18 09:11:09 state Initialized
2018-05-18 15:43:46 t_aftermidnight 00:01
2018-05-18 15:43:46 t_aftersunrise 01:00
2018-05-18 15:43:46 t_aftersunset 01:00
2018-05-18 15:43:46 t_beforemidnight 00:05
2018-05-18 15:43:46 t_beforesunrise 01:00
2018-05-18 15:43:46 t_beforesunset 01:00
2018-05-17 22:47:44 todayDesc --
2018-05-17 22:47:44 todayType workday
2018-05-18 15:43:46 today_0 06:15
2018-05-18 15:43:46 today_0_e enabled
2018-05-18 15:43:46 today_1 23:00
2018-05-18 15:43:46 today_1_e enabled
2018-05-17 22:47:44 tomorrowDesc --
2018-05-18 00:00:33 tomorrowType weekend
2018-05-18 15:43:46 tomorrow_0 off
2018-05-18 15:43:46 tomorrow_0_e enabled
2018-05-18 15:43:46 tomorrow_1 23:00
2018-05-18 15:43:46 tomorrow_1_e enabled
2018-05-18 15:43:24 tr_errmsg
2018-05-18 15:43:24 tr_housemode Normal
2018-05-18 15:43:42 tr_housephase Daytime
2018-05-18 15:43:13 tr_housestate Not Secured
2018-05-18 15:37:00 tr_housetime Afternoon
2018-05-17 22:47:44 tr_todayType Workday
2018-05-18 00:00:33 tr_tomorrowType Weekend
2018-05-17 22:47:44 tr_twodaysType Weekend
2018-05-18 15:43:46 tr_wake_0 off tomorrow
2018-05-18 15:43:46 tr_wake_1 23:00 today
2018-05-17 22:47:44 twodaysDesc --
2018-05-18 00:00:33 twodaysType weekend
TIMER:
YYY_aftermidnight:
HASH YYY
MODIFIER aftermidnight
NAME YYY_aftermidnight
YYY_check:
HASH YYY
MODIFIER check
NAME YYY_check
YYY_daytime:
HASH YYY
MODIFIER daytime
NAME YYY_daytime
YYY_nighttime:
HASH YYY
MODIFIER nighttime
NAME YYY_nighttime
Attributes:
room 00_Wohnung
timeHelper HouseTimeHelper
2018.05.13 19:55:00 1: ERROR evaluating {HouseTimeHelper('sunset')}: Undefined subroutine &main::HouseTimeHelper called at (eval 2895975) line 1.2018.05.13 19:55:00 2: YYY.dtimer.IF: {HouseTimeHelper('sunset')}: Undefined subroutine &main::HouseTimeHelper called at (eval 2895975) line 1.
Zitat von: Prof. Dr. Peter Henning am 11 August 2017, 19:58:33
In die eigene 99_myUtils (o.ä) kopieren und dort anpassen.
Ja.
LG
pah
Ok habe es doch gefunden... jetzt muss ich nur noch herausfinden warum der Fehler im Logfile kommt...
UPDATE: Warum auch immer, aber jetzt gehts :)
Jetzt kommen nur noch diverse Meldungen im Logfile:
2018.05.20 21:21:19 1: PERL WARNING: Use of uninitialized value $check in substitution (s///) at ./FHEM/95_YAAHM.pm line 1605.
2018.05.20 21:21:19 3: eval: {main::YAAHM_startDayTimer("YYY")}
2018.05.20 21:21:19 1: PERL WARNING: Use of uninitialized value $check in numeric le (<=) at ./FHEM/95_YAAHM.pm line 1606.
Jetzt muss ich mich leider noch mal melden.
Ich habe leider ab und zu das Problem das YAAHM nicht ausgeführt wird, bzw. meine Aktionen die ich in den HelperModulen eingetragen habe.
Ich vermute es hängt damit zusammen das nach einem Neustart von FHEM irgendetwas nicht korrekt läuft, denn ich bekomme immer die "speichern" Meldung mit diesen Einträgen (siehe Anhang)
Im Log ist nur zu sehen das ein ecxecuting stattfindet...
Hm - kenne ich nicht, weil bei mir die Definitionen nicht mit "modify" erfolgen.
Ich frage mich außerdem, wieso so häufige Neustarts nötig sein sollten ? Meine FHEM-Installationen werden vielleicht einmal im Monat nach Update neu gestartet - da gibt es keine Fehler.
LG
pah
Ich habe in den letzten Wochen mein FHEM komplett neu aufsetzen müssen. (selbst verschuldet)
Daher habe ich in letzter Zeit öfters neu gestartet. Und da ist es mir eben aufgefallen.
Heute jedoch habe ich bewusst nichts unternommen das einen Neustart nach sich zöge. Könnte theoretisch auch ein kurzer Stromausfall gewesen sein. Meine USV Überwachung habe ich noch nicht wieder aktiv...
Im Moment habe ich noch keine Idee wie ich dem Thema auf die Schliche kommen könnte.
Ich würde nur ungern wieder auf ,,at Definitionen" für meine Rollo Steuerung zurück gehren.
Ist das YAAHMFile vorhanden, schreibbar und im Dateisystem ? Oder in der configdb ?
LG
pah
Hallo pah,
unterstützt das Modul (noch?) nicht userreadings? Ich habe mir eines zusammengebaut, dass mir aus den Modulreadings s_sunset und s_sunrise eine Tageslänge ausrechnet. Das funktioniert auch vom Ergebnis richtig, doch erhalte ich im Log jedesmal Fehlermeldungen der Stufe 1:
2018.09.03 22:09:37 1: readingsUpdate(Timer,Tagesstunden,13.5333333333333) missed to call readingsBeginUpdate first.
2018.09.03 22:09:37 1: stacktrace:
2018.09.03 22:09:37 1: main::readingsBulkUpdate called by fhem.pl (4521)
2018.09.03 22:09:37 1: main::readingsEndUpdate called by ./FHEM/95_YAAHM.pm (2652)
2018.09.03 22:09:37 1: main::YAAHM_GetDayStatus called by ./FHEM/95_YAAHM.pm (3288)
2018.09.03 22:09:37 1: main::YAAHM_toptable called by ./FHEM/95_YAAHM.pm (3519)
2018.09.03 22:09:37 1: main::YAAHM_Longtable called by (eval 174126) (1)
2018.09.03 22:09:37 1: (eval) called by fhem.pl (1113)
2018.09.03 22:09:37 1: main::AnalyzePerlCommand called by ./FHEM/98_weblink.pm (99)
2018.09.03 22:09:37 1: main::weblink_FwFn called by ./FHEM/01_FHEMWEB.pm (1924)
2018.09.03 22:09:37 1: main::FW_showRoom called by ./FHEM/01_FHEMWEB.pm (1080)
2018.09.03 22:09:37 1: main::FW_answerCall called by ./FHEM/01_FHEMWEB.pm (533)
2018.09.03 22:09:37 1: main::FW_Read called by fhem.pl (3589)
2018.09.03 22:09:37 1: main::CallFn called by fhem.pl (724)
Ausschalten mit verbose=0 kann ich die Meldungen wie in einem Thread erwähnt nicht.
Eines will ich aber nicht vergessen: Danke für dieses tolle Modul, das mir einiges erheblich vereinfacht.
Christian
Muss ich mir ansehen, kann ein paar Tage dauern.
LG
pah
Hallöchen,
ist es eigentlich möglich, die Schaltzeiten selbst zu definieren bzw. im Tagesablauf eine oder mehrere "Custom-Zeilen" einzufügen? Also in etwa wie MyCustomMorningTime: {sunrise("REAL",-10,"06:00","07:00")}
Damit würde ich realisieren, dass die Rolläden insbesondere im Sommer nicht zu früh und im Winter nicht zu spät hochfahren. Sorry falls ich das in der Doku oder in diesem Thread übersehen haben sollte.
Grüße Ed
Nein, derzeit nicht, dynamische Offsets gibt es nicht. Ich denke mal darüber nach...
LG
pah
Hallo PAH,
nun bin ich auch auf YAAMH gestoßen, das bereits einige Vereinfachungen in meiner Haussteuerung (u.a. Lüftung, Heizung, Warmwasser, Sonnenkollektor in Abhängigkeit von Umwelt und Bedarf) gebracht hat.
Leider verstehe ich Reverenz und WIKI bezüglich vacation Device nicht und Suche auch im Forum führt mich nicht weiter. Wie sieht ein Vacation-Device aus - was muss ich da eintragen. Ein Feiertags-(Holiday)-Device habe ich erfolgreich eingebunden, der 3. Oktober wird wunderbar angekündigt.
Dabei bin ich gleich bei einer Anregung: Für die allermeisten Nutzer wird ein Feiertag "unter der Woche" wie ein Samstag oder Sonntag sein, d.h. entweder verschieben sich Schlafzeit am Abend zuvor nach hinten, Wecken fällt aus oder verschiebt sich aus und die Schlafzeit am Feiertag ist dann wieder die übliche Werktagszeit.
So ist es ja im Default-Wochenprofil angelegt. Ich stelle mir nun vor, dass bei einem Mittwoch, der auf einen Feiertag fällt, am Dienstag die spätere Freitagsschlafzeit und der Feiertag wie ein Sonntag behandelt wird. Das fände ich eine tolle Automatik.
Herzliche Grüße
Christian
Die devices in der Liste vacationDevices haben dasselbe Format wie die in specialDevices und holidayDevices - nämlich jeweils vom Typ Calendar oder holiday. Nur sind die Events, die in diesen Devices stehen, eben länger: Vom Ferienbeginn bis zum Ferienende.
Die vorgeschlagene Automatik finde ich aber nicht gut. Denn meine Vorlesungen verschieben sich am Dienstag eben nicht, wenn Mittwoch Feiertag ist.
LG
pah
Hallo pah,
vielen Dank für die schnelle Antwort in Sachen Vacation-Device. Nun habe ich es verstanden.
Bei der "Automatik" hast Du mich leider bei einer schlampigen Formulierung erwischt - habe meinen Eintrag nachgebessert. Natürlich verschiebt sich auch bei mir die Arbeitszeit nicht durch den morgigen Feiertag. Aber heute Abend werde ich wohl länger machen wie am Freitag und morgen früh länger schlafen wir an einem Sonntag und morgen Abend wieder auf die Werktagsschlafenszeit zurückkehren.
Aber vielleicht gelingt mir das ja nachzubilden mit einem zusätzlich Feiertagswochenprofil.
Einen schönen vorlesungsfreien 3. Oktober :-)
Christian
Edit 5.10.: Falls jemand dieselbe Idee umsetzen will:
Mit den Dummys heute, morgen, Wecken und Schlafen habe ich das umgesetzt und rufe das als Helper um 00:01 jeden Tag ausführen. "nied" ist mein Holiday-Device für die Feiertage in Niedersachsen, dort trage ich auch meine Urlaube ein.
DOELSEIF ([00:01]) (IF ("get nied today" eq "none") (set heute Arbeitstag,set Schlafen 22:00,set Aufstehen 06:00) ELSE (set heute arbeitsfrei,set Aufstehen 7:00,set Schlafen 23:00),IF ("get nied tomorrow" ne "none") (set morgen arbeitsfrei,set Schlafen 23:00) ELSE (set morgen Arbeitstag)) ## was ist morgen und heute für ein Tagestyp. Sonderfall
Schlafen am arbeitsfreien Tag von dem Arbeitstag
Hier das Beispiel eines Feiertags-Spätaufstehers. Will man an Wochenende oder Feiertag besonders viel erleben, wären die Schlafenszeiten entsprechend anzupassen :-)[/code]
Babble nutzen. Ich spreche einfach in eines meiner Tablets "Schlafen um dreiundzwanzig uhr". Oder gebe das in Telegram ein. Oder in eines meiner Amazon Echo Devices.
Im konkreten Fall allerdings: "Wecken um 6 uhr dreißig", denn ich will bei Sonnenaufgang am ersten Abschlag stehen...
LG
pah
Hallo pah,
erstmal vielen Dank für das tolle Modul!
Ich habe das Modul testweise auf 2 Fhem Instanzen installiert und hänge bei der Nutzung der calendar devices. Definiere ich ein holiday device mittels (attr holidayDevices ...) mit den DE-Feiertagen werden die Feiertage entsprechend ausgewertet und so wird ggf. entsprechend der Priorität aus einem Werktag ein Feiertag - klappt.
Nutze ich einen Kalender mit Demo Feiertagen (attr vacationDevices ...) ändert sich leider nicht der Tages-Typ so wie im Wiki beschrieben. Um auszuschliessen, dass es mit meinen bisher verwendeten Kalendern (Ferienkalender, google etc.) zusammenhängt, habe ich mir einen Test Kalender erstellt und als ics exportiert. Leider bleibt das Ergebnis das gleiche ... nun hänge ich an dem Punkt - liegts am Modul oder ist meine Definition der Ferientage fehlerhaft.
Anbei die def meines YAAHM Devices:
defmod myYAAHM YAAHM
attr myYAAHM room Labor,ProfileRoom
attr myYAAHM vacationDevices TestCal
Hier noch die Calendar def:
defmod TestCal Calendar ical file Calendar/test.ics
attr TestCal room Labor
Auszug aus dem fhem.log:
...
2018.10.20 00:00:33 1: [YAAHM_updater] on device myYAAHM called for this day
2018.10.20 00:00:33 2: get TestCal full is deprecated and will be removed soon. Use get TestCal events instead.
2018.10.20 00:00:33 3: [Astro] No latitude attribute set in global device, using 50.0°
2018.10.20 00:00:33 3: [Astro] No longitude attribute set in global device, using 10.0°
2018.10.20 00:00:33 3: [Astro] No altitude attribute set in global device, using 0.0 m above sea level
2018.10.20 00:00:33 3: [Astro] No latitude attribute set in global device, using 50.0°
2018.10.20 00:00:33 3: [Astro] No longitude attribute set in global device, using 10.0°
...
Ich stehe irgendwie gerade auf dem Schlauch und könnte einen Schubser vertragen.
Danke für die Hilfe.
Gruss hoods
Kann ich vor nächster Woche nicht testen.
LG
pah
Hallo zusammen,
ich mache ja regelmässig FHEM Updates, aber nach den Updates heute ist YAAHM nicht mehr unter Profiles zu finden.
Das war dabei:
2018.10.29 14:48:48 1: UPD FHEM/00_FBAHAHTTP.pm
2018.10.29 14:48:48 1: UPD FHEM/01_FHEMWEB.pm
2018.10.29 14:48:48 1: UPD FHEM/10_MYSENSORS_DEVICE.pm
2018.10.29 14:48:48 1: UPD FHEM/10_RESIDENTS.pm
2018.10.29 14:48:48 1: UPD FHEM/38_netatmo.pm
2018.10.29 14:48:48 1: UPD FHEM/42_AptToDate.pm
2018.10.29 14:48:48 1: UPD FHEM/49_SSCam.pm
2018.10.29 14:48:48 1: UPD FHEM/57_CALVIEW.pm
2018.10.29 14:48:48 1: UPD FHEM/70_PIONEERAVR.pm
2018.10.29 14:48:48 1: UPD FHEM/70_ZoneMinder.pm
2018.10.29 14:48:48 1: UPD FHEM/74_XiaomiBTLESens.pm
2018.10.29 14:48:48 1: UPD FHEM/88_HMCCU.pm
2018.10.29 14:48:48 1: UPD FHEM/88_HMCCUDEV.pm
2018.10.29 14:48:48 1: UPD FHEM/89_FULLY.pm
2018.10.29 14:48:48 1: UPD FHEM/93_DbLog.pm
2018.10.29 14:48:48 1: UPD FHEM/93_DbRep.pm
2018.10.29 14:48:48 1: UPD FHEM/93_Log2Syslog.pm
2018.10.29 14:48:48 1: UPD FHEM/96_allowed.pm
2018.10.29 14:48:48 1: UPD FHEM/98_GEOFANCY.pm
2018.10.29 14:48:48 1: UPD FHEM/98_MSwitch.pm
2018.10.29 14:48:48 1: UPD FHEM/98_SmarterCoffee.pm
2018.10.29 14:48:48 1: UPD FHEM/98_Verkehrsinfo.pm
2018.10.29 14:48:48 1: UPD FHEM/98_logProxy.pm
2018.10.29 14:48:48 1: UPD FHEM/RESIDENTStk.pm
2018.10.29 14:48:48 1: UPD FHEM/UConv.pm
2018.10.29 14:48:48 1: UPD FHEM/lib/74_AMADtaskerset_4.2.4.prj.xml
2018.10.29 14:48:48 1: UPD www/pgm2/f18.js
Hab ich was übersehen?
Der Profileroom ist komplett leer.
Habe über Everything die YAAHM Devices in einen anderen Raum gepackt, ist in Ordnung aber normal ist das nicht oder?
VG Patrick
Hallo Patrick,
hängt mit folgenden Post zusammen.
https://forum.fhem.de/index.php/topic,92433.15.html
Der Umgang mit hiddenroom wurde in 01_FHEMWEB.pm angepasst. Kein Aufruf mehr über direkte Eingabe der URL.
Habe folgende Module auf die ich nicht mehr direkt zugreifen kann. Alarmanlage, YAAHM und Babble. :(
Bei meinem FLOORPLAN geht es noch, kenne aktuell aber den Unterschied noch nicht.
Einzige Lösung die bei mir geholfen hat ist ältere Version von 01_FHEMWEB.pm herstellen. :)
Die Passage in 01_FHEMWEB.pm mit der Änderung ist wie folgt.
code geändert ab marker 1824 von
return 0 if(!$FW_room);
zu
return 0 if(!$FW_room ||
($FW_hiddenroom{$FW_room} &&
AttrVal($FW_wname, "defaultRoom", "") ne $FW_room)); #92433
Grüße Mark
Achtung:
Der Fehler wird derzeit beim Update eingebaut. Wenn er auftritt, bitte auf die alte Version von 01_FHEMWEB zurückgehen.
Problem ist in Arbeit.
LG
pah
Tut wieder....nach Update auf neueste 01_FHEMWEB Version.
Rudi König hat die Änderung wieder rückgängig gemacht, das Problem ist für den Moment behoben. Er möchte sie aber doch wieder einführen. Bitte deshalb hier an der
Abstimmung beteiliigen:
https://forum.fhem.de/index.php/topic,92615.0.html
LG
pah
Edit: Ist erledigt, eine andere Lösung wurde gefunden.
Ich habe eine Frage zu dem Modul, pah. Mir gefällt die Sammlung diverser at's DOIF usw, aber ich komme nicht klar. Ich habe kurz vor Mitternacht folgende Aufgabe
define loggen *23:57:00 { my $d1 = 'Gas: '.ReadingsVal('Gasrechner', 'Heizungskeller_Gas_EnergyCostDay',''); my $d2 = ' Min: '.ReadingsVal('BresserTemeo_1', 'tmin', ''); my $d3 = ' Max: '.ReadingsVal('BresserTemeo_1', 'tmax',''); fhem('set GasTemperaturRegression $d1 $d2 $d3'); }
und war nun davon ausgegangen, dass ich einfach den hinteren Teil in das Wochenprofil "vor Mitternacht" eintrage. Das geht aber bei mir nicht. Hast Du eine Idee, was ich hier falsch mache? Der Logfile sagt
2018.11.09 21:20:51 1: ERROR evaluating {main::YAAHM_setParm("Profil","dt","beforemidnight","undef","00:02","{ my $d1 = 'Gas: '.ReadingsVal('Gasrechner', 'Heizungskeller_Gas_EnergyCostDay',''); my $d2 = ' Min: '.ReadingsVal('BresserTemeo_1', 'tmin', ''); my $d3 = ' Max: '.ReadingsVal('BresserTemeo_1', 'tmax',''); fhem('set GasTemperaturRegression $d1 $d2 $d3'); }",";")}: Global symbol "$d1" requires explicit package name at (eval 609645) line 1.
Global symbol "$d2" requires explicit package name at (eval 609645) line 1.
Global symbol "$d3" requires explicit package name at (eval 609645) line 1.
Global symbol "$d1" requires explicit package name at (eval 609645) line 1.
Global symbol "$d2" requires explicit package name at (eval 609645) line 1.
Global symbol "$d3" requires explicit package name at (eval 609645) line 1.
und ich war der Meinung, dass ich das mit der my-Deklaration doch behoben hätte?!
Die Dollarzeichen sollten escaped werden, also \$.
LG
pah
habe ich jetzt, und das wird angenommen - danke. In dem dummy lese ich dann aber
Internals:
NAME GasTemperaturRegression
NR 76
STATE $d1 $d2 $d3
TYPE dummy
READINGS:
2018-11-09 23:57:00 state $d1 $d2 $d3
Attributes:
group Messen
room Wetter
und müsste der state jetzt nicht die Werte statt der Variablen $d1 etc haben?
Öh, da habe ich mich wohl selbst ausgetrickst, das war zu schnell...
Mal experimentieren, bitte mal im letzten Teil (also dem fhem-Aufruf) die \ weglassen.
LG
pah
Also im Log steht, dass er das wohl gesetzt hat:
2018.11.11 23:59:00 1: [YAAHM_time] executing { my $d1 = 'Gas: '.ReadingsVal('Gasrechner', 'Heizungskeller_Gas_EnergyCostDay',''); my $d2 = ' Min: '.ReadingsVal('BresserTemeo_1', 'tmin', ''); my $d3 = ' Max: '.ReadingsVal('BresserTemeo_1', 'tmax',''); fhem('set GasTemperaturRegression $d1 $d2 $d3'); }
Das Reading ist aber unverändert (gestriger Wert).
Vielleicht sage ich mal, was ich eigentlich will: Ich kriege ja aus der Perl-Rechnung drei Werte heraus (Gasrechner, Temperaturen) und ich möchte die direkt in einen Logfile schreiben, um Mitternacht. Ich habe das über einen Umweg eines dummys gemacht, weil ich mir den Wert auch anzeigen lassen möchte.
Zitatfhem('set GasTemperaturRegression $d1 $d2 $d3');
Nimm doppelte statt einfacher Anführungszeichen.
hem("set GasTemperaturRegression $d1 $d2 $d3");
Gruß
Hans
Hm, da kam das hier im Logfile:
2018.11.12 09:57:36 1: ERROR evaluating {main::YAAHM_setParm("Profil","dt","beforemidnight","undef","00:01","{ my $d1 = 'Gas: '.ReadingsVal('Gasrechner', 'Heizungskeller_Gas_EnergyCostDay',''); my $d2 = ' Min: '.ReadingsVal('BresserTemeo_1', 'tmin', ''); my $d3 = ' Max: '.ReadingsVal('BresserTemeo_1', 'tmax',''); fhem('set GasTemperaturRegression $d1 $d2 $d3'); }",";")}: Global symbol "$d1" requires explicit package name at (eval 845981) line 1.
Global symbol "$d2" requires explicit package name at (eval 845981) line 1.
Global symbol "$d3" requires explicit package name at (eval 845981) line 1.
Global symbol "$d1" requires explicit package name at (eval 845981) line 1.
Global symbol "$d2" requires explicit package name at (eval 845981) line 1.
Global symbol "$d3" requires explicit package name at (eval 845981) line 1.
Ich probiere das heute abend dennoch mal aus.
Nein, gemeint ist: Doppelte Anführungszeichen im letzten fhem(---). Könnte gehen, muss ich auch probieren.
LG
pah
Setmagic wird das Problem lösen, oder
set GasTemperaturRegression Gas: [Gasrechner:Heizungskeller_Gas_EnergyCostDay] Min: [BresserTemeo_1:tmin] Max: [BresserTemeo_1:tmax]
Noch eine Frage, weil ich gern komplett auf das Modul umsteigen möchte: Kann ich auch Abfragen einbauen? Also nach Sonnenuntergang, wenn reading>irgendwas, dann mach dies und das? Ginge da die DOIF-Notation oder muss ich das mit Perl nachbauen?
Zitat von: Prof. Dr. Peter Henning am 23 Oktober 2018, 07:57:52
Kann ich vor nächster Woche nicht testen.
LG
pah
Hallo pah,
ich konnte mein Kalender Problem (https://forum.fhem.de/index.php/topic,75206.msg848604.html#msg848604) leider bisher nicht lösen. Ich habe YAAHM versuchsweise noch auf einem rpi3 und odroid C2 mit Fhem5.9 installiert und nutze wieder einen google Calender als Calender Device aber das Ergebnis ist das gleiche.
Mit eingebundenem Kalender sollte doch tomorrowType kurz nach Mitternacht auf "Ferien" gesetzt werden, wenns ich das Modul richtig verstehe.
Abfrage des Kalenders:
{Calendar_Get($defs{"googleCal"},"get","full","mode=alarm|start|upcoming")}
0mg84lja8i81hrhe7jlee0vb23googlecom start 09.11.2018 00:00-01.12.2018 00:00 Demo Ferien
F_2018_termin5be39d5401b1aschulferienorg upcoming 21.12.2018 00:00-05.01.2019 00:00 Weihnachtsferien 2018 Nordrhein-Westfalen
F_2019_termin5be39d54b4941schulferienorg upcoming 15.04.2019 00:00-28.04.2019 00:00 Osterferien 2019 Nordrhein-Westfalen
F_2019_termin5be39d54b49d3schulferienorg upcoming 11.06.2019 00:00-12.06.2019 00:00 Pfingstferien 2019 Nordrhein-Westfalen
F_2019_termin5be39d54b4a4dschulferienorg upcoming 15.07.2019 00:00-28.08.2019 00:00 Sommerferien 2019 Nordrhein-Westfalen
F_2019_termin5be39d54b4ac2schulferienorg upcoming 14.10.2019 00:00-27.10.2019 00:00 Herbstferien 2019 Nordrhein-Westfalen
Es sieht alles nach einem Benutzerfehler aus aber ich seh den Wald vor lauter Bäumen nicht. Bin für jeden Tipp dankbar.
Gruss hoods
@andies: Nicht DOIF, sondern IF als FHEM-Befehl. Siehe commandref.
LG
pah
Klappt, danke. Noch eine Anfrage. Besteht denn die Möglichkeit, dass das Modul auch um HOIRZON-Werte erweitert wird? Also ich meine das wie folgt. Derzeit gibt es sunset+01:00 als Möglichkeit; ich hätte gern sunset+6 Grad unter Horizont. Habe ich überhaupt verständlich machen können, was ich meine?
Ich habe aktuell die Version 3.0 im Test.
1. Diese neue Version kennt eine neue Kategorie, genannte Geräte-Aktionen. Dort kann man beliebige Schaltvorgänge definieren, sagen wir "Rollladen_WG_hoch". Und diese mit einem der YAAHM-internen Events verbinden - sagen wir mit "Sonnenaufgang" - und dazu ein Zeitintervall "Frühestens" bis "Spätestens" angeben
2. Diese neue Version erlaubt auch, mittels eines Attributes "sunset" bzw. "sunrise" diejenige Definition aus dem Astro-Device anzugeben, die man für "seinen" Sonnenaufgang benötigt. Also z.B. auch "CustomTwilightMorning", und damit einen beliebigen Horizontwinkel.
LG
pah
ZitatDie Checkboxen Fer und Fei geben an, ob das betreffende Wochen-Profil (und damit der Timer) auch an den Tagestypen Ferientag und Feiertag aktiv ist.
Hierzu habe ich eine Frage. Ich möchte gern, dass ein Befehl am Wochenende
und an Feiertagen ausgewählt wird. Wenn ich den Befehl jetzt am Sonntag eintrage, würde er dann auch an einem Wochentag ausgeführt, wenn dieser er Ferientag ist?
Wenn nein: gäbe es da im Modul eine Lösung?
Ich bin mir nicht ganz sicher, ob ich das verstehe - geht es um Ferientage (vacationdevices) oder Feiertage (holidayDevices)? Beides ist unabhängig von der Eigenschaft "Wochenende"=(Sa/So).
ZitatWochenende und an Feiertagen
Gemeint ist wohl das logische ODER. Und da muss ich verneinen, es gibt keine direkte Lösung, einen Befehl nur an den Tagen (Mo-Fr) auszuführen, die gleichzeitig Feiertage oder Ferientage sind.
Beispile: Der Rollladen soll immer dann später aufgehen, wenn entweder Wochenende ode unter der Woche ein Feiertag ist
Mit der neuen im Test befindlichen Version wäre das machbar: Dann wird eine Geräteaktion eingetragen, die an jedem Tag spätestens um 9:30 ausgeführt wird. Und mit einem Wochenprofile gekoppelt, das sie normalerweise unter der Woche sagen wir um 7:30 ausführt, aber eben nicht an Feiertagen.
Ich könnte allerdings noch eine weitere Checkbox einbauen, die die "normale" Ausführung anzeigt. Wenn man diese dann abwählt, würde das _nur_ an Tagen mit Fer, Fei etc. ausgeführt.
LG
pah
Genau, es geht mir um das logische ODER: "Wähle Aktion am Samstag ODER am Feiertag". Das schaue ich mir dann mal an, in der neuen Version.
Noch eine Frage. Bestünde denn die Möglichkeit, bei den Wochenprofilen auch After-sunset und dergleichen Variablen einzuführen? Ein Beispiel: "Fahre Rollos nur am Freitag 10 Minuten nach Sonnenuntergang hoch", nicht aber am Montag und auch nicht pünktlich zum Sonnenuntergang?
pah, ich schreibe etwas in der Wikipedia herum; bitte mal kontrollieren, ob ich das richtig wiedergebe.
Noch eine Frage zu einem Problem, das ich vorher hatte. Vielleicht kann man das nämlich wie folgt lösen.
ZitatKann ich Befehle eingeben, die nur an einem Feiertag ausgeführt werden?
Ich würde einen Wochenprofil "IstFeiertag" definieren, dann Arbeitstag abwählen, Feiertag auswählen und dort die nur an einem Feiertag auszuwählenden Befehle notieren. Wenn ich nun $we "nachbauen" will, würde ich die $we-Befehle am Wochenende eintragen und das von mir gerade ausgedachte Wochenprofil Feiertag hinzufügen.
Oder bin ich da auf dem Holzweg?
Und noch eine Frage habe ich. Ich habe im Profil bei Mitternacht stehen
setreading wetter precip_yesterday [wetter:precip_today];setreading GasTemperaturRegression state Gas: [Gasrechner:Heizungskeller_Gas_EnergyCostDay] Min: [BresserTemeo_1:tmin] Max: [BresserTemeo_1:tmax]
und komischerweise klappt das nicht. Im reading steht dann auch etwas nach Mitternacht, genauer
Internals:
NAME GasTemperaturRegression
NR 76
STATE Gas: 0.255 Min: 05.5 Max: 12.3
2018.11.15 00:00:01 2: Deleting Flightradar24-2018-11-12.log
2018.11.15 00:00:33 1: [YAAHM_updater] on device Profil called for this day
2018.11.15 00:00:33 2: get Schulferien full is deprecated and will be removed soon. Use get Schulferien events instead.
2018.11.15 05:50:00 1: [YAAHM_time] executing action set Sonoff_s20_2 on-for-timer 2400 for timer wakeup
2018.11.15 06:00:00 1: [YAAHM_time] executing { LogFileEintraegeSenden()}
TYPE dummy
READINGS:
2018-11-15 06:00:00 state Gas: 0.255 Min: 05.5 Max: 12.3
2018.11.15 00:00:01 2: Deleting Flightradar24-2018-11-12.log
2018.11.15 00:00:33 1: [YAAHM_updater] on device Profil called for this day
2018.11.15 00:00:33 2: get Schulferien full is deprecated and will be removed soon. Use get Schulferien events instead.
2018.11.15 05:50:00 1: [YAAHM_time] executing action set Sonoff_s20_2 on-for-timer 2400 for timer wakeup
2018.11.15 06:00:00 1: [YAAHM_time] executing { LogFileEintraegeSenden()}
Attributes:
group Messen
room Wetter
Mich verwirrt, dass da im STATE etwas anderes steht. Hast Du eine Idee, wo ich den Fehler suchen kann? Da ist irgendwas völlig faul.
PS Noch der Logfile
2018.11.14 23:55:00 1: [YAAHM_time] executing setreading wetter precip_yesterday [wetter:precip_today];setreading GasTemperaturRegression state Gas: [Gasrechner:Heizungskeller_Gas_EnergyCostDay] Min: [BresserTemeo_1:tmin] Max: [BresserTemeo_1:tmax]
2018.11.15 00:00:01 2: Deleting Flightradar24-2018-11-12.log
2018.11.15 00:00:33 1: [YAAHM_updater] on device Profil called for this day
2018.11.15 00:00:33 2: get Schulferien full is deprecated and will be removed soon. Use get Schulferien events instead.
2018.11.15 05:50:00 1: [YAAHM_time] executing action set Sonoff_s20_2 on-for-timer 2400 for timer wakeup
2018.11.15 06:00:00 1: [YAAHM_time] executing { LogFileEintraegeSenden()}
2018.11.15 06:00:00 1: [YAAHM_today] on device Profil called for this day
2018.11.15 06:05:00 1: [YAAHM_time] executing action set Sonoff_s20_2 on-for-timer 2400 for timer wakeup
2018.11.15 06:08:11 2: get Schulferien full is deprecated and will be removed soon. Use get Schulferien events instead.
2018.11.15 06:08:11 2: get Schulferien full is deprecated and will be removed soon. Use get Schulferien events instead.
2018.11.15 06:08:14 2: get Schulferien full is deprecated and will be removed soon. Use get Schulferien events instead.
2018.11.15 06:08:14 2: get Schulferien full is deprecated and will be removed soon. Use get Schulferien events instead.
2018.11.15 06:08:16 2: get Schulferien full is deprecated and will be removed soon. Use get Schulferien events instead.
2018.11.15 06:08:17 2: get Schulferien full is deprecated and will be removed soon. Use get Schulferien events instead.
2018.11.15 07:29:00 1: [YAAHM_time] executing get Kamera1,Kamera2,Kamera3,Kamera4 image
2018.11.15 09:54:21 2: get Schulferien full is deprecated and will be removed soon. Use get Schulferien events instead.
2018.11.15 09:54:21 2: get Schulferien full is deprecated and will be removed soon. Use get Schulferien events instead.
2018.11.15 09:54:23 2: get Schulferien full is deprecated and will be removed soon. Use get Schulferien events instead.
2018.11.15 09:54:23 2: get Schulferien full is deprecated and will be removed soon. Use get Schulferien events instead.
2018.11.15 09:54:24 2: get Schulferien full is deprecated and will be removed soon. Use get Schulferien events instead.
2018.11.15 09:54:25 2: get Schulferien full is deprecated and will be removed soon. Use get Schulferien events instead.
2018.11.15 09:55:35 2: get Schulferien full is deprecated and will be removed soon. Use get Schulferien events instead.
2018.11.15 09:55:35 2: get Schulferien full is deprecated and will be removed soon. Use get Schulferien events instead.
2018.11.15 09:55:36 2: get Schulferien full is deprecated and will be removed soon. Use get Schulferien events instead.
2018.11.15 09:55:37 2: get Schulferien full is deprecated and will be removed soon. Use get Schulferien events instead.
2018.11.15 09:55:38 2: get Schulferien full is deprecated and will be removed soon. Use get Schulferien events instead.
2018.11.15 09:55:38 2: get Schulferien full is deprecated and will be removed soon. Use get Schulferien events instead.
2018.11.15 09:57:20 2: get Schulferien full is deprecated and will be removed soon. Use get Schulferien events instead.
2018.11.15 09:57:20 2: get Schulferien full is deprecated and will be removed soon. Use get Schulferien events instead.
2018.11.15 09:57:36 2: get Schulferien full is deprecated and will be removed soon. Use get Schulferien events instead.
2018.11.15 09:57:37 2: get Schulferien full is deprecated and will be removed soon. Use get Schulferien events instead.
2018.11.15 09:57:38 2: get Schulferien full is deprecated and will be removed soon. Use get Schulferien events instead.
2018.11.15 09:57:38 2: get Schulferien full is deprecated and will be removed soon. Use get Schulferien events instead.
2018.11.15 09:57:40 2: get Schulferien full is deprecated and will be removed soon. Use get Schulferien events instead.
2018.11.15 09:57:40 2: get Schulferien full is deprecated and will be removed soon. Use get Schulferien events instead.
2018.11.15 10:00:08 2: get Schulferien full is deprecated and will be removed soon. Use get Schulferien events instead.
2018.11.15 10:00:08 2: get Schulferien full is deprecated and will be removed soon. Use get Schulferien events instead.
2018.11.15 10:00:09 1: RMDIR: ./restoreDir/save/2018-11-12
2018.11.15 10:00:16 2: get Schulferien full is deprecated and will be removed soon. Use get Schulferien events instead.
2018.11.15 10:00:16 2: get Schulferien full is deprecated and will be removed soon. Use get Schulferien events instead.
2018.11.15 10:00:18 2: get Schulferien full is deprecated and will be removed soon. Use get Schulferien events instead.
2018.11.15 10:00:18 2: get Schulferien full is deprecated and will be removed soon. Use get Schulferien events instead.
2018.11.15 10:00:20 2: get Schulferien full is deprecated and will be removed soon. Use get Schulferien events instead.
2018.11.15 10:00:20 2: get Schulferien full is deprecated and will be removed soon. Use get Schulferien events instead.
2018.11.15 10:01:15 2: get Schulferien full is deprecated and will be removed soon. Use get Schulferien events instead.
2018.11.15 10:01:15 2: get Schulferien full is deprecated and will be removed soon. Use get Schulferien events instead.
2018.11.15 10:01:18 2: get Schulferien full is deprecated and will be removed soon. Use get Schulferien events instead.
2018.11.15 10:01:18 2: get Schulferien full is deprecated and will be removed soon. Use get Schulferien events instead.
2018.11.15 10:01:20 2: get Schulferien full is deprecated and will be removed soon. Use get Schulferien events instead.
2018.11.15 10:01:21 2: get Schulferien full is deprecated and will be removed soon. Use get Schulferien events instead.
Kann ich so nicht nachstellen - bei mir geht der Befehl get <calendar-device> full <argument> ohne Fehlermeldung. Ist das vielleicht ein holiday-device ?
Edit: Habe es gefunden, eine etwas kryptische Änderung im Modul Calendar erfordert einen Fix von YAAHM. Ist in Arbeit
LG
pah
noch eine Frage. Hatte heute morgen das hier im Log
2018.11.17 00:00:33 1: [YAAHM_updater] on device Profil called for this day
2018.11.17 06:00:00 1: [YAAHM_time] executing { LogFileEintraegeSenden()}
2018.11.17 06:00:00 1: [YAAHM_today] on device Profil called for this day
2018.11.17 07:32:00 1: [YAAHM_time] executing get Kamera1,Kamera2,Kamera3,Kamera4 image
2018.11.17 08:00:00 1: readingsUpdate(Profil,next_3,) missed to call readingsBeginUpdate first.
2018.11.17 08:00:00 1: eval: {YAAHM_time('Profil','timer_3',1)}
2018.11.17 08:00:00 1: stacktrace:
2018.11.17 08:00:00 1: main::readingsBulkUpdate called by ./FHEM/95_YAAHM.pm (1216)
2018.11.17 08:00:00 1: main::YAAHM_time called by (eval 1320148) (1)
2018.11.17 08:00:00 1: (eval) called by fhem.pl (1115)
2018.11.17 08:00:00 1: main::AnalyzePerlCommand called by ./FHEM/98_DOIF.pm (1553)
2018.11.17 08:00:00 1: main::ParseCommandsDoIf called by ./FHEM/98_DOIF.pm (1974)
2018.11.17 08:00:00 1: main::DOIF_cmd called by ./FHEM/98_DOIF.pm (2233)
2018.11.17 08:00:00 1: main::DOIF_Trigger called by ./FHEM/98_DOIF.pm (2466)
2018.11.17 08:00:00 1: main::DOIF_TimerTrigger called by fhem.pl (3142)
2018.11.17 08:00:00 1: main::HandleTimeout called by fhem.pl (649)
2018.11.17 08:00:00 1: [YAAHM_time] executing action set RolladenWohnz1 oeffnen;sleep 0.7;set RolladenAZ oeffnen;sleep 0.7;set RolladenWohnz2 oeffnen for timer timer_3
Ist das korrekt?
Gesendet von iPad mit Tapatalk Pro
Den Fehler habe ich im neuen Beta schon behoben.
Ich hänge also mal die beiden Dateien hier an zum Testen.
1. Neues Feature Geräteaktionen
2. Anpassung an die Änderungen in Calendar
3. Attribute "sunset" bzw. "sunrise" zur Auswahl echte Aufgangszeiten, Civil, Nautical, Astronomical oder Custom Twilight
4. Fix des o.a. Fehlers.
Bei den Geräteaktionen bin ich noch am Experimentieren, das ist noch nicht ganz fertig.
LG
pah
Danke, probiere ich nun aus, wunderbar.
Noch eine Frage: Bestünde die Möglichkeit (ich weiß, doppelter Konjunktiv :-) dass man ein Wochenprofil anlegt, das nur an einem Feiertag/Ferientag ausgeführt wird? Derzeit kann man den Werktag doch in der Checkbox nicht ausstellen, oder?
Diese angefragte Option würde ich auch sehr gerne nutzen.
Christian
Hmmm - machbar wäre von der Programmstruktur her, dass man in der Zeile "Aktiv" einen zusätzlichen Radiobutton hat, der zwischen "auch an" und "nur an" wechselt.
Das wäre aber trotzdem noch eine Verschwendung von Ressourcen - weil man ja in der Regel kein ganzes Wochenprofil braucht, wenn etwas speziell an einem Feiertag oder Ferientag ausgeführt werden soll. Oder doch ? Soll z.B. ein Sonntag, der auch Feiertag ist, anders behandelbar sein als ein Montag, der Feiertag ist ?
LG
pah
Bei mir nicht: da spielt der aktuelle Wochentag keine Rolle, wenn er denn ein Feier- oder Ferientag ist.
Gesendet von iPad mit Tapatalk Pro
Die 3Beta von gestern erzeugte heute Nacht bei mir diese Logs:
2018.11.18 00:00:33 1: [YAAHM_updater] on device Timer called for this day
2018.11.18 00:01:00 1: readingsUpdate(Timer,prev_housetime,beforemidnight) missed to call readingsBeginUpdate first.
2018.11.18 00:01:00 1: stacktrace:
2018.11.18 00:01:00 1: main::readingsBulkUpdate called by ./FHEM/95_YAAHM.pm (1241)
2018.11.18 00:01:00 1: main::YAAHM_time called by (eval 127356) (1)
2018.11.18 00:01:00 1: (eval) called by fhem.pl (1116)
2018.11.18 00:01:00 1: main::AnalyzePerlCommand called by ./FHEM/98_DOIF.pm (1553)
2018.11.18 00:01:00 1: main::ParseCommandsDoIf called by ./FHEM/98_DOIF.pm (1974)
2018.11.18 00:01:00 1: main::DOIF_cmd called by ./FHEM/98_DOIF.pm (2233)
2018.11.18 00:01:00 1: main::DOIF_Trigger called by ./FHEM/98_DOIF.pm (2466)
2018.11.18 00:01:00 1: main::DOIF_TimerTrigger called by fhem.pl (3144)
2018.11.18 00:01:00 1: main::HandleTimeout called by fhem.pl (649)
2018.11.18 00:01:00 1: readingsUpdate(Timer,next_housetime,aftermidnight) missed to call readingsBeginUpdate first.
2018.11.18 00:01:00 1: stacktrace:
2018.11.18 00:01:00 1: main::readingsBulkUpdate called by ./FHEM/95_YAAHM.pm (1242)
2018.11.18 00:01:00 1: main::YAAHM_time called by (eval 127356) (1)
2018.11.18 00:01:00 1: (eval) called by fhem.pl (1116)
2018.11.18 00:01:00 1: main::AnalyzePerlCommand called by ./FHEM/98_DOIF.pm (1553)
2018.11.18 00:01:00 1: main::ParseCommandsDoIf called by ./FHEM/98_DOIF.pm (1974)
2018.11.18 00:01:00 1: main::DOIF_cmd called by ./FHEM/98_DOIF.pm (2233)
2018.11.18 00:01:00 1: main::DOIF_Trigger called by ./FHEM/98_DOIF.pm (2466)
2018.11.18 00:01:00 1: main::DOIF_TimerTrigger called by fhem.pl (3144)
2018.11.18 00:01:00 1: main::HandleTimeout called by fhem.pl (649)
2018.11.18 00:01:00 1: readingsUpdate(Timer,housetime,aftermidnight) missed to call readingsBeginUpdate first.
2018.11.18 00:01:00 1: stacktrace:
2018.11.18 00:01:00 1: main::readingsBulkUpdate called by ./FHEM/95_YAAHM.pm (1243)
2018.11.18 00:01:00 1: main::YAAHM_time called by (eval 127356) (1)
2018.11.18 00:01:00 1: (eval) called by fhem.pl (1116)
2018.11.18 00:01:00 1: main::AnalyzePerlCommand called by ./FHEM/98_DOIF.pm (1553)
2018.11.18 00:01:00 1: main::ParseCommandsDoIf called by ./FHEM/98_DOIF.pm (1974)
2018.11.18 00:01:00 1: main::DOIF_cmd called by ./FHEM/98_DOIF.pm (2233)
2018.11.18 00:01:00 1: main::DOIF_Trigger called by ./FHEM/98_DOIF.pm (2466)
2018.11.18 00:01:00 1: main::DOIF_TimerTrigger called by fhem.pl (3144)
2018.11.18 00:01:00 1: main::HandleTimeout called by fhem.pl (649)
2018.11.18 00:01:00 1: readingsUpdate(Timer,tr_housetime,Nach Mitternacht) missed to call readingsBeginUpdate first.
2018.11.18 00:01:00 1: stacktrace:
2018.11.18 00:01:00 1: main::readingsBulkUpdate called by ./FHEM/95_YAAHM.pm (1244)
2018.11.18 00:01:00 1: main::YAAHM_time called by (eval 127356) (1)
2018.11.18 00:01:00 1: (eval) called by fhem.pl (1116)
2018.11.18 00:01:00 1: main::AnalyzePerlCommand called by ./FHEM/98_DOIF.pm (1553)
2018.11.18 00:01:00 1: main::ParseCommandsDoIf called by ./FHEM/98_DOIF.pm (1974)
2018.11.18 00:01:00 1: main::DOIF_cmd called by ./FHEM/98_DOIF.pm (2233)
2018.11.18 00:01:00 1: main::DOIF_Trigger called by ./FHEM/98_DOIF.pm (2466)
2018.11.18 00:01:00 1: main::DOIF_TimerTrigger called by fhem.pl (3144)
2018.11.18 00:01:00 1: main::HandleTimeout called by fhem.pl (649)
2018.11.18 00:01:00 1: readingsUpdate(Timer,housephase,nighttime) missed to call readingsBeginUpdate first.
2018.11.18 00:01:00 1: stacktrace:
2018.11.18 00:01:00 1: main::readingsBulkUpdate called by ./FHEM/95_YAAHM.pm (1245)
2018.11.18 00:01:00 1: main::YAAHM_time called by (eval 127356) (1)
2018.11.18 00:01:00 1: (eval) called by fhem.pl (1116)
2018.11.18 00:01:00 1: main::AnalyzePerlCommand called by ./FHEM/98_DOIF.pm (1553)
2018.11.18 00:01:00 1: main::ParseCommandsDoIf called by ./FHEM/98_DOIF.pm (1974)
2018.11.18 00:01:00 1: main::DOIF_cmd called by ./FHEM/98_DOIF.pm (2233)
2018.11.18 00:01:00 1: main::DOIF_Trigger called by ./FHEM/98_DOIF.pm (2466)
2018.11.18 00:01:00 1: main::DOIF_TimerTrigger called by fhem.pl (3144)
2018.11.18 00:01:00 1: main::HandleTimeout called by fhem.pl (649)
2018.11.18 00:01:00 1: readingsUpdate(Timer,tr_housephase,Nachtzeit) missed to call readingsBeginUpdate first.
2018.11.18 00:01:00 1: stacktrace:
2018.11.18 00:01:00 1: main::readingsBulkUpdate called by ./FHEM/95_YAAHM.pm (1246)
2018.11.18 00:01:00 1: main::YAAHM_time called by (eval 127356) (1)
2018.11.18 00:01:00 1: (eval) called by fhem.pl (1116)
2018.11.18 00:01:00 1: main::AnalyzePerlCommand called by ./FHEM/98_DOIF.pm (1553)
2018.11.18 00:01:00 1: main::ParseCommandsDoIf called by ./FHEM/98_DOIF.pm (1974)
2018.11.18 00:01:00 1: main::DOIF_cmd called by ./FHEM/98_DOIF.pm (2233)
2018.11.18 00:01:00 1: main::DOIF_Trigger called by ./FHEM/98_DOIF.pm (2466)
2018.11.18 00:01:00 1: main::DOIF_TimerTrigger called by fhem.pl (3144)
2018.11.18 00:01:00 1: main::HandleTimeout called by fhem.pl (649)
Grüße
Christian
Ich hatte nur Warnings
2018.11.18 00:00:33 1: [YAAHM_updater] on device Profil called for this day
2018.11.18 00:00:33 1: PERL WARNING: Use of uninitialized value $name in hash element at ./FHEM/95_YAAHM.pm line 1670.
2018.11.18 00:00:33 1: PERL WARNING: Use of uninitialized value $d in hash element at fhem.pl line 4365.
@cwagner: Wundert mich - gerade das hatte ich verhindert.
Anbei mal eine Zwischenversion. Die Eingabe für ferienage und Feiertage ist zwar schon ok - aber die Timer werden noch nicht richtig erzeugt.
Immerhin kann man hier das UI für die Eingabe sehen.
LG
pah
Wir sind uns unsicher, in der commandref steht das nicht: Sind die Aktionen in den Felder mit Komma oder Semikolon getrennt? Und die grünen Haken zeigen an, dass der Befehl angenommen wurde?
Haken => Timer läuft.
Felder werden komplett an einen Perl-Aufruf von fhem(...) übergeben.
LG
pah
Die gestern beschriebenen Eintragungen im Log-File wiederholten sich bei mir heute Nacht nicht. Womöglich, weil ich dies geändert hatte: 1 Minute vor Mitternacht soll eine Kette von 6 Fhem-Befehlen abgearbeitet werden. Die hatte ich dem Wiki folgend komma-separiert. Auch nachfolgende (Einzel-)Befehle waren dann nicht mehr ausgeführt worden, Angeregt durch die gestrige Diskussion habe ich die Liste nun semikolon-separiert, die 6 Befehle und alle folgenden bis jetzt wurden korrekt ausgeführt.
Im Interface finde ich aber noch eine verwirrende Angabe: Über ein Vacation-Device habe ich den heutigen Tag zum Urlaubstag erklärt. Das findet sich entsprechend seit Mitternacht auch im reading todayType, der heute "vacday" beinhaltet.
In der so toll gestalteten Übersicht heißt es aber "Arbeitstag" (siehe Sceenshot).
Christian
Zitat von: cwagner am 19 November 2018, 07:57:16
Die hatte ich dem Wiki folgend komma-separiert.
Habe ich gerade geändert.
@cwagner: Muss ich mir ansehen. Bitte mal die datei für das vacation-Device schicken, das macht es etwas einfacher.
LG
pah
Mit dem Attribut vacationDevices Urlaub
habe ich diese Datei mit Namen Urlaub.holiday eingebunden
# Siehe auch
# http://de.wikipedia.org/wiki/Feiertage_in_Deutschland
# Urlaub durch cw ergänzt
# Zeitspanne ist Kennung 4
1 11-19 Urlaub
Danke für das Nachstellen!
Christian
OK, das Problem ist gefixt. Bis auf die Tatsache, dass die Timer für die Wochenprofile immer noch nicht stimmen (da muss ich noch etwas an der Logik feilen...), geht das jetzt soweit.
Dateien anbei
LG
pah
Danke für den Fix - funktioniert.
Christian
Zitat von: Prof. Dr. Peter Henning am 19 November 2018, 15:57:47
...Bis auf die Tatsache, dass die Timer für die Wochenprofile immer noch nicht stimmen (da muss ich noch etwas an der Logik feilen...), geht das jetzt soweit.
...
Ist damit auch gemeint, dass s_sleep und s_wakeup 30 Minuten vor den im Interface gezeigten und im Profil eingestellten Zeiten stehen? Selbst wenn ich Timer.wtimer_0|1.IF nochmals laufen lasse?
LG
Christian
s_wakeup und s_sleep sind nicht wirklich in Benutzung, werden nur an einer Stelle bedient. Weckzeiten sind in den readings ring... niedergelegt.
LG
pah
Meine Hoffnung ist, dass es ein Reading gibt, dass nach Verarbeitung der Hierarchie Arbeitstag < Wochenendtag < Feiertag < Urlaub die dann gültigen Weck/Schlafenszeiten abzugreifen sind, um sie in anderen Modulen meiner Haussteuerung zu verwenden. Experimentell sehe ich, dass Arbeitstag/Wochenendtag (über das Wochenprofil) sowie die manuellen Zeiten sich in ring_0 / ring_1 zu finden sind. Aber Ein Urlaubsprofil (das ja nach dem Patch erkannt wird) schreibt seine Zeiten in ring_2 und ring_3, die Hierarchie müsste ich dann aber selbst abbilden, oder?
LG
Christian
Jein. Da derzeit noch die Zeiten für "Urlaub" nur in der Oberfläche zu sehen sind, und nicht im Timer, ist das derzeit richtig. Künftig wird sich aber die gesamte Hierarchie in jedem einzelnen Timer abbilden lassen. Dauert aber noch ein paar Tage, weil ich von morgen bis Samstag abend Großeinsatz in der Hochschule habe.
LG
pah
pah, ich habe eine komische Fehlermeldung:
2018.11.27 06:00:00 1: [YAAHM_time] executing { LogFileEintraegeSenden()}
2018.11.27 06:00:00 1: PERL WARNING: Number found where operator expected at (eval 203866) line 2, near "2018.11.27 06"
2018.11.27 06:00:00 1: PERL WARNING: (Missing operator before 06?)
2018.11.27 06:00:00 1: PERL WARNING: Number found where operator expected at (eval 203866) line 2, near "00 1"
2018.11.27 06:00:00 1: PERL WARNING: (Missing operator before 1?)
2018.11.27 06:00:00 1: PERL WARNING: Bareword found where operator expected at (eval 203866) line 2, near "] executing"
2018.11.27 06:00:00 1: PERL WARNING: (Missing operator before executing?)
und der Befehl lautet:
sub LogFileEintraegeSenden(){
my $datum;
$datum = POSIX::strftime("%Y-%m",localtime(time));
my $nachricht;
$nachricht = qx(tail -n10 /opt/fhem/log/fhem-$datum.log);
fhem("set TelegramBot _msg ".$nachricht);
}
Bin ich das?
Ja. Die Nachricht enthält Zeilenvorschubzeichen. Mein erster Versuch wäre, $nachricht in ' ... ' zu setzen.
LG
pah
Das hat anscheinend nicht gereicht:
An der falschen Stelle gespielt. Läuft jetzt, danke.
Pah, hier gab es noch was:
018.12.01 07:55:00 1: [YAAHM_time] executing get Kamera1,Kamera2,Kamera3,Kamera4 image
2018.12.01 08:00:00 1: readingsUpdate(Profil,next_3,) missed to call readingsBeginUpdate first.
2018.12.01 08:00:00 1: eval: {YAAHM_time('Profil','timer_3',1)}
2018.12.01 08:00:00 1: stacktrace:
2018.12.01 08:00:00 1: main::readingsBulkUpdate called by ./FHEM/95_YAAHM.pm (1216)
2018.12.01 08:00:00 1: main::YAAHM_time called by (eval 431326) (1)
2018.12.01 08:00:00 1: (eval) called by fhem.pl (1116)
2018.12.01 08:00:00 1: main::AnalyzePerlCommand called by ./FHEM/98_DOIF.pm (1553)
2018.12.01 08:00:00 1: main::ParseCommandsDoIf called by ./FHEM/98_DOIF.pm (1974)
2018.12.01 08:00:00 1: main::DOIF_cmd called by ./FHEM/98_DOIF.pm (2233)
2018.12.01 08:00:00 1: main::DOIF_Trigger called by ./FHEM/98_DOIF.pm (2466)
2018.12.01 08:00:00 1: main::DOIF_TimerTrigger called by fhem.pl (3146)
2018.12.01 08:00:00 1: main::HandleTimeout called by fhem.pl (649)
2018.12.01 08:00:00 1: [YAAHM_time] executing action set RolladenWohnz1 oeffnen;sleep 0.7;set RolladenAZ oeffnen;sleep 0.7;set RolladenWohnz2 oeffnen for timer timer_3
Ich kann aber nicht sagen, was das bedeutet.
Gesendet von iPhone mit Tapatalk Pro
Ich habe noch eine Frage zu dem Modul. Es heißt
Zitatattr <comma-separated list of devices>
list of devices that provide vacation information. The devices may be holiday devices or Calendar devices
mir ist aber nicht klar, wie die Information in dem Calendar device vorliegen muss (bei mir werden Feiertag nicht erkannt, ich habe den Kalender aus schulferien.org). Im Calendar device selbst heißt es
ZitatA calendar event has a summary (usually the title shown in a visual representation of the source calendar), a start time, an end time, and zero, one or more alarm times. In case of multiple alarm times for a calendar event, only the earliest alarm time is kept.
und was genau benötigt YAAHM hier? Genügt die Tatsache, dass ein Eintrag im Kalender vorliegt (unabhängig vom summary)? Oder muss in der summary noch etwas stehen?
Sollte. Da sich am calendar-Modul etwas geändert hat, wir derzeit YAAHM auch etwas umgewälzt. Etwas Geduld bitte.
LG
pah
Also, wenn jemand das gleiche Problem wie ich hat und eine schnelle Lösung sucht, ich habe das mit den Ferien in Berlin so gemacht: ferien.holiday-Datei mit den Einträgen
# Ferien 2018/19 Berlin
# Format: X MM-DD MM-DD <Text>
4 02-04 02-09 Winterferien
4 04-15 04-26 Osterferien
4 05-31 06-11 Pfingstferien
4 06-20 08-02 Sommerferien
4 10-07 10-19 Herbstferien
4 12-22 12-31 Weihnachtsferien_2018
4 01-01 01-05 Weihnachtsferien_2019
Man muss nur aufpassen, dass die Winterferien geteilt werden, weil man den Jahreswechsel nicht in einer holiday-Datei haben darf.
Diese Datei ändere ich dann einmal im Jahr, was mich ca 5 Minuten kosten dürfte. Es gab mal hier eine längere Diskussion, dass diese 5 Minuten pro Jahr einigen zu viel waren. Mich würde das wahrscheinlich mehrere Tage Programmieraufwand kosten. Und da ich keine 100 Jahre mehr leben werde...
OK, ich habe den Fehler gefunden. Das Calendar-Modul gibt nämlich die Jahreszahl jetzt vierstellig zurück. Es leben die undokumentierten Änderungen.
Hier die nächste Beta-Version
LG
pah
super. Hast du auch den Fehler in #242 gefunden?
Das war welcher ?
LG
pah
Zitat von: Prof. Dr. Peter Henning am 02 Dezember 2018, 20:24:11
Das war welcher ?
Das hier:
018.12.01 07:55:00 1: [YAAHM_time] executing get Kamera1,Kamera2,Kamera3,Kamera4 image
2018.12.01 08:00:00 1: readingsUpdate(Profil,next_3,) missed to call readingsBeginUpdate first.
2018.12.01 08:00:00 1: eval: {YAAHM_time('Profil','timer_3',1)}
2018.12.01 08:00:00 1: stacktrace:
2018.12.01 08:00:00 1: main::readingsBulkUpdate called by ./FHEM/95_YAAHM.pm (1216)
2018.12.01 08:00:00 1: main::YAAHM_time called by (eval 431326) (1)
2018.12.01 08:00:00 1: (eval) called by fhem.pl (1116)
2018.12.01 08:00:00 1: main::AnalyzePerlCommand called by ./FHEM/98_DOIF.pm (1553)
2018.12.01 08:00:00 1: main::ParseCommandsDoIf called by ./FHEM/98_DOIF.pm (1974)
2018.12.01 08:00:00 1: main::DOIF_cmd called by ./FHEM/98_DOIF.pm (2233)
2018.12.01 08:00:00 1: main::DOIF_Trigger called by ./FHEM/98_DOIF.pm (2466)
2018.12.01 08:00:00 1: main::DOIF_TimerTrigger called by fhem.pl (3146)
2018.12.01 08:00:00 1: main::HandleTimeout called by fhem.pl (649)
2018.12.01 08:00:00 1: [YAAHM_time] executing action set RolladenWohnz1 oeffnen;sleep 0.7;set RolladenAZ oeffnen;sleep 0.7;set RolladenWohnz2 oeffnen for timer timer_3
Aber ja. Das kann gar nicht mehr vorkommen. Demnächst Release der neuen Version.
LG
pah
Noch eine Bitte oder eine Frage. Kann man Meldungen
2018.12.11 15:53:00 1: [YAAHM_time] executing get Kamera1,Kamera2,Kamera3,Kamera4 image
etc im Log unterdrücken? verbose 0 beim Profil leistet das nicht.
Hallo pah, ich habe folgendes holiday device
# Ferien 2018/19 Berlin
# Format: X MM-DD MM-DD <Text>
4 02-04 02-09 Winterferien
4 04-15 04-26 Osterferien
4 05-31 06-11 Pfingstferien
4 06-20 08-02 Sommerferien
4 10-07 10-19 Herbstferien
4 12-22 12-31 Weihnachtsferien_2018
4 01-01 01-05 Weihnachtsferien_2019
bekomme aber heute keinen Ferientag angezeigt - intern wird das aber wie ein Ferientag behandelt. Oder ist das so gewollt?
(https://uploads.tapatalk-cdn.com/20181224/b6a44c032df5836cc945b98a79594c13.jpg)
Gesendet von iPad mit Tapatalk Pro
bitte nicht falsch verstehen: ich habe da noch die eine oder andere fehlermeldung im Modul. Ist das schon behoben (ich mache keine regelmäßigen updates) oder müssen wir uns noch gedulden?
Gedulden noch wir uns müssen.
LG
pah
Vorfreude ist die schönste Freude ;-)
Gesendet von iPhone mit Tapatalk Pro
Soeben habe ich Version 3.0 eingecheckt. Alle Fehler sollten behoben sein, neues Feature sind die so genannten Geräte-Aktionen, das sind benannte Aktionen mit eigenem Timer (wie z.B. "Rollläden hoch"), für die man sich auf eine der anderen Zeitangaben beziehen kann.
LG
pah
Danke!
<edit: Autokorrektur entfernt>
noch eine Verständnisfrage. Ich dachte, dass mit der (automatischen) Ankündigung hier im Forum die neue Datei oben liegt. Das ist aber nicht der Fall. Ab wann ist die denn im update erreichbar?
Gesendet von iPad mit Tapatalk Pro
Zitat von: andies am 28 Februar 2019, 21:31:05
noch eine Verständnisfrage. Ich dachte, dass mit der (automatischen) Ankündigung hier im Forum die neue Datei oben liegt. Das ist aber nicht der Fall. Ab wann ist die denn im update erreichbar?
Gesendet von iPad mit Tapatalk Pro
Gegen 8 Uhr morgens werden alle bis dahin neu eingecheckten Module "eingelesen" und über das normale Update bereitgestellt. Sprich ab morgen Früh um 08:00 Uhr kannst du die neuste Version über den normalen Update Befehl in FhemWeb beziehen. Falls du nicht so lange warten willst, kannst du hier --> https://svn.fhem.de/trac/browser/trunk/fhem/FHEM direkt die Module herunterladen, sobald sie eingecheckt sind.
Grüße
Ich habe ein paar Fragen zu YAAHM bzw. dem Wikieintrag:
- Im Wiki heißt es ,,Wie man hier sieht, ist eine der Türen nicht geschlossen und somit der Zustand Gesichert nicht vollständig erfüllt." und ich sehe das nicht. Beide Türen haben einen grünen Haken. Oder ist das ein Schreibfehler?
- Werden Einträge bei den manuellen Zeiten nach Ausführung gelöscht? Im Wiki steht da nichts.
Ja, ausprobiert. Nein, manueller Befehl war heute noch drin. - Kann man bei den Modi wie zum Beispiel ,,Abwesenheit" eigene Befehlsfolgen (also Aktionen) ausführen lassen? Oder bezieht sich das nur auf die readings state?
Hallo zusammen,
ich habe eine Verständnisfrage.
Meine Rollo's werden über die Wochenprofile gesteuert und fahren auch fast wie gewünscht. Sobald der Tagestyp allerdings Feiertag oder Ferien ist werden die Profile nicht mehr wie erwartet verarbeitet. Im Log ist kein YAAHM_time Eintrag für die Profile zu finden und die Rollos fahren eben nicht zeitgesteuert. In der Wochenprofil Übersicht habe ich explizit kein Häkchen gesetzt für "Fer" bzw. "Fei" weil ich dachte, dass man für diesen Tagestyp in der Oberfläche dediziert andere Zeiten definieren kann. Anbei ein Screenshot zur besseren Übersicht.
Grundsätzlich fände ich es super, wenn man für Fer + Fei dediziert andere Zeiten definieren kann, sollte das auch so funktionieren oder missverstehe ich das Feature? Funktioniert das bei euch?
Danke & Gruss hoods
Hallo Zusammen
ich verwende auch das Modul YAAHM soweit und es funktioniert auch. Jetzt möchte ich gerne überprüfen lassen, ob meine Fenster auf sind. Dazu wird in der Hilfe gesagt, dass man dort den STATE des devices prüfen kann.
Beispiel aus der Doku: HausTuer::locked:locked:locked:locked
Ich selber benutze Homematiksensoren an meinen Fenster. Die heissen beispielsweise : Wohnzimmer1-4 usw. und der State kann entweder: closed oder open sein.
Was muss man dann dort eintragen ---> Wohnzimmer1::closed:closed:closed:closed
Wenn ich das eintrage, dass funktioniert es leider nicht und es wird immer die Meldung "Wohnzimmer nicht ok gegeben" obwohl die Tür zu ist = closed
Danke für eine Hilfe.
Markus
Ich habe das gerade mit einem HomeMatic-Sensor an meiner Terassentür ausprobiert
WZ.Tuer.K::closed:closed:closed:closed
funktioniert problemlos wie geplant. Ich vermute also einen Tippfehler - in der Meldung
ZitatWohnzimmer nicht ok
fehlt z.B. die Ziffer.
LG
pah
Danke für die Schnelle Hilfe.
Leider stehe ich immer noch auf dem Schlauch.
Ich habe beispielsweise jetzt auch einen anderen Sensor genommen. In diesem Fall die Küche
-- >Kueche::closed:closed:closed:closed
Obwohl das Fenster zu, wird immer noch "Sicherheit Kueche Nicht OK" angezeigt. Ich verstehe es ja richtig, es muss der Status verwendet werden der abschlossen sein muss, in diesem Fall closed.
Mache ich ggf. es was falsch bei den Reading (siehe Bild unten).
Geht die Logik im Programm immer "Default" und automatisch auf den "State" des Devices ? oder muss man beim Device doch noch was mitgeben, damit er den State versteht (siehe Bilder)?
....
Das Attribut stateDevices enthält eine kommagetrennte Liste von FHEM-Devices, die jeweils gefolgt werden von den erwarteten state-Readings (getrennt durch ein ":"-Zeichen) für die entsprechenden (Sicherheits-) Zustände, also z.B. für eine Haustür, die in den (Sicherheits-) Zuständen Gesichert, Geschützt und Überwacht abgeschlossen sein soll:
...
Danke für die Hilfe
Wie gesagt, bei mir tritt das nicht auf, sondern wird korrekt behandelt.
Ich kann erst Mittwoch wieder genauer nachsehen.
LG
pah
Hallo Herr Henning, können sie es bitte nochmal nachsehen?
Nicht doch, ich muss nichts "nochmal nachsehen", das ich schon einmal überprüft habe - das Modul YAAHM macht das ganz korrekt. Das "genauer nachsehen" bezieht sich auf Spekulationen, woran es denn liegen könnte.
Und da bin ich auf Spekulation angewiesen, weil leider kein List des Devices "Kueche" mitgeliefert wurde ... ::)
Mein Vermutung ist, dass "Kueche" nicht der Devicename ist, sondern ein Alias. Die in YAAHM verwendete Perl-Funktion "Value" benötigt aber den eigentlichen Devicenamen, nicht den Aliasnamen.
LG
pah
ich habe, gerade nach Hause kommend, eine komische Fehlermeldung. Angeblich ist yaahm schon in normale mode, das Attribut zeigt aber absence und das umschalten funktioniert nicht. Any idee was ich tun kann?
Internals:
FUUID 5c782b59-f33f-1115-d45f-e97b23f152087a1f
NAME Profil
NOTIFYDEV global,Profil
NR 168
STATE Initialized
TYPE YAAHM
VERSION 3.0
DATA:
savedate 2019-06-02 21:56:16
DD:
HASH(0x4d37668)
HASH(0x4d364d8)
HASH(0x4d365e0)
DT:
aftermidnight:
02:01
02:01
set DbLogRep delSeqDoublets delete;{ TermineSetzen()};set Pikrellcam;archive_yesterday
;
afternoon:
14:00
undef
undef
;
aftersunrise:
05:45
01:00
undef
;
aftersunset:
22:08
00:40
undef
;
beforemidnight:
23:55
00:05
setreading Regenmesser rain_midnight [Regenmesser:rain]; setreading EntkalkerWasserTagesLog logentry [Wasserzaehler_IEC_01:energyCalc]; {RegressionSetzen()}
;
beforesunrise:
03:45
01:00
undef
;
beforesunset:
20:28
01:00
undef
;
evening:
18:30
undef
undef
;
morning:
06:00
undef
{ LogFileEintraegeSenden();;Plananzeige()}
;
night:
23:00
undef
set LampeGarage,ShellyHerdlampe,Dimmer,LampeKellerGarage,Wohnzimmer,FlurOben off
;
noon:
13:00
undef
undef
;
sleep:
22:30
undef
undef
undef
sunrise:
04:45
undef
get Kamera1,Kamera2,Kamera3,Kamera4 image;set Pikrellcam still
;
sunset:
21:28
undef
get Kamera1,Kamera2,Kamera3,Kamera4 image;set Pikrellcam still
;
wakeup:
06:15
undef
undef
undef
HSM:
mode normal
state unsecured
time sunset
WT:
HASH(0x4d372f0)
HASH(0x4d36bb0)
HASH(0x4d37260)
HASH(0x4d36f18)
XT:
READINGS:
2019-06-07 16:07:58 housemode absence
2019-06-10 06:00:15 housephase nighttime
2019-04-12 22:01:57 housestate secured
2019-06-10 06:00:15 housetime morning
2018-11-07 23:50:00 lockstate 0
2019-06-08 00:00:34 next_0
2019-06-08 00:00:34 next_1
2019-06-02 00:01:10 next_2
2019-06-02 00:01:10 next_3
2019-06-10 06:00:15 next_housetime sunset
2019-06-07 16:07:58 prev_housemode normal
2019-04-12 22:01:57 prev_housestate protected
2019-06-10 06:00:15 prev_housetime sunrise
2019-06-10 18:37:48 ring_0 off (Fei)
2019-06-10 18:37:48 ring_0_1 off (Url)
2019-06-10 18:37:48 ring_0_1x off (Url)
2019-06-10 18:37:48 ring_0x off (Abw)
2019-06-10 18:37:49 ring_1 off (Fei)
2019-06-10 18:37:49 ring_1_1 off (Url)
2019-06-10 18:37:49 ring_1_1x off (Url)
2019-06-10 18:37:49 ring_1x off (Abw)
2019-06-10 18:37:49 ring_2 off
2019-06-10 18:37:49 ring_2_1 off
2019-06-10 18:37:49 ring_2_1x off
2019-06-10 18:37:49 ring_2x off (Abw)
2019-06-10 18:37:49 ring_3 off
2019-06-10 18:37:49 ring_3_1 off
2019-06-10 18:37:49 ring_3_1x off
2019-06-10 18:37:49 ring_3x off (Abw)
2019-06-10 18:37:48 s_aftermidnight 02:01
2019-06-10 18:37:48 s_afternoon 14:00
2019-06-10 18:37:48 s_aftersunrise 05:45
2019-06-10 18:37:48 s_aftersunset 22:08
2019-06-10 18:37:48 s_beforemidnight 23:55
2019-06-10 18:37:48 s_beforesunrise 03:45
2019-06-10 18:37:48 s_beforesunset 20:28
2019-06-10 18:37:48 s_evening 18:30
2019-06-10 18:37:48 s_morning 06:00
2019-06-10 18:37:48 s_night 23:00
2019-06-10 18:37:48 s_noon 13:00
2019-06-10 18:37:48 s_sleep 22:30
2019-06-10 18:37:48 s_sunrise 04:45
2019-06-10 18:37:48 s_sunset 21:28
2019-06-10 18:37:48 s_wakeup 06:15
2019-06-10 18:37:23 savedate 2019-06-02 21:56:16
2019-06-10 18:49:52 sdev_housestate <html><table></table></html>
2019-06-10 18:49:52 sec_housestate secure
2019-06-10 18:37:23 state Initialized
2019-06-10 18:49:52 sym_housestate <html><div style="color:green">✓</div></html>
2019-06-10 00:00:44 todayDesc Pfingsten
2019-06-10 00:00:44 todayType holiday
2019-06-10 18:37:48 today_0 off (Fei)
2019-06-10 18:37:48 today_0_e disabled (absence)
2019-06-10 18:37:49 today_1 off (Fei)
2019-06-10 18:37:49 today_1_e disabled (absence)
2019-06-10 18:37:49 today_2 off
2019-06-10 18:37:49 today_2_e disabled (absence)
2019-06-10 18:37:49 today_3 off
2019-06-10 18:37:49 today_3_e disabled (absence)
2019-06-10 00:00:44 tomorrowDesc Pfingstferien
2019-06-10 00:00:44 tomorrowType vacation
2019-06-10 18:37:48 tomorrow_0 off (Url)
2019-06-10 18:37:48 tomorrow_0_e disabled (vacation)
2019-06-10 18:37:49 tomorrow_1 off (Url)
2019-06-10 18:37:49 tomorrow_1_e disabled (vacation)
2019-06-10 18:37:49 tomorrow_2 off
2019-06-10 18:37:49 tomorrow_2_e enabled
2019-06-10 18:37:49 tomorrow_3 off
2019-06-10 18:37:49 tomorrow_3_e enabled
2019-06-10 18:47:23 tr_errmsg
2019-06-07 16:07:58 tr_housemode Abwesenheit
2019-06-10 06:00:15 tr_housephase Nachtzeit
2019-04-12 22:01:57 tr_housestate Gesichert
2019-06-10 06:00:15 tr_housetime Morgen
2019-06-10 00:00:44 tr_todayType Feiertag
2019-06-10 00:00:44 tr_tomorrowType Urlaubstag
2019-06-10 00:00:44 tr_twodaysType Arbeitstag
2019-06-10 18:37:48 tr_wake_0 off heute und morgen
2019-06-10 18:37:49 tr_wake_1 off heute und morgen
2019-06-10 18:37:49 tr_wake_2 off heute und morgen
2019-06-10 18:37:49 tr_wake_3 off heute und morgen
2019-06-10 00:00:44 twodaysDesc Arbeitstag
2019-06-10 00:00:44 twodaysType vacation
TIMER:
Profil_aftermidnight:
HASH Profil
MODIFIER aftermidnight
NAME Profil_aftermidnight
Profil_check:
HASH Profil
MODIFIER check
NAME Profil_check
Attributes:
group intern
holidayDevices berlin
room ProfileRoom
stateDevices Garage::locked:locked:locked:locked, Schlafzimmerfenster::closed:closed:closed:closed, Badezimmerfenster::closed:closed:closed:closed, BadUntenfenster::closed:closed:closed:closed,
stateInterval 3
vacationDevices ferien
Einmal hin- und einmal her-schalten ??
Ich habe aber keine Ahnung von der Ursache, tritt bei mir nicht auf
LG
pah
Edit: Gemeint war "keine Ahnung".
Ich habe das jetzt mit "setreading etc." gelöst. Beim nächsten Mal achte ich darauf.
Zitat von: Prof. Dr. Peter Henning am 10 Juni 2019, 20:41:13
Einmal hin- und einmal her-schalten ??
Das klappt (es war nämlich "über Nacht" wieder auf Abwesenheit). Ich musste erst hin- und dann herschalten.
Hm, so etwas ist mir noch nie untergekommen. Es gibt in YAAHM keinen Mechanismus, der das auf absence stellen könnte - muss irgendwie aus FHEM heraus kommen.
LG
pah
Nein, das ist ein Missverständnis jetzt:
- Ich hatte per Hand auf absence gestellt (klick auf den Schalter), das war ok.
- Dann wollte ich per Klick auf den Schalter "Normal" stellen, und das ging nicht [wobei ich eben gerade nicht hin- und hergeschaltet habe]. Danach habe ich "setreading <Modulname> housemode normal" geschrieben und das Attribut war wieder normal, nicht absence.
- Über Nacht wurde es wundersam wieder zu absence, das ich dann mit hin- und herschalten auf Normal gesetzt habe.
Nr. 2 kam mir komisch vor, der Rest nicht.
Hallo,
ich nutze das Modul ebenfalls seit einiger Zeit. Besten Dank dafür;-) Mein eiziges Problem: Nach einem "shutdown/restart" werden keine Aktionen von dem Modul ausgeführt. Erst ein erneutes "start Tages-timer" bewegt das Modul dazu, wieder zu laufen.
Es nützt auch nichts, da zu automatisieren:
defmod YAAHM_Start notify global:INITIALIZED sleep 10;; set Zeitsteuerung.dtimer.IF initialize
attr YAAHM_Start room System
setstate YAAHM_Start 2019-07-20 16:05:17
setstate YAAHM_Start 2019-07-20 16:05:05 state active
Das Problem ist, dass ich jede WO Sonntags morgens ein Backup starte. Danach ist die Zeitsteuerrung aus.
Gruss
Thorsten
Kann ich so nicht bestätigen - natürlich muss, nachdem die Timer einmal gestartet worden sind, die Konfiguration gesichert werden. Dann sind sie auch nach einem Neustart wieder aktiv.
LG
pah
Aha, also "Start Tages-Timer", "Start Wochen-Timer", und dann "set Zeitsteuerung save"? Probiere ich noch mal. Wie stelle ich am einfachsten fest, ob die Timer nach dem Neustart laufen?
Gruss
Thorsten
Nein, "Save config" ist das Wichtige ! Die Timer sind ja einfach weitere FHEM-Devices, deren Zustand natürlich gesichert werden muss.
Wenn die Timer korrekt laufen, zeigen sie auf der YAAHM-Seite "Profile" grüne Häkchen.
LG
pah
Danke für die schnelle Hilfe. Seltsamer Weise habe ich an den Timern aber nichts verändert. Trotzdem werden sie nach einem Neustart nicht ausgeführt. Ist mein "set Zeitsteuerung.dtimer.IF initialize" nach einem Neustart dann vielleicht kontraproduktiv?
Gruss
Thorsten
Aber ja !
LG
pah
Hi,
Naja, vielleicht stimmt die Reihenfolge der defines in der config nicht und die ,,gehen verloren". Kannst Du mal das Log zeigen nach einem shutdown restart!?
Gruß Arnd
Signalduino (Nano, ESP, ...), CUL (Busware, Nano, Maple, ...), Homematic (HM-MOD-UART-RPI, ESP, Maple, ...), LaCrosseGateway (LGW, ESP, ...), 1-wire, ESPEasy, Bravia, Yamaha, ...
Ok, ich habe "set Zeitsteuerung.dtimer.IF initialize" raausgenommen. Hier der log nach dem restart:
2019.07.21 18:41:49 1: Including fhem.cfg
2019.07.21 18:41:50 3: WEB: port 8083 opened
2019.07.21 18:41:50 3: WEBphone: port 8084 opened
2019.07.21 18:41:50 3: WEBtablet: port 8085 opened
2019.07.21 18:41:51 2: eventTypes: loaded 5522 events from ./log/eventTypes.txt
2019.07.21 18:41:52 1: PERL WARNING: Unrecognized escape \w passed through at ./FHEM/10_TASMOTA_DEVICE.pm line 247, <$fh> line 232.
2019.07.21 18:41:52 1: PERL WARNING: TASMOTA::DEVICE::Expand() called too early to check prototype at ./FHEM/10_TASMOTA_DEVICE.pm line 287, <$fh> line 232.
2019.07.21 18:41:52 1: PERL WARNING: TASMOTA::DEVICE::Expand() called too early to check prototype at ./FHEM/10_TASMOTA_DEVICE.pm line 293, <$fh> line 232.
2019.07.21 18:41:52 3: telnetPort: port 7072 opened
2019.07.21 18:41:52 3: TabletUi: new ext defined infix:ftui/: dir:./www/tablet/:
2019.07.21 18:41:52 3: Registering HTTPSRV TabletUi for URL /ftui and assigned link ftui/ ...
2019.07.21 18:41:53 3: TelegramBot_Define telebot: called
2019.07.21 18:41:54 3: Opening Anrufliste device 192.168.1.1:1012
2019.07.21 18:41:54 3: FB_CALLMONITOR (Anrufliste) - loading cache file /opt/fhem/log/reverse_search.txt
2019.07.21 18:41:54 2: FB_CALLMONITOR (Anrufliste) - read 132 contacts from Cache
2019.07.21 18:41:56 2: ONKYO_AVR ONKYO_TX_NR686: Registering ONKYO_AVR for webhook URI ?/ONKYO_AVR ...
2019.07.21 18:41:56 3: Opening ONKYO_TX_NR686 device 192.168.1.89:60128
2019.07.21 18:41:59 1: HMCCU: [d_ccu] Initialized version 4.3.015
2019.07.21 18:41:59 1: HMCCU: [d_ccu] HMCCU: Initializing device
2019.07.21 18:41:59 1: HMCCU: [d_ccu] HMCCU: Read 5 devices with 120 channels from CCU 192.168.1.102
2019.07.21 18:41:59 1: HMCCU: [d_ccu] HMCCU: Read 3 interfaces from CCU 192.168.1.102
2019.07.21 18:41:59 1: HMCCU: [d_ccu] HMCCU: Read 0 programs from CCU 192.168.1.102
2019.07.21 18:41:59 1: HMCCU: [d_ccu] HMCCU: Read 0 virtual groups from CCU 192.168.1.102
2019.07.21 18:41:59 1: HMCCURPCPROC: [d_rpcBidCos_RF] Initialized version 1.7.001 for interface BidCos-RF with I/O device d_ccu
2019.07.21 18:41:59 1: HMCCURPCPROC: [d_rpcHmIP_RF] Initialized version 1.7.001 for interface HmIP-RF with I/O device d_ccu
2019.07.21 18:42:00 3: Xiaomi_Roborock: initialized, using Rijndael
2019.07.21 18:42:00 3: VISSMAN_Heizung - Passwort war bereits gespeichert
2019.07.21 18:42:01 3: FUIP: Registering ui for URL /ui
2019.07.21 18:42:01 1: PERL WARNING: Use of uninitialized value in lc at fhem.pl line 5345.
2019.07.21 18:42:06 1: PERL WARNING: Subroutine YAAHM_restore redefined at ./FHEM/95_YAAHM.pm line 1029, <$fh> line 1919.
2019.07.21 18:42:06 1: PERL WARNING: Subroutine YAAHM_setWeeklyTime redefined at ./FHEM/95_YAAHM.pm line 1991, <$fh> line 1919.
2019.07.21 18:42:06 1: [YAAHM_Define] data hash restored from save file with date 2019-07-21 11:02:57
2019.07.21 18:42:06 1: [YAAHM] finds 1 Astro devices, module not loaded separately
2019.07.21 18:42:06 3: [Zeitsteuerung V3.1] Added hidden room 'ProfileRoom' to WEB
2019.07.21 18:42:06 3: [Zeitsteuerung V3.1] Added hidden room 'ProfileRoom' to WEBphone
2019.07.21 18:42:06 3: [Zeitsteuerung V3.1] Added hidden room 'ProfileRoom' to WEBtablet
2019.07.21 18:42:09 3: [SamsungAV] Samsung_TV defined with host: 192.168.1.38 port: 8001
2019.07.21 18:42:10 0: [echodevice] load ECHO Device ECHO_G090VC0991170SV8
2019.07.21 18:42:10 0: [echodevice] load ECHO Device ECHO_G090U50991230BJP
2019.07.21 18:42:10 1: Including ./log/fhem.save
already connected to 192.168.1.98:5555
2019.07.21 18:42:12 3: ADB_Start return value: -1
2019.07.21 18:42:12 3: Opening Mosquitto device 127.0.0.1:1883
2019.07.21 18:42:12 3: Mosquitto device opened
2019.07.21 18:42:12 3: Opening Nut device 127.0.0.1:5333
2019.07.21 18:42:12 3: Nut device opened
2019.07.21 18:42:12 3: [SamsungAV] device Samsung_TV initialising....
2019.07.21 18:42:12 3: Opening Schluessel_BTle device 127.0.0.1:5333
2019.07.21 18:42:12 3: Schluessel_BTle device opened
2019.07.21 18:42:12 2: alexa: starting alexa-fhem: /usr/local/bin/alexa-fhem -c ./alexa-fhem.cfg -a xx:xx
2019.07.21 18:42:12 3: alexa: starting
2019.07.21 18:42:12 3: alexa: using logfile: ./log/alexa-2019-07-21.log
2019.07.21 18:42:12 0: HMCCU: Start of RPC server after FHEM initialization in 12 seconds
2019.07.21 18:42:12 3: ESPEasy espBridge: Bridge v2.18 port [TCP:IPV4:8383] opened.
2019.07.21 18:42:13 3: mail: connected to mx.freenet.de
2019.07.21 18:42:13 3: mail: logged in to fhem-trs@freenet.de
2019.07.21 18:42:13 0: Featurelevel: 5.9
2019.07.21 18:42:13 0: Server started with 299 defined entities (fhem.pl:19805/2019-07-09 perl:5.024001 os:linux user:fhem pid:10267)
2019.07.21 18:42:14 3: Xiaomi_Roborock: disconnecting
2019.07.21 18:42:14 2: Xiaomi_Roborock: connecting
2019.07.21 18:42:14 3: Xiaomi_Roborock: initialized
2019.07.21 18:42:14 3: [Zeitsteuerung V3.1] Weblink Zeitsteuerung_weblink created
2019.07.21 18:42:15 3: [Zeitsteuerung V3.1] Weblink Zeitsteuerung_shortlink created
2019.07.21 18:42:15 3: telnetForBlockingFn_1563727335: port 46575 opened
2019.07.21 18:42:15 3: Anrufliste device opened
2019.07.21 18:42:16 1: 192.168.1.98:9090 reappeared (Kodi_Wohnzimmer)
2019.07.21 18:42:16 1: 192.168.1.89:60128 disconnected, waiting to reappear (ONKYO_TX_NR686)
2019.07.21 18:42:19 3: ABFALL Muelltonnen - CALENDAR:Muelltonnen_Kalender triggered, updating ABFALL Muelltonnen ...
2019.07.21 18:42:20 1: [YAAHM_updater] on device Zeitsteuerung called for this day
2019.07.21 18:42:20 1: PERL WARNING: Use of uninitialized value in string comparison (cmp) at ./FHEM/95_YAAHM.pm line 284.
2019.07.21 18:42:21 1: 192.168.1.89:60128 reappeared (ONKYO_TX_NR686)
2019.07.21 18:42:24 1: PERL WARNING: Use of uninitialized value $installation in concatenation (.) or string at ./FHEM/98_vitoconnect.pm line 1018.
2019.07.21 18:42:24 1: PERL WARNING: Use of uninitialized value $gw in concatenation (.) or string at ./FHEM/98_vitoconnect.pm line 1018.
2019.07.21 18:42:24 1: PERL WARNING: Use of uninitialized value $access_token in concatenation (.) or string at ./FHEM/98_vitoconnect.pm line 1018.
2019.07.21 18:42:24 1: set VISSMAN_Heizung WW-Solltemperatur 46: Fehler während der Befehlsausführung: :: {"statusCode":400,"errorType":"BAD_REQUEST","message":"Request does not contain authentication context","privateDetails":{"service":"EVEREST"},"error":"NO TOKEN AVAILABLE"}
2019.07.21 18:42:25 1: PERL WARNING: Use of uninitialized value $installation in concatenation (.) or string at ./FHEM/98_vitoconnect.pm line 891.
2019.07.21 18:42:25 1: PERL WARNING: Use of uninitialized value $gw in concatenation (.) or string at ./FHEM/98_vitoconnect.pm line 891.
2019.07.21 18:42:25 1: PERL WARNING: Use of uninitialized value $access_token in concatenation (.) or string at ./FHEM/98_vitoconnect.pm line 891.
2019.07.21 18:42:26 1: VISSMAN_Heizung: Fehler während der Befehlsausführung: err= data= {"statusCode":400,"errorType":"BAD_REQUEST","message":"Request does not contain authentication context","privateDetails":{"service":"EVEREST"},"error":"NO TOKEN AVAILABLE"}
2019.07.21 18:42:27 2: HMCCU: [d_ccu] Get RPC device for interface BidCos-RF
2019.07.21 18:42:27 2: HMCCU: [d_ccu] Get RPC device for interface HmIP-RF
2019.07.21 18:42:27 2: HMCCURPCPROC: [d_rpcBidCos_RF] RPC server process started for interface BidCos-RF with PID=10428
2019.07.21 18:42:27 2: CCURPC: [d_rpcBidCos_RF] Initializing RPC server CB2001001071001102 for interface BidCos-RF
2019.07.21 18:42:27 1: HMCCURPCPROC: [d_rpcBidCos_RF] RPC server starting
2019.07.21 18:42:27 2: HMCCURPCPROC: [d_rpcHmIP_RF] RPC server process started for interface HmIP-RF with PID=10429
2019.07.21 18:42:27 2: CCURPC: [d_rpcHmIP_RF] Initializing RPC server CB2010001071001102 for interface HmIP-RF
2019.07.21 18:42:27 1: HMCCURPCPROC: [d_rpcHmIP_RF] RPC server starting
2019.07.21 18:42:27 2: HMCCURPCPROC: [d_rpcBidCos_RF] Callback server CB2001001071001102 created. Listening on port 7411
2019.07.21 18:42:27 2: CCURPC: [d_rpcBidCos_RF] CB2001001071001102 accepting connections. PID=10428
2019.07.21 18:42:27 2: HMCCURPCPROC: [d_rpcHmIP_RF] Callback server CB2010001071001102 created. Listening on port 7420
2019.07.21 18:42:27 2: CCURPC: [d_rpcHmIP_RF] CB2010001071001102 accepting connections. PID=10429
2019.07.21 18:42:28 2: HMCCURPCPROC: [d_rpcHmIP_RF] RPC server CB2010001071001102 enters server loop
2019.07.21 18:42:28 2: HMCCURPCPROC: [d_rpcHmIP_RF] Registering callback http://192.168.1.71:7420/fh2010 of type A with ID CB2010001071001102 at http://192.168.1.102:2010
2019.07.21 18:42:28 1: HMCCURPCPROC: [d_rpcHmIP_RF] RPC server CB2010001071001102 running
2019.07.21 18:42:28 2: HMCCURPCPROC: [d_rpcBidCos_RF] RPC server CB2001001071001102 enters server loop
2019.07.21 18:42:28 2: HMCCURPCPROC: [d_rpcBidCos_RF] Registering callback http://192.168.1.71:7411/fh2001 of type A with ID CB2001001071001102 at http://192.168.1.102:2001
2019.07.21 18:42:28 1: HMCCURPCPROC: [d_rpcBidCos_RF] RPC server CB2001001071001102 running
2019.07.21 18:42:28 1: HMCCU: [d_ccu] All RPC servers running
2019.07.21 18:42:28 2: CCURPC: [d_rpcBidCos_RF] CB2001001071001102 NewDevice received 55 device and channel specifications
2019.07.21 18:42:28 2: HMCCU: [d_ccu] Updated devices for interface filter BidCos-RF|HmIP-RF. Success=3 Failed=0
2019.07.21 18:42:28 1: HMCCURPCPROC: [d_rpcBidCos_RF] Scheduled CCU ping every 300 seconds
2019.07.21 18:42:29 2: CCURPC: [d_rpcHmIP_RF] CB2010001071001102 NewDevice received 70 device and channel specifications
2019.07.21 18:42:31 2: AttrTemplates: got 98 entries
2019.07.21 18:42:32 1: PERL WARNING: Use of uninitialized value in string eq at ./FHEM/98_vitoconnect.pm line 1331.
Hi,
warum wird hier das Save File verwendet?
Gruß Arnd
Zitat von: trs am 21 Juli 2019, 18:45:48
[...]
2019.07.21 18:42:01 1: PERL WARNING: Use of uninitialized value in lc at fhem.pl line 5345.
2019.07.21 18:42:06 1: PERL WARNING: Subroutine YAAHM_restore redefined at ./FHEM/95_YAAHM.pm line 1029, <$fh> line 1919.
2019.07.21 18:42:06 1: PERL WARNING: Subroutine YAAHM_setWeeklyTime redefined at ./FHEM/95_YAAHM.pm line 1991, <$fh> line 1919.
2019.07.21 18:42:06 1: [YAAHM_Define] data hash restored from save file with date 2019-07-21 11:02:57
2019.07.21 18:42:06 1: [YAAHM] finds 1 Astro devices, module not loaded separately
[...]
2019.07.21 18:42:20 1: [YAAHM_updater] on device Zeitsteuerung called for this day
Signalduino (Nano, ESP, ...), CUL (Busware, Nano, Maple, ...), Homematic (HM-MOD-UART-RPI, ESP, Maple, ...), LaCrosseGateway (LGW, ESP, ...), 1-wire, ESPEasy, Bravia, Yamaha, ...
Keine Ahnung, oder doch: da habe ich das letzte Mal "set Zeitsteuerung save" durchgeführt, siehe Beitrag oben.
Gruss
Thorsten
Zitatwarum wird hier das Save File verwendet?
Weil das Modul seinen internen Hash komplett in eine Datei sichert und aus dieser wieder auslesen kann.
LG
pah
Hallo,
nach einem Backup heute morgen zwischen 03:00 Uhr und 03:23 Uhr mit RaspiBackup (https://www.linux-tips-and-tricks.de/de/raspberry/23-pi-erstellt-automatisch-backups-von-sich-selbst-pi-creates-automatic-backups-of-itself/)
wird die Aktion "Sonnenaufgang" um 05:25 Uhr nicht ausgeführt. Inhalt: { fhem('set Sonoff_ch2 on')}; { fhem('set ESPEasy_ESP_Easy_Garage_Silke_Bewegungsmelder_DOIF_2 disable')}
Jedoch um 06:00 Uhr wird die Aktion "Morgen" korrekt ausgeführt. Inhalt: { fhem('set Klingelschalter on')}
Hier das Logfile:
2019.07.28 00:00:33 3: TelegramBot_Callback telebot: Digest: Number of poll failures on 2019-07-27 is :0:
2019.07.28 00:00:33 1: [YAAHM_updater] on device Zeitsteuerung called for this day
2019.07.28 00:06:53 3: alexa: using logfile: ./log/alexa-2019-07-28.log
2019.07.28 00:11:00 2: HMCCURPCPROC: [d_rpcHmIP_RF] Received no events from interface CB2010001071001102 for 1200 seconds
2019.07.28 00:28:49 3: set VISSMAN_Heizung WW-Solltemperatur 46
2019.07.28 00:28:51 3: set VISSMAN_Heizung HK1-Solltemperatur_normal 23
2019.07.28 00:31:00 2: HMCCURPCPROC: [d_rpcHmIP_RF] Received no events from interface CB2010001071001102 for 1200 seconds
2019.07.28 00:50:35 3: ABFALL Muelltonnen - CALENDAR:Muelltonnen_Kalender triggered, updating ABFALL Muelltonnen ...
2019.07.28 00:51:00 2: HMCCURPCPROC: [d_rpcHmIP_RF] Received no events from interface CB2010001071001102 for 1200 seconds
2019.07.28 00:59:12 3: set VISSMAN_Heizung WW-Solltemperatur 46
2019.07.28 00:59:14 3: set VISSMAN_Heizung HK1-Solltemperatur_normal 23
2019.07.28 01:29:08 2: HMCCURPCPROC: [d_rpcHmIP_RF] Received no events from interface CB2010001071001102 for 1200 seconds
2019.07.28 01:29:32 3: set VISSMAN_Heizung WW-Solltemperatur 46
2019.07.28 01:29:34 3: set VISSMAN_Heizung HK1-Solltemperatur_normal 23
2019.07.28 01:49:08 2: HMCCURPCPROC: [d_rpcHmIP_RF] Received no events from interface CB2010001071001102 for 1200 seconds
2019.07.28 01:50:35 3: ABFALL Muelltonnen - CALENDAR:Muelltonnen_Kalender triggered, updating ABFALL Muelltonnen ...
2019.07.28 01:59:56 3: set VISSMAN_Heizung WW-Solltemperatur 46
2019.07.28 01:59:58 3: set VISSMAN_Heizung HK1-Solltemperatur_normal 23
2019.07.28 02:09:08 2: HMCCURPCPROC: [d_rpcHmIP_RF] Received no events from interface CB2010001071001102 for 1200 seconds
2019.07.28 02:20:38 3: Xiaomi_Roborock: connection timeout
2019.07.28 02:23:38 3: Xiaomi_Roborock: disconnecting
2019.07.28 02:23:38 2: Xiaomi_Roborock: connecting
2019.07.28 02:23:38 3: Xiaomi_Roborock: initialized
2019.07.28 02:30:27 3: set VISSMAN_Heizung WW-Solltemperatur 46
2019.07.28 02:30:28 3: set VISSMAN_Heizung HK1-Solltemperatur_normal 23
2019.07.28 02:47:43 2: HMCCURPCPROC: [d_rpcHmIP_RF] Received no events from interface CB2010001071001102 for 1200 seconds
2019.07.28 02:50:35 3: ABFALL Muelltonnen - CALENDAR:Muelltonnen_Kalender triggered, updating ABFALL Muelltonnen ...
2019.07.28 03:00:25 1: HMCCURPCPROC: [d_rpcBidCos_RF] Graceful shutdown
2019.07.28 03:00:25 1: HMCCURPCPROC: [d_rpcBidCos_RF] Stopping RPC server CB2001001071001102
2019.07.28 03:00:25 1: HMCCURPCPROC: [d_rpcBidCos_RF] Deregistering RPC server http://192.168.1.71:7411/fh2001 with ID CB2001001071001102 at http://192.168.1.102:2001
2019.07.28 03:00:25 1: HMCCURPCPROC: [d_rpcBidCos_RF] Callback for RPC server CB2001001071001102 deregistered
2019.07.28 03:00:25 2: HMCCURPCPROC: [d_rpcBidCos_RF] Sending signal INT to RPC server process CB2001001071001102 with PID=20017
2019.07.28 03:00:25 2: CCURPC: [d_rpcBidCos_RF] CB2001001071001102 received signal INT
2019.07.28 03:00:25 1: CCURPC: [d_rpcBidCos_RF] RPC server CB2001001071001102 stopped handling connections. PID=20017
2019.07.28 03:00:25 2: CCURPC: [d_rpcBidCos_RF] Number of I/O errors = 0
2019.07.28 03:00:25 2: HMCCURPCPROC: [d_rpcBidCos_RF] Scheduling cleanup in 8 seconds
2019.07.28 03:00:26 1: HMCCURPCPROC: [d_rpcHmIP_RF] Graceful shutdown
2019.07.28 03:00:26 1: HMCCURPCPROC: [d_rpcHmIP_RF] Stopping RPC server CB2010001071001102
2019.07.28 03:00:26 1: HMCCURPCPROC: [d_rpcHmIP_RF] Deregistering RPC server http://192.168.1.71:7420/fh2010 with ID CB2010001071001102 at http://192.168.1.102:2010
2019.07.28 03:00:26 1: HMCCURPCPROC: [d_rpcHmIP_RF] Callback for RPC server CB2010001071001102 deregistered
2019.07.28 03:00:26 2: HMCCURPCPROC: [d_rpcHmIP_RF] Sending signal INT to RPC server process CB2010001071001102 with PID=20018
2019.07.28 03:00:26 2: HMCCURPCPROC: [d_rpcHmIP_RF] Scheduling cleanup in 8 seconds
2019.07.28 03:00:26 2: CCURPC: [d_rpcHmIP_RF] CB2010001071001102 received signal INT
2019.07.28 03:00:26 1: CCURPC: [d_rpcHmIP_RF] RPC server CB2010001071001102 stopped handling connections. PID=20018
2019.07.28 03:00:26 2: CCURPC: [d_rpcHmIP_RF] Number of I/O errors = 0
2019.07.28 03:00:27 1: Server shutdown delayed due to alexa,d_rpcHmIP_RF,d_rpcBidCos_RF for max 10 sec
2019.07.28 03:00:27 1: HMCCURPCPROC: [d_rpcBidCos_RF] RPC server process CB2001001071001102 terminated.
2019.07.28 03:00:27 2: HMCCURPCPROC: [d_rpcBidCos_RF] Stop I/O handling
2019.07.28 03:00:27 1: HMCCURPCPROC: [d_rpcHmIP_RF] RPC server process CB2010001071001102 terminated.
2019.07.28 03:00:27 1: HMCCU: [d_ccu] All RPC servers inactive
2019.07.28 03:00:27 2: HMCCURPCPROC: [d_rpcHmIP_RF] Stop I/O handling
2019.07.28 03:00:27 3: alexa: read: end of file reached while sysread
2019.07.28 03:00:27 3: alexa: stopped
2019.07.28 03:00:28 0: Server shutdown
2019.07.28 03:00:28 1: Shutdown executed
2019.07.28 03:00:28 2: HMCCURPCPROC: [d_rpcBidCos_RF] Found no running processes. Cleaning up ...
2019.07.28 03:00:28 1: HMCCURPCPROC: [d_rpcBidCos_RF] Housekeeping called. Cleaning up RPC environment
2019.07.28 03:00:28 2: HMCCURPCPROC: [d_rpcHmIP_RF] Found no running processes. Cleaning up ...
2019.07.28 03:00:28 1: HMCCURPCPROC: [d_rpcHmIP_RF] Housekeeping called. Cleaning up RPC environment
2019.07.28 03:23:20 1: Including fhem.cfg
2019.07.28 03:23:21 3: WEB: port 8083 opened
2019.07.28 03:23:21 3: WEBphone: port 8084 opened
2019.07.28 03:23:21 3: WEBtablet: port 8085 opened
2019.07.28 03:23:22 2: eventTypes: loaded 5596 events from ./log/eventTypes.txt
2019.07.28 03:23:23 1: PERL WARNING: Unrecognized escape \w passed through at ./FHEM/10_TASMOTA_DEVICE.pm line 247, <$fh> line 232.
2019.07.28 03:23:23 1: PERL WARNING: TASMOTA::DEVICE::Expand() called too early to check prototype at ./FHEM/10_TASMOTA_DEVICE.pm line 287, <$fh> line 232.
2019.07.28 03:23:23 1: PERL WARNING: TASMOTA::DEVICE::Expand() called too early to check prototype at ./FHEM/10_TASMOTA_DEVICE.pm line 293, <$fh> line 232.
2019.07.28 03:23:24 3: telnetPort: port 7072 opened
2019.07.28 03:23:24 3: TabletUi: new ext defined infix:ftui/: dir:./www/tablet/:
2019.07.28 03:23:24 3: Registering HTTPSRV TabletUi for URL /ftui and assigned link ftui/ ...
2019.07.28 03:23:25 3: TelegramBot_Define telebot: called
2019.07.28 03:23:26 3: Opening Anrufliste device 192.168.1.1:1012
2019.07.28 03:23:26 3: FB_CALLMONITOR (Anrufliste) - loading cache file /opt/fhem/log/reverse_search.txt
2019.07.28 03:23:26 2: FB_CALLMONITOR (Anrufliste) - read 132 contacts from Cache
2019.07.28 03:23:29 2: ONKYO_AVR ONKYO_TX_NR686: Registering ONKYO_AVR for webhook URI ?/ONKYO_AVR ...
2019.07.28 03:23:29 3: Opening ONKYO_TX_NR686 device 192.168.1.89:60128
2019.07.28 03:23:32 1: HMCCU: [d_ccu] Initialized version 4.3.015
2019.07.28 03:23:32 1: HMCCU: [d_ccu] HMCCU: Initializing device
2019.07.28 03:23:33 1: HMCCU: [d_ccu] HMCCU: Read 5 devices with 120 channels from CCU 192.168.1.102
2019.07.28 03:23:33 1: HMCCU: [d_ccu] HMCCU: Read 3 interfaces from CCU 192.168.1.102
2019.07.28 03:23:33 1: HMCCU: [d_ccu] HMCCU: Read 0 programs from CCU 192.168.1.102
2019.07.28 03:23:33 1: HMCCU: [d_ccu] HMCCU: Read 0 virtual groups from CCU 192.168.1.102
2019.07.28 03:23:33 1: HMCCURPCPROC: [d_rpcBidCos_RF] Initialized version 1.7.001 for interface BidCos-RF with I/O device d_ccu
2019.07.28 03:23:33 1: HMCCURPCPROC: [d_rpcHmIP_RF] Initialized version 1.7.001 for interface HmIP-RF with I/O device d_ccu
2019.07.28 03:23:34 3: Xiaomi_Roborock: initialized, using Rijndael
2019.07.28 03:23:34 3: VISSMAN_Heizung - Passwort war bereits gespeichert
2019.07.28 03:23:35 3: FUIP: Registering ui for URL /ui
2019.07.28 03:23:35 1: PERL WARNING: Use of uninitialized value in lc at fhem.pl line 5345.
2019.07.28 03:23:40 1: PERL WARNING: Subroutine YAAHM_restore redefined at ./FHEM/95_YAAHM.pm line 1029, <$fh> line 1903.
2019.07.28 03:23:40 1: PERL WARNING: Subroutine YAAHM_setWeeklyTime redefined at ./FHEM/95_YAAHM.pm line 1991, <$fh> line 1903.
2019.07.28 03:23:40 1: [YAAHM_Define] data hash restored from save file with date 2019-07-22 22:23:17
2019.07.28 03:23:40 1: [YAAHM] finds 1 Astro devices, module not loaded separately
2019.07.28 03:23:40 3: [Zeitsteuerung V3.1] Added hidden room 'ProfileRoom' to WEB
2019.07.28 03:23:40 3: [Zeitsteuerung V3.1] Added hidden room 'ProfileRoom' to WEBphone
2019.07.28 03:23:40 3: [Zeitsteuerung V3.1] Added hidden room 'ProfileRoom' to WEBtablet
2019.07.28 03:23:43 3: [SamsungAV] Samsung_TV defined with host: 192.168.1.38 port: 8001
2019.07.28 03:23:44 0: [echodevice] load ECHO Device ECHO_G090VC0991170SV8
2019.07.28 03:23:44 0: [echodevice] load ECHO Device ECHO_G090U50991230BJP
2019.07.28 03:23:44 1: Including ./log/fhem.save
already connected to 192.168.1.98:5555
2019.07.28 03:23:46 3: ADB_Start return value: -1
2019.07.28 03:23:46 3: Opening Mosquitto device 127.0.0.1:1883
2019.07.28 03:23:46 3: Mosquitto device opened
2019.07.28 03:23:46 3: Opening Nut device 127.0.0.1:5333
2019.07.28 03:23:46 3: Nut device opened
2019.07.28 03:23:46 3: [SamsungAV] device Samsung_TV initialising....
2019.07.28 03:23:46 3: Opening Schluessel_BTle device 127.0.0.1:5333
2019.07.28 03:23:46 3: Schluessel_BTle device opened
2019.07.28 03:23:46 2: alexa: starting alexa-fhem: /usr/local/bin/alexa-fhem -c ./alexa-fhem.cfg -a xx:xx
2019.07.28 03:23:46 3: alexa: starting
2019.07.28 03:23:46 3: alexa: using logfile: ./log/alexa-2019-07-28.log
2019.07.28 03:23:46 0: HMCCU: Start of RPC server after FHEM initialization in 12 seconds
2019.07.28 03:23:46 3: ESPEasy espBridge: Bridge v2.18 port [TCP:IPV4:8383] opened.
2019.07.28 03:23:47 3: mail: connected to mx.freenet.de
2019.07.28 03:23:47 3: mail: logged in to fhem-trs@freenet.de
2019.07.28 03:23:47 0: Featurelevel: 5.9
2019.07.28 03:23:47 0: Server started with 298 defined entities (fhem.pl:19805/2019-07-09 perl:5.024001 os:linux user:fhem pid:5063)
2019.07.28 03:23:50 3: Xiaomi_Roborock: disconnecting
2019.07.28 03:23:50 2: Xiaomi_Roborock: connecting
2019.07.28 03:23:50 3: Xiaomi_Roborock: initialized
2019.07.28 03:23:50 3: [Zeitsteuerung V3.1] Weblink Zeitsteuerung_weblink created
2019.07.28 03:23:50 3: [Zeitsteuerung V3.1] Weblink Zeitsteuerung_shortlink created
2019.07.28 03:23:50 3: telnetForBlockingFn_1564277030: port 33547 opened
2019.07.28 03:23:51 3: Anrufliste device opened
2019.07.28 03:23:52 1: 192.168.1.89:60128 disconnected, waiting to reappear (ONKYO_TX_NR686)
2019.07.28 03:23:55 3: ABFALL Muelltonnen - CALENDAR:Muelltonnen_Kalender triggered, updating ABFALL Muelltonnen ...
2019.07.28 03:23:56 1: [YAAHM_updater] on device Zeitsteuerung called for this day
2019.07.28 03:23:56 1: PERL WARNING: Use of uninitialized value in string comparison (cmp) at ./FHEM/95_YAAHM.pm line 284.
2019.07.28 03:23:57 1: 192.168.1.89:60128 reappeared (ONKYO_TX_NR686)
2019.07.28 03:23:57 1: RMDIR: ./restoreDir/save/2019-07-23
2019.07.28 03:23:58 2: HMCCU: [d_ccu] Get RPC device for interface BidCos-RF
2019.07.28 03:23:58 2: HMCCU: [d_ccu] Get RPC device for interface HmIP-RF
2019.07.28 03:23:58 2: HMCCURPCPROC: [d_rpcBidCos_RF] RPC server process started for interface BidCos-RF with PID=5419
2019.07.28 03:23:58 2: CCURPC: [d_rpcBidCos_RF] Initializing RPC server CB2001001071001102 for interface BidCos-RF
2019.07.28 03:23:58 1: HMCCURPCPROC: [d_rpcBidCos_RF] RPC server starting
2019.07.28 03:23:59 2: HMCCURPCPROC: [d_rpcHmIP_RF] RPC server process started for interface HmIP-RF with PID=5420
2019.07.28 03:23:59 1: HMCCURPCPROC: [d_rpcHmIP_RF] RPC server starting
2019.07.28 03:23:59 2: CCURPC: [d_rpcHmIP_RF] Initializing RPC server CB2010001071001102 for interface HmIP-RF
2019.07.28 03:23:59 2: HMCCURPCPROC: [d_rpcBidCos_RF] Callback server CB2001001071001102 created. Listening on port 7411
2019.07.28 03:23:59 2: CCURPC: [d_rpcBidCos_RF] CB2001001071001102 accepting connections. PID=5419
2019.07.28 03:23:59 2: HMCCURPCPROC: [d_rpcHmIP_RF] Callback server CB2010001071001102 created. Listening on port 7420
2019.07.28 03:23:59 2: CCURPC: [d_rpcHmIP_RF] CB2010001071001102 accepting connections. PID=5420
2019.07.28 03:23:59 2: AttrTemplates: got 98 entries
2019.07.28 03:24:00 2: HMCCURPCPROC: [d_rpcBidCos_RF] RPC server CB2001001071001102 enters server loop
2019.07.28 03:24:00 2: HMCCURPCPROC: [d_rpcBidCos_RF] Registering callback http://192.168.1.71:7411/fh2001 of type A with ID CB2001001071001102 at http://192.168.1.102:2001
2019.07.28 03:24:00 1: HMCCURPCPROC: [d_rpcBidCos_RF] RPC server CB2001001071001102 running
2019.07.28 03:24:00 1: HMCCURPCPROC: [d_rpcBidCos_RF] Scheduled CCU ping every 300 seconds
2019.07.28 03:24:00 2: HMCCURPCPROC: [d_rpcHmIP_RF] RPC server CB2010001071001102 enters server loop
2019.07.28 03:24:00 2: HMCCURPCPROC: [d_rpcHmIP_RF] Registering callback http://192.168.1.71:7420/fh2010 of type A with ID CB2010001071001102 at http://192.168.1.102:2010
2019.07.28 03:24:00 1: HMCCURPCPROC: [d_rpcHmIP_RF] RPC server CB2010001071001102 running
2019.07.28 03:24:00 2: CCURPC: [d_rpcBidCos_RF] CB2001001071001102 NewDevice received 55 device and channel specifications
2019.07.28 03:24:00 1: HMCCU: [d_ccu] All RPC servers running
2019.07.28 03:24:01 2: HMCCU: [d_ccu] Updated devices for interface filter BidCos-RF|HmIP-RF. Success=3 Failed=0
2019.07.28 03:24:01 2: CCURPC: [d_rpcHmIP_RF] CB2010001071001102 NewDevice received 70 device and channel specifications
2019.07.28 03:24:05 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at FHEM/HttpUtils.pm line 870.
2019.07.28 03:24:05 3: set VISSMAN_Heizung WW-Solltemperatur 46
2019.07.28 03:24:07 3: set VISSMAN_Heizung HK1-Solltemperatur_normal 23
2019.07.28 03:24:09 1: PERL WARNING: Use of uninitialized value in string eq at ./FHEM/98_vitoconnect.pm line 1331.
2019.07.28 03:44:01 2: HMCCURPCPROC: [d_rpcHmIP_RF] Received no events from interface CB2010001071001102 for 1200 seconds
2019.07.28 03:54:40 3: set VISSMAN_Heizung WW-Solltemperatur 46
2019.07.28 03:54:42 3: set VISSMAN_Heizung HK1-Solltemperatur_normal 23
2019.07.28 03:54:47 3: Xiaomi_Roborock: connection timeout
2019.07.28 03:57:47 3: Xiaomi_Roborock: disconnecting
2019.07.28 03:57:47 2: Xiaomi_Roborock: connecting
2019.07.28 03:57:47 3: Xiaomi_Roborock: initialized
2019.07.28 04:00:00 3: ESPEasy ESPEasy_ESP_Easy_UP_button: set ESPEasy_ESP_Easy_UP_button event on
2019.07.28 04:06:36 2: HMCCURPCPROC: [d_rpcHmIP_RF] Received no events from interface CB2010001071001102 for 1200 seconds
2019.07.28 04:23:52 3: ABFALL Muelltonnen - CALENDAR:Muelltonnen_Kalender triggered, updating ABFALL Muelltonnen ...
2019.07.28 04:24:59 3: set VISSMAN_Heizung WW-Solltemperatur 46
2019.07.28 04:25:00 3: set VISSMAN_Heizung HK1-Solltemperatur_normal 23
2019.07.28 04:26:36 2: HMCCURPCPROC: [d_rpcHmIP_RF] Received no events from interface CB2010001071001102 for 1200 seconds
2019.07.28 04:55:37 3: set VISSMAN_Heizung WW-Solltemperatur 46
2019.07.28 04:55:38 3: set VISSMAN_Heizung HK1-Solltemperatur_normal 23
2019.07.28 05:00:00 3: ESPEasy ESPEasy_ESP_Easy_UP_button: set ESPEasy_ESP_Easy_UP_button event off
2019.07.28 05:02:42 2: HMCCURPCPROC: [d_rpcHmIP_RF] Received no events from interface CB2010001071001102 for 1200 seconds
2019.07.28 05:10:18 3: ESPEasy ESPEasy_ESP_Easy_UP2_Relais: set ESPEasy_ESP_Easy_UP2_Relais event on
2019.07.28 05:13:59 3: ESPEasy ESPEasy_ESP_Easy_UP2_Relais: set ESPEasy_ESP_Easy_UP2_Relais event off
2019.07.28 05:20:42 1: PERL WARNING: Use of uninitialized value $installation in concatenation (.) or string at ./FHEM/98_vitoconnect.pm line 1265.
2019.07.28 05:20:42 1: PERL WARNING: Use of uninitialized value $gw in concatenation (.) or string at ./FHEM/98_vitoconnect.pm line 1268.
2019.07.28 05:20:42 1: PERL WARNING: Use of uninitialized value $installation in concatenation (.) or string at ./FHEM/98_vitoconnect.pm line 1284.
2019.07.28 05:20:42 1: PERL WARNING: Use of uninitialized value $gw in concatenation (.) or string at ./FHEM/98_vitoconnect.pm line 1284.
2019.07.28 05:23:52 3: ABFALL Muelltonnen - CALENDAR:Muelltonnen_Kalender triggered, updating ABFALL Muelltonnen ...
2019.07.28 05:25:00 1: PERL WARNING: Use of uninitialized value $mval in substitution (s///) at ./FHEM/95_YAAHM.pm line 1209.
2019.07.28 05:25:00 3: eval: {YAAHM_time('Zeitsteuerung','sunrise',1)}
2019.07.28 05:25:00 1: PERL WARNING: Use of uninitialized value $nval in substitution (s///) at ./FHEM/95_YAAHM.pm line 1210.
2019.07.28 05:25:00 3: eval: {YAAHM_time('Zeitsteuerung','sunrise',1)}
2019.07.28 05:25:00 1: PERL WARNING: Use of uninitialized value $tval in substitution (s///) at ./FHEM/95_YAAHM.pm line 1211.
2019.07.28 05:25:00 3: eval: {YAAHM_time('Zeitsteuerung','sunrise',1)}
2019.07.28 05:25:00 1: PERL WARNING: Use of uninitialized value $mval in numeric ge (>=) at ./FHEM/95_YAAHM.pm line 1214.
2019.07.28 05:25:00 3: eval: {YAAHM_time('Zeitsteuerung','sunrise',1)}
2019.07.28 05:25:00 1: PERL WARNING: Use of uninitialized value $nval in numeric gt (>) at ./FHEM/95_YAAHM.pm line 1214.
2019.07.28 05:25:00 3: eval: {YAAHM_time('Zeitsteuerung','sunrise',1)}
2019.07.28 05:25:00 1: PERL WARNING: Use of uninitialized value $xval in concatenation (.) or string at ./FHEM/95_YAAHM.pm line 1337.
2019.07.28 05:25:00 3: eval: {YAAHM_time('Zeitsteuerung','sunrise',1)}
2019.07.28 05:25:00 1: PERL WARNING: Use of uninitialized value $xval in concatenation (.) or string at ./FHEM/95_YAAHM.pm line 1339.
2019.07.28 05:25:00 3: eval: {YAAHM_time('Zeitsteuerung','sunrise',1)}
2019.07.28 05:25:00 1: [YAAHM_time] executing
2019.07.28 05:25:00 1: PERL WARNING: Use of uninitialized value $cmd in pattern match (m//) at fhem.pl line 1066.
2019.07.28 05:25:00 3: eval: {YAAHM_time('Zeitsteuerung','sunrise',1)}
2019.07.28 05:25:34 2: HMCCURPCPROC: [d_rpcHmIP_RF] Received no events from interface CB2010001071001102 for 1200 seconds
2019.07.28 05:26:04 3: set VISSMAN_Heizung WW-Solltemperatur 46
2019.07.28 05:26:05 3: set VISSMAN_Heizung HK1-Solltemperatur_normal 23
2019.07.28 05:30:00 3: ESPEasy ESPEasy_ESP_Easy_UP2_Relais: set ESPEasy_ESP_Easy_UP2_Relais event on
2019.07.28 05:31:30 3: ESPEasy ESPEasy_ESP_Easy_UP2_Relais: set ESPEasy_ESP_Easy_UP2_Relais event off
2019.07.28 05:45:34 2: HMCCURPCPROC: [d_rpcHmIP_RF] Received no events from interface CB2010001071001102 for 1200 seconds
2019.07.28 05:52:47 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/95_YAAHM.pm line 3615.
2019.07.28 05:52:47 3: eval: {YAAHM_Longtable("Zeitsteuerung")}
2019.07.28 05:52:47 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/95_YAAHM.pm line 3636.
2019.07.28 05:52:47 3: eval: {YAAHM_Longtable("Zeitsteuerung")}
2019.07.28 05:52:47 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/95_YAAHM.pm line 3643.
2019.07.28 05:52:47 3: eval: {YAAHM_Longtable("Zeitsteuerung")}
2019.07.28 05:52:47 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/95_YAAHM.pm line 3655.
2019.07.28 05:52:47 3: eval: {YAAHM_Longtable("Zeitsteuerung")}
2019.07.28 05:52:47 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/95_YAAHM.pm line 3705.
2019.07.28 05:52:47 3: eval: {YAAHM_Longtable("Zeitsteuerung")}
2019.07.28 05:52:47 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/95_YAAHM.pm line 3754.
2019.07.28 05:52:47 3: eval: {YAAHM_Longtable("Zeitsteuerung")}
2019.07.28 05:56:37 3: set VISSMAN_Heizung WW-Solltemperatur 46
2019.07.28 05:56:39 3: set VISSMAN_Heizung HK1-Solltemperatur_normal 23
2019.07.28 06:00:00 1: [YAAHM_time] executing { fhem('set Klingelschalter on')}
2019.07.28 06:05:34 2: HMCCURPCPROC: [d_rpcHmIP_RF] Received no events from interface CB2010001071001102 for 1200 seconds
2019.07.28 06:23:52 3: ABFALL Muelltonnen - CALENDAR:Muelltonnen_Kalender triggered, updating ABFALL Muelltonnen ...
2019.07.28 06:26:58 3: set VISSMAN_Heizung WW-Solltemperatur 46
2019.07.28 06:27:00 3: set VISSMAN_Heizung HK1-Solltemperatur_normal 23
Gruss
Thorsten
Sonst noch etwas, das ich erledigen soll?
pah
Moin,
du sollst gar nichts erledigen. Das ist ein Forum, wo alle antworten können. Vielleicht hatte jemand hier schon das gleiche Symtom. Jeder hilft jedem, das ist doch der Grundgedanke.
Gruss
Hallo pah, ich habe eine Frage. Das Datum/Wochentag innerhalb von yaahm ist falsch (siehe screenshot von heute, Sonntag), aber der Rechner selbst hat ein korrektes Datum. Kann ich das händisch einstellen oder ist das ein Bug? Ich vermute, dass das seit der Zeitumstellung falsch war.
Ruf mal händisch in der FHEM-Komandozeile auf
{YAAHM_GetDayStatus($defs{'<name des YAAHM-Devices>'})}
Scheint ein Bug zu sein, den ich irgendwie abfangen muss.
LG
pah
Das kann ich zwar, es erscheint aber keine Anzeige. Verbose 5 gibt mir im Logfile
2019.11.03 11:22:45 5: [Astro] No horizon attribute defined, using 0.0� for morning and evening
2019.11.03 11:22:45 5: [Astro] No horizon attribute defined, using 0.0� for morning and evening
2019.11.03 11:22:45 5: [Astro] No horizon attribute defined, using 0.0� for morning and evening
2019.11.03 11:22:45 5: [Astro] No horizon attribute defined, using 0.0� for morning and evening
2019.11.03 11:22:45 5: [Astro] No horizon attribute defined, using 0.0� for morning and evening
2019.11.03 11:22:45 5: [Astro] No horizon attribute defined, using 0.0� for morning and evening
2019.11.03 11:22:45 5: [Astro] No horizon attribute defined, using 0.0� for morning and evening
2019.11.03 11:22:45 5: [Astro] No horizon attribute defined, using 0.0� for morning and evening
2019.11.03 11:22:45 5: [Astro] No horizon attribute defined, using 0.0� for morning and evening
2019.11.03 11:23:22 5: [YAAHM_checkstate] on device Profil called
und das list vom Gerät sieht so aus
Internals:
FUUID 5c782b59-f33f-1115-d45f-e97b23f152087a1f
NAME Profil
NOTIFYDEV global,Profil
NR 165
STATE Initialized
TYPE YAAHM
VERSION 3.1
DATA:
savedate 2019-11-03 08:16:56
DD:
HASH(0x59ee390)
HASH(0x59ee2e8)
HASH(0x59ee198)
DT:
aftermidnight:
02:01
02:01
set DbLogRep delSeqDoublets delete;{ DatenSetzen()};
;
afternoon:
14:00
undef
undef
;
aftersunrise:
08:06
01:00
undef
;
aftersunset:
17:14
00:40
undef
;
beforemidnight:
23:55
00:05
setreading EntkalkerWasserTagesLog logentry [Wasserzaehler_IEC_01:energyCalc]; {RegressionSetzen()}
;
beforesunrise:
06:06
01:00
undef
;
beforesunset:
15:34
01:00
undef
;
evening:
18:30
undef
undef
;
morning:
06:00
undef
{ LogFileEintraegeSenden();;Plananzeige()}
;
night:
23:00
undef
set LampeGarage,ShellyHerdlampe,ShellyArbeitszimmer,Dimmer,LampeKellerRund,LampeKellerDurchgang,Sonoff_s20_3 off
;
noon:
13:00
undef
undef
;
sleep:
22:30
undef
undef
undef
sunrise:
07:06
undef
get Kamera1,Kamera2,Kamera3,Kamera4 image
;
sunset:
16:34
undef
get Kamera1,Kamera2,Kamera3,Kamera4 image
;
wakeup:
06:15
undef
undef
undef
HSM:
mode normal
state unsecured
time sunrise
WT:
HASH(0x59b4600)
HASH(0x5929d68)
HASH(0x59b6148)
HASH(0x59b5c80)
XT:
READINGS:
2019-11-03 08:17:05 housemode normal
2019-11-03 07:04:00 housephase daytime
2019-04-12 22:01:57 housestate secured
2019-11-03 07:04:00 housetime sunrise
2018-11-07 23:50:00 lockstate 0
2019-11-02 23:00:36 next_0
2019-11-02 23:00:36 next_1
2019-11-02 23:00:36 next_2
2019-11-03 11:22:45 next_3
2019-11-03 07:04:00 next_housetime sunrise
2019-11-03 08:17:05 prev_housemode party
2019-04-12 22:01:57 prev_housestate protected
2019-11-03 07:04:00 prev_housetime morning
2019-11-03 11:22:45 ring_0 off
2019-11-03 11:22:45 ring_0_1 06:10
2019-11-03 11:22:45 ring_0_1x 06:10
2019-11-03 11:22:45 ring_0x off
2019-11-03 11:22:45 ring_1 off
2019-11-03 11:22:45 ring_1_1 06:25
2019-11-03 11:22:45 ring_1_1x 06:25
2019-11-03 11:22:45 ring_1x off
2019-11-03 11:22:45 ring_2 off
2019-11-03 11:22:45 ring_2_1 off
2019-11-03 11:22:45 ring_2_1x off
2019-11-03 11:22:45 ring_2x off
2019-11-03 11:22:45 ring_3 off
2019-11-03 11:22:45 ring_3_1 off
2019-11-03 11:22:45 ring_3_1x off
2019-11-03 11:22:45 ring_3x off
2019-11-03 11:22:45 s_aftermidnight 02:01
2019-11-03 11:22:45 s_afternoon 14:00
2019-11-03 11:22:45 s_aftersunrise 08:06
2019-11-03 11:22:45 s_aftersunset 17:14
2019-11-03 11:22:45 s_beforemidnight 23:55
2019-11-03 11:22:45 s_beforesunrise 06:06
2019-11-03 11:22:45 s_beforesunset 15:34
2019-11-03 11:22:45 s_evening 18:30
2019-11-03 11:22:45 s_morning 06:00
2019-11-03 11:22:45 s_night 23:00
2019-11-03 11:22:45 s_noon 13:00
2019-11-03 11:22:45 s_sleep 22:30
2019-11-03 11:22:45 s_sunrise 07:06
2019-11-03 11:22:45 s_sunset 16:34
2019-11-03 11:22:45 s_wakeup 06:15
2019-11-03 08:16:56 savedate 2019-11-03 08:16:56
2019-11-03 11:23:22 sdev_housestate <html><table></table></html>
2019-11-03 11:23:22 sec_housestate secure
2019-10-16 06:45:21 state Initialized
2019-11-03 11:23:22 sym_housestate <html><div style="color:green">✓</div></html>
2019-11-01 23:00:36 todayDesc --
2019-11-02 23:00:36 todayType weekend
2019-11-03 11:22:45 today_0 off
2019-11-03 11:22:45 today_0_e enabled
2019-11-03 11:22:45 today_1 off
2019-11-03 11:22:45 today_1_e enabled
2019-11-03 11:22:45 today_2 off
2019-11-03 11:22:45 today_2_e enabled
2019-11-03 11:22:45 today_3 off
2019-11-03 11:22:45 today_3_e enabled
2019-10-31 23:00:36 tomorrowDesc --
2019-11-03 11:17:31 tomorrowType workday
2019-11-03 11:22:45 tomorrow_0 06:10
2019-11-03 11:22:45 tomorrow_0_e enabled
2019-11-03 11:22:45 tomorrow_1 06:25
2019-11-03 11:22:45 tomorrow_1_e enabled
2019-11-03 11:22:45 tomorrow_2 off
2019-11-03 11:22:45 tomorrow_2_e enabled
2019-11-03 11:22:45 tomorrow_3 off
2019-11-03 11:22:45 tomorrow_3_e enabled
2019-11-03 08:17:05 tr_errmsg
2019-11-03 08:17:05 tr_housemode Normal
2019-11-03 07:04:00 tr_housephase Tageszeit
2019-04-12 22:01:57 tr_housestate Gesichert
2019-11-03 07:04:00 tr_housetime Sonnenaufgang
2019-11-02 23:00:36 tr_todayType Wochenende
2019-11-03 11:17:31 tr_tomorrowType Arbeitstag
2019-11-02 23:00:36 tr_twodaysType Arbeitstag
2019-11-03 11:22:45 tr_wake_0 6:10 morgen
2019-11-03 11:22:45 tr_wake_1 6:25 morgen
2019-11-03 11:22:45 tr_wake_2 off heute und morgen
2019-11-03 11:22:45 tr_wake_3 off heute und morgen
2019-10-31 23:00:36 twodaysDesc --
2019-11-03 11:17:31 twodaysType workday
TIMER:
Profil_aftermidnight:
HASH Profil
MODIFIER aftermidnight
NAME Profil_aftermidnight
Profil_check:
HASH Profil
MODIFIER check
NAME Profil_check
Attributes:
group intern
holidayDevices berlin
room ProfileRoom
stateDevices Garage::locked:locked:locked:locked, Schlafzimmerfenster::closed:closed:closed:closed, Badezimmerfenster::closed:closed:closed:closed, BadUntenfenster::closed:closed:closed:closed,
stateInterval 3
vacationDevices ferien
verbose 5
Das Datum ist jetzt korrekt.
Danke für's Anschauen!
Da soll auch keine Anzeige erscheinen.
Der Knackpunkt ist, dass diese Routine normalerweise kurz nach Mitternacht aufgerufen wird. Allerdings nicht durch ein externes Notity, sondern durch einen internen 24 Stunden-Timer. Wenn nun die Uhr eine Stunde zurückgestellt wird, erfolgt der Aufruf eine Stunde vor Mitternacht (und in 24-Stunden-Abständen danach). Ergo: Immer falsches Dateum, bis das Ding einmal manuell getriggert wird.
LG
pah
das war heute morgen wieder falsch, was kann ich da tun: manuell den Befehl um kurz vor Mitternacht auslösen?
(https://uploads.tapatalk-cdn.com/20191104/edcebf187a71e033f6aad5cb0ef1f0ae.jpg)
Gesendet von iPad mit Tapatalk Pro
Äh - nö. Wenn er einmal manuell ausgelöst wurde, stellt sich der Timer wieder richtig ein.
Den Fehler verstehe ich auch nicht, bei mir tritt er nicht auf.
LG
pah
Verstehe ich das richtig, dass dieser Befehl einmal nach Mitternacht (nicht vor Mitternacht) angegeben werden muss? Dann stelle ich das mit einem at ein und gut ist.
Neien - das macht YAAHM automatisch.
Beim ersten (oder manuellen) Aufruf wird der interne Timer auf kurz nach Mitternacht gesetzt, und an kommenden Tagen diese Routine automatisch ausgeführt.
Der einzelne manuelle Aufruf dient nur dazu, das System einmal mit der echten Zeit zu synchronisieren.
Bitte versuch mal, alle Timer mit den entsprechenden Buttons neu zu starten.
LG
pah
OK, habe ich gemacht (und hatte ich meines Wissens auch gestern, komisch). Ich berichte, ob sich das morgen umstellt.
hat nicht geklappt, mein Profil ist nach wie vor auf Montag. Komisch. Kann ich mir denn die timer, die da gesetzt wurden, anzeigen lassen zur Fehlersuche?
Ich behelfe mir jetzt erstmal mit einem regelmässigen Aufruf der Funktion oben.
PS Kann das eine Erklärung sein:
2019.11.04 23:00:00 1: [YAAHM_tonight] on device Profil called for this day
2019.11.04 23:00:38 1: [YAAHM_updater] on device Profil called for this day
Zitat von: trs am 21 Juli 2019, 11:08:01
Aha, also "Start Tages-Timer", "Start Wochen-Timer", und dann "set Zeitsteuerung save"? Probiere ich noch mal. Wie stelle ich am einfachsten fest, ob die Timer nach dem Neustart laufen?
Gruss
Thorsten
Also ich habe das gleiche Problem. Nach jedem Neustart arbeiten die Timer nicht mehr. Die grünen Haken sind immer da. Ich muss dann "Start Wochen-Timer" und "Start Tages-Timer" manuell durchführen und anschliessend das "Save config" und dann läuft es. Aber ich habe jetzt keine Ahnung, wie ich den Start der Timer als Befehl ausführen kann. Wenn ich das nicht automatisch bei jedem Start machen kann, nützt mir das ganze Modul nichts. Das ist wirklich sehr schade. Zumal ich jetzt schon tagelang am Probieren bin und mir das Modul sehr gut gefällt, da man hier seine ganze Zeitsteuerung an einer Stelle hat und nicht an vielen verschiedenen.
Viele Grüße Bernd
@andies Die Meldung muss kurz _nach_ Mitternacht kommen, also z.B.
Zitat2019.11.04 00:00:33 1: [YAAHM_updater] on device YYY called for this day
.
Die Routine dafür lautet
sub YAAHM_updater($) {
my ($timerHash) = @_;
my $hash;
my $next;
my $name = $hash->{NAME};
#-- start timer for updates - when device is reloaded
if( defined($firstcall) && ($firstcall==1) ){
#-- timerHash is device hash
$hash = $timerHash;
my ($sec, $min, $hour, $day, $month, $year, $wday,$yday,$isdst) = localtime(time);
$next = gettimeofday()+(23-$hour)*3600+(59-$min)*60+(59-$sec)+34;
$firstcall=0;
#-- continue timer for updates
}else{
#-- timerHash is internal hash
$hash = $timerHash->{HASH};
$next = gettimeofday()+86400;
}
#-- safeguard if hash is not properly indirected
if( defined($hash->{HASH}) ){
$hash = $hash->{HASH};
}
YAAHM_RemoveInternalTimer("aftermidnight",$hash);
YAAHM_InternalTimer("aftermidnight",$next, "YAAHM_updater", $hash, 0);
Log 1,"[YAAHM_updater] on device ".$hash->{NAME}." called for this day";
YAAHM_GetDayStatus($hash);
YAAHM_startDeviceActions($name);
return undef;
}
Wie man sieht, wird beim ersten Aufruf (wenn die globale Variable $firstcall==1 ist) der Timer so gesetzt, dass um 33 Sekunden nach Mitternacht GetDayStatus aufgerufen wird. Und zwar auch nach jedem FHEM-Neustart.
Also vollkommen unklar, wieso der Timer bei Dir eine Stunde zu früh kommt. Der Fehler ist bisher auch noch nirgendwo sonst aufgetreten.
Du kannst diese Update-Funktion manuell mit firstcall=1 rufen, indem Du den Befehl "set <YAAHM-Device> initialize" ausführst - danach sollte aber wirklich alles in Ordnung sein.
@BerndMiles: Das ist ein ganz anderes Problem.
Diese Timer sind FHEM-Devices und arbeiten nach jedem Neustart ordentlich, wenn die Konfiguration einmal gesichert worden ist.
ZitatAber ich habe jetzt keine Ahnung, wie ich den Start der Timer als Befehl ausführen kann
Hm. Warum baue ich wohl drei fette Buttons "Start ..-Timer" auf die Benutzungsoberfläche?
LG
pah
Zitat von: Prof. Dr. Peter Henning am 05 November 2019, 13:03:59
@BerndMiles: Das ist ein ganz anderes Problem. Diese Timer sind FHEM-Devices und arbeiten nach jedem Neustart ordentlich, wenn die Konfiguration einmal gesichert worden ist. Hm. Warum baue ich wohl drei fette Buttons "Start ..-Timer" auf die Benutzungsoberfläche?
LG
pah
Hallo pah,
wenn es bei mir funktionieren würde, dann würde ich doch hier nicht schreiben. Und da es bei mir halt nicht klappt, frage ich doch nach. Ich kann doch nicht nach jedem Neustart manuell auf die "fetten" Buttons auf der Oberfläche klicken.
Gruß Bernd
Hallo pah,
und noch was anderes. Das Reading housephase und wahrscheinlich noch mehr vom YAAHM Device wird dann auch nicht mehr aktualisiert. So hatte ich dort heute mittags um zwölf noch nighttime drinnen stehen.
Viele Grüße Bernd
Na, dann scheint an der gesamten FHEM-Konfiguration etwas nicht zu stimmen.
ZitatIch kann doch nicht nach jedem Neustart manuell
Das ist auch nicht nötig, und war auch nicht gefragt. Gefragt war vielmehr
ZitatAber ich habe jetzt keine Ahnung, wie ich den Start der Timer als Befehl ausführen kann
pah
Zitat von: andies am 03 November 2019, 08:44:23
Hallo pah, ich habe eine Frage. Das Datum/Wochentag innerhalb von yaahm ist falsch (siehe screenshot von heute, Sonntag), aber der Rechner selbst hat ein korrektes Datum. Kann ich das händisch einstellen oder ist das ein Bug? Ich vermute, dass das seit der Zeitumstellung falsch war.
Hallo,
habe heute ähnliches Verhalten bei mir festgestellt (siehe Screenshot).
Habe dann
{YAAHM_GetDayStatus($defs{'<name des YAAHM-Devices>'})}
ausgeführt. Danach wird wieder korrekt angezeigt.
Ich beobachte mal...
VG...
Oder eben einfach ausführen "set <YAAHM-Device> initialize".
LG
pah
Hallo pah,
mal ein Beispiel. Ich ändere die Zeit vom Ereignis evening auf 20:26 Uhr. Dann starte ich den Tagestimer neu und speichere auch noch die config. Dann starte ich FHEM neu. Da läuft auch alles wunderbar durch. Und dann, wenn das Ereignis evening ausgelöst wird, steht dann folgendes im Logfile:
2019.11.05 20:26:01 1: PERL WARNING: Use of uninitialized value $mval in substitution (s///) at ./FHEM/95_YAAHM.pm line 1209.
2019.11.05 20:26:01 3: eval: {YAAHM_time('HA_YAAHM','evening',1)}
2019.11.05 20:26:01 1: PERL WARNING: Use of uninitialized value $nval in substitution (s///) at ./FHEM/95_YAAHM.pm line 1210.
2019.11.05 20:26:01 3: eval: {YAAHM_time('HA_YAAHM','evening',1)}
2019.11.05 20:26:01 1: PERL WARNING: Use of uninitialized value $tval in substitution (s///) at ./FHEM/95_YAAHM.pm line 1211.
2019.11.05 20:26:01 3: eval: {YAAHM_time('HA_YAAHM','evening',1)}
2019.11.05 20:26:01 1: PERL WARNING: Use of uninitialized value $mval in numeric ge (>=) at ./FHEM/95_YAAHM.pm line 1214.
2019.11.05 20:26:01 3: eval: {YAAHM_time('HA_YAAHM','evening',1)}
2019.11.05 20:26:01 1: PERL WARNING: Use of uninitialized value $nval in numeric gt (>) at ./FHEM/95_YAAHM.pm line 1214.
2019.11.05 20:26:01 3: eval: {YAAHM_time('HA_YAAHM','evening',1)}
2019.11.05 20:26:01 1: PERL WARNING: Use of uninitialized value $xval in concatenation (.) or string at ./FHEM/95_YAAHM.pm line 1337.
2019.11.05 20:26:01 3: eval: {YAAHM_time('HA_YAAHM','evening',1)}
2019.11.05 20:26:01 1: PERL WARNING: Use of uninitialized value $xval in concatenation (.) or string at ./FHEM/95_YAAHM.pm line 1339.
2019.11.05 20:26:01 3: eval: {YAAHM_time('HA_YAAHM','evening',1)}
2019.11.05 20:26:01 1: [YAAHM_time] executing
2019.11.05 20:26:01 1: PERL WARNING: Use of uninitialized value $cmd in pattern match (m//) at fhem.pl line 1072.
2019.11.05 20:26:01 3: eval: {YAAHM_time('HA_YAAHM','evening',1)}
Dann wird natüprlich houseTimeHelper('evening') nicht ausgeführt.
Vielleicht fehlt ja bei mir auch noch irgendwas an der Konfiguration.
Viele Grüsse Bernd
Ich vermute einen Konfigurationsfehler....
Was steht denn im Reading s_evening des YAAHM-Device?
LG
pah
Also ich habe es jetzt noch einmal gemacht für afternoon. Ich habe afternoon auf 13.35 gesetzt und im reading s_afternoon steht das auch korrekt drin. Der Fehler kommt natürlich trotzdem. Ich gebe mal die Werte vom YAAHM-Device mit. Vielleicht hilft das ja weiter.
2019.11.06 13:35:00 1: PERL WARNING: Use of uninitialized value $mval in substitution (s///) at ./FHEM/95_YAAHM.pm line 1209.
2019.11.06 13:35:00 3: eval: {YAAHM_time('HA_YAAHM','afternoon',1)}
2019.11.06 13:35:00 1: PERL WARNING: Use of uninitialized value $nval in substitution (s///) at ./FHEM/95_YAAHM.pm line 1210.
2019.11.06 13:35:00 3: eval: {YAAHM_time('HA_YAAHM','afternoon',1)}
2019.11.06 13:35:00 1: PERL WARNING: Use of uninitialized value $tval in substitution (s///) at ./FHEM/95_YAAHM.pm line 1211.
2019.11.06 13:35:00 3: eval: {YAAHM_time('HA_YAAHM','afternoon',1)}
2019.11.06 13:35:00 1: PERL WARNING: Use of uninitialized value $mval in numeric ge (>=) at ./FHEM/95_YAAHM.pm line 1214.
2019.11.06 13:35:00 3: eval: {YAAHM_time('HA_YAAHM','afternoon',1)}
2019.11.06 13:35:00 1: PERL WARNING: Use of uninitialized value $nval in numeric gt (>) at ./FHEM/95_YAAHM.pm line 1214.
2019.11.06 13:35:00 3: eval: {YAAHM_time('HA_YAAHM','afternoon',1)}
2019.11.06 13:35:00 1: PERL WARNING: Use of uninitialized value $xval in concatenation (.) or string at ./FHEM/95_YAAHM.pm line 1337.
2019.11.06 13:35:00 3: eval: {YAAHM_time('HA_YAAHM','afternoon',1)}
2019.11.06 13:35:00 1: PERL WARNING: Use of uninitialized value $xval in concatenation (.) or string at ./FHEM/95_YAAHM.pm line 1339.
2019.11.06 13:35:00 3: eval: {YAAHM_time('HA_YAAHM','afternoon',1)}
2019.11.06 13:35:00 1: [YAAHM_time] executing
2019.11.06 13:35:00 1: PERL WARNING: Use of uninitialized value $cmd in pattern match (m//) at fhem.pl line 1072.
2019.11.06 13:35:00 3: eval: {YAAHM_time('HA_YAAHM','afternoon',1)}
Internals:
FUUID 5dc18a44-f33f-7d11-2445-a0a1b7a69ba850ff
NAME HA_YAAHM
NOTIFYDEV global,HA_YAAHM
NR 1990
STATE Initialized
TYPE YAAHM
VERSION 3.1
DATA:
savedate 2019-11-06 13:33:01
DD:
HASH(0x55b01dc15b50)
HASH(0x55b01dbe9550)
HASH(0x55b01dc0b2a0)
DT:
aftermidnight:
00:01
00:01
{houseTimeHelper('aftermidnight')}
;
afternoon:
13:35
undef
{houseTimeHelper('afternoon')}
;
aftersunrise:
07:08
00:01
{houseTimeHelper('aftersunrise')}
;
aftersunset:
16:51
00:16
{houseTimeHelper('aftersunset')}
;
beforemidnight:
23:58
00:02
{houseTimeHelper('beforemidnight')}
;
beforesunrise:
07:05
00:02
{houseTimeHelper('beforesunrise')}
;
beforesunset:
16:33
00:02
{houseTimeHelper('beforesunset')}
;
evening:
18:00
undef
{houseTimeHelper('evening')}
;
morning:
06:00
undef
{houseTimeHelper('morning')}
;
night:
22:00
undef
{houseTimeHelper('night')}
;
noon:
12:00
undef
{houseTimeHelper('noon')}
;
sleep:
22:30
undef
undef
undef
sunrise:
07:07
undef
{houseTimeHelper('sunrise')}
;
sunset:
16:35
undef
{houseTimeHelper('sunset')}
;
wakeup:
06:15
undef
undef
undef
HSM:
mode normal
state unsecured
time noon
WT:
HASH(0x55b01dbfa258)
HASH(0x55b01dc0fd70)
HASH(0x55b01dc090d0)
HASH(0x55b01dbdff68)
XT:
Rolladen hoch:
cmd
earliest
event sunrise
latest
name Rolladen hoch
Rolladen runter:
cmd
earliest
event sunset
latest
name Rolladen runter
READINGS:
2019-11-05 19:57:40 housemode normal
2019-11-06 13:33:00 housephase daytime
2019-11-06 12:00:00 housetime noon
2019-11-05 15:43:29 lockstate 0
2019-11-06 13:33:00 next_0
2019-11-06 00:00:33 next_1
2019-11-06 13:33:00 next_2
2019-11-06 00:00:33 next_3
2019-11-06 12:00:00 next_housetime beforesunrise
2019-11-05 19:57:40 prev_housemode absence
2019-11-06 12:00:00 prev_housetime wakeup
2019-11-06 13:33:00 ring_0 07:30
2019-11-06 13:33:00 ring_0_1 07:30
2019-11-06 13:33:00 ring_0_1x 07:30
2019-11-06 13:33:00 ring_0x 07:30
2019-11-06 13:33:00 ring_1 22:30
2019-11-06 13:33:00 ring_1_1 22:30
2019-11-06 13:33:00 ring_1_1x 22:30
2019-11-06 13:33:00 ring_1x 22:30
2019-11-06 13:33:00 ring_2 07:00
2019-11-06 13:33:00 ring_2_1 07:00
2019-11-06 13:33:00 ring_2_1x 07:00
2019-11-06 13:33:00 ring_2x 07:00
2019-11-06 13:33:00 ring_3 22:30
2019-11-06 13:33:00 ring_3_1 22:30
2019-11-06 13:33:00 ring_3_1x 22:30
2019-11-06 13:33:00 ring_3x 22:30
2019-11-06 13:33:00 s_aftermidnight 00:01
2019-11-06 13:33:00 s_afternoon 13:35
2019-11-06 13:33:00 s_aftersunrise 07:08
2019-11-06 13:33:00 s_aftersunset 16:51
2019-11-06 13:33:00 s_beforemidnight 23:58
2019-11-06 13:33:00 s_beforesunrise 07:05
2019-11-06 13:33:00 s_beforesunset 16:33
2019-11-06 13:33:00 s_evening 18:00
2019-11-06 13:33:00 s_morning 06:00
2019-11-06 13:33:00 s_night 22:00
2019-11-06 13:33:00 s_noon 12:00
2019-11-06 13:33:00 s_sleep 22:30
2019-11-06 13:33:00 s_sunrise 07:07
2019-11-06 13:33:00 s_sunset 16:35
2019-11-06 13:33:00 s_wakeup 06:15
2019-11-06 13:33:01 savedate 2019-11-06 13:33:01
2019-11-06 13:31:27 state Initialized
2019-11-05 15:42:20 todayDesc --
2019-11-05 15:42:20 todayType workday
2019-11-06 13:33:00 today_0 07:30
2019-11-06 13:33:00 today_0_e enabled
2019-11-06 13:33:00 today_1 22:30
2019-11-06 13:33:00 today_1_e enabled
2019-11-06 13:33:00 today_2 07:00
2019-11-06 13:33:00 today_2_e enabled
2019-11-06 13:33:00 today_3 22:30
2019-11-06 13:33:00 today_3_e enabled
2019-11-05 15:42:20 tomorrowDesc --
2019-11-05 15:42:20 tomorrowType workday
2019-11-06 13:33:00 tomorrow_0 07:30
2019-11-06 13:33:00 tomorrow_0_e enabled
2019-11-06 13:33:00 tomorrow_1 22:30
2019-11-06 13:33:00 tomorrow_1_e enabled
2019-11-06 13:33:00 tomorrow_2 07:00
2019-11-06 13:33:00 tomorrow_2_e enabled
2019-11-06 13:33:00 tomorrow_3 22:30
2019-11-06 13:33:00 tomorrow_3_e enabled
2019-11-05 19:57:42 tr_errmsg
2019-11-05 19:57:40 tr_housemode Normal
2019-11-06 13:33:00 tr_housephase Tageszeit
2019-11-06 12:00:00 tr_housetime Mittag
2019-11-05 15:42:20 tr_todayType Arbeitstag
2019-11-05 15:42:20 tr_tomorrowType Arbeitstag
2019-11-05 15:42:20 tr_twodaysType Arbeitstag
2019-11-06 13:33:00 tr_wake_0 7:30 morgen
2019-11-06 13:33:00 tr_wake_1 22:30 heute
2019-11-06 13:33:00 tr_wake_2 7:00 morgen
2019-11-06 13:33:00 tr_wake_3 22:30 heute
2019-11-05 15:42:20 twodaysDesc --
2019-11-05 15:42:20 twodaysType workday
TIMER:
HA_YAAHM_aftermidnight:
HASH HA_YAAHM
MODIFIER aftermidnight
NAME HA_YAAHM_aftermidnight
HA_YAAHM_check:
HASH HA_YAAHM
MODIFIER check
NAME HA_YAAHM_check
HA_YAAHM_daytime:
HASH HA_YAAHM
MODIFIER daytime
NAME HA_YAAHM_daytime
HA_YAAHM_nighttime:
HASH HA_YAAHM
MODIFIER nighttime
NAME HA_YAAHM_nighttime
Attributes:
modeAuto 1
modeHelper houseModeHelper
room Timecontrol
sunrise SunRise
sunset SunSet
timeHelper houseTimeHelper
::) Wenn ich nach einem Reading frage, will ich keine 80 Zeilen haben...
Die Timer werden komplett korrekt ausgeführt, der Fehler ist also in der Routine houseTimeHelper zu suchen. Und sorry: Für die bin ich nicht verantwortlich.
LG
pah
Hallo pah,
du hast recht es liegt an der HouseTimeHelper-Routine. Nun habe ich mal nur das template genommen und es funktioniert.
Sobald ich aber eine Zeile dazuschreibe, kommt der Fehler wieder. Das ist schon sehr mysteriös. So was komisches hatte ich noch nie.
VG Bernd
#---------------------------------------------------------------------
}elsif( $event eq "sunrise" ){
#---------------------------------------------------------------------
}elsif( $event eq "afternoon" ){
Log 3, "Aufruf: HouseTimeHelper - afternoon";
}elsif( $event eq "beforesunrise" ){
#---------------------------------------------------------------------
}elsif( $event eq "evening" ){
Zitat von: friesenjung am 05 November 2019, 16:36:26
habe heute ähnliches Verhalten bei mir festgestellt (siehe Screenshot).
Das erste Mal taucht die Verschiebung nach Umstellung auf die Winterzeit auf:
2019.10.27 23:00:34 1: [YAAHM_updater] on device Profil called for this day
Vorher und nach
initialize anscheinend auch danach aber nicht mehr. Ich vermute daher, dass es mit dieser Umstellung zu tun hatte.
Ich denke ich habe jetzt die Ursache gefunden. Nachdem ich fhem neu gestartet habe und das nächste Event ausgelöst wird, steht housephase plötzlich auf nighttime. Das hat nun aber ganz und gar nichts mit mir zu tun. Oder ich lasse das Template unberührt, was mir aber leider dann auch nichts nützt :-).
ZitatIch vermute daher, dass es mit dieser Umstellung zu tun hatte.
Das hatte ich doch schon geschrieben. Weil die Auslösung um 00:00:33 Sommerzeit eben am Tag nach(!) der Zeitumstellung nur 23:00:33 ist. Um das abzufangen, müsste ich das Astro-Modul um den Termin der Zeitumstellung erweitern und an diesem Tag den Timer abändern. Mache ich auch irgendwann.
ZitatSobald ich aber eine Zeile dazuschreibe, kommt der Fehler wieder.
Zeichensatzfehler beim Herunterladen und Editieren. Sollte man aber bereits merken, wenn das Hilfsmodul geladen wird, in dem die houseTimeHelper-Routine steht (Fehlermeldung ...)
LG
pah
Zitat von: Prof. Dr. Peter Henning am 06 November 2019, 17:44:24
Mache ich auch irgendwann.
(Hatte ich nicht kapiert, dass das Astro war.) Das Problem taucht einmal im Jahr auf, ist übersichtlich. Ich trage was ins Wiki ein und dann kann das bei Gelegenheit raus.
ZitatHatte ich nicht kapiert, dass das Astro war
Steht in Astro im Reading ObsIsDST
LG
pah
Hallo pah,
Zeichensatzfehler beim Herunterladen und Editieren. Sollte man aber bereits merken, wenn das Hilfsmodul geladen wird, in dem die houseTimeHelper-Routine steht (Fehlermeldung ...)
LG
pah
Das ist doch Quatsch und es kommt auch keine Fehlermeldung. Ich bin jetzt auch soweit, dass ich das Modul nicht mehr nehme. Ich fühle mich auch von dir total arrogant behandelt und du versuchst überhaupt nicht zu helfen. Ich weiss, dass das alles hier freiwillig ist und niemand was tun muss, aber dieses Modul ist für mich einfach nicht verwendbar.
Das ist insofern schade, weil ich es zum ersten Mal in deinem Buch gefunden habe und es mir vom Anstz her sehr gut gefällt. Komischerweise ist da aber kein Hinweis zu finden, dass das Modul von dir geschrieben wurde. Naja, dann noch viel Erfolg.
VG Bernd
Dreimal habe ich Hilfestellungen gegeben, und dann wird es unverschämt? Dafür ist meine Zeit objektiv zu schade. Danke, bitte in Zukunft ein anderes Modul verwenden. Und das "du" lassen wir mal lieber.
paho
Sehr geehrter Herr Professor Henning,
ich habe mir gestern innerhalb von zwei Stunden mein eigenes Modul geschrieben und es funktioniert auf Anhieb, so wie ich es brauche.
Viele Grüße Bernd
Prima, gratuliere. Das kann man sicher auch anderen zur Verfügung stellen und schauen, was da so an Rückmeldungen kommt...
LG
pah
Ich habe flexible Homeoffice-Tage die ich in einem Google-Kalender verwalte. Ich würde gerne die Homeoffice-Tage wie Wochenenden behandeln. Lässt sich das mit diesem Modul abbilden oder gibt es die Möglichkeit dem Modul über ein Reading mitzuteilen "ich bin heute zu Hause" ohne das es von einer Automatik überschrieben wird? Ich dachte da an die Readings tomorrowType oder todayType.
MfG 2space
Es gibt 2 Sonderkategorien: Feiertag und Urlaubstag. Beide werden über Kalender verwaltet.
Wenn die Kategorie "HomeOffice" wie eine dieser beiden Kategorien zu behandeln ist, geht das auch jetzt schon problemlos. Wenn nicht, wäre das aus einem Kalender etwas aufwändiger. Ich selbst sage meiner Haus-Intelligenz einfach, dass sie für den folgenden Tag eine manuelle Weckzeit stellen soll.
Allerdings steht dann die Frage im Raum, ob ich nicht eine dritte Sonderkategorie einführen sollte, eben "HomeOffice". Liegt wegen der gegenwärtig boomenden neuen Arbeitsformen nahe.
LG
pah
Hallo pah, ich habe eine Frage. Heute wurde mir angezeigt, dass ein Arbeitstag sei (da mache ich jetzt mal keinen Scherz draus), siehe Screenshot. Woran kann das liegen? Ich habe folgende holiday und berlin-Feiertage eingestellt:
# Format für einzelne Tage: 1 MM-DD <Text>
1 01-01 Neujahr
1 03-08 Frauentag
1 05-01 Tag der Arbeit
1 10-03 Tag der deutschen Einheit
1 10-31 Reformationstag
1 12-25 1. Weihnachtstag
1 12-26 2. Weihnachtstag
# Osterbezogene Feiertage
# Format: 2 <relative Tage von Ostern> <Text>
2 -2 Karfreitag
2 1 Ostermontag
2 39 Christi Himmelfahrt
2 50 Pfingsten
und
# Format: X MM-DD MM-DD <Text>
4 12-23 12-31 Weihnachtsferien_2019
4 01-01 01-04 Weihnachtsferien_2020
4 02-03 02-08 Winterferien
4 04-06 04-17 Osterferien
4 05-08 05-08 unterrichtsfrei
4 05-22 05-22 unterrichtsfrei
4 06-11 06-11 Pfingstferien
4 06-25 08-07 Sommerferien
4 10-04 10-04 unterrichtsfrei
4 10-12 10-24 Herbstferien
Das device sieht so aus:
Internals:
FUUID 5c782b59-f33f-1115-d45f-e97b23f152087a1f
NAME Profil
NOTIFYDEV global,Profil
NR 150
STATE Initialized
TYPE YAAHM
VERSION 3.1
DATA:
savedate 2019-12-20 19:48:30
DD:
HASH(0x53c8f48)
HASH(0x53c6ec0)
HASH(0x1dcee30)
DT:
aftermidnight:
02:01
02:01
set DbLogRep delSeqDoublets delete;set Pikrellcam_Haustuer,Pikrellcam_Garten,Pikrellcam_Garage archive_yesterday;
;
afternoon:
14:00
undef
undef
;
aftersunrise:
09:18
01:00
undef
;
aftersunset:
16:42
00:40
undef
;
beforemidnight:
23:55
00:05
setreading EntkalkerWasserTagesLog logentry [Wasserzaehler_IEC_01:energyCalc]; {RegressionSetzen()}
;
beforesunrise:
07:18
01:00
undef
;
beforesunset:
15:02
01:00
undef
;
evening:
18:30
undef
undef
;
morning:
06:00
undef
{ LogFileEintraegeSenden();;Plananzeige()}
;
night:
23:00
undef
set LampeGarage,ShellyHerdlampe,ShellyArbeitszimmer,Dimmer,LampeKellerRund,LampeKellerDurchgang,Sonoff_s20_3 off
;
noon:
13:00
undef
undef
;
sleep:
22:30
undef
undef
undef
sunrise:
08:18
undef
get Kamera1,Kamera2,Kamera3,Kamera4 image;set Pikrellcam_Garten,Pikrellcam_Haustuer,Pikrellcam_Garage still
;
sunset:
16:02
undef
get Kamera1,Kamera2,Kamera3,Kamera4 image;set Pikrellcam_Garten,Pikrellcam_Haustuer,Pikrellcam_Garage still
;
wakeup:
06:15
undef
undef
undef
HSM:
mode normal
state unsecured
time sleep
WT:
HASH(0x53c8cc0)
HASH(0x53c8480)
HASH(0x53c8858)
HASH(0x53c83f0)
XT:
READINGS:
2019-11-04 10:05:38 housemode normal
2019-12-31 06:25:00 housephase daytime
2019-11-04 10:05:33 housestate unsecured
2019-12-31 06:25:00 housetime sleep
2018-11-07 23:50:00 lockstate 0
2019-12-31 06:10:00 next_0
2019-12-31 06:25:00 next_1
2019-12-31 00:00:34 next_2
2019-12-31 00:00:34 next_3
2019-12-31 06:25:00 next_housetime beforesunrise
2019-11-04 10:05:38 prev_housemode party
2019-11-04 10:05:33 prev_housestate secured
2019-12-31 06:25:00 prev_housetime wakeup
2019-12-31 00:00:34 ring_0 06:10
2019-12-31 00:00:34 ring_0_1 06:10
2019-12-31 00:00:34 ring_0_1x 06:10
2019-12-31 00:00:34 ring_0x 06:10
2019-12-31 00:00:34 ring_1 06:25
2019-12-31 00:00:34 ring_1_1 06:25
2019-12-31 00:00:34 ring_1_1x 06:25
2019-12-31 00:00:34 ring_1x 06:25
2019-12-31 00:00:34 ring_2 off
2019-12-31 00:00:34 ring_2_1 off
2019-12-31 00:00:34 ring_2_1x off
2019-12-31 00:00:34 ring_2x off
2019-12-31 00:00:34 ring_3 off
2019-12-31 00:00:34 ring_3_1 off
2019-12-31 00:00:34 ring_3_1x off
2019-12-31 00:00:34 ring_3x off
2019-12-31 00:00:34 s_aftermidnight 02:01
2019-12-31 00:00:34 s_afternoon 14:00
2019-12-31 00:00:34 s_aftersunrise 09:18
2019-12-31 00:00:34 s_aftersunset 16:42
2019-12-31 00:00:34 s_beforemidnight 23:55
2019-12-31 00:00:34 s_beforesunrise 07:18
2019-12-31 00:00:34 s_beforesunset 15:02
2019-12-31 00:00:34 s_evening 18:30
2019-12-31 00:00:34 s_morning 06:00
2019-12-31 00:00:34 s_night 23:00
2019-12-31 00:00:34 s_noon 13:00
2019-12-31 00:00:34 s_sleep 22:30
2019-12-31 00:00:34 s_sunrise 08:18
2019-12-31 00:00:34 s_sunset 16:02
2019-12-31 00:00:34 s_wakeup 06:15
2019-12-20 19:48:30 savedate 2019-12-20 19:48:30
2019-12-31 07:00:06 sdev_housestate <html><table></table></html>
2019-12-31 07:00:06 sec_housestate secure
2019-12-05 22:16:43 state Initialized
2019-12-31 07:00:06 sym_housestate <html><div style="color:green">✓</div></html>
2019-12-31 00:00:34 todayDesc --
2019-12-31 00:00:34 todayType workday
2019-12-31 00:00:34 today_0 06:10
2019-12-31 00:00:34 today_0_e enabled
2019-12-31 00:00:34 today_1 06:25
2019-12-31 00:00:34 today_1_e enabled
2019-12-31 00:00:34 today_2 off
2019-12-31 00:00:34 today_2_e enabled
2019-12-31 00:00:34 today_3 off
2019-12-31 00:00:34 today_3_e enabled
2019-12-31 00:00:34 tomorrowDesc --
2019-12-31 00:00:34 tomorrowType workday
2019-12-31 00:00:34 tomorrow_0 06:10
2019-12-31 00:00:34 tomorrow_0_e enabled
2019-12-31 00:00:34 tomorrow_1 06:25
2019-12-31 00:00:34 tomorrow_1_e enabled
2019-12-31 00:00:34 tomorrow_2 off
2019-12-31 00:00:34 tomorrow_2_e enabled
2019-12-31 00:00:34 tomorrow_3 off
2019-12-31 00:00:34 tomorrow_3_e enabled
2019-11-04 10:05:38 tr_errmsg
2019-11-04 10:05:38 tr_housemode Normal
2019-12-31 06:25:00 tr_housephase Tageszeit
2019-11-04 10:05:33 tr_housestate Nicht Gesichert
2019-12-31 06:25:00 tr_housetime Schlafen
2019-12-31 00:00:34 tr_todayType Arbeitstag
2019-12-31 00:00:34 tr_tomorrowType Arbeitstag
2019-12-31 00:00:34 tr_twodaysType Arbeitstag
2019-12-31 00:00:34 tr_wake_0 6:10 heute
2019-12-31 00:00:34 tr_wake_1 6:25 heute
2019-12-31 00:00:34 tr_wake_2 off heute und morgen
2019-12-31 00:00:34 tr_wake_3 off heute und morgen
2019-12-31 00:00:34 twodaysDesc --
2019-12-31 00:00:34 twodaysType workday
TIMER:
Profil_aftermidnight:
HASH Profil
MODIFIER aftermidnight
NAME Profil_aftermidnight
Profil_check:
HASH Profil
MODIFIER check
NAME Profil_check
Profil_daytime:
HASH Profil
MODIFIER daytime
NAME Profil_daytime
Profil_nighttime:
HASH Profil
MODIFIER nighttime
NAME Profil_nighttime
Profil_today:
HASH Profil
MODIFIER today
NAME Profil_today
Profil_tonight:
HASH Profil
MODIFIER tonight
NAME Profil_tonight
Attributes:
group intern
holidayDevices berlin
room ProfileRoom
stateDevices Garage::locked:locked:locked:locked, Schlafzimmerfenster::closed:closed:closed:closed, Badezimmerfenster::closed:closed:closed:closed, BadUntenfenster::closed:closed:closed:closed,
stateInterval 3
vacationDevices ferien
verbose 0
Heute ist natürlich ein Arbeitstag.
Warum das morgen auch als Arbeitstag angezeigt wird ? Kann sein, dass das holiday-Modul das immer nur auf das gegenwärtige Jahr bezieht, so sieht mir das aus.
LG
pah
Da sind ja zwei Fehler drin: Sowohl Ferien (ferien.holiday) als auch Feiertage (berlin.holiday) werden nicht beachtet. Kannst du mir einen Tipp geben, wo ich da weitersuchen kann? Ich dachte ja, dass Dein Modul das macht, aber Deiner Antwort entnehme ich, dass Du Ergebnisse anderer Module nur durchreichst, richtig?
Frohes Neues Jahr!
<edit> https://forum.fhem.de/index.php/topic,106899.msg1007428.html#msg1007428
Zitat von: Prof. Dr. Peter Henning am 01 Dezember 2019, 17:44:00
Allerdings steht dann die Frage im Raum, ob ich nicht eine dritte Sonderkategorie einführen sollte, eben "HomeOffice". Liegt wegen der gegenwärtig boomenden neuen Arbeitsformen nahe.
Aktueller denn je ;)
Hallo pah, ich habe neuerdings Fehlermeldungen der Form
2020.06.25 06:43:30 1: ERROR evaluating {YAAHM_time('Profil','aftermidnight',1)}: Month '-1' out of range 0..11 at ./FHEM/93_DbRep.pm line 2046.
und der Monat ist tatsächlich -1. Ich verstehe nicht, was da genau passiert - kannst du helfen?
<edit> https://forum.fhem.de/index.php/topic,112085.msg1067678.html#msg1067678 (https://forum.fhem.de/index.php/topic,112085.msg1067678.html#msg1067678)
Muss ich prüfen.
Also eine Problem hat sich erledigt (siehe Link), es kann natürlich sein, dass da noch irgendwo anders ein Bug sein kann.
Hallo pah, gibt Neuigkeiten 8)
2020.11.03 06:25:00 1: ERROR evaluating {YAAHM_time('Profil','sleep',1)}: Reference to nonexistent group in regex; marked by <-- HERE in m/\7 <-- HERE \0/ at ./FHEM/10_CUL_HM.pm line 4597.
Reference to nonexistent group in regex; marked by <-- HERE in m/\1 <-- HERE \0\0/ at ./FHEM/10_CUL_HM.pm line 4597.
Öh. Noch nie gehabt.
LG
pah
Wird bei mir schlimmer, inzwischen stürzt FHEM ab:
2020.11.05 06:25:00 1: ERROR evaluating {YAAHM_time('Profil','sleep',1)}: Reference to nonexistent group in regex; marked by <-- HERE in m/\7 <-- HERE \0/ at ./FHEM/10_CUL_HM.pm line 4597.
Reference to nonexistent group in regex; marked by <-- HERE in m/\8 <-- HERE \2/ at ./FHEM/10_CUL_HM.pm line 4597.
Kannst du mir sagen, wo ich da suchen kann? Sonst habe ich das Problem das Modul nicht mehr nützen zu können, das wäre echt ärgerlich.
Könnte es sein, dass eine ganz andere Sache das verursacht (CUL vielleicht?)
020.11.05 07:05:27 1: PERL WARNING: Argument "<html>3</html>" isn't numeric in array element at ./FHEM/95_YAAHM.pm line 3023.
2020.11.05 07:06:45 1: ACTION: EVTPART0 = status_Briefkasten: | EVTPART1 = alive
2020.11.05 07:16:45 1: ACTION: EVTPART0 = status_BadUntenfenster: | EVTPART1 = alive
2020.11.05 07:16:45 1: ACTION: EVTPART0 = status_Terassenfenster: | EVTPART1 = alive
2020.11.05 07:26:45 1: ACTION: EVTPART0 = status_Badezimmerfenster: | EVTPART1 = alive
Reference to nonexistent group in regex; marked by <-- HERE in m/\6 <-- HERE \9/ at ./FHEM/10_CUL_HM.pm line 4597.
Ichhabe versucht das nachzustellen - kann ich nicht. Muss also aus CUL_HM kommen. Das propagiert dann die Ausführung durch YAAHM, und liefert dann dort die finale Fehlermeldung.
Die Ausführung in YAAHM ist aber gekapselt in "eval", würde also niemals zum Absturz von FHEM führen. Der Fehler ist also mit einem Update von CUL_HM hineingekommen - da kann ich nicht helfen, poste das doch mal in der entsprechenden Ecke.
LG
pah
Falls hier jemand gelandet sein sollte, es liegt an https://forum.fhem.de/index.php/topic,115457.0.html (https://forum.fhem.de/index.php/topic,115457.0.html)
Hallo PAH,
habe folgende perl warnings im LOG. Könntest Du Dir das bei Gelegenheit bitte mal anschauen.
Die tauchen bei mir meistens nach einen Neustart von FHEM auf und ganz sporadisch auch ab und zu ohne Neustart.
2021.02.27 08:48:13 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/95_YAAHM.pm line 3671.
2021.02.27 08:48:13 1: eval: {YAAHM_Shorttable("YAAutoHM")}
2021.02.27 08:48:13 1: stacktrace:
2021.02.27 08:48:13 1: main::__ANON__ called by ./FHEM/95_YAAHM.pm (3671)
2021.02.27 08:48:13 1: main::YAAHM_toptable called by ./FHEM/95_YAAHM.pm (3835)
2021.02.27 08:48:13 1: main::YAAHM_Shorttable called by (eval 6212) (1)
2021.02.27 08:48:13 1: (eval) called by fhem.pl (1154)
2021.02.27 08:48:13 1: main::AnalyzePerlCommand called by ./FHEM/98_weblink.pm (106)
2021.02.27 08:48:13 1: main::weblink_FwFn called by ./FHEM/01_FHEMWEB.pm (2062)
2021.02.27 08:48:13 1: main::FW_showRoom called by ./FHEM/01_FHEMWEB.pm (1176)
2021.02.27 08:48:13 1: main::FW_answerCall called by ./FHEM/01_FHEMWEB.pm (596)
2021.02.27 08:48:13 1: main::FW_Read called by fhem.pl (3830)
2021.02.27 08:48:13 1: main::CallFn called by fhem.pl (767)
2021.02.27 08:48:13 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/95_YAAHM.pm line 3770.
2021.02.27 08:48:13 1: eval: {YAAHM_Shorttable("YAAutoHM")}
2021.02.27 08:48:13 1: stacktrace:
2021.02.27 08:48:13 1: main::__ANON__ called by ./FHEM/95_YAAHM.pm (3770)
2021.02.27 08:48:13 1: main::YAAHM_toptable called by ./FHEM/95_YAAHM.pm (3835)
2021.02.27 08:48:13 1: main::YAAHM_Shorttable called by (eval 6212) (1)
2021.02.27 08:48:13 1: (eval) called by fhem.pl (1154)
2021.02.27 08:48:13 1: main::AnalyzePerlCommand called by ./FHEM/98_weblink.pm (106)
2021.02.27 08:48:13 1: main::weblink_FwFn called by ./FHEM/01_FHEMWEB.pm (2062)
2021.02.27 08:48:13 1: main::FW_showRoom called by ./FHEM/01_FHEMWEB.pm (1176)
2021.02.27 08:48:13 1: main::FW_answerCall called by ./FHEM/01_FHEMWEB.pm (596)
2021.02.27 08:48:13 1: main::FW_Read called by fhem.pl (3830)
2021.02.27 08:48:13 1: main::CallFn called by fhem.pl (767)
Vielen Dank
Grüße Newbee
Das ist ein Fehler, der außerhalb von YAAHM liegt. Aus der Definition von Shorttable:
# YAAHM_Shorttable - returns complete HTML code for inclusion into any room page
# (action and overview fields)
#
# Parameter name = name of the YAAHM definition
Ich halte es für unwahrscheinlich, dass jemand seine YAAHM-Installation "YAAutoHM" nennt - ich vermute vielmehr, dass da jemand mit einem Ersetzungsbefehl den htlmCode-Aufruf von Shorttable im entsprechenden weblink zu
Zitat{YAAHM_Shorttable("YAAutoHM")}
umgeschossen hat.
Dazu sollte man - wie in Zeile 707 des Moduls erkennbar ist - mal das Device für diesen Weblink anschauhen:
#-- this is the short YAAHM entry
FW_fC("defmod ".$name."_shortlink weblink htmlCode {YAAHM_Shorttable(\"".$name."\")}");
Log3 $hash, 3, "[".$name. " V".$yaahmversion."]"." Weblink ".$name."_shortlink created";
Also, was steht im FHEM-Device "<YAAHM-Devicename>_shortlink", und zwar als Internal LINK?
LG
pah
Guten Abend Herr Prof Henning,
ich habe mir vor einigen Wochen das Buch "Smart Home mit FHEM" von Ihnen gekauft und versuche gerade das Modul YAAHM anzuwenden, jedoch werden bei mir fogende events nicht ausgeführt: aftermidnight/beforesunrise/aftersunrise/beforesunset/aftersunset/beforemidnight <- also jene, die mittels Offset berechnet werden.
Nachdem ich das device YYY erstellt habe, habe ich den timeHelper auf HouseTimeHelper gesetzt. Danach habe ich den Button Start Tages-Timer angeklickt, worauf dann YYY.dtimer.IF erstellt worden ist. In dessen readings ist mir dann aufgefallen, dass einige timer nicht richtig konfiguriert werden, z.B.:
timer_01_c01 29.11.2021 00:01:00 2021-11-28 19:26:21
timer_02_c01 error: Wrong timespec : either HH:MM:SS or {perlcode} 2021-11-28 19:26:21
timer_03_c02 29.11.2021 06:19:00 2021-11-28 19:26:21
timer_04_c02 error: Wrong timespec : either HH:MM:SS or {perlcode} 2021-11-28 19:26:21
Manche events werden zum richtigen Zeitpunkt ausgeführt (z.B. [YAAHM_time] executing {HouseTimeHelper('evening')}), andere wiederum nicht (z.B. aftersunset).
Ich gehe davon aus, dass dies mit den nicht angelegten Timer zusammenhängt, aber woran liegt das und wie kann ich das beheben?
Vielen Dank!
Mit freundlichen Grüßen
Walter
Das kann eigentlich nur daran liegen, dass die Offsets nicht richtig eingetragen wurden. Der entsprechende Block auf der YAAHM-Seite muss so aussehen, wie auf der Anlage.
Im Device YYY wiederum gibt es dann entsprechende Readings mit den berechneten Endzeiten:
s_aftermidnight 00:05 2021-11-29 00:00:33
s_afternoon 14:30 2021-11-29 00:00:33
s_aftersunrise 08:56 2021-11-29 00:00:33
s_aftersunset 17:32 2021-11-29 00:00:33
s_beforemidnight 23:55 2021-11-29 00:00:33
s_beforesunrise 06:56 2021-11-29 00:00:33
s_beforesunset 15:32 2021-11-29 00:00:33
s_evening 18:30 2021-11-29 00:00:33
s_morning 7:30 2021-11-29 00:00:33
s_night 22:00 2021-11-29 00:00:33
s_noon 13:30 2021-11-29 00:00:33
s_sunrise 07:56 2021-11-29 00:00:33
s_sunset 16:32 2021-11-29 00:00:33
LG
pah
Hallo,
jetzt funktioniert es.
Ich habe die Offsets nichts angepasst, da sie bei mir genauso wie im Buch bereits standardmäßig eingetragen waren und der entsprechende Block auf der YAAHM-Seite genauso wie in Ihrer vorherigen Anlage bereits angezeigt wurden.
Ich habe jetzt einfach das Offset von aftermidnight von +00:01 auf +00:05 geändert und dann auf Start Tages-Timer geklickt. Danach sind alle Timer richtig angelegt worden, auch jene, wo ich das Offset nicht geändert habe.
Vielen Dank für die Hilfe und für dieses Modul!
lG
Walter
Hallo,
muss mich leider korrigieren... es funktioniert doch (noch) nicht.
Im logfile bekomme ich für den Zeitpunkt beforesunrise folgende Einträge und die Befehle in der HouseTimeHelper werden nicht ausgeführt
021.12.05 06:27:00 1: PERL WARNING: Use of uninitialized value $mval in substitution (s///) at ./FHEM/95_YAAHM.pm line 1222.
2021.12.05 06:27:00 3: eval: {YAAHM_time('YYY','beforesunrise',1)}
2021.12.05 06:27:00 1: PERL WARNING: Use of uninitialized value $nval in substitution (s///) at ./FHEM/95_YAAHM.pm line 1223.
2021.12.05 06:27:00 3: eval: {YAAHM_time('YYY','beforesunrise',1)}
2021.12.05 06:27:00 1: PERL WARNING: Use of uninitialized value $tval in substitution (s///) at ./FHEM/95_YAAHM.pm line 1224.
2021.12.05 06:27:00 3: eval: {YAAHM_time('YYY','beforesunrise',1)}
2021.12.05 06:27:00 1: PERL WARNING: Use of uninitialized value $mval in numeric ge (>=) at ./FHEM/95_YAAHM.pm line 1227.
2021.12.05 06:27:00 3: eval: {YAAHM_time('YYY','beforesunrise',1)}
2021.12.05 06:27:00 1: PERL WARNING: Use of uninitialized value $nval in numeric gt (>) at ./FHEM/95_YAAHM.pm line 1227.
2021.12.05 06:27:00 3: eval: {YAAHM_time('YYY','beforesunrise',1)}
2021.12.05 06:27:00 1: PERL WARNING: Use of uninitialized value $xval in concatenation (.) or string at ./FHEM/95_YAAHM.pm line 1350.
2021.12.05 06:27:00 3: eval: {YAAHM_time('YYY','beforesunrise',1)}
2021.12.05 06:27:00 1: PERL WARNING: Use of uninitialized value $xval in concatenation (.) or string at ./FHEM/95_YAAHM.pm line 1352.
2021.12.05 06:27:00 3: eval: {YAAHM_time('YYY','beforesunrise',1)}
2021.12.05 06:27:00 1: [YAAHM_time] executing
2021.12.05 06:27:00 1: PERL WARNING: Use of uninitialized value $cmd in pattern match (m//) at fhem.pl line 1093.
2021.12.05 06:27:00 3: eval: {YAAHM_time('YYY','beforesunrise',1)}
Das bekomme ich bei list YYY.dtimer.IF
Internals:
DEF ([[YYY:s_aftermidnight]])
({YAAHM_time('YYY','aftermidnight',1)})
DOELSEIF([[YYY:s_beforesunrise]])
({YAAHM_time('YYY','beforesunrise',1)})
DOELSEIF([[YYY:s_sunrise]])
({YAAHM_time('YYY','sunrise',1)})
DOELSEIF([[YYY:s_morning]])
({YAAHM_time('YYY','morning',1)})
DOELSEIF([[YYY:s_aftersunrise]])
({YAAHM_time('YYY','aftersunrise',1)})
DOELSEIF([[YYY:s_noon]])
({YAAHM_time('YYY','noon',1)})
DOELSEIF([[YYY:s_afternoon]])
({YAAHM_time('YYY','afternoon',1)})
DOELSEIF([[YYY:s_beforesunset]])
({YAAHM_time('YYY','beforesunset',1)})
DOELSEIF([[YYY:s_sunset]])
({YAAHM_time('YYY','sunset',1)})
DOELSEIF([[YYY:s_aftersunset]])
({YAAHM_time('YYY','aftersunset',1)})
DOELSEIF([[YYY:s_evening]])
({YAAHM_time('YYY','evening',1)})
DOELSEIF([[YYY:s_night]])
({YAAHM_time('YYY','night',1)})
DOELSEIF([[YYY:s_beforemidnight]])
({YAAHM_time('YYY','beforemidnight',1)})
FUUID 61a3c9cd-f33f-97b4-1acd-19f1d971b7af34ae
MODEL FHEM
NAME YYY.dtimer.IF
NOTIFYDEV global,YYY
NR 972
NTFY_ORDER 50-YYY.dtimer.IF
STATE cmd_4
TYPE DOIF
VERSION 24905 2021-09-01 18:35:54
READINGS:
2021-12-06 08:00:00 cmd 4
2021-12-06 08:00:00 cmd_event timer_4
2021-12-06 08:00:00 cmd_nr 4
2021-11-29 13:09:26 mode enabled
2021-12-06 08:00:00 state cmd_4
2021-12-06 03:01:57 timer_01_c01 07.12.2021 00:05:00
2021-12-06 06:28:00 timer_02_c02 07.12.2021 06:28:00
2021-12-06 07:28:00 timer_03_c03 07.12.2021 07:28:00
2021-12-06 08:00:00 timer_04_c04 07.12.2021 08:00:00
2021-12-06 03:01:57 timer_05_c05 06.12.2021 08:28:00
2021-12-06 03:01:57 timer_06_c06 06.12.2021 13:00:00
2021-12-06 03:01:57 timer_07_c07 06.12.2021 14:00:00
2021-12-06 03:01:57 timer_08_c08 06.12.2021 15:04:00
2021-12-06 03:01:57 timer_09_c09 06.12.2021 16:04:00
2021-12-06 03:01:57 timer_10_c10 06.12.2021 17:04:00
2021-12-06 03:01:57 timer_11_c11 06.12.2021 18:30:00
2021-12-06 03:01:57 timer_12_c12 06.12.2021 22:00:00
2021-12-06 03:01:57 timer_13_c13 06.12.2021 23:55:00
Regex:
accu:
collect:
itimer:
YYY:
itimer:
s_aftermidnight ^YYY$:^s_aftermidnight:
s_afternoon ^YYY$:^s_afternoon:
s_aftersunrise ^YYY$:^s_aftersunrise:
s_aftersunset ^YYY$:^s_aftersunset:
s_beforemidnight ^YYY$:^s_beforemidnight:
s_beforesunrise ^YYY$:^s_beforesunrise:
s_beforesunset ^YYY$:^s_beforesunset:
s_evening ^YYY$:^s_evening:
s_morning ^YYY$:^s_morning:
s_night ^YYY$:^s_night:
s_noon ^YYY$:^s_noon:
s_sunrise ^YYY$:^s_sunrise:
s_sunset ^YYY$:^s_sunset:
attr:
cmdState:
waitdel:
condition:
0 ::DOIF_time_once($hash,0,$wday)
1 ::DOIF_time_once($hash,1,$wday)
10 ::DOIF_time_once($hash,10,$wday)
11 ::DOIF_time_once($hash,11,$wday)
12 ::DOIF_time_once($hash,12,$wday)
2 ::DOIF_time_once($hash,2,$wday)
3 ::DOIF_time_once($hash,3,$wday)
4 ::DOIF_time_once($hash,4,$wday)
5 ::DOIF_time_once($hash,5,$wday)
6 ::DOIF_time_once($hash,6,$wday)
7 ::DOIF_time_once($hash,7,$wday)
8 ::DOIF_time_once($hash,8,$wday)
9 ::DOIF_time_once($hash,9,$wday)
days:
do:
0:
0 {YAAHM_time('YYY','aftermidnight',1)}
1:
0 {YAAHM_time('YYY','beforesunrise',1)}
10:
0 {YAAHM_time('YYY','evening',1)}
11:
0 {YAAHM_time('YYY','night',1)}
12:
0 {YAAHM_time('YYY','beforemidnight',1)}
13:
2:
0 {YAAHM_time('YYY','sunrise',1)}
3:
0 {YAAHM_time('YYY','morning',1)}
4:
0 {YAAHM_time('YYY','aftersunrise',1)}
5:
0 {YAAHM_time('YYY','noon',1)}
6:
0 {YAAHM_time('YYY','afternoon',1)}
7:
0 {YAAHM_time('YYY','beforesunset',1)}
8:
0 {YAAHM_time('YYY','sunset',1)}
9:
0 {YAAHM_time('YYY','aftersunset',1)}
helper:
DEVFILTER ^global$|^YYY$
NOTIFYDEV global|YYY
event timer_4
globalinit 1
last_timer 13
sleeptimer -1
timerdev
timerevent timer_4
triggerDev
timerevents:
timer_4
timereventsState:
timer_4
triggerEvents:
timer_4
triggerEventsState:
timer_4
interval:
intervalfunc:
intervaltimer:
localtime:
0 1638831900
1 1638854880
10 1638811800
11 1638824400
12 1638831300
2 1638858480
3 1638860400
4 1638775680
5 1638792000
6 1638795600
7 1638799440
8 1638803040
9 1638806640
perlblock:
realtime:
0 00:05:00
1 06:28:00
10 18:30:00
11 22:00:00
12 23:55:00
2 07:28:00
3 08:00:00
4 08:28:00
5 13:00:00
6 14:00:00
7 15:04:00
8 16:04:00
9 17:04:00
time:
0 [YYY:s_aftermidnight]
1 [YYY:s_beforesunrise]
10 [YYY:s_evening]
11 [YYY:s_night]
12 [YYY:s_beforemidnight]
2 [YYY:s_sunrise]
3 [YYY:s_morning]
4 [YYY:s_aftersunrise]
5 [YYY:s_noon]
6 [YYY:s_afternoon]
7 [YYY:s_beforesunset]
8 [YYY:s_sunset]
9 [YYY:s_aftersunset]
timeCond:
0 0
1 1
10 10
11 11
12 12
2 2
3 3
4 4
5 5
6 6
7 7
8 8
9 9
timer:
0 0
1 0
10 0
11 0
12 0
2 0
3 0
4 0
5 0
6 0
7 0
8 0
9 0
timers:
0 0
1 1
10 10
11 11
12 12
2 2
3 3
4 4
5 5
6 6
7 7
8 8
9 9
triggertime:
1638775680:
localtime 1638775680
hash:
1638792000:
localtime 1638792000
hash:
1638795600:
localtime 1638795600
hash:
1638799440:
localtime 1638799440
hash:
1638803040:
localtime 1638803040
hash:
1638806640:
localtime 1638806640
hash:
1638811800:
localtime 1638811800
hash:
1638824400:
localtime 1638824400
hash:
1638831300:
localtime 1638831300
hash:
1638831900:
localtime 1638831900
hash:
1638854880:
localtime 1638854880
hash:
1638858480:
localtime 1638858480
hash:
1638860400:
localtime 1638860400
hash:
uiState:
uiTable:
Attributes:
do always
room Unsorted
Finden Sie den Fehler?
lG
Walter
Guten Tag,
ich hab des öfteren versucht, diesen Fehler zu finden, aber ich bin kläglich gescheitert.
2024.04.11 16:27:59 1: [YAAHM_updater] on device called for this day
2024.04.11 16:28:00 1: [YAAHM] Offset before sunrise not in format hh:mm, using 00:00
2024.04.11 16:28:00 1: [YAAHM] Offset after sunrise not in format hh:mm, using 00:00
2024.04.11 16:28:00 1: [YAAHM] Offset before sunset not in format hh:mm, using 00:00
2024.04.11 16:28:00 1: [YAAHM] Offset after sunset not in format hh:mm, using 00:00
2024.04.11 16:28:00 1: [YAAHM] Offset before midnight not in format hh:mm, using 00:05
2024.04.11 16:28:00 1: [YAAHM] Offset after midnight not in format hh:mm, using 00:05
Können Sie mir einen Hinweis geben woran das liegen kann?
Dankeschön!
lG
Steht doch da: Die Offsets müssen im Format hh:mm angegeben werden. Und der Default-Wert steht direkt dahinter.
Wenn man diese auf der "Profile"-Seite eingetragen hat, einfach "Start Tagestimer" anklicken.
LG
pah