HomeMatic CCU2 bei ELV bestellen

Codierung von Float Werten in RPC Schnittstelle

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

Werbung


Codierung von Float Werten in RPC Schnittstelle

Beitragvon 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)
zap
 
Beiträge: 42
Registriert: 05.12.2014, 18:57

Re: Codierung von Float Werten in RPC Schnittstelle

Beitragvon 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)
paul53
 
Beiträge: 2402
Registriert: 26.04.2012, 20:42
Wohnort: Berlin

Re: Codierung von Float Werten in RPC Schnittstelle

Beitragvon 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
Benutzeravatar
uwe111
 
Beiträge: 3564
Registriert: 26.02.2011, 23:22

Re: Codierung von Float Werten in RPC Schnittstelle

Beitragvon 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/tree/master/hc-utils/src/mdz/hc/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
Mathias
 
Beiträge: 738
Registriert: 03.11.2010, 11:25
Wohnort: Aachen

Re: Codierung von Float Werten in RPC Schnittstelle

Beitragvon 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

Beitragvon 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".
zap
 
Beiträge: 42
Registriert: 05.12.2014, 18:57


Zurück zu CUxD

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 8 Gäste







© homematic-forum.de & Lizenzgebern. Alle Rechte vorbehalten. Alle Bilder & Texte auf dieser Seite sind Eigentum
der jeweiligen Besitzer und dürfen ohne deren Einwilligung weder kopiert noch sonstwie weiter verwendet werden.