Auslösen nur bei Falsch

[lessthanmore]

@xadox Nein, im Trigger statt „wurde geändert“ auf „ist kleiner als letztes“ ändern.

[xadox]

Habe ich angepasst. Vielen Dank.

Allerdings verstehe ich dies nicht. Wie kann der Wert hier kleiner sein? Er kann doch entweder "true" oder "false" sein.

[Wal]

@xadox ,
true ist 1
false ist 0
was ist kleiner als 1 ?

[MartinP]

1. Ist der Zustand des Reed-Kontaktes eine Nebenbedingung?
2. Oder wird der Zustand des Reed-Kontaktes im Datenpunkt "Input100" gemeldet, und es soll nur dessen Wechsel von true -> false zu dem Ablauf in der Blockly - Klammer führen?

Die Formulierung des einleitenden Satzes lässt da Interpretationsspielraum:

Ich nutzte einen Reed Kontakt mit Shelly und möchte, dass ein Ereignis nur eintritt wenn der Reed Kontakt "false" liefert

Falls (2) Möglicherweise liegt der Hase ganz woanders im Pfeffer. Reed-Kontakte "prellen" ganz gerne, das heißt der Wechsel von "true" auf "false" ist zuerst nicht stabil, sondern es kommen ein paar "true" Pulse, bevor dauerhaft "false" stehen bleibt...

[xadox]

@wal Von der reinen Logik her verstehe ich das, aber der Reek Kontakt liefert nun mal nicht 0 oder 1 sondern true oder false.
Ist das eine Interne Blockly Funktion, die true und false auch als 0 und 1 interpretiert?

Davon abgesehen hat dies nichts geändert. Das Script löst dennoch bei jeder Zustandsänderung aus.

@MartinP wie von dir in 2 beschrieben.

[MartinP]

@xadox Das ist einfach eine Definition der Programmiersprache Javascript, dass true > false ist...

Ich habe übrigens beide Varianten mit einem kleinen Example state in Userdata ausprobiert - auch die Variante mit der "=" Abfrage funktioniert... Die "Kleiner als" Variante braucht aber eine Klammerebene weniger ...

[paul53]

@martinp sagt: Reed-Kontakte "prellen" ganz gerne

Das vermute ich auch. Man sollte also entprellen:

[MartinP]

Zum Beispiel von @paul53 Das Problem wird nicht das "Prellen" beim Wechsel True -> False sein, sondern ein "Prellen" beim Wechsel False -> True. Da ist der True-Zustand erstmal nicht stabil, sondern es wird noch einige Male kurz "false" gemeldet.
...

Also muss erst in den zu erstellenden "Aktionen" Block die Abfrage, ob der Zustand False vorliegt. Der Timeout muss bei jedem Wechsel - egal in welche Richtung aufgezogen werden ...

[paul53]

@martinp sagte: Der Timeout muss bei jedem Wechsel - egal in welche Richtung aufgezogen werden ...

Weshalb? Es muss nur die Wirkung während des Prellens eingehender weiterer Trigger unterdrückt werden.

[MartinP]

@paul53 falls der Low-Zustand lange stabil angelegen hat, ist der Entprell-Timeout für den High->Low Übergang abgelaufen.

Wenn dann beim darauf folgenden Low->High Übergang der Entprell-Timeout nicht aufgezogen wird, wird die fallende Flanke des ersten "Preller", der diesem Übergang folgt als regulärer High->Low Übergang interpretiert ...

[paul53]

@martinp sagte: falls der Low-Zustand lange stabil angelegen hat

... dann prellt der Kontakt nicht mehr. Prellen bewirkt schnelle Änderungen in beide Richtungen.

[MartinP]

@paul53 Es geht um die Preller die dem Low->High Übergang folgen - gibt es da Preller, enthalten diese natürlich auf "fake" High-Low-Übergänge, die ausgeblendet werden müssen.

Dein Beispiel-Schnipsel arbeitet da aber durchaus korrekt, er zieht den Timeout bei jeder Flanke auf ... Da der "Wenn" Block aber noch nicht enthalten war, habe ich nur auf die korrekte Platzierung von diesem hingewiesen...

[xadox]

Ich habe eurer Diskussion nicht ganz folgen können aber dies hat das Problem auch nicht lösen können:

[Homoran]

@xadox sagte in Auslösen nur bei Falsch:

dies hat das Problem auch nicht lösen können

heisst in beschreibender Sprache?

[xadox]

Trigger löst nach wie vor bei jeder Änderung aus.
Sowohl auf false auch auch auf true.

[paul53]

@xadox sagte: Trigger löst nach wie vor bei jeder Änderung aus.
Sowohl auf false auch auch auf true.

Wie stellst du das fest? Mit entsprechenden Logs?

[MartinP]

@paul53 Durch die Nutzung von "ist kleiner als Letztes" kommt vom Prellen am Übergang Low->High der erste Impuls ungefiltert durch.

So etwas in der Art sollte das beheben. Habe ich mal für einen kurzen Test genutzt...

Hier ist aber die Sperrzeit, bevor wieder Änderungen angenommen werden mit 8000 ms sicherlich deutlich zu hoch...

Alternativ wäre natürlich zu fragen, ob nicht direkt im Shelly der Eingang entprellt werden kann, entweder per Konfiguration in der Shelly Firmware, oder in Form einer Vorschalt-Mimik zwischen Shelly und Reed-Kontakt ...
Da wird ja schon bei jedem Prellen unnötig ein Telegramm auf die Reise geschickt ...

[paul53]

@martinp sagte: kommt vom Prellen am Übergang Low->High der erste Impuls ungefiltert durch.

Das ist der Sinn von Entprellen: Die erste Flanke true --> false löst die gewünschte Aktion ohne Verzögerung aus und weitere Flanken (Prellen) werden während der Sperrdauer ignoriert.

[MartinP]

@paul53 said in Auslösen nur bei Falsch:

Das ist der Sinn von Entprellen: Die erste Flanke true --> false löst die gewünschte Aktion ohne Verzögerung aus und weitere Flanken (Prellen) werden während der Sperrdauer ignoriert.

Nur, dass es auch beim Übergang false-->true durch das Prellen des Kontaktes zu Flanken true-->false kommt ... ich habe mal eine Skizze hingeschmiert. Verzeiht meine Sauklaue ...

Wenn man den Timeout sowohl an steigenden, als auch an fallenden Flanken startet ("wurde geändert" statt "ist kleiner als letztes") behebt man das Problem der Auslösung durch das Prellen an der steigenden Flanke

[paul53]

@martinp sagte: behebt man das Problem der Auslösung durch das Prellen an der steigenden Flanke

Du hast recht. An das Prellen wenn von false --> true geschaltet wird, habe ich nicht gedacht. Also besser so:

EDIT: "stop timeout" ist seit JS-Version 7.0.5 überflüssig, da seitdem Blockly automatisch bei Ablauf des Timers die Variable timeout auf null zurück setzt.