Speichern von Zuständen ohne Aktor

[willisurf]

Guter Punkt. Was Du versuchen könntest, wäre beim Ausgangs KO das S-Flag zu setzen und im Ausgangskonverter einzustellen, das nur bei veränderten Werten gesendet werden soll (diese Einstellung ist nur in den neuesten Versionen vorhanden).

Anmerkung am Rande, falls Du die Firmware Logikmodul benutzt, könntest Du ohne Navhteile auf due Firmware Sensormodul wechseln (auch wenn Du keine Sensoren hast). In der Firmware ist das identische Logikmodul, aber noch weitere Module zusätzlich enthalten (u.a. Virtual PM, Virtual Buttton,..)

[Eraser]

Was Du versuchen könntest, wäre beim Ausgangs KO das S-Flag zu setzen ...

Das S-Flag am Ausgang würde bedeuten, dass ich vom KNX-Bus aus das Ausgangs-KO beschreiben kann.
Was würde das hier an der Situation ändern?

... und im Ausgangskonverter einzustellen, das nur bei veränderten Werten gesendet werden soll ...

Dadurch würde bei einem Signalwechsel trotzdem der Ausgang auf die GA schreiben.

... (diese Einstellung ist nur in den neuesten Versionen vorhanden).

Ich verwende die letzte OAM-LogicModule 3.5.2
Frage nebenbei: Was ist das OFM-Logicmodule und wo ist der Unterschied zum OAM?

... falls Du die Firmware Logikmodul benutzt, könntest Du ohne Navhteile auf due Firmware Sensormodul wechseln (auch wenn Du keine Sensoren hast). In der Firmware ist das identische Logikmodul, aber noch weitere Module zusätzlich enthalten (u.a. Virtual PM, Virtual Buttton,..)

Interessant, wäre mir das mal ansehen.
Die Frage, warum nicht gleich nur das SensorModul dass verwendet werden soll habe ich mir selber beantwortet:

Anmerkung: Für alle, die neu anfangen wollen und darüber Nachdenken, nur das Logikmodul oder nur das Präsenzmodul zu installieren, ist von mir die Empfehlung, das Sensormodul zu nehmen. Die Teile, die nicht gebraucht werden, muss man nicht nutzen und sie belasten auch das System nicht. Und langfristig besteht der Plan, dass das Präsenzmodul komplett im Sensormodul aufgeht. Und dann erspart man sich den Umzug von der einen auf die andere Applikation.

Eine andere Frage:
Wenn ich Transfer-Strings aus Beispielen vom Forum im Logikmodul importiere, bekommt man eine Meldung, dass das Logikmodul eine andere Version hat.
Ist es die richtige Vorgehensweise, hier einfach die Kompatibilitätsprüfung auf "lockerer" zu stellen?


Danke für deine Antworten.

[willisurf]

Das S-Flag am Ausgang würde bedeuten, dass ich vom KNX-Bus aus das Ausgangs-KO beschreiben kann.
Was würde das hier an der Situation ändern?

Da dann bereits bei einem normalen Senden das Ausgangs KO beschrieben wird, sollte eigentlich nicht nochmal der gleiche wert doppelt gesendet werden.
Bei einem Signalwechsel würde auch der Ausgang beschrieben werden. Probier das einfach mal aus, würde mich interessieren.

Eine andere Frage:
Wenn ich Transfer-Strings aus Beispielen vom Forum im Logikmodul importiere, bekommt man eine Meldung, dass das Logikmodul eine andere Version hat.
Ist es die richtige Vorgehensweise, hier einfach die Kompatibilitätsprüfung auf "lockerer" zu stellen?

Ja, es ist nur ein Hinweis das Importergebnis danach etwas genauer anzuschauen.

[Eraser]

Hab es probiert mit dem S-Flag und es funktioniert nun wie gewünscht, keine doppelten Telegramme mehr 👍

Wäre es nicht möglich, die Firmware so anzupassen, dass bei der Logik-Funktionsauswahl direkt eine Funktion für "Wert speichern" auswählbar ist,
bei der dann die KO's mit den Flags gleich richtig gesetzt werden?

Ich denke das wäre für andere auch hilfreich.

Kannst du mir noch den Unterschied zwischen OFM und OAM-LogicModule erklären?
Beim Sensormodul sieht es so aus, als ob das OFM im OAM integriert ist.

Danke für deine Hilfe.

[willisurf]

Die Flags sind sinnvoll für Ein- und Ausgänge vorbelegt. Die ETS kann die Einstellungen nicht dynamisch ändern.
Die Funktionalität „Wert speichern“ bezieht sich primär erstmal nur auf den Eingang. Daher muss man bei solchen speziellen Anforderungen die Flags manuell anpassen.

Den Unterschied zu den Modulen kann mumpf viel besser erklären .

[mumpf]

Auch hier von mir ein paar Anmerkungen als Ergänzung zu Bernhards willisurf hervorragenden Ausführungen (Danke dafür):

Was Du versuchen könntest, wäre beim Ausgangs KO das S-Flag zu setzen und im Ausgangskonverter einzustellen, das nur bei veränderten Werten gesendet werden soll (diese Einstellung ist nur in den neuesten Versionen vorhanden).

Diese beiden Punkte gehören zusammen. Der Ausgangskonverter bezieht sich auf das Ausgangs-KO und arbeitet nur mit dessen Werten. Es gibt z.B. Formeln, die den Ausgangswert inkrementieren (um 1 erhöhen) oder eben auch den Ausgang nur senden lassen, wenn dessen Wert sich vom vorherigen KO-Wert unterscheidet.
Somit ist die Einstellung "nur bei geänderten Werten senden" im Ausgangkonverter elementar anders als z.B. der Trigger "nur bei geändertem Ergebnis". Es wird beim Senden einfach der zu sendende Wert ausgerechnet, dann geschaut, ob der Wert im KO gleich ist - und wenn nicht, wird gesendet.

Wäre es nicht möglich, die Firmware so anzupassen, dass bei der Logik-Funktionsauswahl direkt eine Funktion für "Wert speichern" auswählbar ist,
bei der dann die KO's mit den Flags gleich richtig gesetzt werden?

Ich denke das wäre für andere auch hilfreich.

Nein, das werde ich nicht machen. Das Logikmodul bezieht alle KNX-Möglichkeiten ein, um die Funktionalität zu bieten. Dazu zählt auch die Kenntnis von Flags und deren Nutzung. Würde ich verschiedene Flags für verschiedene Kombinationen setzen wollen, gekreuzt mit verschiedenen DPT, würde das nicht nur zu immens vielen internen Ausgangs-KO führen (für User nicht sichtbar, sind aber jetzt schon 12, würden dann >50 werden), es würde auch dazu führen, dass bei sehr vielen Logikänderungen die Meldung kommen, dass GA entfernt werden, die man dann erneut verknüpfen müsste. Letztendlich wäre es eine schlechtere User-Experiance als jetzt.

Was ist das OFM-Logicmodule und wo ist der Unterschied zum OAM?

Das ist Teil unseres Modularisierungskonzeptes. OFMs sind shared objects, das OFM-LogicModule implementiert die gesamte Logik und die ETS-Applikation, um diese Logik zu parametrieren. Also all das, was Du in der ETS in dem Teilbaum "Logiken" siehst. Dieser Teil kann von vielen Applikationen einfach genutzt werden, so wie er ist, ähnlich einem Include.

OAMs sind die Teile, die auf ein bestimmtes Gerät installiert werden können, im Allgemeinen eine Aggregation von mehreren Modulen. Selbst beim OAM-LogicModule wird neben dem OFM-LogicModule auch noch unser Common verwendet, dass die globalen Settings ermöglicht, und unser Network-Modul, falls es ein Logikmodul-IP ist.

Durch die Verwendung vom OFM-LogicModule in fast allen unseren Modulen kann ich auch ruhigen Gewissens behaupten, dass es immer das SELBE Coding ist, dass in allen Modulen läuft.

OFM sind nur für Entwickler wichtig, die OAM erstellen wollen. Als Enduser wirst Du nur mit OAM konfrontiert.

Gruß, Waldemar