DOIF zur Pumpensteuerung mit on-for-timer geht nicht

[bmwfan]

Hallo,
ich habe ein einfaches DOIF, das ich zur Pumpenansteuerung einer Entwässerungspumpe verwenden möchte. Im Außenbereich ist ein Shelly1 installiert, der als Detached Switch konfiguriert ist. An seinem Ein/Ausgang ist ein Wasserstandssensor angeschlossen und er soll, deswegen Detached Switch, den Zustand des Sensors (1 oder 0) über MQTT an FHEM senden ohne selber zu schalten. Hintergrund: Die Pumpe darf max. 15 Minuten laufen und benötigt dann 15 Min. Pause. Das kann über die Konfiguration des Shelly nicht eingestellt werden.
Problem: Ich bekomme zwar alle 30 sec. ein Statusupdate über MQTT, das DOIF schaltet aber die Pumpoe nicht ein. Ich vermute ein Zusammenspiel zwischen den zyklischen Events, on-for-timer und cmdpause.

Das List des DOIF:

Code: [Auswählen]

Internals:
   DEF        ([MQTT2_shelly1_E8DB84D245AD:input0] == 1 and [?MQTT2_shelly1_E8DB84D245AD] eq "off") (set MQTT2_shelly1_E8DB84D245AD on-for-timer 300)
   FUUID      60cf0efb-f33f-6b6f-ba64-36f56b9236fa740e
   MODEL      FHEM
   NAME       di_Entwaesserungspumpe
   NOTIFYDEV  MQTT2_shelly1_E8DB84D245AD,global
   NR         1874
   NTFY_ORDER 50-di_Entwaesserungspumpe
   STATE      cmd_1
   TYPE       DOIF
   VERSION    24595 2021-06-06 17:52:38
   READINGS:
     2021-06-29 08:06:00   Device          MQTT2_shelly1_E8DB84D245AD
     2021-06-29 07:57:23   cmd             1
     2021-06-29 07:57:23   cmd_event       MQTT2_shelly1_E8DB84D245AD
     2021-06-29 07:57:23   cmd_nr          1
     2021-06-29 08:06:00   e_MQTT2_shelly1_E8DB84D245AD_STATE off
     2021-06-29 08:06:00   e_MQTT2_shelly1_E8DB84D245AD_input0 1
     2021-06-23 08:44:48   mode            enabled
     2021-06-29 07:57:23   state           cmd_1
   Regex:
     accu:
     collect:
     cond:
       MQTT2_shelly1_E8DB84D245AD:
         0:
           input0     ^MQTT2_shelly1_E8DB84D245AD$:^input0:
   attr:
     cmdState:
     cmdpause:
       600
     wait:
     waitdel:
   condition:
     0          ::ReadingValDoIf($hash,'MQTT2_shelly1_E8DB84D245AD','input0') == 1 and ::InternalDoIf($hash,'MQTT2_shelly1_E8DB84D245AD','STATE') eq "off"
   do:
     0:
       0          set MQTT2_shelly1_E8DB84D245AD on-for-timer 300
     1:
   helper:
     DEVFILTER  ^global$|^MQTT2_shelly1_E8DB84D245AD$
     NOTIFYDEV  global|MQTT2_shelly1_E8DB84D245AD
     event      input0: 1
     globalinit 1
     last_timer 0
     sleeptimer -1
     timerdev   MQTT2_shelly1_E8DB84D245AD
     timerevent input0: 1
     triggerDev MQTT2_shelly1_E8DB84D245AD
     timerevents:
       input0: 1
     timereventsState:
       input0: 1
     triggerEvents:
       input0: 1
     triggerEventsState:
       input0: 1
   internals:
     all         MQTT2_shelly1_E8DB84D245AD:STATE
   perlblock:
   readings:
     all         MQTT2_shelly1_E8DB84D245AD:input0
   trigger:
   uiState:
   uiTable:
Attributes:
   cmdpause   600
   comment    cmdpause: Zeitspanne seit letzter Zustandsänderung -> Wenn Pause == Laufzeit sein soll, muss bei cmdpause die doppelte Laufzeit eingegeben werden
   do         always
   room       1.9_Garten,9.8.1_DOIF
Das List des Device:

Code: [Auswählen]

Internals:
   CID        shelly1_E8DB84D245AD
   DEF        shelly1_E8DB84D245AD
   DEVICETOPIC MQTT2_shelly1_E8DB84D245AD
   FUUID      60b4995c-f33f-6b6f-7841-b87470d9c9cc59ac
   IODev      MQTT2_FHEM_Server
   LASTInputDev MQTT2_FHEM_Server
   MQTT2_FHEM_Server_MSGCNT 25745
   MQTT2_FHEM_Server_TIME 2021-06-29 08:07:37
   MSGCNT     25745
   NAME       MQTT2_shelly1_E8DB84D245AD
   NR         1866
   STATE      off
   TYPE       MQTT2_DEVICE
   READINGS:
     2021-06-29 08:07:37   0_event         L
     2021-06-29 08:07:37   0_event_cnt     1
     2021-06-24 21:11:05   IODev           MQTT2_FHEM_Server
     2021-05-31 10:12:24   attrTemplateVersion 20200831
     2021-06-29 08:07:37   fw_ver          20210429-100340/v1.10.4-g3f94cd7
     2021-06-29 08:07:37   id              shelly1-E8DB84D245AD
     2021-05-31 10:12:25   info_actions_stats_skipped 0
     2021-05-31 10:12:25   info_cfg_changed_cnt 0
     2021-05-31 10:12:25   info_cloud_connected false
     2021-05-31 10:12:25   info_cloud_enabled false
     2021-05-31 10:12:25   info_fs_free    150851
     2021-05-31 10:12:25   info_fs_size    233681
     2021-05-31 10:12:25   info_has_update false
     2021-05-31 10:12:25   info_inputs_1_event
     2021-05-31 10:12:25   info_inputs_1_event_cnt 0
     2021-05-31 10:12:25   info_inputs_1_input 0
     2021-05-31 10:12:25   info_mac        E8DB84D245AD
     2021-05-31 10:12:25   info_meters_1_is_valid true
     2021-05-31 10:12:25   info_meters_1_power 0.00
     2021-05-31 10:12:25   info_mqtt_connected true
     2021-05-31 10:12:25   info_ping_check true
     2021-05-31 10:12:25   info_ram_free   38112
     2021-05-31 10:12:25   info_ram_total  50192
     2021-05-31 10:12:25   info_relays_1_has_timer false
     2021-05-31 10:12:25   info_relays_1_ison false
     2021-05-31 10:12:25   info_relays_1_source input
     2021-05-31 10:12:25   info_relays_1_timer_duration 0
     2021-05-31 10:12:25   info_relays_1_timer_remaining 0
     2021-05-31 10:12:25   info_relays_1_timer_started 0
     2021-05-31 10:12:25   info_serial     1
     2021-05-31 10:12:25   info_time       10:12
     2021-05-31 10:12:25   info_unixtime   1622448745
     2021-05-31 10:12:25   info_update_beta_version 20210514-065742/v1.10.5-rc1-gecc99b7
     2021-05-31 10:12:25   info_update_has_update false
     2021-05-31 10:12:25   info_update_new_version 20210429-100340/v1.10.4-g3f94cd7
     2021-05-31 10:12:25   info_update_old_version 20210429-100340/v1.10.4-g3f94cd7
     2021-05-31 10:12:25   info_update_status idle
     2021-05-31 10:12:25   info_uptime     273
     2021-05-31 10:12:25   info_wifi_sta_connected true
     2021-05-31 10:12:25   info_wifi_sta_ip 192.168.178.102
     2021-05-31 10:12:25   info_wifi_sta_rssi -58
     2021-05-31 10:12:25   info_wifi_sta_ssid WLAN75
     2021-06-29 08:07:37   input0          1
     2021-06-29 08:07:37   ip              192.168.178.102
     2021-06-28 21:29:33   longpush_0      1
     2021-06-29 08:07:37   mac             E8DB84D245AD
     2021-06-29 08:07:37   model           SHSW-1
     2021-06-29 08:07:37   new_fw          false
     2021-06-29 08:07:37   online          true
     2021-06-29 08:07:37   relay0          off
     2021-06-29 08:07:37   state           off
   TIMED_OnOff:
     CMD        on-for-timer
     DURATION   300
     NEXTCMD    off
     START      1624946850
     START_FMT  2021-06-29 08:07:30
     hash:
Attributes:
   alias      Wasserpumpe
   devStateIcon {my $onl = ReadingsVal($name,"online","false") eq "false" ? "rot" : ReadingsVal($name,"new_fw","false") eq "true" ? "gelb" : "gruen"; my $light = ReadingsVal($name,"state","off"); my $show = '<a href="';$show .= $onl eq "gelb" ? "/fhem?cmd.dummy=set $name x_update&XHR=1\">" : "http://".ReadingsVal($name,"ip","none").' "target="_blank">'; $show .= FW_makeImage("10px-kreis-".$onl)."</a>"; "<div> $show <a href=\"/fhem?cmd.dummy=set $name toggle&XHR=1\">".FW_makeImage($light)."</a></div>" }
   event-on-update-reading input0
   icon       sani_garden_pump
   model      shelly1
   readingList shellies/shelly1-E8DB84D245AD/relay/0:.* state
  shellies/shelly1-E8DB84D245AD/relay/0:.* relay0
  shellies/shelly1-E8DB84D245AD/input/0:.* input0
  shellies/shelly1-E8DB84D245AD/online:.* online
  shellies/shelly1-E8DB84D245AD/announce:.* { json2nameValue($EVENT) }
  shellies/announce:.* { $EVENT =~ m,..id...shelly1-E8DB84D245AD...mac.*, ? json2nameValue($EVENT) : return }
shelly1_E8DB84D245AD:shellies/shelly1-E8DB84D245AD/info:.* { json2nameValue($EVENT, 'info_', $JSONMAP) }
shelly1_E8DB84D245AD:shellies/shelly1-E8DB84D245AD/input_event/0:.* { json2nameValue($EVENT, '0_', $JSONMAP) }
shelly1_E8DB84D245AD:shellies/shelly1-E8DB84D245AD/longpush/0:.* longpush_0
   room       MQTT2_DEVICE
   setList    off:noArg shellies/shelly1-E8DB84D245AD/relay/0/command off
  on:noArg shellies/shelly1-E8DB84D245AD/relay/0/command on
  x_update:noArg shellies/shelly1-E8DB84D245AD/command update_fw
  x_mqttcom shellies/shelly1-E8DB84D245AD/command $EVTPART1
Aktuell kommt alle 30 sec. ein Event mit Status input0 (Eingang des Sensors) auf 1 und die Pumpe ist auf off, aber das DOIF triggert nicht. Ich habe keine Idee mehr, woran das liegen kann. Hat jemand eine Ansatz?

Viele Grüße Jürgen

[SouzA]

Hi,

mit Attribut "do always" mal versucht?

Bis denn
SouzA

[Frank_Huber]

mit Attribut "do always" mal versucht?

ist doch gesetzt.

[Frank_Huber]

Dein DOIF hat geschaltet.
CMD_1 am 2021-06-29 um 07:57:23

kann denn der MQTT Shelly den Befehl?
Was passiert wenn Du

Code: [Auswählen]

set MQTT2_shelly1_E8DB84D245AD on-for-timer 300über die Befehlszeile eingibst?

evtl fehlt im Shelly ja das Attribut "setExtensions 1"

[SouzA]

ist doch gesetzt.

Stimmt, du hast Recht!
Wenn man mal bis zum Ende scrollt...^^

Bis denn
SouzA

[bmwfan]

@Frank:
Um 7:57 habe ich es manuell versucht. Pumpe lief aber nicht an.

set MQTT2_shelly1_E8DB84D245AD on-for-timer 300

Eingegeben, aber Pumpe läuft nicht. Ich habe ja die Kombination mit cmdpause in Verdacht, weis aber nicht wie ich ansonsten realisieren soll, dass die Pumpe definiert nach einer engestellten Zeit auch wieder abschaltet.

evtl fehlt im Shelly ja das Attribut "setExtensions 1"

Ist tatsächlich nicht gesetzt, da ich nie etwas gelesen habe, dass man das bei MQTT benötigt. Was genau bewirkt das Attribut?

Aktuell steht der Sensor wieder komplett unter Wasser - müßte also schon lange schalten - es tut sich aber nichts. Input0 steht auf 1, alle 30 sec. kommt ein Update vom Device über MQTT aber nichts passiert.

Setze jetzt mal das extension-Attribut

[Beta-User]

Der Befehl scheint nicht bei dem Shelly anzukommen. MQTT2_DEVICE kann (im Unterschied zu MQTT_DEVICE) SetExtensions out-of-the-box, und das war auch aktiv, als du heute morgen das list gemacht hast (der TIMED_OnOff-Hash kommt da her).

Setze mal setStateList auf "on off", dann kannst du ggf. auch optisch direkt erkennen, wie lange es ggf. dauert, bis der Befehl den Empfänger erreicht bzw. ob das überhaupt der Fall ist.

Seltsam, dass wir grade eine Häufung dieses Themas bei den Shelly haben: https://forum.fhem.de/index.php/topic,121816.0/topicseen.html (da gibt's auch mehr Lesestoff wie man ggf. erkennen kann, ob die subscritions ok sind usw.)

[bmwfan]

Hab jetzt attr setExtensionsEvent mal auf 1 gesetzt, auch wenn es scheinbar beim MQTT2-DEVICE nicht notwendig ist und auch setStateList auf "on off".

Ich sehe aber gerade, dass um 13:14 (vor 1 Minute) wieder ein Event von input0 kam, ohne dass die Pumpe anläuft.

Im List steht:

Code: [Auswählen]

2021-06-29 13:18:13   input0          1
     2021-06-29 13:14:43   ip              192.168.178.102
     2021-06-29 09:42:11   longpush_0      1
     2021-06-29 13:14:43   mac             E8DB84D245AD
     2021-06-29 13:14:43   model           SHSW-1
     2021-06-29 13:14:43   new_fw          false
     2021-06-29 13:14:43   online          true
     2021-06-29 13:18:13   relay0          off
     2021-06-29 13:18:13   state           off
   TIMED_OnOff:
     CMD        on-for-timer
     DURATION   300
     NEXTCMD    off
     START      1624965276
     START_FMT  2021-06-29 13:14:36
     hash:
Attributes:
   alias      WasserpumpeDas würde doch bedeuten, dass um 13:14 ein on-for-timer mit 300 sec. gestartet hat, aber die Pumpe ist nicht angelaufen.

Und um 13:22 steht im List:

Code: [Auswählen]

2021-06-29 13:22:13   input0          1
     2021-06-29 13:14:43   ip              192.168.178.102
     2021-06-29 09:42:11   longpush_0      1
     2021-06-29 13:14:43   mac             E8DB84D245AD
     2021-06-29 13:14:43   model           SHSW-1
     2021-06-29 13:14:43   new_fw          false
     2021-06-29 13:14:43   online          true
     2021-06-29 13:22:13   relay0          off
     2021-06-29 13:22:13   state           off
Meine Schlussfolgerung wäre, wie auch Beta-User vermutet, dass der Befehl gar nicht am Shelly ankommt.

Was kann ich noch tun?

[Beta-User]

Was kann ich noch tun?

Erst mal subscriptions checken und testen, ob ein einfaches "on" (bzw. "off") ankommt, oder ob das bei "set_on" bleibt, bis das "off" (als Statusmeldung, nicht als Rückmeldung, dass der Befehl angekommen ist) kommt.

Hab jetzt attr setExtensionsEvent mal auf 1 gesetzt

Mit einiger Wahrscheinlichkeit hatte Frank_Huber was anderes (aus dem Modul MQTT_DEVICE) gemeint, aber es schadet auch nicht, setExtensionsEvent zu setzen...

Ich sehe aber gerade, dass um 13:14 (vor 1 Minute)

Du sollstest dich mAn. mit dem Eventhandler erst dann wieder beschäftigen, wenn die Kommunikation mit dem Shelly reibungslos läuft. Das Ding war schon um 13:18 Uhr aus gewesen...

[bmwfan]

Erster Versuch:
Nach einem

Code: [Auswählen]

set MQTT2_shelly1_E8DB84D245AD on geht das reading state kurz auf set_on und danach wieder auf off, ohne dass das reading relay0 auf on geht.

Zweiter Versuch:
state geht direkt auf on und auch relay0 geht auf on und die Pumpe läuft auch tatsächlich. Ein

Code: [Auswählen]

set MQTT2_shelly1_E8DB84D245AD off bewirkt sofortiges Ausschalten.

Dritter Versuch:
Nach einem

Code: [Auswählen]

set MQTT2_shelly1_E8DB84D245AD on-for-timer 30 geht die Pumpe an und nach einigen Sekunden (nicht gemessen) wieder aus.

Dann liegt es daran, dass die Befehle nicht immer an den Shelly durchkommen. Der Shelly ist im Garten, ca. 10 m von einem AP (Ziegelwand dazwischen) entfernt.
Der RSSI-Wert in FHEM zeigt -58, im Shelly aber -68, wobei das meiner Erfahrung nach noch nicht kritisch sein dürfte.

Kann ich das DOIF so gestalten, dass ich eine Befehlswiederholung erreiche, bis der Shelly tatsächlich on bzw. wieder off ist oder welche Möglichkeiten gibt es noch?
Die Pumpe darf scheinbar max. 15 Min. laufen und braucht dann 15 Min. Pause, da sie ansonsten defekt geht.

[Beta-User]

Zum einen würde ich mal die Teleperiod verlängern oder automatische Reports ganz ausschalten (Stichwort "Geschwätzigkeit").
Dann verhagelt dir nämlich nicht der Status-update die Erkennung, dass da grade was schief hängt.

Für Teil 2 (set_on oder set_off hängt zu lange) kannst du ggf. einen watchdog verwenden.

Hier würde ich aber die Radikallösung vorschlagen: Aktor tauschen gegen was, das mit der Entfernung kein Problem hat... Evtl. ist es auch nur der konkrete Shelly und/oder die Kombination mit dem AP (was auch immer das konkret ist; es gibt welche, die sind ggf. komplett ungeeignet (FritzBox), bei anderen ist es die firmware (jüngst war hier das Thema mit "eigentlich" guten APs von Uni-irgendwas)).

[bmwfan]

Tip mit Teleperiode: Kannst Du das bitte näher erläutern, es sagt mir nichts. Ich meine, dass ich das zyklische Senden des Shelly bzw. Generierung der event-on-update des Device nicht einstellen kann.
Wo und wie kann ich automatische Reports ganz ausschalten?

AP ist tatsächlich eine Fritzbox 7490, die ich übrig hatte und in einem Zimmer möglichst nahe zum Freisitz plaziert habe, da das Signal ansonsten wirklich zu schwach war.

Bin schon auf Shelly gewechselt, da ich mit HM-Aktoren auf 868 MHz deutlich mehr Schwierigkeiten im Außenbereich hatte. Direkt neben dem Shelly1 werkelt noch ein Shelly2.5, der keinerlei Probleme macht. Also eventuell den Shelly 1 austauschen wenn es da so große Qualitätsschwankungen gibt.

EDIT: Bin im Zuge Deiens Hinweises auf die Geschwätzigkeit auf das Attribut

Code: [Auswählen]

timestamp-on-change-reading gestossen. Ich denke das ist es, was Du mit Geschwätzigkeit gemeint hast und habe es gleich egsetzt.

[Beta-User]

https://wiki.fhem.de/wiki/MQTT2-Module_-_Praxisbeispiele#Vorbemerkung:

Code: [Auswählen]

http://<ip-des-shelly>/settings?mqtt_update_period=0FritzBox ist bekannt dafür, dass die mit ESP8266 allg. Probleme hat, was definitiv nicht besser wird, wenn ggf. noch (viele) weitere Clients am WLAN hängen. Kann sein, dass ein simples "Drehen" des Shelly schon was bewirkt. Bzgl. Qualität: an sich verwendet der Hersteller afaik getestete ESP's, ein Serienfehler ist aber trotzdem natürlich nicht auszuschließen.

Bei mir machen die Homematic-Classic-Aktoren (allerdings im Haus) keine Probleme - es sei denn, die Kondensatoren sind trocken; und 10m sind eigentlich auch keine Entfernung für die Technik (aber natürlich abhängig von den allg. Funkgegebenheiten). Na ja, trotzdem ist alles, was an Ersatz künftig kommt dann ZWave (das man aber auch entsprechend organisieren muss).

[bmwfan]

Aktuell kommen die Befehle und auch Rückmeldungen wieder nicht. Habe den Befehl mal abgesetzt und es kommen tatsächlich keine Statusmeldungen im 30sec.-Abstand mehr.

Ich habe den Shelly1 in einem kleinen wasserdichten Kasten und betreibe ihn, da die Pumpe auf 12V läuft, auch mit 12 V. Die Spannungsversorgung erfolgt mit einem AC/DC-Netzteil von Meanwell mit 5 A (Pumpe zieht zwar nur 1,5A, aber der Anlaufstrom war selbst für ein 2,5A-Netzteil zu groß. Mit dem 5A-Netzteil geht es, allerdings frage ich mich jetzt ob es nicht zu viele EMV-Störungen durch die dicht beieinanderliegenden Komponenten (nur Netzteil und Shelly, die Pumpe ist ca. 1 m weit weg iim Sickerschacht) gibt und die Probleme daher rühren. Es ist der erste Shelly, den ich mit 12 V betreibe. Habe auch schon einen Pufferkondensator an die Spannungseingänge geschalten, da ich einen WLAN-Ausfall durch einen Spannungseinbruch befürchtet habe. Dann müßte ich aber die Pumpe anlaufen sehen und das erfolgt gar nicht. Die Befehle kommen schlicht nicht durch scheint mir.

[Beta-User]

Kann schon sein, dass es u.a. auch ein EMV-Problem ist.

Der Shelly schaltet doch potentialfrei, oder? Dann würde ich ggf. mal testen, ob es an 230V Versorgung besser ist?
Ggf. auch einfach das Netzteil über den ESP schalten?

Ansonsten noch:

EDIT: Bin im Zuge Deiens Hinweises auf die Geschwätzigkeit auf das Attribut

Code: [Auswählen]

timestamp-on-change-reading gestossen. Ich denke das ist es, was Du mit Geschwätzigkeit gemeint hast und habe es gleich egsetzt.

Das gehört zwar auch in den Gesamtzusammenhang mit rein, beseitigt aber auch nur bestimmte Symptome einer "allgemeinen" Krankheit. Im Moment bin ich eher am überlegen, ob es für diesen Anwendungsfall nicht sogar sinnvoll wäre, teleperiode zu belassen und dann eine Perl-Routine auf den "relay"-Topic anzusetzen und dann sowohl die Auswertung, ob der set-Befehl angekommen ist darüber zu machen wie auch das "eocr-Handling"...