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

Einrichtung, Nutzung und Hilfe zu RaspberryMatic (OCCU auf Raspberry Pi)

Moderatoren: jmaus, Co-Administratoren

Benutzeravatar
roe1974
Beiträge: 746
Registriert: 17.10.2017, 16:15
System: Alternative CCU (auf Basis OCCU)
Wohnort: Wien
Hat sich bedankt: 52 Mal
Danksagung erhalten: 13 Mal

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

Beitrag von roe1974 » 28.05.2020, 09:41

Hallo zusammen
Bin ein bisschen verwundert .... dieses einfache Programm setzt mir die Variable "Visu_Heizung_Pumpe" (Typ Zahl, min:0, max:100, Unit:%) auf "1%" statt "100%" ... wieso ?
Rechts oben steht auch "1%" ... wieso ?
lg Richard
PS: System: RM 3.51.6.20200420
Unbenannt.PNG

Benutzeravatar
Baxxy
Beiträge: 10847
Registriert: 18.12.2018, 15:45
System: Alternative CCU (auf Basis OCCU)
Hat sich bedankt: 610 Mal
Danksagung erhalten: 2229 Mal

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

Beitrag von Baxxy » 28.05.2020, 09:58

roe1974 hat geschrieben:
28.05.2020, 09:41
auf "1%" statt "100%" ... wieso
Das war letztens erst irgendwo Thema. Finde es aber leider gerade nicht.
Dafür aber einen Uralt-Thread mit den gleichen Symptomen.

Grüße
Baxxy

Benutzeravatar
roe1974
Beiträge: 746
Registriert: 17.10.2017, 16:15
System: Alternative CCU (auf Basis OCCU)
Wohnort: Wien
Hat sich bedankt: 52 Mal
Danksagung erhalten: 13 Mal

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

Beitrag von roe1974 » 28.05.2020, 10:05

Ok ... dürfte ein BUG sein .... ist mir noch nie aufgefallen :-/

manfredh
Beiträge: 4155
Registriert: 09.09.2012, 10:41
System: Alternative CCU (auf Basis OCCU)
Hat sich bedankt: 78 Mal
Danksagung erhalten: 301 Mal

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

Beitrag von manfredh » 28.05.2020, 10:17

Setze den Wert doch mal auf - sagen wir mal - 65%.

Meine Vermutung: da steht dann 0.65 in der SV.
Es gibt 10 Arten von Menschen: solche die Binärcode verstehen und solche, die ihn nicht verstehen.

Benutzeravatar
roe1974
Beiträge: 746
Registriert: 17.10.2017, 16:15
System: Alternative CCU (auf Basis OCCU)
Wohnort: Wien
Hat sich bedankt: 52 Mal
Danksagung erhalten: 13 Mal

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

Beitrag von roe1974 » 28.05.2020, 10:25

Vermutung bestätigt......

Matsch
Beiträge: 5452
Registriert: 30.05.2019, 11:37
System: Alternative CCU (auf Basis OCCU)
Wohnort: Chemnitz
Hat sich bedankt: 116 Mal
Danksagung erhalten: 742 Mal

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

Beitrag von Matsch » 28.05.2020, 11:19


manfredh
Beiträge: 4155
Registriert: 09.09.2012, 10:41
System: Alternative CCU (auf Basis OCCU)
Hat sich bedankt: 78 Mal
Danksagung erhalten: 301 Mal

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

Beitrag von manfredh » 28.05.2020, 12:15

Ich sehe das nicht unbedingt als Bug. Man kann ja damit arbeiten.

Ich setze z.B. SVen für die Rollladenpositionen der 4 Gebäudeseiten, auf die ich dann reagiere und die Rollladen fahren lasse. Das funktioniert einwandfrei mit Werten zwischen null (=0%) und eins (=100%).
Es gibt 10 Arten von Menschen: solche die Binärcode verstehen und solche, die ihn nicht verstehen.

Matsch
Beiträge: 5452
Registriert: 30.05.2019, 11:37
System: Alternative CCU (auf Basis OCCU)
Wohnort: Chemnitz
Hat sich bedankt: 116 Mal
Danksagung erhalten: 742 Mal

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

Beitrag von Matsch » 28.05.2020, 12:21

Doch, es ist ein Bug, denn die automatische Wandlung von Prozentzahl 43% in Dezimalzahl 0,43 erfolgt nicht konsequent im ganzen System einheitlich!
In bestimmten Situationen wird sie gemacht, in anderen nicht!
Du weißt also vorher nie wirklich, muß ich für 55% jetzt 0,55 oder 55 eingeben.
Leider muß man das immer wieder im konkreten Fall ausprobieren.

Xel66
Beiträge: 14169
Registriert: 08.05.2013, 23:33
System: Alternative CCU (auf Basis OCCU)
Wohnort: Nordwürttemberg
Hat sich bedankt: 586 Mal
Danksagung erhalten: 1501 Mal

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

Beitrag von Xel66 » 28.05.2020, 13:07

Matsch hat geschrieben:
28.05.2020, 12:21
...Wandlung von Prozentzahl 43% in Dezimalzahl 0,43 erfolgt nicht konsequent im ganzen System einheitlich!
Doch ist einheitlich. In Systemvariablen wird dieses als Dezimalzahl gespeichert, ebenso der Zugriff aus Scripten. Lediglich wenn der Aktor über seine Kanäle direkt angesprochen wird, tauchen die Prozente auf. Mathematisch ist aber beides gleich. War auch mal Schulstoff.

Gruß Xel66
-------------------------------------------------------------------------------------------
524 Kanäle in 146 Geräten und 267 CUxD-Kanäle in 34 CUxD-Geräten:
343 Programme, 334 Systemvariablen und 183 Direktverknüpfungen,
RaspberryMatic Version: 3.65.11.20221005 + Testsystem: CCU2 2.61.7
-------------------------------------------------------------------------------------------
Einsteigerthread, Programmlogik-Thread, WebUI-Handbuch

Matsch
Beiträge: 5452
Registriert: 30.05.2019, 11:37
System: Alternative CCU (auf Basis OCCU)
Wohnort: Chemnitz
Hat sich bedankt: 116 Mal
Danksagung erhalten: 742 Mal

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

Beitrag von Matsch » 28.05.2020, 16:12

Wenn du wirklich glaubst, dass Prozentwerte einheitlich behandelt werden, dann habe ich hier mal eine Denksportaufgabe für dich. Hier hatte ich eQ-3 das inkonsistente Verhalten erläutert:


Beispiel:

Ich arbeite mit Programmen an der Steuerung von Rollläden (HmIP-BROLL). Die Behanghöhe wird dabei stets in % angegeben (0...100%). Solch einen Wert verwalte ich in einer Systemvariablen. Entsprechend dem Wertebereich von 0...100% definiere ich die Variable also so:
Prozentzahlen01.jpg
Für die Spalte “Maßeinheit” geben Sie an: “beliebige Maßeinheit”. Schreibe ich dort aber das Zeichen “%” rein, stellt sich schnell heraus, dass die Maßeinheit eben nicht beliebig ist!
Lasse ich die Spalte leer, habe ich anschließend eine real-Zahl im Wertebereich von 0...100. Schreibe ich aber das Prozentzeichen rein, hat die Variable nur noch einen Wertebereich von 0...1, d.h. diese Maßeinheit führt unmittelbar zu einer Umdefinition der Variablen.
Zunächst habe ich mir erklärt, ok, 0.30 entspricht ja 30%. Wenn nun dieser Faktor von 100 für das Zeichen % konsequent überall im Programm umgesetzt würde, wäre das ja ok. Nur leider ist das wohl die einzige Stelle, wo dies Beachtung findet.
Bereits bei Übersicht der Systemvariablen funktioniert das nicht:
Prozentzahlen02.jpg
Prozentzahlen02.jpg (12.22 KiB) 1212 mal betrachtet

Da steht doch tatsächlich 0.30 % drin! Richtig wäre “30%” oder “0.30”! Ein Mischmasch aus beiden ist schlicht Unfug.

Noch konfuser wird es im Systemprotokoll, da steht doch tatsächlich:
Prozentzahlen03.jpg
Prozentzahlen03.jpg (18.83 KiB) 1212 mal betrachtet

Ja was denn nun? 0.30 sind nicht 0.30 %, sondern 30%!

Ok, könnten ja hier Darstellungsfehler sein. Doch das falsche Verhalten setzt sich bei der Erstellung von Programmen fort. Diese Bedingung hier ist semantisch logisch, wird aber nie erfüllt:
Prozentzahlen04.jpg

Denn für das Programm ist die Eingabe 30% eben nicht 30%, sondern 30.00, also 3000%!
Die Bedingung funktioniert erst, wenn ich trotz % dahinter nicht die Prozentzahl, sondern die Dezimalzahl dazu, also 0.30 angebe:
Prozentzahlen05.jpg
Erst mit diesem verwirrenden Eintrag funktioniert die Bedingung wie gewollt.
Wer soll begreifen, dass hier plötzlich das Prozentzeichen tatsächlich nur eine zusammenhangslose Maßeinheit und eben nicht den Faktor 100 repräsentiert?!

Und damit die Verwirrung komplett wird: Diese Anweisung hier wird nun aber korrekt umgesetzt und auf 30% gefahren, nicht auf 3000%!
Prozentzahlen06.jpg
Prozentzahlen06.jpg (18.62 KiB) 1212 mal betrachtet

Ergänzende Erklärung:
Anfangs haben die Entwickler von eQ-3 mir gegenüber behauptet, das Prozentzeichen als Maßeinheit einer Systemvariablen habe keinerlei Auswirkungen auf die Zahl an sich, sei lediglich ein beliebiges alphanumerisches Zeichen wie "kg" oder "cm". Die kannten anscheinend ihr eigenes System nicht wirklich!
Im Verlaufe der Diskussion haben sie dann doch das Problem erkannt.

Vermutlich wird auch das dich nicht überzeugen, eQ-3 hat es überzeugt, denn die letzte Stellungnahme lautete wie folgt:

"Das beschriebene Verhalten wird nachgestellt und fließt ggf. in zukünftige Releaseplanungen ein."

Das war im Februar 2019.

Antworten

Zurück zu „RaspberryMatic“