...ich schleppe jetzt seit Monaten ein lästiges Problem mit mir rum, bei dem mir die Ideen ausgehen, woran es liegen könnte.
Bei mir sind Haus und Garage über ein LAN Kabel verbunden. Im Haus läuft fhem auf meiner FB7390.
In meiner Garage habe ich ein eigenes WLAN, welches von einer FB7270 erzeugt wird. Die beiden FritzBoxen sind über das LAN Kabel verbunden.
In der Garage ist auch noch ein CUNO, der die Kommunikation zu meinen FS20 Geräten macht.
Mein Problem ist, wenn ich Dinge in der Garage schalten will, es zunächst zu langen Verzögerungen kommt.
Anders gesagt: ich will das Hallentor auf fahren: Ich setze das Kommando von fhem ab und das Tor öffent sich manchmal nach wenigen Sekunden, manchmal nach 20 Sekunden oder noch später.
Gleiches ist mit einer Lampe: schalte ich sie morgends aus, dann dauert das teilweise ewig.
Jedes weitere Kommando wird dann aber korrekt (=sofort) ausgeführt.
Dieses Verhalten taucht nur auf, wenn man den CUNO irgendwie ne Weile nicht gebraucht hat. Tut mir leid, das ich es nicht beser beschreiben kann.
Der CUNO läuft noch mit Version V 1.45 CUNO868
fhem ist aktuell
Alle IP Adressen entspringen dem Adressraum 192.168.1.x
Was mich verzweifeln lässt ist diese "Verzögerung" von der ich nicht weiss, wo sie her kommt.
Keine Auffälligkeiten im Log
Da ich einen CUL für FS20 im Haus habe, und nicht wollte das die sich ins Gehege kommen, hatte ich "sendpool" für CUL und CUNO eingerichtet, aber das inzwischen wieder gelöscht (Entfernung ist ca. 40m und Störungen wohl eher unwahrscheinlich) Brachte aber keine Änderung.
Hat dazu jemand ne Idee? Kennt das jemand?
VG
Ralf
Ich habe von sowas noch nie gehoert, allerdings habe ich auch kein CUNO.
Ich wuerde als erstes feststellen welche Komponente genau fuer die Verzoegerung zustaendig ist. Vermutlich am einfachsten ist es das CUL Attribut verbose in FHEM hochzudrehen, Schalten, und dabei Log und Lampe "gleichzeitig" beobachten. Beim Mitdenken wuerde es helfen zu wissen, um welche Technologie es sich handelt, ich gehe erstmal auch von FS20 aus.
Danke, das du dich dafür interessierst, Rudolf!
Ich hab mich heute morgen noch mal dran gesetzt, um das etwas einzugrenzen:
In der Garage sind in Verbindung mit dem CUNO nur FS20 Komponenten vorhanden. Es handelt sich dabei um ein paar Funk-Steckdosen, drei Bewegungsmelder, einen Regensensor und ein 4-Kanal Schaltmodul.
So wie es aussieht, hat NUR DAS 4-Kanal Schaltmodul vom Typ FS20 SM4 dieses Verhalten. Die Schaltsteckdosen funktionieren im Gegengsatz dazu einwandfrei!
Wenn ich das Kommando in der Oberfläche von fhem absetze, wird auch einwandfrei der geänderte Status angezeigt. Da meine (HomeMatic) Status-Display im Haus den Zustand auch anzeigen und diese auch im selbem Moment korrekt reagieren, gehe ich davon aus, das fhem an sich korrekt arbeitet, weil die HM-Kommandos ja auch raus gehen.
Also was bleibt für das FS20 Kommando übrig?
Klemmt es im FS20 Modul?
Klemmt es im CUNO?
Klemmt es im FS20 SM4 Device?
Auch mit verbose 5 im CUNO Device keine Auffälligkeiten in der Konsole oder in den Events.
Hier das, was dazu im Log steht:
Ich hatte mit notiert, das ich bei 08:05:28 und bei 08:08:06 die WebOberfläche von fhem bedient hatte.
Die Reaktion der Lampe, die an dem Kanal es SM4 hängt, kam jeweils deutlich später.
Die beiden HM Devices sind meine Status Displays.
2013.12.02 08:05:28 3: FS20 set MansCave_AlarmMode off
2013.12.02 08:05:28 5: CUNO_MansCave sending F68392700
2013.12.02 08:05:28 5: SW: F68392700
2013.12.02 08:05:28 2: CUL_HM set D1LED16 led off
2013.12.02 08:05:28 2: CUL_HM set D2LED16 led off
2013.12.02 08:08:06 3: FS20 set MansCave_AlarmMode on
2013.12.02 08:08:06 5: CUNO_MansCave sending F68392711
2013.12.02 08:08:06 5: SW: F68392711
2013.12.02 08:08:06 2: CUL_HM set D1LED16 led red
2013.12.02 08:08:06 2: CUL_HM set D2LED16 led red
Da die SW Meldung vom DevIo.pm sofort kommt, ist das FS20 und CUL Modul in Ordnung.
Ich sehe folgende Moeglichkeiten:
1. das FHEM-OS schickt das TCP-Paket nicht sofort los
2. das Paket geht unterwegs verloren, und muss wiederholt werden.
3. das CUNO nimmt das Paket nicht sofort ab
4. das CUNO sendet das Funkbefehl nicht sofort los
5. das FS20S4 reagiert nicht sofort.
Die Punkte 1 und 2 kann man mit tcpdump/wireshark/etc pruefen.
Ob 1-4 oder 5 kann man mit einem zweiten CUL+FHEM oder CUL+screen/hyperterminal rausfinden.
3 und 4 (und evtl. 2) kann man nur mit zusaetzliches culfw debug-Ausgaben auseinanderhalten.
Nachfrage zu Punkt 2. : Da die FS20 Kommunikation unidirektional ist, wie kann das Verlieren eines Paketes erkannt werden?
VG
Ralf
Das ist TCP/IP, und die hat dafuer aufwendige und bewaehrte Mechanismen.
Erst ab Punkt 4 waere es FS20.
Danke! Macht Sinn!
Hab in der Zwischenzeit noch etwas rum getestet.
Ich denke es liegt am CUNO.
Hab mich gerade mal nur auf eine Funksteckdose konzentriert, die einen Scheinwerfer schaltet.
Hatte also ca. eine Stunde lang den CUNO nicht in Verwendung. Keine Bewegungsmelder, kein Regen, keine Kommandos. Nichts.
Versuche ich dann den Scheinwerfer ein zu schalten, gab es auch da die Verzögerung. In diesem Fall waren es etwa 8 Sekunden. Jedes weitere Kommando wird dann aber sofort (also korrekt) ausgeführt. Dann auch beim dem SM-4 Modul.
Ich muss also davon ausgehen, das der CUNO das Funksignal nicht direkt sendet. Entweder weil er den Befehl nicht bekommt, oder weil er ihn festhält.
Nur bin ich mir nicht sicher, ob ich das hier sauber analysiert bekomme. Soll ich ihn einfach mal auf die Aktuelle Firmware flashen?
VG
Ralf
Nach deinem Experiment faellt vmtl. Punkt 1 raus.
Update schadet nicht, wird aber vermutlich nichts bringen.
Ansonsten wuerde ich tcpdump bzw. zweites CUL vorschlagen, wie ich das vorher erwaehnt habe.
...für manche Dinge brauche ich einfach etwas länger... :-)
Ich kann jedoch vermelden, das ich das Problem einkreisen konnte: die (alte) Firmware auf dem CUNO scheint einen Bug gehabt zu haben.
Installiert war eine V1.46, und weil der CUNO relativ weit weg und verbaut ist, bin ich da nie dran gegangen.
Ich habe gestern meinen "Reserve-CUNO" auf die aktuelle V1.55 geflashed und den dann anstelle des alten eingebaut. Sei dem läuft alles so wie es soll. Keine Verzögerungen mehr und bislang keine "Disconnected/Reappeared" Meldungen mehr im Log.
Ich wollte das nur noch nachtragen, um hier einen passenden Abschluss des Threads zu finden. :-)
Ich glaube jetzt nach 2 Jahren läuft die inzwischen sehr umfangreiche Steuerung wirklich robust und zuverlässig!
Was für eine Freude! Vielen Dank Jungs!!
VG Ralf