ich möchte gern, dass eine Nachricht geschickt wird wenn mein Blitzwolf für länger als 6 Minuten ein reading ENERGY_Current zwischen 0.025 und 0.034 aufweist. Das gelingt mir nicht und ich verstehe nicht warum. Hier meine Definition:
defmod WaschmaschineDOIF DOIF ([Blitzwolf1:ENERGY_Current]>0.025 and [Blitzwolf1:ENERGY_Current]<0.034) (set TelegramBot _msg Waschmaschine fertig)
attr WaschmaschineDOIF do always <== hatte ich auch mal wegelassen, ohne Erfolg
attr WaschmaschineDOIF repeatsame 1
attr WaschmaschineDOIF waitsame 360
Hat jemand eine Idee, was ich hier falsch mache? Nach der commandref sollte doch folgendes gelten:
Zitat
"Mit dem Attribut waitsame <Zeitspanne in Sekunden für cmd_1>:<Zeitspanne in Sekunden für das cmd_2>:... wird ein Kommando erst dann ausgeführt, wenn innerhalb einer definierten Zeitspanne die entsprechende Bedingung zweimal hintereinander wahr wird." == klar, die Bedingung soll zweimal hintereinander wahr sein, innerhalb von sechs Minuten
"Mit dem Attribut repeatsame <maximale Anzahl von cmd_1>:<maximale Anzahl von cmd_2>:... wird die maximale Anzahl hintereinander folgenden Ausführungen festgelegt" == ich will nur einmal eine Nachricht kriegen
Also wenn der Wert dazwischen liegt, dann wird die Bedingung "true", also wahr.
Und dann einfach per
wait 360
mit der Ausführung warten. klappt das nicht?
Du meinst nochmal extra wait? Ich dachte, waitsame macht das schon. Ich füge das mal ein und schaue dann. Danke!
poste im Zweifel mal ein List des DOIF und des Blitzwolf.
Zitat von: andies am 23 September 2019, 15:14:25
Du meinst nochmal extra wait? Ich dachte, waitsame macht das schon. Ich füge das mal ein und schaue dann. Danke!
btw, waitsame macht ganz was anderes als wait. ;-)
List DOIF:
Internals:
CID DVES_93AC5D
DEF DVES_93AC5D
DEVICETOPIC Blitzwolf1
FUUID 5d0c8a24-f33f-1115-ccb8-fdc59cb4a98962ba
IODev Mosquitto
LASTInputDev Mosquitto
MSGCNT 12526
Mosquitto_MSGCNT 12526
Mosquitto_TIME 2019-09-23 15:11:51
NAME Blitzwolf1
NR 235
STATE on
TYPE MQTT2_DEVICE
Helper:
DBLOG:
ENERGY_Current:
DbLog:
TIME 1569244311.67977
VALUE 0.032
Verbrauch:
DbLog:
TIME 1569244311.67977
VALUE 2.75999999977648
READINGS:
2019-09-23 15:11:51 ENERGY_Current 0.032
2019-09-23 15:11:51 ENERGY_Factor 0.48
2019-09-23 15:11:51 ENERGY_Period 0.240
2019-09-23 15:11:51 ENERGY_Power 3.500
2019-09-23 15:11:51 ENERGY_Today 0.60240
2019-09-23 15:11:51 ENERGY_Total 226.28600
2019-09-23 15:11:51 ENERGY_Voltage 227.500
2019-09-23 15:11:51 ENERGY_Yesterday 1.16991
2019-08-13 07:01:27 FallbackTopic DVES_93AC5D
2019-08-13 07:01:27 GroupTopic sonoffs
2019-08-13 07:01:27 Hostname blitzwolf1-3165
2019-08-13 07:01:27 IPAddress 192.168.2.6
2019-09-21 03:25:12 LWT online
2019-08-13 07:01:27 Module BlitzWolf SHP2
2019-09-23 15:11:51 POWER1 on
2019-08-13 07:01:27 RestartReason Software/System restart
2019-06-24 21:51:23 SaveData on
2019-06-24 21:51:22 SetOption26 on
2019-06-24 21:51:21 StateText1 off
2019-06-24 21:51:22 StateText2 on
2019-06-24 21:51:22 StateText3 toggle
2019-06-24 21:51:22 StateText4 hold
2019-09-23 15:11:51 Time 2019-09-23T15:11:51
2019-09-23 15:11:51 Uptime 41T08:10:31
2019-09-23 15:11:51 Vcc 3.142
2019-09-23 15:11:51 Verbrauch 2.75999999977648
2019-08-13 07:01:27 Version 6.1.1
2019-08-29 18:08:30 WaMaLaeuft 0
2019-08-13 07:01:27 WebServerMode Admin
2019-09-23 15:11:51 Wifi_AP 1
2019-09-23 15:11:51 Wifi_APMac 1A:E8:29:AA:44:A0
2019-09-23 15:11:51 Wifi_RSSI 66
2019-09-23 15:11:51 Wifi_SSId WLAN-120954
Attributes:
IODev Mosquitto
alias Waschmaschine
autocreate 0
comment 192.168.2.6
devStateIcon on:ios-on-green:off off:ios-off:on offline:ios_setoff_fill:
group intern
model A_01a_tasmota_basic_state_power1
readingList tele/blitzwolf1/LWT:.* LWT
tele/blitzwolf1/STATE:.* { json2nameValue($EVENT) }
tele/blitzwolf1/SENSOR:.* { json2nameValue($EVENT) }
tele/blitzwolf1/INFO.:.* { json2nameValue($EVENT) }
stat/blitzwolf1/RESULT:.* { json2nameValue($EVENT) }
setList off:noArg cmnd/blitzwolf1/POWER1 0
on:noArg cmnd/blitzwolf1/POWER1 1
toggle:noArg cmnd/blitzwolf1/POWER1 2
setStateList on off toggle
stateFormat POWER1
userReadings Verbrauch difference {12*1000*ReadingsVal($name,"ENERGY_Total",0);}
und List DOIF:
Internals:
DEF ([Blitzwolf1:ENERGY_Current]>0.025 and [Blitzwolf1:ENERGY_Current]<0.034) (set TelegramBot _msg @346761697 @340579883 Waschmaschine: 🧺 fertig)
FUUID 5d257443-f33f-1115-b0d9-8f58f6304871e7c7
MODEL FHEM
NAME WaschmaschineDOIF
NR 254
NTFY_ORDER 50-WaschmaschineDOIF
STATE cmd_1
TYPE DOIF
VERSION 19303 2019-05-01 08:47:16
READINGS:
2019-09-23 15:11:51 Device Blitzwolf1
2019-09-02 17:02:41 cmd 1
2019-09-02 17:02:41 cmd_count 1
2019-09-02 17:02:41 cmd_event Blitzwolf1
2019-09-02 17:02:41 cmd_nr 1
2019-09-23 15:11:51 e_Blitzwolf1_ENERGY_Current 0.032
2019-08-29 21:13:41 mode enabled
2019-09-02 17:02:41 state cmd_1
2019-09-02 13:08:21 wait_timer no timer
Regex:
accu:
attr:
repeatsame:
1
wait:
0:
360
waitdel:
waitsame:
360
condition:
0 ::ReadingValDoIf($hash,'Blitzwolf1','ENERGY_Current')>0.025 and ::ReadingValDoIf($hash,'Blitzwolf1','ENERGY_Current')<0.034
devices:
0 Blitzwolf1
all Blitzwolf1
do:
0:
0 set TelegramBot _msg @346761697 @340579883 Waschmaschine: 🧺 fertig
1:
helper:
event Time: 2019-09-23T15:11:51,ENERGY_Yesterday: 1.16991,ENERGY_Period: 0.240,ENERGY_Voltage: 227.500,ENERGY_Current: 0.032,ENERGY_Today: 0.60240,ENERGY_Factor: 0.48,ENERGY_Total: 226.28600,ENERGY_Power: 3.500,Verbrauch: 2.75999999977648
globalinit 1
last_timer 0
sleeptimer -1
timerdev Blitzwolf1
timerevent Time: 2019-09-23T15:11:51,ENERGY_Yesterday: 1.16991,ENERGY_Period: 0.240,ENERGY_Voltage: 227.500,ENERGY_Current: 0.032,ENERGY_Today: 0.60240,ENERGY_Factor: 0.48,ENERGY_Total: 226.28600,ENERGY_Power: 3.500,Verbrauch: 2.75999999977648
triggerDev Blitzwolf1
timerevents:
Time: 2019-09-23T15:11:51
ENERGY_Yesterday: 1.16991
ENERGY_Period: 0.240
ENERGY_Voltage: 227.500
ENERGY_Current: 0.032
ENERGY_Today: 0.60240
ENERGY_Factor: 0.48
ENERGY_Total: 226.28600
ENERGY_Power: 3.500
Verbrauch: 2.75999999977648
timereventsState:
Time: 2019-09-23T15:11:51
ENERGY_Yesterday: 1.16991
ENERGY_Period: 0.240
ENERGY_Voltage: 227.500
ENERGY_Current: 0.032
ENERGY_Today: 0.60240
ENERGY_Factor: 0.48
ENERGY_Total: 226.28600
ENERGY_Power: 3.500
Verbrauch: 2.75999999977648
triggerEvents:
Time: 2019-09-23T15:11:51
ENERGY_Yesterday: 1.16991
ENERGY_Period: 0.240
ENERGY_Voltage: 227.500
ENERGY_Current: 0.032
ENERGY_Today: 0.60240
ENERGY_Factor: 0.48
ENERGY_Total: 226.28600
ENERGY_Power: 3.500
Verbrauch: 2.75999999977648
triggerEventsState:
Time: 2019-09-23T15:11:51
ENERGY_Yesterday: 1.16991
ENERGY_Period: 0.240
ENERGY_Voltage: 227.500
ENERGY_Current: 0.032
ENERGY_Today: 0.60240
ENERGY_Factor: 0.48
ENERGY_Total: 226.28600
ENERGY_Power: 3.500
Verbrauch: 2.75999999977648
internals:
itimer:
perlblock:
readings:
0 Blitzwolf1:ENERGY_Current
all Blitzwolf1:ENERGY_Current
trigger:
uiState:
uiTable:
Attributes:
comment verbrauch in watt
do always
group intern
repeatsame 1
wait 360
waitsame 360
Zitat von: Frank_Huber am 23 September 2019, 15:15:16
btw, waitsame macht ganz was anderes als wait. ;-)
Hmm. Dann kapiere ich das nicht, aber es steht doch in der commandref
ZitatMit dem Attribut waitsame <Zeitspanne in Sekunden für cmd_1>:<Zeitspanne in Sekunden für das cmd_2>:... wird ein Kommando erst dann ausgeführt, wenn innerhalb einer definierten Zeitspanne die entsprechende Bedingung zweimal hintereinander wahr wird.
Und genau das will ich doch?!
Zitatlänger als 6 Minuten ein reading ENERGY_Current zwischen 0.025 und 0.034 aufweist.
und
Zitatwird ein Kommando erst dann ausgeführt, wenn innerhalb einer definierten Zeitspanne die entsprechende Bedingung zweimal hintereinander wahr wird.
sind für mich 2 verschiedene Dinge.
"länger als" ist nicht "zweimal".
OK, war ich unpräzise. Wenn zu einem Zeitpunkt t und zum Zeitpunkt t+360Sekunden die genannte Bedingung war ist, soll die Nachricht geschickt werden. Das soll einmal geschehen und dann erst wieder, wenn die genannten Bedingung zwischendurch einmal falsch wurde.
Du schreibst jetzt was ganz anderes als zu Beginn!
ZitatWenn zu einem Zeitpunkt t und zum Zeitpunkt t+360Sekunden die genannte Bedingung war ist,
Zitatlänger als 6 Minuten ein reading ENERGY_Current zwischen 0.025 und 0.034 aufweist.
Überlege Dir erstmal genau was Du willst, dann ....
Und lese Dir mal die Erklärung zu wait durch.
Also Leute, das mit dem wait kam doch nicht von mir - das könnt Ihr sehen, wenn Ihr einfach oben mal nachschaut, wo das zum ersten Mal erschien. Mein Vorschlag war das nicht und das könnt Ihr mir jetzt nicht vorwerfen. Aber gern lese ich nochmal wait:
ZitatVerzögerungen für die Ausführung von Kommandos werden pro Befehlsfolge über das Attribut "wait" definiert.
Ich habe auch deshalb nicht zuerst an wait gedacht und glaube auch nicht, dass das hilft.
So, und nun zu "was willst du eigentlich". Überlegt habe ich mir das schon, keine Sorge. Alle sechs Minuten kommt eine Meldung/event, wie hoch ENERGY_current ist. Dazwischen meldet Blitzwolf1 nichts. Ich will, wenn zweimal das Event "ENERGY_current ist größer als 0.025 und kleiner als 0.034" hintereinander erschien, dass dann eine Message ausgelöst wird. Ich bin auch der Meinung, dass ich das halbwegs klar ausgedrückt habe. Jedenfalls ist mir nicht klar, was rabehd nicht klar ist. Nur "Du schreibst was ganz anderes" stimmt nicht, das ist zumindest ähnlich und die Unterschiede sehe ich auch dann nicht, wenn man mich auffordert "sieh doch den Unterschied". Da musst Du schon etwas klarer werden oder es ganz lassen, Vorwürfe helfen mir hier nicht, wenn sie so knapp und ohne weitere Erläuterung kommen.
Es ist was ganz anders
ob ich aller 6 Minuten prüfe ob etwas wahr ist
oder
ob ein Wert 6 Minuten innerhalb einer Toleranz sein soll
Der Hinweis zu wait kam doch!
https://wiki.fhem.de/wiki/DOIF/Einsteigerleitfaden,_Grundfunktionen_und_Erl%C3%A4uterungen#wait (https://wiki.fhem.de/wiki/DOIF/Einsteigerleitfaden,_Grundfunktionen_und_Erl%C3%A4uterungen#wait)
Da steht es und wenn man es nicht versteht (gelesen hast Du es ja wohl), dann schaut man mit der Suchfunktion oder fragt konkret.
Für Dich: Wird ein Zweig durch die erfüllte Bedingung ausgelöst und hat als Attribut ein wait, dann wird mit der Ausführung gewartet. Die Ausführung erfolgt später aber nur, wenn sich bis dahin die Bedingung nicht verändert hat. ("Laufende Wait-Timer werden bei einem eingeleiteten Statuswechsel des DOIF abgebrochen")
Das wäre dann genau Dein Wunsch
Zitatlänger als 6 Minuten ein reading ENERGY_Current zwischen 0.025 und 0.034 aufweist.
ok, also probiere ich mal wait und berichte, danke!
Trotzdem verstehe ich die Formulierungen in commandref und wiki nicht und das lieg nicht nur an mir. Vielleicht kannst du licht ins dunkel bringen. Ich habe ein device, das genau alle fünf [5!] Minuten Ereignisse erzeugt. Sobald die Ereignisse eintreffen, wird eine Bedingung geprüft. Wo ist unter diesen Annahmen der Unterschied zwischen
Zitat
wait: Das Attribut verzögert die Befehlsausführung, nach wahr werden einer Bedingung [erste Ereignis trifft ein]
Laufende Wait-Timer werden bei einem eingeleiteten Statuswechsel des DOIF abgebrochen [wenn zweites Ereignis nicht die Bedingung erfüllt], daher werden die zu verzögernden Befehle nicht mehr ausgeführt. [Sonst aber doch schon, weil die Verzögerung nur sechs Minuten beträgt]
und
Zitat
waitsame: wenn innerhalb einer definierten Zeitspanne [hier sechs Minuten, also zweimal hintereinander eintreffen des oben genannten Ereignisses] die entsprechende Bedingung zweimal hintereinander wahr wird.
Für mich ist dasselbe? Wenn nein: wie müssen die Ereignisse oder die Umgebung/Bedingungen aussehen, damit bei einem was anderes herauskommt als bei dem anderen?
Ich glaube, du musst das mehr DOIF-mäßig sehen, meine Interpretation (der noch nie mit waitsame gearbeitet hat, aber das wait nutzt um Anwesenheit erst auf Abwesenheit zu schalten, wenn der Token wirklich 240 Sekunden weg war und nicht nur kurz versteckt):
Bedingung wird wahr => DOIF springt auf das Kommando
dann wait: DOIF macht das Kommando erst, wenn DOIF-soundsolange auf wahr bleibt, d.h. sich nicht verändert (Stichwort kein Statuswechsel).
waitsame: Taster wird gedrückt, Bedingung ist war (cmd_1), Taster wird losgelassen, Statuswechsel in cmd_2, taster gedrückt, Bedinung erneut wahr (cmd_1) - das ganze in der waitsame Zeitspanne und sooft wie repeatsame (+1) => Führe die Kommandos aus cmd_1 aus!
ich mach das gleiche wie du:
Verbrauch des Receivers für 3 Minuten unter X => Kodi ausschalten, Beamer ausschalten.
Wenn ich aber nur kurz ausmache (ausversehen oder Fehlmessung) dann passiert nix.
BLE-Token auf absent => Person auf absent aber mit wait 300: 3 Minuten Müll rausbringen soll mich nicht auf absent schalten.
Danke, das ist ja nun viel klarer. Ich würde gern in dem anderen Thread, der im Wiki verlinkt ist, ändern. Was hältst Du von dieser Beschreibung:
- wait X: Ein Kommando wird nur dann ausgelöst, wenn X Sekunden lang die Bedingung durchgehend wahr war.
- waitsame X: Ein Kommando wird nur dann ausgelöst, wenn sich innerhalb von X Sekunden die Bedingungen mehrfach geändert haben; dabei muss es insgesamt repeatsame+1 mal wahr gewesen sein (und entsprechend oft falsch)
Ist das korrekt? Dann frage ich mal Damian.
Zitat von: andies am 02 Oktober 2019, 08:13:46
Danke, das ist ja nun viel klarer. Ich würde gern in dem anderen Thread, der im Wiki verlinkt ist, ändern. Was hältst Du von dieser Beschreibung:
- wait X: Ein Kommando wird nur dann ausgelöst, wenn X Sekunden lang die Bedingung durchgehend wahr war.
- waitsame X: Ein Kommando wird nur dann ausgelöst, wenn sich innerhalb von X Sekunden die Bedingungen mehrfach geändert haben; dabei muss es insgesamt repeatsame+1 mal wahr gewesen sein (und entsprechend oft falsch)
Ist das korrekt? Dann frage ich mal Damian.
Es ist immer die Frage, was die Leute darunter verstehen.
ZitatEin Kommando wird nur dann ausgelöst, wenn X Sekunden lang die Bedingung durchgehend wahr war.
Beispiel:
DOIF ([FS] eq "on") (set bla on)
wait 300
do alwaysDurch do always und keinen DOELSE-Fall, gibt es cmd_2 nicht.
Dadurch kann das Modul bei FS gleich off, den Zustand nicht wechseln, auch wenn die Bedingung eigentlich nicht wahr ist -> obige Aussage stimmt nicht (Kommando wird trotzdem in 300 Sekunden ausgeführt)
ZitatEin Kommando wird nur dann ausgelöst, wenn sich innerhalb von X Sekunden die Bedingungen mehrfach geändert haben; dabei muss es insgesamt repeatsame+1 mal wahr gewesen sein (und entsprechend oft falsch)
Mehrfach ist zu allgemein. Kommando wird ausgeführt, wenn innerhalb von X Sekunden,
zwei mal die Bedingung wahr wurde. repeatsame hat hier eine untergeordnete Rolle. Damit es immer wieder (also auch ohne Zustandswechsel) funktioniert reicht do always, repeatsame ist also nicht nötig.
In beiden Fällen ist die Commandref zu den beiden Attributen, aus meiner Sicht, eindeutiger formuliert.
Ja, sicherlich ist die Commandref eindeutiger formuliert. Mein Problem ist: Ich verstehe sie teilweise nicht. Nun kann man immer sagen "Liegt an dem, der nicht richtig lesen kann" ( ;D ) aber ich dachte mir, auch den Noobs unter uns müsste man das erklären können. Wenn Du also nichts dagegen hast, bohre ich hier mal weiter. Und damit das klarer wird, was ich nicht verstehe, formuliere ich die Fragen, die ich hatte.
ZitatMit dem Attribut waitsame <Zeitspanne in Sekunden für cmd_1>:<Zeitspanne in Sekunden für das cmd_2>:... wird ein Kommando erst dann ausgeführt, wenn innerhalb einer definierten Zeitspanne die entsprechende Bedingung zweimal hintereinander wahr wird.
Implizit steht da drin, dass sie zwischendurch mal falsch wurde - sehe ich das richtig? Es muss also Statuswechsel gegeben haben, auch dann, wenn es kein DOELSE gibt?
ZitatVerzögerungen für die Ausführung von Kommandos werden pro Befehlsfolge über das Attribut "wait" definiert.
Da steht noch nicht, wie genau die Logik ist. Nur, wozu das Kommando dienen soll (eine analoge Formulierung fehlt bei waitsame). Insbesondere war mir nicht klar, ob es hier Statuswechsel geben kann oder muss oder nicht geben darf.
ZitatAusgewertet wird hier der Zustand des Status von remotecontrol nicht das Event selbst.
Das ist ein sehr, sehr wichtiger Satz, dessen Bedeutung ich nicht erfasst oder verstanden hatte. Das ist ja Dein Text, aber ich würde hier gern etwas ausführliches vorschlagen, damit das eben nicht überlesen wird.
ja, es ist immer das Problem, auf der einen Seite die Commandref kurz zu halten, auf der einen Seiten einen Sachverhalt präzise und eindeutig zu beschreiben.
Es ist ja nichts dagegen zu sagen, bestimmte Funktionalität ausführlicher im Wiki zu erklären, allerdings sollte die Erklärung nicht missverständlich (bzw. mehrdeutig sein). Das gelingt mir leider auch nicht immer. Es mussten auch schon Wiki-Beiträge wieder herausgenommen werden, weil die Verfasser es nicht besser wussten ;)
Was man sagen könnte ist z. B.:
Wait:
Ein Kommando wird nur dann ausgelöst, wenn X Sekunden lang die Bedingung durchgehend wahr war, also kein anderer Zweig während der Wartezeit zum Zuge kam.
waitsame:
Ein Kommando wird nur dann ausgelöst, wenn innerhalb von X Sekunden die Bedingung zwei mal wahr wird, ohne dass während der Wartezeit ein anderer Zweig ausgeführt wurde.
Ich bin auch dafür ausführliche Erklärungen gehören ist Wiki!
Dort steht es auch:
Zitatwait
Das Attribut verzögert die Befehlsausführung, nach wahr werden einer Bedingung.
Laufende Wait-Timer werden bei einem eingeleiteten Statuswechsel des DOIF abgebrochen, daher werden die zu verzögernden Befehle nicht mehr ausgeführt.
Kurz, klar, verständlich!