HMUARTLGW disconnected

[skuzzy1704]

Hallo,

habe gestern das Sonos Modul installiert. Danach hat fhem nicht mehr reagiert. Auch nach einem Neustart des Pi nicht. Nach einem Restore lief dann wieder alles, bis auf die Homematic Komponenten.
Im Log wiederholt sich folgendes:

2020-12-10 15:42:12 HMUARTLGW myHmUART CONNECTED
2020-12-10 15:42:13 HMUARTLGW myHmUART cond: init
2020-12-10 15:42:25 HMUARTLGW myHmUART cond: disconnected

Ich verwende einen Pi mit HM-MOD-RPI-PCB. Vor dem ganzen Spaß habe ich die Pakete für Sonos auf dem Pi installiert und aktualisiert.

Jemand eine Idee?

[Kiter1988]

Hallo,

ich kann dir zwar nicht helfen, habe aber das gleiche Problem. Allerdings ist bei mir, seit dem ich den Conbee Stick benutze.
Nach einem kompletten neustart, mit Strom weg läuft es dann wieder einige Zeit.

[Beta-User]

Zum Ausgangsproblem kann ich wenig sagen, da fehlen m.E. einfach zu viele Infos zu dem, was sonst noch läuft.

Bzgl. deconz+Modul an UART hätte ich das anzubieten: Conbee II und HM-MOD-RPI-PCB

[Otto123]

Jemand eine Idee?

Wenn dieser Status immer wechselt, klingt es danach, das zwei um die UART Schnittstelle kämpfen.
Für weitere Ideen fehlen praktisch alle Infos:

Pakete für Sonos

Sonos braucht meines Wissens libsoap-lite-perl libwww-perl libxml-parser-lite-perl oder libxml-parser-perl - das hat alles nichts mit dem  HM-MOD-RPI-PCB zu tun.

War nur der Neustart ursächlich? ist das gesetzt?

Code Auswählen Erweitern

attr initialUsbCeck disable 1

[skuzzy1704]

Danke für die schnellen Antworten.

Ich nutze tatsächlich Conbee II. Aber das Ding läuft schon eine ganze Weile mit!

attr initialUsbCeck disable 1

Habe ich erneut gesetzt, hat aber leider keine Auswirkungen.

Habe mich durch den Beitrag zu Conbee II gehangelt. Die Anpassungen des Dienstes bringen mich aber nicht weiter.

@Otto
Woran erkenne ich das sic 2 Schnittstellen bekämpfen?

[Otto123]

Habe ich erneut gesetzt, hat aber leider keine Auswirkungen.

erneut meint was? Steht das in config beim Start drin? Hast Du mal ins Log nach dem Start geschaut? steht da was mit AMA0 ?

Ich habe nicht gesagt das sich zwei Schnittstellen bekämpfen, sondern das zwei (Dienste oder was auch immer) um die gleiche Schnittstelle kämpfen.
Also Vermutung: dein Conbee ist schneller und belegt die UART. Hast Du das geprüft? Also Conbee beendet bzw nicht mit gestartet, geht dann HMUART?

[skuzzy1704]

Naja, nochmal gesetzt heißt eben genau das. Ich war mir nicht mehr sicher ob das seinerzeit gemacht wurde.

Im Log sah das so aus, also startet deConz später?

2020.12.10 18:19:44 3: Opening myHmUART device /dev/ttyAMA0
2020.12.10 18:19:44 3: Setting myHmUART serial parameters to 115200,8,N,1
2020.12.10 18:19:44 3: myHmUART device opened
2020.12.10 18:19:44 0: Featurelevel: 6
2020.12.10 18:19:45 3: deCONZ: websocket opened to 192.168.xxx.xx:xxxx
2020.12.10 18:19:45 3: deCONZ: websocket: Switching Protocols ok
2020.12.10 18:19:48 1: HMUARTLGW myHmUART did not respond for the 1. time, resending
2020.12.10 18:19:51 1: HMUARTLGW myHmUART did not respond for the 2. time, resending
2020.12.10 18:19:54 1: HMUARTLGW myHmUART did not respond for the 3. time, resending
2020.12.10 18:19:57 1: HMUARTLGW myHmUART did not respond after all, reopening
2020.12.10 18:19:57 3: myHmUART device closed

Mittlerweile habe ich den Beitrag zu Conbee II nochmal gelesen und die Anpassungen für den Dienst durchgeführt. Ein Shutdown mit stromlos hat dann zum Erfolg geführt. Das hatte vor den Anpassungen nichts gebracht.

Was meintest du damit, die fhem.cfg?

Steht das in config beim Start drin?

[Otto123]

ein attr initialUsbCeck disable 1 im laufenden Betrieb bringt nichts. Es muss beim Start aktiv sein (in der Config stehen), d.h. man führt es aus, drückt save und startet neu.
Es ist eine, häufige Ursache den Betrieb des RPI Moduls zu stören.
Jetzt wissen wir Du hast conbee.
Hast Du den Dienst des conbee im System mal deaktiviert und ohne diesen Dienst das komplette System neu gestartet? (ich meine nicht den conbee in FHEM)

[skuzzy1704]

Hast Du den Dienst des conbee im System mal deaktiviert und ohne diesen Dienst das komplette System neu gestartet? (ich meine nicht den conbee in FHEM)

Nur das und fhem Neustart. Nicht den Pi.

Code Auswählen Erweitern

sudo systemctl stop deconz

Ich gehe mal davon aus das du das nicht meinst, also Nein.

[Beta-User]

Hattest du den service auch neu initialisiert, nachdem du die Datei editiert hattest?

Und warum deconz/HUEBridge über externe IP einbinden, wenn das doch derselbe Rechner ist => 127.0.0.1...

[Otto123]

Mein Vorschlag:

Code Auswählen Erweitern

sudo systemctl disable deconz
System herunterfahren.
Ausschalten, Strom weg, warten.
Starten und schauen was der HMUART macht.

[skuzzy1704]

@Beta-User

Und warum deconz/HUEBridge über externe IP einbinden, wenn das doch derselbe Rechner ist => 127.0.0.1...

Das ist eine gute Frage. Habe ich mir nie Gedanken drum gemacht! Werde ich mal bG anpassen.

Hattest du den service auch neu initialisiert, nachdem du die Datei editiert hattest?

Was heißt initialisiert für dich? Habe den Dienst nur neu gestartet.

@Otto
Wenn das Problem noch einmal auftreten sollte, werde ich diese Vorgehensweise anwenden. Aktuell betrachte ich das Thema als gelöst. Da , wie gesagt, nach Dienst Anpassung, Ausschalten, Strom weg, keine Probleme mehr auftreten.

Vielen Dank für eure Unterstützung!

[Beta-User]

Was heißt initialisiert für dich? Habe den Dienst nur neu gestartet.

Es kommt darauf an, wie du die Datei editiert hast. Die Änderungen werden nur wirksam, wenn sie dem daemon bekannt gemacht werden, was bei einem "normalen" Edit nicht der Fall ist, sondern nur, wenn man den dafür vorgesehenen Editor nutzt. Siehe für den fhem-service hier:
https://wiki.fhem.de/wiki/Fhem.service_(systemd_unit_file)#unit_file_bearbeiten, oder generisch hier: https://wiki.ubuntuusers.de/systemd/Units/#Unit-Datei-editieren-oder-anlegen

[Otto123]

Mist - irgendwie habe ich hier verstanden - es hat nichts gebracht. Schön das es funktioniert.

Das hatte vor den Anpassungen nichts gebracht.