Hi,
freue mich riesig, dass jetzt mit 5.0 auch DPT unterstützt werden.
Hatte gehofft, ich müsse nur die OPC neu einlesen und alles würde automatisch umgestellt werden…
Hab ich das richhtig verstanden, dass ich die Instanzen alle manuell ersetzen muss, die ich auf DPT haben will?
kleiner Bug: DPT 20.102 HVAC im standard Profil übersetzt die 3 in „Wirtschaft“, fände „Night“ besser, da die anderen Werte auch zB „Comfort“, „Standby“ oder „BuildingProtection“ heissen…
Der OPC Export kennt leider keine "DPT"s. Wir werden in einer der zukünftigen Versionen uns an einen Import der KNXProj Dateien machen, um auch die DPTs automatisch einlesen zu können. Bisher sind die DPTs also eher unterstützend mit an Board.
Kann ich den DPT für z.B: die Betriebsartenumschaltung manuell auf 20.102 nach dem Export einstellen? Leider finde ich aktuell immernoch nur die EIS typen?
Okay das habe ich erledigt ;), war Generell kein Problem… aber statt meiner „Frost, Komfort, Nacht, Standby“ deutlich mehr Optionen. Könnten diese zusätzlich angepasst bzw. limitiert auf meine Verstellmöglichkeit haben?
Ergänzend, analog ein ähnliches Thema,
DPT auf 13… float m³/h ausgewählt, aber leider kommen in IPS ganz andere Werte an.
Ets zeigt alles korrekt an, nur leider nicht IPS.
das ist richtig, aber schaue mal bitte in meinen ETS Screenshot, hier war das Beispielt mit DPT13.002 für flow m³/h, leider erhalte ich im Symcon immer den Wert 66 und im ETS jedoch korrekt.
Dann zeig mal, was du in IPS als Datentyp (DPT oder EIS) eingestellt hast.
Ich habe bisher in Dutzenden solcher Fälle immer genau eine Ursache gesehen: Nutzer hat unterschiedlichen Datentyp an beiden Enden der Kommunikation gewählt. Die Interpretation der Daten auf den Bus hängen nur vom Datentyp ab, der selbst aber nicht übertragen wird. Der Busmonitor ETS hat natürlich immer den richtigen Datentyp, den du an anderer Stelle im ETS-Projekt verknüpft hast. IPS nutzt das, was du in IPS einstellst, und wenn das nicht passt wird aus einem float auch ein unsigned integer oder sonstwas. Auf den Bus sind das einfach 2 Bytes.
Ich sehe von dir keinen IPS-Screenshot mit erkennbarer Datentyp-Zuweisung, daher habe ich es nun hier nachgebaut.
Tatsächlich sieht das nach Bug aus:
Mit EIB-Instanz und dem richtigen Integer-Datentyp (EIS11 entspricht DPT13) kommt mein Testwert 1234 korrekt an, mit KNX-Instanz vom Typ DPT13 kommt anstelle des Integerwertes 1234 ein falscher Float(!?)wert in IPS an.
@volkerm: Ich bin gerade an dem Problem dran und hätte da eine Rückfrage… Laut DPT Datenblatt sollte der 13.002 eine Auflösung von 0,0001 haben. Wenn ich mir die ETS ansehen, wird jedoch eine Auflösung von 1 genutzt und soweit ich das sehe würdet ihr bzw. eure Geräte dies ebenfalls so erwarten? (Ansonsten können wir alle Werte als Integer abbilden, anstatt wie aktuell als Float)
selbst habe ich kein solches Gerät, auch nur das Datenblatt. Demnach ist DPT13 kein Float, sondern ein 4 Byte Integer. Ich würde das Datenblatt so verstehen, daß 1 einem Schritt von 0,0001 m3/h entspricht. Schau doch mal, ob das in der ETS so passt.
Edit: Ich sehe dein Dilemma, nach meinem eigenen Screenshot (04D2 = 1234 m3/h) wäre die Schrittweite 1 m3/h. Da brauchen wir @nickknx mit seiner Hardware.
Nochmaledit: Nach Screenshot in #10 ist’s wohl so: Schrittweite 1 m3/h
Das muss ein Fehler in den KNX DPT Specs sein. Es hält sich zumindest keiner dran. Ich baue das DPT somit um, sodass es sauber Integer Variablen nutzt.
Bisher habe ich einfach die durch den OPC Import erzeugten Instanzen vom Typ EIB Group verwendet. Erst als mir Floatwerte meines Strommessaktors falsch angezeigt wurden, hab eich entdeckt, dass ich händisch Instanzen mit dem DPT Typ aus der ETS anlegen kann.
Wie ist denn grundsätzlich das beste Vorgehen? Ich hab das Gefühl, dass ich mit den DPT Instanzen irgendwie genauer die KNX Objekte wiedergebe, aber es ist natürlich mega umständlich, die Instanzen auch noch von Hand zu erzeugen. Wie handhabt ihr das?