HomeMatic-Forum / FHZ-Forum

Ich habe einen RPC Client entwickelt, der sich für Events bei CUxD registriert. Die Übertragung und Dekodierung der Events von CUxD funktioniert auch. Allerdings nur bei positiven Werten. Negative Werte werden bei der Dekodierung verfälscht und als positive Werte interpretiert.

Wie kodiert CUxD negative Fließkommawerte? Bisher gehe ich von folgendem Format aus:

32 Bit Word: Mantisse (Vorzeichenbehaftet)
32 Bit Word: Exponent

Daraus baue ich den Fließkommawert dann so zusammen:

Mantisse / 0x40000000 * (2 hoch Exponent)

Skripdoku hat geschrieben:±1,7*10 ±308 , 15 signifikante Dezimalstellen

Das sieht eher aus nach 11 Bit Exponent (inkl. Vorzeichen) und 53 Bit Mantisse (inkl. Vorzeichen).

Hier ist's beschrieben: viewtopic.php?f=31&t=8210

Viele Grüße

Uwe

@Paul53:
Bei BIN-RPC wird leider nicht die IEEE-Darstellung (11 Exp./52 Mant./1 Vorz.) verwendet. Warum auch einen Standard verwenden?

zap hat geschrieben:Mantisse / 0x40000000 * (2 hoch Exponent)

Die Formel ist korrekt. Sie funktioniert auch für negative Mantissen. Eventuell liegt es an den Typkonvertierungen oder der Auswertungsreihenfolge.
(Hinzuzufügen wäre noch, dass die Mantisse (nach der Division) immer größer gleich 0.5 und kleiner 1.0 sein sollte. Das betrifft aber nur das kodieren.)

Ein paar Testdaten:
0.0: [00, 00, 00, 00], [00, 00, 00, 00]
1.0: [20, 00, 00, 00], [00, 00, 00, 01]
-1.0: [e0, 00, 00, 00], [00, 00, 00, 01]
-10.0: [d8, 00, 00, 00], [00, 00, 00, 04]

Die Implementierung des BIN-RPC-Protokolls im CCU-Historian ist wohl vollständig (s.a. https://github.com/mdzio/ccu-historian/ ... itf/binrpc). Ich denke, dass ich die selben C-Quellen in der Hand hatte, wie sie auch die CCU verwendet. Es gibt z.B. zwei bisher nicht bekannte Datentypen (DATE und BINARY), die aber wohl nicht von der CCU verwendet werden.

Gruß
Mathias

Danke für die Infos!

@Mathias: Die Beispiel sind sehr hilfreich. Muss ich jetzt mal testen.

Grüße
Dirk

Ich glaube ich habe es jetzt.

Problem: Die Perl Funktion zum Entpacken eines signed integers aus Binärdaten (unpack 'l') erwartet eine umgekehrte Byte Order. Wenn ich die vorher ändere, funktioniert alles. So wie es aussieht schickt CUxD die Daten nicht in "Network Byte Order".