falsche Vergleiche von Gleitkommazahlen im Script

[Matsch]

CCU3, V 3.45.7
Eigentlich eine auf den ersten Blick sehr einfache Aufgabe.
Ich möchte in einem Homematic-Script die Differenz zweier Temperatursensoren ermitteln und diese nur dann in eine Variable einschreiben, wenn sich der Wert gegenüber der Variablen geändert hat:

Code: Alles auswählen

! Differenz aussen-innen ermitteln                     

real T_out = dom.GetObject("Temperatur/Luftfeuchtigkeitssensor_Ch1").DPByHssDP("ACTUAL_TEMPERATURE").Value();
real T_in = dom.GetObject("SZ_Klimasensor_Ch1").DPByHssDP("ACTUAL_TEMPERATURE").Value();
var Delta = dom.GetObject("SV_SZ_Delta_Temperatur");

if ((T_out - T_in) <> Delta.Value())
{
   Delta.State(T_out - T_in);
}

Funktioniert aber nicht! Obwohl der Browser für den neu errechneten Wert und den früher gespeicherten Wert identisch gleich anzeigt (bis zur 6. Stelle nach dem Komma) liefert der if-Vergleich stets den Wert true. Ich bin fast daran verzweifelt, bis ich aus lauter Blödsinn die Werte vor dem Vergleich versuchsweise mal gerundet habe:

Code: Alles auswählen

if ((T_out - T_in).Round(4) <> Delta.Value())
{
   Delta.State(T_out - T_in);
}

Plötzlich geht alles einwandfrei, selbst dann, wenn ich als Rundung .Round(12) benutze!
Ich habe nach bekannten Problemen gesucht, aber dieses hier nicht gefunden.

[Matsch]

OK, habe den Fehler gefunden.
Ich hatte als Grenzwerte der Variablen SV_SZ_Delta_Temperatur eingeben: -40 .... 50.
Damit bewertet die CCU die Variable wohl als Ganzzahl.

Ein neu definierter Bereich -40.0 ... 50.0 hat das Problem behoben!

[dtp]

Evtl. hätte ein

Code: Alles auswählen

Delta.Value().ToFloat()

das Problem auch gelöst.

[Black]

OK, habe den Fehler gefunden.
Ich hatte als Grenzwerte der Variablen SV_SZ_Delta_Temperatur eingeben: -40 .... 50.
Damit bewertet die CCU die Variable wohl als Ganzzahl.

Ein neu definierter Bereich -40.0 ... 50.0 hat das Problem behoben!

Das darf es eigentlich nicht sein...

eine normale Systemvariable Type Zahl ergibt ValueType 4 bzw ValueTypeStr Float, eine IntegerSysvar (Aufzählung, oder Alarmmeldungen ergibt ValueType 16 bzw ValueTypeStr Integer

das blöde ist, ich konnte deinen Fehler bei mir Nachstellen, bis auf das Bereich umdefinieren, das hat darauf keinen Einfluss.

Code: Alles auswählen

!- Differenz aussen-innen ermitteln

real T_out =23.6;
real T_in = 24.7;
object Delta = dom.GetObject("NeuTestZahl");
real diff= T_out-T_in;
WriteLine (diff);
WriteLine (Delta.Variable () );
if (diff != Delta.Variable())
{
   WriteLine ("SET");
   Delta.State(diff);
} else {
   WriteLine ("Not SET");
}    

ergab:

Code: Alles auswählen

------------------------------- Scriptausgabe -------------------------------
-1.100000
-1.100000
SET
------------------------------ Script Variablen -----------------------------
[T_out             ]: 23.600000
[T_in              ]: 24.700000
[Delta             ]: NeuTestZahl
[diff              ]: -1.100000

während das hier:

Code: Alles auswählen

!- Differenz aussen-innen ermitteln

real T_out =23.6;
real T_in = 24.7;
object Delta = dom.GetObject("NeuTestZahl");
real diff= T_out-T_in;
WriteLine (diff);
WriteLine (Delta.Variable () );
if (-1.100000 != Delta.Variable())
{
   WriteLine ("SET");
   Delta.State(diff);
} else {
   WriteLine ("Not SET");
} 

sauber durchgeht.

Code: Alles auswählen

------------------------------- Scriptausgabe -------------------------------
-1.100000
-1.100000
Not SET
------------------------------ Script Variablen -----------------------------
[T_out             ]: 23.600000
[T_in              ]: 24.700000
[Delta             ]: NeuTestZahl
[diff              ]: -1.100000

Black

[Matsch]

@Black, genau dieses Verhalten hatte ich bei meinen Versuchen auch festgestellt und ins Grübeln gebracht!
Auch sehr komisch, dass allein ein Rundungsbefehl *.Round(12) zur korrekten Funktion führt! 12 Stellen nach dem Komma!

Aber wenn da doch noch ein Bug in der Software steckt, dann hätte das doch irgendeinem Anwender schon lange mal auffallen müssen. Ist doch eigentlich ein simpler alltäglicher Vergleich.

Interessant auch:
Die Datenpunkte aus den Sensoren sind eigentlich als integer definiert. Stelle ich alle Variablen im Script deshalb mal auf integer statt real um, hat das keinen Effekt, die Vergleichsauswertung ist auch dabei wieder falsch.

[Black]

die Datenpunkte Temperatur und Humidity sind zumindest beimeinem Wandthermosten und Heiszungsthermosten als float definiert.

Black

[Matsch]

Was ist eigentlich der Unterschied zwischen logischem und physikalischem Datentyp?
In der Definition steht Logisch FLOAT, Physikalisch integer (es sind beides HmIP-Sensoren).

Heißt das, dass zwar der Wert in einer integer übertragen wird vom Sensor, dieser dann aber als float-Zahl zur Verfügung gestellt wird?

Dann wäre es also doch im Script eine float-Zahl.

[jp112sdl]

Da physisch nur einzelne Bytes übertragen werden (die je nach Anzahl dann einen 8-, 16-, ... Bit breiten Ganzzahlwert ergibt), bedient man sich einem Divisor, um daraus dann eine Gleitkommazahl zu machen.

Beispiel Temperatursensor:
Es soll eine Temperatur von 10,7°C übertragen werden. Man multipliziert das im Sensor mit 10, überträgt ein Byte "107" und sagt der CCU dass der Wert wieder durch 10 geteilt werden muss (und eine Gleitkommazahl von 10,7 ergibt).
Sieht in der Geräte-XML so aus:

Code: Alles auswählen

<physical type="integer" interface="command" value_id="TEMPERATURE">
<conversion type="float_integer_scale" factor="10.0"/>

[Matsch]

Danke!

[Black]

das die kommunikation integer basiert ist mir klar.

seine probleme beruhen aber auf float operation der rega, nachdem der i8 bzw i16 in float konvertiert worden ist