DOIF zur Pumpensteuerung mit on-for-timer geht nicht

Begonnen von bmwfan, 29 Juni 2021, 08:18:05

Vorheriges Thema - Nächstes Thema

bmwfan

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.
Synology DS720+ mit Docker-Container und Haupt-FHEM, HW-LAN, Jalousienaktoren; Raspi 3B+ mit piVCCU ohne FHEM-Instanz, CUL, JeeLink; Raspi 3B+ mit FHEM und HMUARTUSB,  Raspi 3B+ mit HMUARTGPIO, 1-wire, ebusd

Beta-User

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).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

bmwfan

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.
Synology DS720+ mit Docker-Container und Haupt-FHEM, HW-LAN, Jalousienaktoren; Raspi 3B+ mit piVCCU ohne FHEM-Instanz, CUL, JeeLink; Raspi 3B+ mit FHEM und HMUARTUSB,  Raspi 3B+ mit HMUARTGPIO, 1-wire, ebusd

Beta-User

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"...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

bmwfan

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.
Synology DS720+ mit Docker-Container und Haupt-FHEM, HW-LAN, Jalousienaktoren; Raspi 3B+ mit piVCCU ohne FHEM-Instanz, CUL, JeeLink; Raspi 3B+ mit FHEM und HMUARTUSB,  Raspi 3B+ mit HMUARTGPIO, 1-wire, ebusd

bmwfan

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.
Synology DS720+ mit Docker-Container und Haupt-FHEM, HW-LAN, Jalousienaktoren; Raspi 3B+ mit piVCCU ohne FHEM-Instanz, CUL, JeeLink; Raspi 3B+ mit FHEM und HMUARTUSB,  Raspi 3B+ mit HMUARTGPIO, 1-wire, ebusd

Beta-User

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.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

bmwfan

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
Synology DS720+ mit Docker-Container und Haupt-FHEM, HW-LAN, Jalousienaktoren; Raspi 3B+ mit piVCCU ohne FHEM-Instanz, CUL, JeeLink; Raspi 3B+ mit FHEM und HMUARTUSB,  Raspi 3B+ mit HMUARTGPIO, 1-wire, ebusd

bmwfan

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)
Synology DS720+ mit Docker-Container und Haupt-FHEM, HW-LAN, Jalousienaktoren; Raspi 3B+ mit piVCCU ohne FHEM-Instanz, CUL, JeeLink; Raspi 3B+ mit FHEM und HMUARTUSB,  Raspi 3B+ mit HMUARTGPIO, 1-wire, ebusd