[Problem] DALI-Dimmer / Effektansteuerung: Wie KNX DPTS 10.001 statt 225.001 nutzen?

[Robosoc]

Ich habe ein DaliGerät, welches ich mit DPTS 225.001 (3byte) ansprechen muss. Im TWS gibt's für 3byte aktuell (V3.0 IP) nur den DPTS 10.001.

Wenn ich in der ETS was auf die GA sende, mir die RAW Daten im Busmonitor des TWS ansehe, kommt das an, was ich gesendet habe.

Ets Eingabe 00 20 255 dezimal
TWS knx busmonitor raw 0014FF (= 00 14 FF)
Das Objekt 10.001 wird als Integer geführt, aber ich verstehe nicht wie die Umrechnung von drei zweistelligen Hex Werten ind eine Integerzahl läuft. Bildet man für jedes Duplet einen Dezimalwert und multipliziert diese?

[Robosoc]

So, jetzt wird es mal ein wenig theoretisch...ich hoffe, dass sich Jemand die Mühe macht mitzudenken. Wenn ich es am Ende versanden habe, gibt es demnächst einen RGB-Lauflicht Custom Logik von mir

Ich schreibe per ETS auf ein mit dem Timberwolf verknüfte GA des Typs DPTS-225.001 (3-byte). In der ETS-Timberwolf Parametrierung ist das verknüpfte Objekt als DPTS 10.001 angelegt (einziger aktuell verfügbarer 3-byte Typ im TWS). Die Datenpunkt-Typen sind erstmal nicht kompatibel, das ist mir klar. Da der TWS intern aber so oder so einen Integerwert aus dem Raw macht, sollte ich mir einen Konverter schreiben können. So hat es Stefan auch irgendwo mal angedeutet.

Dazu muss ich aber verstehen, wie aus dem KNX-Raw-Wert der interne TWS-Integerwert gebildet wird.

konkretes Beispiel - TEST 1:

• Eingabe in ETS: 0 20 255 -> (Dreimal Dezimaldarstellung) entspricht der Aussage, "Dimme auf 100% mit der Dimmgeschwindigkeit 100% / 2Sekunden = 50%/s"
• Die ETS Diagnose zeigt als Raw-Wert 00 14 FF an -> kann ich nachvollziehen
• Der TWS Busmonitor zeigt als Raw-Wert 0014FF an -> passt
• In Binärcode aufgelöst ist dies meiner Meinung nach 00000000 00010100 11111111 (A)
• Intern führt der TWS diesen Wert nun als Integer 1263 - gemäß Grafana Busauswertung bzw. Doktormodus
• Das wäre in binärcode 00000000 00000100 11101111 (B)
• Da bit7 und bit8 in den Octets 1 (LSB) und 2 des Datentyp 10.001 mit 0 definiert sind (siehe Screenshots unten), hätte ich zwischenzeitlich Folgendes befürchtet 00000000 00010100 00111111 (C), das wäre vermutlich die korrekteste Umsetzung, würde aber eine Konvertierung auf 225.001 unmöglich machen; ebenso, wenn im TWS Autokonverter die 4 bits einfach weggelassen werden würden -> 00000000 __010100 __111111 (D)

Zur besseren Übersichtlichkeit hier noch einmal untereinander dargestellt und die Änderungen zu (A) farbliche erkennbar:
00000000 00010100 11111111 (A) > Dezimal (Integer) = 5375
00000000 00000100 11101111 (B) > Dezimal (Integer) = 1263
00000000 00010100 00111111 (C) > Dezimal (Integer) = 5183
00000000 __010100 __111111 (D) > Dezimal (Integer) = 1343

TEST 2
Zum weiteren Verständnis habe ich in der ETS auch noch einen Zeitwert gemäß DPTS-Format 10.001 auf diese GA geschrieben

• Eingabe in ETS: Mittwoch, 08:41:57
• Die ETS Diagnose zeigt als Raw-Wert 68 29 39 an -> kann ich nachvollziehen
• Der TWS Busmonitor zeigt als Raw-Wert 682939 an -> passt
• In Binärcode aufgelöst ist dies meiner Meinung nach 01101000 00101001 00111001 (A)
• Intern führt der TWS diesen Wert nun als Integer 31317 - gemäß Grafana Busauswertung bzw. Doktormodus
• Das wäre in binärcode 00000000 01111010 01010101 (B)

Zur besseren Übersichtlichkeit hier noch einmal untereinander dargestellt, es lohnt nicht die Änderungen farblich zu markieren:
01101000 00101001 00111001 (A) > Dezimal (Integer) = 6826297
00000000 01111010 01010101 (B) > Dezimal (Integer) = 31317

Das zumindest scheint mir ein Nachweis zu sein, dass ich die Konvertierung nicht mittels Binärcode nachvollziehen kann.
Aber was nun? Habe ich eventuell einen Gedankenfehler gemacht?

[Robosoc]

Mist, ich glaube ich habe es verstanden und das Ergebnis will mir für meine Aufgabe so gar nicht gefallen.

Der Integerwert, den der TWS aus einem 3-byte 10.001 KNX DPTS macht, ist ausschließlich eine Uhrzeit in Sekunden seit 00:00:00 Uhr. Der Wochentag geht dabei z.B. verloren.

08:41:57 -> 31317 Sekunden seit letztem Mitternacht!

Das macht eine vorübergehende Nutzung für alle anderen KNX-Datenpunkte mit 3-byte leider unmöglich.

[Robosoc]

Im übrigen kann man ja alle 1, 2, 3 ,4 Byte Typen ja trotzdem empfangen, muss man dann eben selbst dekodieren

Zitiert aus viewtopic.php?f=21&t=1727

Heißt das, ich muss gar nicht explizit eine DPTS auswählen, sondern kann auch einfach nur eine Hauptgruppe, z.B. 10.xx (3-Byte) wählen.
Dann wären meine Gedanken ja alle völlig für die Katz und es wäre sooo einfach. Ich kann es gerade nicht testen, mache ich aber.

Da würde ich hier lediglich noch ergänzen wollen, dass ich es unglücklich finde, dass ein eindeutig definierter KNX-Datenpunkt (10.001) verlustbehaftet in den TWS übernommen wird. Besser wäre es meiner Meinung nach hier auch den Wochentag mit zu zählen. Mir ist klar, dass dies schwierig ist, weil es in der KNX-Definition zusätzlich den Wochentag-wert 0 gibt, also keine Wochentag. Der macht es dann kompliziert. Aber dann wäre es auch besser das vollständige Binärmuster zu verwenden und User müssen dann eben mit dem Binärmultiplexer und Demultiplexer an die Sache.

[StefanW]

Hi Sven,

Heißt das, ich muss gar nicht explizit eine DPTS auswählen, sondern kann auch einfach nur eine Hauptgruppe, z.B. 10.xx (3-Byte) wählen.

Sorry, da müsste ich tiefer eintauchen und das kann ich gerade nicht (Zeitmangel)

Da würde ich hier lediglich noch ergänzen wollen, dass ich es unglücklich finde, dass ein eindeutig definierter KNX-Datenpunkt (10.001) verlustbehaftet in den TWS übernommen wird.

Wir mussten damals auch fertig werden. Es ist - bei der Menge, teils äußerst spezifischer Datenpunkte - nicht machbar, eine komplette Ausdekodierung für alle vorkommenden DPT zu machen. Insbesondere bei denjenigen, die mehrere verschiedene Werte in einem Bitmuster senden kommt auch der Dispatcher und das ganze Objektkonzept an seine Grenzen, zumindest so wie das bisher gemacht wurde.

Man kann sich überlegen, für die speziellen DPT eine jeweiliges Logikmodul zu entwerfen, welches dann das Bitmuster in einzelne Objekte zerlegt. Oder man hätte dafür eine Funktion im KNX Objekt Manager, der es erlaubt, einen komplexen DPT in verschiedene Objekte aufzuteilen (ich fürchte aber, das braucht nur 2% der Nutzer und nur 1% versteht das dann auch)?

Wir müssen da noch darüber brüten, weil wir wollen ja schon in einer der nächsten Entwicklungsrunden auch die Anzahl der unterstützten Datenpunkttypen erhöhen.

lg

Stefan

[Robosoc]

Euer Problem verstehe ich, voll und ganz. Es ist aber auch das erste Mal wo ich wahrnehme, dass Ihr bewusst entschieden habt nicht der KNX-Definition zu entsprechen. Finde ich persönlich erstmal nicht gut. Wenn Ihr Euch irgendwann umentscheidet, schreien Nutzer auf, die den Datenpunkt schon nutzen.

Was ich aber dazu schade finde (und hier hoffe ich könnte ihr baldigst mit vertretbarem Aufwand nachbessern): Es gibt nach meinen Versuchen heute aktuell keine Möglichkeit für User sich selber zu helfen.

Man kann sich überlegen, für die speziellen DPT eine jeweiliges Logikmodul zu entwerfen, welches dann das Bitmuster in einzelne Objekte zerlegt.

Ja, genau das hatte ich vor und wäre mit den vorhandenen Möglichkeiten des Logikeditors (Binärmultiplexer, etc) wirklich einfach. Das würde natürlich nur 2% der Anwender verstehen, aber es wäre ein einfaches eine zusätzliche Kategorie "Konverter für komplexe Datenpunkte" in der Auswahl der Logik-Module zu schaffen und dort nach und nach mit jedem Update Konverter nachzuliefern, wenn Nutzer das wünschen. Dies würden dann sicher >=80% der Nutzer verstehen.
Gerne stelle ich davon auf die Schnelle ein paar zusammen, zum Beispiel den 225.001 oder einen für 10.001 ohne Informationsverlust.

ABER, dafür müsstet Ihr eine Möglichkeit schaffen, wie man 3-byte KNX-Datenpunkte als vorzeichenloses Integer in den TWS bekommt.
Ich glaube aber, dass ihr das bereits heute könntet, ohne dass die Applikation in der ETS geändert werden muss.

IST Stand:

• Mit den heutigen Möglichkeiten kann ein User in der ETS als Datenpunkt eines TWS-Objektes den Eintrag 10.xx wählen:
  
• Diesen Datenpunkt kann man in ETS mit einer GA eines beliebigen 3-byte Typs verknüpfen. Man erhält dort einen Hinweis, kann das aber "abnicken".
• Beim Import in den TWS spuckt der Log einige Hinweise und vor allem auch Errors aus, was ich für übertrieben halte (müsste nicht sein, Warnungen reichen hier). Aber auch das stört erstmal nicht weiter, der TWS arbeitet trotz "Error" anschließend dennoch mit den GA's. Das war auch meiner Erwartung. Zu den Log-Meldungen, siehe unten.
• ABER leider behandelt der TWS Objekte vom Typ 10.xx im Moment (V3.0 IP3) exakt genauso wie die vom 10.001 - Einige der bits eines Telegrammes werden schlichtweg ignoriert, es ist also keine 3byte Wert mehr.

Und an diesem Punkt sitzt meine Hoffnung:
Der TWS erkennt ja ganz offensichtlich einen Unterschied zwischen der Einstellung einer DPT und einer DPTS. Dann müsstet Ihr auch das Verhalten dabei mit sehr geringem Aufwand ab einer beliebigen Version ändern können. Gleiches gilt dann natürlich auch für alle anderen DPT (4-byte,etc.). Damit schafft Ihr die Möglichkeiten wichige DPTS z.B. für Beleuchtungsapplikationen zu nutzen. Eine direkte Unterstützung aus der ETS heraus und ohne Alarme oder Fehler, ist natürlich besser...aber mal ehrlich: Da wird auch noch ein wenig Wasser die Elbe herunterfließen, bis das verfügbar sein wird.

Es wird sich kein User beschweren, dass bei Einstellung 10.xx anschließend im TWS einfach nur ein Integerwert erscheint, der nicht im Einklang ist mit dem Ergebnis bei 10.001. Es beschwert sich bisher ja auch keiner, dass 10.001 nicht der KNX-Konvention entspricht. Und für 10.xx ist meines Wissens auch keine Formatierung definiert - aber da mag ich mich irren, habe es nicht geprüft. Wer 10.xx nutzt bekommt Warnungen und Errors und würde die heute ignoriert haben...da kann man sich dann noch viel weniger bescheren:

18.11.2021 10:50:23;Objekt Fehler: Objekt 1166 (1.0.101) hat ein unvollständige DPT 10;error
18.11.2021 10:50:23;GA Warning: GA 14/5/1, unvollständige DPT 10;warning
18.11.2021 10:50:24;Objekt 1166 (PA 1.0.101) wurde aktiviert mit DPT 10.000 in den Ressourcen, aber in der Projektdatei mit DPT 10;warning
18.11.2021 10:50:24;DPT 10.000 von Objekt 1166 (PA 1.0.101) wie gegeben in den Ressourcen ist anders als die DPT (10) von dem GA (14/5/1);error

[StefanW]

Hi Sven,

Es ist aber auch das erste Mal wo ich wahrnehme, dass Ihr bewusst entschieden habt nicht der KNX-Definition zu entsprechen.

wie ich schon sagte, KANN ICH GERADE NICHT tief eintauchen. Bitte nicht daraus ableiten, dass wir hier jetzt irgendwas bewusst entschieden haben, weil das habe ich NICHT gesagt.

Ich habe lediglich darauf verwiesen, das es komplexe Datentypen gibt, die herausfordernd sind. Ob dies bei DIESEM der Fall ist und was wir da genau gemacht haben und was nicht, wollte ich damit nicht ausdrücken, weil ich es NICHT AUSWENDIG sagen kann. Sorry, wenn ich das falsch rübergebracht habe


Bitte, der Timberwolf Server spricht bald 12 Protokolle und da gibt es ganz ganz viele Details und beliebige Tiefen. Wir bemühen uns wirklich, aber wir können nicht zu jedem und allem im Detail eine Lösung aus dem Hut zaubern.


lg

Stefan

[Robosoc]

Hallo Stefan, ganz lieb und vorsichtig wollte ich einmal fragen, ob Du meinen Beitrag irgedwann dann gelesen hast und ob Du mein Anliegen verstehen konntest?

Ziel: Nutzung von 3byte Datenpunkten so bald wie möglich, aber ohne dass Ihr dafür eine neue, kostspieliege ETS-Applikation veröffentlichen müsste aber auch ohne dabei KNX-Spezifikationen zu verletzen. Auch habe ich es nur vorgeschlagen, weil ich glaube, dass es zwar Aufwand ist, aber vermutlich überschauber und hoffentlich weniger als 1 Manntag.

Bin mir unsicher, ob ich das deutlich genug beschrieben habe, aber will jetzt nicht noch mehr Prosa fomulieren.