Programmnamen nach dem Editieren um Ziffern ergänzt

[Stefan0815]

Alles gut bei mir. Gleiches Ergebnis wie bei Xel66.

Grüße
Baxxy

Kennt Ihr das Verhalten gar nicht?

[Baxxy]

Kennt Ihr das Verhalten gar nicht?

Doch schon. Aber wenn's hochkommt hatte ich das vielleicht 3-4 mal im letzten Jahr.

Grüße
Baxxy

[Stefan0815]

Kennt Ihr das Verhalten gar nicht?

Doch schon. Aber wenn's hochkommt hatte ich das vielleicht 3-4 mal im letzten Jahr.

Grüße
Baxxy

Kommt sicher auf die Häufigkeit der Änderungen an. Ich programmiere gerade meine Sonnenschutzsteuerung für die Markisen und Rollladen in Abhängigkeit von diversen Sensoren. Da bastelt man halt häufig an den Scripten.

[Stefan0815]

OK. Nach mehreren Tagen programmieren habe ich den Fehler gefunden. Wie üblich sitzt er vor dem Rechner.

Man darf den Editormodus der Programme nur mit "Abbrechen" oder "OK" verlassen. Da ich gelegentlich den aktuellen Status von Systemvariablen nachsehen oder einfach ein anderes Programm öffnen wollte, klickt man dann schon mal einfach in die obere Menüleiste. Das ist genau das Problem, denn dann wird das Programm anscheinend nicht zurückgeschrieben. Hält man sich an "Abbrechen" oder "OK", gibt es auch kein Problem.

Der beste Weg Scripte zu schreiben und zu testen ist aber in jedem Fall der Script Developer. Dann einfach das getestete Script hineinkopieren... fertig.

Ist schon mal jemand aufgefallen, dass:

real Faktor = 2.0;
real x = 10.10;
real z = 20.20;
real y = x+(Faktor*z);
WriteLine(y);

real Faktor = 2;
real x = 10.10;
real z = 20.20;
real y = x+(Faktor*z);
WriteLine(y);


unterschiedliche Werte ergibt? Homematic Script ist aber auch ein Mimöschen.

Grüße Stefan

[Xel66]

Wie ich schon geschrieben habe, beim Abbrechen wird die Bearbeitungskopie gelöscht und nicht in die Datenbank zurückgeschrieben. Darum konnte das auch nicht die Ursache sein. Ebenso bei OK, da werden die Änderungen zurückgeschrieben. Verlässt man das Editorfenster auf eine andere Art, wird beim weiteren Öffnen eben eine weitere Kopie des Programss geöffnet. Dieses erhält dann eine Ziffer. War schon immer so. Der Bug hat schon immer zwei Beine gehabt. Alle vorherigen diesbezüglichen Bugreports kamen zu dem gleichen Ergebnis.

Gruß Xel66

[Hütte]

...
Ist schon mal jemand aufgefallen, dass:

real Faktor = 2.0;
real x = 10.10;
real z = 20.20;
real y = x+(Faktor*z);
WriteLine(y);

real Faktor = 2;
real x = 10.10;
real z = 20.20;
real y = x+(Faktor*z);
WriteLine(y);


unterschiedliche Werte ergibt? Homematic Script ist aber auch ein Mimöschen.

Grüße Stefan

Ich würde vorschlagen, dafür einen separaten Thread aufzumachen. Denn in diesem Thread geht das bestimmt unter.

[Xel66]

Weil im ersten Beispiel die Real als Real behandelt wird und im zweiten Fall als Integer, weil der erste Therm eine Integerzahl ist (auch wenn Du sie als real deklariert hast). Die CCU rechnet von rechts nach links und beachtet keine mathematischen Regeln wie Punkt vor Strichrechnung. Ist auch so dokumentiert und bedarf deswegen auch nicht unbedingt eines separaten Threads.

Gruß Xel66

[jmaus]

...
Ist schon mal jemand aufgefallen, dass:

real Faktor = 2.0;
real x = 10.10;
real z = 20.20;
real y = x+(Faktor*z);
WriteLine(y);

real Faktor = 2;
real x = 10.10;
real z = 20.20;
real y = x+(Faktor*z);
WriteLine(y);


unterschiedliche Werte ergibt? Homematic Script ist aber auch ein Mimöschen.

Grüße Stefan

Ich würde vorschlagen, dafür einen separaten Thread aufzumachen. Denn in diesem Thread geht das bestimmt unter.

Dafür brauch man aber auch keinen extra Thread. Diese "Limitation" bzw. eigenheit der Homematic Skriptsprache ist schon länger bekannt und das liegt an der Reihenfolge der impliziten Datentypwandlungen die leider ursprünglich von den Entwicklern der Skriptsprache statt von rechts nach links von links nach rechts gewählt wurde wie das eigentlich in anderen Programmiersprachen üblich ist. So so ist "der schuldige" in dem oberen Beispiel die Zeile

Code: Alles auswählen

real y =  x+(Faktor*z);

Wenn man diese kurzhand in folgende ändert stimmt alles wieder:

Code: Alles auswählen

real y = x+(z*Faktor);

D.h. wie man daran erkennen kann kommt es sehr wohl auf die Reihenfolge der Argumente bei eine solchen Berechnung an, denn "Faktor" wird ja durch das fehlen des ".0" am schluss implizit in ein Integer gewandelt und somit kommt es da eben zu Rundungen.

[Stefan0815]

...woran das liegt, war mir schon klar. Als "normaler" Softwareentwickler hat man sowas allerdings selten auf dem Schirm. Ich hatte gerade ein Script in der Mache, was den gewichteten Mittelwert, Varianz und Standardabweichung einer Datenreihe berechnet. Überschlägig (rund 200 Werte) sehen die Daten dann gut aus. Zufällig habe ich das dann in Excel übernommen und von Hand gerechnet. Erst dann fällt diese kleine Unzulänglichkeit auf. Wenn bei expliziter Variablendeklaration eine Typumwandlung erfolgt, ist das schon etwas schräg. Also alles nur noch als var und AUFPASSEN.

Grüße
Stefan

[Xel66]

Also alles nur noch als var und AUFPASSEN.

Damit verhinderst Du auch keine Typenwandlung, denn diese geschieht auf Basis des Rechenwertes. Ergibt dieses eine Ganzzahl, wird automatisch mit Integer gerechnet. Kommt es auf Genauigkeit an, ist der Wert eben vor der Weiterverarbeitung mit 1.0 zu multiplizieren.

Gruß Xel66