ElabNET Technik Forum

Naja Einheiten sind das eine, von der KNX-org definierte DPT das andere. Wenn es da was in der ETS nicht gibt, wird es das auch an der Stelle hier im TWS nicht geben können, weil es geht hier nicht darum ein internes TWS-Objekt zu labeln, sondern es mit der Kennung auf den Bus zu senden, zu empfangen und zu interpretieren, dafür ist der DPT da.

Beim BURLI haben wir ja das gleiche Problem, das der keine passenden Telegramme senden kann, da der KNX keinen passenden DPT kennt. Ist zwar ganz was anderes aber ich habe da Globalstrahlung genommen. In einer Visu kann man eh daneben schreiben was man will.

Das mit dem Burli ist ja genau das Problem
Und ja, in der Visu ist das kein Problem. Aber bei den Zeitserien z.B. - dafür würde der "interne" DPT ja taugen.

Ja aber da kann eben elabnet keinen erfinden den es nicht auch von der KNX-org definiert gibt, und deren Grundgesamtheit ist das was es in dem Baum in der ETS gibt.

Hi Göran,

gbglace hat geschrieben: ↑Di Dez 28, 2021 7:58 pmJa aber da kann eben elabnet keinen erfinden den es nicht auch von der KNX-org definiert gibt, und deren Grundgesamtheit ist das was es in dem Baum in der ETS gibt.

Nein, wir können mehr Datentypen / physikalische Einheiten als die KNX bisher umgesetzt hat. Es mag ja auch Nutzer geben, die den Timberwolf Server ohne KNX nutzen und warum sollen diese sich beschränken?

insofern ist es kein Problem, dass wir physikalische Einheiten intern nutzen, für die es keinen passenden DPT gibt. Muss der Nutzer dann eben umrechnen lassen auf was halbwegs passendes wenn er davon etwas an KNX senden möchte.

lg

Stefan

Aber dann muss das deutlich werden das wir hier bei DPT nicht von KNX-DPT sprechen und damit die Definition der Daten hinter dem KNX-Stack im reinen TWS-Objektmodell gemeint ist.

Beim Abruf der Wetterdaten (Weatherbit API) bin ich auf mm/h gestoßen für Niederschlag (lässt sich komfortabel auf l/m² umrechnen, welches bereits im TWS vorhanden ist) und für Schneefall. Schneefall wird eigentlich, wenn man dem Netz glauben darf, in cm/h angegeben, also bräuchte man dafür doch mm/h.

Moin zusammen

Ich wurde gerade auf diesen Faden gestoßen und wollte mal sehen, ob er gerissen ist.

StefanW hat geschrieben: ↑Fr Okt 09, 2020 8:50 am

supernode hat geschrieben: ↑Do Okt 08, 2020 11:56 pmWas ist nun aber wenn der Typ nicht zur Verfügung steht? Sollte da der Projekt Import nicht ein wenig toleranter sein, so dass man im Zweifelsfall "13.*" verwenden kann?

Nun, es ist lediglich eine Auswertung für den Nutzer um auf Diskrepanzen im Projekt bzw. gegenüber der ETS-Programmierung hinzuweisen. Das markieren als Warnung oder als Fehler haben KEINE Konsequenzen …

Ich habe auch diesen Fall mit „obskuren“ DPT bei einer Elsner Wetterstation. Die DPTs habe ich gerade nicht zur Hand, aber einen Vorschlag für eine Änderung, die vermutlich relativ klein ist und die UX trotzdem verbessern könnte:

Da es immer KNX-DPTs geben wird, die der TWS nicht kennt könnte die Darstellung der Warnungen in diesem Fall angepasst werden. In etwa so:
- der Eintrag wird zwar hervorgehoben, aber im Idealfall nicht als Error oder Warnung.
- der Text könnte in etwa aussagen: „Diese DPT kenne/unterstütze ich (noch) nicht. Pass bitte selbst auf, dass du einen „kompatiblen“ DPT als Ersatz verwendest und werde damit glücklich. Sollte in Zukunft dieser DPT unterstützt werden, weise ich dich darauf hin und du kannst es dann „richtig“ umsetzen.“

Ziel wäre also keine „unlösbare Warnung“ zu erzeugen, sondern nur einen Hinweis nach dem Motto: „Kenne ich nicht, aber wenn du als Anwender meinst, dass es so geht, dann ist es ok.“
Das wäre dann also „nur“ eine Anpassung der GUI.

Alles nur nice to have. Es gibt wichtigeres…

Hallo,
gibt es schon etwas neues bezüglich der Umsetzung von DTP 251.600? Wäre sicher toll in Verbindung mit der Visu. Oder gibt es einen einfachen anderen Trick eine 6 bytes GPO einzubinden?

Vielen Dank Für die Info

Wenn es kommt dann spätestens mit der Lightengine nach der Visu. Oder unabhängig davon, weil das Thema Anpassung KNX-Stack eine Prio bekommen sollte. Aber beides ist relativ unabhängig von der Visu. Da die Visu erstmal "nur" eine Oberfläche von Bedienelementen und Anzeigelementen ist. Das ist unabhängig von den Kommunikationsfähigkeiten der einzelnen vom TWS verwendeten Kommunikationsprotokolle.

Die Visu wird aber in Ihren Objektstrukturen mit solchen komplexen Datentypen direkt umgehen können, um diese eben nicht nochmal umbauen zu müssen wen der KNX-Stack erweitert oder die Light-Engine im TWS laufen wird.

Hallo zusammen,

mir fällt gerade noch auf, dass ich den DTP 12.1201 benötigen könnte. Dieser DPT wird bei den Wasserzählern von Ling und Janke verwendet.