Hallo leute.
Muss mal was fragen. Kurz vorweg, bin aus der Zeit mit Basic und den Commodore Brotkasten gross geworden.
Dort konnte man Vergleiche mit Operanden (= < > <>) durchführen.
Im DOIF steht immer "eq" oder "ne" oder.......
Wäre es nicht "angenehmer" mit Operanden zu arbeiten.
Dies würde vielleicht auf dem Verständnis für DOIF helfen.
Ist nur so ne Idee.
Gruß
Sascha
Gesendet von meinem SM-T560 mit Tapatalk
Zitat von: sash.sc am 01 April 2016, 16:28:28
Hallo leute.
Muss mal was fragen. Kurz vorweg, bin aus der Zeit mit Basic und den Commodore Brotkasten gross geworden.
Dort konnte man Vergleiche mit Operanden (= < > <>) durchführen.
Im DOIF steht immer "eq" oder "ne" oder.......
Wäre es nicht "angenehmer" mit Operanden zu arbeiten.
Dies würde vielleicht auf dem Verständnis für DOIF helfen.
Ist nur so ne Idee.
Gruß
Sascha
Gesendet von meinem SM-T560 mit Tapatalk
Das DOIF-Modul hat selbst keine Ahnung von Operatoren. Alle Operatoren, die man in der Bedingung angibt sind Perl-Operatoren. Hier findest du alles, was du auch beim DOIF angeben kannst:
https://wiki.selfhtml.org/wiki/Perl/Operatoren
Hier ein Auszug:
ZitatRangstufe: ++ -- (Inkrementieren, Dekrementieren)
Rangstufe: ** (Potenzierung)
Rangstufe: ! ~ (logische und bitweise Negation)
Rangstufe: =~ !~ (Bindung an reguläre Ausdrücke)
Rangstufe: * / % x (Multiplikation, Division, Modulo-Operation, Zeichenkettenwiederholung)
Rangstufe: + - . (Addition, Subtraktion, Zeichenkettenaddition)
Rangstufe: << >> (Verschieben von Bits)
Rangstufe: < > <= >= lt gt le ge (Vergleich größer/kleiner)
Rangstufe: == != <=> eq ne cmp ~~ (Gleichheit/Ungleichheit)
Rangstufe: & (bitweises UND)
Rangstufe: | ^ (bitweises ODER - inklusiv/exklusiv)
Rangstufe: && (logisches UND)
Rangstufe: || (logisches ODER)
Rangstufe: .. (Bereichsdefinition in Listen)
Rangstufe: ?: (Entweder-Oder-Bedingung)
Rangstufe: = += -= ~*= /= %= &= ^= |= (Zuweisung)
Rangstufe: , => (Aneinanderreihung)
Rangstufe: not (logische Negation)
Rangstufe: and (logisches UND)
Rangstufe: or xor (logisches ODER (inklusiv/exklusiv)
Gruß
Damian
Danke für die Antwort. Hänge wohl noch zu sehr in der Basic welt fest!
Zitat von: sash.sc am 01 April 2016, 16:47:25
Danke für die Antwort. Hänge wohl noch zu sehr in der Basic welt fest!
Wie du der Liste entnehmen kannst, kannst du ebenfalls Operatoren ><=nehmen, aber nur bei Zahlen. Bei Zeichenketten hätte auch Basic mit > Probleme bekommen ;)
Ich habe auch mal mit Basic angefangen und ich kenne auch den Brotkasten (sogar den Vorgänger vom C64). Es lohnt sich aber mal in die Feature-Liste von Perl reinzuschauen - da hat sich in den letzten 30 Jahren etwas getan.
Gruß
Damian
Coole nummer, dass noch jemand den Brotkasten und seine Varianten (C16/116/plus 4/vc20/.....)kennt .
Im Basic ging das auch nur über Umwege (String umwandeln).
Werde mir die Liste mal bei Zeiten anschauen!
Nur weil es hierher passt:
Darf man gt auch in folgendem Fall verwenden, oder muss es > sein?
([speisekammerluefter:AM2301_Humidity] gt [Wetterstation:indoorHumidity])
Und gleich noch eine Frage hinterher:
Ist die folgende Abfrage aufgrund der Gänsefüßchen schlichtweg falsch?
([twilight:elevation:d1] <= "13.8")
Gruß Chris
Hallo Chris,
perldoc (https://perldoc.perl.org/perlop.html#Relational%20Operators)sagt dazu
ZitatBinary "<" returns true if the left argument is numerically less than the right argument.
Binary ">" returns true if the left argument is numerically greater than the right argument.
Binary "<=" returns true if the left argument is numerically less than or equal to the right argument.
Binary ">=" returns true if the left argument is numerically greater than or equal to the right argument.
Binary "lt" returns true if the left argument is stringwise less than the right argument.
Binary "gt" returns true if the left argument is stringwise greater than the right argument.
Binary "le" returns true if the left argument is stringwise less than or equal to the right argument.
Binary "ge" returns true if the left argument is stringwise greater than or equal to the right argument.
Wobei irgendwo auch stand, dass Perl versucht immer erst mal den Ausdruck zu "interpretieren" also falls es geht wird der String auch als Zahl behandelt. Achtung, das ist eventuell gefährliches Halbwissen ;D
Gruß Otto
Ah, ok. Jetzt wird mir einiges klarer.
Hab mir grad testweise so Mühe gegeben, die Funktion eines funktionierendes DOIFs zu stören.
Egal welche Kombination aus "mit Gänsefüßchen"/"ohne Gänsefüßchen" und "gt/>" ich gewählt habe, das DOIF hat immer funktioniert.
Kann man sagen, dass die "ausgeschriebene Schreibweise" (sprich gt, eq, lt,..) ausschließlich für Strings gilt, wenn es um Texte wie "open" usw. geht?
Angenommen folgendes Event wird erzeugt:
2019-03-05 14:15:21 HP1000 Wetterstation wind_speed: 22.7
Ist das dann ein String mit dem Inhalt 22.7?
Anders gefragt: Wann ist ein Event denn kein String?
Gruß Chris
Perldoc (https://perldoc.perl.org/perldata.html#Context)sagt dazu:
ZitatAll data in Perl is a scalar, an array of scalars, or a hash of scalars. A scalar may contain one single value in any of three different flavors: a number, a string, or a reference. In general, conversion from one form to another is transparent.
Um ein wenig Klarheit in die Sache zu bringen:
Es ist ziemlich egal, ob man Zahlen in Anführungszeichen angibt oder nicht, es kommt auf den Vergleichsoperator an.
Stringvergleiche mit lt, gt, le, ge, eq, ne vergleichen lexikografisch (wie im Telefonbuch), dh.
"09" lt "1" ist wahr, weil Null kleiner ist als eins (Stringvergleich wegen lt)
"09" < "1" ist nicht wahr, weil die Zahl neun nicht kleiner ist als 1, hier wird intern verglichen 9 < 1 (Zahlenvergleich wegen <)
Zahlenvergleiche sollten am besten ohne Anführungszeichen gemacht werden.
hallo,
darf ich mich hier mal mir rein werfen?
ich habe dieses doif
([+30] and [Pool:Luft]>40) (set FHEMBOT message Achtung Pool Heizung zu hoch [Pool:luft_corr]) der Wert von Pool:Luft ist 11.4
und bekomme diese meldung im DOIF und log
condition c01: Argument "" isn't numeric in numeric gt (>)
wo ist da mein fehler??
Du lässt zu, dass in [Pool:Luft] eine leere Zeichenkette ("") steht und das ist kein numerischer Wert. Da Du einen Vergleichsoperator für numerische Werte verwendest, erhältst Du eine Warnung. Das kannst Du abfangen mit ...[Pool:Luft] and [Pool:Luft]>40
Sorry, dass ich mich hier mit einem anderen, aber vielleicht ähnlichen Problem einmische.
Ich habe folgendes DOIF, dass Probleme macht:
([06:00|8])
([netatmo_M02_00_00_XX_XX_XX:temperature] <= 2.0 and [netatmo_M02_00_00_XX_XX_XX:humidity] >= 88)
(set Heizluefter_Auto on)
"netatmo_M02_00_00_XX_XX_XX:temperature" hat einen Wert von 3.3
Dies führt bei mir zu der Fehlermeldung: di_Heizluefter_Auto_ein: 3.3 <= 2.0 and 92 >= 88: Unknown command 3.3, try help.
Ich bin leider noch immer blutiger Anfänger. Weshalb wird der gelieferte Wert aus dem Reading offenbar als Befehl interpretiert?
Vielen Dank vorab für Eure Hilfe!
poste doch mal bitte ein komplettes list des DOIF im Fehlerstatus.
Für mich sieht das nach einem Klamemrproblem aus; du scheinst den Befehlsteil bereits in der ersten Zeile (nach dem ([06:00|8])) beendet zu haben. Versuche mal sowas:
(([06:00|8])
and ([netatmo_M02_00_00_XX_XX_XX:temperature] <= 2.0)
and ([netatmo_M02_00_00_XX_XX_XX:humidity] >= 88))
(set Heizluefter_Auto on)
Danke, yersinia!
Das Klammernproblem war's und im Nachhinein ist es auch logisch: Die Uhrzeit ist ja quasi eine weitere Bedingung, die mit "und" verknüpft werden muss.
Vielen Dank für die schnelle Hilfe!
Moinsen,
ich habe grad auch ein kleines Problem mit der Ausführung... und ich klemme fest...
mein DOIF
([11:00] and [Wetter_2:fc0_uv] >= 6 and [LAD7:ambientTemperature] >= 22) (set Rollladen_.*_S$ zu) (set Meine_TGBot message "UV-Werte und Temperatur übersteigen Grenzwerte. Ich schließe die Jalousien im Süden. UV=[Wetter_2:fc0_uv], TEMP=[LAD7:ambientTemperature]") DOELSEIF
([15:00] and ([Wetter_2:fc0_uv] >= 6 or [LAD7:ambientTemperature] >= 26)) (set Rollladen_.*_S$ zu) (set Rollladen_.*_W$ zu)(set Meine_TGBot message "UV-Werte und Temperatur übersteigen Grenzwerte. Ich schließe die Jalousien im Süden und Westen. UV=[Wetter_2:fc0_uv], TEMP=[LAD7:ambientTemperature]")
Was will ich...
1. um 11 Uhr wird überprüft ob der UV Wert >= 6 ist UND die Aussentemperatur >= 22, wenn ja... Rollanden zu <= das funktioniert alle Bedingungen müssen wahr sein.
2. um 15 Uhr wird überprüft ob der UV Wert >= 6 ist ODER die Aussentemperatur >= 26, wenn ja... Rollanden zu <= das funktioniert nicht
bei 2 wird doch erst überprüft, ob die ODER Bedingung wahr ist... entweder UV Wert oder Aussentemp, wenn eins in der Klammer wahr, dann wahr... UND dann noch die Uhrzeit...
Aber heute hatten wir UV von 7 um 15 Uhr und nix ist passiert...
Was ist falsch???
VG
Ich bin mir nicht sicher aber ich glaube das und muss hinten stehen oder mit Klammern muss gestaffelt werden was zusammen gehört.
([Wetter_2:fc0_uv] >= 6 or [LAD7:ambientTemperature] >= 26 and ([15:00]))
Versuch es Mal so
(Bedingung 1) and (Bedingung 2) or (Bedingung 3)
https://perldoc.perl.org/perlop.html#Operator-Precedence-and-Associativity
Was Du willst ist (Bedingung 1) and ((Bedingung 2) or (Bedingung 3)) ?
Gruß Otto
Ahh okay so war es, wußte doch das man es mit den Klammern definiert!
Zitat von: Otto123 am 23 Juli 2020, 21:07:05
Was Du willst ist (Bedingung 1) and ((Bedingung 2) or (Bedingung 3)) ?
Gruß Otto
Hi Otto, ja genau... ich habe schon ein wenig in den FHEM https://wiki.fhem.de/wiki/DOIF/Operatorenrangfolge (https://wiki.fhem.de/wiki/DOIF/Operatorenrangfolge) Seiten gelesen, da steht ja auch welche Reihenfolge gilt...
AND vor OR, () vor AND, || vor AND ... usw...
Daher sollte bei mir doch alles richtig sein...
([15:00] and ([Wetter_2:fc0_uv] >= 6 or [LAD7:ambientTemperature] >= 26))Die Klammern werden zurerst überprüft... also das or und dann das and mit der Zeit...
VG
René
Hi Otto, danke das du mir zustimmst... aber wie im Eingangspost schon geschrieben, es funktioniert nicht...
Ich hatte UV von 7 und Temp von 24 oder so... jedenfalls hätte meiner Meinung nach um 15 Uhr die Bedingung in den Klammern wahr sein müssen und das (set...) ausgeführt werden müssen...
War aber nicht so... ich mach mal das verbose an und schau mir das die Tage nochmal an...
VG
René
Hallo Rene,
in einem List würde man eventuell mehr sehen.
Außerdem musst Du aufpassen, Du hast eventuell redundante Abfragen in deinen Zweigen. Wenn einer zutrifft (wahr) dann werden die folgenden Zweige nicht mehr angeschaut.
Gruß Otto
Hi Otto,
Internals:
DEF ([11:00] and [Wetter_2:fc0_uv] >= 6 and [LAD7:ambientTemperature] >= 22) (set Rollladen_.*_S$ zu) (set Meine_TGBot message "UV-Werte und Temperatur übersteigen Grenzwerte. Ich schließe die Jalousien im Süden. UV=[Wetter_2:fc0_uv], TEMP=[LAD7:ambientTemperature]") DOELSEIF
([15:00] and ([Wetter_2:fc0_uv] >= 6 or [LAD7:ambientTemperature] >= 26)) (set Rollladen_.*_S$ zu) (set Rollladen_.*_W$ zu)(set Meine_TGBot message "UV-Werte und Temperatur übersteigen Grenzwerte. Ich schließe die Jalousien im Süden und Westen. UV=[Wetter_2:fc0_uv], TEMP=[LAD7:ambientTemperature]")
FUUID 5f0b4392-f33f-0804-e05d-d250d6f937145bfb
MODEL FHEM
NAME Alarm_UV_Temp
NOTIFYDEV LAD7,Wetter_2,global
NR 546
NTFY_ORDER 50-Alarm_UV_Temp
STATE cmd_2
TYPE DOIF
VERSION 22428 2020-07-18 20:32:08
READINGS:
2020-07-25 13:38:41 Device LAD7
2020-07-20 15:00:00 cmd 2.3
2020-07-20 15:00:00 cmd_event timer_2
2020-07-20 15:00:00 cmd_nr 2
2020-07-20 15:00:00 cmd_seqnr 3
2020-07-25 13:38:41 e_LAD7_ambientTemperature 23.5
2020-07-25 13:29:36 e_Wetter_2_fc0_uv 5
2020-07-19 15:22:04 mode enabled
2020-07-20 15:00:00 state cmd_2
2020-07-25 11:00:00 timer_01_c01 26.07.2020 11:00:00
2020-07-24 15:00:00 timer_02_c02 25.07.2020 15:00:00
Regex:
accu:
cond:
LAD7:
0:
ambientTemperature ^LAD7$:^ambientTemperature:
1:
ambientTemperature ^LAD7$:^ambientTemperature:
Wetter_2:
0:
fc0_uv ^Wetter_2$:^fc0_uv:
1:
fc0_uv ^Wetter_2$:^fc0_uv:
attr:
waitdel:
condition:
0 ::DOIF_time_once($hash,0,$wday) and ::ReadingValDoIf($hash,'Wetter_2','fc0_uv') >= 6 and ::ReadingValDoIf($hash,'LAD7','ambientTemperature') >= 22
1 ::DOIF_time_once($hash,1,$wday) and (::ReadingValDoIf($hash,'Wetter_2','fc0_uv') >= 6 or ::ReadingValDoIf($hash,'LAD7','ambientTemperature') >= 26)
days:
do:
0:
0 set Rollladen_.*_S$ zu
1 set Meine_TGBot message "UV-Werte und Temperatur übersteigen Grenzwerte. Ich schließe die Jalousien im Süden. UV=[Wetter_2:fc0_uv], TEMP=[LAD7:ambientTemperature]"
1:
0 set Rollladen_.*_S$ zu
1 set Rollladen_.*_W$ zu
2 set Meine_TGBot message "UV-Werte und Temperatur übersteigen Grenzwerte. Ich schließe die Jalousien im Süden und Westen. UV=[Wetter_2:fc0_uv], TEMP=[LAD7:ambientTemperature]"
2:
helper:
DEVFILTER ^global$|^Wetter_2$|^LAD7$
NOTIFYDEV global|Wetter_2|LAD7
event heatPumpElectricalPowerEstimated: 0,opStateHeatPump1: Wärmepumpe steht,opStateHeatPump2: seit 03:54:28,opStateHeatPump3: Keine Anforderung,opModeHotWater: Automatik,opStateHotWater: Temp. OK,opModeHeating: Automatik,opStateHeating: Heizgrenze (Soll 15.0°C),deviceTimeCalc: 2020-07-25 14:20:07,delayDeviceTimeCalc: -2485,durationFetchReadings: 0.020,ambientTemperature: 23.5,averageAmbientTemperature: 18.9,heatingLimit: on,thresholdHeatingLimit: 14.0,thresholdTemperatureSetBack: -20.0,heatingCurveEndPoint: 35.0,heatingCurveOffset: 21.0,hotWaterTemperature: 46.9,hotWaterTemperatureTarget: 46.5,flowTemperature: 29.1,returnTemperature: 26.8,returnTemperatureTarget: 15.0,returnTemperatureHyst: 4.0,returnTemperatureSetBack: 0.0,returnTemperatureExtern: 28.5,heatSourceIN: 21.9,heatSourceOUT: -50.0,heatSourceMotor: off,compressor1: off,hotGasTemperature: 32.4,mixer1FlowTemperature: 27.5,mixer1TargetTemperature: 20.0,counterHours2ndHeatSource1: 451.5,counterHoursHeatPump: 8698.9,counterHoursHeating: 5764.7,counterHoursHotWater: 2932.8,counterHeatQHeating: 21408.3,counterHeatQHotWater: 25632.5,counterHeatQTotal: 47040.8,heatingSystemCircPump: off,hotWaterCircPumpExtern: off,hotWaterSwitchingValve: off,solarPump: off,2ndHeatSource1: off,hotWaterCircPumpDeaerate: off,heatingSystemCircPumpDeaerate: off,bivalentLevel: 1,firmware: V2.79,typeHeatpump: LD7,typeSerial: 2309/11-282,solarCollectorTemperature: 25.1,solarBufferTemperature: 27.3,Wärmepumpe steht seit 03:54:28 - Keine Anforderung
globalinit 1
last_timer 2
sleeptimer -1
timerdev
timerevent timer_2
triggerDev LAD7
timerevents:
timer_2
timereventsState:
timer_2
triggerEvents:
heatPumpElectricalPowerEstimated: 0
opStateHeatPump1: Wärmepumpe steht
opStateHeatPump2: seit 03:54:28
opStateHeatPump3: Keine Anforderung
opModeHotWater: Automatik
opStateHotWater: Temp. OK
opModeHeating: Automatik
opStateHeating: Heizgrenze (Soll 15.0°C)
deviceTimeCalc: 2020-07-25 14:20:07
delayDeviceTimeCalc: -2485
durationFetchReadings: 0.020
ambientTemperature: 23.5
averageAmbientTemperature: 18.9
heatingLimit: on
thresholdHeatingLimit: 14.0
thresholdTemperatureSetBack: -20.0
heatingCurveEndPoint: 35.0
heatingCurveOffset: 21.0
hotWaterTemperature: 46.9
hotWaterTemperatureTarget: 46.5
flowTemperature: 29.1
returnTemperature: 26.8
returnTemperatureTarget: 15.0
returnTemperatureHyst: 4.0
returnTemperatureSetBack: 0.0
returnTemperatureExtern: 28.5
heatSourceIN: 21.9
heatSourceOUT: -50.0
heatSourceMotor: off
compressor1: off
hotGasTemperature: 32.4
mixer1FlowTemperature: 27.5
mixer1TargetTemperature: 20.0
counterHours2ndHeatSource1: 451.5
counterHoursHeatPump: 8698.9
counterHoursHeating: 5764.7
counterHoursHotWater: 2932.8
counterHeatQHeating: 21408.3
counterHeatQHotWater: 25632.5
counterHeatQTotal: 47040.8
heatingSystemCircPump: off
hotWaterCircPumpExtern: off
hotWaterSwitchingValve: off
solarPump: off
2ndHeatSource1: off
hotWaterCircPumpDeaerate: off
heatingSystemCircPumpDeaerate: off
bivalentLevel: 1
firmware: V2.79
typeHeatpump: LD7
typeSerial: 2309/11-282
solarCollectorTemperature: 25.1
solarBufferTemperature: 27.3
Wärmepumpe steht seit 03:54:28 - Keine Anforderung
triggerEventsState:
heatPumpElectricalPowerEstimated: 0
opStateHeatPump1: Wärmepumpe steht
opStateHeatPump2: seit 03:54:28
opStateHeatPump3: Keine Anforderung
opModeHotWater: Automatik
opStateHotWater: Temp. OK
opModeHeating: Automatik
opStateHeating: Heizgrenze (Soll 15.0°C)
deviceTimeCalc: 2020-07-25 14:20:07
delayDeviceTimeCalc: -2485
durationFetchReadings: 0.020
ambientTemperature: 23.5
averageAmbientTemperature: 18.9
heatingLimit: on
thresholdHeatingLimit: 14.0
thresholdTemperatureSetBack: -20.0
heatingCurveEndPoint: 35.0
heatingCurveOffset: 21.0
hotWaterTemperature: 46.9
hotWaterTemperatureTarget: 46.5
flowTemperature: 29.1
returnTemperature: 26.8
returnTemperatureTarget: 15.0
returnTemperatureHyst: 4.0
returnTemperatureSetBack: 0.0
returnTemperatureExtern: 28.5
heatSourceIN: 21.9
heatSourceOUT: -50.0
heatSourceMotor: off
compressor1: off
hotGasTemperature: 32.4
mixer1FlowTemperature: 27.5
mixer1TargetTemperature: 20.0
counterHours2ndHeatSource1: 451.5
counterHoursHeatPump: 8698.9
counterHoursHeating: 5764.7
counterHoursHotWater: 2932.8
counterHeatQHeating: 21408.3
counterHeatQHotWater: 25632.5
counterHeatQTotal: 47040.8
heatingSystemCircPump: off
hotWaterCircPumpExtern: off
hotWaterSwitchingValve: off
solarPump: off
2ndHeatSource1: off
hotWaterCircPumpDeaerate: off
heatingSystemCircPumpDeaerate: off
bivalentLevel: 1
firmware: V2.79
typeHeatpump: LD7
typeSerial: 2309/11-282
solarCollectorTemperature: 25.1
solarBufferTemperature: 27.3
state: Wärmepumpe steht seit 03:54:28 - Keine Anforderung
internals:
interval:
intervalfunc:
localtime:
0 1595754000
1 1595682000
perlblock:
readings:
all Wetter_2:fc0_uv LAD7:ambientTemperature
realtime:
0 11:00:00
1 15:00:00
time:
0 11:00:00
1 15:00:00
timeCond:
0 0
1 1
timer:
0 0
1 0
timers:
0 0
1 1
trigger:
triggertime:
1595682000:
localtime 1595682000
hash:
1595754000:
localtime 1595754000
hash:
uiTable:
Attributes:
devStateIcon cmd_1:FS20.on cmd_2:FS20.off
room ALARM,FENSTER_TÜREN
verbose 5
Das mit der Redundanz könnte evtl. sein... aber meine Überlegung war... wenn morgens um 11 schon zuviel UV UND eine gewisse Temperatur erreicht ist, dann Jalousien zu. (Das funktioniert alleine auch und DOIF deswegen weil nur einmal am Tag notwendig)
Wenn das nicht so ist, dann wollt ich halt um 15 Uhr nochmal überprüfen, da würde es aber schon reichen, wenn UV ODER Temperatur die Werte erreicht haben...
Mhhh
Hallo Fireball,
es fehlt das attribut do always. Laut dem list von deinem DOIF steht es auf cmd_2, und selbst wenn die Bedingungen am nächsten Tag um 15:00Uhr neu zutreffen wird sich nichts ändern. Ansonsten sind die Klammern so richtig. Wenn es wieder nicht schaltet dann liegt es eher an den Daten, die triggern sollen. Lass da mal den EventMonitor auf die beiden Devices mitlaufen, da sieht man das recht einfach.
Weiterhin würde ich Dir empfehlen:
- übersichtlicher schreiben, z.B. so:
([11:00] and [Wetter_2:fc0_uv] >= 6 and [LAD7:ambientTemperature] >= 22)
(set Rollladen_.*_S$ zu)
(set Meine_TGBot message "UV-Werte und Temperatur übersteigen Grenzwerte. Ich schließe die Jalousien im Süden. UV=[Wetter_2:fc0_uv], TEMP=[LAD7:ambientTemperature]")
DOELSEIF
([15:00] and ([Wetter_2:fc0_uv] >= 6 or [LAD7:ambientTemperature] >= 26))
(set Rollladen_.*_S$ zu)
(set Rollladen_.*_W$ zu)
(set Meine_TGBot message "UV-Werte und Temperatur übersteigen Grenzwerte. Ich schließe die Jalousien im Süden und Westen. UV=[Wetter_2:fc0_uv], TEMP=[LAD7:ambientTemperature]")
ist leserlicher (...und nur 1 Vorschlag).
- Du kannst die Angaben im Ausführungsteil statt in eigene Klammern zu setzen mit Komma trennen, um das DOIF ressourcenschonender zu gestalten, außer Du möchtest da mit wait noch Verzögerungen einbauen.
- im Moment triggern alle Bedingungen, also jedesmal, wenn sich in den Devices Wetter_2 oder LAD7 etwas ändert, wird das DOIF getriggert. Du möchtest aber nur um 11:00 und um 15:00 schauen, wie die Werte der beiden Geräte sind, also genügt die Zeit als Trigger. Einfach ein ? bei den Devices eintragen, dann triggern diese nicht mehr [?Wetter_2:fc0_uv] und [?LAD7:ambientTemperature]
Viel Erfolg!
Sany
Hi, danke für die Tipps,
ja überschaubarer Code ist ne feine Sache und da steh ich eigentlich total drauf... in zwei drei Jahren fragt man sich nämlich wieder, warum hat man das gebaut oder wozu...
Gibts eigentlich ein Attribut "INFO" oder "Description", wo man freitext eingeben kann, damit man seine Fhem besser dokumentieren kann?
Also.. ich habs jetzt so umgestellt:
([11:00] and [?Wetter_2:fc0_uv] >= 6 and [?LAD7:ambientTemperature] >= 22) (
set Rollladen_.*_S$ zu,
set Meine_TGBot message "UV-Werte und Temperatur übersteigen Grenzwerte. Ich schließe die Jalousien im Süden. UV=[Wetter_2:fc0_uv], TEMP=[LAD7:ambientTemperature]"
)
DOELSEIF
([15:00] and ([?Wetter_2:fc0_uv] >= 6 or [?LAD7:ambientTemperature] >= 26)) (
set Rollladen_.*_S$ zu,
set Rollladen_.*_W$ zu,
set Meine_TGBot message "UV-Werte und Temperatur übersteigen Grenzwerte. Ich schließe die Jalousien im Süden und Westen. UV=[Wetter_2:fc0_uv], TEMP=[LAD7:ambientTemperature]"
)
Sieht bedeutend besser aus...
Hab zwei neue Sachen dazu gelernt...
- Ressourcensparender zu Arbeiten...
- die ? kannte ich noch nicht, habe jetzt auf den RP4 gewechselt... damit das mit den Ressourcen auf dauer keine Probleme macht... daher wäre mir das fast egal gewesen, aber gut zu wissen.
Dann schau ich mal wie sich das DOIF nächste Woche verhält.
VG
René
PS: habs grad gefunden:
Zitatcomment
Hält einen freien Kommentar für das Gerät verfügbar
Zitat- die ? kannte ich noch nicht, habe jetzt auf den RP4 gewechselt... damit das mit den Ressourcen auf dauer keine Probleme macht... daher wäre mir das fast egal gewesen, aber gut zu wissen.
gucksu hier: https://fhem.de/commandref_DE.html#DOIF_Zeitintervalle_Readings_und_Status_ohne_Trigger (https://fhem.de/commandref_DE.html#DOIF_Zeitintervalle_Readings_und_Status_ohne_Trigger)
nicht alles muss das DOIF triggern. Denn auch DOIF erzeugt seinerseits Events beim abarbeiten.
...und hier: https://fhem.de/commandref_DE.html#DOIF_wait (https://fhem.de/commandref_DE.html#DOIF_wait)
ist das mit den Klammern oder nicht beschrieben.
Zwar kommt der Hinweis auf die commandref recht häufig, oft auch als einziger (und damit nahezu überflüssiger) Hinweis, aber es empfiehlt sich doch immer wieder die commandref zu DOIF zu durchforsten, wenn etwas nicht geht. Die ist echt lang, weil DOIF so viel kann, es steht auch alles nur recht kurz beschrieben darin, aber es steht alles drin! Wären die Erklärungen und Beispiele ausführlicher, wäre der Text noch länger. Und wenn etwas nicht drinsteht kann man ja auch mal rumprobieren...
Gruß
Sany
P.S. das mit der Übersichtlichkeit steht auch so drin!
P.P.S. comment hast du ja gefunden, im DOIF kannst Du auch am Ende einer Zeile ## und dann dein text eintippen (alles ab ## wird ignoriert)
Puhhh, also ich erwische mich immer wieder, mit dem DOIF, notify usw... irgendwo hab ich immer einen Klemmer, aber glaub mir... ich bin, bevor ich hier was poste, immer stundenlang auf der Suche...
Jetzt wollte ich mein DOIF auf zwei Zeiträume umstellen...
([11:00]-[13:29] and [?Wetter_2:fc0_uv] >= 6 and [LAD7:ambientTemperature] >= 20) (
set Rollladen_.*_S$ zu,
set Meine_TGBot message "UV-Werte und Temperatur übersteigen Grenzwerte. Ich schließe die Jalousien im Süden. UV=[Wetter_2:fc0_uv], TEMP=[LAD7:ambientTemperature]"
)
DOELSEIF
([13:30]-[15:00] and ([?Wetter_2:fc0_uv] >= 6 or [LAD7:ambientTemperature] >= 25)) (
set Rollladen_.*_S$ zu,
set Rollladen_.*_W$ zu,
set Meine_TGBot message "UV-Werte und Temperatur übersteigen Grenzwerte. Ich schließe die Jalousien im Süden und Westen. UV=[Wetter_2:fc0_uv], TEMP=[LAD7:ambientTemperature]"
)
Irgendwie triggert er jetzt aber durch das doalways immerzu...
Was will ich denn erreichen... also eigentlich will ich nicht mehr nur zum Zeitpunkt X umstellen, sondern quasi beim Erreichen der UV/Tempwerte soll geschaltet werden...
Aber wenn ein Zustand greift, dann bleibt DOIF ja da drin... durch doalways, triggert er immerzu...
Ich steh grad aufen Schlauch, denke über ein notify nach, aber das löst mir ja auch nicht, das es nur einmal schalten soll... (pro Tag)
....
VG
René
Lösche das Attribut do
und setze das DOIF um 0 Uhr zurück, dann wird jeder Zweig nur einmal pro Tag ausgeführt.
DOELSEIF ([00:00])
Danke, cool... dann wäre auch ein
DOELSE am Ende ohne etwas richtig?! Das mache ich bei einigen anderen DOIFs...
VG
René
Ja, wenn das dadurch Möglicherweise andere Verhalten, für Dich o.k. ist.
Was meinst du?
Ich meine, wenn ein Reset bei DOELSE durchgeführt wird, statt bei [00:00].