Durch Aktualisierung einer String-Systemvariable Programm auslösen

[PeterAC]

Das Problem:
Die Aktualisierung einer String-Systemvariable soll, evtl. i.A. weiterer Bedingungen, ein Programm auslösen, wobei der Inhalt der Systemvariablen nicht relevant ist. Die naheliegende Lösung, eine Stringvariable mit Kennzeichen "bei Aktualisierung auslösen" funktioniert nicht, weil dabei der Inhalt der Systemvariable mit dem String im Parameterfeld der Bedingung verglichen wird und daher das Programm nur ausgelöst wird, wenn diese übereinstimmen. Bisher funktionierte es aus einem unbekannten Grund, wenn des Feld für den Vergleichsstring leer gelassen wurde, nun aber nicht mehr.

Lösung:
Die Lösung scheint auf den ersten Blick paradox. Das gewünschte Verhalten lässt sich erreichen, indem man wie bisher im ersten Bedingungsblock die Stringvariable gegen einen beliebigen String (z.B. einen Nullstring) mit dem Attribut "bei Aktualisierung auslösen" prüft und um eine weitere "ODER"-Bedingung mit dem Attribut "nur prüfen" erweitert. Diese "ODER"-Bedingung muss stets "Wahr" ergeben.

Die Konstruktion funktioniert so:
Die Änderung der String-Systemvariable ruft den Bedingungblock des Programms auf. Dabei wird festgestellt, dass die Bedingung nicht erfüllt ist. Eine Eigenart der Abarbeitung des Bedingungsblock ist, dass dieser nun nicht ohne weiteres wieder verlassen wird, sondern die Liste von Kriterien weiter im Modus "nur prüfen" abgearbeitet wird. Da die "ODER"-Bedingung stets wahr ist, spielt die nicht erfüllte Bedingung des auslösenden Strings keine Rolle mehr und der zugehörige Anweisungsblock wird ausgeführt. Tatsächlich verhält es sich wie eine "UND"-Verknüpfung des Ereignis "Aktualisierung der String-Variable" mit "Hilfsbedingung = Wahr". Wenn die Hilfbedingung nicht immer wahr ist, ergibt sich heraus auch eine Steuerungsmöglichkeit.

Auf diese Weise lassen sich auch komplexere Bedingungen konstruieren, wenn weitere Bedingungen in einem oder mehreren "ODER"-Bedingungsblöcken platziert werden und dort z.B. mit "UND"-Bedingungen verknüpft werden. Allerdings müssen diese Blöcke auf dem obersten Level alle mit "ODER" verbunden werden, wodurch die Möglichkeiten etwas eingeschränkt sind. Es lassen sich auch weitere "SONST, WENN"-Blöcke ("Regeln") hinzufügen. Die auslösende Stringvariable als Trigger braucht man nur einmal zu verwenden.

Um die Übersicht nicht zu verlieren, ist es empfehlenswert nur die Aktualisierung der String-Variable als Trigger zu verwenden und alle anderen Bedingungen mit "nur prüfen" zu verwenden.

Im Anhang ist ein Beispiel für ein Programm, das mit der Aktualisierung der Stringvariable "_vSMA_PV_Power_TS" getriggert wird. Falls die Status-Variable "_vtPV_Update" den Wert "Ready" hat wird diese im "DANN"-Block auf "SmaUpdate" gesetzt. Im "SONST, WENN"-Abschnitt wird die Status-Variable auf "EmUpdate" geprüft und in diesem Fall auf "CalcPVDAta" gesetzt. Das Programm ist ein Teil von mehreren Skripten mit dem die PV-Erzeugung (Shelly EM) und Eigenverbrauch und Netzbezug (SMA-Energymeter oder Homemanager 2.0) erfasst und aufbereitet werden. Die Statusvariable steuert die Synchronisation der beteiligten Skripte und stößt als letzten Schritt die Berechnung der einzelnen Werte an. Das Skript in der letzten Zeile hat keine technische Funktion, sondern enthält nur die Dokumentation zu diesem Programm und wird als erstes mit "quit;" sofort wieder verlassen, falls es einmal aufgerufen werden sollte.

VG,
Peter

[MichaelN]

Wie ist das

Bisher funktionierte es... , nun aber nicht mehr

zu verstehen?
Was ist "bisher" und wwas "nun"
Kann es sein, dass du nur übersehen hast, das nicht das DANN, sondern das SONST ausgelöst wird?

[PeterAC]

"Bisher" heißt die letzten drei Monate, "nun" heißt nach Aktualisierung der Firmware auf 2.55.10 und Überarbeitung des Programms.

In der originalen Fassung des Programms war die oberste Bedingung eine UND-Verknüpfung zwischen _vSMA_PV_Power_TS="" (bei Aktualisierung auslösen) und _vtPV_Update=ready (nur prüfen). Der "SONST, WENN"-Block kam nicht vor, der "SONST"-Block war leer. Bei Aktualisierung von _vSMA_PV_Power_TS und _vtPV_Update=ready wurde zuverlässig _vtPV_Update auf "SMAUpdate" gesetzt.

Nach der Firmware-Aktualisierung gab es zunächst keine Probleme. Um die Reihenfolge der PV-Datenberechnung robuster zu machen, hatte ich dann der Werteliste für _vtPV_Update zusätzlich den Wert "CalcPVData" und den "SONST, WENN"-Block hinzugefügt. Danach wurde der erste DANN-Block niemals mehr ausgelöst. Ein Test ergab, dass _vSMA_PV_Power_TS="" die Ursache war, was eigentlich auch logisch ist, denn diese Variable ist auch niemals leer, sondern enthält den letzten Zeitstempel. Seltsam ist nur, dass es vorher mit dem Nullstring funktionierte (hatte ich getestet). Ob es an einem Fehler der vorigen Releases lag (The bug is the feature), der nun behoben wurde, oder an einer beschädigten Bedingungen im bisherigen Programm, die gleichwohl das erwünschte Ergebnis produzierte und die durch die Bearbeitung nebenbei "repariert" wurde, lässt sich nicht mehr sicher sagen. Jedenfalls ist die neue Umsetzung konform mit der offiziellen Logik und der Beschreibung der Abarbeitung der von Skript-Bedindungen.

"CalcPVData" wurde eingeführt, weil es selten vorkommt, dass die Abfrage der Daten misslingt, weil das Timing nicht gepasst hat, oder genau in dem Moment eine WLAN-Störung aufegtreten war. Die Verbindung zum Shelly EM im Keller ist ziemlich an der Grenze. In diesem Fall werden die Daten erst beim nächsten Zyklus augewertet und das Mittelungsintervall verlängert sich automatisch. Macht man das nicht, passen Bruttoertrag und Einspeise- bzw. Bezugsdaten nicht zusammen und es können sich paradoxe Wert ergeben, wie negativer interner Verbrauch oder Eigenverbrauch, oder Eigenverbrauch höher als Bruttoertrag.

VG,
Peter