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

[Baxxy]

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

[uwe111]

Hallo Baxxy,

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

[Baxxy]

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

cuxdlog.txt

(1.02 MiB) 109-mal heruntergeladen

CUX9001001
Einstellung am State-Device geändert: ca 22:51:40
CUxD-Restart: ca 22:53:44

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

[uwe111]

Hmm... irgendwie habe ich noch keine Ahnung, was da los ist.

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

[Baxxy]

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

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.

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.

Grüße
Baxxy

[wiwo]

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

[uwe111]

Hallo Wolfgang,

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

[jmaus]

Hallo Wolfgang,

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.

[uwe111]

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

[uwe111]

Hallo Jens,

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.

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.

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