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

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

Vorheriges Thema - Nächstes Thema

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,