Hallo zusammen,
ich habe leider ein Problem, welchem ich nicht auf die Spur komme. Ich verwende FHEM seit vielen Jahren und hatte nur ein mal ein Problem mit der Stabilität, damals konnte das durch ein Firmwareupdate (auf 0.965) der HMLANs beheben.
Daraufhin gehörten Disconnects wieder der Vergangenheit an. Leider habe ich wieder das gleiche Problem - die HMLANs rebooten anscheinend immer wieder:
FHEM Uptime: 10 Tage
HMLAN1 uptime 001 46:21:08.825
HMLAN2 uptime 000 01:43:23.690
Meine Konfiguration:
- Ubuntu 18.04 VM auf einem XenServer 7.1 (seit Jahren bis auf das einspielen von Patches unverändert)
- Zwei HMLAN (01/02)
- vccu
- HMLAN1: msgKeepAlive dlyMax:3.008 bufferMin:1
- HMLAN2: msgKeepAlive dlyMax:0.936 bufferMin:4
Was habe ich bereits probiert:
- Upgrade des OS von Ubunt 16.04 auf 18.04 --> Keine Verbesserung
- Erstellen eines eignen VLAN für FHEM (nur die zwei HMLANS und die FHEM VM) --> keine Verbesserung
- testhalber löschen von fast jedem Code aus der fhem.cfg --> keine Verbesserung
Ich habe Logging mit verbos 5 aktiviert und hoffe, es kann mir jemand einen Tipp geben, wo ich suchen soll oder welche Informationen noch benötigt werden! Ich habe 300MB Logfile über die letzten 10 Tage gesammelt, hier aber nur einige Schnipsel angehängt. Ich kann gerne mehr zur Verfügung stellen.
Ich bin für jeden Tipp dankbar!!
wieviel stunden/jahre haben die drauf?
vielleicht mal kondensatoren tauschen?
Sind ca. 5 Jahre alt - Dauerbetrieb...
Hi. Ich hatte vor kurzem extrem häufige Reboots. Am Ende lag es m.E daran dass ich den Raspi über Powerline angeschlossen hatte. Scheint ein Synchronisationsproblem damit zu geben. Seit der Raspi am Gigabitnetzwerk hängt, gehts wieder deutlich besser!
Das kann ich bestätigen.
Ich habe einen HMLAN direkt am LAN und einen über Powerline gekoppelt. Jeweils der (auch nach tauschen der HMLAN) über Powerline zeigt zwischen keinem und ca. 10 Disconnects am Tag.
Laut dlyMax kommen die Keepalive ja rechtzeitig.
Außerdem scheint es ja wirklich reboots zu geben, nicht nur disconnects.
In dem Fall würde ich mal ein anderes Steckernetzteil probieren, oder halt auch die Elkos im HMLAN tauschen. Die waren scheinbar nicht soo toll.
Eben, deshalb kann ich mir das ganze ja nicht erklären. Bei einem Netzwerk "Hicup" würde es zwar einen Disconnect, aber keinen Reboot geben und Laut dlyMax, apptime und Log kann zumindest ich keinen Fehler erkennen.
An einen HW Fehler hätte ich nicht gedacht, da es beide betrifft, aber vielleicht ist das ja wirklich der Grund!
Ich habe bereits nach Kondensatortasuch gesucht, aber leider nichts gefunden - hätte Ihr einen Link für mich?
Bevor ich jetzt den Lötkolben auspacke, kann sich noch jemand einen anderen Grund vorstellen?
ZitatIch habe bereits nach Kondensatortasuch gesucht, aber leider nichts gefunden - hätte Ihr einen Link für mich?
Im endefekt mußt du die dicken Kondensatoren austauschen
ein apptime fehlt trotzdem
und hast du IP tv inzwischen? scheint auch ein Problem gewesen zu sein
PS meine HMlans sind auch schon 8 Jahre alt und zeigen noch kein Problem.
Oups, du hast natürlich recht, apptime hab ich nicht angehängt - sorry. War gerade nicht aktiv, lasse apptime ein paar tage laufen und stelle es rein, wenn es einige Disconnects gegeben hat.
Was meinst Du mit IP TV? Ich verwende seit Ewigkeiten TVHeadend (Streamingserver mit einer Satkarte in einer VM am gleichen XenServer) und mehrere XBMC/Kodi Mediacenter, das gibts aber alles schon länger als meine FHEM, Homematic installation...
Nun noch das fehlende apptime. Log ist wieder auf verbose 1 zurückgestellt.
Disconnects aus dem Logfile:
2018.12.30 01:22:03 1: HMLAN_Parse: HMLAN2 new condition disconnected
2018.12.30 01:22:03 1: 192.168.101.32:1000 disconnected, waiting to reappear (HMLAN2)
2018.12.30 01:22:03 1: HMLAN_Parse: HMLAN2 new condition disconnected
2018.12.30 01:23:08 1: HMLAN_Parse: HMLAN2 new condition init
2018.12.30 01:23:08 1: 192.168.101.32:1000 reappeared (HMLAN2)
2018.12.30 01:23:08 1: HMLAN_Parse: HMLAN2 new condition ok
2018.12.30 05:54:47 1: HMLAN_Parse: HMLAN2 new condition disconnected
2018.12.30 05:54:47 1: 192.168.101.32:1000 disconnected, waiting to reappear (HMLAN2)
2018.12.30 05:54:47 1: HMLAN_Parse: HMLAN2 new condition disconnected
2018.12.30 05:55:52 1: HMLAN_Parse: HMLAN2 new condition init
2018.12.30 05:55:52 1: 192.168.101.32:1000 reappeared (HMLAN2)
2018.12.30 05:55:53 1: HMLAN_Parse: HMLAN2 new condition ok
2018.12.30 09:07:47 1: HMLAN_Parse: HMLAN2 new condition disconnected
2018.12.30 09:07:47 1: 192.168.101.32:1000 disconnected, waiting to reappear (HMLAN2)
2018.12.30 09:07:47 1: HMLAN_Parse: HMLAN2 new condition disconnected
2018.12.30 09:08:51 1: HMLAN_Parse: HMLAN2 new condition init
2018.12.30 09:08:51 1: 192.168.101.32:1000 reappeared (HMLAN2)
2018.12.30 09:08:52 1: HMLAN_Parse: HMLAN2 new condition ok
2018.12.30 11:51:22 1: HMLAN_Parse: HMLAN1 new condition disconnected
2018.12.30 11:51:22 1: 192.168.101.31:1000 disconnected, waiting to reappear (HMLAN1)
2018.12.30 11:51:22 1: HMLAN_Parse: HMLAN1 new condition disconnected
2018.12.30 11:52:28 1: HMLAN_Parse: HMLAN1 new condition init
2018.12.30 11:52:28 1: 192.168.101.31:1000 reappeared (HMLAN1)
2018.12.30 11:52:28 1: HMLAN_Parse: HMLAN1 new condition ok
apptime seit Gestern:
active-timers: 26; max-active timers: 50; max-timer-load: 6 min-tmrHandlingTm: 0.0ms; max-tmrHandlingTm: 73.7ms; totAvgDly: 3.4ms
name function max count total average maxDly avgDly TS Max call param Max call
HMLAN2 HMLAN_Ready 3029 108 9066.16 83.95 0.00 0.00 30.12. 05:54:52 HASH(HMLAN2)
HMLAN1 HMLAN_Ready 3003 52 3015.07 57.98 0.00 0.00 30.12. 11:51:26 HASH(HMLAN1)
HMLAN2 HMLAN_Read 115 12672 22477.90 1.77 0.00 0.00 29.12. 21:02:03 HASH(HMLAN2)
HMLAN1 HMLAN_Read 101 12593 25097.33 1.99 0.00 0.00 29.12. 21:01:55 HASH(HMLAN1)
tmr-CUL_HM_motionCheck OG_Klo_Taster_Btn_01 73 1 73.65 73.65 0.35 0.35 29.12. 21:01:37 OG_Klo_Taster_Btn_01:motionCheck
ntfy.set.OG_Klo_Taster_Btn_01.Nacht.on notify_Exec 72 2 76.35 38.18 0.00 0.00 29.12. 21:01:37 HASH(ntfy.set.OG_Klo_Taster_Btn_01.Nacht.on); HASH(OG_Klo_Taster_Btn_01)
OG_Klo_Licht_Decke CUL_HM_Set 68 73 210.98 2.89 0.00 0.00 29.12. 21:01:37 HASH(OG_Klo_Licht_Decke); OG_Klo_Licht_Decke; 20; 120; 0.5
tmr-HMinfo_autoUpdate sUpdt 53 188 3811.71 20.28 6.78 1.41 29.12. 22:36:03 sUpdt:hm
Alle_Lichter structure_Set 36 12 36.65 3.05 0.00 0.00 29.12. 21:07:44 HASH(Alle_Lichter); Alle_Lichter; ?
ntfy.cnt.Bewegung.AA_Bewegung notify_Exec 29 19980 12038.98 0.60 0.00 0.00 30.12. 00:10:01 HASH(ntfy.cnt.Bewegung.AA_Bewegung); HASH(OG_Gang_Bewegung_01)
tmr-CUL_HM_motionCheck UG_Stiege_Bewegung_01 27 8 81.54 10.19 3.08 1.22 29.12. 21:19:32 UG_Stiege_Bewegung_01:motionCheck
ntfy.cnt.Tueren.AA_Offene_Tueren notify_Exec 25 19980 1478.06 0.07 0.00 0.00 29.12. 23:55:39 HASH(ntfy.cnt.Tueren.AA_Offene_Tueren); HASH(OG_Klo_Tuer_01)
OG_Lichter structure_Set 22 12 23.00 1.92 0.00 0.00 29.12. 21:07:44 HASH(OG_Lichter); OG_Lichter; ?
OG_WoZi_Licht_Esstisch_Sw CUL_HM_Set 21 14 66.71 4.77 0.00 0.00 29.12. 21:07:47 HASH(OG_WoZi_Licht_Esstisch_Sw); OG_WoZi_Licht_Esstisch_Sw; off
tmr-CUL_HM_motionCheck EG_Gang_Bewegung_01 20 26 223.82 8.61 9.15 2.40 29.12. 21:59:51 EG_Gang_Bewegung_01:motionCheck
tmr-CUL_HM_respPendTout respPend 19 135 230.28 1.71 82.96 2.46 29.12. 23:52:46 respPend:4C2D88
tmr-watchdog_Trigger HASH(0x55cfe3b396f0) 15 7 71.73 10.25 8.24 3.87 29.12. 22:06:54 HASH(watchdog_OG_Kueche_Taster_01_Motion)
OG_Kueche_Licht_Decke_Sw CUL_HM_Set 15 15 119.32 7.95 0.00 0.00 29.12. 22:06:54 HASH(OG_Kueche_Licht_Decke_Sw); OG_Kueche_Licht_Decke_Sw; 0; 0; 10
tmr-CUL_HM_motionCheck OG_Stiege_Bewegung_01 15 5 42.12 8.42 5.13 1.84 29.12. 21:34:12 OG_Stiege_Bewegung_01:motionCheck
tmr-CUL_HM_motionCheck OG_Gang_Bewegung_01 14 31 240.35 7.75 8.54 3.09 30.12. 12:13:45 OG_Gang_Bewegung_01:motionCheck
ntfy.cnt.Kellerfenster.AA_Offene_Fenster_UG notify_Exec 14 19980 1574.14 0.08 0.00 0.00 30.12. 00:46:55 HASH(ntfy.cnt.Kellerfenster.AA_Offene_Fenster_UG); HASH(UG_Heizraum_Fenster_02)
AA_Bewegung dummy_Set 12 4551 3250.67 0.71 0.00 0.00 29.12. 21:19:32 HASH(AA_Bewegung); AA_Bewegung; 2
tmr-CUL_HM_motionCheck UG_Trockenraum_Bewegung_01 11 4 39.65 9.91 2.70 1.44 30.12. 11:51:43 UG_Trockenraum_Bewegung_01:motionCheck
ntfy.cnt.Fenster.AA_Offene_Fenster notify_Exec 10 19980 1894.77 0.09 0.00 0.00 30.12. 10:09:56 HASH(ntfy.cnt.Fenster.AA_Offene_Fenster); HASH(EG_Gang_Fenster_01)
tmr-CUL_HM_qStateUpdatIfEnab sUpdt 10 51 182.53 3.58 16.04 2.94 29.12. 21:45:09 sUpdt:OG_Kueche_Licht_Decke_Sw
tmr-CUL_HM_motionCheck UG_Werksatt_Bewegung_01 9 1 9.83 9.83 0.37 0.37 29.12. 21:01:37 UG_Werksatt_Bewegung_01:motionCheck
tmr-CUL_HM_motionCheck GT_Hinten_Bewegung_01 9 4 29.76 7.44 9.58 3.06 29.12. 21:01:36 GT_Hinten_Bewegung_01:motionCheck
AA_Offene_Tueren dummy_Set 8 370 260.16 0.70 0.00 0.00 29.12. 23:55:39 HASH(AA_Offene_Tueren); AA_Offene_Tueren; 1
tmr-CUL_HM_motionCheck GT_Eingang_Bewegung_02 8 2 15.99 7.99 0.74 0.56 30.12. 09:09:18 GT_Eingang_Bewegung_02:motionCheck
tmr-CUL_HM_motionCheck GT_Eingang_Bewegung_01 7 6 38.41 6.40 12.00 3.46 29.12. 21:01:36 GT_Eingang_Bewegung_01:motionCheck
tmr-watchdog_Trigger HASH(0x55cfe3b3f3d0) 7 12 55.78 4.65 5.79 2.30 30.12. 00:15:01 HASH(watchdog_OG_Gang_Bewegung_01)
tmr-CUL_HM_motionCheck EG_VoZi_Bewegung_01 7 13 91.52 7.04 1462.72 113.74 30.12. 11:43:58 EG_VoZi_Bewegung_01:motionCheck
OG_Gang_Licht_Decke CUL_HM_Set 7 12 52.44 4.37 0.00 0.00 30.12. 00:15:01 HASH(OG_Gang_Licht_Decke); OG_Gang_Licht_Decke; 0; 0; 10
OG_WoZi_Licht_Indirekt CUL_HM_Set 7 17 65.36 3.84 0.00 0.00 30.12. 00:01:33 HASH(OG_WoZi_Licht_Indirekt); OG_WoZi_Licht_Indirekt; off
AA_Offene_Fenster_UG dummy_Set 7 230 635.68 2.76 0.00 0.00 29.12. 21:57:22 HASH(AA_Offene_Fenster_UG); AA_Offene_Fenster_UG; 0
ntfy.set.OG_Klo_Tuer_01.OG_Klo_Licht_Decke.on notify_Exec 7 122 39.75 0.33 0.00 0.00 30.12. 00:01:59 HASH(ntfy.set.OG_Klo_Tuer_01.OG_Klo_Licht_Decke.on); HASH(OG_Klo_Tuer_01)
ntfy.set.OG_Klo_Taster_Motion.OG_Klo_Licht_Decke.on notify_Exec 7 38 69.15 1.82 0.00 0.00 30.12. 00:02:00 HASH(ntfy.set.OG_Klo_Taster_Motion.OG_Klo_Licht_Decke.on); HASH(OG_Klo_Taster_Motion)
tmr-at_Exec HASH(0x55cfe3dd5330) 6 942 1016.32 1.08 3004.24 7.71 30.12. 06:25:03 HASH(at.upd.HMLAN2_Funklast)
GT_Lichter structure_Set 6 3 6.75 2.25 0.00 0.00 29.12. 21:07:44 HASH(GT_Lichter); GT_Lichter; ?
ntfy.set.OG_Klo_Taster_Btn_02.Nacht.off notify_Exec 6 2 9.76 4.88 0.00 0.00 30.12. 11:37:52 HASH(ntfy.set.OG_Klo_Taster_Btn_02.Nacht.off); HASH(OG_Klo_Taster_Btn_02)
tmr-HMLAN_KeepAliveCheck keepAliveCk 6 4608 112.42 0.02 2032.51 1.51 30.12. 05:54:47 keepAliveCk:HMLAN2
Irgendwelche Ideen?
Auf jeden Fall auch ein Herzliches Danke für Eure bisherige Unterstützung! :-)
LG,
Kurt
Mir fällt da nur Dein "Bewegungsmelder" auf, aber ich kann das nicht wirklich deuten.
Kannst Du den vielleicht mal "auskommentieren" zum Testen, oder hat der vielleicht irgendwelche Probleme?
Zu dem Thema gibt es ja noch diesen Thread: https://forum.fhem.de/index.php/topic,20776.0.html (https://forum.fhem.de/index.php/topic,20776.0.html)
Ich habe vier HMLAN seit einigen Jahren mit neuster Firmware. Mittlerweile sind diese in einem eigenen VLAN für FHEM und zusätzlich ist seit kurzem noch eine Port-Isolation am Switch für den exklusiven Zugriff durch den FHEM Servers eingerichtet. Trotzdem häufen sich wieder die Disconnects (mit Reboot). Entweder sind das die HM-IP Geräte des Nachbarn oder die Elkos sind langsam hin. Nach all den schon vorgenommenen Maßnahmen tippe ich mittlerweile auf die Elkos und werde diese zeitnah tauschen.
Zitat von: Deudi am 04 Januar 2019, 14:43:09
Zu dem Thema gibt es ja noch diesen Thread: https://forum.fhem.de/index.php/topic,20776.0.html (https://forum.fhem.de/index.php/topic,20776.0.html)
Ich habe vier HMLAN seit einigen Jahren mit neuster Firmware. Mittlerweile sind diese in einem eigenen VLAN für FHEM und zusätzlich ist seit kurzem noch eine Port-Isolation am Switch für den exklusiven Zugriff durch den FHEM Servers eingerichtet. Trotzdem häufen sich wieder die Disconnects (mit Reboot). Entweder sind das die HM-IP Geräte des Nachbarn oder die Elkos sind langsam hin. Nach all den schon vorgenommenen Maßnahmen tippe ich mittlerweile auf die Elkos und werde diese zeitnah tauschen.
Hallo Deudi,
wie ist der Stand bei deinen HMLANs? Hat der Austausch der Elkos was gebracht?
Bei mir erscheint häufig beim Freezmon als Ursache:
HMLAN_KeepAliveCheckViele Grüße Gisbert
Disconnects wegen "keppAlive" haben m.E. nichts mit den Elkos zu tun.
Abstürze/Reboot wegen Spannungseinbruch = Elkos trocken = Kapazitätsverlust = tauschen
Disconnetcs wegen keepAlive = Störungen/Verzögerungen im Netzwerk = analysieren/testen/verbessern
Anmerkung:
Ich habe 2 HMLAN (mit getauschten Elkos und externer Antenne) im gemeinsamen LAN und in den letzten Monaten/Jahren? keine erkennbaren Probleme (LOG jetzt nicht kontrolliert).
P.S.:
Ich habe die zugehörigen LAN-Ports mal irgendwann auf die zugehörige Einstellung "festgenagelt", damit die Auto-Erkennung und Green-Funktionen usw. da nicht reinfunkt.
Hallo Hollo,
ZitatDisconnetcs wegen keepAlive = Störungen/Verzögerungen im Netzwerk = analysieren/testen/verbessern
Danke für den Hinweis, aber wie analysiert, testet und vebessert man denn?
Ich hab den HMLAN jetzt in etwa an die Stelle verpflanzt, an der er 3,5 Jahre stand, vor ca. einem halben Jahr habe ich ihn umgesetzt.
Vorher war er näher am Router dran, jetzt ist er das wieder.
Erwähnen sollte ich vielleicht noch, dass ich vor ca. einem Jahr (Februar/März 2018) die Stummelantenne gegen eine Groundplane-Antenne geatauscht habe.
Damit haben sich Empfangsleistungen signifikant verbessert, ca. 5-10 dB.
Ich führe die Probleme nicht auf die Groundplane-Antenne zurück, da die Probleme deutlich später auftauchten.
Den Austausch der beiden großen Elkos hat das Teil zumindest überlebt; da ich nicht genau die gleichen hatte, habe ich 25V/470µF statt der 25V/100µF mit der gleichen Baugröße reingelötet.
Ich werde mal beobachten, wie es jetzt aussieht.
Der HMLAN hat eine feste IP-Adresse, daran kann es also nicht liegen.
Viele Grüße Gisbert
starte mal apptime und lass es vielleicht 2 stunden laufen, so dass ein paar disconnects in der zeit vorgekommen sind. danach poste dann "apptime max".
schau ebenfalls beim hmlan, ob die uptime während dieser zeit durchlief, oder resettet wurde. wie viele disconnects gab es in dieser zeit?
gibt es eine wlan-strecke zwischen hmlan und fhem?
Hallo frank,
eine neue (eigentlich alte) Position des HMLAN (keine Switches zwischen dem HMLAN und dem Router) hat keine Verbesserung gebracht.
Nachdem ich ihn vorgestern abend wieder am Strom hatte, steht uptime jetzt bei: "uptime 001 40:24:02.877", d.h. neu gestartet wurde das Gerät offensichtlich nicht.
In dieser Zeit steht das Reading bei "Xmit-Events disconnected:150 ok:76 init:76", also viele disconnects in den 40 Stunden Betriebszeit.
Ich hatte gestern morgen, also ca. vor 28 Stunden Fhem neu gestartet und apptime gestartet.
Hier ist die Ausgabe von apptime:
active-timers: 162; max-active timers: 208; max-timer-load: 7 min-tmrHandlingTm: 0.0ms; max-tmrHandlingTm: 855.6ms; totAvgDly: 331.8ms
name function max count total average maxDly avgDly TS Max call param Max call
Callmonitor FB_CALLMONITOR_Read 5494 13 5882.15 452.47 0.00 0.00 25.06. 11:25:51 HASH(Callmonitor)
HMLAN1 HMLAN_Ready 3006 18608 255950.13 13.75 0.00 0.00 25.06. 18:02:04 HASH(HMLAN1)
myHmUARTLGW1 HMUARTLGW_Read 1155 10046 57500.14 5.72 0.00 0.00 25.06. 09:16:47 HASH(myHmUARTLGW1)
Garage.notify notify_Exec 1117 3 3279.20 1093.07 0.00 0.00 25.06. 09:16:47 HASH(Garage.notify); HASH(Handsender.04)
myRollladenGarage dummy_Set 1116 18 3276.33 182.02 0.00 0.00 25.06. 09:16:47 HASH(myRollladenGarage); myRollladenGarage; up
notifyRollladenControl notify_Exec 1104 100909 52797.40 0.52 0.00 0.00 25.06. 09:16:47 HASH(notifyRollladenControl); HASH(myRollladenGarage)
WEB FW_Read 1094 1004 45379.51 45.20 0.00 0.00 25.06. 17:51:34 HASH(WEB)
tmr-Calendar_PollChild HASH(0x55ff95fabc60) 800 6 4358.82 726.47 113.35 26.46 26.06. 00:19:53 HASH(Muelltonnen.Kalender.AVEA)
myMuell ABFALL_Notify 691 30 3742.23 124.74 0.00 0.00 26.06. 00:19:53 HASH(myMuell); HASH(Muelltonnen.Kalender.AVEA)
Battery.State readingsGroup_Notify 578 100909 104480.90 1.04 0.00 0.00 26.06. 02:20:31 HASH(Battery.State); HASH(Wetter.Proplanta)
mySIGNALduino SIGNALduino_Read 552 22310 175636.00 7.87 0.00 0.00 26.06. 00:22:39 HASH(mySIGNALduino)
tmr-DWD_OpenData::Timer HASH(0x55ff969589f8) 433 135 1921.00 14.23 3008.11 57.65 25.06. 09:00:05 HASH(DWD.Wetter.Leverkusen)
DLNASocket-myDLNARenderer-1900 DLNARenderer_Read 423 8099 4811.83 0.59 0.00 0.00 25.06. 12:17:09 HASH(DLNASocket-myDLNARenderer-1900)
MyBroker MQTT::Read 400 25747 877407.27 34.08 0.00 0.00 26.06. 00:22:42 HASH(MyBroker)
mySignalESPSMABuchse SIGNALduino_Read 352 7113 204664.61 28.77 0.00 0.00 25.06. 08:20:17 HASH(mySignalESPSMABuchse)
WEBtablet FW_Read 338 41 2541.42 61.99 0.00 0.00 25.06. 18:37:21 HASH(WEBtablet)
mySignalESPHelicalAntenna SIGNALduino_Read 216 9670 65272.12 6.75 0.00 0.00 25.06. 08:21:52 HASH(mySignalESPHelicalAntenna)
DLNASocket-myDLNARenderer-37723 DLNARenderer_Read 207 8 562.62 70.33 0.00 0.00 25.06. 12:17:10 HASH(DLNASocket-myDLNARenderer-37723)
Haushaltsraum.Lueftung DOIF_Notify 199 100909 13613.91 0.13 0.00 0.00 26.06. 00:22:42 HASH(Haushaltsraum.Lueftung); HASH(Haushaltsraum.Ventilator)
tmr-SYSMON_Update HASH(0x55ff9814a410) 194 1630 58102.33 35.65 589.65 2.60 26.06. 00:15:47 HASH(T610.Sysmon)
tmr-Calendar_PollChild HASH(0x55ff961b2578) 172 4 601.13 150.28 223.88 130.14 26.06. 08:19:54 HASH(NRW.Feiertage.Kalender)
tmr-DOIF_TimerTrigger REF(0x55ff9bdb09f0) 163 1 163.47 163.47 101.28 101.28 26.06. 00:19:47 REF(0x55ff9bdb09f0)
Klingeln DOIF_Notify 151 100909 5839.40 0.06 0.00 0.00 26.06. 10:11:19 HASH(Klingeln); HASH(Klingel)
HMLAN1 HMLAN_Read 143 7694 69744.90 9.06 0.00 0.00 25.06. 18:03:05 HASH(HMLAN1)
tmr-statistics_PeriodChange HASH(0x55ff975b5838) 134 27 2143.97 79.41 72.44 6.04 25.06. 23:59:55 HASH(Statistik)
tmr-FRITZBOX_Readout_Start FritzBox6490.Readout 119 814 15620.32 19.19 3006.38 14.80 26.06. 08:24:11 FritzBox6490.Readout
tmr-DOIF_TimerTrigger REF(0x55ff9d5ac1d0) 116 1 116.59 116.59 10.14 10.14 26.06. 09:00:00 REF(0x55ff9d5ac1d0)
Spitzboden.Lueftung DOIF_Notify 116 100909 38316.03 0.38 0.00 0.00 26.06. 03:00:30 HASH(Spitzboden.Lueftung); HASH(Spitzboden.Ventilator)
tmr-DOIF_TimerTrigger REF(0x55ff99a5d988) 106 1 106.32 106.32 3.97 3.97 26.06. 05:15:00 REF(0x55ff99a5d988)
tmr-DOIF_TimerTrigger REF(0x55ff99a5dca0) 106 1 106.28 106.28 1.70 1.70 25.06. 21:15:00 REF(0x55ff99a5dca0)
tmr-DOIF_SleepTrigger HASH(0x55ff929b36e0) 101 11 986.30 89.66 12.47 2.46 26.06. 09:21:03 HASH(CamWatchAlarm.on)
tmr-DOIF_SleepTrigger HASH(0x55ff98122aa0) 101 664 15132.54 22.79 321.34 8.51 26.06. 09:02:31 HASH(Warmwasser.Zirkulation)
tmr-DOIF_SleepTrigger HASH(0x55ff92b6f920) 100 594 41972.42 70.66 2597.40 21.58 25.06. 17:59:22 HASH(Anwesenheit.Zuhause)
tmr-FHEM::Astro::Update HASH(0x55ff97018828) 98 27 1345.29 49.83 162.65 29.83 26.06. 00:19:54 HASH(myAstro)
tmr-DOIF_TimerTrigger REF(0x55ff9bd015d8) 97 1 97.09 97.09 3.86 3.86 26.06. 00:19:47 REF(0x55ff9bd015d8)
Update.Dieselpreise DOIF_Notify 94 100909 13765.27 0.14 0.00 0.00 26.06. 09:24:59 HASH(Update.Dieselpreise); HASH(myUniFi)
tmr-at_Exec HASH(0x55ff91b22488) 94 54 4567.91 84.59 1.53 1.26 26.06. 02:19:35 HASH(addlog.myUniFi)
tmr-DOIF_TimerTrigger REF(0x55ff9d1751e8) 93 1 93.70 93.70 4.00 4.00 26.06. 07:00:00 REF(0x55ff9d1751e8)
tmr-DOIF_TimerTrigger REF(0x55ff9a5d7448) 87 1 87.85 87.85 6.02 6.02 25.06. 13:00:00 REF(0x55ff9a5d7448)
tmr-at_Exec HASH(0x55ff92e375a8) 87 1630 53180.05 32.63 459.44 3.21 25.06. 23:23:35 HASH(FritzBoxTraffic)
tmr-DOIF_TimerTrigger REF(0x55ff997ab610) 87 1 87.27 87.27 2.36 2.36 25.06. 21:19:47 REF(0x55ff997ab610)
apttime max liefert:
active-timers: 162; max-active timers: 208; max-timer-load: 7 min-tmrHandlingTm: 0.0ms; max-tmrHandlingTm: 855.6ms; totAvgDly: 330.4ms
name function max count total average maxDly avgDly TS Max call param Max call
Callmonitor FB_CALLMONITOR_Read 5494 13 5882.15 452.47 0.00 0.00 25.06. 11:25:51 HASH(Callmonitor)
HMLAN1 HMLAN_Ready 3006 18608 255950.13 13.75 0.00 0.00 25.06. 18:02:04 HASH(HMLAN1)
myHmUARTLGW1 HMUARTLGW_Read 1155 10089 57731.91 5.72 0.00 0.00 25.06. 09:16:47 HASH(myHmUARTLGW1)
Garage.notify notify_Exec 1117 3 3279.20 1093.07 0.00 0.00 25.06. 09:16:47 HASH(Garage.notify); HASH(Handsender.04)
myRollladenGarage dummy_Set 1116 18 3276.33 182.02 0.00 0.00 25.06. 09:16:47 HASH(myRollladenGarage); myRollladenGarage; up
notifyRollladenControl notify_Exec 1104 101373 53034.62 0.52 0.00 0.00 25.06. 09:16:47 HASH(notifyRollladenControl); HASH(myRollladenGarage)
WEB FW_Read 1094 1007 45424.88 45.11 0.00 0.00 25.06. 17:51:34 HASH(WEB)
tmr-Calendar_PollChild HASH(0x55ff95fabc60) 800 6 4358.82 726.47 113.35 26.46 26.06. 00:19:53 HASH(Muelltonnen.Kalender.AVEA)
myMuell ABFALL_Notify 691 30 3742.23 124.74 0.00 0.00 26.06. 00:19:53 HASH(myMuell); HASH(Muelltonnen.Kalender.AVEA)
Battery.State readingsGroup_Notify 578 101373 104536.08 1.03 0.00 0.00 26.06. 02:20:31 HASH(Battery.State); HASH(Wetter.Proplanta)
mySIGNALduino SIGNALduino_Read 552 22326 175645.38 7.87 0.00 0.00 26.06. 00:22:39 HASH(mySIGNALduino)
tmr-DWD_OpenData::Timer HASH(0x55ff969589f8) 433 136 1922.73 14.14 3008.11 57.25 25.06. 09:00:05 HASH(DWD.Wetter.Leverkusen)
DLNASocket-myDLNARenderer-1900 DLNARenderer_Read 423 8269 4881.89 0.59 0.00 0.00 25.06. 12:17:09 HASH(DLNASocket-myDLNARenderer-1900)
MyBroker MQTT::Read 400 25854 881172.23 34.08 0.00 0.00 26.06. 00:22:42 HASH(MyBroker)
mySignalESPSMABuchse SIGNALduino_Read 352 7141 205588.69 28.79 0.00 0.00 25.06. 08:20:17 HASH(mySignalESPSMABuchse)
WEBtablet FW_Read 338 41 2541.42 61.99 0.00 0.00 25.06. 18:37:21 HASH(WEBtablet)
mySignalESPHelicalAntenna SIGNALduino_Read 216 9721 65535.66 6.74 0.00 0.00 25.06. 08:21:52 HASH(mySignalESPHelicalAntenna)
DLNASocket-myDLNARenderer-37723 DLNARenderer_Read 207 8 562.62 70.33 0.00 0.00 25.06. 12:17:10 HASH(DLNASocket-myDLNARenderer-37723)
Haushaltsraum.Lueftung DOIF_Notify 199 101373 13712.83 0.14 0.00 0.00 26.06. 00:22:42 HASH(Haushaltsraum.Lueftung); HASH(Haushaltsraum.Ventilator)
tmr-SYSMON_Update HASH(0x55ff9814a410) 194 1637 58373.42 35.66 589.65 2.59 26.06. 00:15:47 HASH(T610.Sysmon)
tmr-Calendar_PollChild HASH(0x55ff961b2578) 172 4 601.13 150.28 223.88 130.14 26.06. 08:19:54 HASH(NRW.Feiertage.Kalender)
tmr-DOIF_TimerTrigger REF(0x55ff9bdb09f0) 163 1 163.47 163.47 101.28 101.28 26.06. 00:19:47 REF(0x55ff9bdb09f0)
Klingeln DOIF_Notify 151 101373 5864.15 0.06 0.00 0.00 26.06. 10:11:19 HASH(Klingeln); HASH(Klingel)
HMLAN1 HMLAN_Read 143 7759 70120.64 9.04 0.00 0.00 25.06. 18:03:05 HASH(HMLAN1)
tmr-statistics_PeriodChange HASH(0x55ff975b5838) 134 27 2143.97 79.41 72.44 6.04 25.06. 23:59:55 HASH(Statistik)
tmr-FRITZBOX_Readout_Start FritzBox6490.Readout 119 818 15703.74 19.20 3006.38 14.73 26.06. 08:24:11 FritzBox6490.Readout
tmr-DOIF_TimerTrigger REF(0x55ff9d5ac1d0) 116 1 116.59 116.59 10.14 10.14 26.06. 09:00:00 REF(0x55ff9d5ac1d0)
Spitzboden.Lueftung DOIF_Notify 116 101373 38533.39 0.38 0.00 0.00 26.06. 03:00:30 HASH(Spitzboden.Lueftung); HASH(Spitzboden.Ventilator)
tmr-DOIF_TimerTrigger REF(0x55ff99a5d988) 106 1 106.32 106.32 3.97 3.97 26.06. 05:15:00 REF(0x55ff99a5d988)
tmr-DOIF_TimerTrigger REF(0x55ff99a5dca0) 106 1 106.28 106.28 1.70 1.70 25.06. 21:15:00 REF(0x55ff99a5dca0)
tmr-DOIF_SleepTrigger HASH(0x55ff929b36e0) 101 11 986.30 89.66 12.47 2.46 26.06. 09:21:03 HASH(CamWatchAlarm.on)
tmr-DOIF_SleepTrigger HASH(0x55ff98122aa0) 101 668 15195.80 22.75 321.34 8.47 26.06. 09:02:31 HASH(Warmwasser.Zirkulation)
tmr-DOIF_SleepTrigger HASH(0x55ff92b6f920) 100 598 42261.52 70.67 2597.40 21.44 25.06. 17:59:22 HASH(Anwesenheit.Zuhause)
tmr-FHEM::Astro::Update HASH(0x55ff97018828) 98 27 1345.29 49.83 162.65 29.83 26.06. 00:19:54 HASH(myAstro)
tmr-DOIF_TimerTrigger REF(0x55ff9bd015d8) 97 1 97.09 97.09 3.86 3.86 26.06. 00:19:47 REF(0x55ff9bd015d8)
Update.Dieselpreise DOIF_Notify 94 101373 13926.85 0.14 0.00 0.00 26.06. 09:24:59 HASH(Update.Dieselpreise); HASH(myUniFi)
tmr-at_Exec HASH(0x55ff91b22488) 94 54 4567.91 84.59 1.53 1.26 26.06. 02:19:35 HASH(addlog.myUniFi)
tmr-DOIF_TimerTrigger REF(0x55ff9d1751e8) 93 1 93.70 93.70 4.00 4.00 26.06. 07:00:00 REF(0x55ff9d1751e8)
tmr-DOIF_TimerTrigger REF(0x55ff9a5d7448) 87 1 87.85 87.85 6.02 6.02 25.06. 13:00:00 REF(0x55ff9a5d7448)
tmr-at_Exec HASH(0x55ff92e375a8) 87 1637 53426.30 32.64 459.44 3.20 25.06. 23:23:35 HASH(FritzBoxTraffic)
tmr-DOIF_TimerTrigger REF(0x55ff997ab610) 87 1 87.27 87.27 2.36 2.36 25.06. 21:19:47 REF(0x55ff997ab610)
Kannst du einen Ansatzpunkt erkennen, dem es sich lohnt nachzugehen?
Viele Grüße
Gisbert
Einfach mal aus aktuellem Anlass eine "blöde Idee" in eine andere Richtung...
Läuft Dein FHEM unter Bebian Stretch bzw. mit dieser ominösen Perl-Version?
Wenn das vorher lange gut funktioniert hat, hast Du evtl. etwas aktualisiert, geändert, neue Regex eingebaut?
Reagiert das ganze FHEM evtl. "träger" als sonst?
einen direkten verantwortlichen erkenne ich erstmal nicht.
allerdings gibt es einige funktionen mit relativ häufigen und identischer anzahl an aufrufen (100909). ich schätze mal ca alle 10s. ist das nötig? eventuell summieren sich hier hin und wieder die freezes ungünstig.
offen ist noch meine wlan-frage.
wenn du attr wdTimer beim hmlan verkürzt von default 25s auf zb 15s, sollten sich die disconnects im vergleichbaren zeitraum reduzieren, wenn meine vermutung zutrifft.
grundsätzlich aber nicht empfehlenswert wegen zusätzlicher belastung.
poste doch noch ein list vom hmlan.
edit: 100000 aufrufe in 28 std bedeutet nicht jede 10s, sondern jede sekunde.
Hallo Hollo,
es läuft Debian 9.8 Stretch auf einem HP ThinClient T610, seit März 2019, mit regelmäßigen updates/upgrades alle ca. einen Monat.
Fhem reagiert nicht sonderlich träge, aber gefühlt zum März doch langsamer. Das kann aber auch an zusätzlichen Diagrammen bzw. Karten liegen, die ich vor 4 Monaten noch nicht hatte.
Ich aktualisiere Fhem einmal wöchentlich, deshalb ist es für mich unmöglich zu sagen, ab welchem Update es zu den disconnects kommt.
Hallo frank,
ich verstehe die Frage nach dem Wlan nicht ganz. Ich habe natürlich Wlan, aber der HMLAN-Adapter hängt per Kabel am Router.
Ich habe eine VCCU; zusätzlich habe ich ein HmUARTLGW1 hängt per Wlan im Netz.
Die häufigen Aufrufe sind nicht beabsichtigt. Jedes einzelne Device hat eine sinnvolle Abfragefrequenz, allerdings frage ich so gut wie alles ab, was mir unter die Finger kommt (Wetterdaten, Netatmo, Blitzer, ...).
Ist es ratsam sich da etwas zu mäßigen und entweder die Abfragefrequenz weiter auszudünnen oder die Anzahl der abgefragten Devices zu reduzieren?
Viele Grüße Gisbert
Bei meinen HMLANs war erst Ruhe, nachdem ich für zeitkritische Dinge eine zweite FHEM-Instanz eröffnet habe. Konkret handelte es sich um die Module IPCAM und SIRD, ersteres für INSTAR-Kameras, zweites für ein Lidl-Internetradio. Diese Module waren sehr zeithungrig. Außerdem gibt es nun ein eigenes VLAN zwischen dem FHEM-Server und den HMLAN-Adaptern.
Danach waren keepalive-timeouts ohne Ausnahme verschwunden. Ein paar Reboots genehmigte sich der eine HMLAN. Daraufhin habe ich die Elkos getauscht --> keine Besserung. Das Netzteil wars. Mit diesem hier https://www.amazon.de/gp/product/B002TPY1VS/ref=ppx_yo_dt_b_search_asin_title?ie=UTF8&psc=1 (https://www.amazon.de/gp/product/B002TPY1VS/ref=ppx_yo_dt_b_search_asin_title?ie=UTF8&psc=1) ok.
Hallo topfi,
vielen Dank für deine Schilderung und Einschätzung des Fehlerbilds bei meinem HMLAN.
Mit "zweiter FHEM-Instanz" meinst du vermutlich einen 2. Server, der mit FHEM2FHEM angebunden wird.
Einen 2. Fhemserver möchte ich eigentlich vermeiden, da er erstens zusätzliche Hardware erfordert, sowie Strom kostet, und er muss auch noch gewartet werden.
Eine zweite Fhem-Instanz auf dem gleichen Fhemserver geht vermutlich nicht.
Ich könnte aber sowohl den HMLAN-Adapter als auch das HmUARTLGW in ein eigenes VLAN bringen - das mache ich, wenn ich etwas mehr Zeit als im Moment dafür habe.
Ein anderes Netzteil könnte ich probieren, da müsste ich welche zur Verfügung haben, die die gewünschte Spannung haben.
Einen Versuch ist es wert, aber auch den kann ich erst angehen, wenn ich dass über einen längeren Zeitraum beobachten kann.
Viele Grüße Gisbert
Zitatich verstehe die Frage nach dem Wlan nicht ganz. Ich habe natürlich Wlan, aber der HMLAN-Adapter hängt per Kabel am Router.
Ich habe eine VCCU; zusätzlich habe ich ein HmUARTLGW1 hängt per Wlan im Netz.
ist der signalweg des netzwerkes von fhem bis zum hmlan ausschliesslich LAN?
mein hmlan hängt auch über kabel am router => ok.
allerdings war mein pi mit fhem zeitweise über wlan mit dem router verbunden => das verursachte einige disconnects täglich. seit der umstellung dieser teilstrecke auf LAN ist ruhe.
Battery.State readingsGroup_Notify 578 100909 104480.90 1.04 0.00 0.00 26.06. 02:20:31 HASH(Battery.State); HASH(Wetter.Proplanta)das irritiert mich zb.
scheinbar eine batterieanzeige, die sekündlich aufgerufen wird und dabei 105 sekunden fhem blockiert.
hm.... ???
Keine Garantie das es das Problem löst - aber ich hatte auch viele Disconnects seit "Debian Stretch".
Das Problem war die DNS-Auflösung, die in einigen FHEM-Modulen notwendig ist. Die Lösung war das globale FHEM-Attribute dnsServer mit der IPV4-Adresse des DNS-Servers (das kann der Router sein oder - wenn vorhanden - ein dedizierter DNS im LAN).
Hintergrund (habe ich aus einigen Diskussionen gelernt): Ohne das globale Attribut verwendet FHEM die Calls des Betriebssystems und die sind "blockierend". Wird das FHEM-Attribute dnsServer gesetzt dann sind die Calls zur DNS-Auflösung "non-blocking".
Ich habe dazu keine Details, aber mein Verdacht ist das seit Debian Stretch da einiges nicht mehr ganz so performant abläuft. Damit kommt es zu teilweise erheblichen Verzögerungen, was die Disconnects auslöst.
Unabhängig davon gibt es in FHEM immer noch einige generell blockierende Calls (z.B. wenn ZWAVE im Einsatz ist und die ZWAVE-Konfiguration ausgelesen werden - dann fallen die IOs bei mir immer raus. Kommt aber nur während eines Neustarts vor, ist also relativ unkritisch).
Wie auch immer, seit ich dieses dnsServer Attribut gesetzt habe sind alle Disconnects der IOs (HMLAN und HM-LAN-Gateways) weg.
Wäre vielleicht einen Versuch wert. Ist ja nicht so aufwendig und wenn es im speziellen Fall nichts bringt auch wieder leicht rückgängig zu machen.
Gruß, Klaus
Hallo Klaus,
das Attribut dnsServer bei global hatte ich bereits auf 8.8.8.8 gesetzt. Versuchsweise habe ich das auf einen internen DNS-Server gesetzt, leider ohne durchschlagenden Erfolg; innerhalb von ca. 80 Minuten gab es 3 disconnects.
Viele Grüße Gisbert
Zitat von: Gisbert am 26 Juni 2019, 15:27:19
Hallo topfi,
vielen Dank für deine Schilderung und Einschätzung des Fehlerbilds bei meinem HMLAN.
Mit "zweiter FHEM-Instanz" meinst du vermutlich einen 2. Server, der mit FHEM2FHEM angebunden wird.
Einen 2. Fhemserver möchte ich eigentlich vermeiden, da er erstens zusätzliche Hardware erfordert, sowie Strom kostet, und er muss auch noch gewartet werden.
Eine zweite Fhem-Instanz auf dem gleichen Fhemserver geht vermutlich nicht.
[...]
Doch, das geht. Einfach in /opt/fhem1 ein weiteres fhem mit eigener fhem1.cfg kopieren und wie folgt starten:
1. Startdatei für fhem1 erstellen:
sudo nano /etc/init.d/fhem1
#!/bin/sh
# description: Start or stop the fhem server fuer zweite Instanz
# Script added by Alex Peuchert, modifiziert von Topfi
### BEGIN INIT INFO
# Provides: fhem1
# Required-Start: $local_fs $remote_fs
# Required-Stop: $local_fs $remote_fs
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: FHEM server 2.Instanz
### END INIT INFO
set -e
cd /opt/fhem1
port=7073
case "$1" in
'start')
sleep 1
echo "Starting fhem1..."
perl fhem.pl fhem1.cfg
RETVAL=$?
;;
'stop')
echo "Stopping fhem1..."
perl fhem.pl $port "shutdown"
RETVAL=$?
;;
'status')
cnt=`ps -ef | grep "fhem.pl" | grep -v grep | wc -l`
if [ "$cnt" -eq "0" ] ; then
echo "fhem1 is not running"
else
echo "fhem1 is running"
fi
;;
*)
echo "Usage: $0 { start | stop | status }"
RETVAL=1
;;
esac
exit $RETVAL
sudo chmod 755 /etc/init.d/fhem1
2. In der originalen fhem.cfg (Erstinstanz) sieht man vor:
define Neustart_Zweite_Instanz notify (global:INITIALIZED|global:REREADCFG).* {system('sudo /usr/local/bin/fhem1restart.sh)'}
fhem1restart.sh ist einfach:
#!/bin/sh
sudo /etc/init.d/fhem1 stop
sleep 2
sudo /etc/init.d/fhem1 start
Das script sollte in sudoers noch zur Ausführung von fhem eingetragen werden. Nach einem Neustart laufen beide Instanzen.
fhem2fhem in Erstinstanz lautet dann beispielsweise so (ich übergebe die events des SIRD-Radios, das auf der zweiten Instanz definiert ist, an die erste):
define f2f_2a FHEM2FHEM 192.168.0.2:7073 LOG:(Kuechenradio)Die Zweitinstanz (fhem1.cfg) definieren wir natürlich auf anderen Ports:
define telnetPort telnet 7073 global
define WEB FHEMWEB 8073 global
define f2f_Ha FHEM2FHEM 192.168.0.2:7072 LOG:(Kuechenradio_B|TF_Haustuer.*)
....
Hier steuere ich das SIRD-Radio aus der ersten Instanz heraus. Außerdem übergebe ich den Türkontakt Haustür an die zweite Instanz, die mit dem gerne blockierenden IPCam-Modul dann Bilder macht.
Zitat von: topfi am 01 Juli 2019, 14:02:01
Doch, das geht. Einfach in /opt/fhem1 ein weiteres fhem mit eigener fhem1.cfg kopieren und wie folgt starten:
1. Startdatei für fhem1 erstellen:
sudo nano /etc/init.d/fhem1
Hallo topfi,
vielen Dank für den Hinweis. Ich werde es in einer ruhigen Stunde versuchen umzusetzen. Ich werde mir aber dafür vorort Hilfe organisieren müssen.
Eine Frage an dieser Stelle. Du benutzt init.d für die Services, bei mir starten die Services mit systemctl. Kann man beide Varianten parallel benutzen?
Viele Grüße Gisbert
Ja, die erste Instanz starte ich auch über systemctl.
Das init.d-script war früher bei fhem dabei. Damals habe ich FHEM auf wheezy kennengelernt und das seinerzeit so implementiert. Inzwischen habe ich fhem komplett neu auf stretch installiert, natürlich über systemctl gestartet. Für die zweite Instanz habe ich mich einfach des alten scripts in leicht abgewandelter Form bedient und siehe da: es geht. :D
Zitat von: Gisbert am 26 Juni 2019, 15:27:19
Hallo topfi,
Ein anderes Netzteil könnte ich probieren, da müsste ich welche zur Verfügung haben, die die gewünschte Spannung haben.
Einen Versuch ist es wert, aber auch den kann ich erst angehen, wenn ich dass über einen längeren Zeitraum beobachten kann.
Hallo topfi,
ich hab 2 Kondensatoren schon vor längerer Zeit getauscht: C1 und C4 (100µF/25V) - hier ergab sich noch keinerlei Verbesserrung.
Die Kondensatoren C14 (100µF/16V) und C43 (22µF/50V) stehen noch auf der to-do-Liste:
Heute bin ich dazu gekommen, ein anderes Netzteil zu testen.
Das orginale Netzteil ist mit 7.5V schon ein Exot (gemessen habe ich beim Orginal-Netzteil 7.3V). Aus der Sammlung der diversen Netzeile war kein passendes dabei, also hab ich mir aus einem 12V-Netzteil und einem Wandler (ich weiß nicht genau, wie dieses Teil heißt, aber es macht aus einer größeren Gleichspannung eine einstellbare, kleinere Spannung) exakt eine 7.50V-Versorgung hergestellt.
Leider ist das auch noch nicht die Lösung, es kommen in der Stunden nach wie vor ca. ein Dutzend disconnects.
Bleibt auf der Liste der Austausch der beiden weiteren Kondensatoren.
Die Einrichtung einer 2. Fhem-Instanz übersteigt im Moment meine Resourcen, das muss ich auf später verschieben.
Was ich ich noch als ernsthafte Option sehe, ist diesen HMLAN-Adapter still zu legen und gegen ein weiteres Wlan-Gateway zu ersetzen, alles zusammen in einer VCCU.
Gibt es dabei irgendwas zu bedenken, wenn der "orginale" HMLAN-Adapter auf Dauer in der VCCU fehlt?
Viele Grüße Gisbert
Hallo Gisbert,
für Deine eigentliches Problem habe ich leider keine Hilfe.
Für die Frage nach der zweiten Instanz hatte ich hier (https://heinz-otto.blogspot.com/2019/03/eine-weitere-fhem-instanz-auf-gleicher.html)mal meine Erkenntnisse mit verschiedenen Varianten und Möglichkeiten aufgeschrieben.
Gruß Otto
Hallo zusammen,
mit etwas verspätung möchte ich noch meine "Lösung" für die Disconnects anbringen:
Ich habe meine zwei HMLANs durch Raspberry Pis mit HM-MOD-RPI-PCB und Raspberrymatic im HMLAN Modus getauscht und als HMUARTLGW in FHEM eingebunden. Seither habe ich keinen einzigen Aussetzer ...
Hallo KurtB,
hallo an alle,
irgendwo (Homematic Forum oder verlinkte EVL-Seite - ich finde leider die Quelle nicht mehr) habe ich gelesen, dass der HM-CFG-LAN-Adapter Schwierigkeiten mit einem 1 MB LAN-Anschluss hat.
Ich habe den HMLAN-Adapter deshalb an einen vorhandenen, kostengünstigen Netgear GS105Ev2 gehängt, bei dem man die Datenrate für jeden Port definieren kann.
Statt der 1000M, die man auf der Einstellung Auto bekommt, habe ich die Datenrate auf 10M Full (es gibt auch noch 10M Half sowie 100M Half/Full, sowie Auto) gestellt.
Das Ergebnis bisher, d.h. nach dieser Umstellung:
seit 12 Stunden keine einziger disconnect.
Ich berichte weiter.
Viele Grüße Gisbert
Edit:
12.8.2019, 19:30: bisher 24h 30min ohne disconnect - ein neuer Rekord nach langer Zeit. Der logfile von heute macht noch nicht mal eine Bildschirmseite aus (aber nur weil einige Attribute neu gesetzt wurden), ansonsten ist er so gut wie leer. Auch die Anzahl der Freezes ist drastisch zurückgegangen, ganze 2 Stück innerhalb von 24h.
Edit:
13.8.2019 19:25: jetzt schon 2 Tage ohne disconnect, ... puh wie langweilig ...
Hallo an alle,
nach 4 Tagen gab es innerhalb von 3 Minuten 2 disconnets, die Ursache ist aber unklar. Das war es auch schon für die nächsten knapp 2 Tage.
Danach, also nach knapp 6 Tagen, habe ich Fhem neugestartet (shutdown restart), was offensichtlich auch zu einem Neustart des HMLAN-Adapters, wie auch des HMUARTLGW führt, was letztlich meine kleine Statistik ruiniert. Lieber so, als die dauerenden disconnects.
Viele Grüße Gisbert
Hallo Gisbert,
ich hatte damals auch sehr oft Probleme mit meinen 2 HMLAN´s, ständig disconnects und freeze dadurch.
Bin dann komplett auf 2 Homematic Funk-LAN Gateway HM-LGW-O-TW-W-EU umgestiegen und seit dem ist Ruhe.
Kann das echt nur jedem empfehlen, die neuen Gateways sind für mich 1000x besser als die alten HMLAN.
Grüße Marcel