Für alle die Mitlesen und noch nicht so viel Erfahrung oder gar noch Vorbehalte gegen den Logikeditor haben: Im Folgenden spreche ich Dinge an, die ich an dem Logikeditorkonzept vom TWS extrem schätze, die ich so auch noch nicht gesehen habe und die ihn meiner Meinung nach wirklich hocheffizient und sinnvoll für KNX, 1-Wire, MQTT machen - es ist quasi eine Art Plädoye wegen der eingebauten Eingangsfunktionen, der Startverhalten, dem Doktormodus und der Persistenzmöglichkeit
Sensej hat geschrieben: ↑Mo Nov 08, 2021 10:19 pm
2. Wenn ich die Logik ändere und speichere, dann wird auch Gesamtzählerwert resetet.
Liegt es daran, dass ich noch keine Timeserie verwende?
Nein, das liegt daran, dass Du den Startwert als GA übergibst und nicht wie ich als Festparameter. ABER: Wenn Du es so machsst wie ich, könntest Du bei einem erneuten Speichern nach langer Zeit einmal unbeabsichtigt die Funktion der Nulldurchgangerkennung rückgängig machen, wenn Du Dir den aktuellen Startwert nicht, wie in meinem Screenshot zu sehen, im Doktormodus anzeigen lassen und notiert hast. Da muss man die Logik noch sicherer gegen eigene Fehler machen, ist mir jetzt erst bewusst geworden. Du wirst es am Ende des folgenden Textes nachvollziehen können - hoffentlich bekomme ich es einigermaßen erklärt.
Sensej hat geschrieben: ↑Mo Nov 08, 2021 10:19 pm
Bei mir wird unter Startwert im grünen Kästchen kein Wert angezeigt.
1. Wann wird dieser Wert( bei dir 1761,36) normalerweise angezeigt?
Das ist so, wie Du die Eingänge nutzt völlig korrekt, dass in dem grünen Kästchen kein Wert steht. Das ist das Kästchen für die Eingangsfunktionen, von denen Du jetzt keine nutzt. Ich habe in meinem Modul kein Eingangsobjekt auf dem zweiten und dritten Eingang verschaltet, sondern die Eingangsfunktion ("grünes Kästchen") auf Parameter gestellt und somit diesem Eingang einen "zunächst" festen Variablenwert von 1761.36 übergeben. Das mache ich deshalb, weil ich keine GA oder so für diesen Startwert habe, was meiner Meinung nach in diesem Fall auch nur sehr bedingt Sinn macht. Dazu komme ich gleich.
Klicke einfach mal auf dieses grüne Kästchen und spiele mit den Möglichkeiten rum, dann wirst Du sehen, was da geht und was ich meine. Auf diese Weise hätte ich an Deiner Stelle auch die 1 am zweiten Eingang vorgegeben, anstelle den Code zu verändert. Das ist zwar an sich nicht falsch und Du kannst es auch so lassen, aber wenn Du den Code selber irgendwann noch einmal für andere Verbrauchszähler verwenden willst und Du die Korrektur da dann brauchst (so ist es bei mir, bei drei von vier Zählern brauche ich ihn), dann ist er schon da und Du würdest Deine bestehende Logik einfach nur duplizieren (einer der Butten nebem dem Speichern.
Den Startwert mittels GA zu übergeben führt zu folgenden Herausforderungen (versuche den folgenden Absätze möglichst genau nachzuvollziehen):
Der Eingang einer Logik kennt den letzten Wert des verknüpften Objektes nur, wenn dieser zur Laufzeit der Logik auch mindestens 1x empfangen wurde , also nach dem letzten Speichern der Logik oder nach einem Aktivschalten einer inaktiven Logik -> und dafür muss Wert dieser aktiv bereitsgestellt werden egal um was für einen Typen es sich handelt (1-Wire, KNX, MQTT, Objekt eienr anderen Logik)! Es reicht nicht aus, dass Dein TWS z.B. im Objektmonitor den letzten Wert dieses Objektes kennt und anzeigt, denn deshalb liegt der Wert am Eingang der Logik noch lange nicht an. Das ist auch total sinnvoll so!!!
Wenn Du nach dem Speichern einer Logik die Logik auf Doktormodus stellst, siehst Du, dass die Eingänge meist 0 oder false sind, aber z.B. nicht rötlich hinterlegt. Das sind Defaultwerte, die aber nicht wirklich an die Logik übergeben wurden!!! Würde die Logik triggern, arbeitet diese Logik aber damit (es sei denn die internen Defaultwerte aus dem Logikcode sind anders definiert, die werden aber dann im Doktormodus erst nach dem ersten Triggern angezeigt).
In Deinem konkreten Fall für dieses Zähler Modul bedeutet dies, dass der Startwert vor einem ersten Triggern der Logik gesetzt sein sollte, sonst schreibst Du am Ende "Müll" in die Zeitserie. Wenn Du also den Startwert unbedingt per GA übergeben willst, dann sollte dieser Eingang auf keinen Fall mit dem Trigger-Verhalten C = on change, A = always angelegt sein, sondern mit U = update only no trigger! Damit vermeidest Du, dass die Logik nur beim initialen Setzen des Startwertes triggert, was dann zu falschen Werten in der Zeitserie führen würde, wenn der Zählereingang noch nicht aktiv beschrieben wurde und der KNX-Zähler aber nicht mehr 0 ist... (dies zu vestehen ist wichtig für gute Logiken!!!). Zusätzlich solltest Du den Startwerteingang unbedingt von X auf I stellen, dass führt dazu, dass die Logik nur ausgeführt (getriggert) werden kann, wenn auf dem Eingang mindestens ein erster Wert empfangen wurde. Eine Kombination aus U und I auf dem selben Eingang ist somit sehr mächtig. Die Logik wird das erste Mal ausgeführt, wenn dieser Eingang einen Wert hat und ein anderer Eingang (oder Timer) die Logik triggert.
Warum Nulldurchgangserkennung und Persistenz (Unendlichkeitszeichen im Logikkopf)
In meiner Custom-Logik habe ich ja eine "Nulldurchgangserkennung" für den ersten Eingang umgesetzt. Wie oben beschrieben ist das dann hilfreich, wenn z.B. der vorgeschaltete KNX-Zähler seinen bereits erreicheten Zählerwert durch Stromausfall oder Zurücksetzen (Neuprogrammieren) verliert. Dies kann ja passieren ohne das man dann gleich an die Logik dahinter denkt. Erkennt die Logik nun, dass der Werk am Eingang kleiner ist als der zuletzt Empfangene, dann wird der Startwert (dritter Eingangsparameter) auf den letzten Wert des Logikausgangs (Zählerwertausgang) gesetzt und deckt sich ab diesem Moment nicht mehr mit dem ursprünglich vorgegebenen Startwert. Das sieht man dann bei mir im Doktormodus-Screenshot. Durch den Persistenzmodus wird nun dieser neue Wert erhalten, selbst wenn die Logik z.B. nach einem Update oder bei Stromausfall des Servers neu initialisiert. So läuft das bei mir sicher über ein Jahr auch nach Updates und Umbau im Verteilerkasten (also gewolltes Abschalten des TWS).
Der HAKEN in meiner Logik - neues Speichern oder Aktivieren
Was ich nicht umgesetzt habe ist der Fall, dass ich die Logik mal ändere (z.B. weil ich ein weitere Ausgangsobjekt hinzufüge) und deshlab neu Speicher. In dem Fall setzen sich auch alle internen Werte zurück, da hilft dann auch persistenz nichts. Und genau an dieser Stelle wäre dann vermutlich folgendes Konzept besser, aber noch nicht umgesetzt:
Der Startwert, der sich bei Nulldurchgang anpasst, sollte wohl auf einen zweiten Logik-Ausgang ausgeführt werden und von da in eine Zeitreihe geschrieben werden. Den Startwert-Eingang sollte man dann wirklich mit Verhalten U und
vor allem aber I und nicht als Festparameter wie bei mir übergeben. Nur so kann man das ungewollte Triggern nach einem Speichern durch eben das I verhinden. Diesen Eingang muss man ja nicht mit einem Objekt verschalten, sondern ich würde nach einem erneuten Speichern lediglich den Wert aus der Zeitreihe im Doktormodus als Startwert eintragen...das wäre vermutlich der Konigsweg.