FREIGEGEBENE HAUPTVERSION V 4.01 verfügbar!
LOGIK! VISU! IFTTT! FIXES!
Infos im Wiki: https://elabnet.atlassian.net/l/cp/TrZ03Nr7

NEU! Ausführliches Video Tutorial zur VISU
Jetzt werden alle Fragen beantwortet. Das Video: https://youtu.be/_El-zaC2Rrs

[Gelöst] [V4.0.1] Fehlermeldungen zu Differenzen der DPTs beim Laden des KNX-Projektes

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
Benutzeravatar

Parsley
Reactions:
Beiträge: 574
Registriert: Di Okt 09, 2018 7:27 am
Wohnort: 490..
Hat sich bedankt: 631 Mal
Danksagung erhalten: 379 Mal

#11

Beitrag von Parsley »

Moin zusammen
jhaeberle hat geschrieben: Mo Jul 01, 2024 4:55 pm … wenn ich das in der ETS auswählen kann, sollte es in der TWS-Oberfläche keinen Fehler geben
Jein. Die ETS lässt einiges an DPT Einstellungen durchgehen, was soweit ich weiß am Ende durchaus zu Fehlfunktionen führen kann, wenn man nicht aufpasst. Die ETS prüft z.B. nur ob ein 2-Byte DPT auf einen 2-Byte DPT verknüpft wird. Aber ob die verknüpften Geräte des Wert auch gleich interpretieren ist der ETS egal.
Darum finde ich es sehr gut, dass der TWS diese Schwäche der ETS auffängt und eben doch mehr Fehler und Warnungen anzeigt als die ETS.

PS: Göran war schneller.
Gruß Parsley



Timberwolf Server 3500L #657 (VPN offen, reboot nach Absprache)
Bitte WIKI lesen.

Ersteller
jhaeberle
Reactions:
Beiträge: 25
Registriert: Do Aug 24, 2023 11:07 am
Hat sich bedankt: 11 Mal
Danksagung erhalten: 2 Mal

#12

Beitrag von jhaeberle »

okay, das leuchtet ein. Der Fehler liegt also wohl (eher) bei der ETS.

Danke, Gruß
Jochen
TWS 3500XL, #1409

Robosoc
Reactions:
Beiträge: 1897
Registriert: Di Okt 09, 2018 9:26 am
Hat sich bedankt: 641 Mal
Danksagung erhalten: 786 Mal

#13

Beitrag von Robosoc »

Ich hatte diese Diskussion ein wenig mitverfolgt. Nach allem wie ich die KNX-Spezifikationen bisher verstanden habe, würde ich hier nicht von Fehler bei dem Einen oder Anderen sprechen. Elabnet hat sich - und das ist vollständis in Ordnung - dazu entschlossen die Nutzung als Fehler einzustufen. Die ETS lässt die Nutzung zu - auch in Ordnung aus meiner Sicht. (siehe Details zu meiner Einschätzung weiter unten)

Hier wurde kürzlich wieder über DPT's diskutiert, die noch gewünscht sind. Ich denke für jeden von uns Nutzern ist nachvollziehbar, dass es ein riesigier Aufwand ist die vielen, komplexen KNX-DPTs zu integrieren und dies sicher in der Prio hinter anderen Themen steht, die wichtiger und mächtiger sind. Das bedeutet aber natürlich auch: Es wird teilweise noch lange dauern, bis die von aktuellen TWS-Nutzern benötigten DPTs zur Verfügung stehen und in eininge Fällen wird dies vielleicht nie der Fall sein, weil es immer wichtigeres geben wird.

Deshalb wünsche ich mir weiterhin sehr, dass die Nutzung der Hauptgruppen-DPTs im TWS ermöglicht werden - darf auch gerne weiterhin mit Fehlermeldung oder Warnung sein. Das ist hoffentlich ein vergleichsweise niedriger Aufwand für Elabnet (Vergleich mit dem ermöglichen vieler individueller DPTs) und bringt uns Nutzern Aktionsspielraum und wir können die Community nutzen um mit Customlogiken dann doch die Interpretation von den speziellen DPTs zu ermöglichen.

Siehe genau dazu z.B. auch meinen älteren Vorschlag hier




---
Details aus meinen Recherchen zu DPTs (bin kein Experte, ich mag fehlerhaft interpretiert haben):
Die KNX Datentypen sind in der sehr umfangreichen KNX Systemspezifikation definiert, die ich aktuell z.B. unter folgendem Link gefunden habe
https://support.knx.org/hc/en-us/articl ... oint-types

Darin sind die Datentypen mit x.000 nur in wenigen Ausnahmen definiert. (z.B. findet man 14.000, 15.000 und 16.000. Im Falle von 15.000 auch einmal unglücklich in einer Überschirft). Siehe vor allem Kapitel 2

Durch Kapitel 1.1 wird gezeigt, dass die Hauptnummer eines DPTs (also die DPTs-Zahl vor dem Punkt) bereits ausreicht um das Format und die Codierungsschlüssel zu definieren. In Kapitel 1.2 ist die 0 als Subnummer (also die DPTs Zahl nach dem Punkt) explizit erlaubt.

Die Spezifikation sagt in Kapitel 1.5 dann jedoch:
KNX Datapoint Types not only identify the format and the encoding, but also the range and the unit. Consequently, there are no “generic” Datapoint Types that only identify the format as commonly known fro programming languages.

Nun ist Letzteres aber nicht sichergestellt und die Nutzung der undefinierten x.000 Datentypen ist für mich persönlich eine Grauzone mit Risiken, aber auch Möglichkeiten.
Zuletzt geändert von Robosoc am Mi Jul 10, 2024 8:54 am, insgesamt 1-mal geändert.
VG, Sven - 3500 XL ID:1369 | 3500 L ID:1355, VPN offen, Reboot OK
Antworten

Zurück zu „KNX“