Jahresrückblick 2025 – unser neuer Blogbeitrag ist online! ✨

[Cinimod]

@firefrog

Hast du noch ein anderes Skript was auf diese Datenpunkte zugreift ?
Der "input100" ist von typ boolean ?

Den selben Datenpunkt ausgewählt im Skript? Der kann ja nicht beide gegensätzlichen Abfragen mit wahr beantworten. Vielleicht den falschen Datenpunkt angeklickt (kann ja auch den selben Namen haben u.U.)

So ist es auch etwas hübscher vielleicht, und du kannst sicher sein das sich alle Abfragen auf den Trigger Datenpunkt beziehen :

Die Verzögerung macht für mich auf den ersten blick auch keinen Sinn, aber vielleicht ja für dich

[MartinP]

@firefrog

Wo wird "Schalter" wieder auf "falsch" gesetzt?
Hast Du womöglich im vorigen Shelly einen Shelly-Internen Timer genutzt?

Wieso manipulierst Du "TargetDoorState" im Trigger auf den Türzustand?
Änderungen des Soll-Zustandes getriggert durch Änderungen des Ist-Zustandes bergen immer die Gefahr der Instabilität (Feedbackschleife, Oszillation)

[FireFrog]

@martinp
Hallo danke schon mal für das Feedback
ich hab direkt im Shelly "automatisch ausschalten" nach 1 Sekunde gemacht. Dadurch wird "Schalter wieder auf "falsch" gesetzt. So hatte ich es auch beim Vorgänger.

Bei deinem zweiten Punkt, stehe ich leider auf dem Schlauch. Wie meinst du das?

Für eine andere Garage, habe ich das Skritp genau so. Da funktioniert alles. Dort ist allerdings noch Shelly 1 der ersten Generation inkl. Addon.

Ich bin leider kein Profi was das Skripten mit Blockly angeht. Ich hatte hier vor langer Zeit mal ein Skript gefunden und an meine Bedürfnisse angepasst.

Es sollte eigentlich folgendes passieren.
Wenn ObjektID "TargetDoorState" verändert wird -> Shelly schalten
TargetDoorState wird über den yahka Adapter angesprochen.
Dass funktioniert wunderbar.

Dann soll mittels Magnetkontakt geprüft werden ob das Tor geöffnet/geschlossen wird bzw. offen/geschlossen ist.
Wenn ObjektID Input100 (Wert des Magnetkontakts) verändert wird
-> falls der Wert gleich "wahr" ist, soll CurrentDoorState und TargetDoorState 0 werden
-> falls der Wert gleich "falsch" ist, soll CurrentDoorState und TargetDoorState 1 werden

Hoffe man kann mir folgen :)

[FireFrog]

@cinimod

Auch dir vielen Dank für deine Unterstützung.

Datenpunkte habe ich auch erst gedacht, aber hab es mehrfach geprüft. Habe den korrekten Datenpunkt ausgewählt.

Ja input100 ist Typ boolean. Sollte das nicht so sein?

Die Verzögerung habe ich drin, damit mir angezeigt wird, dass Tor schließt gerade und es dauert 20 Sekunden bis es geschlossen ist.
Der Magnetkontakt ist geschlossen wenn das Tor offen ist. Somit wäre so wie das Tor ein paar cm geschlossen wäre der Magnetkontakt nicht mehr geschlossen und ich bekomme den Status "Tor geschlossen". Da wollte ich mit der Verzögerung entgegenwirken.

[FireFrog]

kann hier wirklich keiner weiterhelfen?
Mich wundert halt, dass es mit dem Shelly der ersten Generation genau so funktioniert hat.

[Cinimod]

@firefrog Was mich immernoch etwas wundert, der Magnetkontakt ist geschlossen wenn die Garage offen ist, laut deinem Skript.
Müsste es nicht genau anders herum sein?

Du hast einen Magnetschalter am Addon vom dem Shelly ja ? Und der Magnet ist am Garagentor und bewegt sich mit?!

Der Kontakt meldet offen wenn der Magnet sich vor dem Gegenstück/Schalter befindet ? Oder ist es genau anders herum ?

Ist der Magnet vom dem Kontakt wenn das Tor ganz auf oder ganz zu ist ? ("wenn Tor zu" währe eindeutig die sinnvollere Lösung)

Tausch doch mal true und false zum testen! Es kann ja nicht sein das sich da was selbstständig macht, und dann genau nach den 20 Sekunden die du eingebaut hast.

[Taddy81]

@firefrog was hast du für einen Garagenmotor und wie hast du den Shelly angeschlossen? Ich habe es bei mir probiert und es hat bunt funktioniert

Beim Bild hatte ich door und emrg verbunden, aber steuern konnte ich den Motor nicht.

[FireFrog]

@cinimod said in Garagentor Status Unterstützung:

@firefrog Was mich immernoch etwas wundert, der Magnetkontakt ist geschlossen wenn die Garage offen ist, laut deinem Skript.
Müsste es nicht genau anders herum sein?
Theoretisch ja aber ich habe es tatsächlich genau andersrum. So habe ich mir ein Kabel zum anderen Ende des Garagentors gespart
Du hast einen Magnetschalter am Addon vom dem Shelly ja ? Und der Magnet ist am Garagentor und bewegt sich mit?!
Genau so ist es
Der Kontakt meldet offen wenn der Magnet sich vor dem Gegenstück/Schalter befindet ? Oder ist es genau anders herum ?
Ich glaube das sollte egal sein, da ich das ja mit dem Script abfrage. Wenn "wahr" dann geschlossen und umgekehrt. Aber aktuell ist es so eingestellt, dass mir der Kontakt geschlossen meldet wenn das Gegenstück NICHT am Schalter ist. Das ist aber nur so damit mit auch die Shelly-App das Garagenbild offen bzw. geschlossen anzeigt. Ich habe es aber auch schon andersrum/invertiert versucht
Ist der Magnet vom dem Kontakt wenn das Tor ganz auf oder ganz zu ist ? ("wenn Tor zu" währe eindeutig die sinnvollere Lösung)
Ich gebe dir absolut Recht, dass wäre die sinnvoller Lösung. Da kommt wieder das Kabel ins spiel was ich eigentlich vermeiden wollte
Tausch doch mal true und false zum testen! Es kann ja nicht sein das sich da was selbstständig macht, und dann genau nach den 20 Sekunden die du eingebaut hast.
Habe ich auch schon versucht. Dann wird zum einen der Status genau falschrum angezeigt (offen wäre geschlossen) aber der eigentliche Fehler bleibt auch hier bestehen.

[Cinimod]

@firefrog sagte in Garagentor Status Unterstützung:

Vielleicht zeigst du uns mal die drei Datenpunkte im Detail.

Wenn ich es recht im Sinn habe kann Homekit auch ein Tor in Bewegung darstellen mit der 2

[FireFrog]

@cinimod

Meinst du das so?
Ich danke dir jetzt schon mal, dass du so Unterstützt!

[Cinimod]

@firefrog Ich meinte eher den Inhalt des Datenpunktes. So:

Speziell den Datenpunkt input100, da muss ja irgendwas faul sein.

Hattest du es mal so umgebaut wie ich es dir gezeigt hatte ? oben den input100 rein !?

Du sagst ja der currentState verändert sich nach 20 sekunden wieder auf 1 obwohl der input100 wahr ist und bleibt? verhält sich der targetState auch so ? geht der auch zurück auf 1 ?

[FireFrog]

@cinimod

input100 ist kein selbst erstellter Datenpunkt. Das ist direkt der Datempunkt vom Shelly bzw. der vom Magnetschalter/Kontakt

Ne hatte ich nicht getestet.

Hier würde ich doch aber gar nicht den Schalter vom Shelly auslösen, wenn ich oben input100 einsetze.

ich habe aber gerade noch was gesehen, als ich dir die Datenpunkte geschickt hatte. Die standen auf "state" habe es jetzt mal auf "value" geändert. kann das aber erst heute Nachmittag testen, wenn ich wieder zu hause bin.

[Cinimod]

@firefrog sagte in Garagentor Status Unterstützung:

@cinimod

input100 ist kein selbst erstellter Datenpunkt. Das ist direkt der Datempunkt vom Shelly bzw. der vom Magnetschalter/Kontakt

Zeig doch trotzdem mal den Inhalt bitte. Musst du den Expertenmodus einschalten

Ne hatte ich nicht getestet.

Hier würde ich doch aber gar nicht den Schalter vom Shelly auslösen, wenn ich oben input100 einsetze.

Das soll nur den unteren teil ersetzen. Den oberen Trigger so lassen!

ich habe aber gerade noch was gesehen, als ich dir die Datenpunkte geschickt hatte. Die standen auf "state" habe es jetzt mal auf "value" geändert. kann das aber erst heute Nachmittag testen, wenn ich wieder zu hause bin.

State geht schon klar!

Du sagst ja der currentState verändert sich nach 20 Sekunden wieder auf 1 obwohl der input100 "wahr" ist und bleibt (hast du das beobachtet?) ? verhält sich der targetState auch so ? geht der auch zurück auf 1 ?

[FireFrog]

@cinimod

Es läuft wie folgt ab
Tor ist geschlossen
CurrentState = 1
TargetState = 1
ich öffne
TargetState geht sofort auf =0
Input100 geht sobald Tor komplett offen ist auf true, dadurch geht dann auch Current auf 0
nach 20 sek geht current aber wieder auf 1
Input100 bleibt permant auf true

[Cinimod]

@firefrog ist ja echt verrückt, vor allem weil da genau deine 20 Sekunden Verzögerung das Auslöser ist. Wenn du den auf 10 Sekunden änderst passiert das auch nach 10 Sekunden ja ? Was denn du die Verzögerung mal ganz weg machst?

Den Inhalt von Input100 würd ich gern mal sehen noch, wenn du es einrichten kannst. (Expertenmodus einschalten)

Bau den unteren Teil mal so um mit dem TimeoutBlock statt der Verzögerung:

[Cinimod]

war doppelt

[FireFrog]

@cinimod

habe gestern Abend noch etwas getestet.
Die Verzögerung hatte ich vorher auch schon mal getestet. Wenn ich dort beispielsweise 10 Sekunden eintrage, passiert genau alles nach 10 Sekunden.

Ich habe jetzt mal deinen Vorschlage getestet

Das funktioniert soweit.
Ich habe hier noch eine Vergzögerung eingebaut, damit soll das Tor erst "geschlossen" anzeigen wenn es nach 20 sekunden zugefahren ist

Das klappt allerdings gar nicht. Die Werte Current/TargetState ändern sich sofort wenn der Magnetkontakt unterbrochen wird.
Ich muss mal noch mit deinem Timeout veruschen.
Ich weiß aber nicht warum du ein "stop Timout" eingebaut hast? Was macht das an dieser Stelle?

Kannst du mir noch erklären was an dieser Stelle passiert?

Was wird in dem Objekt "Wert" gemacht?

Und noch mal, Tausend Dank schon mal!

[Cinimod]

@firefrog

Der Block "wert" gehört zu dem Trigger und beinhaltet den wert der Trigger Datenpunktes.
Ist der Trigger Datenpunkt True, ist es der "Wert Block" auch, und anders herum.

Die "falls-abfrage" braucht immer ein "true" als Rückmeldung/bzw. als Ergebnis um die Aktion auszuführen.

In deinem Beispiel hier ist das Ergebnis deiner Auswertung auch "true":
falls wert von input100=wahr (Ergebnis stimmt/true!)

Dort könnte auch beispielsweise ne größer oder kleiner abfrage sein. (Bspw. falls wert von xx größer ist als 10), und das ergebnis bei der abfrage ist dann richtig/true wenn der wert halt größer als 10 ist.

In dem vorgeschlagenen Skrip von mir bekommt er halt auf direktem weg vom Trigger ein "true". Da der Input100 ja nur true/false kann, ist das Ergebnis eben true zum ausführen des oberen Part´s und wenn es nicht true ist läuft das "sonst" durch.

Ich hoffe es ist halbwegs verständlich.

Der Stop Timeout soll den Timeout halt stoppen, falls er noch läuft, ist in deinem fall nicht sehr relevant, sollte man zur Fehlervermeidung aber immer an einbauen.
Wenn du jetzt schnelle Änderungen hättest, angenommen der input100 ist auf false gegangen, und innerhalb der 20 Sekunden aber wieder true wird der timeout abgebrochen. Hast du den nicht läuft dein timeout einfach weiter und führt die Aktion trotzdem aus, auch wenn input100 bereits wieder true ist.
Je nach dem wie oft und schnell diese Änderungen erfolgen oder auch längere Timer hat, hat man unter umständen mehrfach den selben timeout gleichzeitig am laufen und sucht dann aber den Fehler.

Versuch es mal damit! Ich hatte auch schon mal Ärger mit den Verzögerungen, seither nutze ich die gar nicht mehr.

[FireFrog]

@cinimod

hast es gut erklärt. Gaaanz unwissend bin ich auch nicht ;) Hab halt nur wenig Erfahrung direkt mit Blockly.

Aber summa summarum mit dem Timeout funktioniert es jetzt genau wie es soll.

Vielen Vielen Dank!!

[Cinimod]

@firefrog na endlich :blush: :+1:

Gern