IPSWorkflow: Abschaltverzögerung

Der Workfloweditor ist richtig schick, teilweise schon ‚magic‘ - 2-3 Kleinigkeiten für den Komfort wären gut (Verbindungen werden farbig beim Anklicken, Anzeige der Werte auch in den Logikobjekten) - Hut ab von meiner Seite!

Ich versuche gerade eine Abschaltverzögerung zu bauen und vermutlich liegt das Problem eher in der Ansteuerung des Shelly-Relais.

Aufgabe: Solange Tür offen, Lampe leuchtet. Sobald Tür zu, Lampe leuchtet für weitere 60 Sekunden.

Paar Varianten hab ich ausprobiert, hier meine Lieblinge:

  1. Einmaliger Timer, „Neustart/Aktiv“ direkt am Türsensor (solange Tür offen wird der Timer zurückgesetzt). Macht er nicht, der Timer reagiert wohl nur auf „Kicks“.

  2. „Wenn“ Objekt genutzt. Wenn „Tür auf“ wird via „Wenn Erfüllt“ über ein „Oder“ Gate die Lampe angemacht, bei „Wenn nicht Erfüllt“ wird der Einmaltimer angestossen und dessen Ausgang „Timer läuft“ auf das genannte „Oder“ Gate gelegt. Geht nicht, weil das „Wenn Erfüllt“ zuerst abfällt, dann kommt aus dem „Oder“ ein false heraus und schaltet die Lampe ab. Der Timer scheint schnell anzuspringen und bedient das „Oder“, die Leitung zum Shelly Relays geht auf „True“, wird aber nicht realisiert weil es auf der Strecke bleibt (vermutlich mag der Shelly diesen schnellen Wechsel nicht, müsste ich jetzt die Strecke durchdebuggen :skull_and_crossbones:).

  3. Ganz wilde Jagd: Solange die Tür auf ist, wird ein zyklischer Timer mit 1 Sekunde am laufen gehalten, der den Eingang „Neustart/Aktiv“ des Einmaltimers ständig zurücksetzt. Interessanterweise schaltet sich der Einmaltimer dann nach den 30sek (Eingang „Zeit (Sekunden)“) trotzdem ab.

Vermutlich liegt mein Problem darin, dass ich zu kompliziert denke. Oder nach 4 Stunden herummalerei das .json irgendwelche Artefakte enthält.

Hat jemand eine Idee?

Kann Deinen Beschreibungen noch nicht ganz folgen, mach mal einen Screenshot von Deinem Workflow (Punkt 2 scheint ja schon ein guter Ansatz zu sein).

Anbei auch noch der Workflow meiner Bewegungsmelder, macht was ähnliches und könnte einige Ideen liefern :wink:
BWM_2023-01-26.zip (3,2 KB)

Prinzipiell sollte es wie folgt möglich sein:
Wenn „Tür Auf“ Licht einschalten
Wenn „Tür Zu“ 60 Sekunden Timer starten und Licht ausschalten

Mach ich doch glatt:

  1. Grundstellung

  2. Tür auf

  3. Tür zu (0-30 Sekunden)

  4. Tür zu (30+ Sekunden)

Ich hab den Shelly Plug im Debugger des Shelly-Plugins und im MQTT-Debugger angeschaut, wenn „Tür zu“ wird nur ein „off“ Event verschickt, das folgende „On“ verschluckt irgendjemand.

Als Workaround habe ich mal beim „Tür zu“ Status einen 1 Sekunden Timer angestossen der dann bei Ablauf den Timer für die Abschaltverzögerung anstösst - das funktionierte bis ich was anderes gemacht habe und bei Rückkehr dann nicht mehr (Grund: Der Ausgang „Auslösung“ geht nicht mehr auf True, egal welche Zeit ich einstelle oder Verbindungen lösche und neu einzeichne, selbst nach Restart des Symcon Dienstes nicht mehr).

Der Einmaltimer scheint da eh noch eine Macke zu haben:
Bildschirmfoto zu 2023-01-26 22-21-10
Es wird was gezählt, aber mit einem recht grossen Offset.

Ratlos…

Verwende doch einfach den Ausgang „Auslösung“ und ein NICHT für das Schalten.

  1. Timer und ODER brauchst Du ja gar nicht.

Du scheinst andere Software wie ich zu verwenden: Bei mir läuft IPSymcon in einer Linux-VM auf einem Linux Server und der WorkflowEditor im Firefox Webbrowser unter Linux auf einer Linux Workstation.

Hier sieht Dein Vorschlag so aus:

  1. Tür zu:

  2. Tür auf:

  3. Tür auf, nach 30 Sekunden:

  4. Nochmal Tür auf und nach 5 Sekunden wieder zu:

Wenn Du genau hinschaust, wird der Ausgang „Auslösung“ anscheinend nicht immer angesprochen.

Das Kernproblem scheint zu sein, dass IPSymcon als Middleware es versäumt, gelegentlich nachzusehen ob denn seine Statusänderungen angekommen sind (der Status eines IoT Gerätes wird ja erfasst aber nicht erzwungen).

So habe ich das gemeint (jetzt nur mal auf die Schnelle zusammenkopiert):

Das WENN Modul sorgt bei True für das Einschalten und bei False wird der Timer gestartet und schaltet nach 60 Sekunden wieder ab.

Dejure geht das, defacto (zumindest bei mir) nicht.

Vielleicht darf ich eine Zwischenfrage stellen: Wenn Orange Linien mit „True/False“ bedeuten, dass da eine Änderung stattgefunden hat bzw. dieser Pfad durchlaufen wurde, sind dann Schwarze Linien Datenlinien die nicht berechnet wurden weil ein Widget meint da nichts tun zu müssen?

ja, die orangen Linien zeigen die Verbindungen an wo Daten an andere Module weitergereicht wurden. Manche Module machen das immer, andere (wie zum Beispiel das WENN) nur bei einer bestimmten Bedingung.
Bin da auch noch etwas am überlegen ob ich diese Ausgänge speziell markieren sollte :thinking:

Im Beispiel oben muss vermutlich das ODER noch weg, das verhindert ja den Reset, wie auch immer, ich werde das im Laufe der nächsten Woche nachbauen und stelle Dir dann einen SubWF zur Verfügung :wink:

Hab heute mal einen Subworkflow dazu gebaut: Abschaltverzögerung :wink:

Erm… Ich finde auf der Weboberfläche nicht das Knöpfchen, um Deine Routine zu importieren.

Ob mir da jemand weiterhelfen könnte?

Einfach einen SubWorkflow erstellen und dann im Menu „Workflow importieren“ wählen :wink:

Ah, das ist dieses Icon „Verwaltung“, wo ich mich schon immer gefragt habe, was dahinter steckt weil es bei mir immer ausgegraut ist.

Hast Du im Kopf oder kannst nachsehen, unter welchen Bedingungen das freigegeben wird?

Nur wenn Du einen SubWf bearbeitest :wink:

Hm… Da scheint bei den Shellies das Backend eine schwarze Leitung anders zu interpretieren als Du vermutest.

  1. Tür auf:

  2. Tür zu:

In diesem State scheint die Annahme zu bestehen, dass die beiden Schwarzen Leitungen am Gate „Licht Status“ bedeuten sollen „Es hat sich nichts geändert“ - real schickt das Backend ein „off“ auf die Reise (warum auch immer, denn offensichtlich wurde es gar nicht angesprochen).

Ein weiterer „Point of Failure“ besteht darin, dass die Module sequentiell abgearbeitet werden und daher Oder-Module zwischenzeitlich auf False fallen obwohl von der Logik her immer irgendwo ein True anliegt - da scheint entweder das Backend oder die Shelly-Anbindung eine gewisse Totzeit zu haben in der ein Statuswechsel ignoriert wird (Folgt auf ein bestehendes True ein False und kurz danach ein True wird das letzte True verschluckt).

Hm… Sample & Hold mit Timer und Flipflop? „Annahme verweigert“, das RS-FF wird vom Workflow abgelehnt (NAND, NOR).

Alles zurück… Anscheinend habe ich eine Scriptleiche die parallel arbeitet und mir die Ergebnisse versaut.