"websocket: unhandled opcode" Fehler mit Phoscon seit Update

[tomcat.x]

Hallo,

seit einem Update (fhem, apt) wird mein Log von solchen Einträgen geflutet:

Code Auswählen Erweitern


2023.01.31 13:26:03 2: GW_Conbee: websocket: unhandled opcode: 00:0d:6e:fe:fe:e4:50:cf-01"}�~
�{"
2023.01.31 13:26:03 2: GW_Conbee: websocket: unhandled text tr":{"colorcapabilities":0,"ctmax":65279,"ctmin":0,"id":"4","lastannounced":"2023-01-28T13:48:32Z","lastseen":"2023-
2023.01.31 13:26:08 2: GW_Conbee: websocket: unhandled opcode: -31T12:26Z","manufacturername":"IKEA of Sweden","


Sieht so aus, als ob die Kommunikation zwischen fhem und Phoscon nicht mehr bzw. nicht immer richtig funktioniert. Beides läuft auf dem gleichen Raspi, an dem auch der ConBee II Stick steckt. Grundsätzlich bekommen ich noch Werte von den Sensoren (vermutlich aber verzögert), Lichter schalten kann ich auch. Das lastError Reading im HUEBridge Device ist ein paar Wochen alt.

Die Definition sieht so aus:

Code Auswählen Erweitern


defmod GW_Conbee HUEBridge <FQDN>:81
attr GW_Conbee httpUtils 1
attr GW_Conbee icon phoscon
attr GW_Conbee ignoreUnknown 1
attr GW_Conbee key <key>

setstate GW_Conbee connected
setstate GW_Conbee 2022-12-20 16:14:05 groups 6
setstate GW_Conbee 2023-01-06 08:56:40 lastError resource, /lights/2/state, is not modifiable. Device is not reachable.
setstate GW_Conbee 2023-01-27 12:32:48 lights 5
setstate GW_Conbee 2022-12-20 10:46:42 rules 20
setstate GW_Conbee 2022-03-19 19:16:43 scenes 0
setstate GW_Conbee 2022-03-19 19:16:43 schedules 0
setstate GW_Conbee 2022-12-20 16:14:05 sensors 10
setstate GW_Conbee 2023-01-31 13:49:59 state connected


Die Phoscon App funktioniert im Browser ohne Probleme.

Hat jemand eine Idee oder das gleiche Problem?

Vielen Dank
Thomas

[tomcat.x]

Sehr seltsam, das Thema. Habe ja wohl auch nur ich.

Ich habe dann erst mal Verbose vom Gerät auf 1 gesetzt, damit die Log-Einträge aufhören. Als ich mir das vorgestern dann genauer anschauen wollte, habe ich wieder auf 3 gesetzt, aber nichts ist passiert, keine erneuten Einträge mehr. Danach lief es 2 Tage ohne Fehler/Meldungen.

Heute habe ich noch mal ein fhem Update gemacht und (diesmal nur) fhem danach durchgestartet. Jetzt sind die Log-Einträge erst mal wieder da. Verbose gleich wieder auf 1 gesetzt und irgendwann später probiere ich dann nochmal 3. Scheint nur nach dem fhem Neustart für eine gewisse (?) Zeit aufzutreten.

[JoWiemann]

Heute habe ich noch mal ein fhem Update gemacht und (diesmal nur) fhem danach durchgestartet.isse (?) Zeit aufzutreten.

Hallo,

ich hatte schonmal etwas ähnliches. Seither reboote ich den RPi nach einem Fhem Update.

Grüße Jörg

[tomcat.x]

Danke. Das mache ich eigentlich auch immer so, weil ich auch das Raspberry Pi OS dann update. Hatte ich jetzt nur mal testweise so gemacht. Als die Probleme nach dem Update angefangen haben, hatte ich vorher gebootet.

[uge]

Bei mir tritt der Fehler auch unregelmäßig nach einem FHEM-Neustart auf.
Manchmal hilft ein < set deCONZ active > (deCONZ heißt mein HUEBridge-Modul).
Manchmal hilft nur ein < shutdown restart >.
Während die unhandled-Meldungen im Log erscheinen, kann ich keine Zigbee-Lichter schalten.

Phoscon-GW:
RaspBee II
Version 2.14.01 / 6.2.2022
Firmware 26720700

Grüße

[tomcat.x]

Danke für die Info. Der Restart bewirkt bei mir wie gesagt ja das Gegenteil. Ich habe gerade (1 Tag nach Restart) Verbose wieder auf 3 gesetzt und bekomme keine Fehler angezeigt. Also beruhigt sich das irgendwann. Da ich noch schalten kann, kann ich abwarten. Das Hängt vielleicht mit der Anzahl der Geräte (Kommunikationsaufkommen) zusammen. Bei mir sind es nur wenige. Die meisten hängen am Tradfri-Gateway.

"Set ... active" probiere ich mal nach dem nächsten Neustart.

Phoscon-GW bei mir übrigens:
RaspBee II
Version 2.20.01 / 19.9.2022
Firmware 26720700

[uge]

Ich hab' jetzt noch mal nach einer Lösung gesucht.
Die unhandled-opcode-Meldungen treten bei mir sporadisch nach einem FHEM-Neustart auf.
Es gibt mehrere Log-Einträge pro Sekunde und es sind dann keine Zigbee-Kommandos möglich.
Dieser Zustand ändert sich auch nach längerer Zeit nicht von selbst.
Ein Wiederholen von < shutdown restart > löst das Problem nur zufällig und nicht immer.

Was immer hilft, ist ein Neustart der deconz-App auf dem Raspberry.
Mein Workaround ist nun ein Restart von deCONZ, nachdem FHEM gestartet ist.

Mittels DOIF setze ich 3 Minuten nach dem FHEM-Start das folgende System-Kommando ab:
{\system (`sudo systemctl restart deconz`)}

( Mit GUI: {\system (`sudo systemctl restart deconz-gui`)} )

( DOIF Trigger:  [global:"INITIALIZED"] )

( Zur Benutzung von systemctl wurden dem Benutzer fhem Rechte in der Datei /etc/sudoers erteilt. )

Grüße