CUL hängt sich auf

[Ganneff]

Hallo,

ich habe seit kurzem einen RaspBerry Pi und dazu das CCD (http://shop.busware.de/product_info.php/cPath/1/products_id/94) von busware. Tut soweit gut, und ich bin dabei meine Automation von der Homematic CCU auf fhem zu legen. Dazu hab ich alle Komponenten am CUL angelernt, klappte problemfrei.

Ich kann via telnet mit fhem Kontakt aufnehmen und mit "inform on" sehe ich jede Menge Aktion, was auch immer meine Homematic Komponenten halt so anstellen. In Benutzung sind dabei HM-CC-TC,HM-CC-VD,HM-LC-Dim1TPBU-FM,HM-LC-SW1-PL2,HM-LC-Sw1PBU-FM, HM-PB-2-WM55,HM-PBI-4-FM,HM-SEC-RHS, also Heizungs- und ein wenig Lichtsteuerung.

Mein Problem nun stellt sich in unregelmässigen Hängern vom CUL dar, und ich habe hier im Forum nichts passendes gefunden. Und zwar tut alles für einen Zeitraum X wunderbar: fhem empfängt was so vor sich geht, fhem sendet Kommandos, etc. Bis eben X abgelaufen ist - dann versucht fhem noch Aktionen durchzuführen - aber der CUL verweigert jedwede Arbeit. X ist dabei variabel, ich hatte es schon nach 15Minuten, aber auch mal nach 2 Tagen.

Mit "list CCD" sehe ich das Device noch - und das Feld "QUEUE:" in dem Listing enthält viele Einträge. (Naja, halt ansteigend für jeden Befehl den fhem eigentlich senden will).
Gleichzeitig blinkt die LED am Device mit einer Frequenz von, schätzungsweise, 2 Hertz. (Während sie normal so eingestellt ist das sie nur bei Übertragung blinkt).

Einen Ausweg gibt es nur via folgender Sequenz:
------------
echo 17 > /sys/class/gpio/export; fi
echo out > /sys/class/gpio/gpio17/direction
echo 1 > /sys/class/gpio/gpio17/value
sleep 1
/opt/fhem/fhem.pl localhost:7072 "rereadcfg"
------------

Theoretisch könnte ich das ganze via cron einfach stündlich starten - aber das kann ja nun auch nicht der Weisheit letzter Schluss sein.

Hat irgendeiner Tips was ich tun kann um das zu beheben / einzugrenzen wo der Fehler herkommt?

Noch ein paar Daten, vielleicht hilfts beim Helfen. :)
------------------------------------------------------------------------
list CCD
Internals:
   CCD_MSGCNT 113
   CCD_TIME   2013-10-04 22:31:09
   CFGFN      /opt/fhem/etc/ccd.cfg
   CMDS       mCFiAZGMRTVWXefltux
   Clients    :CUL_HM:HMS:CUL_IR:
   DEF        /dev/ttyAMA0@38400 1234
   DeviceName /dev/ttyAMA0@38400
   FD         11
   FHTID      1234
   HM_CMDNR   27
   NAME       CCD
   NR         61
   PARTIAL    
   RAWMSG     A0C8E86701D905400000080D34321
   RSSI       -57.5
   STATE      Initialized
   TYPE       CUL
   VERSION    V 1.57 CSM868
   initString X21
Ar
   Matchlist:
     1:CUL_HM   ^A....................
     8:HMS      ^810e04....(1|5|9).a001
     D:CUL_IR   ^I............
   Readings:
     2013-10-03 18:42:28   ccconf          freq:868.300MHz bWidth:101KHz rAmpl:33dB sens:8dB
     2013-10-04 22:09:11   cmds             m C F i A Z G M R T V W X e f l t u x
     2013-10-04 21:44:36   raw             No answer
   Helper:
     HMnextTR   1380918669.94916
     Nextsend:
       [11 rows]
Attributes:
   hmId       XXXXXX
   rfmode     HomeMatic
------------------------------------------------------------------------
fhem ist 5.5 aus dem Debian Paket von fhem.de, Kernel und Module sind 3.6.11+, direkt aus dem Image von busware.de.

Danke,
 Jörg

[tostmann]

Das sieht aus (2Hz blinken) als ob der Bootloader aktiviert wurde. Ist Dein GPIO22 in Benutzung? Füge mal vor dem gpio17-reset hinzu:

if test ! -d /sys/class/gpio/gpio22; then echo 22 > /sys/class/gpio/export; fi
echo out > /sys/class/gpio/gpio22/direction
echo 1 > /sys/class/gpio/gpio22/value

Das definiert den Pegel eindeutig und springt NICHT den Bootloader an.

[Ganneff]

Das sieht aus (2Hz blinken) als ob der Bootloader aktiviert wurde. Ist Dein GPIO22 in Benutzung?

Ich hab ausser dem CCD nichts weiter am RaspBerry angestöpselt.
Wobei ich mich frage warum der mal so eben von "Ich funke hier fröhlich HomeMatic BidCos
durch die Gegend" auf "Yay, ich mag meinen Bootloader" geht.

Füge mal vor dem gpio17-reset hinzu:

if test ! -d /sys/class/gpio/gpio22; then echo 22 > /sys/class/gpio/export; fi
echo out > /sys/class/gpio/gpio22/direction
echo 1 > /sys/class/gpio/gpio22/value

Das definiert den Pegel eindeutig und springt NICHT den Bootloader an.

Done, nun müssen wir warten obs wieder auftritt.

Danke,
 Jörg
 

[Ganneff]

Füge mal vor dem gpio17-reset hinzu:

if test ! -d /sys/class/gpio/gpio22; then echo 22 > /sys/class/gpio/export; fi
echo out > /sys/class/gpio/gpio22/direction
echo 1 > /sys/class/gpio/gpio22/value

Das definiert den Pegel eindeutig und springt NICHT den Bootloader an.

Done, nun müssen wir warten obs wieder auftritt.

Blech, der meinte heute wieder in das 2Hz Blinken zu gehen und die Queue anwachsen zu lassen. Ein Reset wie in meinem ersten Post (plus den gpio22), und es geht wieder.

Nur um sicherzugehen: Da ist sonst nichts auf dem Raspbi aktiv ausser fhem (also was mit dem device reden will).

Ich meine es würde auftreten so ca. um die Zeit rum wo mehr Traffic herrscht, z.b. dann wenn HeatingControl triggert und gleichzeitig mehrere Thermostate einstellt, obwohl ich mir nicht vorstellen kann das "gerademal" 6 Befehle auf einmal so schwer sind.

Ich teste gleich mal ob ich diesen Fehlerfall provozieren kann, indem ich mit etwas getConfig und so meine Lichtschalter traktiere. (Die sind immerhin dauernd am Funken dank Stromversorgung via Kabel, da muss man nit solange warten).

Grüße
 Jörg

[Ganneff]

Ich meine es würde auftreten so ca. um die Zeit rum wo mehr Traffic herrscht, z.b. dann wenn HeatingControl triggert und gleichzeitig mehrere Thermostate einstellt, obwohl ich mir nicht vorstellen kann das "gerademal" 6 Befehle auf einmal so schwer sind.

Ich teste gleich mal ob ich diesen Fehlerfall provozieren kann, indem ich mit etwas getConfig und so meine Lichtschalter traktiere. (Die sind immerhin dauernd am Funken dank Stromversorgung via Kabel, da muss man nit solange warten).

Ok, es ist definitiv auf "viel Traffic" zurückzuführen. Wobei ich es nicht wirklich für viel halte, aber aus irgendeinem Grund ist dieses Stück Hardware damit überfordert...

Was ich hier habe ist einfach ein Taster am Ausgang. Wenn der letzte geht sorgt der dafür das alle Heizungen runterregeln und alle Lichter aus sind.  Dafür werden 18 Kommandos beim Verlassen und 12 Kommandos beim Wiederkommen abgesetzt. (x-mal set desired temp und x-mal set $foo_licht off, sowie x-mal wieder set desired temp und einmal "dimmer X% für Y zeit").

EIn Druck auf diesen Taster - unds CUL ist nicht mehr benutzbar. Wobei er seit der GPIO22 Änderung in der Regel nicht mehr das 2Hz Blinken bringt. Er bleibt einfach gänzlich aus. fhem meldet dann

Code Auswählen Erweitern

CUL_HM WZ_Dimmer MISSING ACK
CUL_HM Schranklicht MISSING ACK
CUL_HM C_Thermostat MISSING ACK
[...]

und ein "list $DEVICE" auf eines von denen gibt eine (wechselnde) Zahl an "protCmdPend", sowie einen passend grossen "cmdStack".

Hier mal beispielhaft ein Auszug der Internals (Ich kann bei Bedarf volle Logs posten, wollt den Post nur nicht (evtl.) unnütz noch länger machen):

Code Auswählen Erweitern

channel_01 WZ_Dimmer_Sw
protCmdPend 4 CMDs pending
protLastRcv 2013-10-06 22:33:11
protResnd  6 last_at:2013-10-06 22:34:59
protResndFail 1 last_at:2013-10-06 22:34:47
protSnd    18 last_at:2013-10-06 22:34:47


Ähnliches Verhalten trifft auch zu wenn Heating_Control triggert und es einen Schaltzeitpunkt gibt wo mehrere Heizungen gleichzeitig (in dem Fall alle) eine neue desired-temp kriegen, es ist also nicht nur rein die Routine mit dem Taster.

Oh, und es sieht so aus als würde Senden noch gehen wenn er nicht das 2Hz Blinken macht, nur Empfangen nicht: Ich kann Lichter schalten via FHEMWEB, aber ich krieg für alles ein "MISSING ACK" und keinerlei Statusupdates gehen mehr ein, von egal welchem andern Device.

(Ich (versuche) hier nachzubauen was ich mit der CCU1 von EQ habe. Da tut diese Aktion wunderbar. Kann doch nicht sein das son olles lahmes Ding wie die CCU1 nen Raspbi überholt. Marf. :) )

Was kann ich tun? Überall nen "sleep $random" einbauen und/oder alle Schaltzeitpunkte akribisch auseinander halten kann doch nicht der Technik letzter Schluss sein?

[Edit]
Im Fehlerfall hab ich dann übrigens:

Code Auswählen Erweitern

get CCD raw C35
CCD raw => C35 = 01 /  1


während funktionierend es

Code Auswählen Erweitern

get CCD raw C35
CCD raw => C35 = 0D / 13


ergibt. (Kommandos vom fhemwiki, der CUL Seite).
Dooferweise geht der Reboot/Reset des CULs der da angegeben ist nicht.

[rudolfkoenig]

Wenn ich es richtig verstehe, handelt es sich nicht wie im Titel faelschlicherweise formuliert war um ein CUL sondern um ein Busware CCD, deswegen habe ich den Titel angepasst. Achtung: da dieses Geraet noch neu ist, gibt es deswegen auch kaum Erfahrungen damit, auch wenn das Hardware-Stueck, was hier eine Rolle spielt, grob einem CUL entspricht, und auch vom gleichen culfw-firmware bedient wird.

Ich habe die Diskussion ins Homematic Unterforum verschoben, da das Geraet in einem HM Umfeld verwendet wird, und ich hoffe, dass man hier bessere Hinweise darauf bekommt, wo genau das Problem liegt.

Existiert das Problem auch mit einem "richtigen" CUL oder mit einem HMLAN (beides an FHEM/RPi angeschlossen)?
Hat im Fehlerfall das CCD neu gebootet: wie ist uptime des CCD?
Bist Du sicher wg. dem 2 Sek. blinken? Bitte messen! Ein 1 Sek blinken ist nach einem Firmware-Reset/update normal.

[betateilchen]

sondern um ein Busware CCD, deswegen habe ich den Titel angepasst

bei mir steht immer noch CUL im Titel...

(siehe Anhang / see attachement)

[Ganneff]

Wenn ich es richtig verstehe, handelt es sich nicht wie im Titel faelschlicherweise formuliert war um ein CUL sondern um ein Busware CCD, deswegen habe ich den Titel angepasst. Achtung: da dieses Geraet noch neu ist, gibt es deswegen auch kaum Erfahrungen damit, auch wenn das Hardware-Stueck, was hier eine Rolle spielt, grob einem CUL entspricht, und auch vom gleichen culfw-firmware bedient wird.

Ich habe die Diskussion ins Homematic Unterforum verschoben, da das Geraet in einem HM Umfeld verwendet wird, und ich hoffe, dass man hier bessere Hinweise darauf bekommt, wo genau das Problem liegt.

Existiert das Problem auch mit einem "richtigen" CUL oder mit einem HMLAN (beides an FHEM/RPi angeschlossen)?
Hat im Fehlerfall das CCD neu gebootet: wie ist uptime des CCD?
Bist Du sicher wg. dem 2 Sek. blinken? Bitte messen! Ein 1 Sek blinken ist nach einem Firmware-Reset/update normal.

Es meldet sich halt als CUL, desdewegen der Threadname und das CUL Forum.

"Richtiger" CUL - naja, hab halt keine anderen, und auch kein HMLAN (die CCU1 funkt direkt). Kollege hat eine COC Extension für den Raspbi, das wäre die (derzeit) einzige andere Möglichkeit zum Testen. Mach ich morgen abend mal, rein um zu sehen obs geht oder ich das auch zum blockieren kriege.

Uptime des CCD find ich beim nächsten Mal (also heute abend) mit raus, und ich bin mir zu 98% sicher mit der Frequenz, es war definitiv mehr als einmal die Sekunde. Oh, und wie in meinem letzten Post geschrieben, seitdem ich das GPIO22 Handling von tostmann eingebaut habe, ist das Aussehen des Fehlers ein anderer.

Grüße
 Jörg

[tostmann]

Ein CUL hat deutlich weniger RAM als ein CCD (2.5 vs 16KB)- aber ein CCD/COC schickt Daten nur mit 38400baud an den PI. Daher könnte es sein, dass die tty-Puffer überlaufen. Da RAM reichlich ist sollte man diese mal erhöhen und sehen.

z.B.:

#define TTY_BUFSIZE             2048

[Ganneff]

Ein CUL hat deutlich weniger RAM als ein CCD (2.5 vs 16KB)- aber ein CCD/COC schickt Daten nur mit 38400baud an den PI. Daher könnte es sein, dass die tty-Puffer überlaufen. Da RAM reichlich ist sollte man diese mal erhöhen und sehen.

z.B.:

#define TTY_BUFSIZE             2048

Das hört sich so an das ich entweder den Kernel oder die CCD Firmware neu bauen (und ggf flashen) muss? (Derzeit hab ich "Busware standard"). Hrm, heut abend mal schauen wo ich das nötige dafür finde.

[Edit] Ha, gerade gefunden - http://sourceforge.net/p/culfw/code/HEAD/tree/trunk/culfw/Devices/CCD/ - und heissa, " tostmann    [r396] increased TTY_BUFFER ". Feinfein. Heut abend probier ich mal.

[Ganneff]

Ein CUL hat deutlich weniger RAM als ein CCD (2.5 vs 16KB)- aber ein CCD/COC schickt Daten nur mit 38400baud an den PI. Daher könnte es sein, dass die tty-Puffer überlaufen. Da RAM reichlich ist sollte man diese mal erhöhen und sehen.

z.B.:

#define TTY_BUFSIZE             2048

So, und soeben ausprobiert. Mit 2048 war es noch wacklig, sprich ich hatte mal einen Hänger, mal nicht. Ich hab es dann einfach mal mit 3072 probiert. Und dann tat es, die beiden Funktionen ausgelöst und jede Menge Funkverkehr beobachten können. Und kann noch immer, sprich es tut weiterhin.

[Edit] Argh, Freude zurück: Es geht ein paarmal gut, bevor es zurückfällt ins alte Muster.


Oh, und wo ich schon dabei bin:

Code Auswählen Erweitern

CCD# svn diff
Index: README
===================================================================
--- README (revision 396)
+++ README (working copy)
@@ -9,13 +9,19 @@
  make program
 
 on the RPi itself. This will require some tools installed upfront.
-Use:
+To recompile the whole firmware, you will need to install an environment
+to compile it, use
 
- apt-get install make avrdude
+ apt-get install make gcc-avr avr-libc
 
+and to be able to flash you will need to run
 
-to flash the recompiled hex-file.
+ apt-get install avrdude
 
+(or for convenience copy&paste all in one:
+
+ apt-get install make gcc-avr avr-libc avrdrude
+
 BEFORE
 
 To use the serial port @ RPi you need to free it form other tasks as:


[tostmann]

Alternativ kann man auch die Baudrate erhöhen. Die steht nur wegens des geringeren Bitfehlers auf 38400 ....

[Ganneff]

Alternativ kann man auch die Baudrate erhöhen. Die steht nur wegens des geringeren Bitfehlers auf 38400 ....

Mit 115200 - tut gar nix. Da kann fhem nichtmal mit dem CCD reden.
Mit 57600 redet fhem mit dem CCD, aber Problem wieder.

Code Auswählen Erweitern


get CCD raw C35
CCD raw => C35 = 01 /  1


Blech, so macht des keinen Spass, doofe Technik, die soll mich mögen, nicht Murphy.

[Ganneff]

Hi

so 3 Tage später: Des CCD hat 3072 für TTY_BUFSIZE, 57600 UART_BAUD_RATE - und fhem wurde Dienstag abend aktualisiert.

Seitdem tut es. Setz ich die TTY_BUFSIZE oder Baudrate kleiner renn ich in Probleme. Nehm ich die "alte" fhem version (das 5.5er Debian Paket vom Release Tag der 5.5), ebenfalls Probleme.

Nuja, also fürs CCD: Neueste Version und passend angepasste Firmware und Freude, auch bei ordentlich Traffic in kürzester Zeit.

Grüße
 Jörg

[Andreas74]

Ich hab exakt das gleiche Problem.

Läuft es bei Dir jetzt oder gibt es immer noch Aussetzer?

VG

Andreas