Hallo zusammen,
ich bin seit gestern neu in dem Thema Fhem und arbeite grade an einer Steuerung mit einem Pi4 welche diverse Pumpen steuert.
Die Relais incl den zugehörigen (Hardware-)Tastern funktionieren bereits hervorragend.
Dazu gehört auch ein Wasserstandssensor.
Dieser wird einfach quick and dirty über den GPIO25 realisiert.
... ich weiß, ich weiß... ich habe aber schon einige Varianten des Wasserstandssensors durch und was gleich folgt ist für mich wahrscheinlich die beste Lösung.
So soll das funktionieren:
GPIO ist standartmäßig low. Alle 2 Sekunden soll er kurz angezogen werden und Durchgang getestet werden. Ist Durchgang vorhanden ist alles gut und die schleife geht von vorne los. Durch diese lange Low Periode und das extrem kurze anziehen vermeide ich (wahrscheinlich) die gleichstrombedingte Korrosion an den im Wasser liegenden kontakten.
Sollte jetzt aber kein Durchgang für länger als 1 Sekunde vorhanden sein bleibt der pin so lange angezogen bis wieder Kontakt für >1Sekunde da ist. Innerhalb dieses Zeitraumes sollen sämtliche Devices abgeschaltet werden und ein Dummy mit der Meldung "wasserstand OK / zu niedrig" geswitcht werden.
Bei meiner Recherche bin ich auf den Watchdog gestossen, aber die Syntax um mein vorhaben umzusetzen überfordert mich maßlos...
Bin für jeden Ansatz dankbar.
VG
Du schreibst was du gemacht hast und was du erwartest. Was ist nun deine Frage bzw. das genaue Problem? Hast du Logs, Fehlermeldugen, fehlt was in der Config? Was hast du schon getestet?
ok, sorry, war vielleicht nicht ganz eindeutig.
Ich weiss nicht wie ich die Syntax aufbauen soll.
Sowas in der Richtung stelle ich mir vor:
Loop alle 2 Sekunden
Setze GPIO25 auf High
Prüfe GPIO25 auf Durchgang
Wenn kein Durchgang für mehr als 1 Sek dann
Führe Befehl <alles ausschalten, switch Meldung, sperre alle Automatismen> aus, wenn nach Ereignis <Gpio 25 zieht an > nicht
innerhalb der Zeitspanne <1 Sek> das Ereignis <Gpio 25 hat Durchgang> auftritt.
Führe Befehl < switch Meldung, entsperre alle Automatismen, Setze GPIO25 auf low > aus, wenn nach Ereignis <letzter Watchdog hat
abgeschaltet > das Ereignis <Gpio 25 hat für mehr als 1 Sek Durchgang> auftritt.
Sonst
Setze GPIO25 auf low
Loop
Willkommen im Forum.
Aber watchdog als FHEM-device ist Dir schon klar ? :-\ Die commandref dazu studiert ? Wenn Du uns noch Deine FHEM-devices nennst, findet sich bestimmt auch jemand, der es Dir ggfs. definiert.
ZitatGPIO ist standartmäßig low. Alle 2 Sekunden soll er kurz angezogen werden und Durchgang getestet werden.
Da wär ich vorsichtig. Ich hab etwas ähnliches als Leckage-Detektor. Wenn dann ein
bedeutender Strom fließt, zieht das die Stromversorgung des Pi arg in Mitleidenschaft(ich merke das dann an meinem 1W-GPIO4-Bus, der nicht mehr sauber funktioniert). Die "Durchgangsprüfung" machst Du dann über Input an einem weiteren GPIO ?
Grüße Markus
Zitat von: SNX100 am 15 Oktober 2021, 12:30:25
Loop alle 2 Sekunden
Du willst alle 2 Sekunden anziehen damit du keine Korrosion an den Kontakten hast? Ich verstehe die Anforderung nicht. Ich sehe hier das Problem, dass du durch die hochfrequente Prüfung und Aktionen dein fhem blockiert wird.
Wenn die 2 Sekunden wirklich nötig sind, würde ich ggf. die Logik in ein Script auf dem Betriebssystem auslagern. Und das Script schreibt ein Log- oder Statusfile das du in Fhem nur auswertest.
Hier schonmal mein Aufbau bis jetzt falls das hilft...
define Sonnenaufgang dummy
setuuid Sonnenaufgang 61683b9a-f33f-a4e8-8e5c-6c165e562af1cdfb
attr Sonnenaufgang room Start
define Sonnenuntergang dummy
setuuid Sonnenuntergang 61683b9a-f33f-a4e8-b301-2ec31f011838a389
attr Sonnenuntergang room Start
define sun_riseSet_timer at *00:05:00 { my $s = sunrise_abs();; fhem("set Sonnenaufgang $s");; $s = sunset_abs();; fhem("set Sonnenuntergang $s");; }
setuuid sun_riseSet_timer 61683c1b-f33f-a4e8-8309-61ba0f9c3f06cc46
define Datum dummy
setuuid Datum 61683e44-f33f-a4e8-8aec-0a75c6d997c6af58
attr Datum room Start
define at_fp_date at +*00:30:00 { fhem 'set fp_date '.strftime('%d. %B', localtime) }
setuuid at_fp_date 61683e44-f33f-a4e8-c435-8637a30680de9cad
define Uhrzeit dummy
setuuid Uhrzeit 61683e44-f33f-a4e8-fda6-12e7e4fbe96f41a4
attr Uhrzeit room Start
define at_fp_time at +*00:00:10 { fhem 'set fp_time '.strftime('%H:%M', localtime) }
setuuid at_fp_time 61683e44-f33f-a4e8-5322-211165822405c377
define Jet1 RPI_GPIO 13
setuuid Jet1 61684155-f33f-a4e8-7165-88e6ce0e86702321
attr Jet1 active_low yes
attr Jet1 direction output
attr Jet1 room Start
attr Jet1 webCmd toggle
define Jet2 RPI_GPIO 16
setuuid Jet2 6168415a-f33f-a4e8-bebe-3ba0cc8248409051
attr Jet2 active_low yes
attr Jet2 direction output
attr Jet2 room Start
attr Jet2 webCmd toggle
define Licht RPI_GPIO 19
setuuid Licht 6168415f-f33f-a4e8-c43a-9d1d349056fc7291
attr Licht active_low yes
attr Licht direction output
attr Licht room Start
attr Licht webCmd toggle
define Relais6 RPI_GPIO 20
setuuid Relais6 61684164-f33f-a4e8-11b4-37edfd19e3b9bed7
attr Relais6 active_low yes
attr Relais6 direction output
attr Relais6 room Start
attr Relais6 webCmd toggle
define Relais7 RPI_GPIO 21
setuuid Relais7 61684169-f33f-a4e8-5f69-a88331f3c19fc239
attr Relais7 active_low yes
attr Relais7 direction output
attr Relais7 room Start
attr Relais7 webCmd toggle
define Heizung RPI_GPIO 26
setuuid Heizung 6168418a-f33f-a4e8-095d-c67065919c95f17f
attr Heizung active_low yes
attr Heizung direction output
attr Heizung room Start
attr Heizung webCmd toggle
define Zirkulation RPI_GPIO 5
setuuid Zirkulation 6168460e-f33f-a4e8-e9dd-326201a9084e1a62
attr Zirkulation active_low yes
attr Zirkulation direction output
attr Zirkulation room Start
attr Zirkulation webCmd toggle
define Luftpumpe RPI_GPIO 6
setuuid Luftpumpe 6168460e-f33f-a4e8-c316-aa1ac9950ca46dd4
attr Luftpumpe active_low yes
attr Luftpumpe direction output
attr Luftpumpe room Start
attr Luftpumpe webCmd toggle
define Taster1 RPI_GPIO 17
setuuid Taster1 616890a3-f33f-a4e8-1841-d98fa93f1ef38194
attr Taster1 debounce_in_ms 150
attr Taster1 direction input
attr Taster1 interrupt both
attr Taster1 pud_resistor down
define Taster2 RPI_GPIO 27
setuuid Taster2 616890a3-f33f-a4e8-81d8-e6aa576c7b3b45a3
attr Taster2 debounce_in_ms 150
attr Taster2 direction input
attr Taster2 interrupt both
attr Taster2 pud_resistor down
define Taster3 RPI_GPIO 22
setuuid Taster3 616890a3-f33f-a4e8-f97a-99b5fe1387025d7a
attr Taster3 debounce_in_ms 150
attr Taster3 direction input
attr Taster3 interrupt both
attr Taster3 pud_resistor down
define Taster4 RPI_GPIO 23
setuuid Taster4 616890a3-f33f-a4e8-1978-cac4172e49db2bec
attr Taster4 debounce_in_ms 150
attr Taster4 direction input
attr Taster4 interrupt both
attr Taster4 pud_resistor down
define Taster5 RPI_GPIO 24
setuuid Taster5 616890a3-f33f-a4e8-43e5-3d85302f43ddfb30
attr Taster5 debounce_in_ms 150
attr Taster5 direction input
attr Taster5 interrupt both
attr Taster5 pud_resistor down
define Taster1_Notify notify Taster1 {if ( Value("Luftpumpe") eq "on") {fhem("set Luftpumpe off")} else {fhem("set Luftpumpe on")}}
setuuid Taster1_Notify 61689371-f33f-a4e8-0146-131661d44f9500d9
define Taster2_Notify notify Taster2 {if ( Value("Jet1") eq "on") {fhem("set Jet1 off")} else {fhem("set Jet1 on")}}
setuuid Taster2_Notify 61689371-f33f-a4e8-9c9b-e2e840f0764e0a63
define Taster3_Notify notify Taster3 {if ( Value("Jet2") eq "on") {fhem("set Jet2 off")} else {fhem("set Jet2 on")}}
setuuid Taster3_Notify 61689371-f33f-a4e8-bdab-d5d8002c28a90cbb
define Taster4_Notify notify Taster4 {if ( Value("Licht") eq "on") {fhem("set Licht off")} else {fhem("set Licht on")}}
setuuid Taster4_Notify 61689371-f33f-a4e8-661c-ea2eee4c9bbe8f40
define Taster5_Notify notify Taster5 {if ( Value("Heizung") eq "on") {fhem("set Heizung off")} else {fhem("set Heizung on")}}
setuuid Taster5_Notify 61689371-f33f-a4e8-5369-ecfdf246f87ac37e
Zitat von: KölnSolar am 15 Oktober 2021, 13:05:43
Willkommen im Forum.
Aber watchdog als FHEM-device ist Dir schon klar ? :-\ Die commandref dazu studiert ? Wenn Du uns noch Deine FHEM-devices nennst, findet sich bestimmt auch jemand, der es Dir ggfs. definiert.
Da wär ich vorsichtig. Ich hab etwas ähnliches als Leckage-Detektor. Wenn dann ein bedeutender Strom fließt, zieht das die Stromversorgung des Pi arg in Mitleidenschaft(ich merke das dann an meinem 1W-GPIO4-Bus, der nicht mehr sauber funktioniert). Die "Durchgangsprüfung" machst Du dann über Input an einem weiteren GPIO ?
Grüße Markus
Meine Vorstellung war (korrigiere mich) 2 Devices in der Schleife oder ist das schon grundsätzlich falsch?
1W-GPIO4-Bus mit ds18b20 kommt gleich noch im Anschluss... wird vermutlich meine nächste Fragestellung.
Die Durchgangsprüfung wäre Aufbaumäßig identisch zu den o.g. Tastern. Taster sind gegen 3,3V, Durchgang wäre gegen GND
Zitat von: kadettilac89 am 15 Oktober 2021, 13:44:21
Du willst alle 2 Sekunden anziehen damit du keine Korrosion an den Kontakten hast? Ich verstehe die Anforderung nicht. Ich sehe hier das Problem, dass du durch die hochfrequente Prüfung und Aktionen dein fhem blockiert wird.
Wenn die 2 Sekunden wirklich nötig sind, würde ich ggf. die Logik in ein Script auf dem Betriebssystem auslagern. Und das Script schreibt ein Log- oder Statusfile das du in Fhem nur auswertest.
Bei dem alten System hatte ich einen dauerhaften Durchgang welcher sehr schnell zur Korrosion ger
V4A Kontakte geführt hat...
Hab halt mit Elektrik so viel nicht am Hut daher bitte nicht lachen...
Als ich dann rausgefunden habe woran das liegt habe ich einen Wandler auf Rechtecksignal dazwischen gepackt. Wurde zwar etwas besser aber noch nicht perfekt.
Daher möchte ich so selten wie möglich diesen Test durchführen um die Kontakte nicht weiter zu belasten. 2 Sekunden ist aber schon so ziemlich das max weil danach schon eine Pumpe trocken läuft.
Im alten aufbau hatte ich tatsächlich die Abfrage über das BS gelöst und in eine abzufragende Variable ausgegeben, aber diesen Umweg dachte ich könnte ich nach Möglichkeit im neuen Setup vermeiden.
ZitatMeine Vorstellung war (korrigiere mich) 2 Devices in der Schleife oder ist das schon grundsätzlich falsch?
Falsch ist der falsche ::) Ausdruck. Ich wollte nur das Thema sensibilisieren, dass man sich auch recht schnell die GPIOs zerschießen kann, wenn sie zu hoch belastet werden. Ich bin da aber zu wenig Fachmann, ob ein "Kurzschluss" zwischen 2 GPIOs zu Problemen führen könnte.
ZitatHier schonmal mein Aufbau bis jetzt falls das hilft...
Ich meinte nicht den uninteressanten Rest, sondern die (beiden ?) GPIOs und den Mechanismus, der GPIO25 alle 2s auf high setzt. ;)
Ähmm,
ZitatDie Durchgangsprüfung wäre Aufbaumäßig identisch zu den o.g. Tastern. Taster sind gegen 3,3V, Durchgang wäre gegen GND
Also nicht 2 GPIOs ? Du kannst ja nicht einerseits GPIO25 auf high setzen(output) u. irgendwie :-\ messen(input), dass er auf low(GND) ist. Oder hab ich da gerade einen Denkfehler ?
Edit: Wenn Du 1W-GPIO4 machen willst, suchst Du Dir am besten meine aktuellste Version, die an irgendeinem Thread hängt(Suchworte: GPIO4 DHT22).
Ich kenne Deine Anforderung "Wasserstandssensor" nicht wirklich, aber darf ich mal "Ultraschallsensor" in den Raum werfen? Wäre eine berührungslose Variante.
Das gibts von ganz preiswert zum basteln oder halt etwas teurer dann im wasserdichten Gehäuse. Ich hab sowas in meiner Zisterne jetzt seit > 10 Jahren hängen und noch NIE einen Ausfall. Je nach Anbindung an den raspi würdest Du halt "distanzen" gemeldet bekommen und könntest für Wasserstände zum Pumpen direkt mit Hysterese arbeiten.
Aber wie gesagt, das kommt auf Deine Anforderungen an.
Gruß
Sany
P.S. oder ein Schwimmerschalter, ist auch nicht "elektrisch" mit dem Wasser verbunden.
Zitat von: KölnSolar am 15 Oktober 2021, 14:07:48
Falsch ist der falsche ::) Ausdruck. Ich wollte nur das Thema sensibilisieren, dass man sich auch recht schnell die GPIOs zerschießen kann, wenn sie zu hoch belastet werden. Ich bin da aber zu wenig Fachmann, ob ein "Kurzschluss" zwischen 2 GPIOs zu Problemen führen könnte.
Geht immer zwischen gpio und gnd bzw 3,3v. daher save.
Zitat von: KölnSolar am 15 Oktober 2021, 14:07:48der GPIO25 alle 2s auf high setzt. ;)
Softwareschleife
Zitat von: KölnSolar am 15 Oktober 2021, 14:07:48high setzen(output) u. irgendwie :-\ messen(input), dass er auf low(GND) ist. Oder hab ich da gerade einen Denkfehler ?
So wie beim Taster
Zitat von: Sany am 15 Oktober 2021, 14:48:53
Ich kenne Deine Anforderung "Wasserstandssensor" nicht wirklich, aber darf ich mal "Ultraschallsensor" in den Raum werfen? Wäre eine berührungslose Variante.
Das gibts von ganz preiswert zum basteln oder halt etwas teurer dann im wasserdichten Gehäuse. Ich hab sowas in meiner Zisterne jetzt seit > 10 Jahren hängen und noch NIE einen Ausfall. Je nach Anbindung an den raspi würdest Du halt "distanzen" gemeldet bekommen und könntest für Wasserstände zum Pumpen direkt mit Hysterese arbeiten.
Aber wie gesagt, das kommt auf Deine Anforderungen an.
Gruß
Sany
P.S. oder ein Schwimmerschalter, ist auch nicht "elektrisch" mit dem Wasser verbunden.
Whirlpool... daher scheidet Distanzmessung aus
Zitat von: SNX100 am 15 Oktober 2021, 17:11:19
Whirlpool... daher scheidet Distanzmessung aus
Die Möglichkeit deine Anforderung per Script zu lösen steht immer noch im Raum.
Wenn du was von anderen Forenteilnehmern nutzen oder einfließen lassen willst - was ist dein Anwendungsfall. Du hast einen Whirlpool und eine Pumpe die nicht trocken laufen soll. Warum musst du die Pumpe selber steuern wenn das Wasser aus ist? Gibt es dazu nichts vom Hersteller?
Vielleicht Spaßbremse, wie sieht es die Versicherung wenn du hier mit Strom hantierst, oder Wasserschäden durch selbstgebastelte Lösungen nicht verhindern konntest ...
Zitat von: kadettilac89 am 15 Oktober 2021, 18:08:29
Die Möglichkeit deine Anforderung per Script zu lösen steht immer noch im Raum.
Wollte ich nach Möglichkeit umgehen wenns in fhem machbar ist
Zitat von: kadettilac89 am 15 Oktober 2021, 18:08:29
Wenn du was von anderen Forenteilnehmern nutzen oder einfließen lassen willst - was ist dein Anwendungsfall. Du hast einen Whirlpool und eine Pumpe die nicht trocken laufen soll. Warum musst du die Pumpe selber steuern wenn das Wasser aus ist? Gibt es dazu nichts vom Hersteller?
Kompletter Eigenbau. Hersteller bin also ich :-) Zum Verständnis: Der Whirlpool heizt automatisch. Das funktioniert mit der selben Pumpe wie die Filtration. Sollte der Wasserstand zu niedrig sein darf weder die Pumpe noch die Heizung anspringen.
Zitat von: kadettilac89 am 15 Oktober 2021, 18:08:29
Vielleicht Spaßbremse, wie sieht es die Versicherung wenn du hier mit Strom hantierst, oder Wasserschäden durch selbstgebastelte Lösungen nicht verhindern konntest ...
Alles save hinter IP67. im schlimmsten Fall fliegt ein eigener FI. Wasserschäden ausgeschlossen da im Garten.
Irgendwo hier haben wir einen Tread, wo es um Wasserstandmessung ging. Da wurde sogar einfach mal Schwimmschalter angesprochen ....
Kann jemand folgendes zu was brauchbarem verwandeln?
define Wasserstandssensor RPI_GPIO 25
attr Wasserstandssensor direction input
attr Wasserstandssensor interrupt rising
attr Wasserstandssensor pud_resistor down
attr Wasserstandssensor debounce_in_ms 100
define Wassertestschleife at +*00:00:02 gpio high setzten, {if(ReadingsVal(' Wasserstandssensor', kein Durchgang) {starte den Watchdog} else {gpio low setzen}}
define wd_Wasserstand watchdog
Wasserstandssensor:opened.* 00:00:03 Wasserstandssensor:closed.* abschalten der Pumpen;; trigger wd_Wasserstand
ich bleibe dabei, dass es nicht optimal ist, und du ggf. fhem blockierst wenn du alle 2 Sekunden prüfst. Aber jeder ist seines Glückes Schmied.
Es funktioniert vermutlich einfach mit einem at und einem notify.
Annahmen, ich habe keinen Raspberry, musst du prüfen ... ggf. sind meine Annahmen falsch.
Dein Device heißt dem List nach Wasserstandssensor
Setzen des GPIO auf "on" somit per:
set Wasserstandssensor on
Setzen des GPIO auf "off" per:
set Wassersstandssensor off
Durchgang prüfen per:
get Wasserstandssensor
--> Als Folge wird das Reading "Pinlevel" auf
Durchgang = "high"
kein Durchgang = "low"
Die Logik:
Alle 2 Sekunden wird ein At ausgeführt, dass erst den GPIO auf on setzt und im selben Schritt auch den Durchgang abfragt (und damit das Reading setzt sowie ein Event auslöst)
define at_wasserstand at +*00:00:02 set Wasserstandssensor on ;; get Wasserstanddsensor;;
In einem notify reagierst du auf das Event welches beim setzen vom Reading "Pinlevel" ausgelöst wird. Prüfe im Eventmonitor ein Event zu dem REading Pinlevel auftaucht.
Wenn Durchgang
- Alles OK, nur GPIO auf low setzen
Wenn kein Durchgang
- Meldung, schalten ... was auch immer du auslösen willst
- GPIO wieder auf low setzen
#Durchgang
define ntf_wasserstand_high Wassersstandssensor:Pinlevel:high { set Wasserstandssensor off}
#kein Durchgang
define ntf_wasserstand_low Wassersstandssensor:Pinlevel:low { <<<< deine Aktionenen >>>;; set Wasserstandssensor off}
Ich habe keinen Raspberry, und auch aktuell kein fhem vor mir. Die Definitionen können ggf. geringe Syntaxfehler haben.
Wenn Schalten und gleich setzen zu schnell läuft, ggf. ein sleep mit in das at aufnehmen und eine Sekunden warten.
Damit die Events des Readings auch ausgelöst werden darfst du KEIN event-on-change-reading setzen. Du brauchst auch ein Event wenn sich das Reading nicht geändert hat.
Theoretisch könntest du auch im At den GPIO-Ausgang auf low schalten. Ich vermute aber, dass es im notify minimal verzögert wird und du dir ein weiteres Sleep sparen kannst. Musst du testen ...
Aus irgend einem Grund wird das Notify nicht getriggert beim Wechsel von on/off.
Pin schaltet wie er soll...
Schleife:
+*00:00:10 get Wasserstandssensor ; set Wasserstandssensor on
funktioniert beides
Notify:
Wasserstandssensor:Pinlevel:high set Wasserstandssensor off
passiert gar nichts
Zitat von: SNX100 am 16 Oktober 2021, 11:21:30
Notify:
Wasserstandssensor:Pinlevel:high set Wasserstandssensor off
passiert gar nichts
Wie hast du denn das notify erstellt?
Selber manuell?
Oder per Eventmonitor erstellen lassen?
https://wiki.fhem.de/wiki/Event_monitor
Poste doch wenigestens immer ein vollständiges list und auch mal Ausgaben vom Eventmonitor...
list Devicename
in FHEMWEB-cmd und die Ausgabe dann hier posten...
Gruß, Joachim
define Wassertestschleife at +*00:00:10 get Wasserstandssensor ; set Wasserstandssensor on
define wasserstand_Notify notify Wasserstandssensor:Pinlevel:low set Wasserstandssensor off
2021-10-16 11:32:41 dummy Uhrzeit 11:32
2021-10-16 11:32:41 at at_fp_time Next: 11:32:51
2021-10-16 11:32:41 RPI_GPIO Wasserstandssensor on
2021-10-16 11:32:41 at Wassertestschleife Next: 11:32:51
2021-10-16 11:32:51 dummy Uhrzeit 11:32
2021-10-16 11:32:51 at at_fp_time Next: 11:33:01
2021-10-16 11:32:51 RPI_GPIO Wasserstandssensor on
2021-10-16 11:32:51 at Wassertestschleife Next: 11:33:01
2021-10-16 11:33:01 dummy Uhrzeit 11:33
2021-10-16 11:33:01 at at_fp_time Next: 11:33:11
2021-10-16 11:33:01 RPI_GPIO Wasserstandssensor on
2021-10-16 11:33:01 at Wassertestschleife Next: 11:33:11
Heizung 26
Jet1 13
Jet2 16
Licht 19
Logfile ./log/fhem-%Y-%m.log Logfile
Luftpumpe 6
Relais6 20
Relais7 21
Taster1 17
Taster1_Notify Taster1 {if ( Value("Luftpumpe") eq "on") {fhem("set Luftpumpe off")} else {fhem("set Luftpumpe on")}}
Taster2 27
Taster2_Notify Taster2 {if ( Value("Jet1") eq "on") {fhem("set Jet1 off")} else {fhem("set Jet1 on")}}
Taster3 22
Taster3_Notify Taster3 {if ( Value("Jet2") eq "on") {fhem("set Jet2 off")} else {fhem("set Jet2 on")}}
Taster4 23
Taster4_Notify Taster4 {if ( Value("Licht") eq "on") {fhem("set Licht off")} else {fhem("set Licht on")}}
Taster5 24
Taster5_Notify Taster5 {if ( Value("Heizung") eq "on") {fhem("set Heizung off")} else {fhem("set Heizung on")}}
WEB 8083 global
Wasserstandssensor 25
Wassertestschleife +*00:00:10 get Wasserstandssensor ; set Wasserstandssensor on
Zirkulation 5
at_fp_date +*00:30:00 { fhem 'set Datum '.strftime('%d. %B', localtime) }
at_fp_time +*00:00:10 { fhem 'set Uhrzeit '.strftime('%H:%M', localtime) }
eventTypes ./log/eventTypes.txt
global no definition
initialUsbCheck global:INITIALIZED usb create
sun_riseSet_timer *00:05:00 { my $s = sunrise_abs(); fhem("set Sonnenaufgang $s"); $s = sunset_abs(); fhem("set Sonnenuntergang $s"); }
wasserstand_Notify Wasserstandssensor:Pinlevel:high set Wasserstandssensor off
Wo ist das list von deinem GPIO-Device, von deinem notify und dem dummy?
Das sind defines/Auszüge aus der fhem cfg...
EDIT: es wäre schon hilfreich, wenn du tust/lieferst was man hier braucht um helfen zu können...
Egal, wenn der Auszug aus dem Eventmonitor ist, dann ist doch wohl klar warum das notify nix tut:
Zitat
Wasserstandssensor:Pinlevel:low
vs.
Zitat
2021-10-16 11:32:51 RPI_GPIO Wasserstandssensor on
Hast du das verlinkte Wiki mal gelesen?
Also einfach Eventmonitor auf, Event "erzeugen" (oder warten), Zeile wählen und notify/DOIF/FileLog etc. anlegen lassen...
...und dann anpassen.
EDIT: mal soll auf "high" (also verm. "on"?) was passieren, dann wieder auf "low" (also "off"?). Was nun? Oder verschiedene Dinge (hab zugegebenermassen nicht alles im Detail gelesen 8) )? Dann doch bitte (wie angefragt) lists von deinen aktuellen "Versuchen"... :)
Und das mit dem Ausführen auf System-/OS-Ebene halt ich auch für die bessere Variante. Rückmeldung an fhem nach Ausführung geht doch ganz einfach: telnet, http, ... (gibt im Forum einige Beispiele)
Gruß, Joachim
Zitat von: SNX100 am 16 Oktober 2021, 11:33:25
define Wassertestschleife at +*00:00:10 get Wasserstandssensor ; set Wasserstandssensor on
define wasserstand_Notify notify Wasserstandssensor:Pinlevel:low set Wasserstandssensor off
2021-10-16 11:32:41 dummy Uhrzeit 11:32
2021-10-16 11:32:41 at at_fp_time Next: 11:32:51
2021-10-16 11:32:41 RPI_GPIO Wasserstandssensor on
2021-10-16 11:32:41 at Wassertestschleife Next: 11:32:51
2021-10-16 11:32:51 dummy Uhrzeit 11:32
2021-10-16 11:32:51 at at_fp_time Next: 11:33:01
2021-10-16 11:32:51 RPI_GPIO Wasserstandssensor on
2021-10-16 11:32:51 at Wassertestschleife Next: 11:33:01
2021-10-16 11:33:01 dummy Uhrzeit 11:33
2021-10-16 11:33:01 at at_fp_time Next: 11:33:11
2021-10-16 11:33:01 RPI_GPIO Wasserstandssensor on
2021-10-16 11:33:01 at Wassertestschleife Next: 11:33:11
So schlecht sieht es nicht aus.
1) Die Reihenfolge musst du vertauschen. Erst Set on und dann erst den STatus mit "get" abfragen. Zumindest verstehe ich deine Anforderung so.
2) gib mal die Befehle aus dem AT manuell ein. Und poste dann mal welche Events du siehst. Ich vermisse das Event "Wasserstandssensor Pinlevel high". Das müsste durch den set Befehl erzeugt werden. Wichtig, erst den SET ON Befehlt, dann den GET Befehl.
Dann schaun wir weiter.
Manuell gestartet
set Wasserstandssensor on ; get Wasserstandssensor
Bei physisch kein Durchgang
Event: Current Value for Wasserstandssensor: high
Log: 2021.10.16 12:55:39 3: Wassertestschleife: Current Value for Wasserstandssensor: high
Bei physisch Durchgang
Event: Current Value for Wasserstandssensor: low
Log: 2021.10.16 12:57:19 3: Wassertestschleife: Current Value for Wasserstandssensor: low
Event: Current Value for Wasserstandssensor: high
Event: Current Value for Wasserstandssensor: low
Ok, das sind die Situationen die du auswerten bzw. auf die du reagieren willst? Meine Annahme zumindest. Wobei ich bei Durchgang high erwarten würde, das musst nochmal testen.
Zum sauberen Anlegen des Notify:
Markiere die Zeile im Eventlog und klicke auf den Button "Create/Modify Device". Damit legst du dir für low und für high ein notify an.
Wenn die Befehle manuell gehen muss es auch im AT funktionieren. Ich habe mal ein AT angelegt mit 2 Befehlen, das funktioert. Vielleicht hast du irgend wo ein Sonderzeichen, nicht druckbares Zeichen o. ä.
defmod testat at +*00:00:02 set dy_mn1 on ;; set dy_mn2 on
2021-10-16 13:42:01.650 dummy dy_mn1 on
2021-10-16 13:42:01.658 dummy dy_mn2 on
2021-10-16 13:42:01.666 at testat Next: 13:42:03
2021-10-16 13:42:03.642 dummy dy_mn1 on
2021-10-16 13:42:03.650 dummy dy_mn2 on
2021-10-16 13:42:03.659 at testat Next: 13:42:05
Wow, super....
Danke Leute, es tut sich schon mal ein bisschen was.
Scheint als wären hautsächlich Syntaxfehler schuld gewesen.
Muss morgen mal versuchen die komplette Logik um zusetzten und werde dann auf jeden Fall Rückmeldung (oder Fragen) geben.
Für heute erst noch mal ein ganz dickes Dankeschön und einen schönen Abend.
So... die Abfrage funktioniert soweit und er schaltet wie er soll.
Allerdings fehlt jetzt noch die Möglichkeit eine Mehrfachabfrage zu machen welche bei offenem Kontakt checkt ob der Kontakt länger als 1 Sekunde offen ist. Und erst dann die Relais abschaltet.
Notify:
define Wassertestschleife_notify_1 Wassertestschleife:Next:.*:.*:.* {if (ReadingsVal("Wasserstandssensor","Pinlevel","") eq "low") {fhem("set Heizung on")} else {fhem("set Heizung off")}}
Zitat von: SNX100 am 17 Oktober 2021, 16:48:20
Allerdings fehlt jetzt noch die Möglichkeit eine Mehrfachabfrage zu machen welche bei offenem Kontakt checkt ob der Kontakt länger als 1 Sekunde offen ist. Und erst dann die Relais abschaltet.
das verstehe ich nicht. Losgelöst von den AT und NOTIFY. Wie würdest du das manuell machen? Wann genau willst du 1 Sekunde?
Aktuell
Set Wasserstandssensor on
Get Wasserstandssensor
Set Wasserstandssensor off
Wo willst du was genau prüfen?
So was hier? Was willst du dann mit welchem Status machen?
Set Wasserstandssensor on
Get Wasserstandssensor
<<< 1 Sekunde warten >>>
Get Wasserstanddsensor
Set Wasserstandssensor off
ZitatSo was hier? Was willst du dann mit welchem Status machen?
Set Wasserstandssensor on
Get Wasserstandssensor
<<< 1 Sekunde warten >>>
Get Wasserstanddsensor
Set Wasserstandssensor off
Set Wasserstandssensor on
Get Wasserstandssensor
wenn high
<<< wenn pin high teste 1 sekunde lang mehrfach ob pin high bleibt >>>
ZitatSo was hier? Was willst du dann mit welchem Status machen?
Set Wasserstandssensor on
Get Wasserstandssensor
<<< 1 Sekunde warten >>>
Get Wasserstanddsensor
Set Wasserstandssensor off
Set Wasserstandssensor on
Get Wasserstandssensor
wenn high
teste 1 sekunde lang mehrfach ob pin high bleibt
wenn er high bleibt schalte alles ab
wenn nicht Set Wasserstandssensor off
wenn nicht Set Wasserstandssensor off
mehrfach prüfen wird komplizierter. Da musst du aufpassen, dass fhem / raspberry nicht blockiert. Dann hast du schnell das Monitoring deaktiviert.
Änderung der Logik. Im AT alle Befehle, im Notify nur noch die Fehlersituation Wasserstandssensor ausführen.
"mehrfach" = 3 Prüfungen. Sobald EINE davon fehl schlägt wird die Fehlersituation "high" abgearbeitet.
Alle xxx Sekunden: Pin einschalten, Status abfragen, 0,5 Sekunden warten, Status abfragen, 0,5 Sekunden warten, STatus abfragen, Pin ausschalten.
Sollte einer der 3 Prüfungen fehlschlagen --> notify schaltet ab, oder macht was immer du dann machen willst (die Aktion bei Fehler). Ggf. auch die Prüfung alle 2 Sekunden deaktivieren.
Im Notify brauchst du kein if/else. Du musst nur auf das volle Event reagieren. Du solltest ein Event haben das Pinlevel enthält. Zeig dazu mal die Events die im Eventlog angezeigt werden.
Notify müsste dann in etwa so aussehen ...
define ntf_wasserstand_high Wassersstandssensor:Pinlevel:high <<< fhem Aktion bei Fehler >>>
Im AT alle Befehle verketten
define Wassertestschleife at +*00:00:10 set Wasserstandssensor on ; get Wasserstandssensor ; sleep 0.5 ; get Wasserstandssensor ; sleep 0.5 ; get Wasserstandssensor ; set Wasserstandssensor off
Ich würde sowas überhaupt nicht über FHEM realisieren, sondern über ein abgesetztes Device, z.B. einen Arduino, der über USB an den FHEM-Raspberry angeschlossen ist und KeyValueProtocol-kompatible Werte über Seriell schickt. Erstens blockierst du dir so dein FHEM nicht, zweitens machst du dir deinen Raspberry nicht kaputt, wenn irgendwas mal schief geht (Arduino für 2-5€ vs. Raspberry für das mind. zehnfache). Oder nimmst halt ein ESP und machst das ganze über MQTT, z.B.
Ein Sketch für die erste Version ist ja trivial und für einen ESP könntest du Tasmota etc. benutzen.
Und vorallem sind die IO von Arduino/ESP einfach "sauberer" als vom RasPi ...
Ok, also ich denke mal mit folgender Lösung dürfte man Fhem nicht blockieren....
define Wassertestschleife_notify_1 Wassertestschleife:Next:.*:.*:.* {if (ReadingsVal("Wasserstandssensor","Pinlevel","") eq "low") {fhem("set Wasserstandssensor off")} else <<semiscript: if Pinlevel länger als 2 Sekunden high>> {fhem("set Heizung off")} else {fhem("set Wasserstandssensor off")}}
Die Wassertestschleife wird alle 3 sekunden durchgeführt und läuft ohne Unterbrechung gesteuert durch Bedingungen.
Beim ersten mal checkt das notify den Level. Wenn der lvl low ist ist alles gut und der Wasserstandssensor wird abgeschaltet.
Ein Schleifendurchgang beendet.
Wenn er high ist wird der Wasserstandssensor nicht abgeschaltet. Checkt aber dafür wie lange der lvl bereits high ist.
Bei weniger als 2 sekunden hat er es grade gemerkt und lässt einfach den Wasserstandssensor aktiv... bei länger als 2 Sekunden hat das die vorhergehende Schleife bereits bemerkt und die aktuelle Schleife bestätigt es lediglich.
In dieser Zeit würde schwappendes Wasser für einen Wechsel des Pinlevel zwischen den Abfragen sorgen welcher die High-Zeit definiert und müsste auf jeden fall unter 2 Sekunden liegen. bei zu niedrigem Wasserstand ändert sich der Pinlevel nicht, somit kommt automatisch ein wert knapp unter 3Sekunden raus weil in der vorhergegangenen Schleife bereits erfasst. Und jetzt kommt die "Not-Aus" Funktion (hier "set Heizung off... etc" ).
Müsste nur noch den Semiscript teil übersetzt bekommen...
Falls es noch jemand interessiert... Gelöst habe ich das mittlerweile über einen py Script
#!/usr/bin/python
import time
import RPi.GPIO as GPIO
# Fehler ausschalten
GPIO.setwarnings(False)
# RPi.GPIO Layout verwenden (wie Pin-Nummern)
GPIO.setmode(GPIO.BOARD)
# Pin 32 (GPIO 12) auf Output setzen UEBERGABEPIN
GPIO.setup(32, GPIO.OUT)
# Pin 22 (GPIO 25) auf Output setzen SENSOR
GPIO.setup(22, GPIO.OUT)
# Dauersschleife
while 1:
# Zaehler restetten
deb = 0
# Sensor an
GPIO.setup(22, GPIO.IN, pull_up_down = GPIO.PUD_DOWN)
#print("sensor an")
# Warte 100 ms
time.sleep(0.1)
while GPIO.input(22) == GPIO.LOW:
# Warte 100 ms
time.sleep(0.1)
# Zaehler debounce
deb = deb + 1
#print(deb)
#print(GPIO.input(22))
# wenn Zaehler >= 3 sek
if deb >= 30:
GPIO.setup(32, GPIO.IN)
#print("Uebergabe an")
# Warte 100 ms
time.sleep(0.1)
#Uebergabepin ausschalten wenn Wasser wieder voll
GPIO.setup(32, GPIO.OUT)
#print("Uebergabe aus")
# Sensor aus
GPIO.setup(22, GPIO.OUT)
#print(GPIO.input(22))
Dann muss nurnoch der Übergabe Pin in Fhem abgefragt werden.
Kann man sicher auch anders übergeben, aber das war jetzt quick&dirty.