ElabNET Technik Forum

Hallo

Ich betreibe seit kurzem ein Arcus KNX M-Bus Gateway für meine Wärmemengen- und Wasserzähler. Dieses benutzt unter anderem Datenpunkte des Typs 14.***. Hierbei ist mir aufgefallen, dass die Darstellung im TWS Busmonitor von der im ETS Busmonitor abweicht. Der TWS erfindet bis zu 15 Nachkommastellen hinzu, die von meinen Zählern so nicht gesendet werden.

So sieht es in der ETS aus:


Und so im TWS:


Kann sich bzw mir das jemand erklären?

PS: Keine Ahnung, warum die Bilder so unschaf sind, ich hoffe man erkennt was ich meine.

Kaaennixx hat geschrieben: ↑Fr Nov 08, 2024 9:46 pm Hierbei ist mir aufgefallen, dass die Darstellung im TWS Busmonitor von der im ETS Busmonitor abweicht. Der TWS erfindet bis zu 15 Nachkommastellen hinzu, die von meinen Zählern so nicht gesendet werden.

Der TWS erfindet nichts hinzu sondern stellt den exakten Float-Wert in Dezimal mit der entsprechenden Anzahl Nachkommastellen dar.
Float 0x41ad999a in HEX ist halt 21,700000762939453125 in dezimal und nur näherungsweise 21,7.
Der Wert 21,7 kann in Float nicht exakt dargestellt werden.
Der TWS kann nicht wissen, welchen Dezimalwert der Sender wirklich ursprünglich hatte.

Für eine exakte Darstellung/Übertragung des ursprünglichen Werts bräuchte man dann Fixpunkt-Darstellung - also Integer, wo man festlegt, wie viele Nachkommastellen es gibt, und ggf. noch eine Skalierung.

Normalerweise fällt die Nichtexaktheit bei Float nicht so auf, wenn bei der Darstellung nur auf 1-3 Nachkommastellen gerundet wird, so wie das die ETS macht. Der Fehler wird allerdings immer größer, je größer die darzustellende Zahl ist.

Viele Grüße

Bernhard

Hallo Bernhard,

vielen Dank für deine Erklärung. Dann werde ich das so hinnehmen wie es ist. Ich nehme an, dass die „falschen“ HEX Zahlen wohl vom Arcus Gateway generiert werden, denn vom M-Bus kommen soweit ich das sehe die richtigen Werte.

Ich kann damit gut leben

Hi Raimund,

das Problem ist der KNX-Standard hier (bzw. dessen geringer Übertragungsrate von 9600 Bit/s und dem damit verbundenem Sparzwang bei den Paketgrößen). Im KNX Standard wird für diesen Datentyp nur ein 16 Bit Float verwendet und dieses hat eine geringe Auflösung und damit kommt es zu diesen "Abweichungen".

Wir werden überlegen, ob wir nicht eine "Rundungsfunktion" einbauen bei uns, so dass wir auf übliche zwei bis drei Stellen kommen.

lg

Stefan

Schöner wäre in dem Fall ein Runden auf 6-7 signifikante Stellen.
Lg Robert

Der M-Bus Wärmemengenzähler sendet ja verschiedene Werte, aber immer maximal 3 Nachkommastellen, das sollte meiner Meinung nach ausreichen. Ich habe es aufgrund von Zeitmangel noch nicht ausprobiert, aber wenn ich die Werte in der Visu anzeigen lassen will, kann ich doch da auch die überflüssigen Nachkommastellen ausblenden, oder? Eventuelle Rundungsfehler wären da auf jeden Fall vernachlässigbar.