00_CUL.pm Frage

[SpenZerX]

Hi,

ich habe in meiner 00_CUL.pm unten stehenden Code.

- dieser versucht 3 mal die V (Version) abzurufen
- bei Erfolg wird geprüft ob die Antwort konform ist.
- bei Mißerfolg wird das Device zum dummy (und funktioniert dann gefühlt nicht mehr)

Ist das so richtig?

Wenn ja meine Frage: Wieso sollte auf die Frage nach der Version immer die richtige Antwort kommen und nicht eine andere die dem CUL gerade auf der Zunge liegt? Die würde dann das Device zum dummy machen.



sub
CUL_DoInit($)
{
  my $hash = shift;
  my $name = $hash->{NAME};
  my $err;
  my $msg = undef;

  CUL_Clear($hash);
  my ($ver, $try) = ("", 0);
  while($try++ < 3 && $ver !~ m/^V/) {
    CUL_SimpleWrite($hash, "V");
    ($err, $ver) = CUL_ReadAnswer($hash, "Version", 0, "^V");
    return "$name: $err" if($err && ($err !~ m/Timeout/ || $try == 3));
    $ver = "" if(!$ver);
  }

  if($ver !~ m/^V/) {
    $attr{$name}{dummy} = 1;
    $msg = "Not an CUL device, got for V:  $ver";
    Log3 $name, 1, $msg;
    return $msg;
  }
  $ver =~ s/[\r\n]//g;
  $hash->{VERSION} = $ver;

[rudolfkoenig]

Weil vorher CUL_Clear alle "alten" Daten wegwirft.

[SpenZerX]

Weil vorher CUL_Clear alle "alten" Daten wegwirft.

Das ist aber eine FHEM interne Sache. Im TCP Protokoll lässt sich kein Kommando erkennen das CUL/CUNO Clear heisst.

Ist der Zeitpunkt wann der CUL/CUNO Daten eigenmächtig zu FHEM sendet relevant? Also im Falle von empfangenen Funksignalen werden/können diese sofort über TCP an FHEM gesendet werden? Sie würden dann möglicherweise als Antwort auf die Frage V(ersion) aufgefasst werden. Oder gibt es einen Schutz der das verhindert?

[rudolfkoenig]

Ist das eine theoretische Frage fuer die Schule oder gibt es ein konkretes Problem?

[SpenZerX]

ja schon ein Problem. Nach mehreren Stunden Betrieb ist das dummy flag plötzlich gesetzt.

Ist aber mein Problem da es sich um einen Nachbau ähnlich FHEMduino handelt.

culfw / clib / tcplink.c  wird mir da bestimmt weiterhelfen.

MFG

[kaihs]

Aus eigener Erfahrung glaube ich auch, dass es da ein Problem gibt.

Zum Zeitpunkt der Versionsabfrage darf der CUL auf keinen Fall in irgendeinem Empfangsmodus sein, sei es RF, Onewire oder IR.
Sonst kann es m. E. dazu kommen, dass statt der Antwort auf das V Kommando empfangene Daten vom CUL gesendet werden.

Passiert nicht immer, aber mit der Anzahl der empfangenen Daten steigt die Wahrscheinlichkeit.

[SpenZerX]

Zum Zeitpunkt der Versionsabfrage darf der CUL auf keinen Fall in irgendeinem Empfangsmodus sein, sei es RF, Onewire oder IR.
Sonst kann es m. E. dazu kommen, dass statt der Antwort auf das V Kommando empfangene Daten vom CUL gesendet werden.

Passiert nicht immer, aber mit der Anzahl der empfangenen Daten steigt die Wahrscheinlichkeit.

Das wird der Grund sein.
Bei mir fragt er aktuell alle 10 Sekunden nach der Version weil die Verbindung nur 10 Sekunden steht. Wird aber sofort wieder aufgebaut.

Hat der CUL/CUNO eigentlich einen Schutz gegen fremde Benutzung wenn man den Port nach draußen legt?

Ich werde da noch eine passphrase einbauen die die Verbindung legitimiert.

[rudolfkoenig]

weil die Verbindung nur 10 Sekunden steht.

Ich finde das ist nicht in Ordnung, und sollte als erstes repariert werden.

[SpenZerX]

Ich finde das ist nicht in Ordnung, und sollte als erstes repariert werden.

OK, scheinbar trennt FHEM  die Verbindung nach 10 Sek Leerlauf. Wie sollte ich das verhindern? Durch periodisches senden eines V an FHEM als keep alive z.B. alle 5 Sekunden?

[rudolfkoenig]

OK, scheinbar trennt FHEM  die Verbindung nach 10 Sek Leerlauf.

Das ist so nicht wahr, die Verbindung sollte vom define bis Loeschen oder FHEM Herunterfahren bestehen. Ich vermute dass die andere Seite die Verbindung kappt, da selbst bei einem Netzwerkfehler der Timeout laenger als 10 Sekunden dauern duerfte. Oder auf FHEM laeuft ein periodisches  modify, das koennte das Problem auch erklaeren.

[SpenZerX]

Ok, 10 Sek war default bei meiner Hardware. Habe ich jetzt auf 2 Stunden geändert. Sieht erstmal gut aus.

Bei Neustart der Hardware oder bei Neustart der Fritzbox wird die Verbindung von FHEM nicht automatisch sofort wieder hergestellt. Kann man da was machen?
Wenn ich auf das DEF Feld im FHEMWEB gehe und bestätige wird sie wieder aufgebaut.

[rudolfkoenig]

Ok, 10 Sek war default bei meiner Hardware. Habe ich jetzt auf 2 Stunden geändert.

Verstehe ich richtig: die andere Seite macht die Verbindung nach 2 Stunden zu? Warum?

Bei Neustart der Hardware oder bei Neustart der Fritzbox wird die Verbindung von FHEM nicht automatisch sofort wieder hergestellt.

Was ist Hardware und was ist Fritzbox?

Das Problem ist eigentlich ein TCP/IP-Problem: Wenn die andere Seite unzivilisiert ist, und bei reboot/shutdown nicht mitteilt, dass sie weg ist (kein Tschuess), dann greift das normale TCP-Keepalive, was per default auf 2 Stunden gesetzt ist. Man kann auf User-Level "pings" machen, dann faellt die Abwesenheit frueher auf. Oder die globalen TCP-Keepalive Parameter aendern. Ich wuerde vorher der anderen Seite manieren beibringen.

[SpenZerX]

SDK Manual steht:
usage of timeout=0, is deprecated. -> habe ich interpretiert als sollte man nicht machen
weiterhin: timeout interval, unit: second, maximum: 7200 seconds

Ich wuerde vorher der anderen Seite manieren beibringen.

Soll ich bei der Telekom anrufen und bitten die Zwangstrennung zu unterlassen?
Oder ist das Ereignis Zwangstrennung nicht gleichzusetzen mit einem Reset der Hardware durch Watchdog?

[rudolfkoenig]

SDK Manual steht:

Um welche SDK gehts es hier?

Soll ich bei der Telekom anrufen und bitten die Zwangstrennung zu unterlassen?

Ich befuerchte, das wird nicht viel bewirken.
Wenn doch, wuerde in diesem Fall Kopfschmerzen ersparen.

Oder ist das Ereignis Zwangstrennung nicht gleichzusetzen mit einem Reset der Hardware durch Watchdog?

Ich fuerchte doch. Ideal waere, wenn der Router in FHEM nach der Zwangstrennung was aufrufen koennte.
Alternativ setzt man die Zwangstrennung auf eine bestimmte Uhrzeit, und FHEM fuehrt danach "set CUL reopen" aus.

[SpenZerX]

Es geht um die SDK vom ESP8266. Die verwendet LwIP.

Generell funktioniert jetzt alles im Idealfall 24h bis auf die von der Fritz Box arrangierte nötige Zwangstrennung. Hier muss ich wohl die nächsten Tage morgens manuell eingreifen.

Das ist natürlich auf Dauer nicht akzeptabel. Ich werde dann weiter nach einer Lösung suchen. Auf der FHEM Seite.

Also ich ziehe gerade um mit meinem FHEM System auf einen Root Server auf dem ein paar Experimentelle Dienste laufen für neue IoT Hardware.