NEUHEIT! Ab sofort MQTT mit dem Timberwolf Server!
Verfügbar für alle Versionen mit der Insider Preview 5 zur Version 2.0. Infos: viewtopic.php?f=8&t=2846

[Frage] Welche DPT werden noch gewünscht?

Diskussionen über die KNX-Funktionen im Timberwolf Server

MeisterLampe
Reactions:
Beiträge: 54
Registriert: Di Dez 18, 2018 8:17 am
Wohnort: Braunschweig
Hat sich bedankt: 14 Mal
Danksagung erhalten: 19 Mal

#21

Beitrag von MeisterLampe »

Ok danke für die Aufklärung
Timberwolf Server 2600 | ID:246 | VPN offen + reboot erlaubt

Sun1453
Reactions:
Beiträge: 1194
Registriert: Do Feb 07, 2019 8:08 am
Hat sich bedankt: 768 Mal
Danksagung erhalten: 475 Mal

#22

Beitrag von Sun1453 »

DPT 1.024

Tag / Nacht Umschaltung

TWS hatte mir das bei Projekt Import moniert. Heute 21.08.2020.

Hatte DPT 1.xxx genutzt, da obiger nicht in Applikation enthalten war. Log File könnte ich nachreichen. Ist das letzte importierte Projekt falls ihr das log selbst holen wollt.
Gruß Michael

Timberwolf 950 QL #344 | Mit Internetanbindung | VPN Offen | Reboot nach Absprache

richy
Reactions:
Beiträge: 17
Registriert: Di Jun 16, 2020 9:38 pm
Hat sich bedankt: 36 Mal
Danksagung erhalten: 15 Mal

#23

Beitrag von richy »

Ich würde mir

DPT 12.1200 Volumen Flüssigkeit [L]
DPT 12.1201 Volumen [m3]

wünschen, da ich gerade an folgendem Problem knabbere

2020-09-06 DPT.JPG
LG richy
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
TWS 350Q ID:480, VPN offen, Reboot nach Rücksprache
Benutzeravatar

brinchi
Reactions:
Beiträge: 93
Registriert: So Aug 12, 2018 1:04 pm
Hat sich bedankt: 120 Mal
Danksagung erhalten: 73 Mal

#24

Beitrag von brinchi »

StefanW hat geschrieben: Do Dez 05, 2019 10:54 am Wenn Ihr also Wünsche an weitere DPT habt, dann bitte her damit
Zu meinem basalen Verständnis: Übernehmt Ihr die komplette DPT-Liste nach aktuellem ETS-Stand deswegen nicht automatisch, weil das mit einem signifikanten Aufwand verbunden wäre?

Wenn Euer Fokus bzw. TWS-Hauptverkaufsargument die Integrationsfähigkeit diverser Standards ist -neben Eurem tollen Service und den sonstigen Vorzügen, die wir alle im Forum schätzen-, würde ich höllisch aufpassen, damit fehlende, im "ETS-Standard" wohl vorhandene DPTn nicht zum nervigen Flaschenhals in der praktischen TWS-Integrationsanwendung werden.
Bestimmte Zeitgenossen würden dies sicherlich unmittelbar als Aufforderung zu nicht unbedingt wertschöpfenden Äusserungen in den diversen Internetforen auffassen, alles nach dem Motto: "Die wollen 8000 Objekte und können dann noch nicht einmal alle DPTn".

Wenn man sich nur einige DPTn wünschen darf (den aktuellen RC4-Stand habe ich nicht überprüft, insofern bitte ich um Nachsicht):
  • Bitte aus Prinzip sowieso jene DPTn, die wir für die vollständige Funktion Eurer 1W-Sensoren brauchen.
  • Und dann bitte auch jene, die Ihr für die hoffentlich baldige native Netatmo-Integration bräuchtet. 8-)
Zuletzt geändert von brinchi am So Sep 06, 2020 9:38 pm, insgesamt 1-mal geändert.
timberwolf231 (2600), VPN offen, Reboot jederzeit

Ersteller
StefanW
Elaborated Networks
Reactions:
Beiträge: 5634
Registriert: So Aug 12, 2018 9:27 am
Wohnort: Grafing
Hat sich bedankt: 2668 Mal
Danksagung erhalten: 4058 Mal
Kontaktdaten:

#25

Beitrag von StefanW »

Hallo Brian,

hier ist noch eine Antwort offen. Sorry für die späte Antwort, ich musste manches intern erfragen, weil das nicht so einfach ist.

brinchi hat geschrieben: So Sep 06, 2020 9:26 pmZu meinem basalen Verständnis: Übernehmt Ihr die komplette DPT-Liste nach aktuellem ETS-Stand deswegen nicht automatisch, weil das mit einem signifikanten Aufwand verbunden wäre?
Richtig.

Neue DPT müssten berücksichtigt werden in:

  • ETS Applikation beim Freischalten eines Objektes
  • Im KNX Stack wenn damit programmiert worden
  • im TWS beim transkodieren für die Einspeisung in den Dispatcher (wir arbeiten intern mit anderen Formaten plus physikalischen Einheiten, weil wir intern mehr können, als der KNX Standard kann)
  • Im TWS auch beim transkodieren für das Senden vom Dispatcher zum KNX Bus im passenden Format für den DPT
  • Im TWS im Busmonitor beim Dekodieren der KNX Telegramnme

Es ist also mit allen Tests usw. durchaus ein Manntag Arbeit pro Datenpunkttyp plus mehrere Manntage um das ganze Paket Auszurollen und alle Tests vorzunehmen und die Dokumentation anzupassen.

brinchi hat geschrieben: So Sep 06, 2020 9:26 pmWenn Euer Fokus bzw. TWS-Hauptverkaufsargument die Integrationsfähigkeit diverser Standards ist -neben Eurem tollen Service und den sonstigen Vorzügen, die wir alle im Forum schätzen-, würde ich höllisch aufpassen, damit fehlende, im "ETS-Standard" wohl vorhandene DPTn nicht zum nervigen Flaschenhals in der praktischen TWS-Integrationsanwendung werden.
Schon klar. Es gibt keinen KNX Server der alles kann, zumal manche DPT herstellerspezifisch sind und nur der Kommunikation dieser speziellen KNX Geräte untereinander dienen.

brinchi hat geschrieben: So Sep 06, 2020 9:26 pmBestimmte Zeitgenossen würden dies sicherlich unmittelbar als Aufforderung zu nicht unbedingt wertschöpfenden Äusserungen in den diversen Internetforen auffassen, alles nach dem Motto: "Die wollen 8000 Objekte und können dann noch nicht einmal alle DPTn".
Es ist ohnehin egal was wir tun. Es wird immer bestimmte Zeitgenossen geben, die sich einen Vorwurf aus dem Finger saugen. Sehen wir ja gerade an den vielfältigen alternativen Theorien zur aktuellen Pandemie. Manche schätzen, dass fast 30% der Bevölkerung sich von einer oder mehreren "alternativen Theorien weniger Autoren" verführen lassen.

Wie soll man in einer solchen Gesellschaft auf eine kompetente Bewertung eines Produktes hinarbeiten. Es wird immer irgendwas einfach aus dem Bauch heraus behauptet werden, egal wieviel man tut oder was die Tatsachen sind.

brinchi hat geschrieben: So Sep 06, 2020 9:26 pmWenn man sich nur einige DPTn wünschen darf
Klar, bitte nur zu, wir sammeln das schon ernsthaft und analysieren auch gerade die Umsetzung für die Unterstützung neuer DPT.

Das schließt auch eine Doku mit ein, welche DPT für was genutzt werden sollen (basierend auf Deinem Ticket #36607) inkl einer Anzeige im DOS beim Verknüpfen.

Also, es passiert schon, ist aber sehr aufwändig und kommt ab der nächsten Version V2.0, aber nicht mehr mit einem RC für V 1.6 , weil dafür ist die Änderung an so vielen Modulen dafür zu heftig. Mehr und bessere Doku könnte es unabhängig davon vorher geben.


lg

Stefan
Stefan Werner
Product Owner für Timberwolf Server, 1-Wire und BlitzART der Elaborated Networks GmbH
Support nur über dieses Forum und in individuellen Fällen über support@wiregate.de.
Bitte KEINE PN Impressum und Datenschutzerklärung oben

supernode
Reactions:
Beiträge: 55
Registriert: So Aug 12, 2018 7:39 am
Hat sich bedankt: 10 Mal
Danksagung erhalten: 23 Mal

#26

Beitrag von supernode »

Ich wollte jetzt nicht extra ein neues Thema beginnen da die Antwort eventuell schon irgendwo steht, ich die Antwort aber nicht finde. Ich denke aber auch dass das recht gut zum Thema passt.

Ich habe GAs angelegt und meinem Stromzähler (Enertex) zugewiesen. Als DPT wurde bspw. der allg. "13.* 4-Byte vorzeichenbehaftet" automatisch gewählt. Beim TWS habe ich in der ETS dann DPT "13.xxx (32 Bit, 2er Koplement)" gewählt. Beim Import des KNX Projektes im TWS bekomme ich nun Fehler-Meldungen im Import-LOG. Bei meinen Tests gab es dann auch Probleme beim Verwenden der Zeitserien. Ich hab mal paar Screenshots angehäbgt - TWS läuft mit V1.6 RC6.

Natürlich hilft es in meinem Fall wenn ich den DPT hier händisch anders vorgebe - der DPT ist in der TWS App auswählbar.
Was 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?

Grüße
Martin
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
TWS 2600 ID:172, VPN offen, Reboot erlaubt
Benutzeravatar

Eraser
Reactions:
Beiträge: 521
Registriert: So Aug 12, 2018 1:51 pm
Wohnort: Amstetten, Österreich
Hat sich bedankt: 152 Mal
Danksagung erhalten: 225 Mal

#27

Beitrag von Eraser »

Das hatte ich auch mit dem Enertex SmartMeter, hab dann einfach den nächst passenderen Datentyp aus der DPD13-Schiene genommen.
mfg
Wolfgang

Timberwolf 2500 #151 / VPN offen / Reboot nach Rücksprache
+ PBM #938

eib-eg
Reactions:
Beiträge: 294
Registriert: Fr Sep 14, 2018 5:03 pm
Hat sich bedankt: 1243 Mal
Danksagung erhalten: 148 Mal

#28

Beitrag von eib-eg »

Hallo @supernode Martin

Bitte die subtypen separat überprüfen.
Es macht den Anschein das hier was nicht übereinstimmt.
Georg

TW 2600 #216 Vertrag Gold nur knx seit 1998 über ETS 1.36 Programm. VPN offen, Zugriff jederzeit

Ersteller
StefanW
Elaborated Networks
Reactions:
Beiträge: 5634
Registriert: So Aug 12, 2018 9:27 am
Wohnort: Grafing
Hat sich bedankt: 2668 Mal
Danksagung erhalten: 4058 Mal
Kontaktdaten:

#29

Beitrag von StefanW »

Guten Morgen Martin,
supernode hat geschrieben: Do Okt 08, 2020 11:56 pmIch denke aber auch dass das recht gut zum Thema passt.
Jep. Da es am Ende des Tages um weitere DPT für den TWS geht.

supernode hat geschrieben: Do Okt 08, 2020 11:56 pmBeim Import des KNX Projektes im TWS bekomme ich nun Fehler-Meldungen im Import-LOG. Bei meinen Tests gab es dann auch Probleme beim Verwenden der Zeitserien.
Magst Du mir das bitte näher beschreiben, weil das sollte nicht der Fall sein.

Grundsätzlich sollten (abgesehen vom Dekoding im Busmonitor) alle Funktionen des Timberwolf Servers einwandfrei funktionieren nur auf Basis der Programmierung durch die ETS. Es sollte NICHTS zu Problemen führen oder abbrechen, weil der KNX Import nicht ausgeführt wurde.


An dem Import hängt nur das Dekoding im Busmonitor (für GAs die nicht einem KNX-Objekt des TWS zugewiesen sind) und Anzeigemöglichkeiten im DOS.

Daher interessiert es mich schon, zu welchen Problemen es mit der Zeitserie gekommen ist.

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 für den betrieblichen Ablauf des Timberwolf Servers. Insofern ist der Server also sehr tolerant, weil das nicht dazu führt, das etwas nicht funktionieren würde (vom ggfls. "falschen" Dekoding im Busmonitor abgesehen")

Der Gründe dafür, dass wir das so gemacht haben, sind folgende:
  1. Es besteht immer ein wenig die Gefahr, dass der Kunden ein falsches oder veraltetes oder zu neues (gegenüber der Programmierung) importiert. Damit Programmierung und Import den gleichen Datenstand haben, wird beim Import akribisch geprüft
  2. Die ETS erlaubt, wie auch von Eraser in einem anderen Post heute beschrieben, dass DPT für eine GA nicht nur anders eingestellt sein können als das damit assozierte KNX Objekt, sondern die ETS zeigt es womöglich auch noch anders an, als im exportieren Projekt gespeichert. Kurz, wir wollten auf ETS Fehler bzw. Diskrepanzen hinweisen.
  3. Es war auch wichtig, dem Kunden eine schnelle und präzise Rückmeldung und damit auch unseren Support zu entlasten. Je präziser man dem Nutzer eine Fehlermeldung gibt, desto mehr kann er selbst nach dem Fehler suchen. Die vielen Anzeigen zu Status und ggfls. Fehlermeldungen sind ein wesentlicher Teil der Produktphilosophie
Man mag nun darüber streiten, ob man eine solche Diskrepanz rot oder gelb einfärbt. Es gibt sehr viele Fälle die wir hier berücksichtigen müssen und die Analyse des Systems noch so weit hochdrehen, ob eine spezifische Diskrepanz nun vielleicht doch etwas relaxter angezeigt werden kann mag man implementieren können.

Die Frage am Ende des Tages ist aber immer eine Abwägung zwischen Aufwand und Nutzen und es gibt da eine Menge an Funktionen, die von unseren Nutzern gewünscht werden, die noch zur Implementierung anstehen.

Ich würde meinen, dass man mit der ein oder anderen, übertrieben erscheinenden - aber folgenlosen - Fehlermeldung, ganz gut leben kann und wir uns von der Priorisierung her um anstehende neue Themen kümmern sollten. Weil wenn ich mir dieses Jahr so ansehe, dann haben wir mehr an bestehendem gefeilt als neues erschaffen und das bringt uns alle nur bedingt weiter.

lg

Stefan
Stefan Werner
Product Owner für Timberwolf Server, 1-Wire und BlitzART der Elaborated Networks GmbH
Support nur über dieses Forum und in individuellen Fällen über support@wiregate.de.
Bitte KEINE PN Impressum und Datenschutzerklärung oben

supernode
Reactions:
Beiträge: 55
Registriert: So Aug 12, 2018 7:39 am
Hat sich bedankt: 10 Mal
Danksagung erhalten: 23 Mal

#30

Beitrag von supernode »

Ja, wenn ich das alles manuell festlege ist das natürlich in Ordnung und die Fehlermeldungen sind weg.
Wenn ich nun aber den DPT nicht in der Liste der TWS-App finden würde - das ist ja auch das Thema in diesem Thread - würde ich einfach "13.*" (ETS) "13.xxx" (TWS Parametrierung) nehmen. Genau diese allgemein gehaltene Kombination geht aber nicht, was mich ein wenig verwundert. Der Datentyp (Wortbreite) ist doch über 13 festgelegt und die Einheit könnte man im allgemeinen Fall auch ignorieren. Für was wäre dann 13.xxx überhaupt gedacht?

Das Problem mit den DPTs kann ich im Moment nicht beantworten da das schon einige Wochen her ist. Ich versuche dass ich mir das heute Abend oder am Wochenende nochmal ansehen kann und diesen Fall nochmal hervorrufen kann.


Eine Frage zu der Datenaufzeichnung KNX -> Timeseries. Soweit ich das verstanden habe und auch umsetze muss ich hierbei immer über die KNX Objekte, d.h. TWS App in der ETS, gehen und da DPT auswählen die zu empfangenen GA zuweisen. Wäre es nicht deutlich einfacher ähnlich dem Busmonitor die Werte direkt abgreifen zu können? D.h. ich setze einen "Listener" auf eine bestimmte Gruppenadresse auf (in der Weboberfläche) und immer wenn er das sieht schreibt ers in die Datenbank. Da reicht doch das KNX Projekt zu importieren.


Auch wäre es toll wenn man bei einer TS einstellen könnte dass nur neue Werte geschrieben werden sofern sich der Wert wirklich ändert. Meine Zisterne schickt mir alle 5 Minuten den Statuswert, Änderungen sind meist - nicht immer! - rel. langsam und der Pegel bleibt auch über längere Zeit konstant. Er schreibt aber alle 5 Minuten brav einen Wert in die DB was er sich auch sparen könnte. So eine "Datenbereinigung" könnte man auch im Nachhinein einmal am Tag durchführen, falls dies einfacher umzusetzen wäre. Nunja, meine persönliche Wunschliste...
TWS 2600 ID:172, VPN offen, Reboot erlaubt
Antworten

Zurück zu „KNX“