ElabNET Technik Forum

Basierend auf der Diskussion um Reboot etc. hat @EarlBacid eine super Übersicht zum Thema Flags in KNX gepostet (viewtopic.php?f=31&t=1776&start=20#p18896).

Ich habe diese Information in der KB eingearbeitet (app.php/kb/viewarticle?a=122) und versucht eine Empfehlung für Flags (insbesondere L- und I-Flag) zu geben.
Könnte ihr das bitte lesen und kommentieren, Ergänzungsvorschläge posten etc.?

Danke und lg
Robert

moin moin,

danke für die Lorbeeren, aber ich hab nur den Text von der KNX Association kopiert.
Im KB Artikel muss dann evtl. meine Verabschiedung nicht mehr am Ende stehen

Ansonsten, denke ich, dass der Artikel soweit ok ist und die Besipiele den Verwendungszweck gut veranschaulichen.
Letzten Endes sind die Flags aber ganz normaler KNX Funktionsumfang, der für jemanden, der selbst einen KNX Bus betreiben will, eigentlich zu den Grundlagen gehören sollte, unabhängig vom Einsatz des TWS.

VG
Earl

Passt, guter Artikel

Finde ich einen sehr guten Artikel zur doch recht komplexen Thematik.

Vielen danke

Gruss
Dani

Ich habe mich im Rahmen der "GA-Aufräumarbeiten" nun auch mit den Flags beschäftigt, die in der Tabellel für den Timberwolf Importer angelegt werden sollten. Wenn schon, dann richtig!

Um nun zu einer Art "Schema" zu kommen, habe ich mir neben dem oben verlinkten KB-Artikel auch den "offiziellen" Erklär-Artikel der KNX Association in deutsch und englisch durchgelesen und noch einmal das Webinar der KNX Association zum Thema angeschaut, da das einfach für mich zu lange her war. Danach habe ich mir die aktuell in der ETS eingestellten Flags für verschiedene Arten von KOen angeschaut und verglichen.

Erster Entwurf eines Schemas für verschiedene Objekttypen für den TWS:

Typ	Erklärung	Flags EN	Flags DE
KNX Switch	Schaltobjekte von KNX-Geräten, z. B. E/A, DIM, WERT	C--T--	K--Ü--
KNX Status	Statusobjekte von KNX-Geräten, z. B. RM, RM WERT, IST_TEMP, DIAGNOSE	C-W-U-	K-S-A-
KNX Hybrid	Hybridobjekte von KNX-Geräten, z. B. Sperrobjekte, Sommer-Winter, Tag-Nacht	C-WTU-	K-SÜA-
TWS Switch	Schaltobjekte von TWS-Geräten, z. B. Multi-IO-Outputs, Logikeingänge	CRWT--	KLSÜ--
TWS Status	Statusobjekte von TWS-Geräten, z. B. Datum/Uhrzeit, 1-W-Temperaturfühler, Logikausgänge	CR-T--	KL-Ü--
TWS Hybrid	Hybridobjekte von TWS-Geräten, z. B. Sperrobjekte, kombinierte Logikein-/ausgänge	CRWT--	KLSÜ--

Das I-Flag habe ich nirgends als Default gesetzt, würde ich bei Bedarf individuell für einzelne KO einstellen, wo es benötigt wird.

Was haltet ihr von dem Schema und den Flags? Macht das Sinn und vor allem: würde das so funktionieren?

Bei den Statusobjekten fehlt mir das Read. Auch den Hybridobjekten würde ich eher auch ein Read verpassen.

TWS Switch: Da würde ich Read als Einzfallbetrachtung sehen.
TWS Hybrid: Auch da würde ich Read als Einzelfallbetrachtung sehen und U noch dazunehmen.

So als Kochbuch und Orientierung gut

Mit KNX-Geräten sind die üblichen KNX-Teilnehmer gemeint, z. B. ein Dimmaktor, Taster, PM.
Diese verwalten ihre Status-Objekte (z. B. aktueller Dimmwert, gemessener Helligkeits- oder Temperaturwert) selbst. In der Regel haben diese Objekte in den Geräten auch keinerlei Schreibmöglichkeiten vom Bus, also dort fehlen W und U (S und A) Flags. Bei einer Leseanfrage auf der GA wird also dieses KNX-Gerät eine Antwort senden. Warum sollte deiner Ansicht nach der TWS auf der gleichen GA zusätzlich eine Antwort senden (=Read/Lese Flag)?

Würde hier auch mein PDF einwerfen.

@gurumeditation Unter dem Bereich TWS Switch = Logikeingang sehe ich allerdings eher weniger das L Flag.

Streng genommen hast du natürlich Recht, vor allem für Logikeingänge.
Wie ist es aber bei 1-Wire Schaltaktoren (z. B. Multi-IO Outputs)? Die haben soweit ich weiß in der 1-Wire Applikation nur ein (1) Objekt, keine getrennten Objekte für Schalten und Status wie bei KNX üblich, oder? Das war der einzige Grund für meine Überlegung, dort L (R) zu hinterlegen.