MYSENSORS EthernetGateway keine disconnect Erkennung (erst nach exakt 2 Stunden)

[frankbeckers]

Hallo,

ich habe mich entschieden den Ethernet Gateway von MYSENSORS basierend auf 1.4.1 einzusetzen. Dazu folgende Definitionen:

Code Auswählen Erweitern

Internals:
   DEF        192.168.178.66:5003
   DeviceName 192.168.178.66:5003
   FD         120
   NAME       EthernetGateway
   NOTIFYDEV  global
   NR         595
   NTFY_ORDER 50-EthernetGateway
   PARTIAL
   STATE      connected
   TYPE       MYSENSORS
   ack        1
   inclusion-mode 1
   outstandingAck 0
   version    1.4.1
   Readings:
     2015-05-26 17:41:38   connection      connected
     2015-05-26 17:41:38   state           opened
   Messagesforradioid:
     1:
       lastseen   -1
       nexttry    -1
       numtries   1
       messages:
     10:
       lastseen   -1
       nexttry    -1
       numtries   1
       messages:
     100:
       lastseen   -1
       nexttry    -1
       numtries   1
       messages:
     101:
       lastseen   -1
       nexttry    -1
       numtries   1
       messages:
Attributes:
   autocreate 1
   first-sensorid 100
   last-sensorid 200
   requestAck 1
   room       MySensors
   stateFormat connection
   verbose    5

Auch funktionieren die MYSENSOR_DEVICES ohne Probleme.

Allerdings gibt es bei einem Ausfall (z.B. Stromausfall) des Ethernet Gateway keinen direkten Reconnect, sondern erst nach exakt 2 Stunden. Dies kann ich jederzeit reproduzieren.

Code Auswählen Erweitern

2015.05.25 22:28:32 5: MYSENSORS/RAW: /101;103;1;0;25;570

2015.05.25 22:28:32 5: MYSENSORS Read: Rx: fr=101 ci=103 c=001(C_SET         ) st=025(V_VAR2          ) ack=0 '570'

2015.05.25 22:28:32 5: MYSENSORS/RAW: /101;104;1;0;0;27.61

2015.05.25 22:28:32 5: MYSENSORS Read: Rx: fr=101 ci=104 c=001(C_SET         ) st=000(V_TEMP          ) ack=0 '27.61'

2015.05.25 22:28:32 5: MYSENSORS/RAW: /101;105;1;0;26;0 days 15:45:37.300

2015.05.25 22:28:32 5: MYSENSORS Read: Rx: fr=101 ci=105 c=001(C_SET         ) st=026(V_VAR3          ) ack=0 '0 days 15:45:37.300'

---------->>>>>>>>>hier gab es jetzt einen Netzunterbrechung....

2015.05.25 22:29:18 3: Benzinpreis: Read callback: request type was Update,
header: HTTP/1.1 200 OK
Date: Mon, 25 May 2015 20:23:38 GMT
Server: Apache/2.2.22 (Ubuntu)
Vary: Cookie,Accept-Encoding
Content-Type: text/html; charset=utf-8
Via: 1.0 www.clever-tanken.de
Content-Length: 24116
Connection: close, buffer empty,
Error gethostbyname www.clever-tanken.de failed
2015.05.25 22:29:58 3: FBREMOTE: fbremote_energy GetSID() got error in callback: gethostbyname fritz.box failed
2015.05.25 22:30:04 1: HMLAN_Parse: hmlan new condition timeout
2015.05.25 22:30:04 1: 192.168.178.48:1000 disconnected, waiting to reappear (hmlan)
2015.05.25 22:30:04 1: HMLAN_Parse: hmlan new condition disconnected

---------->>>>>>>>>usw.

2015.05.26 00:28:39 1: 192.168.178.66:5003 disconnected, waiting to reappear (EthernetGateway)
2015.05.26 00:28:39 1: 192.168.178.66:5003 reappeared (EthernetGateway)

Gibt es dazu eine globale Einstellung oder liegt hier ein "Defekt" vor.

Vielen Dank.
Frank

[rudolfkoenig]

Liegt wohl daran, dass FHEM nichts sendet, und deswegen das Problem mit dem TCP_KEEPALIVE Automatismus entdeckt wird, was in der Standardeinstellung nach 2 Stunden aktiv wird.

[frankbeckers]

Liegt wohl daran, dass FHEM nichts sendet, und deswegen das Problem mit dem TCP_KEEPALIVE Automatismus entdeckt wird, was in der Standardeinstellung nach 2 Stunden aktiv wird.

Damit habe ich mich mal auf die Suche gemacht, und in DevIo.pm folgendes gefunden:

Code Auswählen Erweitern

$conn->setsockopt(SOL_SOCKET, SO_KEEPALIVE, 1) if(defined($conn));

Damit wird ja dieser Mechanismus aktiviert. Auf der Suche nach dem Timeout von exakt 2 Stunden bin ich dann im Linux (bei mir Ubuntu 14.04.2 LTS) auf folgende Abfrage gestossen:

Code Auswählen Erweitern

sysctl net.ipv4.tcp_keepalive_time

Damit lässt sich die Systemweite Keepalive Zeit abfragen, welche (natürlich) auf 7200 Sekunden steht.

Mit dem Befehl

Code Auswählen Erweitern

sudo sysctl -w net.ipv4.tcp_keepalive_time=300

konnte ich diese erfolgreich auf 5 Minuten umstellen.

Auch ein Test mit dem Mysensors EthernetGateway war erfolgreich. Ein kurzes Trennen vom Strom reicht aus:

Code Auswählen Erweitern

...
2015.05.27 20:10:42 5: MYSENSORS/RAW: /101;105;1;0;26;0 days 06:50:24.901
2015.05.27 20:10:42 5: MYSENSORS Read: Rx: fr=101 ci=105 c=001(C_SET         ) st=026(V_VAR3          ) ack=0 '0 days 06:50:24.901'
2015.05.27 20:15:42 1: 192.168.178.66:5003 disconnected, waiting to reappear (EthernetGateway)
2015.05.27 20:15:42 1: 192.168.178.66:5003 reappeared (EthernetGateway)
2015.05.27 20:15:42 5: MYSENSORS send: Rx: fr=000 ci=000 c=003(C_INTERNAL    ) st=002(I_VERSION       ) ack=0 ''
2015.05.27 20:15:42 5: SW: 303b303b333b303b323b0a
2015.05.27 20:15:42 5: MYSENSORS/RAW: /101;104;1;0;0;27.61
2015.05.27 20:15:42 5: MYSENSORS Read: Rx: fr=101 ci=104 c=001(C_SET         ) st=000(V_TEMP          ) ack=0 '27.61'
...


Da diese Einstellung allerdings Systemweit gilt stellt sich mir die Frage, ob es eine Möglichkeit gibt diese Einstellung nur Fhem weit zu machen?

Gruß
Frank

[Klaus0815]

Habe exakt das gleiche Problem, macht es evtl. Sinn, alle 5 min etwas zu einem Dummy-Device zu schicken ?

Welche Auswirkungen hat es, die keepalive_time systemweit wesentlich niedriger zu setzen ?

Viele grüße

Klaus

[hjgode]

Laut dieser Seite (http://www.tldp.org/HOWTO/html_single/TCP-Keepalive-HOWTO/) kann man, zumindest unter Linux, auch 'lokale' Werte für die keep_alive Settings setzen.

Code Auswählen Erweitern

This interface requires both sysctl and procfs to be built into the kernel, and procfs mounted somewhere in the filesystem (usually on /proc, as in the examples below). You can read the values for the actual parameters by "catting" files in /proc/sys/net/ipv4/ directory:


  # cat /proc/sys/net/ipv4/tcp_keepalive_time
  7200

  # cat /proc/sys/net/ipv4/tcp_keepalive_intvl
  75

  # cat /proc/sys/net/ipv4/tcp_keepalive_probes
  9
       

The first two parameters are expressed in seconds, and the last is the pure number. This means that the keepalive routines wait for two hours (7200 secs) before sending the first keepalive probe, and then resend it every 75 seconds. If no ACK response is received for nine consecutive times, the connection is marked as broken.

Modifying this value is straightforward: you need to write new values into the files. Suppose you decide to configure the host so that keepalive starts after ten minutes of channel inactivity, and then send probes in intervals of one minute. Because of the high instability of our network trunk and the low value of the interval, suppose you also want to increase the number of probes to 20.

Code Auswählen Erweitern

There are also three other socket options you can set for keepalive when you write your application. They all use the SOL_TCP level instead of SOL_SOCKET, and they override system-wide variables only for the current socket. If you read without writing first, the current system-wide parameters will be returned.

    TCP_KEEPCNT: overrides tcp_keepalive_probes

    TCP_KEEPIDLE: overrides tcp_keepalive_time

    TCP_KEEPINTVL: overrides tcp_keepalive_intvl



Entweder man löst das Problem generell oder aber im MySensors Modul wird eine periodische Abfrage der Versionsnummer des Gateways implementiert.

Ich bin leider von MySensors insgesamt und der FHEM Implementierung ziemlich enttäuscht.

~Josef

[Klaus0815]

Hat hier jemand mittlerweile was unternommen?  Das Problem besteht ja weiterhin?

Viele Grüße

Klaus

[DerFrickler]

Entweder man löst das Problem generell oder aber im MySensors Modul wird eine periodische Abfrage der Versionsnummer des Gateways implementiert.

Besteht die Möglichkeit eine solche Abfrage zu implementieren?

Gruß!

[DerFrickler]

Da sich bisher keiner zum Thema gemeldet hat, möchte ich diesen Punkt noch mal anbringen.

Binnen 24h Stunden habe ich mindestens einen Abbruch, der dazu führt dass die Sensoren zwar noch zum Gateway funken, aber keine Daten nach FHEM übertragen werden. Ein einfaches Connect des Sensors hilft hier auch nicht weiter, ich muss den GW stromlos schalten und dann ein neues connect durchführen.

Bei mir ist es von der Architektur halt so, dass FHEM auf einer virtuellen Maschine läuft und ich zwecks Kommunikation mit allen Devices LAN Anbindungen nutze. Das hat aber auch den Vorteil das man Funklöcher mit zusätzlichen Empfängern besser stopfen kann. Mit dem CUBE, HM-LAN und auch dem CUNX habe ich keinerlei Probleme, mit dem MySensors LAN Gateway leider mindestens 1X pro Tag.

Was läuft bei dem MySensors GW anders?

Gruß!

[Klaus0815]

Bei mir ist es wie bei Dir, Homematic, FS20,... funktioniert, aber mit MySensors ständig Ärger, brauche z.B. für 10m Entfernung, eine Wand schon einen Repeater

Bei mir taucht dann aber das Gatway nach 2 Stunden wider auf, musst Du es wirklich jedes Mal komplett reseten?  Falls ja vermute ich dass das Problem wo anders liegt

[DerFrickler]

Bei mir ist es wie bei Dir, Homematic, FS20,... funktioniert, aber mit MySensors ständig Ärger, brauche z.B. für 10m Entfernung, eine Wand schon einen Repeater

Mit der Empfangsqualität habe ich keine Probleme, nachdem ich jetzt RFM69 868MHz einsetzen komme ich auf RSSI werte um die -80 dBm.

Bei mir taucht dann aber das Gatway nach 2 Stunden wider auf, musst Du es wirklich jedes Mal komplett reseten?  Falls ja vermute ich dass das Problem wo anders liegt

Ein "disconnect" wird nicht angezeigt, ein einfaches "connect" reicht auch nicht aus. Der GW empfängt aber munter weiter von den Sensoren. Ich bin gerade eben dabei mit verbose 5 das ganze mal aus FHEM Sicht für GW und Sensor zu betrachten...

[hjgode]

Hi

ich habe das Problem so gelöst, dass ich die 00_MYSENSORS.pm erweitert habe. Das habe ich im Forum auch schon gepostet, aber is wohl noch nicht beim Maintainer angekommen.

Meine Änderung fügt dem Modul einen Timer hinzu, der alle 5 Minuten eine Versionsabfrage an den Gateway sendet. Damit fällt das Ding nicht über Keep-Alive irgendwann weg, weil keine Kommunikation stattfand.

Code Auswählen Erweitern

--- 00_MYSENSORS.pm.org 2017-02-08 17:38:18.966791895 +0100
+++ 00_MYSENSORS.pm 2017-01-04 07:44:12.811919078 +0100
@@ -218,6 +218,19 @@
   return undef;
}

+# GetConnectStatus
+sub GetConnectStatus($){
+ my ($hash) = @_;
+ my $name = $hash->{NAME};
+ Log3 $name, 4, "MySensors: GetConnectStatus called ...";
+   
+ #query version from gateway
+    sendMessage($hash, radioId => 0, childId => 0, cmd => C_INTERNAL, ack => 0, subType => I_VERSION, payload => '');
+
+ # neuen Timer starten in einem konfigurierten Interval.
+ InternalTimer(gettimeofday()+300, "MYSENSORS::GetConnectStatus", $hash);
+}
+
sub Timer($) {
   my $hash = shift;
   my $now = time;
@@ -247,6 +260,8 @@
   Log3 ($name, 5, "MYSENSORS/RAW: $data/$buf");
   $data .= $buf;

+  readingsSingleUpdate($hash,"lastRead","$buf",1);
+
   while ($data =~ m/\n/) {
     my $txt;
     ($txt,$data) = split("\n", $data, 2);
@@ -348,6 +363,8 @@
           my $client = shift;
           MYSENSORS::DEVICE::onGatewayStarted($client);
         });
+ #start connect watch thread, interval 500
+ InternalTimer(gettimeofday()+300, "MYSENSORS::GetConnectStatus", $hash);
         last;
       };
       $type == I_VERSION and do {


Gruss

~Josef