WebUI/ReGaHss Beta für CCU2 & RaspberryMatic (2.29.x)

[mule]

bei mir läuft der CUxD mit der ReGaHss Beta20 und mehreren CULs problemlos auf einer CCU2.

Danke für die Info! Gerade noch einmal bei mir getestet und wieder mit dem identischen Problem und der Beta20. Ich hoffe ich kann das am Wochenende genauer analysieren.

[jmaus]

Ich kann bestätigen, dass es mit der Beta 20 Probleme gibt, wenn man versucht Systemvariablen per Skript auf leere Zeichenkette zu ändern.

Danke für die Bestätigung, hab es auch gerade getestet und ich denke ich hab den Fehler auch bereits lokalisiert. Wird dann in der beta21 repariert sein. Hast du auch mal das mit Wartelisten setzen in Programmen versucht zu reproduzieren? Dazu kam ich noch nicht.

[HMside]

Nur wenn man unten den Button "Systeminterne Programme einblenden" klickt, werden die "normalen" Programme nebst der Systeminternen sichtbar.

Fix siehe hier: viewtopic.php?f=65&t=38721&start=10#p382212

[BadenPower]

ReGaHSS verlernt das "Rechnen":

Nein, es hat das Rechnen nicht verlernt sondern ist in der Tat sogar genauer/detaillierter in der Ausgabe von Gleitkommazahlen geworden.
....
Das sollte erklären warum die beta20 in der Tat "richtiger" liegt in der Ausgabe (Anzeige 2.9999 statt 3.000) und Weiterverarbeitung der Werte.

Statt dieses Beitrages zu schreiben in dem Du darlegen möchtest, dass Du ja alles wieder richtig gemacht hast, hättest Du Dir über die Tragweite dieser Änderung Gedanken machen können.

Ich hatte Dir bereits irgendwo geschrieben, dass Du es wieder so machen sollst wie die 102. Aber das hast Du schlichtweg nicht gelten lassen.

Schau Dir einmal das genau an:

Code: Alles auswählen

real lReal2 = 0.7 - 0.4;
WriteLine(dom.BuildLabel());
WriteLine("lReal2:" # lReal2);
WriteLine("lReal2 str: " # lReal2.ToString(0));
WriteLine("lReal2 str: " # lReal2.ToString(1));
WriteLine("lReal2 str: " # lReal2.ToString(2));
WriteLine("lReal2 str: " # lReal2.ToString(3));
WriteLine("lReal2 str: " # lReal2.ToString(4));
WriteLine("lReal2 str: " # lReal2.ToString(5));
WriteLine("lReal2 str: " # lReal2.ToString(6));
WriteLine("lReal2 str: " # lReal2.ToString(7));
WriteLine("lReal2 str: " # lReal2.ToString(8));
WriteLine("lReal2 str: " # lReal2.ToString(9));
WriteLine("lReal2 str: " # lReal2.ToString(10));

Dies ist die vermurkste Ausgabe:

Code: Alles auswählen

lReal2 str: 0
lReal2 str: 0.3
lReal2 str: 0.30
lReal2 str: 0.300
lReal2 str: 0.3000
lReal2 str: 0.30000
lReal2 str: 0.299999
lReal2 str: 0.3000000
lReal2 str: 0.30000000
lReal2 str: 0.300000000
lReal2 str: 0.3000000000

Na, immer noch nicht kapiert?

Durch diese Änderung werden Programme nicht korrekt gestartet und abgearbeitet.

So und daher auch meine Warnung.
.

[jmaus]

Oh mann, kannst du bitte nicht einfach deine Zusatzkommentare weglassen und dich nur aufs fachliche/technische konzentrieren? Warum können wir uns da nicht einfach drauf einigen und all die anderen Dinge die der Sache nicht dienlich sind weglassen und komplett neutral und emotionslos diskutieren? Ich bin da zumindest dazu bereit.

Schau Dir einmal das genau an:

Das habe ich und es ist in der Tat genau so wie du sagt. Allerdings sieht man wenn man die zusätzliche Prüfung auf != 0.3 einbaut, das der Ursprung des Problems (0.7 - 0.4 != 0.3) auch in der alten ReGaHss zu sehen ist und somit anders gelagert ist. Denn auch dort hat der Wert nach der Subtraktion unverständlicherweise nicht exakt den wert 0.3 sondern eben 0.299999. Und durch die Nutzung von ToString() wird dieser Wert eben wieder auf X stellen gerundet. Deine Ausgabe zeigt aber natürlich auch, das in der Operation von ToString(6) der Wert wieder als 0.299999 ausgegeben wird, vmtl. weil er eben exakt diesen Wert besitzt und somit keine Rundung durchgeführt werden muss.

Code: Alles auswählen

real lReal2 = 0.7 - 0.4;
WriteLine(dom.BuildLabel());
WriteLine("lReal2:" # lReal2);
if(lReal2 != 0.3) { WriteLine("lReal2 ist NICHT exakt 0.3"); }

Ausgabe:

Code: Alles auswählen

R1.00.0388.0102
lReal2:0.300000
lReal2 ist NICHT exakt 0.3

Wie schon gesagt werde ich mir allerdings das ursprüngliche Problem (0.7 - 0.4 != 0.3) einmal näher anschauen und versuchen das ganze dahingehend zu reparieren das da am Schluss in der Tat exakt 0.3 rauskommt und nicht nur das WriteLine() dann "0.3" ausgibt (weil es eben früher gerundet hat) sondern auch die lReal2 variable dann exakt den Wert 0.3 besitzt.

[BadenPower]

Das habe ich und es ist in der Tat genau so wie du sagt. Allerdings sieht man wenn man die zusätzliche Prüfung auf != 0.3 einbaut, das der Ursprung des Problems (0.7 - 0.4 != 0.3) auch in der alten ReGaHss zu sehen ist und somit anders gelagert ist.

Jens, Du siehst das Problem nicht.

Bestehende Programme werden falsch ausgeführt.

Code: Alles auswählen

WENN
  Systemzustand "Zahl" bei "größer oder gleich 0.30" bei Aktuallisierung auslösen
DANN
  Systemzustand "Zeichenkette" sofort "Der Dimmer steht bei 30%" 

In einem anderen Programm, bei dem zum Beispiel der Dimmerwert um 40% gesenkt werden solch mit einem Skript:
Ich habe einfachheithalber das Auslesen weggelassen:

Code: Alles auswählen

object lSysVar = dom.GetObject("Zahl");
real lReal = 0.7 - 0.4;
lSysVar.State(lReal);

So ein Programm würde mit der Beta20 nicht mehr korrekt funktionieren.

Das ist nur eines der vielen möglich Beispiele. Denke auch an Jalousiesteuerung usw..

Du erwartest nicht wirklich, dass die Homematic-User nun alle ihre Programme und Skript ändern?
Sorry, Du schaust einfach nicht über den Tellerrand, sonst würdest Du diese Probleme erkennen und dies ist leider das Problem, welches ich mit Deiner Arbeit habe.
.

[DrTob]

Deine Ausgabe zeigt aber natürlich auch, das in der Operation von ToString(6) der Wert wieder als 0.299999 ausgegeben wird, vmtl. weil er eben exakt diesen Wert besitzt und somit keine Rundung durchgeführt werden muss.
.

Nein, denn dann dürfte ToString(7) nicht wieder 0.3000000 sein! (So groß ist eine Mögliche Ungenauigkeit außerdem nun wirklich nicht...) Ich vermute eher, dass du bzw. deine Ausgabe-„Korrektur“ der Grund ist.

[BadenPower]

Nein, denn dann dürfte ToString(7) nicht wieder 0.3000000 sein! (So groß ist eine Mögliche Ungenauigkeit außerdem nun wirklich nicht...) Ich vermute eher, dass du bzw. deine Ausgabe-„Korrektur“ der Grund ist.

Endlich jemand der sieht und versteht was ich schreibe.
.

[mule]

Das das grundsätzliche Problem ist doch, das 0.7-0.4 <> 0.3 ist. Daran dürfte wohl niemand zweifeln.

Zu den derzeitigen Resultaten mit der Beta20: Ich denke schon das jmaus bezüglich dessen, was als Auswirkung derzeit passiert Recht hat: Die Variable hat intern exakt den Wert 0.299999 (keine weiteren Nachkommastellen). Nur wenn exakt mit dieser Anzahl an Nachkommastellen gearbeitet wird, dann erfolgt keine Rundung und es wird der exakte interne Wert 0.299999 genutzt. Bei Operationen mit einer abweichenden Anzahl an Nachkommstellen wird gerundet und daher dann 0.3... ausgegeben. Das erklärt auch die Ergebnisse ab ToString(7).

Allerdings verstehe ich das Beispiel von Badenpower nicht, indem ein Programm ab 0.30 auslösen soll, obwohl die abgefragte Variable den Wert 0.299999 aufweist. 0.299999 ist und bliebt < 0.30.
Durch die bisherigen Änderungen von jmaus sehe ich eher eine Verbesserung, da bis auf den einen (in der Praxis wohl eher extrem selten auftretenden Fall String(5)) mit den exakt identischen Nachkommastellen nun immer der Wert 0.3xxx vorliegt und somit ein Programm wie gewünscht bei >= 0.30 ausgeführt werden würde (im Gegensatz zu vorher).

Letztendlich halte ich den Weg des Rundens aber für den falschen Lösungsweg, denn dieser Ansatz versucht nur Symptome eines anders gelagerten Fehlers zu korrigieren, der aber wieder andere Fehler mitsich bringt (ungewolltes Runden). Daher halte ich die Beseitung des Problems 0.7-0.4 <> 0.3 als den einzig sinnvollen Lösungsweg.

[jmaus]

Jens, Du siehst das Problem nicht.

Ich sehe das Problem sehr wohl, betrachte es nur vmtl. unter einem anderen Blickwinkel.

In einem anderen Programm, bei dem zum Beispiel der Dimmerwert um 40% gesenkt werden solch mit einem Skript:
Ich habe einfachheithalber das Auslesen weggelassen:

Code: Alles auswählen

object lSysVar = dom.GetObject("Zahl");
real lReal = 0.7 - 0.4;
lSysVar.State(lReal);

So ein Programm würde mit der Beta20 nicht mehr korrekt funktionieren.

Da hast du natürlich wieder prinzipiell Recht. Trotzdem bleibt es allerdings bei der Tatsache, dass nach der oberen Subtraktion von 0.7 - 0.4 der Wert von lReal eben nicht exakt 0.3 ist, sondern auf Grund von Floating Point Arithmetik eben 0.299999. und somit würde z.B. ein "if(lReal >= 0.3) {}" ins leere laufen innerhalb eines Skriptes. Und auch wenn das am Schluss eben auf Grund der Art wie Floating Point Arithmetik funktioniert nicht komplett zu vermeiden ist, so sehe ich hier sehr wohl Optimierungspotential um dafür zu sorgen das nicht nur Programme/Skripte die Werte wieder wie gewohnt erhalten, sondern eben auch innerhalb eines Skriptes man solch einfache Berechnungen durchführen und auf das menschliche Verständnis solch einer Gleitkommazahlenoperation abbilden kann sodass am Schluss nach solch einer Operation eben 0.3 rauskommt und nicht 0.299999. Das ist aber, wie ich schon gesagt hatte nicht ganz so einfach weil Floating Point Arithmetik eben nunmal solche Randbedingungen hat.

Du erwartest nicht wirklich, dass die Homematic-User nun alle ihre Programme und Skript ändern?

Natürlich erwarte ich das nicht. Das ist eine Betaversion und genau dafür ist dieser Thread bzw. diese Version eben da um daran gemeinschaftlich zu arbeiten und Dinge zu verbessern. Das dies nicht ohne holpern funktioniert liegt allerdings in der Natur der Dinge und genau deshalb wurde dieses Betaprogram auch mit Unterstützung von eQ3 ausgerufen. Und ich bin auch für jede Beteiligung die konstruktive Hinweise/Vorschläge bringt immer offen und dankbar.