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:
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:
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
Hi,
mit Attribut "do always" mal versucht?
Bis denn
SouzA
Zitat von: SouzA am 29 Juni 2021, 09:25:00
mit Attribut "do always" mal versucht?
ist doch gesetzt.
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 set MQTT2_shelly1_E8DB84D245AD on-for-timer 300
über die Befehlszeile eingibst?
evtl fehlt im Shelly ja das Attribut "setExtensions 1"???
Zitat von: Frank_Huber am 29 Juni 2021, 10:16:46
ist doch gesetzt.
Stimmt, du hast Recht!
Wenn man mal bis zum Ende scrollt...^^
Bis denn
SouzA
@Frank:
Um 7:57 habe ich es manuell versucht. Pumpe lief aber nicht an.
Zitatset 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.
Zitatevtl 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
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.)
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:
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 Wasserpumpe
Das 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:
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?
Zitat von: bmwfan am 29 Juni 2021, 13:24:23
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.
Zitat
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...
Zitat
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...
Erster Versuch:
Nach einem 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 set MQTT2_shelly1_E8DB84D245AD off
bewirkt sofortiges Ausschalten.
Dritter Versuch:
Nach einem 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.
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)).
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 timestamp-on-change-reading
gestossen. Ich denke das ist es, was Du mit Geschwätzigkeit gemeint hast und habe es gleich egsetzt.
https://wiki.fhem.de/wiki/MQTT2-Module_-_Praxisbeispiele#Vorbemerkung:
http://<ip-des-shelly>/settings?mqtt_update_period=0
FritzBox 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).
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.
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:
Zitat von: bmwfan am 29 Juni 2021, 14:15:25
EDIT: Bin im Zuge Deiens Hinweises auf die Geschwätzigkeit auf das Attribut 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"...
Potentialfrei: Stimmt. Wenn ich ihn auf 230V betreibe muss ich vorher noch prüfen, ob der Wasserstandssensor, der auf dem SW-Eingang liegt, auch 230V abkann. Ganz wohl ist mir dabei nicht, da der ja im Sickerschacht eingebaut ist und, je nachdem wie stark es regnet, völlig unter Wasser steht bis die Pumpe leergepumpt hat. Muss natürlich dicht sein, aber....
Perl-Routine auf relay-Topic: Da hast Du mich abgehängt. Programmierung in Perl werde ich nicht hinbekommen da meine Kenntnisse da gegen 0 gehen.
Man liest auch immer wieder, dass die Shellys über ein eigenes WLAN (SSID und AP) angebunden werden sollten. Bei mir hängt alles an einem WLAN und das sind inzwischen einige Geräte.
OK, Wasser und 230V sind keine gute Kombi...
Da ich WLAN vermeide, wo es geht, kann ich nur bedingt mitreden und mitteilen, dass mein WLAN deutlich stabiler ist, seit ich praktisch alle ESP's (das sind nicht viele, eine gute Handvoll, teils nur zum Testen) über einen dd-wrt-basierten AP laufen habe.
Was Perl-readingList angeht: ist kein Hexenwerk, und das vorliegende ist eigentlich auch ein ganz passables Einsteiger-Projektchen: $NAME und $EVENT übergeben, und schon kannst du mit ein paar Vergleichen gegen aktuelle Readings Aktionen ableiten...
Bei Interesse ggf. ein neues Thema im MQTT-Bereich aufmachen und vorab mal wenigstens versuchen, eine Log-Anweisung zu vercoden, in der diese beiden Parameter sauber übergeben wurden (dazu im Wiki 99_myUtils.pm konsultieren).
Ich setze inzwischen verstärkt auf WLAN-Geräte (Shelly), da ich mit den 868MHz-Geräten immer wieder Probleme hatte, speziell die im Außenbereich. Habe auch inzwischen überall (CUL, HMUARTLGW) externe Antennen eingesetzt, womit die Signalstärke deutlich besser wurde. Trotzdem habe ich noch Device im Haus mit einem RSSI von fast -70, die im Außenbereich gehen auf -80.
Welchen AP benutzt du? Ich würde mal testen, ob ich damit eine Verbesserung zur Fritzbox erhalte.
Perl-Programmierung. Schaue ich mir mal an, ob ich klarkomme und mache ggf. im MQTT-Bereich ein neues Thema auf.
Besten Dank für die Hilfe.
Zitat von: bmwfan am 29 Juni 2021, 17:51:28
Ich setze inzwischen [...]
Was wichtig ist, geht bei mir nach ZWave, WLAN braucht mir zu viel Infrastruktur, ich will alles von einem USB-Stick aus erreichen können...
Zitat
Welchen AP benutzt du?
Netgear R7000 mit dd-wrt (also nicht mehr unbedingt das neueste Gerät und damit auch nicht mehr zur Nachahmung empfohlen; würde heute eher was nehmen, das openwrt kann).
Aber die Erfahrung lehrt: alles andere ist besser als "Fritte"...
Habe einen Cisco-Router WRT160L, den ich noch hatte, mit anderer SSID installiert. RSSI-Signalstärke ist zwar nicht stärker als mit der 7490, aber mal sehen ob die Befehle besser durchkommen.
Hat gar nichts gebracht! War einige Tage weg und aus meinem Freisitz ist ein Pool geworden. Sämtliche Elektrokomponenten unter Wasser. Werde zuerst den Shelly separat versorgen. Mal sehen ob das was bringt. Wenn nicht: Schritt für Schritt vorgehen.
Ups, das hört sich nicht lustig an, tut mir leid, dass der andere AP da keine Besserung gebracht hat!
Vielleicht eine Anmerkung: Wenn Ausfälle solche Auswirkungen haben und die (Funk-) Verbindung dann zudem noch so schlecht ist, solltest du darüber nachdenken, an der Stelle ein teilautonomes System aufzubauen. Weiß nicht, ob es bei dem Shelly sowas wie "rules" (bei Tasmota oder ESPEasy) gibt, jedenfalls würde ich das Ding selbständig entscheiden lassen, ob jetzt die Pumpe angeschaltet werden muss oder nicht. Ergo muss da ein passender Sensor ran (oder mehrere). FHEM bekommt dann nur mitgeteilt, _was_ der "erweiterte Aktor" dann gemacht hat, bzw. wie der Status ist und kann dann ggf. wieder ausschalten (bzw. versuchen, das zu tun...).
Meine Lösung wäre vermutlich mit einer MySensors-Node (incl. "starkem" Funkmodul), aber an der Stelle gilt: viele Wege führen nach Rom.
Hatte dieselbe Idee, aber bisher noch keine Einstellung im Shelly gefunden, die auch bei ständig anliegendem SW-Eingang wiederholt den Ausgang schaltet und dazwischen eine eingestellte Zeit abwartet. Die Pumpe darf max. 15 Min. laufen und soll dann laut Hersteller 15 Min ausgeschaltet bleiben. Ist der Wasserstand trotz laufender Pumpe (Starkregen wie gestern) aber zu hoch, bringt der Sensor dauerhaft eine 1 und der Trigger fehlt. Deswegen wollte ich mit einer Logik in FHEM das Problem lösen, aber da kam mir dann die schlechte WLAN-Verbindung dazwischen.
Muß ich vielleicht mal im Shelly-Forum nachfragen, ob man mit der Standard-Software so etwas machen kann. Ansonsten muss ich schauen, ob man einen Shelly1 auf Tasmota flashen kann und ob da dann solch eine Funktion möglich ist.
Danke für die Tipps.
Grüße Jürgen
Bin inzwischen etwas weiter in meiner Problemlösung, die Pumpe geht aber leider immer noch nicht. :(
Die WLAN-Abdeckung ist jetzt mit einem zusätzlichen Repeater auf der Terrasse in Ordnung (RSSI von -60 .. -68)
Shelly hat einen eigenen AC/DC-Wandler (Traco, 3W) bekommen und arbeitet jetzt tadellos.
Leider hat die kleine Pumpe (Dauerstrom laut Datenblatt 1,5A) einen so hohen Anlaufstrom, dass das 6,5A-Netzteil aussteigt und die Pumpe nur noch taktet. Habe jetzt Teile für eine Anlaufstrombegrenzung bestellt. Mal sehen, ob es dann funktioniert. Alternative wäre ein noch stärkeres Netzteil (aber wie stark denn noch?) oder ein Umstieg auf eine 24 V-Pumpe und 24V-Netzteil, was sicher die teuerste Lösung wäre)