CUL HM empfängt nicht oder sendet Empfangsdaten nicht an den Rechner

[noansi]

Hallo Rudolf,


hier noch eine Variante als Diff, die die funktionelle Anpassung in fhem.pl auf das notwendigste begrenzt und alles andere dem nutzenden Modul zuschiebt:

Code: [Auswählen]

30c30
< # $Id: fhem.pl 5663 2014-04-26 09:13:54Z rudolfkoenig $
---
> # $Id: fhem.pl 5728 2014-05-03 09:41:12Z rudolfkoenig $
519,521d524
< # handle device not sending data until a timeout defined by the device module
< my $acttime = gettimeofday();
<
524,599d526
<
< # handle device not sending data until a timeout defined by the device module
< # shows also a little statistics for execution of the device ReadFn
< #
< # in device module do
< # define $hash->{LastReadTimeout} with the read timeout in seconds
< # define $hash->{ReadTimeoutFn} with the reference to the handler function for read timeouts
< #
< # example for CUL:
< #
< # add timeout function
< # sub CUL_ReadTimeoutFn($)
< # {
< # my ($hash) = @_;
< # my $name = $hash->{NAME};
< #
< # $hash->{LastReadTimeoutDetected}++;
< # Log3 $name, 1, "CUL_ReadTimeoutFn: $name Read timeout seen on serial port";
< #
< # DevIo_Disconnected($hash);
< #
< # return undef;
< # }
< #
< # in CUL_Read function directly after "my ($hash) = @_;" add
< # # do ReadFn statistics
< # if(defined($hash->{LastReadTime}))
< # {
< # my $acttime = gettimeofday();
< # my $td = $acttime - $hash->{LastReadTime};
< # my $mean = $hash->{LastReadTDmean} * $hash->{LastReadTDN};
< # $hash->{LastReadTDN}++;
< # if ($hash->{LastReadTDN} > 0)
< # {
< # $mean /= $hash->{LastReadTDN};
< # $mean += $td / $hash->{LastReadTDN};
< # $hash->{LastReadTDmean} = $mean;
< # }
< # else
< # {
< # $hash->{LastReadTDN} = 0;
< # }
< # $hash->{LastReadTD} = $td;
< # $hash->{LastReadTDmax} = $td if($td > $hash->{LastReadTDmax});
< # }
< #
< # in CUL_Define function add
< # $hash->{ReadTimeoutFn} = \&CUL_ReadTimeoutFn;
< # $hash->{LastReadTimeout} = 300;  # 300 seconds timeout, resonable for e.g. Homematic TH Sensors which continously send data in about 2 minutes interval
< #
< # in CUL_Undef function add
< # delete($hash->{ReadTimeoutFn});
< # delete($hash->{LastReadTime});
< # delete($hash->{LastReadTimeout});
< # delete($hash->{LastReadTDmax});
< # delete($hash->{LastReadTDmean});
< # delete($hash->{LastReadTDN});
< # delete($hash->{LastReadTD});
< # delete($hash->{LastReadTimeoutDetected});
<
< if(defined($hash->{LastReadTimeout}))
< {
< if (defined($hash->{LastReadTime}))
< {
< # handle timeout of receiving data from device
< my $td = $acttime - $hash->{LastReadTime};
< if($td > $hash->{LastReadTimeout})
< {
< Log 1, "Try ReadTimeoutFn $hash->{NAME}";
< $hash->{ReadTimeoutFn}->($hash) if(defined($hash->{ReadTimeoutFn}));
< $hash->{LastReadTime} = $acttime; #needed, else timeout forever after timeout
< next;
< }
< }
< }
<
649,652d575
<
< # handle device not sending data until a timeout defined by the device module
< $acttime = gettimeofday();
<
665,672d587
<
< # handle device not sending data until a timeout defined by the device module
< if(defined($hash->{LastReadTimeout}))
< {
< # set last ReadFn time stamp
< $hash->{LastReadTime} = $acttime;
< }
< 

Man beachte, dass der Zeitstempel jetzt nach dem Aufruf der ReadFn Funktion genommen wird (und werden muss).

Läßt man übrigens die Definition der ReadTimoutFn im jeweiligen Modul weg, so kann man auch nur die Statistik nutzen.
Fehlt die Definition von LastReadTimeout, dann passiert gar nichts, sprich es ist ausgeschaltet.

Ich hoffe, so findet es Deine Zustimmung.


Gruß und Danke,

Ansgar.

[rudolfkoenig]

Das Format ist besser, aber patch sagt dazu immer noch "Only garbage was found in the patch input.", richtig waere es gewesen mit diff -u, wie ich es vorher geschrieben habe.

Aendert nichts an meinen anderen  Bemerkungen, und ich habe nicht vor die Aenderungenin fhem.pl zu integrieren. Bevor ein von FHEM ausgeloestes Disconnect irgendwelche Probleme loest, sollte der Anwender den Hardware austauschen: die wenigsten werden mit einem 50%-Empfang zufrieden sein, und ich will nichts supporten, was die Haelfte der Nachrichten wg. Hardware-Fehler verliert.

Uebrigens man kann beliebig viele Timer mit sowas wie InternalTimer($triggerTime, "FnName", {hash=>$hash}) setzen, falls der Modulautor sowas realisieren moechte.

[noansi]

Hallo Rudolf,

ups, entschuldige bitte, -u ist mir im Eifer des Gefechts durchgegangen. Hier nochmal zum Abschluss ein kompletter diff -u und bitte den Versionsunterschied beachten weil er anderes wieder in die Vergangenheit befördert und nur MAIN die Änderungen enthält:

Code: [Auswählen]

--- ./fhem.pl 2014-05-11 10:22:30.000000000 +0200
+++ ../fhem.pl 2014-05-11 14:25:17.718179139 +0200
@@ -27,7 +27,7 @@
 #
 #  Homepage:  http://fhem.de
 #
-# $Id: fhem.pl 5728 2014-05-03 09:41:12Z rudolfkoenig $
+# $Id: fhem.pl 5663 2014-04-26 09:13:54Z rudolfkoenig $
 
 
 use strict;
@@ -54,8 +54,6 @@
 sub Dispatch($$$);
 sub DoTrigger($$@);
 sub EvalSpecials($%);
-sub FileRead($);
-sub FileWrite($@);
 sub FmtDateTime($);
 sub FmtTime($);
 sub GetLogLevel(@);
@@ -154,10 +152,7 @@
 sub cfgDB_ReadAll($);
 sub cfgDB_SaveState;
 sub cfgDB_SaveCfg;
-sub cfgDB_AttrRead($);
-sub cfgDB_ReadFile($);
-sub cfgDB_UpdateFile($);
-sub cfgDB_WriteFile($@);
+sub cfgDB_GlobalAttr;
 sub cfgDB_svnId;
 
 ##################################################
@@ -216,7 +211,7 @@
                 "eventMap userReadings";
 my $currcfgfile=""; # current config/include file
 my $currlogfile; # logfile, without wildcards
-my $cvsid = '$Id: fhem.pl 5728 2014-05-03 09:41:12Z rudolfkoenig $';
+my $cvsid = '$Id: fhem.pl 5663 2014-04-26 09:13:54Z rudolfkoenig $';
 my $duplidx=0;                  # helper for the above pool
 my $evalSpecials;               # Used by EvalSpecials->AnalyzeCommand parameter passing
 my $intAtCnt=0;
@@ -515,15 +510,93 @@
 # Main Loop
 sub MAIN {MAIN:};               #Dummy
 
-
 my $errcount= 0;
 while (1) {
   my ($rout,$rin, $wout,$win, $eout,$ein) = ('','', '','', '','');
 
   my $timeout = HandleTimeout();
 
+ # handle device not sending data until a timeout defined by the device module
+ my $acttime = gettimeofday();
+
   foreach my $p (keys %selectlist) {
     my $hash = $selectlist{$p};
+
+ # handle device not sending data until a timeout defined by the device module
+ # shows also a little statistics for execution of the device ReadFn
+ #
+ # in device module do
+ # define $hash->{LastReadTimeout} with the read timeout in seconds
+ # define $hash->{ReadTimeoutFn} with the reference to the handler function for read timeouts
+ #
+ # example for CUL:
+ #
+ # add timeout function
+ # sub CUL_ReadTimeoutFn($)
+ # {
+ # my ($hash) = @_;
+ # my $name = $hash->{NAME};
+ #
+ # $hash->{LastReadTimeoutDetected}++;
+ # Log3 $name, 1, "CUL_ReadTimeoutFn: $name Read timeout seen on serial port";
+ #
+ # DevIo_Disconnected($hash);
+ #
+ # return undef;
+ # }
+ #
+ # in CUL_Read function directly after "my ($hash) = @_;" add
+ # # do ReadFn statistics
+ # if(defined($hash->{LastReadTime}))
+ # {
+ # my $acttime = gettimeofday();
+ # my $td = $acttime - $hash->{LastReadTime};
+ # my $mean = $hash->{LastReadTDmean} * $hash->{LastReadTDN};
+ # $hash->{LastReadTDN}++;
+ # if ($hash->{LastReadTDN} > 0)
+ # {
+ # $mean /= $hash->{LastReadTDN};
+ # $mean += $td / $hash->{LastReadTDN};
+ # $hash->{LastReadTDmean} = $mean;
+ # }
+ # else
+ # {
+ # $hash->{LastReadTDN} = 0;
+ # }
+ # $hash->{LastReadTD} = $td;
+ # $hash->{LastReadTDmax} = $td if($td > $hash->{LastReadTDmax});
+ # }
+ #
+ # in CUL_Define function add
+ # $hash->{ReadTimeoutFn} = \&CUL_ReadTimeoutFn;
+ # $hash->{LastReadTimeout} = 300;  # 300 seconds timeout, resonable for e.g. Homematic TH Sensors which continously send data in about 2 minutes interval
+ #
+ # in CUL_Undef function add
+ # delete($hash->{ReadTimeoutFn});
+ # delete($hash->{LastReadTime});
+ # delete($hash->{LastReadTimeout});
+ # delete($hash->{LastReadTDmax});
+ # delete($hash->{LastReadTDmean});
+ # delete($hash->{LastReadTDN});
+ # delete($hash->{LastReadTD});
+ # delete($hash->{LastReadTimeoutDetected});
+
+ if(defined($hash->{LastReadTimeout}))
+ {
+ if (defined($hash->{LastReadTime}))
+ {
+ # handle timeout of receiving data from device
+ my $td = $acttime - $hash->{LastReadTime};
+ if($td > $hash->{LastReadTimeout})
+ {
+ Log 1, "$hash->{NAME} ReadFn timeout $hash->{LastReadTimeout}s reached. Trying ReadTimeoutFn...";
+ $hash->{ReadTimeoutFn}->($hash) if(defined($hash->{ReadTimeoutFn}));
+ $hash->{LastReadTime} = $acttime; #needed, else timeout forever after timeout
+ next;
+ }
+ }
+ }
+
     if(defined($hash->{FD})) {
       vec($rin, $hash->{FD}, 1) = 1
         if(!defined($hash->{directWriteFn}));
@@ -573,6 +646,10 @@
   # Function. The latter ist needed for Windows, where USB devices are not
   # reported by select, but is used by unix too, to check if the device is
   # attached again.
+
+ # handle device not sending data until a timeout defined by the device module
+ $acttime = gettimeofday();
+
   foreach my $p (keys %selectlist) {
     my $hash = $selectlist{$p};
     my $isDev = ($hash && $hash->{NAME} && $defs{$hash->{NAME}});
@@ -585,6 +662,14 @@
       } else {
         CallFn($hash->{NAME}, "ReadFn", $hash);
       }
+
+ # handle device not sending data until a timeout defined by the device module
+ if(defined($hash->{LastReadTimeout}))
+ {
+ # set last ReadFn time stamp
+ $hash->{LastReadTime} = $acttime;
+ }
+
     }
 
     if((defined($hash->{$wbName}) || defined($hash->{directWriteFn})) &&
@@ -1233,11 +1318,8 @@
 
   foreach my $d (sort keys %defs) {
     next if($defs{$d}{TEMPORARY});
-    if($defs{$d}{VOLATILE}) {
-      my $def = $defs{$d}{DEF};
-      $def =~ s/;/;;/g; # follow-on-for-timer at
-      print SFH "define $d $defs{$d}{TYPE} $def\n";
-    }
+    print SFH "define $d $defs{$d}{TYPE} $defs{$d}{DEF}\n"
+        if($defs{$d}{VOLATILE});
 
     my $val = $defs{$d}{STATE};
     if(defined($val) &&
@@ -1885,20 +1967,17 @@
     if($arg[1]) {
       foreach my $sdev (@list) { # Show a Hash-Entry or Reading for each device
 
-        if($defs{$sdev}) {
-          if($defs{$sdev}{$arg[1]}) {
-            $str .= sprintf("%-20s %s\n", $sdev, $defs{$sdev}{$arg[1]});
-
-          } elsif($defs{$sdev}{READINGS} &&
-                  $defs{$sdev}{READINGS}{$arg[1]}) {
-            $str .= sprintf("%-20s %s %s\n", $sdev,
-                    $defs{$sdev}{READINGS}{$arg[1]}{TIME},
-                    $defs{$sdev}{READINGS}{$arg[1]}{VAL});
-
-          } elsif($attr{$sdev} && $attr{$sdev}{$arg[1]}) {
-            $str .= sprintf("%-20s %s\n", $sdev, $attr{$sdev}{$arg[1]});
-
-          }
+        if($defs{$sdev} &&
+           $defs{$sdev}{$arg[1]}) {
+          $str .= $sdev . " " .
+                  $defs{$sdev}{$arg[1]} . "\n";
+
+        } elsif($defs{$sdev} &&
+           $defs{$sdev}{READINGS} &&
+           $defs{$sdev}{READINGS}{$arg[1]}) {
+          $str .= $sdev . " ".
+                  $defs{$sdev}{READINGS}{$arg[1]}{TIME} . " " .
+                  $defs{$sdev}{READINGS}{$arg[1]}{VAL} . "\n";
         }
       }
 
@@ -1935,6 +2014,7 @@
   $param =~ s,\.pm$,,g;
   my $file = "$attr{global}{modpath}/FHEM/$param.pm";
   my $cfgDB = '-';
+
   if( ! -r "$file" ) {
     if(configDBUsed()) {
       # try to find the file in configDB
@@ -2120,13 +2200,10 @@
     my $counter = 0;
 
     if(configDBUsed()) {
-      my $list = cfgDB_Read99(); # retrieve filelist from configDB
-      if($list) {
-        foreach my $m (split(/,/,$list)) {
-          $m =~ m/^([0-9][0-9])_(.*)\.pm$/;
-          CommandReload(undef, $m) if(!$modules{$2}{LOADED});
-          $counter++;
-        }
+      my @dbList = split(/,/,cfgDB_Read99()); # retrieve filelist from configDB
+      foreach my $m (@dbList) {
+        CommandReload(undef, $m);
+        $counter++;
       }
     }
 
@@ -3214,15 +3291,13 @@
 {
   my ($f) = @_;
 
-  my ($err, @rows);
   if($f eq 'configDB') {
-    @rows = cfgDB_AttrRead('global');
-  } else {
-    ($err, @rows) = FileRead($f);
-    die("$err\n") if($err);
+    cfgDB_GlobalAttr();
+    return;
   }
 
-  foreach my $l (@rows) {
+  open(FH, $f) || die("Cant open $f: $!\n");
+  while(my $l = <FH>) {
     $l =~ s/[\r\n]//g;
     next if($l !~ m/^attr\s+global\s+([^\s]+)\s+(.*)$/);
     my ($n,$v) = ($1,$2);
@@ -3231,6 +3306,7 @@
     $attr{global}{$n} = $v;
     GlobalAttr("set", "global", $n, $v);
   }
+  close(FH);
 }
 
 
@@ -3784,50 +3860,4 @@
   return ($attr{global}{configfile} eq 'configDB');
 }
 
-sub
-FileRead($)
-{
-  my ($fname) = @_;
-  my ($err, @ret);
-
-  if(configDBUsed()) {
-    @ret = cfgDB_FileRead($fname);
-    $err = "$fname not found in the database." if(@ret==1 && !defined($ret[0]));
-
-  } else {
-    if(open(FH, $fname)) {
-      @ret = <FH>;
-      close(FH);
-    } else {
-      $err = "Can't open $fname: $!";
-    }
-  }
-
-  return ($err, @ret);
-}
-
-sub
-FileWrite($@)
-{
-  my ($fname, @rows) = @_;
-  my ($err, @ret);
-
-  if(configDBUsed()) {
-    return cfgDB_FileWrite($fname, @rows);
-
-  } else {
-    if(open(FH, ">$fname")) {
-      foreach my $l (@rows) {
-        print FH $l;
-      }
-      close(FH);
-      return undef;
-
-    } else {
-      return "Can't open $fname: $!";
-
-    }
-  }
-}
-
 1;
Sei's drum, den Versuch war's wert.

Nochmal zum eigentlichen Thema, dem ich ja auf den Grund gehen will. Ich habe nun mal im PDF zum Transceiver gelesen und das State Register gefunden. Also etwas Ergänzung in meine Timeout Funktion liefert:

2014.05.11 21:33:11 1: CUL_0 ReadFn timeout 300s reached. Trying ReadTimeoutFn...
2014.05.11 21:33:11 1: CUL_ReadTimeoutFn: CUL_0 Read timeout no 1 seen on serial port, transeiver-state: get raw => C35 = 0D / 13
2014.05.11 21:33:11 1: /dev/ttyACM0 disconnected, waiting to reappear (CUL_0)
2014.05.11 21:33:11 1: /dev/ttyACM0 reappeared (CUL_0)

Also der Transceiver steht im Empfang, sieht also normal aus, denke ich. Das kommt auch wenn ich den Befehl auch so mal absetze.
Die USB-Verbindung geht offenbar auch noch, sonst wäre das Register nicht auslesbar gewesen.

Mit dem nächsten Timeout werde ich dann mit C99 mal mehr auslesen. Mal sehen, ob sich da noch was ergibt.
Wenn das bestellte dickere Netzteil da ist, bin ich mal gespannt, ob das des Rätsels Lösung bringt.

Gruß und Danke, Ansgar.

[noansi]

Hallo CUL Programmier Experten,


nun habe ich 3 Hänger am CUL, der nur auf Homematic läuft, mit geloggt und jeweils ein get raw C99 vor dem disconnect abgesetzt um die Transceiver Register auszulesen:

2014.05.12 05:36:18 1: CUL_ReadTimeoutFn: CUL_0 Read timeout no 1 seen on serial port, transeiver-state: get uptime => 7 15:45:26, get raw => C35 = 0D / 13, get raw => 072E2E0DE9CAFF0C450000060021656AC8930322F834073318166C434091876BF85610AF2A3F114100597F3E81350B00

2014.05.12 11:40:55 1: CUL_ReadTimeoutFn: transeiver-state: get uptime => 7 21:50:03, get raw => C35 = 0D / 13, get raw => 072E2E0DE9CAFF0C450000060021656AC8930322F834073318166C434091876BF85610AF2A3F114100597F3E81350B00

2014.05.12 20:16:39 1: CUL_ReadTimeoutFn: transeiver-state: get uptime => 8 06:25:49, get raw => C35 = 0D / 13, get raw => 072E2E0DE9CAFF0C450000060021656AC8930322F834073318166C434091876BF85610AF2A3F114100597F3E81350B00

Wenn ich einfach so im Normalbetrieb mal get raw C99 teste bekomme ich:

CUL_0 raw => 072E2E0DE9CAFF0C450000060021656AC8930322F834073318166C434091876BF85610AC2A15114100597F3E81350B00

Der Unterschied liegt in in den Registern 0x23 und 0x25, FSCAL3 und FSCAL1.

Normal ist 0x23 auf 0xAC und im hängenden Fall auf AF.
Normal ist 0x25 auf 0x15 und im hängenden Fall auf 3F.

Eingestellt ist der Transceiver auf FS_AUTOCAL 01 -> When going from IDLE to RX or TX (or FSTXON) laut Doku CC1101.

Sagt jemandem das spontan was?

Die Chip Doku sagt dazu noch:

As an alternative the user can read register FSCAL1. The PLL is in lock if the register content is different from 0x3F. Refer also to  the  CC1101 Errata Notes  [3]

Wenn ich nichts unternehme, also keinen Disconnect oder harten Reset, dann kommt nach längerer Zeit (bis zu 2 Stunden) wieder was an Daten rein, warum auch immer. Außerdem kann ich nichts senden, Komandos kommen nicht bei Empfängern an.

Ich werde nun versuchen, noch am Ende von in CUL_DoInit die Register auszulesen. Mal schauen, was dann drin steht.


Gruß und Danke, Ansgar.

[noansi]

Hallo CUL Programmier Experten,

nun das Ergebnis des Loggens vor und nach dem Disconnect:

Code: [Auswählen]

2014.05.13 11:32:28 1: CUL_0 ReadFn timeout 300s reached. Trying ReadTimeoutFn...
2014.05.13 11:32:28 1: CUL_ReadTimeoutFn: CUL_0 Read timeout no 1 seen on serial port
2014.05.13 11:32:28 1: CUL_ReadTimeoutFn: transeiver-state: get uptime => 8 21:41:40, get raw => C35 = 0D / 13, get raw => 072E2E0DE9CAFF0C450000060021656AC8930322F834073318166C434091876BF85610AF2A3F114100597F3E81350B00
2014.05.13 11:32:28 1: /dev/ttyACM0 disconnected, waiting to reappear (CUL_0)
2014.05.13 11:32:29 1: /dev/ttyACM0 reappeared (CUL_0)
2014.05.13 11:32:30 1: CUL_DoInit: transeiver-state: get uptime => 8 21:41:41, get raw => C35 = 0D / 13, get raw => 072E2E0DE9CAFF0C450000060021656AC8930322F834073318166C434091876BF85610AC2A15114100597F3E81350B00
Der Transceiver zeigt danach wieder die gleichen Registerwerte, wie im Normalzustand.

Wird beim erneuten Öffnen der Schnittstelle der Transceiver neu initialisiert und erholt sich dadurch wieder?
Bedeutet das, das der CUL eine Macke hat?

Kann der Transceiver durcheinander und außer Tritt kommen, wenn in der Umgebung auch noch SlowRF Geräte auf (fast) gleicher Frequenz senden?

Den RasPi kann ich nun wohl als Ursache ausschließen, denke ich.

Der Test mit der Stromversorgung steht noch aus. Darauf hoffe ich nun noch.

Kann ich noch was sinnvolles loggen, was mehr Klarheit bringen kann?

Gruß und Danke,

Ansgar.

[rudolfkoenig]

Wird beim erneuten Öffnen der Schnittstelle der Transceiver neu initialisiert und erholt sich dadurch wieder?

Ja, evtl.

Bedeutet das, das der CUL eine Macke hat?

Evtl.

Kann der Transceiver durcheinander und außer Tritt kommen, wenn in der Umgebung auch noch SlowRF Geräte auf (fast) gleicher Frequenz senden?

Eigentlich nicht, beobachtet hat das noch keiner.

Den RasPi kann ich nun wohl als Ursache ausschließen, denke ich.

Und worauf genau beruht diese Behauptung?

Kann ich noch was sinnvolles loggen, was mehr Klarheit bringen kann?

Ja, wie ich schon mal geschrieben habe, das Ding an einem "richtigen" Rechner (d.h. mir ordentlichen Stromversorgung) ausprobieren. Aber soweit ich es bisher gesehen habe, bist Du eher einer, der nicht Ratschlaege sucht, sondern die eigenen Theorien bestaetigen moechte. Ist auch nicht verkehrt, gute Forscher hoeren nicht auf die anderen, kann aber die Ratgebenden etwas nerven.

[noansi]

Hallo Rudolf,

erst mal vielen Dank für alle Deine Antworten und Deine Mühe, anderen und mir zu helfen. Und besten Dank für die viele Arbeit, Du in das FHEM Projekt sowohl mit Programmierung, als auch Support steckst und gesteckt hast. Nerven möchte ich keineswegs.
Deine Anregungen nehme ich durchaus ernst und teste sie durch, Netzteile sind auch gekommen. Der Test startet am Wochenende.
Es ist schlicht so, dass ich den Hardwaretest distanzbdingt nur mit Verzögerung durchführen kann, aber Remote wunderbar schon Softwaremöglichkeiten ausloten kann. Und mein Gefühl dabei schließt ein selten auftretendes Softwareproblem nicht aus, auch wegen der Systematik, siehe unten.
Eigentlich möchte ich nur zuverlässig die Sensoren empfangen können, um auf die Temperatursignale regeln zu können und nicht regelmäßig in die Hardwarebegrenzung rennen, weil z.B. die letzte empfangene Temperatur unter dem Sollwert hängen bleibt oder umgekehrt nicht geheizt wird weil sie drüber hängen bleibt.

Mit den Änderungen, die ich vorgenommen habe, kann ich jetzt auch schon einges sehen. So kann ich sagen, dass, ohne die Timeouts zu berücksichtigen, maximal alle 80s Daten vom CUL und somit von irgend einem der Sensoren kommen. Im Mittel kommen alle 12s Daten vom CUL rein.

Mittlerweile habe ich im Dauerbetrieb von 3 Tagen 11x meinen 5 Minuten Timeout geloggt und jeweils jedes mal den gleichen schon beschriebenen Registerzustand vorher und nacher gesehen.

Und worauf genau beruht diese Behauptung?

In allen Fällen des Timeouts konnte ich beim CUL die Register vor dem Disconnect anfordern und habe eine Antwort bekommen, ohne dass die Schnittstelle neu geöffnet worden wäre. Damit steht offenbar die USB Verbindung vom RasPi zum CUL noch in beide Richtungen und es kommen nur keine Empfangsdaten von den Sensoren rein. Der RasPi ist mir auch noch nie abgestürzt und seine Logs sind bezüglich USB sauber. Daher setze ich auch meine erste Hardwarehoffnung auf das Netzteil, das nach allen Recherchen dazu mit 1A etwas knapp bemessen ist. Die Spannung werd ich auch noch am CUL messen, um da Klarheit zu bekommen.

Ich habe auch noch das cc1101 Errata swrz020d.pdf gefunden und darin wird auch die Möglichkeit eines Empfangshängers beschrieben:

RXFIFO_OVERFLOW Issue Radio stays in RX state instead of entering RXFIFO_OVERFLOW state ...

Und noch einen weiteren Abschnitt zum FSCAL1 Register:

PLL Lock Detector Output PLL lock detector output is not 100% reliable

PLL lock can be checked reliably as follows:
1...
2. Read register FSCAL1. The PLL is in lock if the register content is different from
0x3F. With both of the above workarounds, the CC1101 PLL calibration should be
carried out with the correct settings for TEST0.VCO_SEL_CAL_EN and
FSCAL2.VCO_CORE_H_EN. These settings are depending on the operating
frequency, and is calculated automatically by SmartRF™ Studio. It must be noted
that the TEST0 register content is not retained in SLEEP state, and thus it is
necessary to write to this register as described above when returning from the
SLEEP state.

Ob der CUL mit seiner Programmierung für so einen beschrieben Empfangshänger anfällig sein kann, versuche ich am Quelltext zu ergründen, wenn die Hardwaretests nichts bringen.
Den 0x3F Zustand von FSCAL1 sehe ich bei jedem der Timeouts, jedoch nicht bei Abfrage der Register ohne Timeout.

Danke und Gruß, Ansgar.

[Jens_B]

Für mich sieht das nach einem Hardware Problem aus. -> defektes cul, falsches Netzteil am Pi, oder defekt. Je nachdem was noch am USB Port dran ist kann das schon zu Problemen führen.
Hängt der cul den direkt am Pi oder über einen USB hub?

Schon mal das cul auf anderer Hardware unter fhem probiert?

Ich persönlich hätte nicht lange gefackelt und ein anderes Netzteil und ein andres cul probiert....

Gruß
Jens


Gesendet von meinem iPhone mit Tapatalk

[noansi]

Hallo CUL Programmier Experten,


@Jens: Vielen Dank für Deine Antwort. Der CUL hängt, ebenso wie mein USB-WDE1, mit USB Verlängerungskabel direkt am RasPi. Den RasPi bediene ich nur über Netzwerk, also ohne Tastaur, Maus und Monitor.
Das Zwangs-Fackeln hat ein Ende.

Hier die bisherigen Ergebnisse des Hardware Tauschs.

1A Netzteil gegen 2A Netzteil getauscht: Timeouts, wie gehabt.

Zusätzlich RasPi gegen Reserve RasPi getauscht: Timeouts, wie gehabt.

Zusätzlich USB Verbindungskabel gegen 3m Kabel mit 2 Ferritkernen getauscht (von busware mit CUL bezogen): Timeouts, wie gehabt. Spannung am CUL stabil bei 4,95V

Nun habe ich einen weiteren CUL geordert und zusätzlich noch einen COC und werde berichten, wenn ich damit getestet habe.

En PC-Test muss aus Zeitgründen noch warten.


Gruß, Ansgar.

PS: Wenn mal ein CUL Nutzer mit einigen Homematic Temperatur-Sensoren (ich habe 14 im Einsatz, mit RSSI von -48 bis -89) meine paar Code Änderungen in fhem.pl und CUL.pm einbauen und auch mal testen könnte, würde das vielleicht ebenfalls weiter helfen. Statt 300s Timeout meinetwegen auch 600s, damit schlechte Empfangsverhältnisse das Ergebnis nicht verfälschen.

[Jens_B]

Also ich weiß ja nicht wieviel Strom der cul benötigt, aber beides an direkt an die raspi Ports zu hangen( die beide am soeben Bus hangen, das heißt zusammen nur max 500 mA Strom liefern... )
Kann auch schon problematisch sein. Ich würde stromhungrige Geräte welche keine eigene Stromversorgung am Pi nur über eine aktiven USB Hub betreiben.
Gruß
Jens


Gesendet von meinem iPhone mit Tapatalk

[noansi]

Hallo Jens,

nun, so weit ich heraus finden konnte, liegt der Strom für den CUL unter 100mA (so meldet er sich laut CUL Quelltext auch als USB Gerät an, wenn ich das nicht missverstanden habe). Ebenso, wie der Strom für den USB-WDE1 unter 100mA liegt. Also beide keine stromkritischen USB Geräte. Der RasPi B liegt bei 700mA. Somit sollte auch schon das 1A Netzteil dafür reichen. Mit dem 2A Netzteil bin ich auf der sicheren Seite (es wird auch nicht warm). Und da die Spannung am CUL gemessen ebenfalls gut aussieht, sehe ich hier elektrisch derzeit kein Problem.

Ich habe einen interessanten Logeintrag:

Code: [Auswählen]

2014.05.18 23:54:32 1: CUL_0 ReadFn timeout 300s reached. Trying ReadTimeoutFn...
2014.05.18 23:54:32 2: CUL_0: unknown message C35 = 0D / 13


2014.05.18 23:54:32 2: CUL_0: unknown message C35 = 0D / 13

C35 = 0D / 13

2014.05.18 23:54:32 2: CUL_0: unknown message C35 = 0D / 13

C35 = 0D / 13


2014.05.18 23:54:32 2: CUL_0: unknown message C35 = 0D / 13

C35 = 0D / 13

0D2E2D07D3913D04

2014.05.18 23:54:32 2: CUL_0: unknown message C35 = 0D / 13

C35 = 0D / 13

0D2E2D07D3913D04


2014.05.18 23:54:32 2: CUL_0: unknown message C35 = 0D / 13

C35 = 0D / 13

0D2E2D07D3913D04

320000060021656A

2014.05.18 23:54:32 2: CUL_0: unknown message C35 = 0D / 13

C35 = 0D / 13

0D2E2D07D3913D04

320000060021656A


2014.05.18 23:54:32 2: CUL_0: unknown message C35 = 0D / 13

C35 = 0D / 13

0D2E2D07D3913D04

320000060021656A

55E43023B9000700

2014.05.18 23:54:32 2: CUL_0: unknown message C35 = 0D / 13

C35 = 0D / 13

0D2E2D07D3913D04

320000060021656A

55E43023B9000700


2014.05.18 23:54:32 2: CUL_0: unknown message C35 = 0D / 13

C35 = 0D / 13

0D2E2D07D3913D04

320000060021656A

55E43023B9000700

18146C070090876B

2014.05.18 23:54:32 2: CUL_0: unknown message C35 = 0D / 13

C35 = 0D / 13

0D2E2D07D3913D04

320000060021656A

55E43023B9000700

18146C070090876B


2014.05.18 23:54:33 2: CUL_0: unknown message C35 = 0D / 13

C35 = 0D / 13

0D2E2D07D3913D04

320000060021656A

55E43023B9000700

18146C070090876B

F85611EF2A151F41

2014.05.18 23:54:33 2: CUL_0: unknown message C35 = 0D / 13

C35 = 0D / 13

0D2E2D07D3913D04

320000060021656A

55E43023B9000700

18146C070090876B

F85611EF2A151F41


2014.05.18 23:54:33 2: CUL_0: unknown message C35 = 0D / 13

C35 = 0D / 13

0D2E2D07D3913D04

320000060021656A

55E43023B9000700

18146C070090876B

F85611EF2A151F41

00597F8788310B00

2014.05.18 23:54:33 2: CUL_0: unknown message C35 = 0D / 13

C35 = 0D / 13

0D2E2D07D3913D04

320000060021656A

55E43023B9000700

18146C070090876B

F85611EF2A151F41

00597F8788310B00


2014.05.18 23:54:33 2: CUL_0: unknown message C35 = 0D / 13

C35 = 0D / 13

0D2E2D07D3913D04

320000060021656A

55E43023B9000700

18146C070090876B

F85611EF2A151F41

00597F8788310B00

C35 = 0D / 13

2014.05.18 23:54:33 2: CUL_0: unknown message C35 = 0D / 13

C35 = 0D / 13

0D2E2D07D3913D04

320000060021656A

55E43023B9000700

18146C070090876B

F85611EF2A151F41

00597F8788310B00

C35 = 0D / 13


2014.05.18 23:54:33 2: CUL_0: unknown message C35 = 0D / 13

C35 = 0D / 13

0D2E2D07D3913D04

320000060021656A

55E43023B9000700

18146C070090876B

F85611EF2A151F41

00597F8788310B00

C35 = 0D / 13

? (0D280597F8788310B35 = 0D / 13 is unknown) Use one of B C F i A Z E G M K U R T V W X e f m l t u x

2014.05.18 23:54:33 2: CUL_0: unknown message C35 = 0D / 13

C35 = 0D / 13

0D2E2D07D3913D04

320000060021656A

55E43023B9000700

18146C070090876B

F85611EF2A151F41

00597F8788310B00

C35 = 0D / 13

? (0D280597F8788310B35 = 0D / 13 is unknown) Use one of B C F i A Z E G M K U R T V W X e f m l t u x


2014.05.18 23:54:33 2: CUL_0: unknown message C35 = 0D / 13

C35 = 0D / 13

0D2E2D07D3913D04

320000060021656A

55E43023B9000700

18146C070090876B

F85611EF2A151F41

00597F8788310B00

C35 = 0D / 13

? (0D280597F8788310B35 = 0D / 13 is unknown) Use one of B C F i A Z E G M K U R T V W X e f m l t u x

0015ABD7

2014.05.18 23:54:33 2: CUL_0: unknown message C35 = 0D / 13

C35 = 0D / 13

0D2E2D07D3913D04

320000060021656A

55E43023B9000700

18146C070090876B

F85611EF2A151F41

00597F8788310B00

C35 = 0D / 13

? (0D280597F8788310B35 = 0D / 13 is unknown) Use one of B C F i A Z E G M K U R T V W X e f m l t u x

0015ABD7


2014.05.18 23:54:36 1: /dev/ttyACM0 disconnected, waiting to reappear (CUL_0)
2014.05.18 23:54:36 1: CUL_ReadTimeoutFn: CUL_0 Read timeout no 2 seen on serial port
2014.05.18 23:54:36 1: CUL_ReadTimeoutFn: transeiver-state: get uptime => No answer, get raw => C35 = 0D / 13, get raw => C35 = 0D / 13
2014.05.18 23:54:36 1: /dev/ttyACM0 reappeared (CUL_0)
2014.05.18 23:54:36 1: CUL_DoInit: transeiver-state: get uptime => 0 03:09:26, get raw => C35 = 0D / 13, get raw => 072E2E0DE9CAFF0C450000060021656AC8930322F834073318166C434091876BF85610AC2A15114100597F3E81350B00

Die Registerabfrage vor dem Disconnect ist da irgendwie merkwürdig durcheinander geraten.


Gruß, Ansgar.

[noansi]

Hallo Rudolf und alle anderen CUL Programmier Experten,


da der neue CUL noch nicht zu Testzwecken eingetroffen ist, habe ich mal einen Blick in den CUL Firmware Sourcecode und auch die CC1101 Doku geworfen.

Die Doku sagt:

The PLL is in lock if the register content is different from 0x3F. Refer also to the CC1101 Errata Notes [3]. The PLL must be re-calibrated until PLL lock is achieved if the PLL does not lock the first time.
If the calibration is not performed each time before entering active mode (RX or TX)  the user  should  program register IOCFGx.GDOx_CFG  to 0x0A to check that the PLL is in lock before receiving/transmitting data.

Eine solche Prüfung habe ich in rf_asksin.c nicht gefunden (nur ein Kalibrierung bei der Initialisierung) und die Prüfung mal eingebaut, mitsamt Debugausgabe "PLLNOLOCK" und einer Kalibrierung im Falle fehlenden PLL Locks (falls Register CC1100_FSCAL1 == 0x3f). Den Wert hatte ich ja zuvor in meinen Log Ausgaben jedes mal im Register CC1100_FSCAL1 gesehen.

Die neue Logausgabe taucht nun auch (selten, wie zuvor auch die Aussetzer,) auf:

2014.05.25 18:48:02 2: CUL_0: unknown message PLLNOLOCK
2014.05.25 20:39:45 2: CUL_0: unknown message PLLNOLOCK

und danach (hoffentlich wegen der ausgeführten Kalibrierung) sind auch brav weiter Daten gekommen. Muss ich noch was beobachten, denke aber auf dem richtigen Weg zu sein.

Zumindest hatte der CC1101 im bisherigen Code eine Chance zur Selbsterholung, da FS_AUTOCAL auf 1 steht und damit beim Wechsel von IDLE nach TX oder RX eine automatische Kalibrierung durchgeführt würde. Wie der Zustandswechsel so zustande kommt und damit zur Selbstheilung (nach bis zu 2 Stunden) geführt haben könnte, habe ich jedoch noch nicht gesehen?

Warum der CC1101 die Kalibrierung verliert kann ich nicht sagen und bin mal gespannt, ob der neue CUL das genauso macht.

Eine zuvor genutzte Methode, im Falle fehlenden PLL Locks beim State MARCSTATE_RX einfach mal rf_asksin_init aufzurufen hat jedenfalls schon mal den Empfang erhalten (mein Timeout in fhem.pl löst damit nicht aus), kostet aber mehr Zeit.

Was ich am rf_asksin.c Code noch nicht verstehe, ist die Stateumschaltung. Zum einen ohne Timeout zur Prüfung auf den Ziel-State-Zustand (TX/RX) und zum Teil ohne Prüfung, ob der State auch eingenommen wurde oder einfach mit Wartezeiten?
Dient das der Ersparnis von Programmspeicherplatz mit (empirisch ?) ermittelten Warte- und Schaltzeiten?


Gruß, Ansgar.

[rudolfkoenig]

Ich meine auch, dass due auf dem richtigen Weg bist, leider kann ich deine Frage nicht beantworten, vielleicht einer der Co-Autoren von rf_asksin.c

[noansi]

Hallo CUL rf_asksin Programmier Experten,


das bisherige Testergebnis der Kalibrierung bei fehlendem PLL Lock sieht gut as.

Zwei mal wurde der fehlende PLL Lock bisher noch aufgezeichnet und der Empfangstimeout ist nicht mehr aufgreten und auch die Sensorkurven sehen sauber aus:

2014.05.26 14:45:06 2: CUL_0: unknown message PLLNOLOCK
2014.05.26 23:08:03 2: CUL_0: unknown message PLLNOLOCK

Ob die Sendeprobleme damit auch gelöst sind, werde ich am Wochendende testen, ebenso die Vergleichs-Hardware, die heute eingetroffen ist.

@Rudolf: Danke für Deine Antwort und den Vesuch. Wäre eine Codeänderung in dieser Richtung in der CUL Firmware ein Update wert? Blöderweise kann ich es nur bei CUL V3.4 und künftig bei COC V1.2 testen und weiß auch nicht, wie eng es bei den anderen im Speicher aussieht?

Wäre nett, wenn noch jemand zu meinen Code Fragen was schreiben könnte. Ich würde gern unnötige Bytes sparen, wo der bisherige Code auf Erkennissen aus der CC1101 Doku beruht.


Gruß, Ansgar.

[rudolfkoenig]

Wäre eine Codeänderung in dieser Richtung in der CUL Firmware ein Update wert?

Sicher, ich haette nur gerne noch feedback von einem weiteren Benutzer mit viel HM Hardware.
Evtl. in der HM Gruppe nachfragen.

und weiß auch nicht, wie eng es bei den anderen im Speicher aussieht?

Ein CUL_V2 hat 16k Flash, die anderen CULs 32k. Davon kommen 4k Bootloader + 4k USB Bibliothek (LUFA) weg.
V2 mit SlowRF ist extrem eng am Speicher (12 Bytes frei, siehe make size), fuer HM und MAX muessen andere Binaries verwendet werden. Diese Versionen haben dann jeweils etwa 1K Platz fuer Code frei. Die anderen Modelle haben Platz genug (CUL_V3: 10k frei, COC: 100k frei): du brauchst vermutlich keine Sorgen wg. Speicher zu machen.