Problem mit State-Monitor-Device (cuxd_2.3.3_ccu_x86_32 auf virtueller RaspberryMatic)
Moderator: Co-Administratoren
- Baxxy
- Beiträge: 10820
- Registriert: 18.12.2018, 15:45
- System: Alternative CCU (auf Basis OCCU)
- Hat sich bedankt: 607 Mal
- Danksagung erhalten: 2223 Mal
Problem mit State-Monitor-Device (cuxd_2.3.3_ccu_x86_32 auf virtueller RaspberryMatic)
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
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
- Raspberry Pi 4 als Homematic-Zentrale - Tipps und Informationen
- Analysescript für genutzte Funk-Adressen, Funkmodul-Hardware und Zentralen Hardware
- NANO CUL 868MHz - Stick zum AskSin Analyzer XS umflashen (Anleitung für ArduinoIDE unter Windows)
- Firmware Updates für IP-Aktoren / Sensoren... Info's, Tipps und Sonstiges
- CCU funkt nicht - CarrierSense (CS) Probleme erkennen und lösen
- uwe111
- Beiträge: 4820
- Registriert: 26.02.2011, 22:22
- Hat sich bedankt: 3 Mal
- Danksagung erhalten: 246 Mal
- Kontaktdaten:
Re: Problem mit State-Monitor-Device (cuxd_2.3.3_ccu_x86_32 auf virtueller RaspberryMatic)
Hallo Baxxy,
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?
Danach versuche bitte mal vor dem nächsten Neustart die cuxd.ps Dateien zu löschen:
und teste, ob er jetzt startet.
Viele Grüße
Uwe
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
Code: Alles auswählen
rm /tmp/cuxd.ps*
rm /usr/local/addons/cuxd/cuxd.ps*
Viele Grüße
Uwe
Alle sagten: Das geht nicht. Dann kam einer, der wußte das nicht und hat's einfach gemacht.
SPENDEN Download: CUxD 2.11, SSH KeyDir
SPENDEN Download: CUxD 2.11, SSH KeyDir
- Baxxy
- Beiträge: 10820
- Registriert: 18.12.2018, 15:45
- System: Alternative CCU (auf Basis OCCU)
- Hat sich bedankt: 607 Mal
- Danksagung erhalten: 2223 Mal
Re: Problem mit State-Monitor-Device (cuxd_2.3.3_ccu_x86_32 auf virtueller RaspberryMatic)
CUX9001001
Einstellung am State-Device geändert: ca 22:51:40
CUxD-Restart: ca 22:53:44
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
- Raspberry Pi 4 als Homematic-Zentrale - Tipps und Informationen
- Analysescript für genutzte Funk-Adressen, Funkmodul-Hardware und Zentralen Hardware
- NANO CUL 868MHz - Stick zum AskSin Analyzer XS umflashen (Anleitung für ArduinoIDE unter Windows)
- Firmware Updates für IP-Aktoren / Sensoren... Info's, Tipps und Sonstiges
- CCU funkt nicht - CarrierSense (CS) Probleme erkennen und lösen
- uwe111
- Beiträge: 4820
- Registriert: 26.02.2011, 22:22
- Hat sich bedankt: 3 Mal
- Danksagung erhalten: 246 Mal
- Kontaktdaten:
Re: Problem mit State-Monitor-Device (cuxd_2.3.3_ccu_x86_32 auf virtueller RaspberryMatic)
Hmm... irgendwie habe ich noch keine Ahnung, was da los ist.
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?
Viele Grüße
Uwe
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.
Uwe
Alle sagten: Das geht nicht. Dann kam einer, der wußte das nicht und hat's einfach gemacht.
SPENDEN Download: CUxD 2.11, SSH KeyDir
SPENDEN Download: CUxD 2.11, SSH KeyDir
- Baxxy
- Beiträge: 10820
- Registriert: 18.12.2018, 15:45
- System: Alternative CCU (auf Basis OCCU)
- Hat sich bedankt: 607 Mal
- Danksagung erhalten: 2223 Mal
Re: Problem mit State-Monitor-Device (cuxd_2.3.3_ccu_x86_32 auf virtueller RaspberryMatic)
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
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.
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.
Grüße
Baxxy
Grüße... Baxxy
- Raspberry Pi 4 als Homematic-Zentrale - Tipps und Informationen
- Analysescript für genutzte Funk-Adressen, Funkmodul-Hardware und Zentralen Hardware
- NANO CUL 868MHz - Stick zum AskSin Analyzer XS umflashen (Anleitung für ArduinoIDE unter Windows)
- Firmware Updates für IP-Aktoren / Sensoren... Info's, Tipps und Sonstiges
- CCU funkt nicht - CarrierSense (CS) Probleme erkennen und lösen
Re: Problem mit State-Monitor-Device (cuxd_2.3.3_ccu_x86_32 auf virtueller RaspberryMatic)
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
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
Proxmox VE HA Cluster auf Shuttle DL20N6 + DL10J, RaspberryMatic 3.75.7.20240420, RPI-RF-MOD mit HB-RF-ETH, HM-LGW + HmIP-HAP als Gateway, 82 BidCos-RF, 45 HmIP Geräte, ioBroker
- uwe111
- Beiträge: 4820
- Registriert: 26.02.2011, 22:22
- Hat sich bedankt: 3 Mal
- Danksagung erhalten: 246 Mal
- Kontaktdaten:
Re: Problem mit State-Monitor-Device (cuxd_2.3.3_ccu_x86_32 auf virtueller RaspberryMatic)
Hallo Wolfgang,
Viele Grüße
Uwe
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 Download: CUxD 2.11, SSH KeyDir
SPENDEN Download: CUxD 2.11, SSH KeyDir
- jmaus
- Beiträge: 9862
- Registriert: 17.02.2015, 14:45
- System: Alternative CCU (auf Basis OCCU)
- Wohnort: Dresden
- Hat sich bedankt: 464 Mal
- Danksagung erhalten: 1880 Mal
- Kontaktdaten:
Re: Problem mit State-Monitor-Device (cuxd_2.3.3_ccu_x86_32 auf virtueller RaspberryMatic)
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.
RaspberryMatic 3.75.7.20240420 @ ProxmoxVE – ~200 Hm-RF/HmIP-RF/HmIPW Geräte + ioBroker + HomeAssistant – GitHub / Sponsors / PayPal /
- uwe111
- Beiträge: 4820
- Registriert: 26.02.2011, 22:22
- Hat sich bedankt: 3 Mal
- Danksagung erhalten: 246 Mal
- Kontaktdaten:
Re: Problem mit State-Monitor-Device (cuxd_2.3.3_ccu_x86_32 auf virtueller RaspberryMatic)
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
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 Download: CUxD 2.11, SSH KeyDir
SPENDEN Download: CUxD 2.11, SSH KeyDir
- uwe111
- Beiträge: 4820
- Registriert: 26.02.2011, 22:22
- Hat sich bedankt: 3 Mal
- Danksagung erhalten: 246 Mal
- Kontaktdaten:
Re: Problem mit State-Monitor-Device (cuxd_2.3.3_ccu_x86_32 auf virtueller RaspberryMatic)
Hallo Jens,
Viele Grüße
Uwe
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.
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.
Das hatten wir ja bereits diskutiert. Das könnte man so machen, aber Du kennst ja meine Meinung dazu.jmaus hat geschrieben: ↑01.02.2020, 20:04Und 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.
Viele Grüße
Uwe
Alle sagten: Das geht nicht. Dann kam einer, der wußte das nicht und hat's einfach gemacht.
SPENDEN Download: CUxD 2.11, SSH KeyDir
SPENDEN Download: CUxD 2.11, SSH KeyDir