Duty Cycle mit CUxD auslesen

[Janniman]

Moin!
Ich habe ein Problem mit dem DC als CuxD Wrapper device. Dieses Device habe ich angelegt und es funktionierte auch ordentlich. Nun möchte ich aber dieses Device löschen...

Problematische CCU-Firmware: 2.29.22, vorab auf CuxD Version 1.11. (Hierbei bin ich noch auf der Fehlersuche, ich hänge in einer verzögerten Bootschleife). Zur Fehlersuche habe ich versucht den DC auszulesen, deshalb die Installation.

Über CuxD Daemon - Geräte konnte ich das Gerät nicht löschen, erst stürzt CuxD ab, dann die CCU2 (auch ein Neustart von CuxD nutzt da wenig, es verzögert dies nur um eine/wenige Minuten). Das Gerät (Wrapper) bleibt erhalten. In der CCU2 - Einstellungen - Geräte passiert meist gar nichts. Manchmal sagt der Gerätemanager das es noch direkte Verknüpfungen gäbe, aber diese Meldung kommt selten.Meist passiert wirklich nichts, außer das prompt der CuxD abschmiert.
Mit der 2.29.22 Installation geht auch kein Reboot in den Safe-Mode mehr (gut, das habe ich noch nie benutzt), das sollte aber helfen.

Mein Ansatz ist die Geräte wieder auf den vorherigen Stand zurückzusetzen, dann ein Firmware Downgrade und danach Backup einspielen.
Wie bekomme ich dieses Device wieder gelöscht?
Das Fehlerprotokoll sagt darüber rein gar nichts, es fehlt mir der entscheidende Hinweis.

Jan

[Janniman]

Entschuldigt,

habe es gerade geschafft das Gerät zu löschen.
Fehler ist wohl eine defekte Installationsdatei der neuen Firmware. Da ich ich nicht weiter wusste, wollte ich die CCU-Firmware 2.29.22 erneut drüberinstallieren, aber dieses mal (nicht beim der ersten Installation) meldete mir die CCU:
An internal error was detected in the service software. The diagnostice are being emailed to the system administrator (root)

Es kam zwar nie eine Mail an, aber was soll ich sagen...
dann konnte ich das Gerät löschen.

Jan

[alchy]

Ich habe deine Frage aus dem Thread >Duty Cycle CCU2 mit HM Script auslesen und speichern<

abgetrennt und verschoben. Das ist nicht böse gemeint. Ihr müsst aber beachten, das uwe111 unter Umständen natürlich dort nicht unbedingt mitliest.
So erfährt er ja nicht, das es ein eventuelles Problem mit seiner Implementierung des DutyCycle gibt.
Im CuxD Forum aber bin ich mir sicher, das er Dir helfen kann und wird.

Ich werde deine Beiträge verschieben bei Gelegenheit nach Cuxd. -> done,

viel Spass

Alchy

[uwe111]

Den Fehler kann ich bei mir leider nicht nachstellen.

Ich habe zum Testen auf der CCU2 unter FW 2.29.22 und mit CUxD 1.11 ein Wrapper.Transform Device angelegt und konnte es auch problemlos wieder löschen.
Die DC-Abfrage erfolgt als eigenständiger Prozess (TCL-Script) parallel zu CUxD und hat keinen direkten Einfluss auf CUxD.

Um einen CUxD Absturz analysieren zu können, benötige ich das CUxD-Logfile von dem Absturz.

Viele Grüße

Uwe

[JRiemann]

Hmmm... jetzt wo ich es lese....

Bei meinen Tests mit der CUxD DC-Umsetzung hatte ich das Wrapper-Gerät als "transform" und ein zusätzliches als "State" eingerichtet.
Das "transform" Gerät wollte ich dann über "Geräte" der CUxD-Oberfläche lösen und hatte als Folge einen Absturz des CUxD. Nach dem Restart war das zu löschende Gerät noch vorhanden.
Der nächste Löschversuch über die Geräteliste der WebUI war dann erfolgreich.

Das Problem hatte ich als bedeutungslos und einmalig eingestuft und den Fehler nicht weiter verfolgt.

[klassisch]

Ok, dann war ich nicht der Einzige, viewtopic.php?p=379059#p379059 . Bei der Einstellung im Postfach hat sich die CCU aufgehängt. Da meine CCU auch recht voll ist und die Sache mit ein paar Restarts behoben war, habe ich das auch "weggeschüttelt". Jetzt wird der DC brav gemessen und im ioBroker geloggt.

[Janniman]

Moin Alchy,

danke für das verschieben. Mein Gedanke war eben, das passt dort hinein.

Wobei ich schreiben muss, nach einem Neustart der CCU2 war das Gerät wieder da.
OK, ich habe später gelesen, der Watchdog macht eventuell Probleme und somit habe ich diesen deinstalliert. Im gleichen Atemzug habe ich das Gerät, das es ja sowieso wieder überall vorhanden war, wieder genutzt den DC anzuzeigen und zu weiter beobachten.

Es scheint bei mir am Watchdog (und an mir) gelegen zu haben, denn nach einigen Stunden ist mein DC jetzt deutlich gesunken (auf 6). Selbst die Neuinstallation der Firmware lief dieses mal sauber durch.
An mir: ich habe der CCU2 nicht genügend Zeit gelassen und mich nicht mit dem Button [Abmelden] von der Oberfläche verabschiedet, dann schlug irgendwann der Watchdog zu (obwohl die Zeit schon auf 15 Minuten stand).

In meinem LOG gibt es aber nun wieder etliche Fehler:

Code: Alles auswählen

Aug 27 18:43:38 homematic-ccu2 user.err kernel: [    0.000000] saif0_clk_set_rate: clock is gated
Aug 27 18:43:38 homematic-ccu2 user.err kernel: [    0.000000] saif1_clk_set_rate: clock is gated
...
Aug 27 18:43:38 homematic-ccu2 user.info kernel: [    6.160000] ip_tables: (C) 2000-2006 Netfilter Core Team
Aug 27 18:43:38 homematic-ccu2 user.err kernel: 0>[    6.820000] udevd[115]: starting version 182
Aug 27 16:43:38 homematic-ccu2 daemon.err udevd[115]: specified group 'dialout' unknown
Aug 27 16:43:38 homematic-ccu2 daemon.err udevd[115]: specified group 'kmem' unknown
Aug 27 16:43:38 homematic-ccu2 daemon.err udevd[115]: specified group 'video' unknown
Aug 27 16:43:38 homematic-ccu2 daemon.err udevd[115]: specified group 'lp' unknown
Aug 27 16:43:38 homematic-ccu2 daemon.err udevd[115]: specified group 'floppy' unknown
Aug 27 16:43:38 homematic-ccu2 daemon.err udevd[115]: specified group 'cdrom' unknown
Aug 27 16:43:38 homematic-ccu2 daemon.err udevd[115]: specified group 'tape' unknown
...
Aug 27 18:45:50 homematic-ccu2 daemon.err cuxd[350]: AUTOMOUNT system(mount -t vfat /media/sd-mmcblk0 /mnt) exit(255)
Aug 27 18:46:14 homematic-ccu2 daemon.warn cuxd[350]: process_rpc_request(127.0.0.1) - illegal XMLRPC(listDevices) request
Aug 27 18:46:39 homematic-ccu2 daemon.warn cuxd[350]: process_rpc_request(127.0.0.1) - illegal XMLRPC(init) request
Aug 27 18:46:41 homematic-ccu2 user.info : hss_lcd: Programm initialisiert.
Aug 27 16:46:43 homematic-ccu2 daemon.info init: starting pid 602, tty '/dev/ttyAMA0': '/sbin/getty -L ttyAMA0 115200 vt100 '
Aug 27 16:46:43 homematic-ccu2 daemon.info init: starting pid 603, tty '/dev/ttyGS0': '/sbin/getty -L ttyGS0 115200 vt100 '
Aug 27 18:47:23 homematic-ccu2 user.err rfd: HSSParameter::GetValue() id=TEMPERATURE failed getting physical value.
Aug 27 18:47:27 homematic-ccu2 user.err rfd: HSSParameter::GetValue() id=DECISION_VALUE failed getting physical value.
Aug 27 18:47:40 homematic-ccu2 user.err rfd: HSSParameter::GetValue() id=TEMPERATURE failed getting physical value.
Aug 27 18:47:40 homematic-ccu2 local0.err ReGaHss: Error: IseXmlRpc::CallXmlrpcMethod: execute result isFault; method =getValue Params = {"MEQ0205110:5","TEMPERATURE"} result= [faultCode:-1,faultString:"Failure"] [iseXmlRpc.cpp:2641]
Aug 27 18:47:40 homematic-ccu2 local0.err ReGaHss: Error: IseXmlRpc::CallGetValue: CallXmlrpcMethod failed [iseXmlRpc.cpp:1455]
Aug 27 18:47:40 homematic-ccu2 local0.err ReGaHss: Error: IseHssDP::ReadValue: CallGetValue failed; sVal = 0.000000 [iseDOMdpHSS.cpp:130]
Aug 27 18:47:41 homematic-ccu2 local0.err ReGaHss: Error: IseXmlRpc::CallGetValue: XmlrpcTypeToIseVal failed [iseXmlRpc.cpp:1463]
Aug 27 18:47:41 homematic-ccu2 local0.err ReGaHss: Error: IseHssDP::ReadValue: CallGetValue failed; sVal =  [iseDOMdpHSS.cpp:130]
Aug 27 18:47:41 homematic-ccu2 local0.err ReGaHss: Error: IseXmlRpc::CallGetValue: XmlrpcTypeToIseVal failed [iseXmlRpc.cpp:1463]
Aug 27 18:47:41 homematic-ccu2 local0.err ReGaHss: Error: IseHssDP::ReadValue: CallGetValue failed; sVal =  [iseDOMdpHSS.cpp:130]
Aug 27 18:47:41 homematic-ccu2 local0.err ReGaHss: Error: IseXmlRpc::CallGetValue: XmlrpcTypeToIseVal failed [iseXmlRpc.cpp:1463]
Aug 27 18:47:41 homematic-ccu2 local0.err ReGaHss: Error: IseHssDP::ReadValue: CallGetValue failed; sVal =  [iseDOMdpHSS.cpp:130]
Aug 27 18:47:43 homematic-ccu2 local0.err ReGaHss: Error: IseXmlRpc::CallGetValue: XmlrpcTypeToIseVal failed [iseXmlRpc.cpp:1463]
Aug 27 18:47:43 homematic-ccu2 local0.err ReGaHss: Error: IseHssDP::ReadValue: CallGetValue failed; sVal =  [iseDOMdpHSS.cpp:130]
Aug 27 18:47:45 homematic-ccu2 daemon.info cuxd[350]: INIT 'xmlrpc_bin://127.0.0.1:1999' '2347'
Aug 27 18:47:46 homematic-ccu2 daemon.info cuxd[350]: setup CUX9000002:1 read(CUX-SYSTEM:1) => CUxD.CUX-SYSTEM:1 (SYSTEM) DP(DC_..........)
Aug 27 18:47:49 homematic-ccu2 local0.err ReGaHss: Error: IseXmlRpc::CallGetValue: XmlrpcTypeToIseVal failed [iseXmlRpc.cpp:1463]
Aug 27 18:47:49 homematic-ccu2 local0.err ReGaHss: Error: IseHssDP::ReadValue: CallGetValue failed; sVal =  [iseDOMdpHSS.cpp:130]
Aug 27 17:01:02 homematic-ccu2 auth.crit sshd[1142]: fatal: no matching mac found: client hmac-sha1,hmac-sha1-96,hmac-md5,hmac-md5-96,hmac-ripemd160,hmac-ripemd160@openssh.com server hmac-sha2-256,hmac-sha2-512 [preauth]

Das Gerät "MEQ0205110" ist ein Temperatur-Differenz-Sensor, aber ich frage weder in Skripten, noch auf der GUI den angemeckerten Datenkanal :5 ab.

Wieso habe ich mir schon wieder die SD-Karte verbogen? Die geht doch.

Code: Alles auswählen

LOGFILEMOVE=/media/sd-mmcblk0/cuxd/logfile/
DEVLOGFILE=/tmp/devlog.txt
DEVLOGSIZE=0
DEVLOGMOVE=/media/sd-mmcblk0/cuxd/devlog/
DEVLOGMOVE-HR=
DEVLOGEXPORT=
DEVTIMEFORMAT=%Y-%m-%dT%X
DEVDATAFORMAT=
DEVLOGOLDALIAS=1
SUBSCRIBE-RF=1
SUBSCRIBE-WR=1
AUTOSAVE=1
MOUNTCMD=mount -t vfat /media/sd-mmcblk0 /mnt
UMOUNTCMD=umount /mnt
BACKUPCMD=/usr/local/sys-backup

Viel schlimmer ist für mich, ich kann zwar mit Putty per SSH auf das Gerät zugreifen, aber mit dem Totalcommander geht keine FTP/SFTP-Verbindungen mehr, naja es gibt andere Möglichkeiten.

Jan