Einfaches Programm setzt Variable auf 1 statt 100 ?!?!?

[Matsch]

Dann hast du eine andere WebUI.
Es liegt nicht im Ermessen des Anwenders, die CCU-Firmware schreibt das %-Zeichen dort vor, erwartet aber an der einen Stelle tatsächlich einen Prozentwert, an der anderen aber die adäquate Dezimalzahl. Darauf hat der Anwender keinen Einfluß.
Eine Zahl zwischen 0...1 würde in der zweiten gekennzeichneten Zeile zu einem völlig falschen Ergebnis führen.

Im Gegensatz zur Programmoberfläche liegt es bei Scripten in deiner Hand, hier aber nicht.

[Xel66]

Es liegt nicht im Ermessen des Anwenders, die CCU-Firmware schreibt das %-Zeichen dort vor, erwartet aber an der einen Stelle tatsächlich einen Prozentwert, an der anderen aber die adäquate Dezimalzahl.

Ja, immer dann wenn der Kanal Behanghöhe des Aktors selbst beschrieben wird. Dann muss der gleiche Wert rein, der auch in der WebUI für diesen Wert erwartet wird (Prozentwert). Benutzt man allerdings Systemvariablen, dann kommt der Dezimalwert rein. Auch wenn man eine Systemvariable einem Aktorkanal zugeordnet hat. Soll heißen, die Systemvariable verhält sich anders als der Kanal der Behanghöhe. Ist schon immer so, selbst wenn man per Programm mit Bordmitteln (also ohne Script) über den "weißen Zettel" eine Behanghöhe in eine Systemvariable schreibt. Ich benutze das auch in dieser Richtung, um z.B. durch manuelle Bedienung den aktuellen Wert als Sollwert in eine Systemvariable zu schreiben.

An der Stelle mit dem Pfeil schreibe ich die aktuelle Behangöhe in den Sollwert per Programm und es landet dort ein Dezimalwert, selbst wenn die Systemvariable ein Wertebereich von 0-100 hat, weil intern die Behanghöhe als Dezimalwert behandelt und nur im WebUI im entsprechenden Kanal als Prozentwert dargestellt wird.

Gruß Xel66

[jp112sdl]

Das Problem ist die unterschiedliche Werteinheit zwischen Behanghöhe des Aktors und der Systemvariable.

Systemvariable: %
Aktor: 100%

Und bei einer SingleCondition erfolgt halt beim Aktor durch die WebUI (/www/rega/esp/sico.inc):

Code: Alles auswählen

        if( sValueUnit == "100%" )
        {
          sValueUnit = "%";
          iRV1 = iRV1*100;
          iRV2 = iRV2*100;
        }
        

und schon passt es wieder; der Anwender kann 60 eingeben (Wenn Behanghöhe Aktor = 60) und erhält 60% (weil die 0.6 vom Aktor hier *100 multipliziert werden).

Wenn die Einheit aber von Anfang an schon nur "%" ist, erfolgt keine Multiplikation.
0.6 werden auch nur als 0.6 angezeigt.

Probier(t) es bitte mal aus, wenn ihr der Systemvariable die Einheit "100%" verpasst!

Anders sieht es bei den SingleDestination aus.
Hier werden 60% angezeigt, wenn der Wert 0.6 ist (/www/rega/esp/side.inc):

Code: Alles auswählen

          real percVal = oSD.DestinationValue();
          if (oDP.ValueUnit() == "%") {
            percVal = oSD.DestinationValue() * 100;
          }
 

Auch in der (/www/rega/pages/msg/insertValue.htm) erfolgt die "Prozent2Dezimal" Umwandlung nur bei der Werteeinheit "100%":

Code: Alles auswählen

convertValue = function(value, unit) {
  if (unit == "100%") {
    value = parseInt(value,10);
    value = value/100.0;
  }
  if (unit == "∞C") {
    value = roundValue05(value);
  }
  return value;
};

Ich glaub, in dem Konstrukt gibt es noch Optimierungsbedarf seitens eQ-3 ^^

[Hominger]

Behanghöhe ?

[Matsch]

Xel66, es hilft hier wirklich nicht weiter, wenn du darauf beharrst, dass es in einem Fall funktioniert, wenn du alle anderen hier aufgezählten Fälle gewissentlich ignorierst.
Manchmal habe ich den Verdacht, du bist im wahren Leben Politiker

[Matsch]

Ich glaub, in dem Konstrukt gibt es noch Optimierungsbedarf seitens eQ-3 ^^

Prinzipiell richtig, aber "Optimierungsbedarf" ist auch ein oft benutzter Schönfärberausdruck für Bugfixing.

[jp112sdl]

"Optimierungsbedarf" ist auch ein oft benutzter Schönfärberausdruck für Bugfixing.

"Does not work as expected" ist nicht unbedingt ein "Bug"

Ist halt fraglich,
1.) ob das Konstrukt "besser/korrekt" funktioniert, wenn man der SV die Einheit "100%" gibt
2.) ob es sich lohnt, für RaspberryMatic einen WebUI Patch zu schreiben, wenn es eQ-3 eh im nächsten Release korrigiert

[Matsch]

1.) ob das Konstrukt "besser/korrekt" funktioniert, wenn man der SV die Einheit "100%" gibt

Das ist ja gar nicht das Thema.
Klar kann man sich darauf einigen, bei Nutzung des %-Zeichens muß der eingegebene Wert durch 100 dividiert werden bzw. der interne Wert für die Anzeige mit 100 multipliziert werden, Wertebereich 0...100).
Oder man legt fest, auch Prozentbrüche werden generell als Dezimalzahl 0....1 dargestellt.

Man darf aber diese beiden Varianten nicht kunterbunt vermischen - das ist das Thema.

Wir müssen uns doch eigentlich gar nicht darum streiten, wenn selbst eQ-3 (und das will was heißen) das Thema als Problem erkannt und akzeptiert hat.
Ich glaube aber nicht an eine Änderung, weil nämlich viele existierende Programme, die auf diese Besonderheit abgestimmt sind, dann nicht mehr laufen würden ...