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

Begonnen von Udomatic, 28 Januar 2020, 08:47:25

Vorheriges Thema - Nächstes Thema

Udomatic

Hallo,

ich habe leider immer noch seit einigen Wochen Probleme mit dem Homematic Funkmodul. Das Log wird vollgeschrieben mit.

2020.01.28 08:41:46 1: /dev/ttyAMA0 disconnected, waiting to reappear (myHmUART)
2020.01.28 08:41:51 3: Setting myHmUART serial parameters to 115200,8,N,1
2020.01.28 08:41:51 1: /dev/ttyAMA0 reappeared (myHmUART)


Dementsprechend werden Funkbefehle wohl unsauber verarbeitet oder gar nicht. Zum Beispiel wird nicht erkannt, wenn das Fenster geöffnet wird oder auch geschlossen.

Hatte das Modul mal ausgebaut und geprüft. Nach dem Einbau funktionierte es dann vermeintlich.

Habe noch einen zweiten Pi mit HM Funkmodul da. Wenn ich jetzt die SD Karte in den zweiten Pi rein schiebe, müsste ich das Funkmodul, wie bei Neuinstallation initialisieren?

Ein Update Problem ist es scheinbar ja nicht, da sich sonst keiner gemeldet hat.

Was soll ich am Besten tun?

Gruß
Udo
2x Raspberry 3B+, 1x Raspberry 4, Signalduino 433 (Somfy), CUL_HM (HM-MOD-RPI-PCB), MQTT, Hue, ConBee 2, Sonos, AVM DECT, Netatmo, eufy, Nuki,

Udomatic

Hallo,

nachdem ich das Netzteil als Fehler vermute habe, habe ich dieses getauscht. Leider bleibt der Fehler der gleiche. Also vermute ich immer noch, dass das Funkmodul einen Schaden hat.
Ich habe hier zu Hause noch einen zweiten Pi 3b+ mit baugleichem HM Funkmodul. Kann ich zum Testen einfach die SD Karte im zweiten Backup Pi hochfahren?
Die hmid des Funkmoduls müsste ich sicherlich auf die ID des neuen Moduls ändern?

Fällt euch sonst noch etwas ein, was man beachten / anpassen muss?

Gruß
Udo
2x Raspberry 3B+, 1x Raspberry 4, Signalduino 433 (Somfy), CUL_HM (HM-MOD-RPI-PCB), MQTT, Hue, ConBee 2, Sonos, AVM DECT, Netatmo, eufy, Nuki,

Otto123

Hallo Udo,

Du kannst doch das Funkmodul einfach mal umstecken?

Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

Udomatic

Zitat von: Otto123 am 28 Januar 2020, 20:11:59
Hallo Udo,

Du kannst doch das Funkmodul einfach mal umstecken?

Gruß Otto

Im Moment sehen die Readings so aus:
READINGS:
     2020-01-28 20:44:12   D-HMIdAssigned  6A60EA
     2020-01-28 20:44:12   D-HMIdOriginal  6A60EA
     2020-01-28 21:09:02   D-firmware      unsupported
     2020-01-28 20:44:13   D-serialNr      PEQ0531167
     2020-01-28 20:45:44   D-type          HM-MOD-UART
     2020-01-28 21:09:02   cond            unsupported firmware
     2020-01-28 20:44:13   load            0
     2020-01-28 20:45:44   loadLvl         suspended
     2020-01-28 21:09:01   state           opened


Muss ich das Funkmodul dann neu definieren?
2x Raspberry 3B+, 1x Raspberry 4, Signalduino 433 (Somfy), CUL_HM (HM-MOD-RPI-PCB), MQTT, Hue, ConBee 2, Sonos, AVM DECT, Netatmo, eufy, Nuki,

Otto123

Nein.

Das sieht komisch aus:
2020-01-28 21:09:02   D-firmware      unsupported

Ist das wirklich ein HM-MOD-UART ?
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

Udomatic

#5
Zitat von: Otto123 am 28 Januar 2020, 21:31:34
Nein.

Das sieht komisch aus:
2020-01-28 21:09:02   D-firmware      unsupported

Ist das wirklich ein HM-MOD-UART ?

Ja, ein HM-MOD-RPI-PCB

Sollte ich nicht eine neue hmid sehen, weil es ein anderes Funkmodul ist?

Hab noch mal die Firmware geflasht. Jetzt wechselt das Teil von ständig von init auf disconnected

2020.01.28 21:31:54 1: HMUARTLGW myHmUART application switch failed, application-firmware probably corrupted!
2020.01.28 21:31:54 3: myHmUART device closed
2020.01.28 21:31:54 3: Setting myHmUART serial parameters to 115200,8,N,1
2020.01.28 21:31:54 1: /dev/ttyAMA0 reappeared (myHmUART)
2x Raspberry 3B+, 1x Raspberry 4, Signalduino 433 (Somfy), CUL_HM (HM-MOD-RPI-PCB), MQTT, Hue, ConBee 2, Sonos, AVM DECT, Netatmo, eufy, Nuki,

Otto123

Also  das gleiche Verhalten wie mit dem anderen Modul? Dann ist es nicht das Modul sondern die Schnittstelle ist nicht frei. Alles wie im Wiki beschrieben gemacht?
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

Udomatic

#7
Zitat von: Otto123 am 28 Januar 2020, 21:36:40
Also  das gleiche Verhalten wie mit dem anderen Modul? Dann ist es nicht das Modul sondern die Schnittstelle ist nicht frei. Alles wie im Wiki beschrieben gemacht?

Warum auch immer hat in der Boot Config folgender Eintrag gefehlt:
core_freq=250

Habe ich nachgeholt und einen reboot gemacht. Läuft immer noch nicht obwohl ich die Besteätigung laut Wiki habe, dass die Schnittstelle sauber konfiguriert ist

pi@raspberrypi:~ $ ls -l /dev/ttyAMA0
crw-rw---- 1 root dialout 204, 64 Jan 28 21:46 /dev/ttyAMA0
pi@raspberrypi:~ $ ls -l /dev/serial*
lrwxrwxrwx 1 root root  7 Jan 28 21:44 /dev/serial0 -> ttyAMA0
lrwxrwxrwx 1 root root  5 Jan 28 21:44 /dev/serial1 -> ttyS0


Ich habe noch eine VCCU. Ändert das große etwas am Thema?
2x Raspberry 3B+, 1x Raspberry 4, Signalduino 433 (Somfy), CUL_HM (HM-MOD-RPI-PCB), MQTT, Hue, ConBee 2, Sonos, AVM DECT, Netatmo, eufy, Nuki,

Otto123

Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

Udomatic

Zitat von: Otto123 am 28 Januar 2020, 21:57:01
es muss - ohne "
core_freq=250

JA, das war jetzt ein copy / paste Fehler. Steht ohne " in der boot config.
2x Raspberry 3B+, 1x Raspberry 4, Signalduino 433 (Somfy), CUL_HM (HM-MOD-RPI-PCB), MQTT, Hue, ConBee 2, Sonos, AVM DECT, Netatmo, eufy, Nuki,

Otto123

kannst Du mal bitte ein aktuelles list myHmUART posten?
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

Udomatic

Zitat von: Otto123 am 28 Januar 2020, 22:12:03
kannst Du mal bitte ein aktuelles list myHmUART posten?

Mach ich gleich Otto. Aufgrund dieser Fehlermeldung probiere ich gerade erneut zu flashen anhand deines Blog Artikels:
http://heinz-otto.blogspot.com/2016/07/raspberry-pi-homematic-modul.html

Jetzt hängt das ganze hier:

_update.eq3
Auflösen des Hostnamens »raw.githubusercontent.com (raw.githubusercontent.com)« ... 151.101.12.133
Verbindungsaufbau zu raw.githubusercontent.com (raw.githubusercontent.com)|151.101.12.133|:443 ... verbunden.
HTTP-Anforderung gesendet, auf Antwort wird gewartet ... 200 OK
Länge: 88408 (86K) [text/plain]
Wird in »»coprocessor_update.eq3«« gespeichert.

coprocessor_update.eq3              100%[=================================================================>]  86,34K  --.-KB/s    in 0,02s   

2020-01-28 22:07:05 (3,44 MB/s) - »»coprocessor_update.eq3«« gespeichert [88408/88408]

root@raspberrypi:/home/pi/hmcfgusb# ./flash-hmmoduart -U /dev/ttyAMA0 coprocessor_update.eq3
HM-MOD-UART flasher version 0.103-git

Reading firmware from coprocessor_update.eq3...
Firmware with 43 blocks successfully read.

Initializing HM-MOD-UART...
HM-MOD-UART opened.

Flashing 43 blocks: |     


Wie lange dauert die Geschichte? Kommt da noch was?
2x Raspberry 3B+, 1x Raspberry 4, Signalduino 433 (Somfy), CUL_HM (HM-MOD-RPI-PCB), MQTT, Hue, ConBee 2, Sonos, AVM DECT, Netatmo, eufy, Nuki,

Udomatic

So sieht das List derzeit aus:

Internals:
   CNT        2
   Clients    :CUL_HM:
   DEF        /dev/ttyAMA0
   DEVCNT     2
   DevState   0
   DevType    UART
   DeviceName /dev/ttyAMA0@115200
   FUUID      5e30a0b2-f33f-45fc-42b5-0121b0bdfa26b41f
   LastOpen   1580246381.06528
   NAME       myHmUART
   NOTIFYDEV  global
   NR         473
   NTFY_ORDER 50-myHmUART
   PARTIAL   
   RAWMSG     0400
   STATE      opened
   TYPE       HMUARTLGW
   XmitOpen   0
   model      HM-MOD-UART
   .attraggr:
   .attreocr:
     .*
   .attrminint:
   Helper:
     AckPending:
     LastSendLen:
       3
       3
     Log:
       IDs:
     RoundTrip:
   MatchList:
     1:CUL_HM   ^A......................
   PeerQueue:
     HASH(0x536f388)
     HASH(0x505bef8)
     HASH(0x53a1520)
     HASH(0x53ff128)
     HASH(0x53f0d00)
     HASH(0x53dd2b0)
     HASH(0x5060090)
     HASH(0x53a3410)
     HASH(0x53a13d0)
     HASH(0x53c63c0)
     HASH(0x54071b8)
     HASH(0x5407098)
     HASH(0x54074a0)
     HASH(0x53f0b80)
     HASH(0x53739e0)
     HASH(0x5407680)
     HASH(0x5407e90)
     HASH(0x53f0cb8)
     HASH(0x53700c0)
     HASH(0x53ff818)
     HASH(0x540b7c0)
     HASH(0x5408660)
     HASH(0x53ff908)
     HASH(0x540bda8)
     HASH(0x1af6e48)
     HASH(0x5411318)
     HASH(0x53a76f8)
     HASH(0x505c0a8)
     HASH(0x5410880)
     HASH(0x5410748)
     HASH(0x54085d0)
     HASH(0x53a7740)
     HASH(0x5417348)
     HASH(0x5410e50)
     HASH(0x54129b8)
     HASH(0x540ba18)
     HASH(0x5412e80)
     HASH(0x536f898)
     HASH(0x540b568)
     HASH(0x541f358)
     HASH(0x5417780)
     HASH(0x540d7a8)
     HASH(0x4a08360)
     HASH(0x42a9d08)
     HASH(0x42ab380)
     HASH(0x42a94f8)
     HASH(0x42a8e80)
     HASH(0x505b7d8)
     HASH(0x4faeb88)
     HASH(0x505bbf8)
     HASH(0x4faec30)
     HASH(0x4d03e60)
     HASH(0x42a8f88)
     HASH(0x428d3c0)
     HASH(0x408f828)
     HASH(0x422a2e0)
     HASH(0x422ab98)
     HASH(0x422aa48)
     HASH(0x422a7d8)
     HASH(0x422a580)
     HASH(0x4229b70)
     HASH(0x4229f60)
     HASH(0x422a098)
     HASH(0x3b30588)
     HASH(0x4229810)
     HASH(0x4229948)
     HASH(0x40f6ad8)
     HASH(0x3ed04f0)
     HASH(0x42a8100)
     HASH(0x42a8e50)
     HASH(0x42a8028)
     HASH(0x42a5160)
     HASH(0x42a7d28)
     HASH(0x42a24f8)
     HASH(0x42a1e80)
     HASH(0x42a21f8)
     HASH(0x42a1da8)
     HASH(0x3bc8a70)
     HASH(0x3bc8ab8)
     HASH(0x3bc80b0)
     HASH(0x3bc83e0)
     HASH(0x3bc83c8)
     HASH(0x3bc8260)
     HASH(0x3bbcef8)
   Peers:
     361649     pending
     56257F     pending
     5947DC     pending
     594C6E     pending
     594D83     pending
     59540F     pending
     5959AD     pending
     5D3DE9     pending
     5D41A1     pending
     628D91     pending
     633924     pending
     633926     pending
     63395E     pending
     633964     pending
     633A87     pending
     6359A7     pending
     63A606     pending
     63AB1F     pending
     63AB56     pending
     63AB74     pending
     63AB7A     pending
     63AB99     pending
     64AD36     pending
     64CBA3     pending
     64CBB3     pending
     64CBD5     pending
     654BE7     pending
     654D47     pending
     654DB7     pending
     6644DC     pending
     6738DA     pending
     674082     pending
     6740B4     pending
     674137     pending
     69CFB8     pending
     6A1ECE     pending
     6A1ED2     pending
     6A1EE5     pending
     6A1EFD     pending
     6B6F56     pending
     6C483E     pending
     6CD39F     pending
   READINGS:
     2020-01-28 22:19:20   D-type          HM-MOD-UART
     2020-01-28 22:19:45   cond            disconnected
     2020-01-28 22:19:20   loadLvl         suspended
     2020-01-28 22:19:41   state           opened
   helper:
Attributes:
   event-on-change-reading .*
   hmId       0000a1
   room       CUL_HM
2x Raspberry 3B+, 1x Raspberry 4, Signalduino 433 (Somfy), CUL_HM (HM-MOD-RPI-PCB), MQTT, Hue, ConBee 2, Sonos, AVM DECT, Netatmo, eufy, Nuki,

Otto123

Wenn Du das Modul nicht gescheit mit der Schnittstelle verbunden hast (warum auch immer) weil
Ein unklarer Fehler ist
Das Modul kaputt ist
Die Schnittstelle nicht frei ist

Macht doch Modul flashen überhaupt keinen Sinn!?! Wozu diese Aktion? Wir vermuten Du kannst nicht mit dem Modul kommunizieren und Du versuchst zu flashen. Denkst Du fürs flashen gibt es einen Voodoo Zauber  ;D ;D ;D


Für meine Begriffe steht da zwar viel drin in dem list, das heisst für mich irgendwas ist das passiert, aber nach sinnvoller Kommunikation sieht das nicht aus.
ZitatHabe noch einen zweiten Pi mit HM Funkmodul da.
Dieser Pi funktioniert mit HMUART Modul?
Was ist jetzt das erste Ziel dieser Aktion? Ich dachte wir wollten prüfen ob das Modul intakt ist. An dem pi von dem Du das list zeigst, sag ich, ist nichts intakt.

Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

Udomatic

Zitat von: Otto123 am 28 Januar 2020, 22:54:56
Wenn Du das Modul nicht gescheit mit der Schnittstelle verbunden hast (warum auch immer) weil
Ein unklarer Fehler ist
Das Modul kaputt ist
Die Schnittstelle nicht frei ist

Macht doch Modul flashen überhaupt keinen Sinn!?! Wozu diese Aktion? Wir vermuten Du kannst nicht mit dem Modul kommunizieren und Du versuchst zu flashen. Denkst Du fürs flashen gibt es einen Voodoo Zauber  ;D ;D ;D


Für meine Begriffe steht da zwar viel drin in dem list, das heisst für mich irgendwas ist das passiert, aber nach sinnvoller Kommunikation sieht das nicht aus. Dieser Pi funktioniert mit HMUART Modul?
Was ist jetzt das erste Ziel dieser Aktion? Ich dachte wir wollten prüfen ob das Modul intakt ist. An dem pi von dem Du das list zeigst, sag ich, ist nichts intakt.

Gruß Otto

Sorry Otto, aber ich bin doch deinem Vorschlag gefolgt und habe aus meinem Backup Pi das Funkmodul in meinem produktiven Pi gesetzt. Dann schrieb ich dir die Meldung ist die gleiche und deine Antwort war dann liegt es nicht am Funkmodul. Daraufhin habe ich den Error aus dem Log bzgl. Flash in Angriff genommen und probiert erneut zu flashen.
Ok, war sinnfrei, wenn die Kommunikation nicht sauber klappt.

Inzwischen bin ich wieder bei meinem Produktiv Pi mit Funkmodul des Produktiv PI.

So schaut das List aus

Internals:
   AssignedPeerCnt 42
   CNT        122
   Clients    :CUL_HM:
   DEF        /dev/ttyAMA0
   DEVCNT     41
   DevState   99
   DevType    UART
   DeviceName /dev/ttyAMA0@115200
   FD         104
   FUUID      5e30a0b2-f33f-45fc-42b5-0121b0bdfa26b41f
   LastOpen   1580249422.12202
   NAME       myHmUART
   NOTIFYDEV  global
   NR         473
   NTFY_ORDER 50-myHmUART
   PARTIAL   
   RAWMSG     05000035DD847064CBD500000000D03F
   RSSI       -53
   STATE      opened
   TYPE       HMUARTLGW
   XmitOpen   1
   model      HM-MOD-UART
   msgLoadCurrent 0
   msgLoadHistory -/-/-/-/-/-/-/-/-/-/-/-
   msgLoadHistoryAbs 0/-/-/-/-/-/-/-/-/-/-/-/-
   owner      6A60EA
   .attraggr:
   .attreocr:
     .*
   .attrminint:
   .clientArray:
     CUL_HM
   Helper:
     CreditTimer 22
     FW         66561
     Initialized 1
     AckPending:
       103:
         cmd        08
         dst        0
         frame      FD0003006708CA35
         time       1580249456.68915
       104:
         cmd        08
         dst        0
         frame      FD0003006808E835
         time       1580249460.69573
       106:
         cmd        08
         dst        0
         frame      FD0003006A086436
         time       1580249479.70469
       108:
         cmd        08
         dst        0
         frame      FD0003006C087036
         time       1580249498.73484
       109:
         cmd        08
         dst        0
         frame      FD0003006D08F635
         time       1580249502.73921
       111:
         cmd        08
         dst        0
         frame      FD0003006F087A36
         time       1580249521.74893
       112:
         cmd        08
         dst        0
         frame      FD0003007008B835
         time       1580249525.75319
       114:
         cmd        08
         dst        0
         frame      FD00030072083436
         time       1580249544.76089
       116:
         cmd        08
         dst        0
         frame      FD00030074082036
         time       1580249563.77091
       118:
         cmd        08
         dst        0
         frame      FD0003007608AC35
         time       1580249582.80178
       119:
         cmd        08
         dst        0
         frame      FD00030077082A36
         time       1580249586.80708
       121:
         cmd        08
         dst        0
         frame      FD00030079088E35
         time       1580249605.81616
     LastSendLen:
       3
       3
     Log:
       IDs:
     RoundTrip:
       Delay      0.00307106971740723
     loadLvl:
       lastHistory 1580249425.65545
   MatchList:
     1:CUL_HM   ^A......................
   Peers:
     361649     +361649,00,00,00
     56257F     +56257F,00,00,00
     5947DC     +5947DC,00,00,00
     594C6E     +594C6E,00,00,00
     594D83     +594D83,00,00,00
     59540F     +59540F,00,00,00
     5959AD     +5959AD,00,00,00
     5D3DE9     +5D3DE9,00,00,00
     5D41A1     +5D41A1,00,00,00
     628D91     +628D91,00,00,00
     633924     +633924,00,00,00
     633926     +633926,00,00,00
     63395E     +63395E,00,00,00
     633964     +633964,00,00,00
     633A87     +633A87,00,00,00
     6359A7     +6359A7,00,00,00
     63A606     +63A606,00,00,00
     63AB1F     +63AB1F,00,00,00
     63AB56     +63AB56,00,00,00
     63AB74     +63AB74,00,00,00
     63AB7A     +63AB7A,00,00,00
     63AB99     +63AB99,00,00,00
     64AD36     +64AD36,00,00,00
     64CBA3     +64CBA3,00,00,00
     64CBB3     +64CBB3,00,00,00
     64CBD5     +64CBD5,00,00,00
     654BE7     +654BE7,00,00,00
     654D47     +654D47,00,00,00
     654DB7     +654DB7,00,00,00
     6644DC     +6644DC,00,00,00
     6738DA     +6738DA,00,00,00
     674082     +674082,00,00,00
     6740B4     +6740B4,00,00,00
     674137     +674137,00,00,00
     69CFB8     +69CFB8,00,00,00
     6A1ECE     +6A1ECE,00,00,00
     6A1ED2     +6A1ED2,00,00,00
     6A1EE5     +6A1EE5,00,00,00
     6A1EFD     +6A1EFD,00,00,00
     6B6F56     +6B6F56,00,00,00
     6C483E     +6C483E,00,00,00
     6CD39F     +6CD39F,00,00,00
   READINGS:
     2020-01-28 23:10:25   D-HMIdAssigned  6A60EA
     2020-01-28 23:10:25   D-HMIdOriginal  6A60EA
     2020-01-28 23:10:25   D-firmware      1.4.1
     2020-01-28 23:10:25   D-serialNr      PEQ0531167
     2020-01-28 22:53:30   D-type          HM-MOD-UART
     2020-01-28 23:10:25   cond            ok
     2020-01-28 23:10:25   load            0
     2020-01-28 23:10:25   loadLvl         low
     2020-01-28 23:10:22   state           opened
   helper:
Attributes:
   event-on-change-reading .*
   hmId       6A60EA
   room       CUL_HM


Die Meldung im Log ist natürlich noch da, auch wenn im List gerade "cond" auf "ok" steht

2020.01.28 23:10:16 1: /dev/ttyAMA0 disconnected, waiting to reappear (myHmUART)
2020.01.28 23:10:22 3: Setting myHmUART serial parameters to 115200,8,N,1
2020.01.28 23:10:22 1: /dev/ttyAMA0 reappeared (myHmUART)
2x Raspberry 3B+, 1x Raspberry 4, Signalduino 433 (Somfy), CUL_HM (HM-MOD-RPI-PCB), MQTT, Hue, ConBee 2, Sonos, AVM DECT, Netatmo, eufy, Nuki,

Otto123

Sorry aber jetzt hast Du mich vollends verwirrt. Ich weiß jetzt nicht mehr welches Modul wo und welcher Fehler wo ist.
Ich meine jetzt verstanden zu haben:
Auf deinem produktiven Pi hast du prinzipiell Funktion mit beiden HMUART Modulen, aber ab und zu im Log den disconnect. Richtig? Wie oft ist der disconnect?
Auf dem Ersatz Pi läuft überhaupt nichts? Wieder mit beiden Modulen? Deine ganzen letzten (außer der allerletzte) lists waren von dem Ersatz Pi wo meiner Meinung nach gar nichts geht?

Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

Udomatic

#16
Zitat von: Otto123 am 28 Januar 2020, 23:27:58
Sorry aber jetzt hast Du mich vollends verwirrt. Ich weiß jetzt nicht mehr welches Modul wo und welcher Fehler wo ist.

Das war nicht die Intention. Ich weiß deine Unterstützung zu schätzen!

Zitat von: Otto123 am 28 Januar 2020, 23:27:58
Ich meine jetzt verstanden zu haben:
Auf deinem produktiven Pi hast du prinzipiell Funktion mit beiden HMUART Modulen, aber ab und zu im Log den disconnect. Richtig? Wie oft ist der disconnect?

Auf dem produktiven Pi funktioniert das bisherige HMUART in Verbindung mit den disconnect Fehlern. Die kommen ca. alle 3-4 Minuten. Der allerletzte List ist davon.

Mit dem Backup Funkmodul aus dem Backup PI ging nichts im produktiven Pi. Daher rührte das List, wo du sagtest da geht gar nichts.
Aus diesem Grund habe ich wieder zurück gebaut. Obwohl das Funkmodul aus dem Backup Pi auch auf der Firmware Version 1.4.1 lief wurde das im produktiven System nicht erkannt!
Deshalb der Schnellschuss noch mal ein Firmware Update drüber zu bügeln.

Zitat von: Otto123 am 28 Januar 2020, 23:27:58
Auf dem Ersatz Pi läuft überhaupt nichts? Wieder mit beiden Modulen? Deine ganzen letzten (außer der allerletzte) lists waren von dem Ersatz Pi wo meiner Meinung nach gar nichts geht?
Gruß Otto

Vom Backup Pi habe ich dir kein List gesendet. Wie oben erwähnt habe ich lediglich das Funkmodul aus dem Backup Pi im produktiven getestet, was zu einem schlechteren Ergebnis führte bzw. wieder zu disconnects.
2x Raspberry 3B+, 1x Raspberry 4, Signalduino 433 (Somfy), CUL_HM (HM-MOD-RPI-PCB), MQTT, Hue, ConBee 2, Sonos, AVM DECT, Netatmo, eufy, Nuki,

Otto123

ZitatAus diesem Grund habe ich wieder zurück gebaut. Obwohl das Funkmodul aus dem Backup Pi auch auf der Firmware Version 1.4.1 lief wurde das im produktiven System nicht erkannt!
Du hast aber schon den Pi zum Umstecken ausgeschaltet? Wenn ja, wäre ja das zweite Modul defekt?

Dann könntest Du, ich glaube das war deine ursprüngliche Intension, den Pi "testen". Also alles aus dem produktiven Pi in den Backup Pi bauen und sehen ob es läuft?!
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

andies

Wie ist denn das Modul mit dem Pi verbunden: USB oder GPIO? Stimmen dort dann Adresse sowie Baudrate?


Gesendet von iPhone mit Tapatalk Pro
FHEM 6.1 auf RaspPi3 (Raspbian:  6.1.21-v8+; Perl: v5.32.1)
SIGNALduino (433 MHz) und HM-UART (868 MHz), Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

Otto123

GPIO und stimmt (Gestern um 23:14:03):
ZitatDeviceName /dev/ttyAMA0@115200
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

tndx

Zitat von: Otto123 am 28 Januar 2020, 21:31:34
Das sieht komisch aus:
2020-01-28 21:09:02   D-firmware      unsupported

Ist das wirklich ein HM-MOD-UART ?

Nur zur Info, die Meldung kommt, wenn auf dem Modul die Firmware-Version > 1.4.1 ist, die auch HMIP kann und wohl nicht abwärtskompatibel ist. RaspberryMatic flasht z.B. ohne Rückfrage die zur Zeit aktuelle Version 2.8.6 und macht das Funkmodul unbrauchbar für FHEM. Das kann aber aus FHEM heraus wieder auf 1.4.1 geflasht werden und wechselt nicht deswegen ständig zw. "reappeared" und "disapperead".

Udomatic

#21
Sorry für die späte Antwort, aber ich wurde von einemVirus lahm gelegt, es ist nicht der Corona Virus.

Zitat von: tndx am 29 Januar 2020, 13:46:52
Nur zur Info, die Meldung kommt, wenn auf dem Modul die Firmware-Version > 1.4.1 ist, die auch HMIP kann und wohl nicht abwärtskompatibel ist. RaspberryMatic flasht z.B. ohne Rückfrage die zur Zeit aktuelle Version 2.8.6 und macht das Funkmodul unbrauchbar für FHEM. Das kann aber aus FHEM heraus wieder auf 1.4.1 geflasht werden und wechselt nicht deswegen ständig zw. "reappeared" und "disapperead".

Die Antwort liefert jetzt wohl den Trugschluss. Hier zusammenfassend die Historie:

- Meinen Backup Raspberry, den ich als Testsystem verwende, habe ich über Ebay als fertiges System mit HM-Funkmodul und einer Raspberrymatic Installation neu gekauft.
- Allerdings habe ich Rasoberymatic nie getestet. Wollte ich mir aufheben, wenn ich mehr Zeit habe.
- Also habe ich die microSD Karte ausgebaut und weggelegt und eine neue leere microSD Karte mit FHEM bespielt.
- Allerdings habe ich in meinem Testsystem noch kein HMUARTLGW Modul installiert!
- Trotzdem bin ich davon ausgegangen, dass das myHMUART Funkmodul durch Raspberrrymatic auf die FW 1.4.1 geflasht wurde.

Dann stieg Otto in das Thema ein

- Sein Tipp das Funkmodul umzustecken habe ich gemacht
- Dann kam die unsupported message im Log
- Daraufhin dachte ich OK einfach schnell noch mal flashen, weil das Funkmodul scheinbar dich eine andere FW Version hat.
- Das wiederum hat nicht funktioniert mit den Standard wegen sonst hätte das Modul erkannt werden müssen, schließe ich daraus??

Meine Frage ist also, wie ich das Funkmodul flashen muss, welches unter einem Raspberrymatic initial geflasht wurde damit es in meinem Produktivsystem direkt läuft?
Ist das eine spezielle Vorgehensweise?

Update: Flashen auf FW 1.4.1. in meinem Backup System hat jetzt soweit geklappt. Readings und Log sehen gut aus.

list myHMUART Backup System

Internals:
   AssignedPeerCnt 0
   CFGFN     
   CNT        76
   Clients    :CUL_HM:
   DEF        /dev/ttyAMA0
   DEVCNT     42
   DevState   99
   DevType    UART
   DeviceName /dev/ttyAMA0@115200
   FD         7
   FUUID      5e352130-f33f-f547-0cc5-738e7816848e3f39
   LastOpen   1580540492.77229
   NAME       myHmUART
   NOTIFYDEV  global
   NR         38
   NTFY_ORDER 50-myHmUART
   PARTIAL   
   RAWMSG     050000399D861064AD360000000AA8C90B6400
   RSSI       -57
   STATE      opened
   TYPE       HMUARTLGW
   XmitOpen   1
   model      HM-MOD-UART
   msgLoadCurrent 0
   msgLoadHistory -/-/-/-/-/-/-/-/-/-/-/-
   msgLoadHistoryAbs 0/-/-/-/-/-/-/-/-/-/-/-/-
   owner      424242
   Helper:
     CreditTimer 17
     FW         66561
     Initialized 1
     AckPending:
     LastSendLen:
       3
       3
     Log:
       IDs:
     RoundTrip:
       Delay      0.00313305854797363
     loadLvl:
       lastHistory 1580540520.07151
   MatchList:
     1:CUL_HM   ^A......................
   Peers:
   READINGS:
     2020-02-01 07:02:00   D-HMIdAssigned  424242
     2020-02-01 07:02:00   D-HMIdOriginal  6BD774
     2020-02-01 07:02:00   D-firmware      1.4.1
     2020-02-01 07:02:00   D-serialNr      PEQ2214443
     2020-02-01 06:56:48   D-type          HM-MOD-UART
     2020-02-01 07:02:00   cond            ok
     2020-02-01 07:02:00   load            0
     2020-02-01 07:02:00   loadLvl         low
     2020-02-01 07:01:32   state           opened
Attributes:
   hmId       424242
   room       CUL_HM


Bau ich dann später in den produktiven PI ein. Jetzt rufen gerade die Kids...

Muss man eigentlich etwas an der hmid ändern / anpassen? hmid in produktiv und Backup System sind unterschiedlich?

Als merkt sich das Funkmodul das und muss ich dann im produktiven System die hmid anpassen?

Update: Umstecken des Funkmoduls vom Backup System in das produktive System

list sieht erstmal normal aus oder?

Internals:
   AssignedPeerCnt 42
   CNT        118
   Clients    :CUL_HM:
   DEF        /dev/ttyAMA0
   DEVCNT     118
   DevState   99
   DevType    UART
   DeviceName /dev/ttyAMA0@115200
   FD         101
   FUUID      5e30a0b2-f33f-45fc-42b5-0121b0bdfa26b41f
   LastOpen   1580553160.13766
   NAME       myHmUART
   NOTIFYDEV  global
   NR         473
   NTFY_ORDER 50-myHmUART
   PARTIAL   
   RAWMSG     04020C
   RSSI       -73
   STATE      opened
   TYPE       HMUARTLGW
   XmitOpen   1
   model      HM-MOD-UART
   msgLoadCurrent 6
   msgLoadHistory -/-/-/-/-/-/-/-/-/-/-/-
   msgLoadHistoryAbs 0/-/-/-/-/-/-/-/-/-/-/-/-
   owner      6A60EA
   owner_CCU  VCCU
   .attraggr:
   .attreocr:
     .*
   .attrminint:
   .clientArray:
     CUL_HM
   Helper:
     CreditTimer 16
     FW         66561
     Initialized 1
     SendCnt    2
     AckPending:
       102:
         cmd        08
         dst        0
         frame      FD00030066084C36
         time       1580553179.75158
       104:
         cmd        08
         dst        0
         frame      FD0003006808E835
         time       1580553198.76013
       105:
         cmd        08
         dst        0
         frame      FD00030069086E36
         time       1580553202.76633
       109:
         cmd        08
         dst        0
         frame      FD0003006D08F635
         time       1580553221.77641
       111:
         cmd        08
         dst        0
         frame      FD0003006F087A36
         time       1580553240.78694
       112:
         cmd        08
         dst        0
         frame      FD0003007008B835
         time       1580553244.79409
       114:
         cmd        08
         dst        0
         frame      FD00030072083436
         time       1580553263.80246
       116:
         cmd        08
         dst        0
         frame      FD00030074082036
         time       1580553282.81267
       117:
         cmd        08
         dst        0
         frame      FD0003007508A635
         time       1580553286.81848
     LastSendLen:
       3
       3
     Log:
       IDs:
     PendingCMD:
     RoundTrip:
       Delay      0.00320696830749512
     loadLvl:
       lastHistory 1580553163.7201
   MatchList:
     1:CUL_HM   ^A......................
   Peers:
     361649     +361649,00,00,00
     56257F     +56257F,00,00,00
     5947DC     +5947DC,00,00,00
     594C6E     +594C6E,00,00,00
     594D83     +594D83,00,00,00
     59540F     +59540F,00,00,00
     5959AD     +5959AD,00,00,00
     5D3DE9     +5D3DE9,00,00,00
     5D41A1     +5D41A1,00,00,00
     628D91     +628D91,00,00,00
     633924     +633924,00,00,00
     633926     +633926,00,00,00
     63395E     +63395E,00,00,00
     633964     +633964,00,00,00
     633A87     +633A87,00,00,00
     6359A7     +6359A7,00,00,00
     63A606     +63A606,00,00,00
     63AB1F     +63AB1F,00,00,00
     63AB56     +63AB56,00,00,00
     63AB74     +63AB74,00,00,00
     63AB7A     +63AB7A,00,00,00
     63AB99     +63AB99,00,00,00
     64AD36     +64AD36,00,00,00
     64CBA3     +64CBA3,00,00,00
     64CBB3     +64CBB3,00,00,00
     64CBD5     +64CBD5,00,00,00
     654BE7     +654BE7,00,00,00
     654D47     +654D47,00,00,00
     654DB7     +654DB7,00,00,00
     6644DC     +6644DC,00,00,00
     6738DA     +6738DA,00,00,00
     674082     +674082,00,00,00
     6740B4     +6740B4,00,00,00
     674137     +674137,00,00,00
     69CFB8     +69CFB8,00,00,00
     6A1ECE     +6A1ECE,00,00,00
     6A1ED2     +6A1ED2,00,00,00
     6A1EE5     +6A1EE5,00,00,00
     6A1EFD     +6A1EFD,00,00,00
     6B6F56     +6B6F56,00,00,00
     6C483E     +6C483E,00,00,00
     6CD39F     +6CD39F,00,00,00
   READINGS:
     2020-02-01 11:32:43   D-HMIdAssigned  6A60EA
     2020-02-01 11:32:43   D-HMIdOriginal  6BD774
     2020-02-01 11:32:43   D-firmware      1.4.1
     2020-02-01 11:32:43   D-serialNr      PEQ2214443
     2020-02-01 11:20:00   D-type          HM-MOD-UART
     2020-02-01 11:32:43   cond            ok
     2020-02-01 11:33:45   load            6
     2020-02-01 11:32:43   loadLvl         low
     2020-02-01 11:32:40   state           opened
   helper:
Attributes:
   event-on-change-reading .*
   hmId       6A60EA
   room       CUL_HM


Update: Das Funkmodul ist es dann wohl nicht. Bekomme direkt wieder die Fehler im Log

2020.02.01 11:36:26 1: /dev/ttyAMA0 disconnected, waiting to reappear (myHmUART)
2020.02.01 11:36:34 3: Setting myHmUART serial parameters to 115200,8,N,1
2020.02.01 11:36:34 1: /dev/ttyAMA0 reappeared (myHmUART)


Das ist echt frustrierend  :(

Am Raspberry hängt noch ein ConBee2 und ein Signalduino per USB. Haben diese Geräte irgend einen Einfluss auf Homematic?
2x Raspberry 3B+, 1x Raspberry 4, Signalduino 433 (Somfy), CUL_HM (HM-MOD-RPI-PCB), MQTT, Hue, ConBee 2, Sonos, AVM DECT, Netatmo, eufy, Nuki,

Otto123

Moin,
ZitatMuss man eigentlich etwas an der hmid ändern / anpassen? hmid in produktiv und Backup System sind unterschiedlich?
Die hmId ist der Dreh und Angelpunkt des Homematic Systems. Sie ist die Grundlage der Authorisierung zwischen Zentrale und den Geräten.
Warum hast Du sie unterschiedlich gesetzt?

Zum Rest bin ich ratlos. Also das Funkmodul ist es offenbar nicht.
Da es ja auch nicht massiv passiert sondern nur "ab und zu" muss es irgendein Programm / Dienst sein, der die AMA0 Schnittstelle greifen will. Da musst Du mal in Dich gehen, was da so noch läuft auf deinem System.

Du kannst doch auf dem Backup System mal ein minimal System einrichten:
raspbian-lite streng nach Wiki ohne alles weitere. hmId kannst Du gleich wie Produktivsystem machen.
https://wiki.fhem.de/wiki/Raspberry_Pi#Verwendung_UART_f.C3.BCr_Zusatzmodule
https://wiki.fhem.de/wiki/HM-MOD-RPI-PCB_HomeMatic_Funkmodul_f%C3%BCr_Raspberry_Pi#Originaler_Einsatzzweck_im_Raspberry
Wenn Du willst kannst Du meine Scripts nutzen. Damit geht das schnell und dauert nur wenige Minuten.

Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

Udomatic

#23
Zitat von: Otto123 am 01 Februar 2020, 12:06:50
Moin,Die hmId ist der Dreh und Angelpunkt des Homematic Systems. Sie ist die Grundlage der Authorisierung zwischen Zentrale und den Geräten.
Warum hast Du sie unterschiedlich gesetzt?


Zum Rest bin ich ratlos. Also das Funkmodul ist es offenbar nicht.
Da es ja auch nicht massiv passiert sondern nur "ab und zu" muss es irgendein Programm / Dienst sein, der die AMA0 Schnittstelle greifen will. Da musst Du mal in Dich gehen, was da so noch läuft auf deinem System.

Das ist nur, weil ich heute Morgen schnell per Wiki Copy / Paste das Funkmodul im Backupsystem neu geflasht und eingerichtet habe.
Im Backup System mit FHEM minimal Konfiguration habe ich zumindest nicht den Fehler.

Ich habe halt jetzt keine Ahnung, wo ich ansetzen soll. Neu hinzu gekommen ist in den letzten drei Monaten primär das Thema MQTT2 Server und ein paar Devices dazu und as Echo Device Modul.
2x Raspberry 3B+, 1x Raspberry 4, Signalduino 433 (Somfy), CUL_HM (HM-MOD-RPI-PCB), MQTT, Hue, ConBee 2, Sonos, AVM DECT, Netatmo, eufy, Nuki,

Otto123

FHEM blockiert zeitweise?
Hast mal nach freezes gesucht? freezemon definiert?
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

Udomatic

Zitat von: Otto123 am 01 Februar 2020, 12:42:27
FHEM blockiert zeitweise?
Hast mal nach freezes gesucht? freezemon definiert?

Hallo Otto,

gestern und heute morgen ist FHEM hängen geblieben. Hatte ich bisher im Verlauf der Probleme nicht. Das Stand im Log, ich kann aber nicht ausmachen, was der Auslöser ist?

2020.02.03 08:54:07 3: mqtt2s: mqtt2s_192.168.178.49_63914/Blitzwolf-BWSHP2-01 left us (keepalive check)
2020.02.03 08:54:25 3: mqtt2s: mqtt2s_192.168.178.32_60532/Blitzwolf-BWSHP2-02 left us (keepalive check)
2020.02.03 08:54:51 1: Timeout for SYSMON_blockingCall reached, terminated process 23678
2020.02.03 08:54:52 3: mqtt2s: mqtt2s_192.168.178.24_48062/shellyswitch25-B89E2D left us (keepalive check)
2020.02.03 08:54:52 3: mqtt2s: mqtt2s_192.168.178.22_46224/shellyplug-s-040CA2 left us (keepalive check)
2020.02.03 08:55:01 3: mqtt2s: mqtt2s_192.168.178.20_46272/shellyplug-s-041439 left us (keepalive check)
2020.02.03 08:55:01 3: mqtt2s: mqtt2s_192.168.178.23_41138/shellyplug-s-7A2FD2 left us (keepalive check)
2020.02.03 08:55:08 1: Timeout for PRESENCE_DoLocalFunctionScan reached, terminated process 23790
2020.02.03 08:55:08 2: PRESENCE (iphone_Anita) - device could not be checked (retrying in 10 seconds): Timeout: process terminated
2020.02.03 08:55:08 1: Timeout for PRESENCE_DoLocalFunctionScan reached, terminated process 23791
2020.02.03 08:55:08 2: PRESENCE (iphone_Udo) - device could not be checked (retrying in 10 seconds): Timeout: process terminated
2020.02.03 08:55:50 1: Timeout for SYSMON_blockingCall reached, terminated process 24244
2020.02.03 08:56:03 0: SONOS0: Das Lauschen auf der Schnittstelle wurde beendet. Prozess endet nun auch...
2020.02.03 08:56:16 1: Timeout for PRESENCE_DoLocalFunctionScan reached, terminated process 24497
2020.02.03 08:56:16 2: PRESENCE (iphone_Anita) - device could not be checked after 1 retry (retrying in 10 seconds): Timeout: process terminated
2020.02.03 08:56:16 1: Timeout for PRESENCE_DoLocalFunctionScan reached, terminated process 24498
2020.02.03 08:56:16 2: PRESENCE (iphone_Udo) - device could not be checked after 1 retry (retrying in 10 seconds): Timeout: process terminated
2020.02.03 08:56:22 1: Timeout for FRITZBOX_Readout_Run_Web reached, terminated process 24596
2020.02.03 08:56:22 1: FRITZBOX FritzBox: Readout_Aborted.1931 Error: Timeout when reading Fritz!Box data.
2020.02.03 08:56:29 3: radinoCC1101: KeepAlive, not ok, retry = 2 -> get ping
2020.02.03 08:56:49 1: Timeout for SYSMON_blockingCall reached, terminated process 24859
2020.02.03 08:57:24 1: Timeout for PRESENCE_DoLocalFunctionScan reached, terminated process 25203
2020.02.03 08:57:24 2: PRESENCE (iphone_Anita) - device could not be checked after 2 retries (retrying in 10 seconds): Timeout: process terminated
2020.02.03 08:57:24 1: Timeout for PRESENCE_DoLocalFunctionScan reached, terminated process 25204
2020.02.03 08:57:24 2: PRESENCE (iphone_Udo) - device could not be checked after 2 retries (retrying in 10 seconds): Timeout: process terminated
2020.02.03 08:57:28 3: radinoCC1101: KeepAlive, not ok, retry = 3 -> get ping
2020.02.03 08:57:48 1: Timeout for SYSMON_blockingCall reached, terminated process 25443
2020.02.03 08:58:27 3: radinoCC1101: KeepAlive, not ok, retry count reached. Reset
2020.02.03 08:58:27 3: radinoCC1101: ResetDevice, radinoCC1101
2020.02.03 08:58:27 3: radinoCC1101: ResetDevice, forcing special reset for radinoCC1101 on /dev/serial/by-id/usb-Unknown_radino_CC1101-if00
2020.02.03 08:58:27 3: radinoCC1101: ResetDevice, reopen delayed for 10 second
2020.02.03 08:58:32 1: Timeout for PRESENCE_DoLocalFunctionScan reached, terminated process 25878
2020.02.03 08:58:32 2: PRESENCE (iphone_Anita) - device could not be checked after 3 retries (resuming normal operation): Timeout: process terminated
2020.02.03 08:58:32 1: Timeout for PRESENCE_DoLocalFunctionScan reached, terminated process 25879
2020.02.03 08:58:32 2: PRESENCE (iphone_Udo) - device could not be checked after 3 retries (resuming normal operation): Timeout: process terminated
2020.02.03 08:58:36 3: Opening radinoCC1101 device /dev/serial/by-id/usb-Unknown_radino_CC1101-if00
2020.02.03 08:58:36 3: Setting radinoCC1101 serial parameters to 57600,8,N,1
2020.02.03 08:58:36 1: radinoCC1101: DoInit, /dev/serial/by-id/usb-Unknown_radino_CC1101-if00
2020.02.03 08:58:36 1: radinoCC1101: DoInit, /dev/serial/by-id/usb-Unknown_radino_CC1101-if00
2020.02.03 08:58:36 3: radinoCC1101 device opened
2020.02.03 08:58:36 3: radinoCC1101: SimpleWrite_XQ, disable receiver (XQ)
2020.02.03 08:58:37 3: radinoCC1101: StartInit, get version, retry = 0
2020.02.03 08:58:46 3: radinoCC1101: StartInit, get version, retry = 1
2020.02.03 08:58:47 1: Timeout for SYSMON_blockingCall reached, terminated process 26062
2020.02.03 08:58:55 3: radinoCC1101: StartInit, get version, retry = 2
2020.02.03 08:59:04 3: radinoCC1101: StartInit, get version, retry = 3
2020.02.03 08:59:04 2: radinoCC1101: StartInit, retry count reached. Reset
2020.02.03 08:59:04 3: radinoCC1101: ResetDevice, radinoCC1101
2020.02.03 08:59:04 3: radinoCC1101: ResetDevice, forcing special reset for radinoCC1101 on /dev/serial/by-id/usb-Unknown_radino_CC1101-if00
2020.02.03 08:59:04 3: radinoCC1101: ResetDevice, reopen delayed for 10 second
2020.02.03 08:59:13 3: Opening radinoCC1101 device /dev/serial/by-id/usb-Unknown_radino_CC1101-if00
2020.02.03 08:59:13 3: Setting radinoCC1101 serial parameters to 57600,8,N,1
2020.02.03 08:59:13 1: radinoCC1101: DoInit, /dev/serial/by-id/usb-Unknown_radino_CC1101-if00
2020.02.03 08:59:13 1: radinoCC1101: DoInit, /dev/serial/by-id/usb-Unknown_radino_CC1101-if00
2020.02.03 08:59:13 3: radinoCC1101 device opened
2020.02.03 08:59:14 3: radinoCC1101: SimpleWrite_XQ, disable receiver (XQ)
2020.02.03 08:59:14 3: radinoCC1101: StartInit, get version, retry = 0
2020.02.03 08:59:23 3: radinoCC1101: StartInit, get version, retry = 1
2020.02.03 08:59:32 3: radinoCC1101: StartInit, get version, retry = 2
2020.02.03 08:59:41 3: radinoCC1101: StartInit, get version, retry = 3
2020.02.03 08:59:41 2: radinoCC1101: StartInit, init retry count reached. Closed
2020.02.03 08:59:41 2: radinoCC1101: CloseDevice, closed
2020.02.03 08:59:46 1: Timeout for SYSMON_blockingCall reached, terminated process 26691
2020.02.03 09:00:00 1: Timeout for PRESENCE_DoLocalFunctionScan reached, terminated process 26800
2020.02.03 09:00:00 1: Timeout for PRESENCE_DoLocalFunctionScan reached, terminated process 26801
2020.02.03 09:00:45 1: Timeout for SYSMON_blockingCall reached, terminated process 27337
2020.02.03 09:01:21 1: Timeout for FRITZBOX_Readout_Run_Web reached, terminated process 27711
2020.02.03 09:01:21 1: FRITZBOX FritzBox: Readout_Aborted.1931 Error: Timeout when reading Fritz!Box data.
2020.02.03 09:01:28 1: Timeout for PRESENCE_DoLocalFunctionScan reached, terminated process 27762
2020.02.03 09:01:28 1: Timeout for PRESENCE_DoLocalFunctionScan reached, terminated process 27763
2020.02.03 09:01:44 1: Timeout for SYSMON_blockingCall reached, terminated process 27958
2020.02.03 09:02:43 1: Timeout for SYSMON_blockingCall reached, terminated process 28572
2020.02.03 09:02:56 1: Timeout for PRESENCE_DoLocalFunctionScan reached, terminated process 28623
2020.02.03 09:02:56 1: Timeout for PRESENCE_DoLocalFunctionScan reached, terminated process 28624
2020.02.03 09:03:42 1: Timeout for SYSMON_blockingCall reached, terminated process 29149
2020.02.03 09:04:24 1: Timeout for PRESENCE_DoLocalFunctionScan reached, terminated process 29515
2020.02.03 09:04:24 1: Timeout for PRESENCE_DoLocalFunctionScan reached, terminated process 29516
2020.02.03 09:04:41 1: Timeout for SYSMON_blockingCall reached, terminated process 29768
2020.02.03 09:05:40 1: Timeout for SYSMON_blockingCall reached, terminated process 30328
2020.02.03 09:05:52 1: Timeout for PRESENCE_DoLocalFunctionScan reached, terminated process 30473
2020.02.03 09:05:52 1: Timeout for PRESENCE_DoLocalFunctionScan reached, terminated process 30475
2020.02.03 09:06:20 1: Timeout for FRITZBOX_Readout_Run_Web reached, terminated process 30774
2020.02.03 09:06:20 1: FRITZBOX FritzBox: Readout_Aborted.1931 Error: Timeout when reading Fritz!Box data.
2020.02.03 09:06:39 1: Timeout for SYSMON_blockingCall reached, terminated process 30957
2020.02.03 09:07:20 1: Timeout for PRESENCE_DoLocalFunctionScan reached, terminated process 31374
2020.02.03 09:07:20 1: Timeout for PRESENCE_DoLocalFunctionScan reached, terminated process 31375
2020.02.03 09:07:38 1: Timeout for SYSMON_blockingCall reached, terminated process 31576
2020.02.03 09:08:37 1: Timeout for SYSMON_blockingCall reached, terminated process 32193
2020.02.03 09:08:48 1: Timeout for PRESENCE_DoLocalFunctionScan reached, terminated process 32239
2020.02.03 09:08:48 1: Timeout for PRESENCE_DoLocalFunctionScan reached, terminated process 32240
2020.02.03 09:09:36 1: Timeout for SYSMON_blockingCall reached, terminated process 319
2020.02.03 09:10:16 1: Timeout for PRESENCE_DoLocalFunctionScan reached, terminated process 796
2020.02.03 09:10:17 1: Timeout for PRESENCE_DoLocalFunctionScan reached, terminated process 804
2020.02.03 09:10:35 1: Timeout for SYSMON_blockingCall reached, terminated process 1056
2020.02.03 09:11:19 1: Timeout for FRITZBOX_Readout_Run_Web reached, terminated process 1576
2020.02.03 09:11:19 1: FRITZBOX FritzBox: Readout_Aborted.1931 Error: Timeout when reading Fritz!Box data.
2020.02.03 09:11:34 1: Timeout for SYSMON_blockingCall reached, terminated process 1718
2020.02.03 09:11:44 1: Timeout for PRESENCE_DoLocalFunctionScan reached, terminated process 1796
2020.02.03 09:11:45 1: Timeout for PRESENCE_DoLocalFunctionScan reached, terminated process 1797
2020.02.03 09:12:33 1: Timeout for SYSMON_blockingCall reached, terminated process 2352
2020.02.03 09:13:12 1: Timeout for PRESENCE_DoLocalFunctionScan reached, terminated process 2665
2020.02.03 09:13:13 1: Timeout for PRESENCE_DoLocalFunctionScan reached, terminated process 2666
2020.02.03 09:13:32 1: Timeout for SYSMON_blockingCall reached, terminated process 3361
2020.02.03 09:14:31 1: Timeout for SYSMON_blockingCall reached, terminated process 3949
2020.02.03 09:14:40 1: Timeout for PRESENCE_DoLocalFunctionScan reached, terminated process 4012
2020.02.03 09:14:41 1: Timeout for PRESENCE_DoLocalFunctionScan reached, terminated process 4013
2020.02.03 09:15:30 1: Timeout for SYSMON_blockingCall reached, terminated process 4522
2020.02.03 09:16:08 1: Timeout for PRESENCE_DoLocalFunctionScan reached, terminated process 4921
2020.02.03 09:16:09 1: Timeout for PRESENCE_DoLocalFunctionScan reached, terminated process 4922
2020.02.03 09:16:18 1: Timeout for FRITZBOX_Readout_Run_Web reached, terminated process 5078
2020.02.03 09:16:18 1: FRITZBOX FritzBox: Readout_Aborted.1931 Error: Timeout when reading Fritz!Box data.
2020.02.03 09:16:29 1: Timeout for SYSMON_blockingCall reached, terminated process 5176
2020.02.03 09:17:28 1: Timeout for SYSMON_blockingCall reached, terminated process 5793
2020.02.03 09:17:36 1: Timeout for PRESENCE_DoLocalFunctionScan reached, terminated process 5818
2020.02.03 09:17:37 1: Timeout for PRESENCE_DoLocalFunctionScan reached, terminated process 5819
2020.02.03 09:18:27 1: Timeout for SYSMON_blockingCall reached, terminated process 6459
2020.02.03 09:19:04 1: Timeout for PRESENCE_DoLocalFunctionScan reached, terminated process 6816
2020.02.03 09:19:05 1: Timeout for PRESENCE_DoLocalFunctionScan reached, terminated process 6817
2020.02.03 09:19:26 1: Timeout for SYSMON_blockingCall reached, terminated process 7079
2020.02.03 09:20:25 1: Timeout for SYSMON_blockingCall reached, terminated process 7660
2020.02.03 09:20:32 1: Timeout for PRESENCE_DoLocalFunctionScan reached, terminated process 7708
2020.02.03 09:20:33 1: Timeout for PRESENCE_DoLocalFunctionScan reached, terminated process 7715
2020.02.03 09:21:17 1: Timeout for FRITZBOX_Readout_Run_Web reached, terminated process 8237
2020.02.03 09:21:17 1: FRITZBOX FritzBox: Readout_Aborted.1931 Error: Timeout when reading Fritz!Box data.
2020.02.03 09:21:24 1: Timeout for SYSMON_blockingCall reached, terminated process 8282
2020.02.03 09:22:00 1: Timeout for PRESENCE_DoLocalFunctionScan reached, terminated process 8574
2020.02.03 09:22:01 1: Timeout for PRESENCE_DoLocalFunctionScan reached, terminated process 8575
2020.02.03 09:22:23 1: Timeout for SYSMON_blockingCall reached, terminated process 8893
2020.02.03 09:23:22 1: Timeout for SYSMON_blockingCall reached, terminated process 9510
2020.02.03 09:23:29 1: Timeout for PRESENCE_DoLocalFunctionScan reached, terminated process 9525
2020.02.03 09:23:29 1: Timeout for PRESENCE_DoLocalFunctionScan reached, terminated process 9526
2020.02.03 09:24:21 1: Timeout for SYSMON_blockingCall reached, terminated process 11151
2020.02.03 09:24:57 1: Timeout for PRESENCE_DoLocalFunctionScan reached, terminated process 12893
2020.02.03 09:24:57 1: Timeout for PRESENCE_DoLocalFunctionScan reached, terminated process 12917
2020.02.03 09:25:20 1: Timeout for SYSMON_blockingCall reached, terminated process 14285
2020.02.03 09:26:16 1: Timeout for FRITZBOX_Readout_Run_Web reached, terminated process 16820
2020.02.03 09:26:16 1: FRITZBOX FritzBox: Readout_Aborted.1931 Error: Timeout when reading Fritz!Box data.
2020.02.03 09:26:19 1: Timeout for SYSMON_blockingCall reached, terminated process 16950
2020.02.03 09:26:25 1: Timeout for PRESENCE_DoLocalFunctionScan reached, terminated process 16971
2020.02.03 09:26:25 1: Timeout for PRESENCE_DoLocalFunctionScan reached, terminated process 16972
2020.02.03 09:26:49 1: BlockingInformParent (BlockingRegisterTelnet): Can't connect to localhost:7072: IO::Socket::INET: connect: Interrupted system call
2020.02.03 09:27:18 1: Timeout for SYSMON_blockingCall reached, terminated process 19533
2020.02.03 09:27:53 1: Timeout for PRESENCE_DoLocalFunctionScan reached, terminated process 21041
2020.02.03 09:27:53 1: Timeout for PRESENCE_DoLocalFunctionScan reached, terminated process 21042
2020.02.03 09:28:17 1: Timeout for SYSMON_blockingCall reached, terminated process 22315


Das Presence Modul?
2x Raspberry 3B+, 1x Raspberry 4, Signalduino 433 (Somfy), CUL_HM (HM-MOD-RPI-PCB), MQTT, Hue, ConBee 2, Sonos, AVM DECT, Netatmo, eufy, Nuki,

Otto123

Guten Morgen,

Dieses Verhalten vom Presence Modul kenne ich bei mir auch.  Ich konnte bisher nicht ausmachen woran das liegt. Das ist zwar eine unschöne Meldung im Log aber noch kein direkter Hinweis das FHEM zu dem Zeitpunkt steht und das HMUARTLGW Modul damit ein Problem hat.

Definier mal bitte den freezemon
define freez freezemon
Der zeigt Dir ob FHEM da wirklich einfriert und für wie lange.

Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

Udomatic

Zitat von: Otto123 am 03 Februar 2020, 09:52:31
Guten Morgen,

Dieses Verhalten vom Presence Modul kenne ich bei mir auch.  Ich konnte bisher nicht ausmachen woran das liegt. Das ist zwar eine unschöne Meldung im Log aber noch kein direkter Hinweis das FHEM zu dem Zeitpunkt steht und das HMUARTLGW Modul damit ein Problem hat.

Definier mal bitte den freezemon
define freez freezemon
Der zeigt Dir ob FHEM da wirklich einfriert und für wie lange.

Gruß Otto
Nach define freezemon und Neustart Pi steht folgendes im Log:

2020.02.03 09:48:32 1: [Freezemon] myFreezemon: possible freeze starting at 09:48:31, delay is 1.324 possibly caused by: tmr-CUL_HM_sndIfOpen(myHmUART) tmr-CUL_HM_procQs(N/A) tmr-HMUARTLGW_CheckCmdResp(myHmUART) tmr-CODE(0x392d2c0)(__ANON__) tmr-HOMEMODE_GetUpdate(Home) tmr-CODE(0x44939c8)(__ANON__) tmr-CODE(0x5ead790)(__ANON__)
2x Raspberry 3B+, 1x Raspberry 4, Signalduino 433 (Somfy), CUL_HM (HM-MOD-RPI-PCB), MQTT, Hue, ConBee 2, Sonos, AVM DECT, Netatmo, eufy, Nuki,

Otto123

Naja dass wäre ja das Problemkind an sich? Aber ich glaube solche Meldungen habe ich auch immer mal.

Zu beobachten wäre das Ganze jetzt, ob freezes im Zusammenhang mit diesen Meldungen auftauchen:
2020.02.01 11:36:26 1: /dev/ttyAMA0 disconnected, waiting to reappear (myHmUART)
2020.02.01 11:36:34 3: Setting myHmUART serial parameters to 115200,8,N,1
2020.02.01 11:36:34 1: /dev/ttyAMA0 reappeared (myHmUART)
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

Udomatic

Zitat von: Otto123 am 03 Februar 2020, 12:41:43
Naja dass wäre ja das Problemkind an sich? Aber ich glaube solche Meldungen habe ich auch immer mal.

Zu beobachten wäre das Ganze jetzt, ob freezes im Zusammenhang mit diesen Meldungen auftauchen:
2020.02.01 11:36:26 1: /dev/ttyAMA0 disconnected, waiting to reappear (myHmUART)
2020.02.01 11:36:34 3: Setting myHmUART serial parameters to 115200,8,N,1
2020.02.01 11:36:34 1: /dev/ttyAMA0 reappeared (myHmUART)


Bis jetzt nichts zu erkennen. Immer wieder der gleiche Log Fehler

2020.02.03 18:12:19 1: /dev/ttyAMA0 disconnected, waiting to reappear (myHmUART)
2020.02.03 18:12:23 3: Setting myHmUART serial parameters to 115200,8,N,1
2020.02.03 18:12:23 1: /dev/ttyAMA0 reappeared (myHmUART)


Habe schon diverse Devices gelöscht, die ich zuletzt angelegt hatte, wie Homemode, Presence, FritzBox.

Leider keine Änderung.

2x Raspberry 3B+, 1x Raspberry 4, Signalduino 433 (Somfy), CUL_HM (HM-MOD-RPI-PCB), MQTT, Hue, ConBee 2, Sonos, AVM DECT, Netatmo, eufy, Nuki,

Otto123

Also wenn FHEM an der Stelle nicht blockiert und Du alle 3-4 min einen disconnect bekommst, dann muss ein anderer Prozess die serielle Schnittstelle mit diesem Zeitraster stören.

Da musst Du jetzt irgendwie die Prozesse auf dem Pi monitoren - weiß jetzt auf die Schnelle auch nicht richtig wie. Bei drei Minuten kannst Du Dich hinsetzen und mit top schauen welcher Prozess da eventuell hochschnellt.
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

Pfriemler

Da die disconnects bei mir zu einem ständigen Begleiter geworden sind, habe ich mal meine Logs des letzten Monats durchsucht und dabei eine interessante Beobachtung gemacht:


2020.02.03 09:01:33 3: CUL_HM set AlarmanlageEntschaerfenButton press # das ist ein Kanal eines HM-Mod-Re-8, der auf eine andere FB "drückt"
2020.02.03 09:01:37 1: Alarmanlage ist jetzt Aus # kommt als Rückmeldung über einen HM-Mod-SEN-8bit
...
2020.02.03 09:01:44 1: HMUARTLGW HMUART unexpected info about Co_CPU_BL received (module crashed?), reopening
2020.02.03 09:01:44 3: HMUART device closed
2020.02.03 09:01:44 3: Setting HMUART serial parameters to 115200,8,N,1
2020.02.03 09:01:44 1: /dev/ttyAMA0 reappeared (HMUART)


Dieser Effekt kommt bei mir mit einer unglaublichen Präzision genau einmal am Tag, wobei ich zunächst an die konstant 7-8 s Verzögerung nach dem SEN-8bit-Telegramm dachte - stattdessen aber ist die Konstante der an das Re-8 gesendete (Burst-)Schaltbefehl, der zwischen 11 und 20 Sekunden davor liegt.

Was die Sache echt mystisch macht: Diese Befehle erfolgen über den Tag verteilt zu sehr unterschiedlichen Zeiten mehrmals, aber der "Zusammenbruch" erfolgt tatsächlich in 95% der Fälle zwischen 6 und 10 Uhr (wo der erste Schaltvorgang dieser Art kommt). Es ist auch nicht immer genau der Kanal des Re-8, manchmal wird ein anderer geschaltet und hat den gleichen Effekt.

Und es wird noch mystischer: Wenn es an einem Tag nicht das HMUART am seriellen Port des Raspi ist, erwischt es stattdessen das per WLAN angebundene Modul. Fast so, als hätte die VCCU an diesem Tag beschlossen das andere IO als Sender zu verwenden, was es daraufhin in den Orkus reißt.

Bei sowas macht es mir keinen Spaß, den Dingern näher auf den Grund zu gehen ...
"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

Udomatic

Hallo,

ich kämpfe leider immer noch mit dem disconnect Fehler meines Funkmoduls, was sich scheinbar nicht lösen lässt.
Aus diesem überlege ich jetzt entweder das Thema Homematic auf einen eigenen Raspberry auszulagern.

Im Moment tendiere ich zu Raspberrymatic und dem einbinden über HMCCU
Alternativ ein zweite FHEM Instanz mit CUL_HM. Geht das überhaupt und wenn ja, wie bekomme ich dann die HM Geräte in meine primäre Instanz?

Gibt es hierzu Empfehlungen?

Gruß
Udo
2x Raspberry 3B+, 1x Raspberry 4, Signalduino 433 (Somfy), CUL_HM (HM-MOD-RPI-PCB), MQTT, Hue, ConBee 2, Sonos, AVM DECT, Netatmo, eufy, Nuki,

Otto123

Naja Du musst wissen HMCCU und CUL_HM sind komplett anders. Du musst also alles was damit im Zusammenhang steht anfassen.

Warum lagerst Du nicht bloß mal das Funkmodul auf einen zweiten Pi aus? Das geht doch relativ easy.
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

Udomatic

Zitat von: Otto123 am 12 Februar 2020, 12:10:39
Warum lagerst Du nicht bloß mal das Funkmodul auf einen zweiten Pi aus? Das geht doch relativ easy.

Hi Otto,

was meinst du genau mit auslagern?
2x Raspberry 3B+, 1x Raspberry 4, Signalduino 433 (Somfy), CUL_HM (HM-MOD-RPI-PCB), MQTT, Hue, ConBee 2, Sonos, AVM DECT, Netatmo, eufy, Nuki,

Otto123

#35
so :)

Also
1. VCCU machen
2. IOList setzen
3. Remote Pi per ser2net einbinden
4. In die IOList eintragen
5. alten lokale Def pausieren: attr DUMMY
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

Udomatic

#36
Zitat von: Otto123 am 12 Februar 2020, 12:36:35
so :)

Also
1. VCCU machen
2. IOList setzen
3. Remote Pi per ser2net einbinden
4. In die IOList eintragen
5. alten lokale Def pausieren: attr DUMMY

Danke für die Anleitung. Habe soweit alles eingerichtet. Mir wird aber gesagt, dass der Port bereits in Nutzung ist

Internals:
   CFGFN     
   CMDS       
   CUL868_MSGCNT 2
   CUL868_TIME 2020-02-12 20:28:27
   Clients    :FS20:FHT.*:KS300:USF1000:BS:HMS:FS20V: :CUL_EM:CUL_WS:CUL_FHTTK:CUL_HOERMANN: :ESA2000:CUL_IR:CUL_TX:Revolt:IT:UNIRoll:SOMFY: :STACKABLE_CC:TSSTACKED:STACKABLE:CUL_RFR::CUL_TCM97001:CUL_REDIRECT:
   DEF        192.168.178.56:4000 0000
   DeviceName 192.168.178.56:4000
   FHTID      0000
   FUUID      5e44519f-f33f-45fc-ec9f-944598ee6d848e2c
   NAME       CUL868
   NEXT_OPEN  1581535767
   NR         524
   PARTIAL   
   RAWMSG     Port already in use
   STATE      disconnected
   TYPE       CUL
   initString X21
   .attraggr:
   .attreocr:
     .*
   .attrminint:
   .clientArray:
     SOMFY
   MatchList:
     0:FS20V    ^81..(04|0c)..0101a001......00[89a-f]...
     1:USF1000  ^81..(04|0c)..0101a001a5ceaa00....
     2:BS       ^81..(04|0c)..0101a001a5cf
     3:FS20     ^81..(04|0c)..0101a001
     4:FHT      ^81..(04|09|0d)..(0909a001|83098301|c409c401)..
     5:KS300    ^810d04..4027a001
     6:CUL_WS   ^K.....
     7:CUL_EM   ^E0.................$
     8:HMS      ^810e04......a001
     9:CUL_FHTTK ^T[A-F0-9]{8}
     A:CUL_RFR  ^[0-9A-F]{4}U.
     B:CUL_HOERMANN ^R..........
     C:ESA2000  ^S................................$
     D:CUL_IR   ^I............
     E:CUL_TX   ^TX[A-F0-9]{10}
     F:Revolt   ^r......................$
     G:IT       ^i......
     H:STACKABLE_CC ^\*
     I:UNIRoll  ^[0-9A-F]{5}(B|D|E)
     J:SOMFY    ^Y[r|t|s]:?[A-F0-9]+
     K:CUL_TCM97001 ^s[A-F0-9]+
     L:CUL_REDIRECT ^o+
     M:TSSTACKED ^\*
     N:STACKABLE ^\*
   READINGS:
     2020-02-12 20:28:27   state           disconnected
Attributes:
   event-on-change-reading .*
   room       Devices


Bin dieser Beschreibung gefolgt und nutze Port 4000

https://wiki.fhem.de/wiki/HM-MOD-RPI-PCB_HomeMatic_Funkmodul_für_Raspberry_Pi#Originaler_Einsatzzweck_im_Raspberry

In der VCCU sieht es jetzt so aus:

Internals:
   .triggerUsed 1
   DEF        6A60EA
   FUUID      5e30b2cb-f33f-45fc-5543-1e9060fbfc6fdf59
   IODev     
   NAME       VCCU
   NOTIFYDEV  global
   NR         456
   NTFY_ORDER 50-VCCU
   STATE      myHmUART:UAS,CUL868:opened
   TYPE       CUL_HM
   assignedIOs CUL868,myHmUART
   chanNo     01
   .attraggr:
   .attrminint:
   READINGS:
     2020-02-12 20:43:32   IOopen          0
     2020-01-28 23:19:05   RegL_00.       
     2020-02-12 20:43:32   state           myHmUART:UAS,CUL868:opened
     2020-02-01 12:52:33   unknown_424242  received
     2020-02-01 12:02:08   unknown_683EBD  received
     2020-02-01 18:37:13   unknown_683ECF  received
     2020-02-01 12:01:23   unknown_683EE1  received
     2020-02-12 19:05:26   unknown_683EE2  received
   helper:
     HM_CMDNR   82
     mId        FFF0
     peerFriend peerSD,peerSens,peerAct
     peerOpt    -:virtual
     regLst     0
     rxType     1
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       prefIO     
       vccu       VCCUHM
       ioList:
         CUL868
     mRssi:
       mNo       
     prt:
       bErr       0
       sProc      0
     q:
       qReqConf   
       qReqStat   
     role:
       chn        1
       dev        1
       vrt        1
     tmpl:
Attributes:
   .mId       FFF0
   IODev      CUL868
   IOList     CUL868
   IOgrp      VCCUHM
   expert     2_raw
   model      CCU-FHEM
   room       CUL_HM
   subType    virtual
   webCmd     virtual:update


Bisher bekommen aktualisieren die HM Geräte nicht Ihre Register bzw. reagieren.
Woran kann es liegen?

Muss ich das Attribut IODev jedes Homematic Gerätes auch anpassen?Dort steht noch überall der deaktivierte myHMUART drinne



2x Raspberry 3B+, 1x Raspberry 4, Signalduino 433 (Somfy), CUL_HM (HM-MOD-RPI-PCB), MQTT, Hue, ConBee 2, Sonos, AVM DECT, Netatmo, eufy, Nuki,

Otto123

#37
Wieso jetzt CUL868  :o ? Ich denke wir reden vom HMUART Modul? Wo steht in der Anleitung was vom CUL?

Mit dem attr IOgrp VCCUHM bin ich auch durch den Wind? Woher nimmst Du das?
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

Udomatic

Zitat von: Otto123 am 12 Februar 2020, 21:08:02
Wieso jetzt CUL868  :o ? Ich denke wir reden vom HMUART Modul? Wo steht in der Anleitung was vom CUL?

Nachdem ich ser2net auf dem zweiten Raspberry installiert habe, habe ich in FHEM folgendes gemacht:

define CUL868 CUL 192.168.178.56:4000 0000
CUL868 ist also nur der Name des IO Device

War das falsch?
2x Raspberry 3B+, 1x Raspberry 4, Signalduino 433 (Somfy), CUL_HM (HM-MOD-RPI-PCB), MQTT, Hue, ConBee 2, Sonos, AVM DECT, Netatmo, eufy, Nuki,

Udomatic

Zitat von: Otto123 am 12 Februar 2020, 21:08:02
Wieso jetzt CUL868  :o ? Ich denke wir reden vom HMUART Modul? Wo steht in der Anleitung was vom CUL?

Mit dem attr IOgrp VCCUHM bin ich auch durch den Wind? Woher nimmst Du das?

Hmm, stimmt, das müsste ja nur VCCU heißen, also der Name der VCCU. Hab ich ma geändert
2x Raspberry 3B+, 1x Raspberry 4, Signalduino 433 (Somfy), CUL_HM (HM-MOD-RPI-PCB), MQTT, Hue, ConBee 2, Sonos, AVM DECT, Netatmo, eufy, Nuki,

Otto123

#40
Ja - wo steht das ???
In dem Artikel dessen Link Du mir auch bestätigt hast, steht drin:
define WLAN_HmUART HMUARTLGW uart://<IP-Adresse>:<Portnummer>

Also von mir aus:
define rpi_HmUART HMUARTLGW uart://192.168.178.56:4000

Wie kommst Du nur auf CUL ?

Hattest Du jetzt eigentlich zwei HMUART Module?
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

Udomatic

#41
Zitat von: Otto123 am 12 Februar 2020, 21:16:20
Ja - wo steht das ???
In dem Artikel dessen Link Du mir auch bestätigt hast, steht drin:
define WLAN_HmUART HMUARTLGW uart://<IP-Adresse>:<Portnummer>

Also von mir aus:
define rpi_HmUART HMUARTLGW uart://192.168.178.56:4000

Wie kommst Du nur auf CUL ?

Hattest Du jetzt eigentlich zwei HMUART Module?

Verstanden, habe ich angelegt. Hier das List

Internals:
   CFGFN     
   CNT        1
   Clients    :CUL_HM:
   DEF        uart://192.168.178.56:4000
   DevIoJustClosed 1
   DevState   1
   DevType    UART
   DeviceName 192.168.178.56:4000
   FUUID      5e445e31-f33f-45fc-8527-f0a23145f5698913
   LastOpen   1581539053.93827
   NAME       LAN_HmUART
   NOTIFYDEV  global
   NR         603
   NTFY_ORDER 50-LAN_HmUART
   STATE      disconnected
   TYPE       HMUARTLGW
   XmitOpen   0
   model      HM-MOD-UART
   .attraggr:
   .attreocr:
     .*
   .attrminint:
   Helper:
     AckPending:
       1:
         cmd        00
         dst        0
         frame      FD00030001009E03
         time       1581539054.97845
     LastSendLen:
       3
     Log:
       IDs:
   MatchList:
     1:CUL_HM   ^A......................
   READINGS:
     2020-02-12 21:21:05   D-type          HM-MOD-UART
     2020-02-12 21:24:14   cond            init
     2020-02-12 21:21:05   loadLvl         suspended
     2020-02-12 21:24:13   state           disconnected
Attributes:
   event-on-change-reading .*
   room       CUL_HM


Derzeit wechselt der Status von init zu disconnected. Das zweite HMUARt Modul habe ich gemäß deiner Kurzanleitung mit dem Attribut DUMMY deaktiviert

Im Log steht jetzt:

2020.02.12 21:27:20 1: HMUARTLGW LAN_HmUART did not respond for the 1. time, resending
2020.02.12 21:27:21 1: 192.168.178.56:4000 reappeared (LAN_HmUART)
2020.02.12 21:27:21 1: 192.168.178.56:4000 disconnected, waiting to reappear (LAN_HmUART)


hmid braucht das Gerät jetzt auch wieder nehme ich an?
2x Raspberry 3B+, 1x Raspberry 4, Signalduino 433 (Somfy), CUL_HM (HM-MOD-RPI-PCB), MQTT, Hue, ConBee 2, Sonos, AVM DECT, Netatmo, eufy, Nuki,

Otto123

#42
Da stimmt was nicht. Der andere Pi muss natürlich genauso vorbereitet werden bez. UART Schnittstelle usw. Und es darf dort NICHTS auf  die UART und das Modul zugreifen! Kein FHEM mit einer Definition für das HMUART Modul!

Was sagt auf dem anderen
systemctl status ser2net
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

Udomatic

#43
Zitat von: Otto123 am 12 Februar 2020, 21:30:46
Da stimmt was nicht. Der andere Pi muss natürlich genauso vorbereitet werden bez. UART Schnittstelle usw. Und es darf dort NICHTS auf  die UART und das Modul zugreifen! Kein FHEM mit einer Definition für das HMUART Modul!

Was sagt auf dem anderen
systemctl status ser2net

Da hast du recht. List sieht jetzt so aus

Internals:
   AssignedPeerCnt 12
   CFGFN     
   CNT        99
   Clients    :CUL_HM:
   DEF        uart://192.168.178.56:4000
   DEVCNT     76
   DevState   99
   DevType    UART
   DeviceName 192.168.178.56:4000
   FD         4
   FUUID      5e445e31-f33f-45fc-8527-f0a23145f5698913
   LastOpen   1581540048.00393
   NAME       LAN_HmUART
   NOTIFYDEV  global
   NR         603
   NTFY_ORDER 50-LAN_HmUART
   PARTIAL   
   RAWMSG     050000367F861063AB740000000A98C70C0540
   RSSI       -54
   STATE      opened
   TYPE       HMUARTLGW
   XmitOpen   1
   model      HM-MOD-UART
   msgLoadCurrent 33
   msgLoadHistory 33/-/-/-/-/-/-/-/-/-/-/-
   msgLoadHistoryAbs 33/0/-/-/-/-/-/-/-/-/-/-/-
   owner      424242
   owner_CCU  VCCU
   .attraggr:
   .attreocr:
     .*
   .attrminint:
   .clientArray:
     CUL_HM
   Helper:
     CreditTimer 23
     FW         66561
     Initialized 1
     SendCnt    34
     AckPending:
     LastSendLen:
       3
       3
     Log:
       IDs:
     PendingCMD:
     RoundTrip:
       Delay      0.00465106964111328
     loadLvl:
       lastHistory 1581540350.55961
   MatchList:
     1:CUL_HM   ^A......................
   Peers:
     56257F     +56257F,00,00,00
     628D91     +628D91,00,00,00
     6359A7     +6359A7,00,00,00
     64CBA3     +64CBA3,00,00,00
     654DB7     +654DB7,00,00,00
     6644DC     +6644DC,00,00,00
     6738DA     +6738DA,00,00,00
     674082     +674082,00,00,00
     6740B4     +6740B4,00,00,00
     674137     +674137,00,00,00
     6C483E     +6C483E,00,00,00
     6CD39F     +6CD39F,00,00,00
   READINGS:
     2020-02-12 21:40:50   D-HMIdAssigned  424242
     2020-02-12 21:40:50   D-HMIdOriginal  6BD774
     2020-02-12 21:40:50   D-firmware      1.4.1
     2020-02-12 21:40:50   D-serialNr      PEQ2214443
     2020-02-12 21:21:05   D-type          HM-MOD-UART
     2020-02-12 21:40:50   cond            ok
     2020-02-12 21:46:01   load            33
     2020-02-12 21:40:50   loadLvl         low
     2020-02-12 21:40:48   state           opened
   helper:
Attributes:
   event-on-change-reading .*
   hmId       424242
   room       CUL_HM


Und von der VCCU so:

Internals:
   .triggerUsed 1
   DEF        424242
   FUUID      5e30b2cb-f33f-45fc-5543-1e9060fbfc6fdf59
   IODev     
   NAME       VCCU
   NOTIFYDEV  global
   NR         456
   NTFY_ORDER 50-VCCU
   STATE      LAN_HmUART:ok
   TYPE       CUL_HM
   assignedIOs LAN_HmUART
   chanNo     01
   .attraggr:
   .attrminint:
   READINGS:
     2020-02-12 21:40:50   IOopen          1
     2020-01-28 23:19:05   RegL_00.       
     2020-02-12 21:40:50   state           LAN_HmUART:ok
     2020-02-01 12:52:33   unknown_424242  received
     2020-02-01 12:02:08   unknown_683EBD  received
     2020-02-01 18:37:13   unknown_683ECF  received
     2020-02-01 12:01:23   unknown_683EE1  received
     2020-02-12 19:05:26   unknown_683EE2  received
   helper:
     HM_CMDNR   22
     mId        FFF0
     peerFriend peerSD,peerSens,peerAct
     peerOpt    -:virtual
     regLst     0
     rxType     1
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       prefIO     
       vccu       VCCU
       ioList:
         LAN_HmUART
     mRssi:
       mNo       
     prt:
       bErr       0
       sProc      0
     q:
       qReqConf   
       qReqStat   
     role:
       chn        1
       dev        1
       vrt        1
     tmpl:
Attributes:
   .mId       FFF0
   IODev      LAN_HmUART
   IOList     LAN_HmUART
   IOgrp      VCCU
   expert     2_raw
   model      CCU-FHEM
   room       CUL_HM
   subType    virtual
   webCmd     virtual:update


Die hmid des HMUART muss doch in die DEF der VCCU. Das ist korrekt oder?

Log spuckt gerade folgendes aus:

2020.02.12 21:57:26 0: HMUARTLGW LAN_HmUART: Can't send ACK not originating from my hmId (firmware bug), please use a VCCU virtual device!
2020.02.12 21:58:01 1: [Freezemon] myFreezemon: possible freeze starting at 21:58:00, delay is 1.516 possibly caused by: tmr-SONOSPLAYER_SimulateCurrentTrackPosition(Sonos_Wohnzimmer_Beam)
2x Raspberry 3B+, 1x Raspberry 4, Signalduino 433 (Somfy), CUL_HM (HM-MOD-RPI-PCB), MQTT, Hue, ConBee 2, Sonos, AVM DECT, Netatmo, eufy, Nuki,

Otto123

Das sieht auf die Schnelle gut aus.

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

Du hast bei allen Geräten IOgrp gesetzt? Siehe Wiki VCCU, Befehlszeile:
attr TYPE=CUL_HM:FILTER=DEF=[0-9a-fA-F]{6}:FILTER=DEF!=[0]{6} IOgrp VCCU
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

Udomatic

Zitat von: Otto123 am 12 Februar 2020, 22:09:31
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?

Zitat von: Otto123 am 12 Februar 2020, 22:09:31
Du hast bei allen Geräten IOgrp gesetzt? Siehe Wiki VCCU, Befehlszeile:
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

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?

2x Raspberry 3B+, 1x Raspberry 4, Signalduino 433 (Somfy), CUL_HM (HM-MOD-RPI-PCB), MQTT, Hue, ConBee 2, Sonos, AVM DECT, Netatmo, eufy, Nuki,

Otto123

#46
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.
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

Udomatic

#47
Zitat von: Otto123 am 12 Februar 2020, 22:24:00
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!
2x Raspberry 3B+, 1x Raspberry 4, Signalduino 433 (Somfy), CUL_HM (HM-MOD-RPI-PCB), MQTT, Hue, ConBee 2, Sonos, AVM DECT, Netatmo, eufy, Nuki,

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
2x Raspberry 3B+, 1x Raspberry 4, Signalduino 433 (Somfy), CUL_HM (HM-MOD-RPI-PCB), MQTT, Hue, ConBee 2, Sonos, AVM DECT, Netatmo, eufy, Nuki,

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
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

frank

@udomatic
hast du eventuell eine "virtuelle ccu" (debmatic, pivccu, ...) auf deinem lokalen pi, so dass der hmuart in fhem immer disconnected?
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

Udomatic

#51
Zitat von: frank am 13 Februar 2020, 09:48:55
@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
2x Raspberry 3B+, 1x Raspberry 4, Signalduino 433 (Somfy), CUL_HM (HM-MOD-RPI-PCB), MQTT, Hue, ConBee 2, Sonos, AVM DECT, Netatmo, eufy, Nuki,

Udomatic

Zitat von: Otto123 am 13 Februar 2020, 09:25:08
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.
2x Raspberry 3B+, 1x Raspberry 4, Signalduino 433 (Somfy), CUL_HM (HM-MOD-RPI-PCB), MQTT, Hue, ConBee 2, Sonos, AVM DECT, Netatmo, eufy, Nuki,

Udomatic

Moin,

folgendes ist kurz nach Mitternacht passiert

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?
2x Raspberry 3B+, 1x Raspberry 4, Signalduino 433 (Somfy), CUL_HM (HM-MOD-RPI-PCB), MQTT, Hue, ConBee 2, Sonos, AVM DECT, Netatmo, eufy, Nuki,

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?
ZitatdnsServer
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
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

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.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

Udomatic

Zitat von: Otto123 am 14 Februar 2020, 09:03:06
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?
2x Raspberry 3B+, 1x Raspberry 4, Signalduino 433 (Somfy), CUL_HM (HM-MOD-RPI-PCB), MQTT, Hue, ConBee 2, Sonos, AVM DECT, Netatmo, eufy, Nuki,

Otto123

Naja es gibt immer wieder die Empfehlung das attr global dnsServer auf die interne IP Adresse des Routers zu setzen. Der übernimmt normalerweise die DNS Abfrage ...
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

Udomatic

#58
Zitat von: Otto123 am 14 Februar 2020, 09:03:06
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.
2x Raspberry 3B+, 1x Raspberry 4, Signalduino 433 (Somfy), CUL_HM (HM-MOD-RPI-PCB), MQTT, Hue, ConBee 2, Sonos, AVM DECT, Netatmo, eufy, Nuki,

Otto123

Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

Udomatic

Zitat von: Otto123 am 14 Februar 2020, 11:47:31
Die Antwort steht doch schon in #54 ?

Ja schon aber mit welchem Parameter. Habe keine Ahnung, was ich da gerade tue oder tun soll?
Im global device ist das Attribut ja nicht einfach so auszuwählen und fertig.
2x Raspberry 3B+, 1x Raspberry 4, Signalduino 433 (Somfy), CUL_HM (HM-MOD-RPI-PCB), MQTT, Hue, ConBee 2, Sonos, AVM DECT, Netatmo, eufy, Nuki,

Otto123

Wenn deine Router Adresse 192.168.2.1 ist, setzt Du
attr global dnsServer 192.168.2.1

Wie die DNS Server Adresse Deines FHEM Servers derzeit eingestellt ist kann Du in der FHEM Kommandozeile so ermitteln:
{qx(grep "nameserver" /etc/resolv.conf)}
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

Udomatic

#62
Zitat von: Otto123 am 14 Februar 2020, 12:37:26
Wenn deine Router Adresse 192.168.2.1 ist, setzt Du
attr global dnsServer 192.168.2.1

Wie die DNS Server Adresse Deines FHEM Servers derzeit eingestellt ist kann Du in der FHEM Kommandozeile so ermitteln:
{qx(grep "nameserver" /etc/resolv.conf)}

Danke Otto, bezogen auf Post 54 hatte ich verstanden du sprichst davon das attribut HttpUtils_NonblockingGet zu setzen. Muss man das trotzdem tun?
Das Attribut DNS Server habe ich jetzt gesetzt.

BTW ist mir gerade noch aufgefallen, dass ich das attr initialUsbCheck disable 1 nicht mehr gesetzt habe.
Wenn ich das jetzt wieder nachträglich tun will sagt FHEM
Please define initialUsbCheck first
2x Raspberry 3B+, 1x Raspberry 4, Signalduino 433 (Somfy), CUL_HM (HM-MOD-RPI-PCB), MQTT, Hue, ConBee 2, Sonos, AVM DECT, Netatmo, eufy, Nuki,

Otto123

Dann hast Du initialUsbCheck komplett gelöscht?
list initialUsbCheck ?
Mit attribut HttpUtils_NonblockingGet kenn ich mich nicht aus. Aber das ist ja eine Funktion und kein Attribute. Bei einigen Module kann man das attribute httpUtils setzen, welches dann eine Verwendung nach sich zieht.
ZitathttpUtils
0 -> use HttpUtils_BlockingGet
1 -> use HttpUtils_NonblockingGet
not set -> use old module specific implementation
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

frank

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)

von 00:14 bis 01:14 stand dein fhem still.
ok ich übertreibe. es waren nur 3599 sekunden.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

Udomatic

#65
Zitat von: Otto123 am 14 Februar 2020, 12:59:42
Dann hast Du initialUsbCheck komplett gelöscht?

Ja, das habe ich leider komplett gelöscht. fhem.cfg manuell editieren nötig?

Allgemein verstehe ich derzeit sprechen wir über das Kommunikationsverhalten von FHEM bei Anfragen über http richtig?
Da habe ich ja einige Module am Laufen, die wohl http nutzen (Kalender, Wetterdaten, Tankstelle, Echo Modul, Sonos, Hue ...)

httpUtils_NonblockingGet würde dann nicht warten bis Antwort kommt von der angefragten Gegenstelle richtig?

Wie passt da Homematic jetzt rein mit seinem Funkprotokoll? Dachte das hat mit http weniger zu tun?
Oder glaubst,dass das Homematic Thema eher eine Nebenwirkung des http Themas ist?
2x Raspberry 3B+, 1x Raspberry 4, Signalduino 433 (Somfy), CUL_HM (HM-MOD-RPI-PCB), MQTT, Hue, ConBee 2, Sonos, AVM DECT, Netatmo, eufy, Nuki,

Otto123

Zitat von: Udomatic am 14 Februar 2020, 13:35:58
Ja, das habe ich leider komplett gelöscht. fhem.cfg manuell editieren nötig?
Niemals :)
Brauchst Du doch nicht, weg ist weg und stört nicht. (Mich stört es immer)Du kannst es jederzeit einrichten:
define initialUsbCheck notify global:INITIALIZED usb create
attr initialUsbCheck disable 1
Aber wozu?

Wir reden derzeit darüber, dass Dein FHEM heute Nacht offenbar eventuell für eine 1h eingefroren war:
Zitat2020.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)
Wenn der FHEM Prozess steht steht alles, da redet auch keiner mehr mit dem Homematic Modul.

Wobei wenn ich mir die zeitliche Reihenfolge anschaue: Nach 1:14 kommt 0:14 - das ist auch eigenartig.
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)
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

Udomatic

Zitat von: Otto123 am 14 Februar 2020, 13:55:55
Niemals :)
Brauchst Du doch nicht, weg ist weg und stört nicht. (Mich stört es immer)Du kannst es jederzeit einrichten:
define initialUsbCheck notify global:INITIALIZED usb create
attr initialUsbCheck disable 1
Aber wozu?

Wir reden derzeit darüber, dass Dein FHEM heute Nacht offenbar eventuell für eine 1h eingefroren war:Wenn der FHEM Prozess steht steht alles, da redet auch keiner mehr mit dem Homematic Modul.

Wobei wenn ich mir die zeitliche Reihenfolge anschaue: Nach 1:14 kommt 0:14 - das ist auch eigenartig.
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)


Ja, verstehe ich auch nicht. So ging das Log dann weiter:

2020.02.14 00:22:53 1: RMDIR: ./restoreDir/save/2020-02-11
2020.02.14 00:37:34 3: CUL_HM set Office_Temp getConfig
2020.02.14 01:14:25 0: SONOS0: Das Lauschen auf der Schnittstelle wurde beendet. Prozess endet nun auch...
2020.02.14 01:28:14 1: Calendar Abfallkalender_Web: retrieval failed with error message read from http://www.roedermark.mein-abfallkalender.de:80 timed out
2020.02.14 01:28:14 1: Calendar Abfallkalender_Web: retrieved no or empty data
2020.02.14 01:28:14 3: ABFALL Muell - CALENDAR:Abfallkalender_Web triggered, updating ABFALL Muell ...
2020.02.14 01:28:16 1: [Freezemon] myFreezemon: possible freeze starting at 01:28:15, delay is 1.013 possibly caused by: tmr-MQTT2_SERVER_keepaliveChecker(mqtt2s) tmr-HttpUtils_Err(N/A)
2020.02.14 03:41:25 1: [Freezemon] myFreezemon: possible freeze starting at 03:41:21, delay is 4.81 possibly caused by: no bad guy found :-(
2020.02.14 03:41:27 1: [Freezemon] myFreezemon: possible freeze starting at 03:41:26, delay is 1.914 possibly caused by: tmr-MQTT2_SERVER_keepaliveChecker(mqtt2s)
2020.02.14 07:00:00 3: FHEMBackupOn return value: -1
/backup bereits vorhanden
2020.02.14 07:00:45 1: [Freezemon] myFreezemon: possible freeze starting at 07:00:44, delay is 1.314 possibly caused by: no bad guy found :-(
PING 192.168.178.6 (192.168.178.6) 56(84) bytes of data.
64 bytes from 192.168.178.6: icmp_seq=1 ttl=64 time=0.338 ms

--- 192.168.178.6 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.338/0.338/0.338/0.000 ms
192.168.178.6 erreichbar
/QNAP-TS251B/backup bereits vorhanden
/QNAP-TS251B/backup leer, Mounten starten
mountComplete: //192.168.178.6/backup /QNAP-TS251B/backup cifs username=fhem,password=fhembackup,iocharset=utf8,sec=ntlmv2,vers=3.0 0 0
mountComplete: //192.168.178.6/backup /QNAP-TS251B/backup cifs username=fhem,password=fhembackup,iocharset=utf8,sec=ntlmv2,vers=3.0 0 0
mountComplete: //192.168.178.6/backup /QNAP-TS251B/backup cifs username=fhem,password=fhembackup,iocharset=utf8,sec=ntlmv2,vers=3.0 0 0
mountComplete: //192.168.178.6/backup /QNAP-TS251B/backup cifs username=fhem,password=fhembackup,iocharset=utf8,sec=ntlmv2,vers=3.0 0 0
mountComplete: //192.168.178.6/backup /QNAP-TS251B/backup cifs username=fhem,password=fhembackup,iocharset=utf8,sec=ntlmv2,vers=3.0 0 0
mountComplete: //192.168.178.6/backup /QNAP-TS251B/backup cifs username=fhem,password=fhembackup,iocharset=utf8,sec=ntlmv2,vers=3.0 0 0
/etc/fstab: Eintrag bereits vorhanden: //192.168.178.6/backup /QNAP-TS251B/backup cifs username=fhem,password=fhembackup,iocharset=utf8,sec=ntlmv2,vers=3.0 0 0
Mounts werden aktualisiert
/QNAP-TS251B/backup//rpi/fhem/192.168.178.55 existiert bereits
200214_070000_fhem_backup.tar.gz (110 MB) wird in den Backupordner verschoben
{"status":1,"request":"dbffe8d8-a2ea-448b-9557-740a481b43ee"}21 Backups vorhanden - nur 20 aktuelle Backups werden vorgehalten - 1 Backups werden gelöscht
Mount wieder unmounten
2020.02.14 08:02:46 1: [Freezemon] myFreezemon: possible freeze starting at 07:02:47, delay is 3599.008 possibly caused by: no bad guy found :-(
2020.02.14 07:02:47 1: HMUARTLGW LAN_HmUART did not respond for the 1. time, resending
2020.02.14 07:02:47 1: HMUARTLGW LAN_HmUART did not respond for the 2. time, resending
2020.02.14 08:03:20 3: mqtt2s: mqtt2s_192.168.178.32_50133/Blitzwolf-BWSHP2-02 left us (keepalive check)
2020.02.14 07:03:20 3: mqtt2s: mqtt2s_192.168.178.49_58774/Blitzwolf-BWSHP2-01 left us (keepalive check)
2020.02.14 07:03:20 3: mqtt2s: mqtt2s_192.168.178.24_48156/shellyswitch25-B89E2D left us (keepalive check)
2020.02.14 07:03:20 3: mqtt2s: mqtt2s_192.168.178.22_48426/shellyplug-s-040CA2 left us (keepalive check)
2020.02.14 07:03:20 3: mqtt2s: mqtt2s_192.168.178.20_62478/shellyplug-s-041439 left us (keepalive check)
2020.02.14 07:03:20 3: mqtt2s: mqtt2s_192.168.178.23_61667/shellyplug-s-7A2FD2 left us (keepalive check)
2020.02.14 07:04:33 3: radinoCC1101: KeepAlive, not ok, retry = 2 -> get ping
2020.02.14 07:04:47 0: SONOS0: Das Lauschen auf der Schnittstelle wurde beendet. Prozess endet nun auch...
2x Raspberry 3B+, 1x Raspberry 4, Signalduino 433 (Somfy), CUL_HM (HM-MOD-RPI-PCB), MQTT, Hue, ConBee 2, Sonos, AVM DECT, Netatmo, eufy, Nuki,

Udomatic

Hallo,

gestern war es mal wieder soweit und ich hatte Probleme mit disconnects der UART Adapter. Alles im Zusammnehang mit einem ConBee II Update. Zuvor Freezes in FHEM.
Vor einiger Zeit hatte ich mal gelesen, dass der ConBee Stick direkt am USB Port des PI zu Problemen führen kann. Verstanden habe ich nicht warum. Da ich keine andere Lösung wusste habe ich den ConBee nun über ein USB Verlängerungskabel am PI angeschlossen.

Jetzt funktioniert wohl wieder alles und beide HMUART Adpater sind nun in FHEM verfügbar. Die Ganze Zeit ging immer nur einer und der zweit HMUART und der andere hatte mit Disconects zu kämpfen!

Das freut mich riesig! Hat jemand eine Erklärung der Zusammenhänge?
2x Raspberry 3B+, 1x Raspberry 4, Signalduino 433 (Somfy), CUL_HM (HM-MOD-RPI-PCB), MQTT, Hue, ConBee 2, Sonos, AVM DECT, Netatmo, eufy, Nuki,