CUxD sendet keine Befehle mehr

[litronics]

Hallo Zusammen,
mein Setup lief jetzt 10 Jahre einwandfrei - aber es häuften sich Aussetzer, dass keine Befehle mehr empfangen wurden und jetzt kann ich gar keine CUxD Devices mehr steuern.

Die Logs sehen soweit ich das beurteilen kann gut aus:

Code: Alles auswählen

Nov 22 16:15:14 homematic-raspi daemon.info cuxd[1317]: CUx-Daemon(2.11) on CCU(3.83.6.20250824) start PID:1317
Nov 22 16:15:14 homematic-raspi daemon.info cuxd[1317]: write_pid /var/run/cuxd.pid [1317]
Nov 22 16:15:14 homematic-raspi daemon.info cuxd[1317]: load paramsets(/usr/local/addons/cuxd/cuxd.ps) size:2223 update(-81s):Sat Nov 22 16:13:53 2025
Nov 22 16:15:14 homematic-raspi daemon.info cuxd[1317]: 12 device-paramset(s) loaded ok!
Nov 22 16:15:14 homematic-raspi daemon.info cuxd[1317]: write_proxy /var/cache/cuxd_proxy.ini (1317 /usr/local/addons/cuxd/ 2.11 3.83.6.20250824 0)
Nov 22 16:15:14 homematic-raspi daemon.info cuxd[1317]: add interface 'CUxD'
Nov 22 16:15:14 homematic-raspi daemon.info cuxd[1317]: write interface(1) 'BidCos-RF' to /usr/local/etc/config/InterfacesList.xml
Nov 22 16:15:14 homematic-raspi user.info cuxd: started cux-daemon
Nov 22 16:15:14 homematic-raspi daemon.info cuxd[1317]: write interface(2) 'VirtualDevices' to /usr/local/etc/config/InterfacesList.xml
Nov 22 16:15:14 homematic-raspi daemon.info cuxd[1317]: write interface(3) 'HmIP-RF' to /usr/local/etc/config/InterfacesList.xml
Nov 22 16:15:14 homematic-raspi daemon.info cuxd[1317]: write interface(4) 'CUxD' to /usr/local/etc/config/InterfacesList.xml
Nov 22 16:15:14 homematic-raspi daemon.info cuxd[1317]: USB(1-1.3/ttyUSB1) connect device disabled!
Nov 22 16:15:14 homematic-raspi daemon.info cuxd[1317]: USB(1-1.4/ttyUSB0) CP2102N USB to UART Bridge Controller connect(38400:8N1)
Nov 22 16:15:38 homematic-raspi daemon.warn cuxd[1317]: process_rpc_request(127.0.0.1) - illegal XMLRPC(listDevices) request
Nov 22 16:15:41 homematic-raspi daemon.warn cuxd[1317]: process_rpc_request(127.0.0.1) - illegal XMLRPC(init) request
Nov 22 16:15:58 homematic-raspi daemon.info cuxd[1317]: INIT 'xmlrpc_bin://127.0.0.1:31999' '1552'
Nov 22 16:15:58 homematic-raspi daemon.info cuxd[1317]: RPC-server from HM-CCU (1552) registered!
Nov 22 16:15:59 homematic-raspi daemon.info cuxd[1317]: connection to 127.0.0.1:8183 successfull!
Nov 22 16:16:12 homematic-raspi daemon.info cuxd[1317]: INIT 'binrpc://node-red.fire.fly:2076' 'nr_ac5e5b_CUxD'

Was ich bisher herausgefunden habe ist, dass anscheinend keine Befehle mehr gesendet werden - aber der Empfang funktioniert noch. Tatsächlich kann ich in Raspberrymatik alle Rolläden rauf und runter fahren und im Terminal-Log sehe ich folgendes:

Code: Alles auswählen

16:15:14 [ttyUSB0] *** connect(38400:8N1) CP2102N USB to UART Bridge Controller
16:15:17 [ttyUSB0] <-- V
16:30:52 [ttyUSB0] <-- F00550F00
16:30:55 [ttyUSB0] <-- F00550F11

Das würde für mich darauf deuten, dass ich zwar vom Gerät etwas empfange - aber nichts gesendet wird. Da müsste der Pfeil doch anders herum sein - oder?

Bevor jemand fragt, was ich verändert habe. Aktiv an der Einstellung habe ich nichts geändert - ich habe lediglich alles runter gefahren und die SD-Karte rausgenommen um ein Backup zu machen. Danach wieder rein und da stehe ich nun...

Jemand von euch eine Idee, woran das liegen könnte?

[uwe111]

Hallo,

Das würde für mich darauf deuten, dass ich zwar vom Gerät etwas empfange - aber nichts gesendet wird. Da müsste der Pfeil doch anders herum sein - oder?

Nein, Befehle werden zum CUL gesendet, aber nichts empfangen.

Jemand von euch eine Idee, woran das liegen könnte?

CUL defekt?

Viele Grüße

Uwe

[litronics]

So - ich habe mich mit dem Problem noch tiefer auseinander gesetzt.

Dass der CulStick evtl. defekt wäre habe ich mir auch schon gedacht - aber wenn ich ihn an einen anderen Rechner stecke, dann empfängt er ganz sauber die Daten von meiner Fernbedienung. Ergo funktioniert die Hardware mal einwandfrei.

Dann habe ich mich auf den Raspi verbunden und gecheckted was dort ankommt und siehe da, er wird angezeigt - aber ich bekomme nur rubbish angezeigt. OK - ich habe auch die Schnittstelle nicht konfiguriert sondern einfach mit CAT ausgegeben.

In CUxD sieht es aktuell so aus, dass er mit der Schnittstelle erfolgreich connected aber eben keine Daten übertragen werden, egal in welcher Richtung.

Dann habe ich mir gedacht OK, schmeiß den Container weg und hol dir einen neuen. Also container weg, neues Image gepulled und neuen Container hin. Hat leider nicht geholfen

Was mir dann noch aufgefallen ist, dass ich zu ReGaHss noch ein paar Fehlermeldungen sehe:

Code: Alles auswählen

Nov 26 08:18:54 homematic-raspi local0.err ReGaHss: ERROR: ScriptRuntimeError: object chn = dom.GetObject('2085'); object oOverflow = chn.DPByControl('POWERMETER_PSM.ENERGY_COUNTER_OVERFLOW'); object oEnergyCounter = chn.DPByControl('POWERMETER_PSM.ENERGY_COUNTER'); object oSysVarEnergyCounter = dom.GetObject('svEnergyCounter_2085_00089BE9A6ECD6:5'); object oSysVarEnergyCounterOldVal = dom.GetObject('svEnergyCounterOldVal_2085'); boolean overFlowFlag = oOverflow.Value(); real devVal = oEnergyCounter.Value
); real devValMax = oEnergyCounter.ValueMax(); real oldDevVal = oSysVarEnergyCounterOldVal.Value(); real diffVal = 0.0; real sysVarVal = oSysVarEnergyCounter.Value(); integer tmp_devVal = (devVal.ToString().ToFloat() * 1000).ToInteger(); integer tmp_oldDevVal = (oldDevVal.ToString().ToFloat() * 1000).ToInteger(); if (overFlowFlag == false) { ! Normal conditions if (tmp_oldDevVal <= tmp_devVal) { diffVal = devVal - oldDevVal; } ! Device has rebooted if (tmp_oldDevVal > tmp_devVal) { diffVal = devVal; } } e
se { !overFlow is true
Nov 26 08:18:54 homematic-raspi local0.err ReGaHss: ERROR: XMLRPC 'getValue' call failed (interface: 1009, params: {"00089D89BA17B0:5","ENERGY_COUNTER"}) [CallGetValue():iseXmlRpc.cpp:1448]
Nov 26 08:18:54 homematic-raspi local0.err ReGaHss: ERROR: CallGetValue failed; sVal = 0.000000 [ReadValue():iseDOMdpHSS.cpp:124]
Nov 26 08:18:54 homematic-raspi local0.err ReGaHss: ERROR: XMLRPC 'getValue' call failed (interface: 1009, params: {"00089D89BA17A9:5","ENERGY_COUNTER"}) [CallGetValue():iseXmlRpc.cpp:1448]
Nov 26 08:18:54 homematic-raspi local0.err ReGaHss: ERROR: CallGetValue failed; sVal = 0.000000 [ReadValue():iseDOMdpHSS.cpp:124]
Nov 26 08:18:54 homematic-raspi local0.err ReGaHss: ERROR: XMLRPC 'getValue' call failed (interface: 1009, params: {"00089D89BA17B0:5","ENERGY_COUNTER_OVERFLOW"}) [CallGetValue():iseXmlRpc.cpp:1448]
Nov 26 08:18:54 homematic-raspi local0.err ReGaHss: ERROR: CallGetValue failed; sVal = 0 [ReadValue():iseDOMdpHSS.cpp:124]
Nov 26 08:18:54 homematic-raspi local0.err ReGaHss: ERROR: XMLRPC 'getValue' call failed (interface: 1009, params: {"00089BE9A6ECD6:5","ENERGY_COUNTER"}) [CallGetValue():iseXmlRpc.cpp:1448]
Nov 26 08:18:54 homematic-raspi local0.err ReGaHss: ERROR: CallGetValue failed; sVal = 0.000000 [ReadValue():iseDOMdpHSS.cpp:124]
Nov 26 08:18:54 homematic-raspi local0.err ReGaHss: ERROR: XMLRPC 'getValue' call failed (interface: 1009, params: {"00089D89BA17A9:5","ENERGY_COUNTER_OVERFLOW"}) [CallGetValue():iseXmlRpc.cpp:1448]
Nov 26 08:18:54 homematic-raspi local0.err ReGaHss: ERROR: CallGetValue failed; sVal = 0 [ReadValue():iseDOMdpHSS.cpp:124]
Nov 26 08:18:54 homematic-raspi local0.err ReGaHss: ERROR: XMLRPC 'getValue' call failed (interface: 1009, params: {"00089BE9A6ECD6:5","ENERGY_COUNTER_OVERFLOW"}) [CallGetValue():iseXmlRpc.cpp:1448]
Nov 26 08:18:54 homematic-raspi local0.err ReGaHss: ERROR: CallGetValue failed; sVal = 0 [ReadValue():iseDOMdpHSS.cpp:124]

Ob die mit der Datenübertragung zusammenhängen kann ich nicht beurteilen.

Als nächstes wolle ich mal in dem Container /dev/ttyUSB0 versuchen zu konfigurieren und direkt auszulesen wenn ich daten mit der FB sende. Vielleicht ist ja die Verbindung zwischen Container und der Schnittstelle im Host hinüber.

Wenn jemand eine zündende andere Idee hat, was da kaputt gegangen ist, ich wär für jede Idee dankbar.

[litronics]

Habe den Fehler gefunden - der lag hauptsächlich zwischen Tastatur und Rückenlehne und ein klein wenig an CUxD und dem Ubuntu darunter.

Aus irgendwelchen, völlig unerfindlichen Gründen, hat anscheinend Ubuntu die zwei USB Interfaces vertauscht und so an den Container weitergegeben. Ergo war CUxD letztendlich auf dem falschen COM-Port konfiguriert.

Warum aber auch ein wenig CUxD schuld ist. Er hätte ja melden können, dass er auf "V" keine Antwort von dem Device bekommt - schließlich zeigt er es ja auch an. Aber gut - läuft wieder und ich merke mir immer auf Layer 0 anfangen, auch bei Seriellen Schnittstellen.