[gelöst] Skript nicht automatisch starten

[MichaelN]

Mit virtueller Taste würde es auch gehen und die könntest Du auch noch "drücken", um das Programm zu starten. Das wäre die "normkonforme" Anwendung.

[Xel66]

@Xel66
Nein, jede andere kann ich nicht nehmen. Diese spezielle Variable wird vom System immer auf "true" (von mir definiert als Neustart) besetzt, wenn es gestartet wird (bevor andere Variablen).

Glaube mir, ich kenne diesen Workaround und auch dessen Auswirkungen und sehe diesen Blödsinn omnipräsent, weil alle den Rattenfängern von Hameln folgen. Es ist absolut sinnfrei und entbehrt jeglicher Logik und technischem Sachverstand, diesen Workaround in durch Zeitmodule, Sensordaten oder Tasterbetätigung getriggerte Programme einzubauen. Diese Bedingungen sind bei Systemstarts nicht WAHR (außer Zeitbereiche und hier wäre eine Abarbeitung ja zielführend, weil so vorgesehen). Und doch wird dieses immer wieder gemacht. Es gibt durchaus sinnvolle Anwendungen für den Workaround (setze ich auch selbst ganz gezielt ein, z.B. Unterdrückung von Statusmeldungen per Pushdienst durch die Initialisierung des Systems), aber diese Omnipräsenz in allen Programmen ist einfach nur Bull und zeigt nur, dass der Ratgeber nicht vermitteln konnte, wie das funktioniert oder eben selbst die Funktionsweise des Systems nicht verinnerlicht hat. Solange so ein Blödsinne verbreitet wird, dass alle Programme beim Systemstart gestartet werden, wird sich das auch nicht ändern. Es werden nur Bedingungsprüfungen angestoßen. Leider werden bestimmte Sensorwerte und Aktorstatus mit Defaultwerten (bis zur ersten Statusmeldung) initialisiert, so dass auch das Programme triggern kann. Als das System ursprünglich erdacht wrude, wurden z.B. auch noch netzversorgte Aktoren abgefragt, um deren Status zu setzen. Das ist zu Zeiten von IP nicht mehr der Fall und leider auch schlecht kommuniziert. Diesbezügliche Anfragen sieht man wiederholt im Forum (z.B. Rollladenstatus, Wandthermostatstatus etc.).

Und doch, Du kannst jede andere Bedingungs(kombinations)prüfung nehmen, die zum Systemstart kein WAHR ergibt, um eine "Ausführung" beim Systemstart zu verhindern, wenn Du das Programm sowieso nur direkt startest. Solange das WENN leer ist, ergibt sich außer dem Systemstart keine Bedingung, die eine Bedingungsprüfung startet und so den Ablauf im DANN starten könnte. Insofern ist es egal, ob Du eine ungültige Bedingung (z.B. Prüfung auf WAHR UND FALSCH des gleichen boolschen Triggers gleichzeitig mit nur prüfen) oder gar keine hinterlegst. Die einzige Möglichkeit das Programm nur als Sammelcontainer für auszuführende Aktionen zu missbrauchen ist eben die direkte Ausführung über WebUI oder App (oder Scriptaufruf - auch schon oft gesehen).

Ein Programm mit einer virtuellen Taste als Trigger würde nicht ausgeführt, weil die Taste zum Systemstart nicht gedrückt würde (außer Du programmierst sowas). Somit wäre diese Ausführungsverhinderung schon gelöst und Du könntest das Programm auch über diese Taste (per WebUI, App oder Programm) gezielt triggern und mit SONST WENNs auch noch andere Nebenbedingungen mit prüfen. Es ist soviel einfacher, das System einfach so zu nutzen, wie es vom Hersteller vorgesehen ist, als irgendwelche windigen Workarounds einzusetzen und mit externen Apps die DANNs von Programmen ausführen zu lassen. Die Programmierung einer virtuellen Taste wäre vom Aufwand vergleichbar und würde Fehlfunktionen und solche Threads ersparen.

Gruß Xel66