Problem mit State-Monitor-Device (cuxd_2.3.3_ccu_x86_32 auf virtueller RaspberryMatic)

Anbindung von FS20-Komponenten, ELV-Wetterstationen, EnOcean und DMX an HomeMatic

Moderator: Co-Administratoren

Baxxy
Beiträge: 1480
Registriert: 18.12.2018, 15:45
System: Alternative CCU (auf Basis OCCU)
Hat sich bedankt: 140 Mal
Danksagung erhalten: 218 Mal

Problem mit State-Monitor-Device (cuxd_2.3.3_ccu_x86_32 auf virtueller RaspberryMatic)

Beitrag von Baxxy » 22.01.2020, 19:56

Hallo Uwe,

der User wiwo ist auf ein Problem mit dem State-Monitor-Device gestoßen welches ich heute bei einem Test nachstellen konnte. Als System
ist eine virtuelle RaspberryMatic 3.49.17.20191225 mit cuxd_2.3.3_ccu_x86_32 im Einsatz.

Kurz zusammengefasst: Das State-Monitor-Device (Typ 90) lässt sich problemlos einrichten und erscheint auch ordnungsgemäß in der vRM. Nach einem Neustart des Systems ist die CUxD - Statusseite sowie die CUxD - Geräte Seite nicht mehr erreichbar. Desweiteren lässt sich das State-Monitor-Device nicht mehr auf herkömmlichen Weg aus der vRM entfernen.
Hier habe ich das etwas detaillierter beschrieben.

Wenn du weitere Informationen brauchst gib mir Bescheid.

Grüße
Baxxy
Grüße
Baxxy

Benutzeravatar
uwe111
Beiträge: 4149
Registriert: 26.02.2011, 22:22
Danksagung erhalten: 44 Mal
Kontaktdaten:

Re: Problem mit State-Monitor-Device (cuxd_2.3.3_ccu_x86_32 auf virtueller RaspberryMatic)

Beitrag von uwe111 » 22.01.2020, 22:42

Hallo Baxxy,
Baxxy hat geschrieben:
22.01.2020, 19:56
Wenn du weitere Informationen brauchst gib mir Bescheid.
Ich habe mir die Beiträge angesehen und vermute, dass der CUxD wahrscheinlich beim Laden der Gerätekonfiguration abstürzt.
Wenn der CUxD nicht läuft, kann man auch keine CUxD Geräte aus der CCU Konfiguration entfernen. Das ist soweit richtig.

Kannst Du bitte mal das CUxD Logfile aktivieren und mir nach dem Absturz zusenden?

Code: Alles auswählen

LOGFILE=/tmp/cuxdlog.txt
LOGLEVEL=5
LOGFLAGS=1
LOGSIZE=5000000
Danach versuche bitte mal vor dem nächsten Neustart die cuxd.ps Dateien zu löschen:

Code: Alles auswählen

rm /tmp/cuxd.ps*
rm /usr/local/addons/cuxd/cuxd.ps*
und teste, ob er jetzt startet.

Viele Grüße

Uwe
Alle sagten: Das geht nicht. Dann kam einer, der wußte das nicht und hat's einfach gemacht.
SPENDEN :wink: Download: CUxD 2.4.4, RFD-Monitor, Vellemann K8055, SSH KeyDir

Baxxy
Beiträge: 1480
Registriert: 18.12.2018, 15:45
System: Alternative CCU (auf Basis OCCU)
Hat sich bedankt: 140 Mal
Danksagung erhalten: 218 Mal

Re: Problem mit State-Monitor-Device (cuxd_2.3.3_ccu_x86_32 auf virtueller RaspberryMatic)

Beitrag von Baxxy » 22.01.2020, 23:06

uwe111 hat geschrieben:
22.01.2020, 22:42
Kannst Du bitte mal das CUxD Logfile aktivieren und mir nach dem Absturz zusenden?
cuxdlog.txt
(1.02 MiB) 34-mal heruntergeladen
CUX9001001
Einstellung am State-Device geändert: ca 22:51:40
CUxD-Restart: ca 22:53:44
uwe111 hat geschrieben:
22.01.2020, 22:42
Danach versuche bitte mal vor dem nächsten Neustart die cuxd.ps Dateien zu löschen:
Hat leider nichts gebracht. CUxD läuft zwar erstmal normal, aber sobald man im State-Device den Haken bei USE_HMDATAPT setzt oder entfernt geht die CPU Last wieder auf 50%.

Grüße
Baxxy
Grüße
Baxxy

Benutzeravatar
uwe111
Beiträge: 4149
Registriert: 26.02.2011, 22:22
Danksagung erhalten: 44 Mal
Kontaktdaten:

Re: Problem mit State-Monitor-Device (cuxd_2.3.3_ccu_x86_32 auf virtueller RaspberryMatic)

Beitrag von uwe111 » 23.01.2020, 22:09

Hmm... irgendwie habe ich noch keine Ahnung, was da los ist.
Baxxy hat geschrieben:
22.01.2020, 23:06
CUxD läuft zwar erstmal normal, aber sobald man im State-Device den Haken bei USE_HMDATAPT setzt oder entfernt geht die CPU Last wieder auf 50%.
Es sieht so aus, als ob der CUxD bis zum Neustart weiterläuft und einfach nichts mehr tut. Kannst Du das bestätigen?
Die Stelle, wo es nicht weitergeht, habe ich gefunden. Ich habe leider kein x86 System zum Testen, also hoffe ich es so zu finden.

Kannst Du mal bitte testen, ob er immer an dieser Stelle hängt?

Code: Alles auswählen

22.01.2020 22:51:49.14 [8309] {114536} execute_event_start()
22.01.2020 22:51:49.14 [8309] {114536} get_parameter(9001001:2) - SWITCH_24H = '0'
22.01.2020 22:51:49.14 [8309] {114536} CUX9001001:2 process_writeBinValue(SWITCH_24H = 0) type(1) - 1
22.01.2020 22:51:49.14 [8309] {114536} syslog: DBG: event_put(CUX9001001:2.SWITCH_24H=0)
22.01.2020 22:53:43.64 [8309] {114600} syslog: Received SIGHUP signal.
Viele Grüße

Uwe
Alle sagten: Das geht nicht. Dann kam einer, der wußte das nicht und hat's einfach gemacht.
SPENDEN :wink: Download: CUxD 2.4.4, RFD-Monitor, Vellemann K8055, SSH KeyDir

Baxxy
Beiträge: 1480
Registriert: 18.12.2018, 15:45
System: Alternative CCU (auf Basis OCCU)
Hat sich bedankt: 140 Mal
Danksagung erhalten: 218 Mal

Re: Problem mit State-Monitor-Device (cuxd_2.3.3_ccu_x86_32 auf virtueller RaspberryMatic)

Beitrag von Baxxy » 23.01.2020, 22:49

uwe111 hat geschrieben:
23.01.2020, 22:09
Kannst Du mal bitte testen, ob er immer an dieser Stelle hängt?
Ich gebe mein bestes. :)
Die Stelle ist immer die selbe.

Code: Alles auswählen

23.01.2020 22:29:01.15 [1628] {106056} get_parameter(9001001:2) - SWITCH_24H = '0'
23.01.2020 22:29:01.15 [1628] {106056} CUX9001001:2 process_writeBinValue(SWITCH_24H = 0) type(1) - 1
23.01.2020 22:29:01.15 [1628] {106056} syslog: DBG: event_put(CUX9001001:2.SWITCH_24H=0) <--- ab hier 50% CPU Last
23.01.2020 22:33:33.53 [1628] {106120} syslog: Received SIGHUP signal. <--- CUxD Restart
uwe111 hat geschrieben:
23.01.2020, 22:09
Es sieht so aus, als ob der CUxD bis zum Neustart weiterläuft und einfach nichts mehr tut. Kannst Du das bestätigen?
Würde ich auch so sehen. Er geht ja auf 50% CPU-Last und erzeugt auch keine weiteren Logeinträge.

Übrigens braucht die virtuelle RaspberryMatic auch eine gefühlte Ewigkeit zum starten. Grob geschätzt 3 Minuten, ohne State-Device ca. 30 Sekunden.
uwe111 hat geschrieben:
23.01.2020, 22:09
Ich habe leider kein x86 System zum Testen
Das ist schade, vielleicht probierst du es mal aus. Ich habe das hier auf nem Windows PC in VirtualBox am laufen. Ist die Virtualisierungslösung erstmal am Start dauert das erstellen und Starten der VM nur 2-3 Minuten. :wink:

Grüße
Baxxy
Grüße
Baxxy

wiwo
Beiträge: 7
Registriert: 17.01.2020, 17:48
Hat sich bedankt: 3 Mal
Danksagung erhalten: 1 Mal

Re: Problem mit State-Monitor-Device (cuxd_2.3.3_ccu_x86_32 auf virtueller RaspberryMatic)

Beitrag von wiwo » 01.02.2020, 16:56

Hallo Uwe,

gibt es zu dem Verhalten des CUxD in der oben genannten Konstellation bereits Erkenntnisse von dir?

Eine Behebung würde mir wirklich sehr sehr helfen, da ich den geplanten Umzug weg von meiner CCU2 auf die virtualisierte RaspberryMatic sonst leider nicht machen kann. Ich nutze die wirklich gute Funktion der State-Monitor-Devices für mehrere Laufzeiterfassungen.

Gruss und Dank
Wolfgang
Shuttle DL10J, Proxmox VE mit RaspberryMatic 3.51.6.20200621, HB-RF-USB, 628 Kanäle, 106 Geräte

Benutzeravatar
uwe111
Beiträge: 4149
Registriert: 26.02.2011, 22:22
Danksagung erhalten: 44 Mal
Kontaktdaten:

Re: Problem mit State-Monitor-Device (cuxd_2.3.3_ccu_x86_32 auf virtueller RaspberryMatic)

Beitrag von uwe111 » 01.02.2020, 18:51

Hallo Wolfgang,
wiwo hat geschrieben:
01.02.2020, 16:56
gibt es zu dem Verhalten des CUxD in der oben genannten Konstellation bereits Erkenntnisse von dir?
Ja, ich hab's schon repariert. Nur leider hatte ich bisher keine Zeit, ein neues x86 Installationspaket mit der neuen Version zu bauen.

Viele Grüße

Uwe
Alle sagten: Das geht nicht. Dann kam einer, der wußte das nicht und hat's einfach gemacht.
SPENDEN :wink: Download: CUxD 2.4.4, RFD-Monitor, Vellemann K8055, SSH KeyDir

Benutzeravatar
jmaus
Beiträge: 6052
Registriert: 17.02.2015, 14:45
System: Alternative CCU (auf Basis OCCU)
Wohnort: Dresden
Hat sich bedankt: 30 Mal
Danksagung erhalten: 345 Mal
Kontaktdaten:

Re: Problem mit State-Monitor-Device (cuxd_2.3.3_ccu_x86_32 auf virtueller RaspberryMatic)

Beitrag von jmaus » 01.02.2020, 20:04

uwe111 hat geschrieben:
01.02.2020, 18:51
Hallo Wolfgang,
wiwo hat geschrieben:
01.02.2020, 16:56
gibt es zu dem Verhalten des CUxD in der oben genannten Konstellation bereits Erkenntnisse von dir?
Ja, ich hab's schon repariert. Nur leider hatte ich bisher keine Zeit, ein neues x86 Installationspaket mit der neuen Version zu bauen.
Wenn du das machst, kannst du bitte für alle unterstützten platformen (ccu2, ccu3, x86_32, etc.) dir bitte angewöhnen einheitliche versionsnummern zu vergeben? Es ist in der Vergangenheit nicht nur einmal passiert das Nutzer es versuchen die ccu3 version unter x86_32 zu installieren weil die als 2.3.4 ausgegeben wird und auch als aktuellste versionsnummer vorgeschlagen wird. Und auch wenn du nur änderungen an z.b. Der x86 version machst solltest du trotzdem immer parallel für alle platformen neue Installationsarchive mit aktualisierten versionsnummern erstellen und verteilen. Das vermeidet einfach derartige Missverständnisse und Probleme.
Und noch besser wäre es natürlich wenn du dich dich darauf einlassen könntest für alle platformen ein einzelnes Installationsarchiv anzubieten wo für alle plattformen alle binaries drinstecken und dann einfach in der Installationsroutine automatisch erkannt wird welche hardware/plattform zugrunde liegt und dann entsprechend die passenden binaries installiert werden. Auch das würde dann die Verwirrung über die vielen verschiedenen Installationsarchive mit einem schlag eliminieren.

Benutzeravatar
uwe111
Beiträge: 4149
Registriert: 26.02.2011, 22:22
Danksagung erhalten: 44 Mal
Kontaktdaten:

Re: Problem mit State-Monitor-Device (cuxd_2.3.3_ccu_x86_32 auf virtueller RaspberryMatic)

Beitrag von uwe111 » 02.02.2020, 21:09

Hallo Wolfgang,

ich habe gerade ein aktuelles Installationspaket mit dem Namen cuxd_2.3.9_ccux86.tar.gz auf der Downloadseite viewtopic.php?f=37&t=15298 bereitgestellt.

Viele Grüße

Uwe
Alle sagten: Das geht nicht. Dann kam einer, der wußte das nicht und hat's einfach gemacht.
SPENDEN :wink: Download: CUxD 2.4.4, RFD-Monitor, Vellemann K8055, SSH KeyDir

Benutzeravatar
uwe111
Beiträge: 4149
Registriert: 26.02.2011, 22:22
Danksagung erhalten: 44 Mal
Kontaktdaten:

Re: Problem mit State-Monitor-Device (cuxd_2.3.3_ccu_x86_32 auf virtueller RaspberryMatic)

Beitrag von uwe111 » 02.02.2020, 21:35

Hallo Jens,
jmaus hat geschrieben:
01.02.2020, 20:04
Wenn du das machst, kannst du bitte für alle unterstützten platformen (ccu2, ccu3, x86_32, etc.) dir bitte angewöhnen einheitliche versionsnummern zu vergeben?
Nach Bugfixes kann es leider vorkommen, dass sich die 3. Stelle der Version unterscheidet. Da ich zum Compilieren für die 4 verschiedenen Prozessoren 2 virtuelle Maschinen nutze, ist es für mich zeitaufwendiger, immer alles neu zu bauen.
jmaus hat geschrieben:
01.02.2020, 20:04
Es ist in der Vergangenheit nicht nur einmal passiert das Nutzer es versuchen die ccu3 version unter x86_32 zu installieren weil die als 2.3.4 ausgegeben wird und auch als aktuellste versionsnummer vorgeschlagen wird.
Das lag wahrscheinlich daran, dass bei der x86-Version bisher die Versionsnummer der ccu3 Version abgefragt wurde. Ich habe das im neuen x86 Installationspaket korrigiert.
jmaus hat geschrieben:
01.02.2020, 20:04
Und noch besser wäre es natürlich wenn du dich dich darauf einlassen könntest für alle platformen ein einzelnes Installationsarchiv anzubieten wo für alle plattformen alle binaries drinstecken und dann einfach in der Installationsroutine automatisch erkannt wird welche hardware/plattform zugrunde liegt und dann entsprechend die passenden binaries installiert werden.
Das hatten wir ja bereits diskutiert. Das könnte man so machen, aber Du kennst ja meine Meinung dazu.

Viele Grüße

Uwe
Alle sagten: Das geht nicht. Dann kam einer, der wußte das nicht und hat's einfach gemacht.
SPENDEN :wink: Download: CUxD 2.4.4, RFD-Monitor, Vellemann K8055, SSH KeyDir

Antworten

Zurück zu „CUxD“