[DISKUSSION] [V4.0 IP11] Umgang mit Flags im KNX-Subsystem

Diskussionen über die KNX-Funktionen im Timberwolf Server
Forumsregeln
  • Denke bitte an aussagekräftige Titel und gebe dort auch die [Firmware] an. Wenn ETS oder CometVisu beteiligt sind, dann auch deren Version
  • Bitte mache vollständige Angaben zu Deinem Server, dessen ID und dem Online-Status in Deiner Signatur. Hilfreich ist oft auch die Beschreibung der angeschlossener Hardware sowie die verwendeten Protokolle
  • Beschreibe Dein Projekt und Dein Problem bitte vollständig. Achte bitte darauf, dass auf Screenshots die Statusleiste sichtbar ist
  • Bitte sei stets freundlich und wohlwollend, bleibe beim Thema und unterschreibe mit deinem Vornamen. Bitte lese alle Regeln, die Du hier findest: https://wiki.timberwolf.io/Forenregeln
Antworten

Ersteller
blaubaerli
Reactions:
Beiträge: 2366
Registriert: Sa Sep 15, 2018 10:26 am
Wohnort: Kerpen
Hat sich bedankt: 902 Mal
Danksagung erhalten: 704 Mal

[V4.0 IP11] Umgang mit Flags im KNX-Subsystem

#1

Beitrag von blaubaerli »

Hallo zusammen,

wie gerade hier angedeutet, habe ich hier offensichtlich noch Aufschlauungsbedarf... :whistle: :confusion-scratchheadyellow:

Ich war bisher davon ausgegangen, dass über die Applikation des Herstellers in der ETS auch durchgehend zwangsweise vorgegeben wird, welche Flags an den entsprechenden KOs überhaupt gesetzt werden können. Das scheint in der Tat nicht wirklich so zu sein. Es gilt offensichtlich ein klares sowohl als auch. Das Häkchen "Lesen bei Init" ist bei diversen Devices ja ausgegraut. Daher scheint es da also doch grundsätzlich eine Einflussmöglichkeit zu geben.

Mir ist nun aber damit noch nicht ganz klar, ob ein KNX-Device zwingend auf in der ETS gesetzt Flags reagieren muss.
gbglace hat geschrieben: Mi Mai 01, 2024 12:11 am Und somit kann man dann neben dem S Flag auch noch das L Flag setzen und dann solte das KO auch mit diesem letzten empfangenen oder auch selbst gesendeten Wert antworten.
Hier irritiert mich der Konjunktiv.

Wenn ich in unterschiedliche Dokus zu Geräten schaue, die bei mir im Einsatz sind, dann stelle ich wieder fest, dass es da ein total unterschiedliches Bild gibt. In einem Handbuch von MDT finde ich z.B. folgende Passage:
Aus der oben stehenden Tabelle können die voreingestellten Standardeinstellungen entnommen
werden. Die Priorität der einzelnen Kommunikationsobjekte, sowie die Flags können nach Bedarf
vom Benutzer angepasst werden. Die Flags weisen den Kommunikationsobjekten ihre jeweilige
Aufgabe in der Programmierung zu, dabei steht K für Kommunikation, L für Lesen, S für Schreiben, Ü
für Übertragen und A für Aktualisieren.
Also da wird tabellarisch "nur" die Standardeinstellung dokumentiert und man kann sich das in der ETS entsprechend umstellen.

In einer Dokumentation von Merten wird das schon konkreter:
Bild
Hier ist auch der Default dokumentiert und das "(L)" jeweils in Klammern als optional setzbar erwähnt. An einigen Objekten fehlen nun einige Flags in der Doku, sind in der ETS aber setzbar. Was muss das Device da nun können? Das was der Hersteller dokumentiert hat, oder mehr?

Bei den nächsten Herstellern gibt es "nur" eine Tabelle aus der nicht hervorgeht, ob es sich um die gesetzten Defaults, oder die vom Gerät am jeweiligen KO grundsätzlich unterstützten Flags handelt....

Ihr seht mit ein wenig "Lost in Space" :confusion-scratchheadyellow:

Beste Grüße
Jens
wiregate1250 & timberwolf168 (2600er), VPN offen, Reboot nach Vereinbarung
Bitte WIKI lesen.

gbglace
Reactions:
Beiträge: 3629
Registriert: So Aug 12, 2018 10:20 am
Hat sich bedankt: 1276 Mal
Danksagung erhalten: 1677 Mal

#2

Beitrag von gbglace »

Bei Gira gibt/hab es eine Zeit da hatten die Flags keine sinnvolle Default-Einstellung um als Gerät den Ihm zugewiesenen Standardfunktionsumfang zu erfüllen.

Wie gesagt die Flags steuern zuerst den KNX Stack des jeweiligen Gerätes also die direkten Kommunikationseigenschaften von und zum Bus.

Die sonstigen Applikationseinstellungen in der ETS sind dann das Parameterset für die Firmware des Gerätes, damit dieses dann mit den Informationen vom KO was sinnvolles tut.

Insofern wird eben ein Gerät mit aktiviertem L Flag antworten ob das ganze dann aber in der Applikation zu einem Sinnvollen Verhalten führt ist eine andere Frage.
Die Applikation selbst entscheidet ja nicht mehr nach Telegrammtyp. Es ist also ein Unterschied ob nun bei einem Aktor das S oder/und das A Flag aktiviert ist. Ein S bedeutet ein eingehendes Telegramm GroupValuenWrite mit 1 schaltet den Kanal AN. Aber mit einem aktivierten A würde der Aktor eben auch/nur schalten wenn ein GroupValueRespond mit einer 1 ankommt.

Das ist der Applikation egal. Die Flags sagen dem KNX Stack nur ob die Nutzlast am KO an die Firmware durchgereicht wird ja/nein.

Bei dem L-Flag bin ich selbst etwas unsicher ob man über die Firmware da differenzierte Informationen generieren kann. Entweder aus dem Speicher des KNX-Stack einfach die letzte Tekegramminfo die am KO Anlag als Antwort senden oder ob die Firmware dann ich Malm wirklich indisch schaut und einen effektiven Status holt und sendet. Es könnte ja sein das man am Aktor ein L aber kein Ü Flag gesetzt hat am Status-KO, da ist dann die Frage wie ist in dem Falle die Kommunikation von Firmware zu Stack und KO effektiv umgesetzt. Liegt der Status vom Relais im Stack vor, würde nur nicht aktiv gesendet (kein Ü Flag) aber eine Leseanfrage kann direkt beantwortet werden. Oder ist der KO-Speicher leer und bei eingehender Leseanfrage muss erst der Relaisstatus aktiv ermittelt werden um gesendet werden zu können.

Keine Ahnung ob das in der KNX Spec vorgeschrieben ist.

Meine Erfahrung ist nur, das wenn man die Flags entsprechend einstellt, auch immer was.passiert entlang der Flags. Aber ich habe mich nicht soviele unterschiedlichen Geräte hier im Haus.

Aber sowas lohnt ja mal auszuprobieren.
Grüße
Göran

#1 Timberwolf 2600 Velvet Red TWS #225 / VPN aktiv / Reboot OK
#2 Timberwolf 2600 Organic Silver TWS #438 / VPN aktiv / Reboot OK
#3 PBM 3 Kanäle, #4 Modbus-Extension
Antworten

Zurück zu „KNX“