Autor Thema: 00_CUL.pm Frage  (Gelesen 4256 mal)

SpenZerX

  • Gast
00_CUL.pm Frage
« am: 16 Oktober 2015, 15:08:20 »
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;

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 22552
Antw:00_CUL.pm Frage
« Antwort #1 am: 16 Oktober 2015, 15:22:03 »
Weil vorher CUL_Clear alle "alten" Daten wegwirft.

SpenZerX

  • Gast
Antw:00_CUL.pm Frage
« Antwort #2 am: 16 Oktober 2015, 15:50:12 »
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?





Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 22552
Antw:00_CUL.pm Frage
« Antwort #3 am: 16 Oktober 2015, 16:03:10 »
Ist das eine theoretische Frage fuer die Schule oder gibt es ein konkretes Problem?

SpenZerX

  • Gast
Antw:00_CUL.pm Frage
« Antwort #4 am: 16 Oktober 2015, 18:52:50 »
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

Offline kaihs

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1087
Antw:00_CUL.pm Frage
« Antwort #5 am: 16 Oktober 2015, 21:16:36 »
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.
Banana Pi, Add-On Board mit 1.8" TFT LCD und IR-Sender, FHEM V5.9, CULFW V1.61, div. Homematic Komponenten, Pollin Funksteckdosen, Selbstbau CUL433 MHz, Jeelink Clone, EC3000
Selbstbau CUL868MHz für Wireless M-Bus, FHEMduino mit Logilink Temp.-sensoren und Auriol Wetterstation

SpenZerX

  • Gast
Antw:00_CUL.pm Frage
« Antwort #6 am: 16 Oktober 2015, 21:51:24 »
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.

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 22552
Antw:00_CUL.pm Frage
« Antwort #7 am: 17 Oktober 2015, 11:09:06 »
Zitat
weil die Verbindung nur 10 Sekunden steht.
Ich finde das ist nicht in Ordnung, und sollte als erstes repariert werden.

 

SpenZerX

  • Gast
Antw:00_CUL.pm Frage
« Antwort #8 am: 17 Oktober 2015, 11:47:27 »
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?

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 22552
Antw:00_CUL.pm Frage
« Antwort #9 am: 17 Oktober 2015, 12:03:11 »
Zitat
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

  • Gast
Antw:00_CUL.pm Frage
« Antwort #10 am: 17 Oktober 2015, 13:50:54 »
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.
« Letzte Änderung: 17 Oktober 2015, 13:53:51 von SpenZerX »

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 22552
Antw:00_CUL.pm Frage
« Antwort #11 am: 18 Oktober 2015, 12:40:45 »
Zitat
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?

Zitat
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

  • Gast
Antw:00_CUL.pm Frage
« Antwort #12 am: 18 Oktober 2015, 13:45:16 »
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?

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 22552
Antw:00_CUL.pm Frage
« Antwort #13 am: 19 Oktober 2015, 18:24:49 »
Zitat
SDK Manual steht:
Um welche SDK gehts es hier?

Zitat
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.

Zitat
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

  • Gast
Antw:00_CUL.pm Frage
« Antwort #14 am: 19 Oktober 2015, 20:48:07 »
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.


 

decade-submarginal