DOIF Taster zum umschalten

[Frank_Huber]

Das zweite cmd ist deine Bedingung.
Bei DOELSE wird jede klammer als Befehl ausgewertet.

Was meinst du mit dem anderen Taster?
Versuche doch mal mit DOELSEIF, und wenn du denkst da ist was faul poste ein list im fehlerstatus.

Gesendet von meinem Doogee S60 mit Tapatalk

[Dersch]

Ich probiere aus. DOELSEIF aber mit do always? Denn er soll es ja wieder ausführen wenn die Bedingung wiederholt wahr wird?

[Ellert]

Tasten prellen sollte im Bereich von Millisekunden liegen, bei 2 Sekunden ist was faul.

und

Code Auswählen Erweitern

([GarageTasterTorHoch:"on"] and $cmd==1) (set GarageTorHoch off) wird nach DOELSE als Sequenz interpretiert, weil es keine Bedigung sein kann.

[Frank_Huber]

Ich probiere aus. DOELSEIF aber mit do always? Denn er soll es ja wieder ausführen wenn die Bedingung wiederholt wahr wird?

Dürfte bei dem doif egal sein weil die zweige ja eh nur abwechselnd auslösen können.

Gesendet von meinem Doogee S60 mit Tapatalk

[Frank_Huber]

Tasten prellen sollte im Bereich von Millisekunden liegen, bei 2 Sekunden ist was faul.

2sec ist halt das minimum das im Doif richtig funktioniert.

Wenn du debounce auf 100ms stellst schaltet das Licht auch 100ms verzögert an.
Da war der WAF sehr tief.
Über das "entprellen" im Doif geht alles tadellos.



Gesendet von meinem Doogee S60 mit Tapatalk

[Dersch]

Wegen dem Prellen mache ich mir grade noch Gedanken. Ich habe bisher bei RPI_GPIO als Interrupt immer "both" verwendet. Warum kann ich eigentlich gar nicht sagen, wahrscheinlich nur im Bedarf die Option von Longpress nutzen zu können, ein weiterer Sinn fällt mir nicht ein. Aber ist es nicht einfach besser Rising bzw Falling zu verwenden und damit auch nur die Flanke auswerten wenn Longpress gar nicht gebraucht wird? Oder denke ich da falsch?

[Ellert]

2sec ist halt das minimum das im Doif richtig funktioniert.

Bei mir funktionieren im DOIF auch Timer < 1s zum Trennen von Sequenzen (Pi 2B), insofern ist die Verallgemeinerung falsch.

Wenn du debounce auf 100ms stellst schaltet das Licht auch 100ms verzögert an.

Sinn des Entprellen ist es, erst dann einen Zustand zu signalisieren, wenn sicher ist das der Zustand stabil ist, dabei ist eine Verzögerung unabdingbar.

Aber ist es nicht einfach besser Rising bzw Falling zu verwenden und damit auch nur die Flanke auswerten

Das würde sozusagen die Prellfrequenz halbieren, aber nicht verhindern.
Ich würde mir den die Schaltevents im Eventmonitor ansehen (mit gesetztem mseclogAttribut), die Prellhäufigkeit/zeit ansehen und dann debounce setzen.
Es ist immer besser Störungen möglichst früh auszuschalten, als unnötige Events durchs System zu jagen.

[Frank_Huber]

Bei mir funktionieren im DOIF auch Timer < 1s zum Trennen von Sequenzen (Pi 2B), insofern ist die Verallgemeinerung falsch.
Sinn des Entprellen ist es, erst dann einen Zustand zu signalisieren, wenn sicher ist das der Zustand stabil ist, dabei ist eine Verzögerung unabdingbar.
Das würde sozusagen die Prellfrequenz halbieren, aber nicht verhindern.
Ich würde mir den die Schaltevents im Eventmonitor ansehen (mit gesetztem mseclogAttribut), die Prellhäufigkeit/zeit ansehen und dann debounce setzen.
Es ist immer besser Störungen möglichst früh auszuschalten, als unnötige Events durchs System zu jagen.

Hi,

Es geht nicht um timer allgemein sondern um das Attribut cmdpause.
Im oben verlinkten Thema ist nachzulesen warum.

Klar ist ein eliminieren so weit vorne wie möglich besser,
Verzögert aber eben alles nachgelagerte.
Da muss man eben abwägen was das kleinere Übel ist. [emoji6]

Gesendet von meinem Doogee S60 mit Tapatalk

[Ellert]

Das Beispiel aus dem Wiki wird über Dummy geschaltet die Prellen nicht, daher muss es angepasst werden. Wenn tatsächlich 2 s das praktische Minimum für cmdpause sind, dann würde ich es mit wait lösen

Code Auswählen Erweitern

([GarageTasterTorHoch] eq "on" and [$SELF] =~"initialized|^cmd_2)\$" (setreading doifGarageTor Tor Hoch)
DOELSEIF
([GarageTasterTorHoch] eq "on" and [$SELF]  eq "cmd_1") (set GarageTorHoch off)

und

wait x:x mit x etwas länger als die längste Prellzeit

Funktionsweise: Der Befehl wird erst nach der Prellzeit ausgeführt und erst dann kann in einen anderen Zweig geschaltet werden

[Frank_Huber]

Da wird aber wieder der Befehl verzögert.
Was spricht denn gegen die 2sec?
Wenn ich Licht anschalte will ich es ja nicht nach ner halben wieder ausschalten.
Viel mehr will ich dass es direkt mit dem Tastendruck angeht.

Je nach Einsatzzweck mag es auch mit wait Sinn machen, Klar.

Gesendet von meinem Doogee S60 mit Tapatalk

[Dersch]

Es klappt auch mit Umstellung auf DOELSEIF leider nicht.

Ist das Tor oben (nicht mit Taster nach oben gefahren) und drücke ich den Taster für Runter, lasse einen Moment fahren und drücke erneut den Taster Runter für Stop springt das DOIF des Tasters für Hoch auf cmd1 und das Tor fährt wieder hoch.

Es gibt doch aber gar nichts was das DOIF für den Taster triggern könnte außer der Taster selbst?

[Ellert]

@Frank_Huber
Du sprichst von Licht, hier geht es um ein Garagentor, das springt nicht auf Tastendruck auf oder zu, da sind 100 ms nix. 2 s können für einen Notstop/Richtungsumkehr
schon zu lang sein.
Es hängt vom Einsatzzweck, wie Du es sagst.

[Ellert]

Es klappt auch mit Umstellung auf DOELSEIF leider nicht.

Ist das Tor oben (nicht mit Taster nach oben gefahren) und drücke ich den Taster für Runter, lasse einen Moment fahren und drücke erneut den Taster Runter für Stop springt das DOIF des Tasters für Hoch auf cmd1 und das Tor fährt wieder hoch.

Es gibt doch aber gar nichts was das DOIF für den Taster triggern könnte außer der Taster selbst?

Wie soll das DOIF erraten, das Du das Tor manuell bedient hast, das musst Du in den Bedingungen zusätzlich implementieren.

[Frank_Huber]

Wie ist denn das Gesamtkonstrukt des Garagentors?
Wäre nicht evtl das Rollo Modul eine Idee für dich?
Poste doch mal von allem ein List nachdem der Fehler aufgetreten ist.


@Ellert,
Ja da hast du recht.
Mit cmdpause kann es alles zwischen 1,01 und 2,99 sec sein.
Mit wait kann man es gezielt auf 0,1 sec stellen.
Aber eben dann immer verzögert anstatt sofort geschalten.



Gesendet von meinem Doogee S60 mit Tapatalk

[Frank_Huber]

Es klappt auch mit Umstellung auf DOELSEIF leider nicht.

Ist das Tor oben (nicht mit Taster nach oben gefahren) und drücke ich den Taster für Runter, lasse einen Moment fahren und drücke erneut den Taster Runter für Stop springt das DOIF des Tasters für Hoch auf cmd1 und das Tor fährt wieder hoch.

Es gibt doch aber gar nichts was das DOIF für den Taster triggern könnte außer der Taster selbst?

Beobachte mal im event monitor deine gpio.
Könnte es sein dass der zweite mit triggert?

Falls ja:
Hast du pull up /pull down Widerstände verbaut?
Wie lange sind die Kabel?

Gesendet von meinem Doogee S60 mit Tapatalk