DPT 13.002 in OpenHAB

[Donnerknall]

Hallo,
ich habe einen DPT13.002 Wert. Auf dem Bus habe ich den Wert 1,285m³/h.
In OpenHAB wird mir der Wert 1067559420.000 m³/h angezeigt.

So sieht mein Item aus

Number Heiz_Durchfluss     "Volumen [%.3f m³/h]" <temperature> (gHeizung, gHKV)   { knx="<13.002:2/2/3"}

Kann mir jemand erklären was hier schief läuft?

[udo1toni]

Schreib mal das < an die korrekte Stelle:

Number Heiz_Durchfluss "Volumen [%.3f m³/h]" <temperature> (gHeizung, gHKV) { knx="13.002:<2/2/3"}

vielleicht erkennt openHAB den DPT sonst nicht richtig.
(In der Doku stand (oder steht noch?), dass die Schreibweise egal ist, das stimmt aber nicht. Das Read-Symbol gehört zwingend zur GA, wenn man mehrere GA auf einem Parameter einfügt, darf man nur einmal den DPT angeben, und das ist dann logischerweise ganz am Anfang.).
Allein mit "Komma an der falschen Stelle" ist es hier jedenfalls nicht getan, deshalb gehe ich davon aus, dass der Wert fälschlicheweise als Float interpretiert wird, und nicht als vorzeichenbehafteter 4-Byte Integer.

[Donnerknall]

Das war nicht der Fehler. Aber irgendwie ist's komisch.
Ich habe das < jetzt mal versetzt, dann kam als Anzeige im OpenHAB nur - m³/h. Im Gruppenmonitor der ETS hab ich auch gesehen, dass der Wert auch gar nicht mehr abgefragt wird von OpenHAB Busadresse abgefragt wird.
Dann hab ich das < wieder vorne hingesetzt. Im Gruppenmonitor seh ich jetzt wieder, dass auf die OpenHAB Adresse der Wert geschrieben wird. Und sogar der richtige, 4 Byte 1,265 steht in der Info Spalte. Nur in OpenHAB wird wieder 1067743969.000 m³/h angezeigt.

[udo1toni]

Ganz ehrlich: das < ist an der Stelle schlicht falsch. Notfalls kannst Du es auch mal ohne < probieren, nur um es auszuprobieren...

[Donnerknall]

Probier ich auch mal aus. Ich hatte auch mal die ganze Konvertierung weggelassen, im Gruppenmonitor wurde mir dann gezeigt, dass an OpenHAB ein 2 Byte Wert übertragen wird. Aber übertragen wurde etwas, im Gegensatz zu < vorne.

[udo1toni]

Dann kann aber 13.002 nicht stimmen, das ist ein Long Integer mit Vorzeichen und der Maßeinheit m³/h, also 32Bit bzw. 4Byte.

[Donnerknall]

So, es funktioniert jetzt. Ich habe mir jetzt als Datentyp irgendeinen DPT 14, also Gleitkommawert geschnappt. Mein Item ist jetzt mit { knx="<14.001:2/2/3"} definiert. < vor der GA funktioniert definitiv nicht. Wenn ich die < vor die GA setzte wird überhaupt kein Wert an OpenHAB übertragen. Und komischerweise wird ein Item in welchem ich einen berechneten Wert speichere auf 0 gesetzt, also irgendwas funktioniert dann nicht mehr richtig.

In der Beschreibung des Wärmemengenzählers ist der Datenpunkt als "Momentaner Durchfluss m3/h DPT 4 Byte" beschrieben. Weil der DPT 13.002 die Einheit m³/h bin ich leichtgläubig davon ausgegangen es funktioniert. Wenn ich das Item mit { knx="<13.002:2/2/3"} definiere sehe ich auch im Gruppenmonitor den richtigen Wert an OpenHAB gesendet. Nur in der BasicUI wird er nicht richtig angezeigt. Hier steht dann 1067743969.000 m³/h statt 1,285 m³/h.

KlammerVorne.JPG

Edit:
Ähnliches Problem habe ich auch mit dem Verbrauchswert des Wärmemengenzählers. 4 Byte Wert, also entweder DPT 12, 13 oder 14. Gebe ich 14 an, wird der Wert wieder gar nicht an OpenHAB übertragen. Gebe ich 12 oder 13 an dann wird zwar der richtige Wert geschrieben laut Gruppenmonitor aber in der BasicUI erscheint Err. Auf den Err bin ich auch schon gestoßen als ich relative und absolute Luftfeuchtigkeit Übertragen wollte. Hatte dazu auch schon fleißig gegoogelt und Einträge gefunden, nur keine Lösung die funktioniert hat.

[udo1toni]

Sorry, ich muss mich selbst korrigieren... (das kommt davon...)

Da Du knx1 nutzt, gehört das < tatsächlich vor den DPT. Dafür muss der DPT bei jeder GA mit dazu geschrieben werden, falls man mehrere GA als ein Parameter angibt, also z.B.

{ knx="13.002:2/2/3+13.002:<2/2/4,2/2/5,2/2/6+<2/2/7"}

würde für den ersten der drei Parameter den DPT 13 erzwingen und für die beiden anderen Parameter den default DPT nutzen (ist natürlich ein willkürliches Beispiel ohne Sinn)

DPT 12 ist 32Bit Integer ohne Vorzeichen (Wertbereich 0 ... +4.294.967.295)
DPT 13 ist 32Bit Integer mit Vorzeichen (Wertbereich -2.147.483.648 ... +2.147.483.647)
DPT 14 ist 32Bit Float mit Vorzeichen (Wertbereich -3,40282347e+38 ... 3.40282347e+38)

Der DPT ist kein Ratespiel man muss in den Unterlagen des Herstellers nachschauen, welcher DPT verwendet wird. Dabei kommt es nicht so sehr auf die Untergruppe an, die Hauptgruppe muss stimmen.
Es gibt auch noch andere 4Byte DPT, z.B. 210.100 (Consumer Flow Temperature Demand), man muss also schon nachschauen, welcher denn nun der korrekte ist.

[Donnerknall]

Leider gibt die Anleitung nicht mehr her Komisch ist halt, dass wenn ich DPT 13 definiere ich sehe wie der Wert im Gruppenmonitor richtig an OpenHAB gesendet wird aber falsch angezeigt wird.

Wo kommt denn der "Err" her?

WMZ Datenpunkte.PNG

[udo1toni]

Also, es handelt sich definitiv um eine 4Byte Gleitkommazahl (0x3fa47ae1 = 1,285), also ist DPT14 für die Durchflussmenge korrekt. Die Liste der DPT14 ist lang... Du kannst hier die komplette Liste der unterstützten DPT einsehen: https://github.com/openhab/openhab1-...ypeMapper.java Das ist der Sourcecode. Wie erwähnt ist der Untertyp auf dem Bus egal, alles, das 14.xxx heißt, ist 4-Byte-Float.
Was die anderen Werte betrifft, muss man halt schauen, wie sie kodiert sind.
Für die anderen Werte kannst Du den DPT ermitteln, indem Du in ETS den Byte-Code und den Anzeigewert aufschreibst und selbst umrechnest (bzw. einen der Umrechner im Netz verwendest, z.B. https://www.h-schmidt.net/FloatConverter/IEEE754de.html) Das funktioniert natürlich nur bei reinen Zahlen, nicht, falls ein Spezial-4-Byte-Wert verwendet wird (z.B. 2 16Bit-Integer als ein 4-Byte-Wert übertragen, oder 24Bit-Wert plus 8Bit Steuerinformationen...)
Es kann aber auch sein, dass ETS Dir die DPT frei Haus liefert (manchmal ist das direkt in der Applikation hinterlegt).

Unter uns: die Doku (https://www.arcus-eds.de/waerme.html) ist an dieser Stelle eine Unverschämtheit. 4 Byte kann alles mögliche sein. Am besten schreibst Du an den Hersteller und bittest um exakte Aussagen zu den DPT, die müssen es schließlich wissen (und es handelt sich dabei ja nicht um Betriebsgeheimnisse...)
Meine Erfahrungen mit solchen Anfragen sind durchweg positiv, oft werden die Dokumente anschließend sogar aktualisiert (das kann natürlich eine ganze Weile dauern...).

[Donnerknall]

Also, laut Hersteller ist der aktuelle Verbrauchswert 4-Byte Float. Also DPT 14. Hier bekomme ich aber "Err" in der BasicUI angezeigt.

Edit: Problem gelöst. Der Teufel steckt wie immer im Detail. Habe das Item mit "Verbrauchswert [%.f kWh]" definiert statt "Verbrauchswert [%.0f kWh]".