Hallo,
ich kämpfe derzeit mit teilweise sehr langen Verzögerungen von verschiedenen HmIP Geräten (Bewegungsmelder, Fensterkontakt, etc.), bis diese von der CCU2 in Fhem ankommen.
Ich bilde mir ein, am längsten sind die "Signallaufzeiten" wenn die entsprechenden Sensoren längere Zeit nicht gefordert werden, z.B. ein
Bewegungsmelder wenn dieser die erste Bewegung am Morgen sieht.
Vom Gefühl her spreche ich von ca. 30-200 Sekunden bis ein Signal in Fhem ankommt, nachdem ich einen Sensor betätigt habe. Komischerweise ist dies nicht
immer so, wenn ich zum testen mit Sensoren experimentiere, so habe ich Signallaufzeiten von ca. 5 Sekunden, damit könnte ich locker leben.
Folgende Hardware verwende ich und folgende Beobachtungen habe ich bisher gemacht:
- Raspberry Pi 3 mit Jessy, COC (wird eigentlich nicht benötigt)
- MySQL Datenbank für Logging auf Raspi vorhanden
- CCU2 mit ca. 25 HmIP Sensoren
- CCU2 läuft ohne jegliche Programmierung, nur das Peering wurde über CCU2 durchgeführt
- Alle Clients hängen mit Netzwerkleitungen an der Fritz!Box und laufen nicht über WLan
- Modbuskommunikation zu einer WAGO Steuerung läuft (32 Datenpunkte, Abruf alle 60 Sekunden)
- Auf der CCU2 Oberfläche kommt das Signal des Sensors nach ca. 1-2 Sekunden an
- Über den COC (CUL-Ersatz) empfange ich immer das Signal der Sensoren "CUL COC UNKNOWNCODE A......" nach ca. 1 - 3 Sekunden
- Ist der Trigger des Sensors in Fhem angekommen, werden die folgenden notify in Fhem sofort ohne Verzögerung abgearbeitet
- Mein Ziel ist es die Programmierung vollständig mit Fhem zu erledigen
- Die Konfiguration sollte eigentlich im groben passen, denn ich kann alle Sensoren empfangen und auch alle Aktoren über Fhem schalten
- Die Umstellung von Filelog auf dbLog hat nichts gebracht
- Alle "gesprächigen" Geräte und die dbLog einträge habe ich auf das äußert Notwendigste beschnitten (addLog in Verwendung), hat jedoch auch nichts geholfen
- Perfmon Modul von Fhem ist installiert, meldet sich ca. 1-5 mal täglich mit "freeze starting delay > 2.000" besonders bei Plots, ich denke das ist OK so
- Im Event Monitor von Fhem tauchen pro Minute ca. 20-60 Meldungen von Fhem auf, ich denke die Auslastung sollte sich hier auch in Grenzen halten
Sicher könnt ihr mir ein paar Tipps geben, wie ich dem Verursacher auf die Schliche kommen kann, welcher für die Laufzeitverzögerung verantwortlich ist.
Eventuell könnt ihr mich ja auf Beiträge aufmerksam machen, welche ich ev. bei der Suche übersehen habe.
Interresieren würden mich auch mal Signallaufzeiten CCU2 -> Fhem bei euch mit ähnlicher Konfiguration.
Sollte sich das Zeitverhalten nicht bessern, so brauche ich meinen Einbruchschutz mit Fensterkontakten, Bewegungsmelder etc. in dieser Konfiguration nicht weiter verfolgen.
Gruß
Reinhard
Hallo REWE
hast du die CCU2 auch in FHEM angelegt?
wenn ja hast du auch die PORTs 2010 mit configuriert?
denn ohne diesen, kommen die Rückmeldungen sehr verspätet an
Gruss tagedieb
Die maximale Verzögerung ergibt sich aus dem Wert im Attribut rpcinterval (default = 5 Sekunden) und der Zeit, bis das Signal bei der CCU ankommt (normalerweise <= 1 Sekunde). 30 Sekunden sind jedenfalls viel zu lang.
Wenn der Port 2010 nicht bei rpcport angegeben ist, komme gar keine automatischen Updates. Dann werden Readings nur aktualisiert, wenn mal ein get Update oder ein get datapoint ausgeführt wird.
Du kannst mal folgendes prüfen:
- ist Port 2010 ausgewählt
- läuft der RPC Server
- Werden die Dateien /tmp/ccu* aktualisiert
- gibt es Fehlermeldungen im fhem Log
- gibt es Fehlermeldungen in der CCU in /var/Log/ messages
Hallo,
Danke für eure Mühe mit einem Anfänger.
Mit der Einstellung von "
rpcinterval" hab ich auch schon gespielt, es hat sich aber nichts verändert, deshalb bin ich wieder auf
5 zurückgegangen. Mit einer Antwortzeit von 10 Sekunden wäre ich ja Happy, ich habe schon mehrere Minuten beobachtet.
Ich arbeite mal eure Frageliste ab:
Zitat- ist Port 2010 ausgewählt
Ja sollte eigentlich so passen, bei mir bei ist unter attr "
rpcport" "
2001,2010,9292" eingetragen
Zitat- läuft der RPC Server
Ich denke auch das ist OK, attr "
rpcserver" "
on" ist eingetragen
Und unter device wird
running/OK angezeigt
Zitat- Werden die Dateien /tmp/ccu* aktualisiert
Wenn du die "
ccuqueue_xxxx_0.dat" und "
ccuqueue_xxxx_0.idx" Dateien meinst, ja diese sind aktuell und werden ständig aktualisiert.
Zitat- gibt es Fehlermeldungen im fhem Log
Keine Meldungen, welche auf Probleme mit HMCCU hindeuten, soweit ich gelesen habe kommen Fehler ja auch bei "
Verbose" "
0" in das log, denn ich habe alle Logfunktionen nur auf das nötigste beschränkt.
Zitat- gibt es Fehlermeldungen in der CCU in /var/Log/ messages
Da scheint schon etwas nicht in Ordnung zu sein, der Inhalt sagt mir aber nicht sehr viel, seit einigen Tagen sind nur Einträge wie folgt, in 2 Minütigem Abstand, jedoch mit geänderten Zeiten, zu finden:
Jan 1 06:26:59 raspberrypi rsyslogd0: action 'action 17' resumed (module 'builtin:ompipe') [try http://www.rsyslog.com/e/0 ]
Jan 1 06:26:59 raspberrypi rsyslogd-2359: action 'action 17' resumed (module 'builtin:ompipe') [try http://www.rsyslog.com/e/2359 ]
...
...
Jan 11 17:37:07 raspberrypi rsyslogd-2007: action 'action 17' suspended, next retry is Wed Jan 11 17:38:37 2017 [try http://www.rsyslog.com/e/2007 ]Ich denke da müsst Ihr mir, bei der Interpretation und Übersetzung ein wenig helfen.
Ich finde da 2 Dateien mit folgender Größe, in beiden immer die Meldung mit 'action 17':
messages 249.506
messages.1 502.686
Was mir noch aufgefallen ist, wenn ich im Gerät der "
HMCCU"bei "
internals" auf "
HMCCU" klicke, wird eine ewig lange Liste mit allen Devices und Kanälen aufgebaut. Nicht dass dies noch ein Überbleibsel vom "Spielen" am Anfang mit
(get CCU2 devicelist create ^HM-KL.* t=dev f=HM_%n room=Homematic) ist.
Noch ein Punkt kommt mir komisch vor, beim Gerät HMCCU werden unter Readings auch Systemvariablen der CCU2 angezeigt, welche ich auf der CCU2 längst gelöscht habe, wie bekomme ich die wieder aus der Liste der Readings der HMCCU?
Grundsätzlich kommt der Sensor in der CCU2 und über den COC auf dem Raspi in etwa nach 2-5 Sekunden zur gleichen Zeit an, das habe ich noch nie anders beobachtet.
Vorerst mal vielen Dank für die Hilfe
Reinhard
Heißt das, Du hast keine CCU2 sondern setzt einen Raspi mit CCU Software ein? So zumindest interpretiere ich Dein /var/log/messages.
Die CCU Software für den Raspi unterstützt kein HM-IP. Dazu brauchst Du eine echte CCU2.
Die lange Liste an Einträgen im I/O Device ist ok. Hier speichert HMCCU alle benötigten Infos zu den Geräten der CCU. Das erspart das ständige Nachfragen bei der CCU.
Nein zap,
das hast du falsch verstanden, meine CCU2 hängt brav neben dem Raspi und stellt die Kommunikation zu den HmIP Sensoren/Aktoren sicher. Aufgrund der Verschlüsselung von HmIP, welche ich derzeit ausschließlich einsetze ist doch ein Betrieb über Raspi und COC (CUL) alleine (ohne eine CCU2) nicht möglich, oder habe ich da etwas verpasst?
Ich war schon froh wie ich die Hardware am laufen hatte und habe Hoffnung das Laufzeitproblem mit eurer Hilfe auch noch gelöst zu bekommen.
Eigentlich könnte ich den COC vom Raspi abbauen, da ich (derzeit) keine anderen Sensoren verwende, aber Hm ohne IP hat ja auch einige nützliche Dinge zu bieten. Spätestens bei der Anschaffung einer Wetterstation werde ich den COC nutzen.
Ich habe wegen der "action 17" Meldung im Internet mal geggooglt, irgendwie scheint dies häufiger vorzukommen, es wird empfohlen die entsprechenden Zeilen in der "/etc/rsyslog.conf" auszukommentieren, das werde ich mal umsetzen, damit das LOG wieder frei wird, für die wichtigen Einträge.
Hast du noch eine Idee wie ich mein Zeitproblem eingrenzen kann?
Ich hab schon gute Lust alles platt zu machen und nochmals alles von Grund auf neu einzurichten. Gerade am Anfang probiert man viele Einstellungen aus und dabei wird viel Müll erzeugt!
Gruss Reinhard
Plattmachen würde ich nur, wenn nichts mehr geht. Der einzige Parameter, der Einfluss auf das Timing hat, ist rpcinterval.
Nutzt Du event-on-change-reading oder event-on-update-reading?
Beziehen sich deine Vermutungen mit 30-200 Sekunden auf Logeinträge oder auf Timestamps der Readings?
Du schreibst, dass die ccu Dateien in tmp ständig aktualisiert werden. So soll es sein. Das heißt aber auch, dass die CCU Events schickt, und zwar ständig. Das Auslesen der ccu Dateien ist Timer gesteuert. Könnte natürlich dein, dass so ein Timer einfach nicht zum Zug kommt, weil extrem viel in FHeM los ist. Ist ja alles nur eine große Schleife, ohne Interrupts und echte Paralellverarbeitung. Gibt es in Deiner Inst. etwas, das das Auslesen der ccu Dateien ausbremsen könnte?
Manchmal hilft auch ein Neustart der CCU ...
Hallo zap,
Danke für Deine Geduld.
Ich will mal versuchen mein Problem noch etwas präziser darzustellen, denkt aber immer daran, ich habe erst mitte Dezember überhaupt erfahren was Fhem und Raspi ist. Ich komme aus der SPS Welt und kenne eher Siemens und Wago, es könnten auch irgendwelche Fehler bei mir sein, an welche "alte Hasen" überhaupt nicht denken.
ZitatManchmal hilft auch ein Neustart der CCU ...
Eben habe ich die CCU2 neu gestartet und auch den Raspi mit sudo shutdown -r now (vorher Fhem shutdown) neu gestartet
ZitatNutzt Du event-on-change-reading oder event-on-update-reading?
Ja das nutze ich intensiv, da ich dachte, das Zeitverhalten würde schneller werden, wenn ich die Events und die Readings auf das minimale reduziere. Anbei z.B. mein Fensterkontakt "Garderobe" dieser liegt neben mir und mit diesen kann ich "spielen", ähnlich sind auch die anderen Sensoren parametriert.
defmod HM_OG_FKE1_Garderobe HMCCUDEV 0000D3C995FFF3
attr HM_OG_FKE1_Garderobe DbLogExclude .*
attr HM_OG_FKE1_Garderobe IODev CCU2
attr HM_OG_FKE1_Garderobe ccureadingformat datapoint
attr HM_OG_FKE1_Garderobe ccureadingname 0.OPERATING_VOLTAGE:Batteriespannung,0.LOW_BAT:Batterie_leer
attr HM_OG_FKE1_Garderobe devStateIcon 0:fts_window_1w 1:fts_window_1w_tilt
attr HM_OG_FKE1_Garderobe event-on-change-reading state
attr HM_OG_FKE1_Garderobe group Sicherheit
attr HM_OG_FKE1_Garderobe icon fts_window_1w_tilt
attr HM_OG_FKE1_Garderobe room Einbruchschutz,Homematic,OG_Garderobe
attr HM_OG_FKE1_Garderobe userReadings Batteriezustand {\
return "00" if(ReadingsVal($name,"Batteriespannung","0") < "1.1" );;;; \
return "25" if(ReadingsVal($name,"Batteriespannung","0") < "1.2" );;;; \
return "50" if(ReadingsVal($name,"Batteriespannung","0") < "1.3" );;;; \
return "75" if(ReadingsVal($name,"Batteriespannung","0") < "1.4" );;;; \
return "100" },\
Devicename {return 'OG Garderobe - Fensterkontakt Einbruch' }
attr HM_OG_FKE1_Garderobe verbose 4
setstate HM_OG_FKE1_Garderobe 0
setstate HM_OG_FKE1_Garderobe 2017-01-11 22:33:01 0.CONFIG_PENDING false
setstate HM_OG_FKE1_Garderobe 2017-01-11 22:37:45 0.DUTY_CYCLE 0
setstate HM_OG_FKE1_Garderobe 2017-01-11 22:37:46 0.ERROR_CODE 0
setstate HM_OG_FKE1_Garderobe 2017-01-11 22:37:45 0.RSSI_DEVICE -62
setstate HM_OG_FKE1_Garderobe 2017-01-11 22:33:01 0.RSSI_PEER 0
setstate HM_OG_FKE1_Garderobe 2017-01-11 22:37:45 0.SABOTAGE 0
setstate HM_OG_FKE1_Garderobe 2017-01-11 22:37:46 0.UNREACH 0
setstate HM_OG_FKE1_Garderobe 2017-01-11 22:33:01 0.UPDATE_PENDING false
setstate HM_OG_FKE1_Garderobe 2017-01-11 22:37:46 1.STATE 0
setstate HM_OG_FKE1_Garderobe 2017-01-11 22:37:45 Batterie_leer 0
setstate HM_OG_FKE1_Garderobe 2017-01-11 22:37:46 Batteriespannung 1.4
setstate HM_OG_FKE1_Garderobe 2017-01-11 22:37:46 Batteriezustand 100
setstate HM_OG_FKE1_Garderobe 2017-01-11 22:37:46 Devicename OG Garderobe - Fensterkontakt Einbruch
setstate HM_OG_FKE1_Garderobe 2017-01-11 22:37:46 state 0ZitatDu schreibst, dass die ccu Dateien in tmp ständig aktualisiert werden. So soll es sein. Das heißt aber auch, dass die CCU Events schickt, und zwar ständig. Das Auslesen der ccu Dateien ist Timer gesteuert.
Ich habe die Änderungen der Dateien in
/tmp/ccu* mal einige Zeit beobachtet, eine Änderung tritt meist immer nur dann auf (Zeitstempel der Datei ändert sich), wenn auch im Statusmonitor Daten ankommen. Das kann ca. 10 Mal pro minute sein aber dann bewegt sich 2 Minuten wieder gar nichts. Sende ich aber mit einem Sensor eine Zustandsänderung, so werden die Dateien
sofort geschrieben und Zeitgleich sehe ich über COC im Event Monitor den Sensor
immer. Sollte meiner Meinung nach auch so passen.
Das mit dem ausgelasteten Fhem Server habe ich versucht mit apptime einzugrenzen, aber da sehe ich nach ca. 10 Minuten auch keinen Verursacher, welcher Fhem ausbremsen könnte.
Auch "Perfmon" schlägt nur dann an, wenn ich einen größeren SVG Plot öffne.
name function max count total average maxDly
tmr-HMCCU_ReadRPCQueue HASH(0x1b77100) 410 91 2147 23.59 1 HASH(CCU2)
WEB FW_Read 96 8 707 88.38 0 HASH(WEB)
WAGO ModbusTCPServer_Read 55 296 467 1.58 0 HASH(WAGO)
tmr-at_Exec HASH(0x33332c0) 44 1 44 44.00 1 HASH(DBLogging_Reopen)
tmr-ModbusTCPServer_Poll poll:WAGO 30 907 10211 11.26 166 poll:WAGO
COC CUL_Read 29 150 147 0.98 0 HASH(COC)
DBLogging DbLog_Set 29 1 29 29.00 0 HASH(DBLogging); DBLogging; reopen
DBLogging DbLog_Log 26 32 254 7.94 0 HASH(DBLogging); HASH(HM_OG_HR_BueroReinhard)
tmr-CUL_HM_complConfigTO CUL_HM_complConfigTO 5 1 5 5.00 1 CUL_HM_complConfigTO
tmr-HTTPMOD_GetUpdate update:OUT.Spritpreis 4 1 4 4.00 0 update:OUT.Spritpreis
no_HA_Vollschutz_Ueberwachung notify_Exec 3 32 19 0.59 0 HASH(no_HA_Vollschutz_Ueberwachung); HASH(HM_EG_Bm_Flur)
no_Spritpreis_change notify_Exec 2 1 2 2.00 0 HASH(no_Spritpreis_change); HASH(OUT.Spritpreis)
tmr-FW_closeInactiveClients 1 8 7 0.88 1
tmr-ModbusTCPServer_HandleReadQueue HASH(0x30b7308) 1 296 4 0.01 43 HASH(WAGO)
no_HA_Akustischer_Alarm_ein notify_Exec 1 32 6 0.19 0 HASH(no_HA_Akustischer_Alarm_ein); HASH(HM_OG_HR_Schlafzimmer)
no_HA_Huellschutz_Ueberwachung notify_Exec 1 32 16 0.50 0 HASH(no_HA_Huellschutz_Ueberwachung); HASH(HM_OG_HR_Schlafzimmer)
Aussentemperatur ModbusRegister_Notify 0 32 0 0.00 0
CCU2 HMCCU_Notify 0 32 0 0.00 0
Druckpumpe_Zisterne ModbusCoil_Notify 0 32 0 0.00 0
EntnahmeZisterne ModbusRegister_Notify 0 32 0 0.00 0
GB01_laeuft ModbusCoil_Notify 0 32 0 0.00 0
ZitatDas Auslesen der ccu Dateien ist Timer gesteuert. Könnte natürlich dein, dass so ein Timer einfach nicht zum Zug kommt, weil extrem viel in FHeM los ist. Ist ja alles nur eine große Schleife, ohne Interrupts und echte Paralellverarbeitung. Gibt es in Deiner Inst. etwas, das das Auslesen der ccu Dateien ausbremsen könnte?
Das Verhalten mit den langen Antwortzeiten beobachte ich im Eventmonitor und an der Reaktion eines dummy Devices, welches in Abhängigkeit von z.B. einem Fensterkontakt seinen Zustand ändern soll.
Derzeit lässt sich der Fehler nicht mehr reproduzieren, ich denke aber ich kann spätestens Morgen einen Auszug aus dem Event Monitor nachreichen, in welchem die langen Antwortzeiten zu sehen sind.
Hier ein Beispiel wie es sein sollte:
CUL erkennt sofort die Bewegung und 3 Sekunden später sind die dummys gesetzt, so sollte es immer sein! :)
2017-01-11 23:07:10 CUL COC UNKNOWNCODE A06B71B36846FED
2017-01-11 23:07:13 dummy du_HA_Verletzung_Huellschutz on
2017-01-11 23:07:13 dummy du_HA_Verletzung_Vollschutz on
2017-01-11 23:07:13 HMCCUDEV HM_OG_FKE1_Garderobe 1Hier habe ich eben noch ein Log mit einer Laufzeit, welche leider bei mir üblich ist:
2017.01.12 17:41:22 2: COC: unknown message A06B71B36846FED # Dies ist der Fensterkontakt wenn ihn der COC erkennt Zustandsänderung off->on
2017.01.12 17:43:26 2: COC: unknown message A06B71B3654F6E5 # Ein anderer HmIP Aktor
2017.01.12 17:44:09 4: dummy set du_HA_Verletzung_Huellschutz on # Erst jetzt, nach 43 Sekunden kommt das Event für das notify
2017.01.12 17:44:09 4: dummy set du_HA_Verletzung_Vollschutz on # Ein anderer Dummy, welcher durch das gleiche Event getriggert wird
2017.01.12 17:45:00 2: COC: unknown message A06B71B364B5C3C # Ein anderer HmIP Aktor
2017.01.12 17:45:27 2: COC: unknown message A06B71B36846FED # Dies ist der Fensterkontakt wenn ihn der COC erkennt Zustandsänderung on->off
2017.01.12 17:45:39 2: COC: unknown message A06B71B3654F6E5 # Ein anderer HmIP Aktor
2017.01.12 17:47:10 4: dummy set du_HA_Verletzung_Huellschutz off # Erst jetzt, nach 1 Minute und 43 Sekunden kommt das Event für das notify
2017.01.12 17:47:10 4: dummy set du_HA_Verletzung_Vollschutz off # Ein anderer Dummy, welcher durch das gleiche Event getriggert wirdMir gehen langsam aber sicher die Ideen aus, was ich da noch versuchen könnte,
ich kann nur hoffen der Neustart und das Shutdown hat alle Probleme beseitigt.
Gruss Reinhard
Hat denn niemand mehr eine Idee wie ich dem Phänomen auf den Grund gehen kann?
Werde wahrscheinlich den Raspi und Fhem nochmals komplett neu aufsetzen, wenn ich meine neue Speicherkarte bekomme, verzweifelt bin ich mittlerweilen :'(
Alles Übrige läuft wirklich Super, wenn nur die langen Laufzeiten nicht wären.
Ein Alarmsystem so aufzubauen ist nahezu sinnlos, bis da das Signal vom Fensterkontakt oder Bewegungsmelder ankommt, ist der Einbrecher schon über alle Berge.
Gruß Reinhard
Ich habe leider keine Idee mehr. Du bist offensichtlich auch der Einzige, der diese extrem langen Reaktionszeiten hat. Es muss also irgendwas mit den lokalen Gegebenheiten bei Dir zu tun haben.
Hallo,
wahrscheinlich werde ich meine neuen microSD Karten morgen bekommen, dann werde ich das System mal komplett neu aufsetzen und zwischendurch vom Raspi ohne Fhem und einmal mit "Jungfräulichem" Fhem ein Image der SD-Karte erstellen. Man weiß ja nie ob es zukünftig nochmals benötigt wird.
Erst dann werde ich Fhem mit einer Minimalkonfiguration einrichten und meine Geräte von der CCU2 neu holen. Das sollte zunächst für einen Test der Laufzeiten ausreichen, wenn alles passt werde ich mein System Zug um Zug wieder so aufbauen wie es jetzt ist.
Ich will aber vermeiden irgend welche Konfigurationsdaten vom alten System (z.B. Fhem.cfg) zu importieren, ich habe die Befürchtung da handle ich mir eventuell einen alten "Müll" mit ein.
Drückt mir die Daumen, dass es diesmal klappt.
Gruß Reinhard
Das wird noch eine größere Baustelle!
Habe nun eine neue Speicherkarte verwendet und nur eine minimale Fhem Konfiguration mit 2 Sensoren angelegt, sporadisch hatte ich schon wieder Antwortzeiten von über 60 Sekunden, somit lag es nicht an der Konfig meines Fhem.
Nun will ich mal kein Teil unbeobachtet lassen und versuche mal grundlegend die Komponenten auszuschließen, mit folgenden Testaufbauten:
1. Neues jessi Linux für Raspi, Konfiguration ohne COC(CUL) -> keine Änderung
2. Neue Netzwerkleitungen -> keine Änderung
3. microSD Speicherkarte aus der CCU2 entfernt -> keine Änderung
4. Standortverlagerung der CCU2 um EMV Probleme des Raspi auszuschließen -> keine Änderung
5. Nun lasse ich dummy Variablen mitloggen, welche 3 unterschiedliche Zeiten beinhalten:
- CCU2 Zeit, getriggert innerhalb der CCU2 durch 2 Aktoren
- Fhem Zeit, getriggert durch die gleichen zwei Aktoren
- Systemzeit einer WAGO Steuerung, sekündliche Übertragung der Zeit über Modbus (sollte der Raspi hängen bleiben, sollte auch die Zeit nicht mehr stimmen.
Alle diese dummy Variablen schreibe ich in eine Logdatei (getriggert durch die 2 Sensoren) somit können die Antwortzeiten gut bewertet und verglichen werden.
2017-01-16_20:41:05 dummy_Aktor HM_OG_FKE1_Garderobe.1
2017-01-16_20:41:05 dummy_ZeitCCU 20:41:02
2017-01-16_20:41:05 dummy_ZeitWago 20:41:04
2017-01-16_20:41:05 dummy_Systemzeit 20:41:05
Momentan läuft es wieder prima, alle Zeiten unter 5 Sekunden, so sollte es bleiben.
Leider war die Freude nur von kurzer Dauer:
2017-01-17_06:28:41 dummy_Aktor HM_EG_Bm_Flur.Bewegung.MOTION: 1
2017-01-17_06:28:41 dummy_ZeitCCU 06:27:17
2017-01-17_06:28:41 dummy_ZeitWago 06:28:39
2017-01-17_06:28:41 dummy_Systemzeit 06:28:41
Solche Reaktionszeiten, von über einer Minute, sind nach längerer Ruhezeit (über Nacht) bei mir normal!
Meine o.g. Maßnahmen haben also alle nichts gebracht!
6. Als nächstes habe ich nun einen Systemreset der CCU2, mit Neuanlernen von nur 7 HmIP Geräte durchgeführt -> keine Änderung.
7. Als letzte Möglichkeit von meiner Seite noch eine Idee, ich habe den Raspi und die CCU2 an einen alten Speedport W 900V gehängt, welcher als Router, ohne Internetanbindung und WLan läuft. Sollte die Fritz!Box die Ursache sein, so könnte ich es so testen -> keine spürbaren Verbesserungen
8. Nachdem ich nun definitiv mit meinen Möglichkeiten am Ende bin, habe ich den Hersteller eQ-3 AG angeschrieben, mit der Bitte um Stellungnahme und Übersendung eines Testgerätes, damit ich einen Fehler meiner CCU2 auschließen kann. Bin auf die Reaktion gespannt, ob sich die Firma mit Endkunden überhaupt einlässt oder mich an den Handel verweist. Ich bin jedoch davon überzeugt, ein Verkäufer kann mir in dieser Angelegenheit nicht weiterhelfen.
Eine Frage stellt sich mir noch,
gibt es eine Möglichkeit mit wenig Aufwand den Inhalt des rpcqueue Port 2010 in eine Logdatei, mit Zeitstempel zu schreiben???
5 Minuten würden ausreichen, daran würde sich eindeutig erkennen lassen, wann die Signale von der CCU2 über das Netzwerk an den Raspi kommen.
Irgend etwas muss ja bei mir für dieses Verhalten verantwortlich sein, ich denke schon ich bilde mir den Fehler nur ein, weil ich anscheinend der einzige CCU2 Anwender bin, welcher hier Probleme mit Fhem hat. >:(
Kurios ist nur, die Antwortzeiten sind am längsten, wenn lange Zeit kein Sensor betätigt wurde, teste ich häufig habe ich Antwortzeiten von unter 5 Sekunden. Es stellt sich fast so dar, als wenn ein Gerät in den "Schlafmodus" wechseln würde. Auch nach einem Neustart der CCU2 läuft die Kommunikation wieder einige Stunden Fehlerfrei.
Gruß Reinhard
Hängt der Raspi am WLAN oder LAN?
Hallo zap,
ich hänge direkt mit dem Raspi auf LAN Port 3 und mit der CCU2 auf LAN Port 4 der Fritz!Box. Über Nacht schalte ich das WLan komplett ab, somit können die Störungen auch nicht vom WLan kommen, da ich diese langen Reaktionszeiten auch ohne WLan bemerke.
Ich hab mich schon mit Wireshark versucht, aber auf die Schnelle, ohne viel Ahnung mit dem Programm hab ich da nichts erkennen können. Ich bin aber mittlerweile ziemlich sicher, dass die CCU2 die Verzögerung verursacht und nicht der Raspi, sollte der Raspi hängen, würde die über Modbus empfangene Zeit auch verzögert in der Log-Datei landen.
Sollte der Systemreset und das Neuanlernen der wenigen Sensoren auch wieder nichts gebracht haben, werde ich mal ELV oder den Hersteller kontaktieren, eventuell können die mir mal eine andere CCU2 zum testen zur Verfügung stellen. Sie sollten ja auch ein Interesse dran haben, dass Homematic IP Geräte über die CCU2 problemlos funktionieren. Ich werde sicherlich nicht der letzte sein, welcher diese Systemauswahl einsetzt.
Drück mir die Daumen
Gruß Reinhard
Hast Du Dir mal die Datei /var/log/messages in der CCU angeschaut? Gibt es dort Fehlermeldungen, speziell wenn die Verzögerung auftritt?
Ich habe mir die Datei mal angesehen, es waren keine Fehler enthalten. Genaueres werde ich aber erst morgen Vormittag erkennen, da ich die CCU2 eben vom Netz genommen habe und danach ist für ca. 5 Stunden wieder alles paletti.
Habe jetzt wie unter Beitrag https://forum.fhem.de/index.php/topic,64567.msg562686.html#msg562686 geschrieben, meinen alten Speedport als Router wiederbelebt, um Fehler der Fritz!Box auszuschließen. Somit hängt nur der Raspi, die CCU2 und mein Desktop PC über eine eigene Netzwerkkarte daran, WLan, Internet und andere Rechner sind somit aussen vor.
Wir werden sehen
Gruß Reinhard
Mir lässt das einfach keine Ruhe,
habe jetzt mal die CCU2 und den Raspi mit statischen IP-Adressen versehen und betreibe diese mit einer Minimalkonfiguration an einen alten Netgear Splitter, an welchen auch noch mein PC mit einer eigenen Netzwerkkarte hängt.
Auch bei dieser Ausstattung sind die Antwortzeiten bis zu 3 Minuten. :(
Heute wollte ich mal über SSH (mit Putty) den Inhalt der "ccuqueue_2010_1.dat" für den RPC Server prüfen, ob diese auch von der CCU2 verzögert geschrieben werden. Mangels anderer Möglichkeiten habe ich mir diese mit "cat" alle 5 Sekunden auf der Konsole ausgeben lassen und konnte während dieses Tests keinerlei Verzögerung mehr feststellen. Alle Signallaufzeiten kamen unter 10 Sekunden an.
Das brachte mich auf eine Idee.
Ich habe am Windows Rechner, welcher über den Splitter noch mit den beiden Geräten verbunden ist, auf beide Geräte einen Dauerping eingerichtet. Ab diesen Zeitpunkt beobachte ich absolut korrekte und kurze Signallaufzeiten von unter 10 Sekunden und das schon über einen Tag. :)
Kann es sein, dass ein Gerät in den Ruhe oder Schlafmodus wechselt, wenn längere Zeit keine Daten über das Netzwerk transportiert werden?
Als nächsten Versuch pinge ich mal im Hintergrund die CCU2 vom Raspi ständig mit "nohup ping 192.168.1.32 &" an, mal sehen ob sich somit mein Problem ein wenig eingrenzen lässt.
Erfahrung nach mehreren Tagen: Keinerlei Verzögerungen bei der Übertragung mehr, wenn der Ping läuft, Zeiten < 6 Sekunden OK!
Auch warte ich noch auf eine Antwort von eQ-3, bin mal gespannt ob ich als Endkunde da überhaupt Gehör finde.
Die Antwort ist da: eQ-3 etwickelt die entsprechende Software nicht selbst, ich sollte mich bei Verdacht von Fehlern in der CCU2 an den "kompetenten" Fachandel wenden!
Kann sich dieses seltsame Verhalten irgend jemand erklären, welcher mehr Ahnung von der Netzwerktechnik als ich hat?
Gruß Reinhard