ElabNET Technik Forum

Hallo Zusammen,
spricht eigentlich etwas dagegen, dem Timberwolf Server einfach alle Datentypen 'beizubringen', die die ETS kennt?

Beim Importieren der ETS Datei werden mir z.B. Fehler wegen abweichender DPTs gemeldet, weil der TWS die in der ETS verwendeten DPTs leider nicht kennt (DPT 1.024 ist Tag/Nacht - diesen DPT kennt der TWS nicht). Das ist zwar in einem solchen Fall nicht schlimm aber lästig
Schwierig wird es aber, wenn kein 'gleichwertiger' DPT zur Verfügung steht (wie z.B. der bereits erwähne HVAC Modus (20.102) oder gar Helligket Farbtemperaturübergang (249.600))

Viele Grüße

Piet

Hi Piet,

piet61 hat geschrieben: ↑Mo Jul 01, 2024 2:16 pmspricht eigentlich etwas dagegen, dem Timberwolf Server einfach alle Datentypen 'beizubringen', die die ETS kennt?

Das kommt darauf an, wie Du das meinst.

Wenn es diesbezüglich um den zweiten Punkt geht (keine Fehlermeldung beim Import Projekt), dann kann man darüber nachdenken.

Wenn es darum geht, dass diese anderen DPT auch funktional im Stack unterstützt und kodiert / dekodiert werden, dann wäre das wohl zu aufwändig. Auch weil es viele herstellerspezifische - und teils recht spezielle - Datenpunkttypen gibt, die weder komplett dokumentiert sind, noch die wir testen könnten (mangels speziellem Gerät). Sicherlich würde schon "die meisten im Stack unterstützen" einen ordentlichen sechsstelliger Betrag kosten.

piet61 hat geschrieben: ↑Mo Jul 01, 2024 2:16 pmBeim Importieren der ETS Datei werden mir z.B. Fehler wegen abweichender DPTs gemeldet, weil der TWS die in der ETS verwendeten DPTs leider nicht kennt (DPT 1.024 ist Tag/Nacht - diesen DPT kennt der TWS nicht). Das ist zwar in einem solchen Fall nicht schlimm aber lästig

Punkt ist verstanden.

piet61 hat geschrieben: ↑Mo Jul 01, 2024 2:16 pmSchwierig wird es aber, wenn kein 'gleichwertiger' DPT zur Verfügung steht (wie z.B. der bereits erwähne HVAC Modus (20.102) oder gar Helligket Farbtemperaturübergang (249.600))

Der Helligkeit Farbtemperaturübergang (249.600) ist insofern speziell, weil dieser drei Werte gleichzeitig beinhalten KANN.

1. Zeitperiode in Anzahl 100 ms Schritten in 16 Bit
2. Farbtemperatur in Kelvin in 16 Bit
3. Helligkeit in Prozent in 8 Bit

Und dann noch eine 3-Bit Maske mit Information, ob und welche der drei Werte tatsächlich enthalten sind (korrekt: Gültig ist).

Das Timberwolf Objektsystem verteilt derzeit Objekte, die nur eine Wert aus einem Datentyp enthalten.

Um nun solche "Multi-Wert-Telegramme" zu unterstützen, müssen wir auch im Timberwolf Server "Komplex-Datentypen" implementieren. Das bedeutet dann, hierfür auch Logikmodule für das Aus- und Einleiten der x Werte aus und in diese Komplex-Datentypen nebst Umrechnung zur Verfügung stellen (man will die Zeit ja dann in ms haben und nicht in Anzahl von 100 ms). Dies muss dann auch vom Verknüpfungsassistenten und wegen der automatischen Typkonvertierung von allen anderen Subsystem berücksichtigt werden.

Ist eine tolle Sache, wenn das drin ist, weil das würde das Handling sehr vereinfachen, gerade mit der VISU, aber ist auch eine Herausforderung.

Wir haben den Bedarf für diese erweiterten DPT durchaus verstanden. Ich habe nichts versprochen und keinen Termin genannt.

lg

Stefan

Hallo,

ich schließe mich der Frage von Piet an: alle DPTs im Timberwolf Server zu haben wäre schön.
Nach der Antwort von Stefan sehe ich allerdings auch, dass das nicht so einfach wird für die komplexen DPTs.
Aber einige, wie z. B. fehlenden binären DPTs (Tag/Nacht) oder auch ein paar 2/4-Byte-DPTs mit Einheiten wie g/m3 oder PPM für die Luftqualität sind hoffentlich einfach umzusetzen. Hier geht es ja im Prinzip "nur" um neue Einheite für bereits implementierte Datentypen.

Komplexe DPTs wie 232 für RGB-Licht und andere werden aber sicher spätestens dann auch im TWS benötigt, wenn das Lichtwidget der Visu auch Farbsteuerung kann ...

Vielen Dank und viele Grüße
Falk

Hi Falk,

speckenbuettel hat geschrieben: ↑Di Jul 02, 2024 12:11 pmNach der Antwort von Stefan sehe ich allerdings auch, dass das nicht so einfach wird für die komplexen DPTs.

Richtig

speckenbuettel hat geschrieben: ↑Di Jul 02, 2024 12:11 pmAber einige, wie z. B. fehlenden binären DPTs (Tag/Nacht) oder auch ein paar 2/4-Byte-DPTs mit Einheiten wie g/m3 oder PPM für die Luftqualität sind hoffentlich einfach umzusetzen. Hier geht es ja im Prinzip "nur" um neue Einheite für bereits implementierte Datentypen.

Richtig

speckenbuettel hat geschrieben: ↑Di Jul 02, 2024 12:11 pmKomplexe DPTs wie 232 für RGB-Licht und andere werden aber sicher spätestens dann auch im TWS benötigt, wenn das Lichtwidget der Visu auch Farbsteuerung kann ...

Richtig


Das kommt wenn es fertig ist.


Stefan

Habe gerade in einer Paralleldiskussion (hier) schon meinen Wunsch erneuert und finde es passt auch hierhin:

Ermöglicht uns doch gerne die Nutzung einiger der DPT-Hauptgruppen, damit der TWS die Werte mit dem KNX austauschen kann. Das ist nicht der Königsweg, aber er würde uns Nutzern schnell helfen und die Community zum Einsatz bringen.

Für die Kommunikation oder Interpretation von 232.600 brauchen wir einen 24 bit Wert. Das würde mir auch bei 225.001 helfen.
Wenn der TWS den "DPT 10.xxx" mit Fehlern und Warnungen nicht genauso wie 10.001 übernehmen würde, sondern als strukturlosen 24bit Wert (gerne weiterhin mit Fehlern und Warnungen) könnten wir alles Andere selber lösen. Und Elabnet müsste wahrscheinlich nicht einmal die ETS-Applikation ändern.

Hallo Sven,

Robosoc hat geschrieben: ↑Mi Jul 10, 2024 8:50 amFür die Kommunikation oder Interpretation von 232.600 brauchen wir einen 24 bit Wert. Das würde mir auch bei 225.001 helfen.

Wir müssen dafür einen neuen Datentyp intern definieren. Das betrifft sämtliche Subsysteme, Objekt-System und den Verknüpfungsassistenten. Das ist nicht einfach.

Wunsch ist verstanden, wir werden darüber beraten.

lg

Stefan

Hi Stefan, ich glaube der Wunsch ist noch nicht verstanden. Ich mocht den Wert aus dem KNX als Integerwert in den Logikeditor bekommen...bis 24 bit könnt ihr dass doch schon oder?

Robosoc hat geschrieben: ↑Do Jul 11, 2024 5:48 pmHi Stefan, ich glaube der Wunsch ist noch nicht verstanden. Ich mocht den Wert aus dem KNX als Integerwert in den Logikeditor bekommen...bis 24 bit könnt ihr dass doch schon oder?

Ich habe das so verstanden.

Stefan

Wie ist das eigentlich bei DPT 10.001 (Tageszeit) und DPT 11.001 (Datum). Objekte dafür gibt es ja in ETS, aber die Visu zeigt sie beide in Sekunden.

StefanW hat geschrieben: ↑Di Jul 02, 2024 4:51 pm

speckenbuettel hat geschrieben: ↑Di Jul 02, 2024 12:11 pmAber einige, wie z. B. fehlenden binären DPTs (Tag/Nacht) oder auch ein paar 2/4-Byte-DPTs mit Einheiten wie g/m3 oder PPM für die Luftqualität sind hoffentlich einfach umzusetzen. Hier geht es ja im Prinzip "nur" um neue Einheite für bereits implementierte Datentypen.

Richtig

...wenn einfach einfach einfach wäre, dann sollte das es eigentlich nicht 5 Jahre dauern.
Ich bin da gerade drüber gestolpert: DPT 9.029 fehlt leider weiterhin.
viewtopic.php?t=1166

VG
Stefan