Auslösen nur bei Falsch
-
@paul53 >>Wie stellst du das fest? Mit entsprechenden Logs?
Indem ich sehe, dass die eigentliche Aktion sowohl bei true als auch bei false ausgelöst wird.Ich habe aber hier wieder den Faden verlohren
Und weiß nicht genau welchen dieser Vorschläge ich nun am ehesten nutzen soll.Ist denn überhaupt sichergestellt, dass der Reek Kontakt wirklich "prellt"?
In der iob Übersicht sieht es zumindest mit dem bloßen Auge nach einer normalen schaltung von false auf true und von true auf false aus ohne mehrfach hin und her zu schalten. -
@xadox sagte: mit dem bloßen Auge
Mit dem bloßen Auge kann man Prellen nicht erkennen, denn es passiert im Abstand von wenigen ms. Eine Logausgabe des Trigger-Wertes zeigt, ob es prellt.
-
@xadox said in Auslösen nur bei Falsch:
@paul53 >>Wie stellst du das fest? Mit entsprechenden Logs?
Indem ich sehe, dass die eigentliche Aktion sowohl bei true als auch bei false ausgelöst wird.Ich habe aber hier wieder den Faden verlohren
Und weiß nicht genau welchen dieser Vorschläge ich nun am ehesten nutzen soll.Ist denn überhaupt sichergestellt, dass der Reek Kontakt wirklich "prellt"?
In der iob Übersicht sieht es zumindest mit dem bloßen Auge nach einer normalen schaltung von false auf true und von true auf false aus ohne mehrfach hin und her zu schalten.Wie @paul53 schon sagte würde ich mich mit Logging dem Problem nähern
Zuerst ein ganz einfaches Skript, was nur eine Log-Meldung ausgibt, sobald der Datenpunkt des Reed Relais sich geändert hat.
Damit schaut man dann, ob es zu "Prellen" kommt. Wenn ja....
Danach dann das Skript um die "Entprellung" erweitern (nur Logging als Aktion).
Hat man das dann zum Funktionieren gebracht,
baut man um des Logging die Erkennung des "interessierenden" entprellten Zustandsübergangs ein....Schritt für Schritt aufbauen das Skript, und immer Testen, ob die letzte eingebaute Erweiterung wie gewünscht funktioniert, bevor man den nächsten Aufbauschritt angeht...
Sollten die Tests wirklich am Tor draußen mit dem dort installierten Reed-Relais erfolgen, sollte man dem Torantrieb zwischendurch auch Pausen gönnen. Die sind in der Regel nicht dafür ausgelegt, das Tor pausenlos auf und zu zu machen.
Bequemere Tests könnte man mit einem Umbiegen des zu erstellenden Skripts während der Tests auf einen "Userdata.0" Test-Datenpunkt bewerkstelligen.
Den Userdata-Datenpunkt könnte man auch selber "prellen" lassen ...
Für solche Zwecke habe ich da einen angelegt, den ich über einen VIS "Knopf" bequem aktivieren und deaktivieren kann ...
-
Ich habe den Reek Kontakt nun mal an einen anderen Shelly ohne Garagentor aufgebaut.
Und kann nun auch bestätigen dieser prellt.Ich habe dem Script dann entsprechend den Verzögerer hinzugefügt aber nach wie vor wird der Trigger bei true und false ausgelöst:
Bei Shelly selbst konnte ich kein Entprell Feature finden.
-
@xadox
Ändere den Trigger auf "wurde geändert"! (siehe hier) -
-
@paul53 ,
wie wird ein wait Befehl in Blockly behandelt ?
Bleibt das Script dort stehen oder wird der Trigger wieder angestoßen ?
Bei async müsste der Trigger wieder angestoßen werden und das Problem verursachen.
Ich muss das mal testen. -
-
@paul53
Funktioniert das Blockly so wie deines oder gibt es da technische Unterschiede?
-
@gonzokalle sagte: Funktioniert das Blockly so wie deines
Ja.
-
Ich benötige nochmal eure Unterstützung.
In der Weihnachtzeit ist die Gargenbeleuchtung von Sonnenuntergang bis 22:00 an.
Daher möchte ich hierbei ebenfalls vorab prüfen lassen, ob die Weihnachtsbeleuchtung bereits an ist und falls ja soll das Script nicht auslösen.So ist mein Ansatz, aber nun geht die Beleuchtung nicht mehr an:
-
Ich habe es nochmals auf anderem Weg probiert, leider ebenfalls ohne Erfolg:
Habt ihr ggf. nochmals einen Tipp?
-
- Du liest das ganze Objekt. Was Du brauchst wäre "Wert vom Objekt"
- Wenn in dem Objekt ein bool'scher Wert (true/false) steht, brauchst Du nicht auf "= falsch" prüfen.
Da nimmt man dann ein "nicht"
-
@codierknecht Vielen Dank dafür. Funktioniert
