HMLAN Adapter wechselt permanent zwischen disconnected / connected

Begonnen von bdombrowsky, 26 Februar 2014, 19:41:00

Vorheriges Thema - Nächstes Thema

domii666

Apptime? CPU Performance meist 700mhz mal 1000mhz

Gesendet von meinem HTC One mit Tapatalk


Hollo

Zitat von: martinp876 am 26 Januar 2015, 21:54:45
Was sagt apptime, was macht die performance der cpu
Wenn der Kasten das RSS neu generiert, ist die CPU-Last bei 100% , ABER...
das war ja schon immer so und hat zwischendurch auch mit 2 Tablets funktioniert.
Es muss noch etwas anderes sein, denn es hat sich ja wesentlich verschlimmert (bei mir).
FHEM 6.x auf RPi 3B Buster
Protokolle: Homematic, Z-Wave, MQTT, Modbus
Temp/Feuchte: JeeLink-Clone und LGW mit LaCrosse/IT
sonstiges: Linux-Server, Dreambox, "RSS-Tablet"

domii666

Ich logge seit heute den ping auf den hmlan. Hier Stelle ich aktuell schon fest dass es teilweise 150ms dauert. Rest der Geräte LAN ping von 0-2ms. Vllt hat das auch was zu heißen?

Gesendet von meinem HTC One mit Tapatalk


LuckyDay


Hollo

Zitat von: Hollo am 26 Januar 2015, 09:31:32
Aktuell habe ich die diesconnects ca. alle 10 Minuten.   >:( ...
Manchmal hilft es ja, darüber zu reden.  ;D
Nachdem ich das so geschrieben habe, habe ich überlegt, was denn alle 10 Minuten passiert.
Daraufhin habe ich mal meine beiden at's readGDS und checkGDS für die DWD-Sachen disabled.

Siehe da, in 24 Stunden noch 7 disconnects, statt sonst fast alle 10 Minuten.
SCHEINBAR ist nicht die CPU-Auslastung massgeblich, sondern die Netzwerkkommunikation entscheidend.
Wäre ja auch logisch, weil der HMLAN disconnected wenn ihm das keepalive fehlt.

Ich komme wohl nicht umhin, mein FHEM testweise mal auf meinen Server umzuziehen und per FHEM2FHEM den Pi mit Sensoren und 433-Sender anzubinden.
FHEM 6.x auf RPi 3B Buster
Protokolle: Homematic, Z-Wave, MQTT, Modbus
Temp/Feuchte: JeeLink-Clone und LGW mit LaCrosse/IT
sonstiges: Linux-Server, Dreambox, "RSS-Tablet"

Rohan

Zitat von: Hollo am 28 Januar 2015, 08:18:56... Nachdem ich das so geschrieben habe, habe ich überlegt, was denn alle 10 Minuten passiert.
Daraufhin habe ich mal meine beiden at's readGDS und checkGDS für die DWD-Sachen disabled.

Wo ich dann immer meine Probleme damit habe, welchen tieferen Sinn es für "Otto Normalo" macht, die DWD-Daten (womöglich mit Satelliten-Fotos etc.) alle 10 Minuten zu erneuern? Selbst bei akuten Warnmeldungen mMn keinen, aber die Antwort darf sich jeder selbst geben  8)

Zitat... SCHEINBAR ist nicht die CPU-Auslastung massgeblich, sondern die Netzwerkkommunikation entscheidend. ...

Nein, sondern eher der missliebige Umstand, dass das Schreiben der DWD-Daten (und sonstiger Fhem-Log-Dateien) auf SD-Karte am RPi und die Netzwerkkommunikation über ein und denselben IO-Controller erfolgen. Das ist ein ständig wiederkehrendes Problem.

Gruß
Thomas
Fhem auf Mini-ITX mit Celeron 2-Core, HMLAN (> 55 Devices), CUL (FS20 und EM), RFXtrx 433E, Arduino (einige DS18B20), RPi mit 1-Wire (DS2423 für S0-Signale, DS18B20+), RPi/Arduino mit MQ-5 und MQ-9 (CO- und CNG/LPG-Sensor), CO-20 IAQ Sensor

Hollo

Zitat von: Rohan am 28 Januar 2015, 08:40:17
Wo ich dann immer meine Probleme damit habe, welchen tieferen Sinn es für "Otto Normalo" macht, die DWD-Daten (womöglich mit Satelliten-Fotos etc.) alle 10 Minuten zu erneuern? Selbst bei akuten Warnmeldungen mMn keinen, aber die Antwort darf sich jeder selbst geben  8)
Korrekt.
Die Aktualisierung findet nur tagsüber statt, betrifft nur die Warnungen (also keine Karten etc) und sind ein "Folgeschaden" aus knapp 30 Jahren Feuerwehr.  ;D

Zitat
Nein, sondern eher der missliebige Umstand, dass das Schreiben der DWD-Daten (und sonstiger Fhem-Log-Dateien) auf SD-Karte am RPi und die Netzwerkkommunikation über ein und denselben IO-Controller erfolgen. Das ist ein ständig wiederkehrendes Problem.
Du hast USB vergessen, was ja leider ebenfalls am selben Controller hängt.
Komisch nur, dass sich das öfter mal ändert. Vielleicht sollte man mit rpi-kernelupdate vorsichtiger sein.  ;)
Der Pi ist nunmal eine Bastelplattform.
FHEM 6.x auf RPi 3B Buster
Protokolle: Homematic, Z-Wave, MQTT, Modbus
Temp/Feuchte: JeeLink-Clone und LGW mit LaCrosse/IT
sonstiges: Linux-Server, Dreambox, "RSS-Tablet"

Rohan

Ist ja nicht so, als ob ich nicht auch diese "Bastelplattform" einsetze, aber nur um zu schauen, ob es so wie angedacht läuft. Wenn es dann grundsätzlich läuft, wird umgezogen.

Mein momentanes  "Bastelprojekt" ist ein RPi an dessen GPIO ein Arduino dranhängt, der 2 Gassensoren für CO und LPG/CNG (MQ-5 und MQ-9) im Umgebungsbereich meiner Gastherme ausliest. Der RPi tut nix anderes, als jede Minute die Werte  an der Schnittstelle zum Arduino per Python-Skript auszulesen und auf SD-Karte in ein File zu schreiben. Einmal täglich hole ich mir vom RPi per SSH über WLAN die Datei ab und pflege sie in mein Produktiv-Fhem als Fakelog ein. Mittlerweile ist die Log-Datei über 2 MByte groß. Einmal braucht der Datentransfer nur ein paar Sekunden, an einem anderen Tag aber fast 2 Minuten (kein RPi-Neustart zwischendurch).

Da nach allem, was ich bisher über HomeMatic-Kommunikation mitbekommen habe, gerade das Timing zum IO-Device (HM-LAN, CUL, HM-USB-CFG) besonders wichtig ist, habe ich keinen Bedarf für eine Nutzung des RPi als Fhem-Zentrale, es sei denn gerade und nur für Testzwecke.

Btw: Das ganze obige Projekt soll dann demnächst direkt an Fhem angebunden werden mit E-Mail bei zu hohen Werten. Und bevor jemand schreit: Nein, die Bastel-Gassensoren sind zusätzlich neben kommerziellen Warnsensoren für CO und Erd-/Flüssiggas mit Prüfzertifikat und akustischer Alarmmeldung. Das wäre mir sonst zu heiß.

Edith möchte noch nachtragen: Mit der Vorsicht beim Kernel-Update hast du durchaus Recht. Das war mir gleich ein Bookmark wert ;)

Gruß
Thomas
Fhem auf Mini-ITX mit Celeron 2-Core, HMLAN (> 55 Devices), CUL (FS20 und EM), RFXtrx 433E, Arduino (einige DS18B20), RPi mit 1-Wire (DS2423 für S0-Signale, DS18B20+), RPi/Arduino mit MQ-5 und MQ-9 (CO- und CNG/LPG-Sensor), CO-20 IAQ Sensor

Amenophis86

Ich muss dieses Thema mal wieder ausgraben. Ich habe festgestellt, dass mein Harmony Hub und mein HMLan regelmäßig der Verbindung verlieren. Ein Intervall von ca. 2h ist manchmal zu erkennen, aber nicht immer. Jetzt habe ich mal Apptime angeschaltet und auch das Performance Modul eingebaut. Hier sind die ersten Ergebnisse:

Apptime:

                                name             function    max  count    total  average maxDly
            tmr-perfmon_ProcessTimer      HASH(0x1ee5300)      0      9        0     0.00    445
            tmr-HMLAN_KeepAliveCheck   keepAliveCk:HMLAN1      0      1        0     0.00     13
                 tmr-HMLAN_KeepAlive     keepAlive:HMLAN1      2      1        2     2.00      5 keepAlive:HMLAN1
                    Alarm_Ausloesung          DOIF_Notify      0      6        0     0.00      0
                   Alles.Ausschalten          DOIF_Notify      0      6        0     0.00      0
               Anwesenheit.Vergessen          DOIF_Notify      0      6        0     0.00      0
          FHEMWEB:192.168.2.10:50823              FW_Read     28      4       77    19.25      0 HASH(FHEMWEB:192.168.2.10:50823)
          FHEMWEB:192.168.2.10:50826              FW_Read     27      3       78    26.00      0 HASH(FHEMWEB:192.168.2.10:50826)
          FHEMWEB:192.168.2.10:50827              FW_Read     20      3       38    12.67      0 HASH(FHEMWEB:192.168.2.10:50827)
          FHEMWEB:192.168.2.10:50828            FW_Notify      0      6        0     0.00      0
          FHEMWEB:192.168.2.10:50829              FW_Read     37      3       86    28.67      0 HASH(FHEMWEB:192.168.2.10:50829)
          FHEMWEB:192.168.2.10:50832            FW_Notify      0      6        0     0.00      0
          FHEMWEB:192.168.2.10:50832              FW_Read     36      5      151    30.20      0 HASH(FHEMWEB:192.168.2.10:50832)
                      Feiertag.Check          DOIF_Notify      0      6        0     0.00      0
                FileLog_SZ.Heizung.R          FileLog_Log     12      1       12    12.00      0 HASH(FileLog_SZ.Heizung.R); HASH(SZ.Heizung.R)
                  FileLog_WC.Fenster          FileLog_Log     11      6       17     2.83      0 HASH(FileLog_WC.Fenster); HASH(HMLAN1)
                              HMLAN1         HMLAN_Notify      0      6        0     0.00      0
                              HMLAN1           HMLAN_Read    779      2     1110   555.00      0 HASH(HMLAN1)
                Heizung.Anja.Morgens          DOIF_Notify      0      6        0     0.00      0
           Heizung.Etienne.Tagdienst          DOIF_Notify      0      6        0     0.00      0
                     Heizung.SZ.1900          DOIF_Notify      0      6        0     0.00      0



Performance mit Verbose 5:

2015.09.17 10:41:50 4: Closing inactive connection FHEMWEB:192.168.2.10:65343
2015.09.17 10:41:50 4: Closing inactive connection FHEMWEB:192.168.2.10:65344
2015.09.17 10:41:50 4: Closing inactive connection FHEMWEB:192.168.2.10:65346
2015.09.17 10:41:50 4: Closing inactive connection FHEMWEB:192.168.2.10:65347
2015.09.17 10:41:50 4: Closing inactive connection FHEMWEB:192.168.2.10:65345
2015.09.17 10:42:19 1: Perfmon: possible freeze starting at 10:42:16, delay is 3.034
2015.09.17 10:43:23 1: Perfmon: possible freeze starting at 10:43:20, delay is 3.005
2015.09.17 10:44:26 1: Perfmon: possible freeze starting at 10:44:23, delay is 3.034
2015.09.17 10:45:30 1: Perfmon: possible freeze starting at 10:45:27, delay is 3.024
2015.09.17 10:46:34 1: Perfmon: possible freeze starting at 10:46:31, delay is 3.024
2015.09.17 10:47:38 1: Perfmon: possible freeze starting at 10:47:35, delay is 3.014
2015.09.17 10:48:42 1: Perfmon: possible freeze starting at 10:48:39, delay is 3.372
2015.09.17 10:49:46 1: Perfmon: possible freeze starting at 10:49:43, delay is 3.004
2015.09.17 10:50:49 1: Perfmon: possible freeze starting at 10:50:46, delay is 3.019
2015.09.17 10:51:53 1: Perfmon: possible freeze starting at 10:51:50, delay is 3.004
2015.09.17 10:52:56 1: Perfmon: possible freeze starting at 10:52:53, delay is 3.004
2015.09.17 10:53:59 1: Perfmon: possible freeze starting at 10:53:56, delay is 3.016
2015.09.17 10:55:03 1: Perfmon: possible freeze starting at 10:55:00, delay is 3.004
2015.09.17 10:56:06 1: Perfmon: possible freeze starting at 10:56:03, delay is 3.015
2015.09.17 10:57:10 1: Perfmon: possible freeze starting at 10:57:07, delay is 3.004
2015.09.17 10:57:32 1: Perfmon: possible freeze starting at 10:57:31, delay is 1.163
2015.09.17 10:58:13 1: Perfmon: possible freeze starting at 10:58:10, delay is 3.024
2015.09.17 10:59:17 1: Perfmon: possible freeze starting at 10:59:14, delay is 3.004
2015.09.17 11:00:20 1: Perfmon: possible freeze starting at 11:00:17, delay is 3.01
2015.09.17 11:01:23 1: Perfmon: possible freeze starting at 11:01:20, delay is 3.024
2015.09.17 11:02:27 1: Perfmon: possible freeze starting at 11:02:24, delay is 3.014
2015.09.17 11:03:31 1: Perfmon: possible freeze starting at 11:03:28, delay is 3.011
2015.09.17 11:04:35 1: Perfmon: possible freeze starting at 11:04:32, delay is 3.019
2015.09.17 11:05:38 1: Perfmon: possible freeze starting at 11:05:35, delay is 3.01
2015.09.17 11:06:42 1: Perfmon: possible freeze starting at 11:06:39, delay is 3.021
2015.09.17 11:07:45 1: Perfmon: possible freeze starting at 11:07:43, delay is 2.669
2015.09.17 11:08:49 1: Perfmon: possible freeze starting at 11:08:46, delay is 3.311
2015.09.17 11:09:53 1: Perfmon: possible freeze starting at 11:09:50, delay is 3.004
2015.09.17 11:10:56 1: Perfmon: possible freeze starting at 11:10:53, delay is 3.014
2015.09.17 11:12:00 1: Perfmon: possible freeze starting at 11:11:57, delay is 3.004
2015.09.17 11:13:03 1: Perfmon: possible freeze starting at 11:13:00, delay is 3.104
2015.09.17 11:14:07 1: Perfmon: possible freeze starting at 11:14:04, delay is 3.015
2015.09.17 11:15:11 1: Perfmon: possible freeze starting at 11:15:08, delay is 3.014
2015.09.17 11:16:29 2: HarmonyHub: disconnect
2015.09.17 11:16:29 1: 192.168.2.104:1000 disconnected, waiting to reappear (HMLAN1)
2015.09.17 11:16:29 1: HMLAN_Parse: HMLAN1 new condition disconnected
2015.09.17 11:16:33 1: Perfmon: possible freeze starting at 11:15:56, delay is 37.044
2015.09.17 11:16:33 3: HarmonyHub: connected
2015.09.17 11:16:33 1: 192.168.2.104:1000 reappeared (HMLAN1)
2015.09.17 11:16:33 1: HMLAN_Parse: HMLAN1 new condition init
2015.09.17 11:16:34 1: HMLAN_Parse: HMLAN1 new condition ok
2015.09.17 11:16:52 3: HarmonyHub: new config
2015.09.17 11:16:52 1: Perfmon: possible freeze starting at 11:16:36, delay is 16.883
2015.09.17 11:17:37 1: Perfmon: possible freeze starting at 11:17:34, delay is 3.025
2015.09.17 11:18:41 1: Perfmon: possible freeze starting at 11:18:38, delay is 3.014
2015.09.17 11:19:45 1: Perfmon: possible freeze starting at 11:19:42, delay is 3.004
2015.09.17 11:20:48 1: Perfmon: possible freeze starting at 11:20:45, delay is 3.001
2015.09.17 11:21:51 1: Perfmon: possible freeze starting at 11:21:48, delay is 3.002
2015.09.17 11:22:54 1: Perfmon: possible freeze starting at 11:22:51, delay is 3.013
2015.09.17 11:23:58 1: Perfmon: possible freeze starting at 11:23:55, delay is 3.003
2015.09.17 11:25:01 1: Perfmon: possible freeze starting at 11:24:58, delay is 3.003
2015.09.17 11:26:04 1: Perfmon: possible freeze starting at 11:26:01, delay is 3.003
2015.09.17 11:27:07 1: Perfmon: possible freeze starting at 11:27:04, delay is 3.004
2015.09.17 11:28:10 1: Perfmon: possible freeze starting at 11:28:07, delay is 3.004
2015.09.17 11:29:13 1: Perfmon: possible freeze starting at 11:29:10, delay is 3.004
2015.09.17 11:30:16 1: Perfmon: possible freeze starting at 11:30:13, delay is 3.013
2015.09.17 11:30:28 4: Connection accepted from FHEMWEB:192.168.2.10:50823
2015.09.17 11:30:28 4: HTTP FHEMWEB:192.168.2.10:50823 GET /fhem/FileLog_logWrapper?dev=Logfile&type=text&file=fhem-2015-09.log


Allerdings werde ich leider nicht schlau darauf, was nun den Delay auslöst, dass sowohl das Harmony Hub, als auch der HMLan sich neu Verbinden muss?? Offensichtlich ist es wohl das erste bei Apptime, was ein sehr langes Delay hat, aber was ist das??
Aktuell dabei unser neues Haus mit KNX am einrichten. Im nächsten Schritt dann KNX mit FHEM verbinden. Allein zwei Dinge sind dabei selten: Zeit und Geld...

frank

apptime mit option max aufrufen und perfmon bringt (meist) nur etwas in verbindung mit global verbose 5.
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

Amenophis86

Zitat von: frank am 17 September 2015, 11:48:24
apptime mit option max aufrufen und perfmon bringt (meist) nur etwas in verbindung mit global verbose 5.

Wie gesagt, Verbose 5 ist eingeschaltet und oben auch der Code aus dem Log eingefügt. Oder was möchtest du mir damit sagen?
Aktuell dabei unser neues Haus mit KNX am einrichten. Im nächsten Schritt dann KNX mit FHEM verbinden. Allein zwei Dinge sind dabei selten: Zeit und Geld...

frank

ZitatWie gesagt, Verbose 5 ist eingeschaltet und oben auch der Code aus dem Log eingefügt. Oder was möchtest du mir damit sagen?
dann muss im log mehr zu sehen sein.
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

marvin78

Wo hast du verbose 5 eingestellt? frank sprach von "global verbose 5". Also verbose 5 im Device global nicht in einem anderen Device.

Amenophis86

Verrückte FHEM-Welt. Habe ich doch tatsächlich nicht bei global Verbose 5 eingestellt, sondern bei WEB. :D

Na gut, dann warten wir jetzt nochmal ein bisschen auf das nächste aufhängen und schauen dann was passiert. Danke für den Hinweis.  :-[
Aktuell dabei unser neues Haus mit KNX am einrichten. Im nächsten Schritt dann KNX mit FHEM verbinden. Allein zwei Dinge sind dabei selten: Zeit und Geld...

marvin78

Zitat von: Amenophis86 am 17 September 2015, 12:54:31
Verrückte FHEM-Welt.

Hm. Eigentlich ist das sehr logisch. Zudem hat frank ja geschrieben, wo es eingestellt werden muss ;)