Hi Stefan,
ich denke Deine Sorge ist in diesem Fall unberechtigt.
Warum:
A) Ich habe noch nicht wahrgenommen, dass Ihr gebeten wurdet Support für einen von den vielen komplexen Custom-Logiken zu bieten. Z.B. wird Euch keiner gefragt haben, warum bei ihm der Verschattungsbaustein von RobertMini nicht funktioniert. Diesen hat sich der User offensichtlich aus der Community gezogen. Genauso würde ich es auch hier erwarten.
B) Es bliebe dabei, dass der TWS nativ vorerst diese Datentypen nicht unterstützt. So würdet Ihr auch stets kommunizieren, nur dass es nun ein WorkAround aus der Community heraus gibt, mit der Nutzer des TWS eben doch einige der nicht unterstützten Datenpunkte eingeschränkt verwenden könnten. Es erfolgt keine sinnvolle Anzeige der Protokollwerte im Busmonitor, Grafana, Objektmanager etc., auch die direkte Nutzung in der Visu wird so nicht möglich sein. Das ist mir klar, würde ich aber zur Umsetzung meiner Vorhaben nicht brauchen. Ich würde die Werte dekodieren und dann die einzelnen Bestandteile auf Objekte in der Visu legen. (Beispiel 251.600 RGB ... da habe ich halt 3 einzelne Slider in CV oder TWS-Visu mit jeweils einem eigenen Wert...der KNX-Bus bekommt aber alle drei Werte im 251.600).
C) Der eigentliche Integerwert wäre mir völlig egal. Es kann auch gerne ein 32bit Wert sein, bei dem auch das bit für negative Zahlen genutzt wird. Der Datenpunkt ist ja lediglich Träger der KNX-Binärstruktur und wir werden ja dann sehen in welchen 24 der 32 bits der Datensatz hinterlegt ist. Wenn das einmal für Euren "DPT 10.xxx" definiert ist, dann ändert Ihr das ja nicht mehr.
D) Kein Nutzer wird von sich aus ohne Kenntnis/Lesen unserer Community-Bausteine den DPT10.xxx verwenden und dann trotz der Fehler beim Import auf einmal etwas damit machen wollen, wenn er nicht weiß, was er tut. Das macht ja heute auch niemand und der DPT 10.xxx liefert ja auch heute bereits undokumentiert Daten - nämlich genau die gleichen wie DPT 10.001. Es wird also niemanden stören/auffallen, dass DPT10.xxx nun anstelle von 10.001 als Integerzahl interpretiert wird. Ausser, ein Nutzer nutzt heute dn DPT10.xxx fälschlicher Weise als DPT10.001 und ignoriert bei jedem ETS-Upload im TWS die Fehlermeldungen...glaube nicht, dass das jemand macht.
E) In den Beschreibungen der "
Community Bausteinen zu Dekodierung und Codierung von im TWS nicht nativ vorhandenen DPTs" würden wir ja auch Funktionsbeschreibungen mitgeben - wie bei jeder anderen Custom-Logik bisher auch. Darin würden wir z.B. schreiben können (gerne auch abgestimmt mit Dir):
Beispiel/Vorschlag
Community Decodierlogik für Ersatz von DPT 225.001
- Zum Zeitpunkt der Erstellung dieser Logik untersützt der TWS (V4.0) den DPT 225.001 noch nicht
- Mithilfe dieser von der Community erstellten Logik, ist ein Workaround geschaffen worden, um KNX-Aktoren und KNX-Sensoren, die ein Objekt vom DPT 225.001 nutzen, mit dem Logik-Editor des TWS interagieren zu lassen. Die nachfolgend bereitgestellte Custom-Logik zerlegt das Datentelegramm vom KNX in die zwei Bestandteile "Übergangs-Dimmzeit" und "Dimmwert" die gemäß KNX Spezifikation in dem DPT 225.001 übertragen werden.
- Der Eingangswert, den der TWS über das genutzte KNX-Objekt einliest, werden im Busmonitor, in den Zeitserien (auch Grafana-Auswertungen) und in dem Objektmonitor nicht menschenlesbar angezeigt und können auch nicht direkt in der Visu verwendet werden. Die Ausgabewerte der nachfolgenden Customlogik sind dagegen verständlich und vom Menschen lesbar, werden aber ohne Einheiten im TWS geführt (in diesem Fall wären es ms und % gemäß KNX Spezifikation).
- Die Lösung bedient sich einem Behelfs-DPT der nicht in der KNX-Spezifikation defininert ist. Dieser wird beim Import in den TWS entsprechend mit entsprechenden Warnhinweisen erkannt.
- Es isteine Community-Lösung, für die Elabnet keine Haftung und keinen Support übernimmt.
- Der Workaround funktioniet nur, solange die ETS-Software das Verknüpfen von Datenpunkten der gleichen Länge innerhalb einer Gruppe zulässt. Beispielsweise ist es in der ETS-Version 5.7.6 ohne Weiteres möglich Kommunikationsobjekte vom Typ 225.001 und 10.* mit einer Gruppe des Typs 30.010 zu verbinden. Alle drei genannte Datentypen nutzen 24bit.