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
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
Hallo Udo,
Du kannst doch das Funkmodul einfach mal umstecken?
Gruß Otto
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?
Nein.
Das sieht komisch aus:
2020-01-28 21:09:02 D-firmware unsupported
Ist das wirklich ein HM-MOD-UART ?
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)
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?
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?
es muss - ohne "
core_freq=250
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.
kannst Du mal bitte ein aktuelles list myHmUART posten?
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 (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?
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
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
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)
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
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.
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?!
Wie ist denn das Modul mit dem Pi verbunden: USB oder GPIO? Stimmen dort dann Adresse sowie Baudrate?
Gesendet von iPhone mit Tapatalk Pro
GPIO und stimmt (Gestern um 23:14:03):
ZitatDeviceName /dev/ttyAMA0@115200
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".
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 SystemInternals:
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 Log2020.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?
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 (https://heinz-otto.blogspot.com/2019/05/setup-raspberry-pi-2019.html) nutzen. Damit geht das schnell und dauert nur wenige Minuten.
Gruß Otto
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.
FHEM blockiert zeitweise?
Hast mal nach freezes gesucht? freezemon definiert?
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?
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
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__)
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)
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.
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.
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 ...
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
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.
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?
so (https://wiki.fhem.de/wiki/HM-MOD-RPI-PCB_HomeMatic_Funkmodul_f%C3%BCr_Raspberry_Pi#Remoteanbindung_-_Pi_.2B_RPI_Modul_.3D_LAN_Modul):)
Also
1. VCCU machen (https://wiki.fhem.de/wiki/Virtueller_Controller_VCCU)
2. IOList setzen
3. Remote Pi per ser2net einbinden
4. In die IOList eintragen
5. alten lokale Def pausieren: attr DUMMY
Zitat von: Otto123 am 12 Februar 2020, 12:36:35
so (https://wiki.fhem.de/wiki/HM-MOD-RPI-PCB_HomeMatic_Funkmodul_f%C3%BCr_Raspberry_Pi#Remoteanbindung_-_Pi_.2B_RPI_Modul_.3D_LAN_Modul):)
Also
1. VCCU machen (https://wiki.fhem.de/wiki/Virtueller_Controller_VCCU)
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 (https://wiki.fhem.de/wiki/HM-MOD-RPI-PCB_HomeMatic_Funkmodul_f%C3%BCr_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
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?
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?
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
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?
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?
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
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)
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
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?
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.
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!
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
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
@udomatic
hast du eventuell eine "virtuelle ccu" (debmatic, pivccu, ...) auf deinem lokalen pi, so dass der hmuart in fhem immer disconnected?
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
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.
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?
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
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.
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?
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 ...
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.
Die Antwort steht doch schon in #54 ?
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.
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)}
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
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
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.
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?
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)
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...
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?