KNX/EIB Speichern von Zuständen / Statusführung

[Soundman]

Hallo zusammen,

mal 'ne Frage zum Thema .
Im Beitrag https://knx-user-forum.de/forum/öffe...90#post1957690 wurde von mumpf empfohlen, für die Statusführung "...ein Logikkanal als Identität, 1 Eingang direkt auf Ausgang, 1 wird zu 1, 0 wird zu 0." zu verwenden. Klappt auch super, danke!
In dem selben Thread wurde mir ebenfalls von mumpf der Hinweis auf die Verwendung von "KLSÜ" auf einem KO gegeben.

Ich benutze nun das OpenKNX-Logikmodul so, dass ich nur einen Eingang einer Logik einfach mit "KLS-A" als Flags parametriere (die Logik ist eigentlich egal, ich nehme ODER, der Ausgang interessiert auch nicht), dann kann ich über ein Schreiben auf die entsprechende GA einen Wert setzen und bei einer Leseanforderung bekomme ich dann den gesetzten Wert wieder. Das klappt beim OpenKNX-Logikmodul sogar mit Gleitkommawerten (z.B. DPT 9.xxx).

Hintergrund ist der, dass ich meine Außentemperatur über einen Luftdaten-Feinstaubsensor erfasse und per NodeRed und dann an KNX weitergebe.
So kann ich dann per Read auf die GA den letzten Wert abfragen.
Nutze dieselbe Methode auch für Energiewerte, die nicht periodisch erfasst werden.

Gibt es evtl. noch eine "elegantere" Methode so eine Statusspeicherung zu machen? Ich möchte das auf jeden Fall ohne EIB-PC, GIRA-X1 oder ähnlichen realisieren.

Danke & Gruß
Andreas

[gbglace]

gerade bei solchen Klimasensorwerten kann ich den Sinn einer solchen Speicherung nicht nachvollziehen.
Wenn der Wertgeber kaputt ist, sollte man schnellstmöglich feststellen das dem so ist und nicht im Winter das lezte kaputte Zucken in Form einer Sommerlike Temperatur ewig im System haben.

Warum macht Ihr euch immer soviele Gedanken darum das man soviele Werte per Lesetelegramm abrufen können muss. Im KNX ist das doch eher ein seltenes Bedürfnis der Geräte das zu tun (reboot der Anlage).

Andere Geräte die gerne solche Lesetelegramme starten sind meiner Meinung nach schlecht gebaute Softwarelösungen die per IP an den KNX gekoppelt sind. Da sollte man dann besser schauen das diese "Server"-Systeme sich das Zeug einfach selbst persistieren, wenn sie denn so oft rebooten müssen.
Anderen falls treffen sie auf ein lebendes KNX-System udn dann kann auch einfach der am Sensor nächstgelegene Teilnehmer eine solche Leseanfarge beantworten. In Deinem Falle das Nodered und nicht das Logikmodul.

[Soundman]

gbglace : Oh, man VIELEN DANK für Deine Meinung, DAS war hier aber nicht gefragt!
Es ging hier nicht um die Sinnhaftigkeit, sondern um die technische Art der Umsetzung.

Sobald man verschiedene Steuerungssysteme über verschiedene Wege (IP, Funk, Modbus, IEC, MQTT, etc.) koppeln möchte, muss man sich eben auch überlegen, WO (in welchem System) man WAS persistieren möchte. Ich frage hier, was es an nativen Möglichkeiten im KNX-System gibt. Nicht mehr und nicht weniger. Die Entscheidung, WIE ich das dann Schlussendlich realisiere ist nach wie vor meine Entscheidung.


PS: Klar, in einer "Idealen Welt" habe ich alles mit EIB/KNX realisiert. Dem ist aber nun mal nicht so, da es bestimmte Funktionen entweder nicht nativ im KNX Universum zu kaufen gibt oder diese einfach "unbezahlbar" sind. (z.Bsp. ein Feinstaubsensor für den Außenbereich). Also muss ich die Einkoppeln, bzw. auch auf Stati aus dem KNX-Universum (immer) lesen können, um dann darauf zu reagieren.

[gbglace]

OK ich koppele IoT Devices eben über meinen KNX 24/7 Homeserver (Timberwolf 2600). Der hat an der Stelle für alles was auf den KNX geleitet werden soll native in der ETS parametrierte KO und da kann ich das dann entsprechend des KNX Standards mit den Flags steuern, was er sich selbst zieht bzw. anderen zum Lesen anbietet oder eben aktiv sendet oder passiv horcht. Der Server ist da quasi Owner der Daten im KNX.
Ansonsten hat der auch ein MQTT Subsystem wo man das Systemverhalten im Broker nutzen kann. Der MQTT Broker läuft dabei auch auf diesem Server in einem Container. Alles was wichtige Logiken in diesem Server sind kann ich dort auch persistieren an Eingangs-Parametern, so dass diese unabhängig von Zuliefersystemen sich selbst die letzten Werte speichern, um zumindest eine Initialisierung hinzubekommen, ein KNX-Wert kann mit gesetzten I-Flag sich dann auch bei Reboot selbst frische Daten heranholen vom Bus. In der Regel ist der Bus schneller gebootet als der Server.

Da ich mit dem Server recht glücklich in Sachen Stabilität bin, vermeide ich auch Werte auf den Bus zu schicken, die da nicht direkt gebraucht werden (Anzeige am Taster). Ja Logiken mit Bezug zu IoT Devices sind da auf dem Server zentralisiert, aber da ich solche IoT Devices auch nicht via Taster bediene sehe ich da meist auch keinen Grund das auf dem KNX zu haben. Die gesamte PV Steuerung usw läuft da quasi neben dem KNX. Speicherung in Datenbanken und Visualisierung braucht kein KNX für unzählige Zählerstandsaktualisierungen und die notwendige hochfrequente Kommunikation mit dem ESS, den verschiedenen WR und später WP und WB, die eh alle nur per MQTT oder Modbus-TCP angebunden sind. Allein das müsste in eine separate Linie, um die Telegrammlast im Zaum zu halten.

Insofern habe ich derzeit im open-KNX Logikmodul vorwiegend die VPM Funktionalität realisiert und das Backupverhalten, um bei kaputter Logik, dann per Tasterdirektbedienung noch ans Licht zu kommen da die DMX-Treiber auch per Weinzierl KNX-DMX GW angesprochen werden.

Alles was selbst keine native KNX-Kommunikation kann lasse ich auch primär fern vom KNX. Insofern läuft hier im KNX das was dessen primäre Domäne ist. Licht und Heizung, Präsenzerkennung, Indoor Klimasensorik (sukzessive Ablösung von 1-wire). Rollo habe ich nur wenige im Haus.

[willisurf]

Ich benutze nun das OpenKNX-Logikmodul so, dass ich nur einen Eingang einer Logik einfach mit "KLS-A" als Flags parametriere (die Logik ist eigentlich egal, ich nehme ODER, der Ausgang interessiert auch nicht), dann kann ich über ein Schreiben auf die entsprechende GA einen Wert setzen und bei einer Leseanforderung bekomme ich dann den gesetzten Wert wieder. Das klappt beim OpenKNX-Logikmodul sogar mit Gleitkommawerten (z.B. DPT 9.xxx).

Mache ich auch so, für native KNX sicher eine probate Methode. Nebenbei bemerkt, Du kannst auch beide Eingänge (sogar mit unterschiedlichen DPT) nutzen, falls die Kanäle knapp werden sollten.

[mumpf]

Gibt es evtl. noch eine "elegantere" Methode so eine Statusspeicherung zu machen?

Du kannst im KNX jedes KO eines jeden Gerätes mit passenden Flags (KLS) sowohl beschreiben wie auch lesen. Solang Dir das Gerät nicht dazuwischenfunkt, indem es selbst was in das KO schreibt oder indem es auf das, was Du reinschreibst nicht ungewollt reagiert. Insofern sind Logikeingänge (wiederum egal welchen Gerätes) besonders geeignet, da dort sicherlich nichts von dem Gerät reingeschrieben wird und - solange man den Logikausgang nicht nutzt - man auch selber mit reinschreiben nichts unbeabsichtigt verändert.

Mein OpenKNX-Logikmodul hat diesbezüglich 2 Besonderheiten gegenüber vielen Logikmodulen, die Du sonst in KNX findest:

1. Es erlaubt die üblichen DPT als Eingang zu definieren, die meisten anderen lassen nur DPT1 zu (boolesche Logiken)
2. Ich erlaube für meine Logikeingänge eine echte Persistenz auch über den Stromausfall hinaus (muss man aber entsprechend aktivieren).

Deswegen würde ich sagen, eleganter wirst Du Dein Ansinnen nicht erfüllen können, aber ich bin auch "befangen" .

Gruß, Waldemar

[Soundman]

gbglace: Moin, ich kann nur um Entschuldigung bitten, wie ich die Antwort formuliert habe. Es war nichts gegen Dich.
Leider musste ich die Erfahrung machen, dass das Leben nicht so lange währt, wie man(n) sich das manchmal vorstellt. (https://www.mz.de/lokal/weissenfels/...m-auto-3669791, mein Sohn😭)
Ich plane inzwischen so, dass alles auch laufen muss, falls ich nicht mehr da bin. Deshalb auch meine Fragestellung in diese Richtungen.
Ich bin ein KNX-Neuling, hatte aber seit 2014 Homematic bei mir im Einsatz. Klar kann ich alles so programmieren und "feintunen" das alles läuft (auf NodeRed, Timberwulf, OpenHab), ABER was ist, wenn ich nicht mehr bin? Deshalb bin ich auf KNX umgestiegen, da hat ggf. meine Frau noch die Chance einen Elektriker zu finden, der davon Ahnung hat.
Die Infos aus dem Forum finde ich extrem wertvoll! Ebenso das Logikmodul von mumpf. Ich bin aus den o.g. Gründe aber jetzt dazu übergegangen, die "elementaren" Logiken auf einen X1 umzusetzen. Da ist die Wahrscheinlichkeit höher ist, das ein x-beliebiger Elektriker das Teil kennt.
Ich werde weiter das OpenKNX Logikmodul einsetzten. Bin gerade dabei, die SW-Entwicklungsumgebung einzurichten. (Mich interessiert nur der Anschluss eines BME680 bzgl. des Luftdruck). Das ist allerdings "Hobby". Deshalb probiere ich vieles "nativ" im KNX umzusetzen.
Danke auf jeden Fall an Euch vom Forum, ohne Euch währe ich nicht so weit!
Gruß
Andreas