ProofAndSetValue... wie geht's weiter?

[Baxxy13]

Um #1058 nicht unnötig weiter in die Länge zu ziehen würde ich hier gerne über mögliche (finale) Lösungen oder Lösungsansätze diskutieren.
Die letzten Tage habe ich mich ausgiebig mit dem Thema befasst und stand auch mit Uwe (von CUxD) in Kontakt. Das war sehr aufschlussreich, und führte dazu das Uwe eine neue CUxd-Version (2.5.3) herausbrachte weil die alte Version die übergeben Werte nicht korrekt übernahm / rundete und bei der Rückgabe der Werte eine Nachkommastelle abschnitt.

Wichtig ist hier aber nur zu wissen das das beispielhafte CUxD-Gerät (90) Universal Wrapper Device Typ Thermostat an den Stellen wo man Float-Werte übergeben kann intern mit 2 Nachkommastellen arbeitet. Dumm ist nur das die WebUI an diesen stellen die Limits mit einer Nachkommastelle vorgibt. Dazu später mehr.

So, ausgehend von der Aussage von @theimo1221

Es müssten hier also entsprechend die Templates angepasst werden, um eben die korrekten Werte als Minimum/Maximum als STRING nicht als Zahl zu übergeben (Zahlen schneiden überflüssige Nullen ab, Texte nicht.)

und dem Hinweis von @MichaelN0815

Ich habe nur eine einzige Stelle gefunden, wo versucht wird Fließkommazahlen als Zahl zu übergeben:

www\config\ic_common.tcl
Zeile 1344 append s " onkeyup=\" ProofAndSetValue('$input_idval', '${idval}', parseFloat($min), parseFloat($max), parseFloat([expr 1 / $factor]));\" /></td>"

Diese Stelle muss also auf jeden Fall korrigiert werden.

Variante A:
hatte ich die Zeile wie folgt abgeändert.
append s " onblur=\" ProofAndSetValue('$input_idval', '${idval}', '$min', '$max', parseFloat([expr 1 / $factor]));\" /></td>"

Damit waren alle (von mir testbaren) "Float-Eingabestellen" soweit in Ordnung. Der Eingegebene Wert wird als String übergeben und die Nachkommastelle richtet sich nach den Limits in der WebUI. Das bedeutet aber auch das das oben angeführte CUxD-Gerät nur mit einer Nachkommastelle gefüttert wird obwohl es 2 verdauen kann.

Variante B:
hatte ich die Zeile wie sie aktuell in CCU 3.57.4 ist, geändert.
append s " onblur=\" ProofAndSetValue('$input_idval', '${idval}', [expr $min + 0.001], [expr $max + 0.001], parseFloat([expr 1 / $factor]));\" /></td>"

Das führt natürlich dazu das erstmal (bis zu) 3 Nachkommastellen übergeben werden können, egal wie viele Nachkommastellen bei den Limits in der WebUI vorgegeben sind.

Ist das problematisch?
Zumindest für das angeführte CUxD-Gerät kann ich das verneinen.
Zitat Uwe:

Dieser Parameter ist vom Datentyp FLOAT (also beliebig viele Kommastellen) und wird vom CUxD intern auf 2 Nachkommastellen gerundet.

Also selbst wenn ich 22.44677 übergebe, werden bei der Rückgabe korrekte 22.45 ausgegeben.

Präferieren würde ich Variante A.
Idealerweise müsste man aber die Nachkommastellen der Limits an die Fähigkeiten des Gerätes anpassen.

Grüße
Baxxy

[MichaelN0815]

Also kommt expr $min + 0.001 doch aus der FW? Diese offizielle "Lösung" hat den Nachteil,daß man ggf.keinen Wert "0" mehr eingeben kann,wweil das unterste Limit 0,001 ist.

[Baxxy13]

Ja, ist in der aktuellen CCU 3.57.4 so drin. Sieht für mich irgendwie nach schnellem Workaround aus.
Mach doch mal bei Min expr $min - 0.001 zum testen draus.

Achso, ich benutze die letzte Ausgabe der ProofAndSetValue aus den Nightlys. Das Zusammenspiel mit der CCU 3.57.4 - Version der Funktion habe ich nicht untersucht.

[MichaelN0815]

Und wenn man das bei einem Datenpunkt macht, der keine Werte <0 verträgt? Ne, das kann man nicht machen.die einzige richtige lösung ist die Übergabe als string.vermutlich wusste das der Editierende nicht.

[Baxxy13]

Wie gesagt, ich präferiere ja auch Variante A.
Aber getestet habe ich es trotzdem schnell mal ;-)

per xmlrpc.GetParamset wird korrekt 0.000000 zurückgegeben und der Taster funktioniert noch.

Selbst wenn ich dem Datenpunkt per xmlrpc.PutParamset z.B. -1.256 übergebe geht der nicht kaputt. Er gibt dann sein Minimum von 0.000000 zurück. Kann also gar nicht falsch gefüttert werden.

[MichaelN0815]

Überigens habe ich noch ein Vorkommen von parseFloat gefunden.
In www/config/easymodes/wa_od_ch_master.tcl

Wofür auch immer diese Datei benötigt wird...

Zeile 186
append HTML_PARAMS(separate_1) "<td> <input type=\"text\" id=\"separate_CHANNEL_1_$paramNr\" name=\"$param\" value=\"[format {%1.2f} $ps($param)]\" onblur=\"ProofAndSetValue('separate_CHANNEL_1_$paramNr', 'separate_CHANNEL_1_$paramNr', parseFloat($min), parseFloat($max), parseFloat(1));\"> </td>"

Ändern zu:
append HTML_PARAMS(separate_1) "<td> <input type=\"text\" id=\"separate_CHANNEL_1_$paramNr\" name=\"$param\" value=\"[format {%1.2f} $ps($param)]\" onblur=\"ProofAndSetValue('separate_CHANNEL_1_$paramNr', 'separate_CHANNEL_1_$paramNr', '$min', '$max', parseFloat(1));\"> </td>"

[Baxxy13]

Ah ja. Das dürfte der
ELV Homematic Bausatz Kapazitiver Füllstandsmesser HM-Sen-Wa-Od
sein. :-)

[Baxxy13]

"Fieslinge" sind auch die Grenzwerte (z.B. Kanal:7 PSM) für den Entscheidungswert.
Kann man bei den klassischen Geräten (z.B. HM-ES-PMSw1) noch 2 Nachkommastellen eingeben sind es bei der PSM momentan null.
(Die Limits haben auch keine Kommastelle, somit werden nur Integer übernommen was funktionstechnisch i.O. ist)
Das Gerät kommt aber sehr gut mit max 2 Nachkommastellen klar, welche aber tatsächlich keine sind da die Eingabe einfach mit 100 multipliziert wird.
append html "<input id=\"thresLo_$chn\_$prn\" type=\"text\" size=\"5\" value=\"[expr $ps($param). / 100]\" onblur=\"ProofAndSetValue(this.id, this.id, 0, [getUserDefinedMaxValue $devType $param], 1); jQuery(this).next().val(this.value * 100)\"/>&nbsp;[getUserDefinedCondTXThresholdUnitMinMaxDescr $devType $param]"
Hier kann man also einen Grenzwert von 10.5 W nur durch Umgehung der WebUI eingeben. (im Gerät stehen dann 1050)

Wie läuft es denn bei @jp112sdl und den Homebrew-Geräten momentan bezüglich ProofAndSetValue?

[jp112sdl]

Nur bei einer Hand voll Geräte habe ich eigene Config-Seiten:
https://github.com/jp112sdl/JP-HB-Devices-addon/tree/master/src/addon/www/config/easymodes

Und da nutze ich ProofAndSetValue wie ich es irgendwo in anderen eQ-3 Dateien gefunden habe, z.B.
ProofAndSetValue('separate_CHANNEL_1_$paramNr','separate_CHANNEL_1_$paramNr', parseInt($min), parseInt($max), parseFloat(1));

Hat sich auch bisher niemand beschwert, dass da was nicht passt.
Ich bin hier auch recht leidenschaftslos... entweder es klappt irgendwann mal wieder oder eben nicht.
An meiner Meinung von hier: https://homematic-forum.de/forum/viewtopic.php?f=26&t=63436&start=60#p626311 hat sich nichts geändert.

[theimo1221]

Und da nutze ich ProofAndSetValue wie ich es irgendwo in anderen eQ-3 Dateien gefunden habe, z.B.
ProofAndSetValue('separate_CHANNEL_1_$paramNr','separate_CHANNEL_1_$paramNr', parseInt($min), parseInt($max), parseFloat(1));

Wie viele Nachkommastellen möchtest du hier denn eigentlich erlauben?

[jp112sdl]

Nicht mehr/weniger als notwendig :)
Es gibt. m.W. nur 1 Anwendungsfall für 3 Nachkommastellen (Zählersensor; m³ je Impuls = 0.001)

Und eigentlich ergibt sich das aus den min./max.-Werten der Geräteparameter (um beim HM-ES-TX-WM zu bleiben):

        <parameter id="METER_CONSTANT_GAS">
          <logical type="float" min="0.001" max="65.536" default="0.01" unit="m3/Imp." />
          <physical type="integer" interface="config" list="1" index="152" size="2.0" />
          <conversion type="float_integer_scale" factor="1000" />
        </parameter>

Es gibt doch die getMin und getMax Methoden, die diese Grenzen auslesen und dem ProofAndSetValue übergeben.
Dann hat man doch die Anzahl an für den jeweiligen Datenpunkt erlaubten/notwendigen Dezimalstellen?

EDIT: Ob da bei der Eingabe von 0.01 nun 0.01 oder 0.010 angezeigt wird, ist mir gleich.
Je weniger Darstellungs-Abweichungen es zur offiziellen FW gibt, um so besser.

[theimo1221]

Variante B:
hatte ich die Zeile wie sie aktuell in CCU 3.57.4 ist, geändert.
append s " onblur=\" ProofAndSetValue('$input_idval', '${idval}', [expr $min + 0.001], [expr $max + 0.001], parseFloat([expr 1 / $factor]));\" /></td>"

Was habt ihr da "unten" denn für eine Script/Template/was auch immer Sprache?

Solange euer Aufruf am Ende bei Minimum/Maximum so aussieht habt ihr 3 Nachkommastellen, ohne dass ihr die .001 machen müsst:
append s " onblur=\" ProofAndSetValue('...', '...', "", 'x.000', 'y.000');\" /></td>"

[theimo1221]

Gut dann passt ja alles 👍

[MichaelN0815]

Dann muss jetzt nur noch jemand einen "PullRequest" für die beiden geänderten tcl Dateien erstellen?! Ich habe ja gelernt, das man dazu Linux Tools braucht. Daher bin ich da raus.

[jp112sdl]

Ich habe das hier nicht alles verfolgt, daher nur kurz gefragt:

• muss ich dazu im Homebrew-Addon auch was an den .tcl-Files anpassen?
• wenn ja:
  • ist diese Anpassung auch noch kompatibel mit dem ProofAndSetValue der CCU-Original-FW ?

[MichaelN0815]

Rufst Du in deinen tcl Dateien die ProofAndSetValue mit parseFloat($min) auf? Wenn nein, dann ändert sich für Dich nichts.
Ich habe verstanden, daß Du die Funktion immer mit ... parseInt($min), parseInt($max)... auf rufst. Also im Endeffekt sind dann keine Nachkommastellen zulässig.
Wenn Du unbedingt Nachkommastellen zulassen willst, dann solltest Du die min/max Werte mit . .. '$min', '$max'.. . übergeben. Dies wird auch im Original-Code der CCU so gemacht ( an den Stellen, an denen die Aufrufe nicht verschlimmberssert wurden)

Wie kompatibel ist das mit dem Original? Ich würde behaupten kompatibler als das Original,da nun auch wieder Null-Werte zulässig sind. Wenn im Original nur Ganzzahlen zulässig sind,so sind sie es auch hier. Und sind im Original Fließkommazahlen zulässig, so auch hier. Der Unterschied wird sein,wie dies beim Verlassen des Eingabefelder angezeigt wird. @theimo1221 korrigiere mich bitte, wenn ich das falsch einschätze.

[jp112sdl]

Rufst Du in deinen tcl Dateien die ProofAndSetValue mit parseFloat($min) auf? Wenn nein, dann ändert sich für Dich nichts.

so z.B.
onblur=\"ProofAndSetValue('separate_CHANNEL_$chn\_$prn','separate_CHANNEL_$chn\_$prn', $min, $max, parseFloat(1));
https://github.com/jp112sdl/JP-HB-Devices-addon/blob/c9bddd2ead492077125bc72efc3819d306d6c26a/src/addon/www/config/easymodes/HB-UNI-Sen-PC-WM_ch_master.tcl#L93

Ich habe verstanden, daß Du die Funktion immer mit ... parseInt($min), parseInt($max)... auf rufst.

Nur da wo keine Dezimalstellen erlaubt sind.

[Baxxy13]

Soo... mal langsam.
Nicht das wir hier was durcheinanderbringen und die Zusammenhänge verlieren:

• ProofAndSetValue - Funktion (letzte Ausgabe von @theimo1221 in den RM Nightlys) und von mir oben beschriebene Variante A funktioniert (für RaspberryMatics) wunderbar.

• ProofAndSetValue - Funktion (aktuelle CCU 3.57.4 Firmware) und von mir oben beschriebene Variante A funktioniert in der CCU nicht besser oder schlechter wie die (originale) Variante B. Soll heißen die Probleme sind die gleichen, es kann z.B. nicht "0" eingegeben werden.

Auswirkungen oder nötige Änderungen an den Geräten von @jp112sdl sehe ich auch erstmal nicht.
Kommt dann aber vielleicht drauf an wie die Funktion in der nächsten CCU FW aussehen wird.

Noch ne kleine Anekdote aus meinen Tests die sehr gut zu einem Kommentar von @jens-maus passt.

und selbst würde ich auch wohl einfach komplett diese ganze ProofAndSetValue rückstandlos entfernen und einfach ein Freitextfeld dort belassen und dann die eigentliche prüfung den Routinen überlassen die diese Werte in die Geräteparameter kopieren

Das kann tatsächlich auch nach hinten losgehen wie ich feststellen musste.
Ich habe bei einem HB-LC-Bl1PBU-FM (umgeflashter HM-LC-Bl1PBU-FM) mal die "Statusmeldungen Mindestverzögerung" auf einen unerlaubten Wert (0.0) gesetzt (Limit 0.50-15.50).
Anschließend war die Einstellmöglichkeit in der WebUI verschwunden. (Der Aktor gibt aber ordnungsgemäß die 0.0 zurück. Ob der nun tatsächlich instant seinen Status sendet kann ich nicht beurteilen, bin wohl zu langsam. ;-) )

Wie auch immer... ich schließe mich @MichaelN0815 an, zumindest die www\config\ic_common.tcl zu Variante A zu ändern.
Dann könnten das mal ein paar User mit den Nightlys testen.
Bin aber auch nicht fähig einen PR zu erstellen.

Grüße
Baxxy

[MichaelN0815]

Da hat du natürlich recht. Wenn man die beiden Änderungen getrennt durchführen will, muss die Kompatibilität kreuzweise ggeprüft werden. Ich bin davon ausgegangen, dass man beides gleichzeitig ändert.

[MichaelN0815]

Lt. https://homematic-forum.de/forum/viewtopic.php?f=65&t=66446&start=120#p653562
gibt es ein Problem bei der Eingabe des Wert für die Ventilstörungsposition beim HM-CC-RT-DN

Der Defaultwert ist 15%. Wenn man versucht ihn z.B. auf 12% zu ändern steht nach der Fehlermeldung da 12.0% Was nicht axeptiert wird.

Aufruf der Funktion erfolgt mit:
<input id="separate_DEVICE_32" type="text" size="5" value="15" name="VALVE_ERROR_RUN_POSITION" onblur="ProofAndSetValue(this.id, this.id, '0.0', '100.0', 1)" style="background-color: rgb(255, 255, 254);" valvalid="true">

Die Funktion macht also was von ihr erwartet wird. Wieso da Nachkommastellen übergeben werden, wenn gar keine zulässig sind, kann ich nicht beurteilen.
Festgestellt wurde es unter RaspberryMatic 3.57.4.20210320

[Baxxy13]

Ich hab's verfolgt und ein bisschen recherchiert.
Die von mir gefundenen Informationen deuten darauf das das HM-CC-RT-DN für die "VALVE_ERROR_RUN_POSITION" einen Integerwert erwartet. Der Aufruf erfolgt vermutlich in der /www/config/easymodes/cc_rt_dev_master.tcl
Man bräuchte mal einen Screenshot der Limits in der WebUI und jemanden der guckt was das Thermostat an dieser Stelle verdaut. (Master Paramset)
@jp112sdl oder @HMMike vielleicht?

Edit: Ich habe nur ein HmIP-eTRV-B1 zum testen hier, das arbeitet intern aber mit anderen Zahlen.
<name>VALVE_ERROR_RUN_POSITION</name><value><double>0.150000</double></value>

[MichaelN0815]

Der Programmierer wollte aber wohl wirklich float haben:
# Limit float to 2 decimal places

Aber es wird noch schlimmer:
https://homematic-forum.de/forum/viewtopic.php?f=65&t=66446&p=653795#p653783
<input type="text" name="__PULL_FORCE" value="100.0" id="separate_CHANNEL_1_4_temp" onblur=" ProofAndSetValue('separate_CHANNEL_1_4_temp', 'separate_CHANNEL_1_4', parseFloat(0.0), parseFloat(100.0), parseFloat(0));" valvalid="true" style="background-color: rgb(255, 255, 254);">

Der Faktor wird mit 0 übergeben!

Bei so viel Kreativität beim Aufruf dieser Funktion ist eine nachhaltige Abstellmaßnahme nur möglich, wenn EQ-3 gewillt ist zukünftig einen Standard einzuhalten. Wenn dieser Wildwuchs nicht beseitigt wird und zukünftig so weitergeht, dann wird das eine Dauerbaustelle.

[jp112sdl]

dann wird das eine Dauerbaustelle.

Fass ohne Boden... erwähnte ich schon mal im Issue ^^

Da könnt ihr (oder @theimo1221) noch hundert mal einen "So jetzt müsste aber alles abgedeckt"-Haken dran machen.
Irgendwo schlummert doch noch eine Falle.

Welche Probleme gab es denn mit der ProofAndSetValue bis CCU FW 3.53.x ? - Aus meiner Sicht absolut keine.

Ich kopiere mir die gute alte Methode auch immer wieder zurück in die webui.js ins laufende System.
Damit hab ich meine Ruhe und alles geht wie gehabt.

[Baxxy13]

Damit hab ich meine Ruhe und alles geht wie gehabt.

Bei IP-Freunden klemmt es damit zumindest wieder bei...
Energiespar-Temperatur (Heiz-Modus)
und
Fenster-Auf-Temperatur
bei Thermostaten und IP-Heizgruppen.

[jens-maus]

Ich denke auch , das wir hier zumindest in gewissem Maße nicht um sukzessive Anpassungen der ProofAndSetValue() Funktion bzw deren Nutzung herumkommen. Ein einfaches zurückgehen auf einen früheren Stand kann auch nicht der Weissheit letzter Schluss sein.

Wenn es also noch etwas gibt nicht geht, so sollten wir das am besten wieder in konkreten Issue Ticket einsammeln, denn hier im Diskussionsforum geht das nur unter oder wird vergessen. Bitte also einfach mal jedes einzelne Problem mit genauer beschreibung (am besten screencast) als Ticket melden und dann kann man das nach und nach angehen und auch die von @theimo1221 erarbeiteten Testcases darauf anpassen/erweitern.

[MichaelN0815]

Deine weitere Strategie wäre also den aktuellen Stand erstmal laufen zu lassen und alle Bugreports einzusammeln in der Hoffnung irgendwann alles gelöst zu haben? Wenn ich mir die Nutzung dieser Funktion anschauen, erscheint es mir so, als hätte EQ-3 selber keine Schnittstellen-Dokumentation. Wie soll man dann sinnvoll ein System weiter entwickeln? Wird bei OpenSource immer so gearbeitet?

[jens-maus]

Deine weitere Strategie wäre also den aktuellen Stand erstmal laufen zu lassen und alle Bugreports einzusammeln in der Hoffnung irgendwann alles gelöst zu haben? Wenn ich mir die Nutzung dieser Funktion anschauen, erscheint es mir so, als hätte EQ-3 selber keine Schnittstellen-Dokumentation. Wie soll man dann sinnvoll ein System weiter entwickeln?

Na welche "Strategie" hättest du denn bitte? Kannst ja gerne Vorschläge hier machen.
Aber solange wir von eQ3 abhängig sind und eQ3 selbst hier Updates noch rausbringt müssen wir eben auch schauen das wir uns nicht zu weit vom Original entfernen weil sonst sind wir (als OpenSource Projekt) abgeschnitten. Insofern muss man eben nicht nur downstream schauen wie es weitergehen soll, sondern auch den Blick auf upstream Entwicklungen nicht verlieren.

Wenn du aber konkrete Dinge Vorschlage kannst wie du es bitte anders machen würdest, dann auch gerne in Form von direkten Contributions mittels PullRequests, usw.

Wird bei OpenSource immer so gearbeitet?

Ist das eine ernsthafte Frage oder mit Absicht provokant gestellt? Wie gesagt kannst du gerne direkte Vorschläge machen wie man die Situation rund um ProofAndSetValue() verbessern kann und nicht nur Fehler benennen und den Zeigerfinger heben.

[MichaelN0815]

Ich bin QS-ler. Daher bin ich es gewohnt den Finger in die Wunde zu legen und die Root-Cause zu identifizieren und das Problem dort abzustellen. Wenn Du erst am Ende der Prozesskette korrigierend eingreifst, wirst Du nicht glücklich.

[theimo1221]

Ich bin QS-ler. Daher bin ich es gewohnt den Finger in die Wunde zu legen und die Root-Cause zu identifizieren und das Problem dort abzustellen. Wenn Du erst am Ende der Prozesskette korrigierend eingreifst, wirst Du nicht glücklich.

Naja mit den Anpassungen an ProofAndSetValue haben wir erstmal den Root-Cause verbessert.
Die internen Strukturen und Vorgehensweisen von eQ-3 in Bezug auf ein korrektes Ansprechen/Verwenden der Funktion liegt nicht in meiner/unserer Hand....

[MichaelN0815]

Einen letzten Versuch das ganze zu verstehen starte ich noch.
@theimo1221 in deinem Patch

if (ok)
{
srcElm.style.backgroundColor = "#fffffe";
dstElm.value = (parsedValue * dstValueFactor).toFixed(digits);
srcElm.value = dstElm.value;
srcElm.setAttribute("valvalid", "true");
}
else
{
srcElm.setAttribute("valvalid", "false");
srcElm.style.backgroundColor = "red";
dstElm.value = (finalVal * dstValueFactor).toFixed(digits);
srcElm.value = dstElm.value;
window.setTimeout(function(){srcElm.style.backgroundColor = "white";},1000);
}

Welchem Zweck dient dieser Code:
srcElm.value = dstElm.value;

[MichaelN0815]

Welchen Sinn hat dstValueFactor?
Hier wird aus 0 => 0,01
if (! dstValueFactor) dstValueFactor = 0.01;//dstValue = value/100

Im Original und im modifizierten Code wird immer die Eingabe gegen die Limits geprüft, ohne den Faktor zu berücksichtigen.
Am Ende wird in $(dstid).value der faktorisierte Wert geschrieben. Im Original war's das, im RM-Code folgt dann aber noch srcElm.value = dstElm.value;

Solange ich nicht verstehe was da passiert, kann ich keine Verbesserungsvorschläge erarbeiten.
Hat da jemand Input für mich?

[jens-maus]

Glaub mir, ich würde selbst die gesamte WebUI gerne in die Tonne klopfen und komplett neu entwickeln.

Am besten wäre es, eQ-3 gibt die CCU3 und das WebUI Konzept gänzlich auf und entwickelt in Richtung "offline AP".
Also nur noch HmIP(W) Support mit neuer UI und neuem Backend (rein HMIPServer basierend).

Ich bin mir nicht so sicher ob man solch einer reinen Java-Komponente alle Macht übertragen sollte :). Auf jeden fall wäre mit solch einer Änderung dein AskSin Projekt am Ende, denn eigen entwickelte HmIP-Geräte zu entwickeln wird wohl nie möglich sein. Ich denke wir sollten für jeden Tag den die CCU Umgebung noch lebt dankbar sein, denn mit solch einer "offline AP" wird definitiv die Flexibilität drunter leiden. So etwas wie Experteneinstellungen/parameter gibt es ja immer noch nicht in der HmIP-Cloud und wird es wohl auch nie geben (weil zu komplex). Und auch mit einem "offline AP" werden die Funktionalitäten stark eingeschränkt sein gegenüber der jetzigen CCU/WebUI Umgebung. Und wer braucht schon eine schicke/moderne UI für reine Konfigurationszwecke, mir persönlich würden kommandozeilen-befehle vollkommen reichen um die Geräteparameter einzustellen :).

Und gegen ordentliche Middlewares wie HomeAssistant oder ioBroker wird eQ3 niemals wirklich ankommen weil einfach da mehr Entwickler dahinterstecken. Ich würde es also eher begrüßen wenn es irgendwann eine CCU4 z.B. gibt die als Oberfläche HomeAssistant nutzt und im Backend dann eben auf das bewährte CCU Schnittstellenprozess-konzept, usw. setzt. In der Tat hatte ich da bei der HomeAssistant Add-on Umsetzung auch mal drüber nachgedacht ob man nicht einfach jetzt das HomeAssistant-OS forken sollte und dann zusammen mit der HomeMatic Integration in HomeAssistant so weiterentwickelt das das im Grunde die neue WebUI für die CCU/RaspberryMatic wird. Aber ich als einzelne Person kann eben doch nicht die ganze Welt retten schätze ich.. Wenn sich da aber Mitstreiter finden würden die genauso gerne Zeit opfern wie ich, dann denke ich da nochmal drüber nach :)

[jp112sdl]

Auf jeden fall wäre mit solch einer Änderung dein AskSin Projekt am Ende,

Ich sehe gerade den Vorteil darin, dass diejenigen, die sich dem klassischen BidCos verschworen haben, einen Stand X der CCU Firmware haben, der dann nicht mehr angefasst wird ;)

[MichaelN0815]

Du wirst es zwar nicht glauben, aber wir wissen genauso viel wie du und fischen teilweise selbst im trüben.

Das habe ich befürchtet.
Trotzdem möchte ich auf die Frage zurückkommen. Es gibt doch vielleicht berechtigte Annahmen was dstValueFactor für einen Sinn hat und ich möchte auch zur Diskussion stellen, ob srcElm.value = dstElm.value; sinnvoll ist, wenn der FAktor <>1 ist.

[jp112sdl]

Aber es wird noch schlimmer:

Vielleicht hängt es auch noch mit den Prozentangaben zusammen...
WinMatic hat als Einheit für die Prozentwerte überall unit="100%"
https://github.com/AskSinPP/asksinpp-web/blob/8462b6badd9778a9db194b04f276f2fa8e536f82/rftypes/xmls/rf_winmatic.xml#L91
und das Thermostat hat unit="%".
https://github.com/AskSinPP/asksinpp-web/blob/master/rftypes/xmls/rf_cc_rt_dn.xml#L167

Da gibt es irgendwo in der WebUIauch noch mal eine "Spezialbehandlung" bei der Werteverwertung ^^
Und im Forum gibt es auch irgendwo einen Thread zu dem "Prozent Bug". Ist schon länger her... hatte da auch mal was geschrieben. Finde es aber nicht wieder.

[MichaelN0815]

Ja, ich habe die Stelle wo die % "behandelt" werden auch mal in der WebUI.js gefunden. Ichgglaube hier istaaber ein Problem der Übergabe. Man merkt einfach an allen Ecken und Kanten, das da "Bugfixes" eingebaut wurden, weil vorhandene Funktionen nicht verstanden wurden. Und ich will eigentlich nicht, dass wir in diesem Geiste weiter machen

[jp112sdl]

eQ-3 hat eine Verbesserung eingepflegt und publiziert:
eq-3/occu@8cb5117#diff-d59de87697ca7568f762ceb765537082caed2eedcc72ea67a7713daea4f5b5e6

[MichaelN0815]

Die haben also auch erkannt, das es ggf. sinnvoll ist 0 eingeben zu können....

[jens-maus]

Hallo Zusammen,

kann ich hier nochmal dazu aufrufen nun vielleicht mal bitte eine Liste oder ähnliches zu generieren an welchen konkreten Stellen es jetzt aktuelle noch Probleme mit der ProofAndSetValue() Funktion gibt damit wir diese sukzessive daraufhin abarbeiten können? Und bitte keine weiteren Grundsatzdiskussionen über das Für und Wider einer solchen Aktion, usw.. Einfach nüchtern die Stellen bitte benennen/aufzeigen an denen Eingaben in die Geräteeinstellungselemente in der WebUI nicht korrekt bzw. wie erwartet funktionieren. Und dieses bitte am besten mittels einfacher gif-screencasts in separaten Bugtickets untermauern damit man sich dann entsprechend auf die Suche nach einem Fix für jeden einzelnen dieser Fälle machen kann oder es einfach halt dann nur in form eines Issues dokumentiert hat das es in diesem Fall noch Probleme mit der ProofAndSetValue() Funktion gibt. Und wie gesagt, bitte langwierige diskussionen diesbzgl. vermeiden und einfach neutral die einzelnen Situation aufzeigen und darlegen.

[theimo1221]

Die weiteren hier bisher aufgeführten Punkte sind Resultate "falscher" Aufruft an ProofAndSetValue; keine Fehler in selbiger.

[jens-maus]

Dann sollten diese falschen Aufrufe aber auch so IMHO in separaten Bugtickets/issue landen damit wir diese separat abarbeiten können. Und insgesamt laufen die für mich inhaltlich komplett unter ProofAndSetValue Problemen die wir für den nächsten Release dann reparieren sollten. Und genau dafür wäre es gut diese in separaten Bugtickets zu haben oder zumindest im ursprünglich ProofAndSetValue Bugticket nun abzuarbeiten...

[Baxxy13]

Nachdem ich mich heute mal wieder ausgiebig mit dem Thema befasst habe, denke ich das, die sogenannten "falschen Aufrufe" zu identifizieren und sie kompatibel zur ProofAndSetValue der aktuellen RaspberryMatic zu machen der falsche Weg ist.

Im Ticket #1221 hatte ich ja geschrieben das allein für das dortige Problem die Aufrufe der ProofAndSetValue in 3 Dateien korrigiert werden müssten. Grob gezählt finde ich da zusammen 12 Aufrufe. Und wer weiß wo noch überall "falsche Aufrufe" versteckt sind.

Aktuell würde ich dazu tendieren die ProofAndSetValue aus CCU 3.57.5 zu nutzen.
Ob man auch die /www/config/ic_common.tcl der CCU nutzt oder diese in der RM anpasst müsste man noch klären.
So wie sie jetzt in der RM ist funktioniert das Zusammenspiel weder mit der CCU ProofAndSetValue noch mit der RM ProofAndSetValue.
Siehe erster Beitrag.

[jens-maus]

Na wenn ihr das nicht in GitHub hinbekommt könnt ihr mir gerne auch die Dateien die ihr abgeändert habt einfach zuschicken und ich bau daraus nen PullRequest usw. aber bitte so wenig wie möglich änderungen machen und keine line endings verändern usw. d.h. Also einen brauchbaren editor verwenden.

[Baxxy13]

OK. Als ersten Schritt habe ich dir die geänderte /www/config/ic_common.tcl über's Homematic Forum zukommen lassen. Das sollte schonmal einen Großteil der Aufrufe korrigieren.
Info für @jp112sdl : Die Änderung ist Variante A aus dem ersten Post hier, da meintest du ja im Forum das das soweit funktioniert.

[MichaelN0815]

Variante A ist auch occu kompatibel. Habe ich bei mir eingebaut und konnte keine Probleme feststellen,im Gegenteil.

[jp112sdl]

Ich hab den Überblick verloren. 🙈
Baut mal was, das kann ich mir dann in einem folgenden nightly build dann anschauen.

[jens-maus]

So, hab die Anpassung von @Baxxy13 mal aufgenommen (https://github.com/jens-maus/RaspberryMatic/blob/master/buildroot-external/patches/occu/0119-WebUI-Fix-ProofAndSetValue.patch#L1-L11). Sollte mit dem morgigen nightly build dann mitkommen. Kann also gerne getestet werden.

[Baxxy13]

@jens-maus :
Um das leidige Thema voranzubringen brauch ich Hilfe.
Ich habe einen Fork von RaspberryMatic angelegt und darin einen "Test-Branch" erstellt.
Jetzt möchte ich @theimo1221 's Patch buildroot-external/patches/occu/0119-WebUI-Fix-ProofAndSetValue.patch für die ProofAndSetValue - Funktion ändern, um unsere gestrigen Erkenntnisse einzupflegen.

Mir ist nun aber absolut unklar wie da vorzugehen ist.
Muss ich das Patchfile von Thiemo ändern, oder die webui.js aus dem occu nehmen und einen neuen patch machen?
Eigentlich möchte ich ja nur 4 Zeilen von Thiemo's Patch in der webui.js ändern.

Ich raff das nicht...

[jp112sdl]

Wie ich Windows hasse... 😛

Hätte ab ca. 20:30 Uhr kurz Zeit für Teamviewer.
Wenn es dir passt, rufe ich dich an. Deine TelNr. hab ich noch.

[Baxxy13]

Danke für das Angebot, was ich liebend gerne annehmen würde.
Klappt aber heute wegen Familien-Filmabend nicht.

Ich habe mir jetzt mal ein vollwertiges Linux auf einem Reste-PC installiert und doktore ein bisschen dran rum.
Mal schauen ob es damit klappt. :D

[MichaelN0815]

Und das um 4 Zeilen zu patchen. Da soll noch einer sagen, Du hängst Dich nicht richtig rein.

[jp112sdl]

Wenn man den Workflow einmal inne hat, dann ist das gar nicht mehr so kompliziert.
Aber Aufwand ist es schon... ich wüsste jedoch nicht, wie man es anders machen könnte.

Ich hatte jedoch auch bereits einen Fall, wo ich Jens geschrieben habe, dass ich für einen Einzeiler in einer einzelnen Datei keinen PR mache und er das selbst schnell ändern soll.
Das hat auch gut geklappt.

[Weseler485]

Ich würde hier gern auch nochmal nachhaken, da ich es auch bis heute nicht verstanden habe!

Du änderst nie direkt im Patchfile, sondern in der zu patchenden Datei, also in der webui.js (in deinem Fork natürlich).

https://github.com/Baxxy13/RaspberryMatic/blob/master/buildroot-external/patches/occu/0119-WebUI-Fix-ProofAndSetValue/occu/WebUI/www/webui/webui.js

Muss ich also zweimal ändern? Also einmal in der echten Datei damit ich testen kann was ich tue und wenn alles dann
läuft übernehme ich es nochmal in die Kopie?

Wird die *.orig regelmässig durch die neue Auslieferung von EQ3 ersetzt?

Für mich erschließt sich einfach nicht wie die geänderte Datei sowie die *.orig in den jeweiligen Patch-Ordnern zustande kommt und erst recht nicht, wie es sich verhält, wenn ein und die selbe Datei in mehreren Patches geändert wird.

[Baxxy13]

Naja, was tut man nicht alles. Ich hatte ja gehofft das Thiemo den Part übernimmt.
Egal, selbst ist der Baxxy!
Guckst du mal drauf Jerome? Link

[Baxxy13]

Nochmals Danke Jérôme für die Stupser in die richtige Richtung!
Der PR an sich war dann gar nicht mehr so schwer. Das ganze in englisch zu beschreiben hat aber tatsächlich Zeit gekostet.

Mal schauen ob alles korrekt war.

[MichaelN0815]

Muss da nicht noch die Änderung an der www\config\ic_common.tcl mit rein?

[jp112sdl]

Ist das nicht das, was Jens schon gemacht hat?
d841913

[MichaelN0815]

Ok

[Baxxy13]

Die hatte ja Jens schon nach meiner Vorlage gestern angepasst. Ist also seit dem Nightly 3.57.5.20210418 drin und musste nicht nochmal angefasst werden.
Jetzt warte ich drauf das Jens das übernimmt und dann werde ich eventuell noch die Aufrufe der ProofAndSetValue in...

/www/config/easymodes/BLIND/BLIND.tcl
/www/config/easymodes/BLIND/VIRTUAL_KEY.tcl
/www/config/easymodes/BLIND/KEY.tcl

leicht optimieren.

Die sind momentan irgendwie 3fach drin...
append HTML_PARAMS(separate_$prn) "<input type=\"text\" id=\"separate_${special_input_id}_$prn\_3_temp\" name=\"SHORT_ON_LEVEL\" value=\"[format %.1f [expr $ps(SHORT_ON_LEVEL) * 100]]\" onblur=\"ProofAndSetValue('separate_${special_input_id}_$prn\_3_temp', 'separate_${special_input_id}_$prn\_3', parseInt(0), parseInt(100), parseFloat(0.01));\" onmouseup=\"ProofAndSetValue('separate_${special_input_id}_$prn\_3_temp', 'separate_${special_input_id}_$prn\_3', parseInt(0), parseInt(100), parseFloat(0.01));\" onblur=\"ProofAndSetValue('separate_${special_input_id}_$prn\_3_temp', 'separate_${special_input_id}_$prn\_3', parseInt(0), parseInt(100), parseFloat(0.01));\" />\%"

und gerade das "onmouseup" macht in diesem Fall Probleme da man...

Stand aktuell...

3x in das Eingabefeld klicken muss um was einzugeben

Stand optimierte ProofAndSetValue...

2x in das Eingabefeld klicken muss um was einzugeben

Stand mit optimierter ProofAndSetValue und optimiertem Aufruf

nur 1x in das Eingabefeld klicken muss um was einzugeben