CUxD 2.13 Triggerwerte für CMD_RETS/RETL nicht mehr einstellbar

[HMSchrottix]

Hallo Uwe,

ich habe ein seltsames Problem bei der Konfiguration der Triggerwerte für CMD_RETS/RETL. Beim Neuanlage eines Programms kann ich die Felder CMD_RETS oder CMD_RETL auswählen, aber der folgende Dialog zum Einstellen der Triggerwerte ist OHNE Funktion. Man kann wählen was man will, der OK-Button läßt sich NIE bedienen. Man kommt nur mit 'Abbrechen' wieder aus dem Dialog raus. Dann bleibt aber die falsche Vorbelegung so erhalten, was natürlich laut CUxD-Handbuch dazu führt, dass der Programmtrigger nicht ausgelöst wird.

Als Workaround nutze ich den Trigger PRESS_SHORT/LONG zusätzlich, um die Auswertung der Daten aus CMD_RETS/RETL zu starten. Das funktioniert auch. Die Daten sind mit folgenden Statement wie zu erwarteten nutzbar.

Code: Alles auswählen

string data = dom.GetObject("CUxD.CUX2801001:X.CMD_RETS").State();

Es gab noch ein paar ältere, unveränderte Programme aus der Zeit mit den Versionen 2.11 und 2.12, die triggern einwandfrei.
Nur die Neuerstellung geht nicht.
Ich habe schon wegen Verdacht auf GUI-Problem verschiedene Browser ausprobiert und auch CUxD 2.13 deinstalliert und 2.12 installiert. Leider kein Erfolg.
Ich habe vor ca. 14 Tage von R3 auf R4 umgestellt. Erst R3 von 3.79.6.20250220 auf die Version 3.85.7.20260131 mit CUxD 2.13 gewechselt.Dann die Hardware auf R4 mit externer Antenne und OpenCCU-3.85.7.20260131-rpi4 umgebaut und das Backup eingespielt.
Bisher keine gravierenden Probleme festgestellt, nur das Phänomen mit CUxD.
Vielleicht kannst Du mir mal einen Tipp geben, wo und was ich versuchen soll.
Gibt es eine Konfig-Datei, wo ich den benötigten RETx-Triggerwert gemäß Doku '<= 0' direkt ohne GUI-Dialog patchen kann?
Danke und viele Grüße von Schrottix

[Baxxy]

Als Addendum paar Fehler aus der Browserkonsole:
1: Wenn man das PopUp durch Klick auf den vordefinierten Wert öffnet:

Code: Alles auswählen

prototype.js:399 Uncaught SyntaxError: Unexpected token ';'
    at prototype.js:399:69
    at prototype.js:640:20
    at prototype.js:600:9
    at Array.forEach (<anonymous>)
    at Array.each (prototype.js:599:12)
    at Array.collect (prototype.js:639:10)
    at String.evalScripts (prototype.js:399:34)
    at Function.<anonymous> (prototype.js:214:23)
    at prototype.js:236:23
(anonym) @ prototype.js:399
(anonym) @ prototype.js:640
(anonym) @ prototype.js:600
each @ prototype.js:599
collect @ prototype.js:639
evalScripts @ prototype.js:399
(anonym) @ prototype.js:214
(anonym) @ prototype.js:236
setTimeout
delay @ prototype.js:235
(anonym) @ prototype.js:229
update @ prototype.js:1612
_methodized @ prototype.js:251
updateContent @ prototype.js:1471
(anonym) @ prototype.js:1450
(anonym) @ prototype.js:214
respondToReadyState @ prototype.js:1322
onStateChange @ prototype.js:1249
(anonym) @ prototype.js:214
XMLHttpRequest.send
request @ prototype.js:1234
initialize @ prototype.js:1190
(anonym) @ prototype.js:243
(anonym) @ prototype.js:92
(anonym) @ prototype.js:214
initialize @ prototype.js:1454
(anonym) @ prototype.js:243
klass @ prototype.js:53
LoadFromFile @ webui.js?_version_=2.0pre1:30943
load @ webui.js?_version_=2.0pre1:30799
initialize @ webui.js?_version_=2.0pre1:30607
klass @ prototype.js:53
CreatePopup @ webui.js?_version_=2.0pre1:32185
onclick @ index.htm?sid=@BycZr81Zmn@:1

2. Wenn man eine der Vergleichsoperationen anklickt:

Code: Alles auswählen

index.htm?sid=@BycZr81Zmn@:1 Uncaught ReferenceError: SetCT is not defined
    at HTMLInputElement.onclick (index.htm?sid=@BycZr81Zmn@:1:1)
onclick @ index.htm?sid=@BycZr81Zmn@:1

3. wenn man OK anklickt:

Code: Alles auswählen

index.htm?sid=@BycZr81Zmn@:1 Uncaught ReferenceError: SaveValueRange is not defined
    at HTMLDivElement.onclick (index.htm?sid=@BycZr81Zmn@:1:1)
onclick @ index.htm?sid=@BycZr81Zmn@:1

Getestet mit CCU3 "original" und OpenCCU 3.85.7

Düfte durch irgendeine Änderung an der WebUI durch eQ-3 reingekommen sein... nur wann und wo...

[jp112sdl]

nur wann und wo...

Datei:
https://github.com/eq-3/occu/blob/maste ... eRange.htm

Änderung:
https://github.com/eq-3/occu/commit/ff6 ... 4e087817d8

[Baxxy]

Das Problem besteht also seit CCU3/RaspberryMatic >= 3.83.x. (etwa Juli 2025), erstaunlich das das bisher noch niemand bemerkt hat.
Ich selbst nutze das in einigen bestehenden Programmen.

einen Tipp geben, wo und was ich versuchen soll

Die Frage wäre halt ob Uwe (CUxD) nachbessern sollte oder wir das ggf. in OpenCCU versuchen geradezubiegen.
eQ-3 selbst wird da wegen dem "Schweizer Taschenmesser CUxD" sicher keinen Finger krumm machen.

Die CMD_RETx sind auch etwas "abnormal" da sie wohl den system() Exit-Status (integer) sowie die eigentliche Rückgabe (string) enthalten können.
Das ist mit einer numerischen Auswertung im WebUI-Programm nun nicht mehr so richtig vereinbar.

Was man machen könnte/sollte weiß ich auch nicht genau, vielleicht die CMD_RETx - Datenpunkte so modifizieren das die WebUI denkt es sei ein float oder integer. Oder aufsplitten, also 2 DP's, einer für den Ret-Code (int/float) für's WebUI-Programm und ein anderer für den Rückgabe-Wert (string).

Wie auch immer, mit dem Programmeditor des SDV kann man noch immer die Bedingung auf <=0 "bei Aktualisierung" definieren.
Ob das auch wirklich triggert habe ich erstmal nicht getestet.

[HMSchrottix]

Hallo Jerome und Baxxy,
erst mal vielen Dank für eure tiefgreifende Analyse.
Aus meiner Sicht war die Lösung vor dem aktuellen Bug nicht gerade einfach nachzuvollziehen.
Siehe Betrag [Gelöst] CUxD 2.9 und CMD_RETS/CMD_RETL viewtopic.php?f=37&t=74315

Denn was will ich eigentlich mit dem Aufruf über CUxD statt über die Script-Funktion 'system.Exec' erreichen?
Ich möchte in der Regel verhindern, dass ein eventuell länger laufender HTTP-Request oder ähnliches die CCU für ein paar Sekunden blockiert.
Also soll der Befehl an den CUxD gehen und die CCU macht ihren Job schön weiter.
Wenn der CUxD irgendwann fertig ist, würde ich das Ergebnis gerne asynchron zurück bekommen. Das könnten z.B. auch zwei Systemvariable vom Typ string analog zu stdout und stderr sein. Wenn der CUxD das Ergebnis und ggf. Fehler da reinschreibt, könnte man auf die Änderung bzw. Aktualisierung triggern und alles wäre (fast) perfekt. Ein kleines Problemchen könnte nur entstehen, wenn der CUxD mehrere Aufrufe parallel abarbeitet und dabei natürlich nicht eine gewisse Reihenfolge einhalten kann. Da müssten die Rückgabevariablen schon eher wie RETS und RETL am Geräte verankert sein. Hauptsache der asynchrone Trigger kommt wieder in die CCU, um das Ergebnis weiter zu verarbeiten.
Aber diese Fragen kann nur Uwe abschätzen und bewerten.
Danke und Gruß
HMSchrottix

[uwe111]

Was man machen könnte/sollte weiß ich auch nicht genau, vielleicht die CMD_RETx - Datenpunkte so modifizieren das die WebUI denkt es sei ein float oder integer. Oder aufsplitten, also 2 DP's, einer für den Ret-Code (int/float) für's WebUI-Programm und ein anderer für den Rückgabe-Wert (string).

Bei Bedarf könnte ich einen weiteren Datenpunkt mit dem Ret-Code als INT anlegen. Ich denke das wäre die beste Lösung.

Wenn der CUxD irgendwann fertig ist, würde ich das Ergebnis gerne asynchron zurück bekommen.

Genau so funktioniert das aus CUxD Sicht auch! Das die CCU-Logikschicht auf die asynchrone Antwort vom CUxD wartet, ist hier das Problem.
Das beste, was Du bei undefinierten Laufzeiten machen kannst, ist entweder auf CMD_RET zu triggern, oder aus Deinem aufgerufenen Script heraus am Ende irgendwelche Datenpunkte oder Systemvariablen zu setzen.

Viele Grüße

Uwe