HM-MOD-UART disconnected, waiting to reappear (myHmUART)

[Udomatic]

Das sieht auf die Schnelle gut aus.

Das mit der hmId ist korrekt. Du kannst ruhig das momentan deaktivierte myHmUART auch der VCCU zuordnen.

Das mache ich einfach indem ich dem Attribut IODev in der VCCU beide HMUART zuordne?

Du hast bei allen Geräten IOgrp gesetzt? Siehe Wiki VCCU, Befehlszeile:

Code Auswählen Erweitern

attr TYPE=CUL_HM:FILTER=DEF=[0-9a-fA-F]{6}:FILTER=DEF!=[0]{6} IOgrp VCCU

Ja ist so gesetzt. Warum auch immer gibt es Devices bei denen im Attribut statt nur dem Namen der VCCU diese Kombination steht:
VCCU:myHmUART

Hier ein List eines Devices, wo das so ist

Code Auswählen Erweitern

Attributes:
   .mId       00C7
   IODev      myHmUART
   IOgrp      VCCU:myHmUART
   actCycle   002:50
   actStatus  alive
   alexaName  Balkontür
   autoReadReg 4_reqStatus
   devStateIcon open:tuer_fenster_kontakt_opened@red tilted:tuer_fenster_kontakt_opened@red closed:tuer_fenster_kontakt_closed@green
   expert     2_raw
   firmware   1.0
   genericDeviceType contact
   group      Fensterkontakt
   homebridgeMapping ContactSensorState=state,values=closed:CONTACT_DETECTED;open:CONTACT_NOT_DETECTED
history:size=1024
   icon       hm-sec-win
   model      HM-SEC-SCO
   peerIDs    00000000,63395E03,64AD3603,
   room       Alexa,CUL_HM,Homekit,Lilly
   serialNr   OEQ1980613
   siriName   Lilly Balkontür
   subType    threeStateSensor

Das Attribut IODev eines jeden HM Devices muss ich jetzt händisch anpassen auf das neue?
Oder gibt es da einen Befehl, wie für das setzen des Attributs IOgrp?

[Otto123]

Du solltest einfach den Artikel VCCU im Wiki lesen, da steht alles drin. Vielleicht zuviel

Das attr IODev fasst DU bitte nicht an!

In der der VCCU musst Du das attr IOList entsprechend mit beiden IOs setzen! Komma getrennt! Keine Leerzeichen!

IOgrp      VCCU:myHmUART da wäre der IO myHmUART bevorzugt. Aber wenn nicht da wird auch der andere genommen.

[Udomatic]

Du solltest einfach den Artikel VCCU im Wiki lesen, da steht alles drin. Vielleicht zuviel

Das attr IODev fasst DU bitte nicht an!

In der der VCCU musst Du das attr IOList entsprechend mit beiden IOs setzen! Komma getrennt! Keine Leerzeichen!

IOgrp      VCCU:myHmUART da wäre der IO myHmUART bevorzugt. Aber wenn nicht da wird auch der andere genommen.

Tausend Dank Otto für deine Geduld. Das ist schon großartig, was du hier täglich an Support leistest!

Die Verbindungsprobleme (disconnect / reappear) sind erstmal gestoppt in der jetzigen Konfiguration. Teste dann morgen nach und nach alle Funktion.
Mit einem Fensterkontakt lief soweit alles, wie es sein soll. Auf / Zu Status wurde korrekt erkannt und an FHEM gemeldet.

Habe die VCCU Konfig soweit angepasst. Werde morgen trotzdem noch mal den Artikel ausgeschlafen lesen.

Das war glaube ich heute ein großer Schritt!

[Udomatic]

Hallo Otto,

folgendes kann ich heute morgen festhalten.
- keine disconnect mehr im Log
- Der Action Detector hat alle 34 HM Devices wieder sauber erkannt incl. virtaul Devices
- Die Kommunikation scheint bis jetzt wieder sauber zu funktionieren. Statusänderungen an den Geräten werden schnell und richtig versendet.

Was ich jetzt nicht weiter getestet habe, den störenden HMUART, zusätzlich zu aktivieren. Bin gerade glücklich und zufrieden, dass es wieder so läuft, wie es soll.

Herzlichen Dank an dieser Stelle noch mal für deine Unterstützung.

Gruß
Udo

[Otto123]

Guten Morgen Udo,

na das klingt ja gut. Die Frage ist jetzt wie damit umgehen?
Also scheinbar blockiert das FHEM nicht und verursacht die disconnects, die würden ja bei einer remote anbindung sonst genauso auftreten.
Scheinbar stört irgendwas lokal die serielle Kommunikation.

Eine Anbindung über LAN funktioniert offenbar gut:
1. so lassen auf dem Pi?
2. Ethernet Shield besorgen und HMUART Modul damit verbinden?

Test ob das HMUART Modul an einer USB Schnittstelle lokal funktioniert? Also USB/seriell Wandler besorgen und das HMUART Modul an USB anschließen und Definition ändern.

Gruß Otto

[frank]

@udomatic
hast du eventuell eine "virtuelle ccu" (debmatic, pivccu, ...) auf deinem lokalen pi, so dass der hmuart in fhem immer disconnected?

[Udomatic]

@udomatic
hast du eventuell eine "virtuelle ccu" (debmatic, pivccu, ...) auf deinem lokalen pi, so dass der hmuart in fhem immer disconnected?

Hallo Frank,

ich habe "nur" CUL_HM und eine VCCU definiert, keine piVCCU oder ähnliches. Das hatte alles über ein Jahr super funktioniert.
Ich bekomme leider nicht eingegrenzt, was die disconnects verursacht. War in den letzten Wochen durchgehend in einem Abstand von 3-4 Minuten

Ich hatte einige Zeit Probleme mit meiner Internetleitung und ipv4. Als das behoben war fingen die Probleme an. Sicherlich ein Zufall.
So ziemlich alle Geräte, die ich vor der Problematik neu angelegt hatte sind ebenfalls gelöscht. Hat aber keine Änderung herbei geführt. Das waren Module wie Presence, Homemode, Twilight.

Den mqtt2 Server habe ich gelassen. Der Freezemon hat in die Richtung aber nichts ausgespuckt. Der Freezemon meldet derzeit immer wieder mal bzgl. Sonos Player

Gruß
Udo

[Udomatic]

Guten Morgen Udo,

Eine Anbindung über LAN funktioniert offenbar gut:
1. so lassen auf dem Pi?
2. Ethernet Shield besorgen und HMUART Modul damit verbinden?

Gruß Otto

Ich werds jetzt erstmal so lassen. Der zweite Pi der nun die Funkschnittstelle aktiv hat ist testweise noch mit einem ioBroker bestückt.
Daher wird der Strom nicht nur aufgrund des IODevice verbraucht.

[Udomatic]

Moin,

folgendes ist kurz nach Mitternacht passiert

Code Auswählen Erweitern

SONOSPLAYER_SimulateCurrentTrackPosition(Sonos_Buero)
2020.02.13 22:29:41 1: [Freezemon] myFreezemon: possible freeze starting at 22:29:37, delay is 4.124 possibly caused by: tmr-SONOSPLAYER_SimulateCurrentTrackPosition(Sonos_Buero) tmr-SONOS_IsSubprocessAliveChecker(Sonos)
2020.02.13 22:34:10 1: [Freezemon] myFreezemon: possible freeze starting at 22:34:08, delay is 2.605 possibly caused by: tmr-SONOSPLAYER_SimulateCurrentTrackPosition(Sonos_Buero)
2020.02.13 23:20:44 2: autocreate: renamed FileLog_Tradfri_Taster to FileLog_Taster_Noah
2020.02.13 23:35:24 1: [Freezemon] myFreezemon: possible freeze starting at 23:35:21, delay is 3.069 possibly caused by: tmr-HMUARTLGW_CheckCredits(LAN_HmUART) tmr-SONOSPLAYER_SimulateCurrentTrackPosition(Sonos_Buero)
2020.02.13 23:35:40 1: [Freezemon] myFreezemon: possible freeze starting at 23:35:38, delay is 2.786 possibly caused by: tmr-SONOSPLAYER_SimulateCurrentTrackPosition(Sonos_Buero)
2020.02.13 23:35:56 1: [Freezemon] myFreezemon: possible freeze starting at 23:35:53, delay is 3.149 possibly caused by: tmr-SONOSPLAYER_SimulateCurrentTrackPosition(Sonos_Buero)
2020.02.13 23:36:26 1: [Freezemon] myFreezemon: possible freeze starting at 23:36:24, delay is 2.894 possibly caused by: tmr-SONOSPLAYER_SimulateCurrentTrackPosition(Sonos_Buero)
2020.02.13 23:36:43 1: [Freezemon] myFreezemon: possible freeze starting at 23:36:40, delay is 3.217 possibly caused by: tmr-SONOSPLAYER_SimulateCurrentTrackPosition(Sonos_Buero)
2020.02.13 23:36:58 1: [Freezemon] myFreezemon: possible freeze starting at 23:36:56, delay is 2.459 possibly caused by: tmr-SONOSPLAYER_SimulateCurrentTrackPosition(Sonos_Buero)
2020.02.13 23:37:13 1: [Freezemon] myFreezemon: possible freeze starting at 23:37:11, delay is 2.349 possibly caused by: tmr-SONOSPLAYER_SimulateCurrentTrackPosition(Sonos_Buero)
2020.02.13 23:42:20 1: [Freezemon] myFreezemon: possible freeze starting at 23:42:19, delay is 1.606 possibly caused by: tmr-MQTT2_SERVER_keepaliveChecker(mqtt2s) tmr-SONOSPLAYER_SimulateCurrentTrackPosition(Sonos_Buero)
2020.02.13 23:46:43 1: [Freezemon] myFreezemon: possible freeze starting at 23:46:42, delay is 1.614 possibly caused by: tmr-SONOSPLAYER_SimulateCurrentTrackPosition(Sonos_Buero)
2020.02.13 23:47:00 1: [Freezemon] myFreezemon: possible freeze starting at 23:46:59, delay is 1.143 possibly caused by: tmr-SONOSPLAYER_SimulateCurrentTrackPosition(Sonos_Buero) tmr-echodevice_GetSettings(ECHO_G0014D0594610DNM) tmr-HUEBridge_GetUpdate(deCONZ) tmr-MQTT2_SERVER_keepaliveChecker(mqtt2s)
2020.02.13 23:54:01 1: [Freezemon] myFreezemon: possible freeze starting at 23:54:00, delay is 1.225 possibly caused by: tmr-SONOSPLAYER_SimulateCurrentTrackPosition(Sonos_Buero)
2020.02.14 00:02:09 1: [Freezemon] myFreezemon: possible freeze starting at 00:02:08, delay is 1.102 possibly caused by: tmr-SONOSPLAYER_SimulateCurrentTrackPosition(Sonos_Buero)
2020.02.14 01:14:04 1: [Freezemon] myFreezemon: possible freeze starting at 00:14:05, delay is 3599.015 possibly caused by: tmr-SONOSPLAYER_SimulateCurrentTrackPosition(Sonos_Buero)
2020.02.14 01:14:24 3: mqtt2s: mqtt2s_192.168.178.22_48416/shellyplug-s-040CA2 left us (keepalive check)
2020.02.14 00:14:25 3: mqtt2s: mqtt2s_192.168.178.49_64044/Blitzwolf-BWSHP2-01 left us (keepalive check)
2020.02.14 00:14:25 3: mqtt2s: mqtt2s_192.168.178.32_65336/Blitzwolf-BWSHP2-02 left us (keepalive check)
2020.02.14 00:14:25 3: mqtt2s: mqtt2s_192.168.178.20_62468/shellyplug-s-041439 left us (keepalive check)
2020.02.14 00:14:25 3: mqtt2s: mqtt2s_192.168.178.23_61657/shellyplug-s-7A2FD2 left us (keepalive check)
2020.02.14 00:14:25 3: mqtt2s: mqtt2s_192.168.178.24_48155/shellyswitch25-B89E2D left us (keepalive check)
2020.02.14 00:14:25 1: HMUARTLGW LAN_HmUART did not respond for the 1. time, resending
2020.02.14 00:14:25 1: HMUARTLGW LAN_HmUART did not respond for the 2. time, resending
2020.02.14 00:14:25 1: HMUARTLGW LAN_HmUART did not respond for the 1. time, resending
2020.02.14 00:14:25 1: HMUARTLGW LAN_HmUART did not respond for the 2. time, resending
2020.02.14 00:14:25 1: HMUARTLGW LAN_HmUART did not respond for the 1. time, resending
2020.02.14 00:14:25 1: HMUARTLGW LAN_HmUART did not respond for the 2. time, resending
2020.02.14 00:14:25 1: HMUARTLGW LAN_HmUART did not respond for the 3. time, resending
2020.02.14 00:14:25 1: HMUARTLGW LAN_HmUART did not respond for the 1. time, resending
2020.02.14 00:14:25 1: HMUARTLGW LAN_HmUART did not respond for the 2. time, resending
2020.02.14 00:14:25 1: HMUARTLGW LAN_HmUART did not respond for the 3. time, resending
2020.02.14 00:14:25 1: HMUARTLGW LAN_HmUART did not respond for the 1. time, resending
2020.02.14 00:14:25 1: HMUARTLGW LAN_HmUART did not respond for the 2. time, resending
2020.02.14 00:14:25 1: HMUARTLGW LAN_HmUART did not respond for the 3. time, resending
2020.02.14 00:14:25 1: HMUARTLGW LAN_HmUART did not respond for the 1. time, resending
2020.02.14 00:14:25 1: HMUARTLGW LAN_HmUART did not respond for the 2. time, resending
2020.02.14 00:14:25 1: HMUARTLGW LAN_HmUART did not respond for the 1. time, resending
2020.02.14 00:14:25 1: HMUARTLGW LAN_HmUART did not respond for the 2. time, resending
2020.02.14 00:14:25 1: HMUARTLGW LAN_HmUART did not respond for the 1. time, resending
2020.02.14 00:14:25 1: HMUARTLGW LAN_HmUART did not respond for the 2. time, resending
2020.02.14 00:14:25 1: HMUARTLGW LAN_HmUART did not respond for the 1. time, resending
2020.02.14 00:14:25 1: HMUARTLGW LAN_HmUART did not respond for the 2. time, resending
2020.02.14 00:14:25 1: HMUARTLGW LAN_HmUART did not respond for the 1. time, resending
2020.02.14 00:14:25 1: HMUARTLGW LAN_HmUART did not respond for the 2. time, resending
2020.02.14 00:14:25 1: HMUARTLGW LAN_HmUART did not respond for the 1. time, resending
2020.02.14 00:14:25 1: HMUARTLGW LAN_HmUART did not respond for the 2. time, resending
2020.02.14 00:14:25 1: HMUARTLGW LAN_HmUART did not respond for the 1. time, resending
2020.02.14 00:14:25 1: HMUARTLGW LAN_HmUART did not respond for the 2. time, resending
2020.02.14 00:14:25 1: HMUARTLGW LAN_HmUART did not respond for the 3. time, resending
2020.02.14 00:14:25 1: HMUARTLGW LAN_HmUART did not respond after all, reopening
2020.02.14 00:14:25 3: LAN_HmUART device closed
2020.02.14 00:14:38 1: Timeout for PROPLANTA_Run reached, terminated process 21532
2020.02.14 00:14:47 1: 192.168.178.56:4000 reappeared (LAN_HmUART)

Das führte dazu, dass HM IODevice kurzzeitig nicht verfügbar war und erstmal alle HM Thermostate im Action Detector auf dead standen. Heute morgen alles wieder normal bei HM

Jetzt meine Frage.

Wisst ihr einen Zusammenhang zwischen Sonos oder dem mqtt2 Server?
Deute ich es jetzt richtig, dass nach dem keep alive check auch das IODevice erstmal kurz tot war?
Kann man den Keep Alive Check abstellen?

[Otto123]

Guten Morgen,

es gibt da so eine Sache mit dem DNS Server und blockierenden HTTP Aufrufen. Kurz nach Mitternacht -> Zwangstrennung vom Provider?
Hast Du in global das attribute gesetzt?

dnsServer
Enthält die IP Adresse des DNS Servers. Die von bestimmten Modulen (oder eigenen Code) aufgerufene HttpUtils_NonblockingGet wird auch bei der DNS Auflösung nicht mehr blockieren, falls dieses Attribut gesetzt ist, da es in diesem Fall FHEM eigene Routinen aufgerufen werden. Sonst werden die OS-eigenen, blockierenden Routinen inet_aton bzw gethostbyname aufgerufen.

Gruß Otto

[frank]

ich würde sonos sofort "killen".
1 stunde fhem lahmlegen geht ja gar nicht. auch die anderen regelmässigen freezes würden mich extrem stören.

[Udomatic]

Guten Morgen,

es gibt da so eine Sache mit dem DNS Server und blockierenden HTTP Aufrufen. Kurz nach Mitternacht -> Zwangstrennung vom Provider?
Hast Du in global das attribute gesetzt?
Gruß Otto

@Frank:
Die Meldungen vor Mitternacht hatten keine spürbare Auswirkung. Habe ich jetzt eher als Log Hinweis aufgenommen. Also FHEM hing nicht 1 Stunde lang.
Aber um 00:14 war plötzlich Sonos weg, die Musik ging aus und HMUARTLGW war kurz disconnected

@Otto:
Eine Zwangstrennung beim Provider habe ich nicht. Ich bin bei Unitymeda und hatte in der Vergangenheit einen DS-Lite Anschluss was gegen Ende des letzten Jahres zu langen und nervenden Internet / DNS Problemen führte. Als ich dann raffte was DS-Lite bedeutet habe ich meinen Anschluss auf DS umstellen lassen und habe seither ein feste ipv4 Adresse und keine Internet Probleme mehr. Gefühlt seitdem habe ich aber die FHEM Probleme.

HttpUtils habe ich in der Hue Bridge und deConz gesetzt, aber nicht im Device global. Wenn ich es global setze kann / muss ich das Attribut lokal in der Hue Bridge und deConz löschen?

[Otto123]

Naja es gibt immer wieder die Empfehlung das

Code Auswählen Erweitern

attr global dnsServer auf die interne IP Adresse des Routers zu setzen. Der übernimmt normalerweise die DNS Abfrage ...

[Udomatic]

HttpUtils_NonblockingGet

Dieses Attribut habe ich bisher nicht gesetzt. Welche Auswirkungen hat es das zu setzen? Setzt man es im Global Device?

DNS macht die FritzBox und der Raspberry hat eine feste IP.

[Otto123]

Die Antwort steht doch schon in #54 ?