Ich würde gerne eine Markise runter lassen, aber nur wenn jemand zuhause ist und nur wenn der Wind unter 3 ist und es muss Markise Eins offen sein und es darf nicht Regnen.
Bisher habe ich folgendes was aber leider nicht funktioniert, und beim windSpeed bekomme ich im DOIF die Temperatur angezeigt >:(
define Schattenplus_auf DOIF ([16:00-20:00] and [tahoma_1026532] eq "open" and [wetter_eigheim:windSpeed] < 3 and [Alle_Bewohner] eq "present" and ([HM_34C809_Rain:"dry"]) ( set Markise closed ) DOELSE (set Markise open)
Dir müsste ein Klammerfehler angezeigt werden.
Deine Bedingung wird nur in dem Moment wahr, wenn der Regensensor ein Ereignis mit "dry" sendet, warum nutzt Du dort die Eventabfrage?
ZitatDir müsste ein Klammerfehler angezeigt werden
Ja klar, da fehlt eine Klammer.
ZitatDeine Bedingung wird nur in dem Moment wahr, wenn der Regensensor ein Ereignis mit "dry" sendet
Nein, jede [], die ein Ereignis sendet wird das DOIF triggern. Dann werden die andere bewertet.
Z.B. [wetter_eigheim:windSpeed] wird < 3
oder [tahoma_1026532] wechselt auf "open"
oder 15:59 wird 16:00
Man muss überlegen, ob man wirklich auf allen Ereignisse triggern wird. Wenn einige das DOIF nicht triggern sollten, dann [?condition] statt [condition]
Ich habe schon zig mal umgeschrieben aber leider immer keine Reaktion, habe tatsächlich eine Version erwischt die mir einen Klammerfehler anzeigt. Das ist der aktuelle Stand.
DEF
([16:00-20:00] and [tahoma_1026532] eq "open" and [wetter_eigheim:windSpeed] < 3 and [Alle_Bewohner] eq "present" and [HM_34C809_Rain:"dry"]) ( set Markise closed ) DOELSE (set Markise open)
Es sollen auf jeden Fall alle Bedingungen erfüllt sein damit die Markise ausfährt, aber evtl. wenn sie ausgefahren ist und wir das Haus verlassen soll sie draußen bleiben, jedoch wenn der Wind Stärker ist oder es zu Regnen beginnt muss sie rein.
Unter Probably associated with steht wie oben schon geschrieben, wetter_eigheim 32,5 HTTPMOD
Das ist die aktuelle Temperatur und nicht der Windspeed, anscheinend habe ich mehr Fehler wie mir lieb ist.
Wenn ich bei allen Devices ein ? setzte und nur bei [tahoma_1026532] eq "open" nicht wird nur das Tahoma Device getriggert aber alle anderen Bedingungen müssen erfüllt sein damit die Markise raus fährt, verstehe ich das richtig?
Du musst bedenken, dass
[HM_34C809_Rain:"dry"]
nur zum Zeitpunkt des Triggers wahr ist und sonst nicht. Wenn du nicht nur den Trigger abfragen willst, sondern auch den Zustand, dann musst du das so angeben:
[HM_34C809_Rain] eq "dry"
Zitatnur zum Zeitpunkt des Triggers wahr ist und sonst nicht.
Aaah ! Das meinte Ellert! Jetzt habe ich verstanden, was er meinte! Hatte natürlich recht, sorry.
ZitatWenn ich bei allen Devices ein ? setzte und nur bei [tahoma_1026532] eq "open" nicht wird nur das Tahoma Device getriggert aber alle anderen Bedingungen müssen erfüllt sein damit die Markise raus fährt, verstehe ich das richtig?
Ja, richtig, es wird dann nur von tahoma getriggert, und alle anderen müssen erfüllt sein (angenommen die Anmerkung von Damian / Ellert).
Zitat von: elmer am 29 Mai 2017, 18:59:30
Ich habe schon zig mal umgeschrieben aber leider immer keine Reaktion, habe tatsächlich eine Version erwischt die mir einen Klammerfehler anzeigt. Das ist der aktuelle Stand.
DEF
([16:00-20:00] and [tahoma_1026532] eq "open" and [wetter_eigheim:windSpeed] < 3 and [Alle_Bewohner] eq "present" and [HM_34C809_Rain:"dry"]) ( set Markise closed ) DOELSE (set Markise open)
Es sollen auf jeden Fall alle Bedingungen erfüllt sein damit die Markise ausfährt, aber evtl. wenn sie ausgefahren ist und wir das Haus verlassen soll sie draußen bleiben, jedoch wenn der Wind Stärker ist oder es zu Regnen beginnt muss sie rein.
Unter Probably associated with steht wie oben schon geschrieben, wetter_eigheim 32,5 HTTPMOD
Das ist die aktuelle Temperatur und nicht der Windspeed, anscheinend habe ich mehr Fehler wie mir lieb ist.
Wenn ich bei allen Devices ein ? setzte und nur bei [tahoma_1026532] eq "open" nicht wird nur das Tahoma Device getriggert aber alle anderen Bedingungen müssen erfüllt sein damit die Markise raus fährt, verstehe ich das richtig?
ZitatUnter Probably associated with ...
wird das Internal STATE angezeigt, das hat mit dem Reading windSpeed nichts zutun.
ZitatWenn ich bei allen Devices ein ? setzte und nur bei [tahoma_1026532] eq "open" nicht wird nur das Tahoma Device getriggert aber alle anderen Bedingungen müssen erfüllt sein damit die Markise raus fährt, verstehe ich das richtig?
Ja.
([16:00-20:00] and [tahoma_1026532] eq "open" and [?wetter_eigheim:windSpeed] < 3 and [?Alle_Bewohner] eq "present" and [?HM_34C809_Rain] eq "dry") (set Markise auf)
So sieht das Ganze erst mal ganz gut aus, ausgefahren ist sie auf jeden Fall.
Ich verwenden für den windSpeed einen HTTPMOD, wie stabil läuft so etwas, kann man sich darauf verlassen oder muss man mit Aussetzern rechnen.
Ich habe einen Somfy io Windsensor der lässt sich aber nicht in Fhem einbinden, gibt es eine zuverlässige Alternative die mit Fhem geht?
ZitatIch verwenden für den windSpeed einen HTTPMOD, wie stabil läuft so etwas, kann man sich darauf verlassen oder muss man mit Aussetzern rechnen.
Läuft so lange die Webseite erreichbar ist ;)
Zu früh gefreut, wenn ich eine Zeitspanne von 16:00-20:00 angebe und um 16:00 alle Bedingungen wahr sind fährt die Markise raus. Wenn ich aber um 16:00 absent bin und erst um 16:01 present bleibt das DOIF auf cmd2 stehen und die Markise bleibt geschlossen.
([15:45-20:00] and [tahoma_1026532] eq "open" and [?wetter_eigheim:windSpeed] < 8 and [?Alle_Bewohner] eq "present" and [?HM_34C809_Rain] eq "dry") (set Markise auf) DOELSE (set Markise off)
Das Fragezeichen bei alle Bewohner raus nehmen.
Mit 20 Minuten Verspätung ist sie nun doch raus, wieso das auf einmal?
Genau um 16:04:41 hat tahoma_1026532 RSSILevelState aktualisiert laut Readings, genau in diesem Moment ist die Markise raus, was hat das für einen Zusammenhang?
Kannst Du ein list vom DOIF geben?
Zitat von: elmer am 30 Mai 2017, 16:06:26
Mit 20 Minuten Verspätung ist sie nun doch raus, wieso das auf einmal?
Genau um 16:04:41 hat tahoma_1026532 RSSILevelState aktualisiert laut Readings, genau in diesem Moment ist die Markise raus, was hat das für einen Zusammenhang?
Ganz einfach!
Tahoma ist Dein trigger. Wenn also ein event eintrifft und alle Bedingungen erfuellt sind , dann wird das entsprechende cmd ausgefuehrt!
Gruss Christoph
Zitat von: elmer am 30 Mai 2017, 16:06:26
Mit 20 Minuten Verspätung ist sie nun doch raus, wieso das auf einmal?
Genau um 16:04:41 hat tahoma_1026532 RSSILevelState aktualisiert laut Readings, genau in diesem Moment ist die Markise raus, was hat das für einen Zusammenhang?
Aus der Commandref:
ZitatDas Modul wird getriggert, sobald das angegebene Device hier "remotecontrol" ein Event erzeugt.
Ok, also das ausführende Decice hat ein Event gesendet und deshalb ist die Markise raus. Sobald also nach 16:00 alle Bedingungen wahr sind wartet DOIF auf das nächste Event vom Gerät das Getriggert wird und schaltet auf cmd1.
Wird dann bei jedem Event state mit gesendet weil die Markise raus ist, wenn ja verhalten sich alle Geräte so, das ist schwer zu verstehen für einen Neuling wie mich ;D
Welche Events zusammen gesendet werden, siehst Du im Eventmonitor, siehe https://wiki.fhem.de/wiki/Event
Wenn Du nur auf bestimmte Readings triggern möchtest, schau Dir mal das Attribut "checkReadingEvent" an.
Ich habe gerade gesehen das mein Log voll läuft mit dieser Fehlermeldung, kann jemand damit etwas anfangen.
2017.05.30 20:02:43 1: Error: >Schattenplus_auto_open< has no TYPE, but following keys: >READINGS<
2017.05.30 20:02:43 1: Error: >Schattenplus_automatsch_auf< has no TYPE, but following keys: >READINGS<
Hier noch ein list vom DOIF:
Internals:
CFGFN
DEF ([15:45-20:00] and [tahoma_1026532] eq "open" and [?wetter_eigheim:windSpeed] < 3 and [?Alle_Bewohner] eq "present" and [?HM_34C809_Rain] eq "dry") (set Markise 70) DOELSE (set Markise off)
NAME Schattenplus_auf
NR 1870
NTFY_ORDER 50-Schattenplus_auf
STATE cmd_2
TYPE DOIF
Readings:
2017-05-31 20:54:21 Device tahoma_1026532
2017-05-31 20:00:00 cmd 2
2017-05-31 20:00:00 cmd_event timer_2
2017-05-31 20:00:00 cmd_nr 2
2017-05-31 20:54:21 e_tahoma_1026532_STATE closed
2017-05-31 20:00:00 state cmd_2
2017-05-31 20:00:00 timer_01_c01 01.06.2017 15:45:00
2017-05-31 20:00:00 timer_02_c01 01.06.2017 20:00:00
Condition:
0 DOIF_time($hash,0,1,$wday,$hms) and InternalDoIf($hash,'tahoma_1026532','STATE') eq "open" and ReadingValDoIf($hash,'wetter_eigheim','windSpeed') < 3 and InternalDoIf($hash,'Alle_Bewohner','STATE') eq "present" and InternalDoIf($hash,'HM_34C809_Rain','STATE') eq "dry"
Days:
Devices:
0 tahoma_1026532
all tahoma_1026532
Do:
0:
0 set Markise 70
1:
0 set Markise off
Helper:
event RSSILevelState: 66.0
globalinit 1
last_timer 2
sleeptimer -1
timerdev tahoma_1026532
timerevent RSSILevelState: 66.0
triggerDev tahoma_1026532
timerevents:
RSSILevelState: 66.0
timereventsState:
RSSILevelState: 66.0
triggerEvents:
RSSILevelState: 66.0
triggerEventsState:
RSSILevelState: 66.0
Internals:
0 tahoma_1026532:STATE Alle_Bewohner:STATE HM_34C809_Rain:STATE
all tahoma_1026532:STATE Alle_Bewohner:STATE HM_34C809_Rain:STATE
Interval:
0 -1
1 0
Itimer:
Localtime:
0 1496324700
1 1496340000
Readings:
Realtime:
0 15:45:00
1 20:00:00
Regexp:
0:
All:
State:
State:
Time:
0 15:45:00
1 20:00:00
Timecond:
0 0
1 0
Timer:
0 0
1 0
Timers:
0 0 1
Trigger:
Triggertime:
1496324700:
localtime 1496324700
Hash:
1496340000:
localtime 1496340000
Hash:
Attributes:
Hier wäre eigentlich ein list von Schattenplus_auto_open und von Schattenplus_automatsch_auf interessanter :)
So wie das Ergebnis vom folgenden Befehl:
{ join(",", grep { !$defs{$_}{TYPE} } keys %defs) }
Ich bin gerade unterwegs, aber das ist ja das komische Schattenplus_auto_open und von Schattenplus_automatsch_auf gibt es gar nicht. Ich glaube das waren meinen erste Versuche das DOIF zu erstellen aber da ich bei beiden Veruchen einen Fegler hatte, hat es mit einer Fehlermeldung abgebrochen.
Ist es möglich das bei Fhem temporär noch etwas von diesen Versuchen vorhanden ist und bei einem Neustart von Fhem verschwindet?
Nein
Du hast ja schon gespeichert! Jetzt kommen wir aber ganz an den Anfang von fhem: Schau mal in unsorted, da findest du diese DOIFs wieder!
Gruss Christoph
Nein, die sind nicht vorhanden, auch nicht mit list.
Und mit { join(",", grep { !$defs{$_}{TYPE} } keys %defs) } ?
wie hast du denn deine alten DOIF's gelöscht?
fhem.cfg bearbeitet?
WebInterface??
Zitat von: nils_ am 01 Juni 2017, 09:24:05
wie hast du denn deine alten DOIF's gelöscht?
fhem.cfg bearbeitet?
WebInterface??
Ein Schelm, der boeses dabei denkt!
Gruss Christoph
Zitat von: amenomade am 01 Juni 2017, 08:28:42
Und mit { join(",", grep { !$defs{$_}{TYPE} } keys %defs) } ?
Hie bekomme ich nur eine Fehlermeldung:
{ join(",", grep { 0defs{$_}{TYPE} } keys %defs) }
-bash: syntax error near unexpected token `",",'
Und gelöscht habe ich nichts, da wie gesagt bei 2 Versuchen das DOIF zu erstellen von fhem eine Fehlermeldung kam und das ganze abgebrochen wurde, deshalb kann es doch auch nicht sein das etwas vorhanden ist.
Hier noch die fhem Meldungen die beim erstellen vom DOIF gekommen sind:
Schattenplus_automatsch_auf DOIF: expected DOELSEIF or DOELSE: and ([wetter_eigheim:windSpeed] < 3) and ([HM_34C809_Rain:"dry"]) ( set Markise closed ) DOELSE (set Markise open) Schattenplus_auto_open DOIF: expected DOELSEIF or DOELSE: and ([wetter_eigheim:windSpeed] < 3) and ([HM_34C809_Rain:"dry"]) ( set Markise closed ) DOELSE (set Markise open)
Argument "100 %" isn't numeric in numeric lt (<) at (eval 33307) line 1.
Das du etwas anderes eingegeben hast als amenomade vorgeschlagen hat ist Dir aber aufgefallen?
Gruss
Was ist.......
Ok beim nochmaligen lesen wriss ich was du gemeint hast, man sollte wärend man Auto fährt nicht lesen ;D
Ok, eben noch mal nachgeschaut und es hat gepasst was ich eingegeben habe.
pi@raspberrypi:~ $ { join(",", grep { !$defs{$_}{TYPE} } keys %defs) }
{ join(",", grep { 0defs{$_}{TYPE} } keys %defs) }
-bash: syntax error near unexpected token `",",'
Ich habe heute früh zur Sicherheit doch mal einen Neustart gemacht und bisher sieht das Log sauber aus, mal sehen ob es nach 16 Uhr wieder zugemüllt wird.
2017.06.01 00:01:00 3: addLog return value: SCALAR(0x471c7c0)
2017.06.01 00:14:24 3: UWZ Unwetterzentrale: Run.964 Done fetching data
2017.06.01 01:14:24 3: UWZ Unwetterzentrale: Run.964 Done fetching data
2017.06.01 02:14:24 3: UWZ Unwetterzentrale: Run.964 Done fetching data
2017.06.01 02:55:33 3: tahoma1: request active
2017.06.01 02:55:35 3: tahoma1: request active
2017.06.01 02:55:37 3: tahoma1: request active
2017.06.01 03:00:05 3: tahoma1: request active
2017.06.01 03:00:07 3: tahoma1: request active
2017.06.01 03:14:24 3: UWZ Unwetterzentrale: Run.964 Done fetching data
2017.06.01 04:14:24 3: UWZ Unwetterzentrale: Run.964 Done fetching data
2017.06.01 05:14:24 3: UWZ Unwetterzentrale: Run.964 Done fetching data
2017.06.01 06:14:24 3: UWZ Unwetterzentrale: Run.964 Done fetching data
2017.06.01 07:14:24 3: UWZ Unwetterzentrale: Run.964 Done fetching data
2017.06.01 08:14:24 3: UWZ Unwetterzentrale: Run.964 Done fetching data
2017.06.01 09:14:24 3: UWZ Unwetterzentrale: Run.964 Done fetching data
2017.06.01 10:14:24 3: UWZ Unwetterzentrale: Run.964 Done fetching data
2017.06.01 11:14:24 3: UWZ Unwetterzentrale: Run.964 Done fetching data
2017.06.01 12:14:24 3: UWZ Unwetterzentrale: Run.964 Done fetching data
2017.06.01 13:14:24 3: UWZ Unwetterzentrale: Run.964 Done fetching data
Argument "100 %" isn't numeric in numeric lt (<) at (eval 92995) line 1.
Argument "100 %" isn't numeric in numeric lt (<) at (eval 93008) line 1.
2017.06.01 13:41:57 3: FBDECT set FBDECT_Fritzbox_22 on
2017.06.01 13:49:38 3: CUL_1: Unknown code YsAA49024A010000, help me!
2017.06.01 13:49:40 3: CUL_1: Unknown code YsAB1C024B010000, help me!
2017.06.01 14:14:24 3: UWZ Unwetterzentrale: Run.964 Done fetching data
2017.06.01 14:45:07 3: tahoma1: tahoma_dispatch json string is faulty
2017.06.01 14:45:09 3: tahoma1: tahoma_login
2017.06.01 14:45:09 2: tahoma1: login start
2017.06.01 14:45:09 2: tahoma1: login end, logged_in=1
2017.06.01 14:45:13 2: tahoma1: tahoma_autocreate begin
2017.06.01 14:45:13 2: tahoma1: tahoma_autocreate end, new=0
2017.06.01 14:45:13 3: tahoma1: tahoma_updateDevices
2017.06.01 14:45:13 3: tahoma1: updateDevices device=io://0803-1025-4201/3738050
2017.06.01 14:45:15 2: tahoma1: tahoma_autocreate begin
2017.06.01 14:45:15 2: tahoma1: tahoma_autocreate end, new=0
2017.06.01 14:45:15 3: tahoma1: tahoma_updateDevices
2017.06.01 14:45:15 3: tahoma1: updateDevices device=io://0803-1025-4201/3738050
2017.06.01 15:14:24 3: UWZ Unwetterzentrale: Run.964 Done fetching data
Jetzt ist es 19 Uhr und noch immer keine Einträge im Log zu sehen, der Neustart von Fhem hat anscheinend das Problem von alleine gelöst.