Verständnisfrage zu DOIF: repeatsame und wait

Begonnen von andies, 23 September 2019, 14:15:52

Vorheriges Thema - Nächstes Thema

andies

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
FHEM 6.3 auf RaspPi4 (Raspbian:  6.6.28+; Perl: v5.36.0)
SIGNALduino (433 MHz) und HM-UART (868 MHz), Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

laberlaib

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?
--
Proxmox, Homematic, G-Tags, Zigbee2MQTT, Rhasspy Sprachsteuerung im Aufbau (beta)

andies

Du meinst nochmal extra wait? Ich dachte, waitsame macht das schon. Ich füge das mal ein und schaue dann. Danke!
FHEM 6.3 auf RaspPi4 (Raspbian:  6.6.28+; Perl: v5.36.0)
SIGNALduino (433 MHz) und HM-UART (868 MHz), Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

Frank_Huber

poste im Zweifel mal ein List des DOIF und des Blitzwolf.

Frank_Huber

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. ;-)

andies

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
FHEM 6.3 auf RaspPi4 (Raspbian:  6.6.28+; Perl: v5.36.0)
SIGNALduino (433 MHz) und HM-UART (868 MHz), Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

andies

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?!
FHEM 6.3 auf RaspPi4 (Raspbian:  6.6.28+; Perl: v5.36.0)
SIGNALduino (433 MHz) und HM-UART (868 MHz), Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

rabehd

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".
Auch funktionierende Lösungen kann man hinterfragen.

andies

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.
FHEM 6.3 auf RaspPi4 (Raspbian:  6.6.28+; Perl: v5.36.0)
SIGNALduino (433 MHz) und HM-UART (868 MHz), Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

rabehd

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.
Auch funktionierende Lösungen kann man hinterfragen.

andies

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.
FHEM 6.3 auf RaspPi4 (Raspbian:  6.6.28+; Perl: v5.36.0)
SIGNALduino (433 MHz) und HM-UART (868 MHz), Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

rabehd

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
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.
Auch funktionierende Lösungen kann man hinterfragen.

andies

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?
FHEM 6.3 auf RaspPi4 (Raspbian:  6.6.28+; Perl: v5.36.0)
SIGNALduino (433 MHz) und HM-UART (868 MHz), Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

laberlaib

#13
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.
--
Proxmox, Homematic, G-Tags, Zigbee2MQTT, Rhasspy Sprachsteuerung im Aufbau (beta)

andies

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.
FHEM 6.3 auf RaspPi4 (Raspbian:  6.6.28+; Perl: v5.36.0)
SIGNALduino (433 MHz) und HM-UART (868 MHz), Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann