Codierung von Float Werten in RPC Schnittstelle

Anbindung von FS20-Komponenten, ELV-Wetterstationen, EnOcean und DMX an HomeMatic

Moderator: Co-Administratoren

Antworten
zap
Beiträge: 42
Registriert: 05.12.2014, 18:57

Codierung von Float Werten in RPC Schnittstelle

Beitrag von zap » 08.02.2018, 20:30

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)

paul53
Beiträge: 2409
Registriert: 26.04.2012, 20:42
Wohnort: Berlin

Re: Codierung von Float Werten in RPC Schnittstelle

Beitrag von paul53 » 08.02.2018, 21:46

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).
Versionen: HM-CC-TC 2.1, HM-LC-Sw1 1.9, HM-CC-RT-DN 1.1, HM-MOD-RPI-PCB 1.2.1 (keine CCU)

Benutzeravatar
uwe111
Beiträge: 3629
Registriert: 26.02.2011, 23:22
Kontaktdaten:

Re: Codierung von Float Werten in RPC Schnittstelle

Beitrag von uwe111 » 08.02.2018, 21:59

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

Viele Grüße

Uwe
Alle sagten: Das geht nicht. Dann kam einer, der wußte das nicht und hat's einfach gemacht.
SPENDEN :wink: Download: CUxD 2.0.1, RFD-Monitor, Vellemann K8055, SSH KeyDir

Mathias
Beiträge: 778
Registriert: 03.11.2010, 11:25
Wohnort: Aachen
Kontaktdaten:

Re: Codierung von Float Werten in RPC Schnittstelle

Beitrag von Mathias » 08.02.2018, 22:26

@Paul53:
Bei BIN-RPC wird leider nicht die IEEE-Darstellung (11 Exp./52 Mant./1 Vorz.) verwendet. Warum auch einen Standard verwenden? :evil:
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

zap
Beiträge: 42
Registriert: 05.12.2014, 18:57

Re: Codierung von Float Werten in RPC Schnittstelle

Beitrag von zap » 09.02.2018, 10:58

Danke für die Infos!

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

Grüße
Dirk

zap
Beiträge: 42
Registriert: 05.12.2014, 18:57

Re: Codierung von Float Werten in RPC Schnittstelle

Beitrag von zap » 09.02.2018, 15:23

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".

Antworten

Zurück zu „CUxD“