Hallo zusammen,
ich habe eine Remote-FHEM Installation per FHEM2FHEM Modul an meine
"Haupt"-FHEM-Installtion gekoppelt. Das funktioniert auch super. Aber nach
ein paar wenigen Tagen empfängt mein Haupt-FHEM keine Daten mehr vom
"Client"-FHEM.
Nach einem "shutdown restart" werden wieder Daten empfangen.
Gibt es in FHEM2FEHM keine Reconnect-Logik? Oder kann ich mit einem Befehl
es zum Reconnect zwingen wenn ich feststelle das seit ca 10min keine Daten
mehr kommen? Ein "shutdown restart" ist schon ziemlich die
Holzhammer-methode..... ;)
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
> Aber nach ein paar wenigen Tagen empfängt mein Haupt-FHEM keine Daten mehr
> vom "Client"-FHEM.
Steht in einem der FHEM-logs was auffaelliges? Kann man noch ueber den Client
Kommandos auf dem Haupt-Server auffuehren? Wie sind die beiden verbunden, LOG
oder RAW?
> Gibt es in FHEM2FEHM keine Reconnect-Logik?
Doch, aber erst wenn die Verbindung zwischen den beiden getrennt ist.
Evtl. hat der Haupt-fhem den Client (warum auch immer) aus der Verteilerliste
gestrichen. Kannst Du folgendes testen (im Normall und im Fehlerfall):
{ my $r="";; foreach my $c (keys %client) { $r .= "\n$client{$c}{addr}/$client{$c}{inform}" if($client{$c}{inform}) } ;; $r }
Das ist eine Zeile, ausgefuehrt auf dem Haupt-Fhem (telnet oder FHEMWEB), mich
interessiert der Rueckgabewert.
> Oder kann ich mit einem Befehl es zum Reconnect zwingen wenn ich feststelle
> das seit ca 10min keine Daten mehr kommen?
Nur via
{ FHEM2FHEM_Disconnected($defs{}) }
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
On 7 Jun., 09:16, "tobias.faust" wrote:
> Hallo zusammen,
>
> ich habe eine Remote-FHEM Installation per FHEM2FHEM Modul an meine
> "Haupt"-FHEM-Installtion gekoppelt. Das funktioniert auch super. Aber nach
> ein paar wenigen Tagen empfängt mein Haupt-FHEM keine Daten mehr vom
> "Client"-FHEM.
> Nach einem "shutdown restart" werden wieder Daten empfangen.
Seltsam. Ich stelle bei mir auf der Fritzbox 7390 die angeschlossenen
Devices CUL sowie RFXtrx433 per FHEM2FHEM meinem Haupt-FHEM-Server
(Sheevaplug) unter Debian Squeeze bereit. Das läuft seit Monaten und
stabil.
Normalerweise überstehen TCP-Verbindungen auch Netzwerkprobleme
klaglos. Da stören auch Paketverluste nicht.
Versuch mal zwischen beiden Systemen parallel eine SSH (bzw. bei
Fritzbox) eine Telnet-Verbindung aufzumachen und zu beobachten, ob
diese nach einigen Tagen noch problemlos läuft.
Was für eine Konfiguration (Betriebsysteme) hast Du?
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Also in den Logs (fakelog) sehe ich nix. Es fällt nur auf das keine Events
mehr rein kommen. Verbunden sind sie per Internet, die letzten Events die
reinkommen sind aber zeitlich gesehen ungleich des Fritzbox-Reconnects
Verbunden sind sie per RAW
Deine Perl-Zeile habe ich im Webif ausgeführt, da kommt aber nix zurück??
Am Donnerstag, 7. Juni 2012 10:18:18 UTC+2 schrieb Rudolf Koenig:
>
> > Aber nach ein paar wenigen Tagen empf�ngt mein Haupt-FHEM keine Daten
> mehr
> > vom "Client"-FHEM.
>
> Steht in einem der FHEM-logs was auffaelliges? Kann man noch ueber den
> Client
> Kommandos auf dem Haupt-Server auffuehren? Wie sind die beiden verbunden,
> LOG
> oder RAW?
>
>
> > Gibt es in FHEM2FEHM keine Reconnect-Logik?
>
> Doch, aber erst wenn die Verbindung zwischen den beiden getrennt ist.
> Evtl. hat der Haupt-fhem den Client (warum auch immer) aus der
> Verteilerliste
> gestrichen. Kannst Du folgendes testen (im Normall und im Fehlerfall):
>
> { my $r="";; foreach my $c (keys %client) { $r .=
> "\n$client{$c}{addr}/$client{$c}{inform}" if($client{$c}{inform}) } ;; $r }
>
> Das ist eine Zeile, ausgefuehrt auf dem Haupt-Fhem (telnet oder FHEMWEB),
> mich
> interessiert der Rueckgabewert.
>
>
> > Oder kann ich mit einem Befehl es zum Reconnect zwingen wenn ich
> feststelle
> > das seit ca 10min keine Daten mehr kommen?
>
> Nur via
> { FHEM2FHEM_Disconnected($defs{}) }
>
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
> Deine Perl-Zeile habe ich im Webif ausgeführt, da kommt aber nix zurück??
Welche der beiden? Vor oder nach dem Neustart des Clients?
Haette gerne folgendes
- Server: Status-Perl
- Client: FHEM2FHEM_Disconnected
- Server: Status-Perl
- Client: Neustart
- Server: Status-Perl
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Ok,
auf dem Client kommt folgendes zurück wenn der Connect noch funktioniert.
192.168.10.37:50743/raw
Wenn die Verbindung abgebrochen ist melde ich mich wieder mit dem output des Scriptes, incl Neustart
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
On 7 Jun., 14:24, "tobias.faust" wrote:
> mehr rein kommen. Verbunden sind sie per Internet, die letzten Events die
> reinkommen sind aber zeitlich gesehen ungleich des Fritzbox-Reconnects
> Verbunden sind sie per RAW
Verstehe ich richtig, dass die beiden FHEM-Instanzen per Internet
verbunden sind?
Dann verwendest Du zwei Internet-Anschlüsse?
Wenn die Internet-Anschlüsse dynamische IP-Adressen haben, Dein
Provider täglich eine Zwangstrennung mit Vergabe neuer IP-Adresse
durchführt und Du daher einen DynDNS-Dienst oder ähnliches verwendest,
ist die Situation klar.
Das das nicht genau zeitlich zusammenpasst, ist verständlich. Für den
Abbau einer TCP-Verbindung gibt es verschiedene Möglichkeiten
(Timeouts (sofern KEEPALIVE genutzt wird), ICMP-Pakete, etc.). Bis der
Rechner bei TCP merkt, dass etwas nicht stimmt, kann es ziemlich lange
dauern. Das kommt auch darauf an, wem Dein Provider die alte IP-
Adresse neu zuweist und wie der Router des neuen Kunden auf Deine TCP-
Pakete reagiert.
Das Scenario würde nur funktionieren, wenn Du Du zeitgesteuert die
FHEM2FHEM-Verbindung trennen und neu aufbauen würdest (mit neuer
Namensauflösung). Ob das FHEM2FHEM_Disconnected($defs{InstanName>} ausreicht und FHEM2FHEM die Namensauflösung erneut macht,
ist mir unklar (Rudi?). Eine genaue Synchronisation ohne Verlust von
Daten wird aber schwer.
Eine andere Alternative (meines Erachtens nach besser), wäre die
beiden Internet-Anschlüsse per VPN zu verbinden (z.B. OpenVPN oder
IPSEC) und diese Verbindungen so einzustellen, dass nach
Zwangstrennung die VPN-Verbindung schnell wieder aufgebaut wird. Die
Realisierung kommt darauf an, welches VPN-Protokoll Du verwendest.
Alternativ kannst Du auch die beiden Anschlüsse per IPv6 mit
statischer IPv6-Adresse verbinden. Dazu kannst Du einen IPv6-Tunnel-
Provider wie z.B. http://www.sixxs.net/ verwenden. Wenn ich es richtig
verstanden habe, müßte FHEM auch mit IPv6 zurecht kommen. Wenn nicht,
wird es sicherlich später mal gebraucht, so dass dies ein Anlass zur
Realisierung wäre.
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
> Ob das FHEM2FHEM_Disconnected($defs{} ausreicht und
> FHEM2FHEM die Namensauflösung erneut macht, ist mir unklar (Rudi?).
Wenn Willis Theorie korrekt ist, dann muesste das FHEM Client regelmaessig die
Verbindung testen, z.Bsp indem auf dem Client ein at alle 10 Sekunden auf dem
Server einen dummy aendert. Damit wuerde das Client OS ein Paket rausschicken,
und merken dass die Gegenseite weg ist. Ein Reconnect muesste dann die neue
Adresse holen, sofern dieser beim DNS Provider schon aktuell ist, und nirgendwo
gecached wurde.
Ich sehe mit so eine Verbindung zwei grundsaetzliche Probleme:
- Die Verbindung ist weder verschluesselt, noch wird ein Passwort verlangt,
deswegen ist VPN ratsam.
- Nach Zwangstrennung gibt es defintiv ein "Loch" (egal ob VPN oder anders),
da FHEM2FHEM keine Events puffert, damit muss man rechnen.
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
On 7 Jun., 16:23, Rudolf Koenig wrote:
> Ich sehe mit so eine Verbindung zwei grundsaetzliche Probleme:
> - Die Verbindung ist weder verschluesselt, noch wird ein Passwort verlangt,
> deswegen ist VPN ratsam.
Stimmt ja: FHEM2FHEM hat keine Authentisierung per Kennung/Kennwort.
Daher vergiss die Idee der Nutzung von IPv6, da dies dieses Problem
nicht löst.
Den eingehenden Port einfach so zu öffnen, ist sehr gefährlich. Die
Portscanner erkennen schnell, dass da ein offener Port ist und
probieren dann weiteres............
> - Nach Zwangstrennung gibt es defintiv ein "Loch" (egal ob VPN oder anders),
> da FHEM2FHEM keine Events puffert, damit muss man rechnen.
Evtl. bekommt man es hier so hin, dass nach Neuaufbau des VPN-Tunnels
ein paar Pakete verlorengehen, aber die TCP-Verbindung bestehen
bleibt.
In diesem Fall würde TCP puffern und es gehen keine Daten verloren.
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Um etwas Klarheit zu schaffen, es sind zwar beide Instanzen per Internet
verbunden, befinden sich aber im VPN. Sieht man auch, da der Client in
meinem letzten Post die 192.168.10.37 als verbundene Instanz ausweist und
keine öffentliche IP ;)
Der Client ist einer täglichen Zwangstrennung unterbunden, die Haupt-FHEM
Instanz nicht.
Ich schaue morgen nochmal rein ob die Verbindung noch steht, die
Zwangstrennung liegt gegen 3Uhr morgens
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Kurzer Zwischenbericht.
Verbindung war wieder weg. Rudis Perl Zeile hat auf dem Client keine
Ausgabe gebracht. Nach einem { FHEM2FHEM_Disconnected($defs{"CUNO_Remote"})
} war die Verbindung wieder da und die PerlZeile auf dem Client gab auch
wieder den Connectstring zurück.
Was ich nicht verstanden habe, wie soll ich vom Haupt-FHEM auf dem Client
ein dummy ändern?? Wenn ich auf dem Client einen dummy anlege "define dummy
dummy" und ich versuche auf dem Haupt-Fhem ein "set dummy on" so kommt nur
lapidar "please define dummy first"
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
> Verbindung war wieder weg. Rudis Perl Zeile hat auf dem Client keine
> Ausgabe gebracht.
Das ist nett, mich interessiert aber der Server :) Zitat:
> - Server: Status-Perl
> - Client: FHEM2FHEM_Disconnected
> - Server: Status-Perl
> - Client: Neustart
> - Server: Status-Perl
> Was ich nicht verstanden habe, wie soll ich vom Haupt-FHEM auf dem Client
> ein dummy ändern??
Auf dem Server ein FS20 oder HM Geraet anlegen, es mit attribut "dummy"
versehen. Geraet auf dem Client auch anlegen, und IODev dem FHEM2FHEM zuordnen.
Oder automatisch anlegen lassen. Jetzt kann man das Geraet auch auf dem Client
schalten. Kann sein dass ich irgendwo noch ein Denkfehler habe, habs nicht
getestet.
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
{ my $r="";; foreach my $c (keys %client) { $r .=
"\n$client{$c}{addr}/$client{$
c}{inform}" if($client{$c}{inform}) } ;; $r }
- Server: Status-Perl
-> leere ausgabe
- Client: FHEM2FHEM_Disconnected
-> ok
- Server: Status-Perl
-> 192.168.10.37:42592/raw
- Client: Neustart
-> ok
- Server: Status-Perl
-> 192.168.10.37:36124/raw
Hoffe das war jetzt richtig...
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
> - Server: Status-Perl
> -> leere ausgabe
Das bedeutet, dass der Server den Client nicht mehr benachrichtigen will, ich
vermute er hat den Verbindungsabbruch schon entdeckt, und den Client komplett
entfernt. Der Client hat den Verbindungsbbruch dagegen nicht gemerkt, und
wartet geduldig.
Kannst Du bitte in 93_FHEM2FHEM.pm unter der Zeile
my $conn = IO::Socket::INET->new(PeerAddr => $dev);
die Zeile
setsockopt($conn, SOL_SOCKET, SO_KEEPALIVE, 1);
einfuegen, und nochmal testen.
Alternativ kann ein regelmaessig durchgefuehrter "set serverDummy on" (bei
richtig angelegten serverDummy) auch helfen.
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Diese Nacht ist die Conn wieder verloren gegangen. Habs jetzt eingefügt und
beobachte ein paar Tage....
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Leider hat es nicht den gewünschten Erfolg gebracht. Gestern abend ist
wieder die Verbindung abgebrochen. Falls das mit dem Dummy wert auch nichts
bringt werde ich einfach die Zeiten der letzten Aktualisierungen prüfen.
Wenn die irgendwann größer werden (i.d.R. größer 15min) soll ein reconnect
erfolgen.
Trotzdem Danke! für die eingebrachten Ideen...
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com