Bug in der CCU Version 3.59.6?

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

Moderatoren: jmaus, Co-Administratoren

MichaelN
Beiträge: 9562
Registriert: 27.04.2020, 10:34
System: CCU
Hat sich bedankt: 696 Mal
Danksagung erhalten: 1608 Mal

Re: Bug in der CCU Version 3.59.6?

Beitrag von MichaelN » 16.08.2021, 13:20

jp112sdl hat geschrieben:
16.08.2021, 06:36

Bei bereits erwähnter und besagter Lamellenverstellzeit ist das der Faktor 50.

Code: Alles auswählen

      <parameter id="REFERENCE_RUNNING_TIME_SLATS">
        <logical type="float" min="0.0" max="10.0" default="2.0" unit="s" />
        <physical type="integer" interface="config" list="1" index="179" size="2" />
        <conversion type="float_integer_scale" factor="50" offset="0.0" />
      </parameter>
https://github.com/AskSinPP/asksinpp-we ... #L295-L299

Der Wert kann/muss also mit 1/50 Genauigkeit in der WebUI eingegeben/gespeichert werden können.

Gibt man 1 Sekunde ein, wird 1 Byte mit Wert "50" zum Aktor übertragen.
Gibt man 1,02 Sekunden ein, wird der Wert "51" zum Aktor übertragen.
Gibt man 1,23 Sekunden ein - muss entweder auf +0,01 oder -0,01 addiert werden, dann nur Vielfache von 0,02 (1/50) erlaubt sind.
Macht bei 1,24 Sekunden 62.

:arrow: Es müssen für dieses Parameter-Feld Eingaben mit einer Genauigkeit von 0,02 erlaubt sein.
Was mich nur wundert ist, daß der Aufruf für diesen Parameter lautet:

Code: Alles auswählen

ProofAndSetValue('separate_CHANNEL_1_4_tmp', 'separate_CHANNEL_1_4', 0.00, 10.00, 1, event)
D.h. Factor ist 1! Erfolgt die Umrechnung erst "irgendwo" später?
LG, Michael.

Wenn du eine App zur Bedienung brauchst, dann hast du kein Smarthome.

Wettervorhersage über AccuWeather oder OpenWeatherMap+++ Rollladensteuerung 2.0 +++ JSON-API-Ausgaben auswerten +++ undokumentierte Skript-Befehle und Debugging-Tipps +++

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

Re: Bug in der CCU Version 3.59.6?

Beitrag von Baxxy » 16.08.2021, 14:07

jmaus hat geschrieben:
16.08.2021, 12:09
bei BidCos stecken die in den xml dateien
Dann passt da aber was nicht zusammen.

Beispiel HM-ES-PMSw1-Pl --> Statusmeldungen Mindestverzögerung
WebUI - Limits: s (0.50-15.50)
XML:

Code: Alles auswählen

<parameter id="STATUSINFO_MINDELAY" operations="read,write">
        <logical type="float" min="0.5" max="15.5" default="2.0" unit="s">
        <special_value id="NOT_USED" value="0.0"/></logical>
        <physical type="integer" interface="config" list="1" index="87.0" size="0.5"/>
        <conversion type="float_integer_scale" factor="2"/>
      </parameter>
Oder hat das wieder was mit dem Faktor zu tun?
jmaus hat geschrieben:
16.08.2021, 12:09
und sollten stattdessen die funktion die diese interpretiert (hier eben ProofAndSetValue() soweit ertüchtigen das diese damit besser klar kommt.
Klar. Aber Grundvoraussetzung ist doch nun mal eine korrekte Übergabe der Parameter.

Nehmen wir nochmal das Beispiel HM-LC-Bl1PBU-FM:
BL1_Fahrtzeit-Nachkommastelle.JPG
Hier werden alle 7 Parameter mit dem gleichen Aufruf behandelt.
  • 2x Integer - offensichtlich anhand der Limits (Anzahl der Fahrten bis zur automatischen Kalibrierfahrt; Max. Sendeversuche) - kein Faktor
  • 1x theoretisch Integer - falsche Limits (Statusmeldungen Zufallsanteil) - Faktor 1

    Code: Alles auswählen

    <parameter id="STATUSINFO_RANDOM" operations="read,write">
            <logical type="float" min="0.0" max="7.0" default="1.0" unit="s"/>
            <physical type="integer" interface="config" list="1" index="87.5" size="0.3"/>
            <conversion type="float_integer_scale" factor="1"/>
          </parameter>
    
  • 4x float mit einer Nachkommastelle - falsche Limits (Motorrichtungsumschaltzeit - Faktor 10; Fahrzeit von unten nach oben - Faktor 10; Fahrzeit von oben nach unten - Faktor 10; Statusmeldungen Mindestverzögerung - Faktor 2)
Wie soll hier die Funktion unterscheiden wie das jeweilige Feld zu handhaben ist?
Und was ist mit dem Faktor?
Das habe ich trotz Beispiel noch nicht durchschaut. Zumal ja auch der Faktor bei allen 7 Aufrufen mit 1 ausgegeben wird.
Könnte man den Faktor als Indiz für die Nachkommastellen heranziehen?

Bin ratlos. :shock:

Grüße
Baxxy

jp112sdl
Beiträge: 12085
Registriert: 20.11.2016, 20:01
Hat sich bedankt: 847 Mal
Danksagung erhalten: 2139 Mal
Kontaktdaten:

Re: Bug in der CCU Version 3.59.6?

Beitrag von jp112sdl » 16.08.2021, 14:15

Der Faktor aus der XML ist m.W. nicht per RPC Request abrufbar.
Nur die logische Beschreibung kann man auslesen (min, max, default, unit).

Das ist aber auch nicht schlimm, weil man mit dem Faktor keine Berührungspunkte hat.
Sprich: Ich sage dem Parameter - "du sollst jetzt den Wert 1,24 annehmen".
Der Schnittstelleprozess RFD rechnet das dann um (x 50) und schickt 62 ans Gerät. Umgekehrt genau so.

Ich hab das mit dem Faktor hier nur so kleinlich aufgedröselt, um aufzuzeigen, welche Präzision bei REFERENCE_RUNNING_TIME_SLATS verlangt wird/erlaubt sein soll.

VG,
Jérôme ☕️

---
Support for my Homebrew-Devices: Download JP-HB-Devices Addon

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

Re: Bug in der CCU Version 3.59.6?

Beitrag von Baxxy » 16.08.2021, 14:22

Ah, ok. Das ist verständlich. :)
Also hat der Faktor aus der XML...

Code: Alles auswählen

<conversion type="float_integer_scale" factor="2"/>
nichts mit dem Faktor zu tun der an die ProofAndSetValue übergeben wird?

Code: Alles auswählen

if (! dstValueFactor) dstValueFactor = 0.01;//dstValue = value/100
.
.
.
dstElm.value = (parsedValue.toFixed(digits) * dstValueFactor);
Grüße
Baxxy

jp112sdl
Beiträge: 12085
Registriert: 20.11.2016, 20:01
Hat sich bedankt: 847 Mal
Danksagung erhalten: 2139 Mal
Kontaktdaten:

Re: Bug in der CCU Version 3.59.6?

Beitrag von jp112sdl » 16.08.2021, 14:27

Baxxy hat geschrieben:
16.08.2021, 14:22
nichts mit dem Faktor zu tun der an die ProofAndSetValue übergeben wird?
Richtig. Es wird kein faktorisierter Wert an den Schnittstellenprozess gegeben.
Wenn in der WebUI "1.24" steht, wird das auch als "1.24" an den RFD-Prozess so übergeben.

VG,
Jérôme ☕️

---
Support for my Homebrew-Devices: Download JP-HB-Devices Addon

MichaelN
Beiträge: 9562
Registriert: 27.04.2020, 10:34
System: CCU
Hat sich bedankt: 696 Mal
Danksagung erhalten: 1608 Mal

Re: Bug in der CCU Version 3.59.6?

Beitrag von MichaelN » 16.08.2021, 14:32

Baxxy hat geschrieben:
16.08.2021, 14:07
Grundvoraussetzung ist doch nun mal eine korrekte Übergabe der Parameter.
Sehe ich auch so. Also kommt man doch nicht umhin alle Aufrufe der ProofAndSetValue zu ertüchtigen.
Was ich noch nciht verstanden habe - Wenn man die Limits generell als String übergeben würde - was wäre das schlimmste was passieren kann?
Man könnte 2 Nachkommastellen eingeben, die das Gerät so gar nicht speichern kann. Wenn man den Dialog wieder aufruft sind die Nachkommastellen weg (gerundet). Könnte den User irritieren. Aber das Gerät wird nicht abstürzen, weil ja nur die Anzahl Nachkommastellen dort gespeichert werden, die es verträgt. Richtig?
LG, Michael.

Wenn du eine App zur Bedienung brauchst, dann hast du kein Smarthome.

Wettervorhersage über AccuWeather oder OpenWeatherMap+++ Rollladensteuerung 2.0 +++ JSON-API-Ausgaben auswerten +++ undokumentierte Skript-Befehle und Debugging-Tipps +++

jp112sdl
Beiträge: 12085
Registriert: 20.11.2016, 20:01
Hat sich bedankt: 847 Mal
Danksagung erhalten: 2139 Mal
Kontaktdaten:

Re: Bug in der CCU Version 3.59.6?

Beitrag von jp112sdl » 16.08.2021, 14:41

MichaelN hat geschrieben:
16.08.2021, 14:32
Aber das Gerät wird nicht abstürzen
Das Gerät wird niemals abstürzen, weil der RFD nur das überträgt, was in der XML spezifiziert ist.
Selbst wenn du "Gurke" reinschreibst, wird der RFD nix machen... kann weder in eine Zahl noch mit irgendwas multipliziert werden.

Das ist nicht wie JavaScript, wo "Hallo + 5 / 3" noch irgendein Ergebnis liefert. :mrgreen:

VG,
Jérôme ☕️

---
Support for my Homebrew-Devices: Download JP-HB-Devices Addon

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

Re: Bug in der CCU Version 3.59.6?

Beitrag von Baxxy » 16.08.2021, 14:43

MichaelN hat geschrieben:
16.08.2021, 14:32
Richtig?
Vermutlich. :wink:
Ich kann mich aber erinnern das ich mal mit faschen Parametern die Geräteeinstellungsseite kaputt bekommen hatte. :lol:

MichaelN
Beiträge: 9562
Registriert: 27.04.2020, 10:34
System: CCU
Hat sich bedankt: 696 Mal
Danksagung erhalten: 1608 Mal

Re: Bug in der CCU Version 3.59.6?

Beitrag von MichaelN » 16.08.2021, 14:48

Baxxy hat geschrieben:
16.08.2021, 14:43
Ich kann mich aber erinnern das ich mal mit faschen Parametern die Geräteeinstellungsseite kaputt bekommen hatte.
Da bin ich dann bei Jens, das wir das immer noch fixen können, wenn es auftritt.
LG, Michael.

Wenn du eine App zur Bedienung brauchst, dann hast du kein Smarthome.

Wettervorhersage über AccuWeather oder OpenWeatherMap+++ Rollladensteuerung 2.0 +++ JSON-API-Ausgaben auswerten +++ undokumentierte Skript-Befehle und Debugging-Tipps +++

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

Re: Bug in der CCU Version 3.59.6?

Beitrag von Baxxy » 16.08.2021, 14:53

Lassen wir es halt mal drauf ankommen... 8)

Zum testen:
/www/config/ic_deviceparameters.cgi
Zeile 408 von...

Code: Alles auswählen

append s1 "<td><input type=\"text\" size=\"10\" value=\"$value\" id=\"separate_CHANNEL_$ch\_$i\_tmp\" name='__$param' onblur=\"ProofAndSetValue('separate_CHANNEL_$ch\_$i\_tmp', 'separate_CHANNEL_$ch\_$i', $min, $max, $factor, event)\"></td>"
in...

Code: Alles auswählen

append s1 "<td><input type=\"text\" size=\"10\" value=\"$value\" id=\"separate_CHANNEL_$ch\_$i\_tmp\" name='__$param' onblur=\"ProofAndSetValue('separate_CHANNEL_$ch\_$i\_tmp', 'separate_CHANNEL_$ch\_$i', '$min', '$max', $factor, event)\"></td>"
ändern.

Grüße
Baxxy

Edit:
In Zeile 442 ist ein ähnlicher Aufruf, da kann man...

Code: Alles auswählen

$min, $max,
auch zu

Code: Alles auswählen

'$min', '$max',
machen.

Edit2:
Die Modifizierung der XML fände ich jetzt auch nicht so dramatisch. :wink:
BL1_Fahrtzeit-Nachkommastelle_modified.JPG
Edit3:
Die Änderungen an der XML hätten nur Auswirkungen auf den jeweiligen Parameter des jeweiligen Gerätes...
Die Auswirkungen der Änderungen an der ic_deviceparameters.cgi auf andere Geräte sind noch unklar.

Antworten

Zurück zu „RaspberryMatic“