Hallo,
ich habe seit kurzem einen RaspBerry Pi und dazu das CCD (http://shop.busware.de/product_info.php/cPath/1/products_id/94 (//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
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.
Zitat von: tostmann schrieb am Fr, 04 Oktober 2013 22:51Das 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.
Zitat von: ...und ausserdem noch...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
Zitat von: Ganneff schrieb am Fr, 04 Oktober 2013 23:15Zitat von: tostmann schrieb am Fr, 04 Oktober 2013 22:51Fü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
Zitat von: Ganneff schrieb am Sa, 05 Oktober 2013 21:26Ich 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
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):
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:
get CCD raw C35
CCD raw => C35 = 01 / 1
während funktionierend es
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.
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.
Zitat von: rudolfkoenig schrieb am Mo, 07 Oktober 2013 08:23sondern um ein Busware CCD, deswegen habe ich den Titel angepasst
bei mir steht immer noch CUL im Titel...
(siehe Anhang / see attachement)
Zitat von: rudolfkoenig schrieb am Mo, 07 Oktober 2013 08:23Wenn 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
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
Zitat von: tostmann schrieb am Mo, 07 Oktober 2013 12:42Ein 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.
Zitat von: tostmann schrieb am Mo, 07 Oktober 2013 12:42Ein 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:
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:
Alternativ kann man auch die Baudrate erhöhen. Die steht nur wegens des geringeren Bitfehlers auf 38400 ....
Zitat von: tostmann schrieb am Mo, 07 Oktober 2013 22:37Alternativ 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.
get CCD raw C35
CCD raw => C35 = 01 / 1
Blech, so macht des keinen Spass, doofe Technik, die soll mich mögen, nicht Murphy.
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
Ich hab exakt das gleiche Problem.
Läuft es bei Dir jetzt oder gibt es immer noch Aussetzer?
VG
Andreas
Moin,
Was mich Wunder ist:
ich hab einen Original CUL-USB von Busware und zwei selbstgebaute
[1x minipro (3,3V) und 1x Nano (5V)] Culs.
Alle haben die 1.67 Firmware. Und alle hängen sich nach dem gleichen Muster auf.
(Andere Firmware - gleiches Problem)
Irgendwann gehen die vom Status "Initialized" auf "Opend", blinken lustig mit 2 Hz und tun nix mehr.
Ich bekomme die dann nur wieder ans Laufen, indem ich die vom USB trenne und wieder verbinde.
Nach einem Reopen funktionieren sie wieder.
Das Problem mit dem regelmäßigen Aufhängen hab ich bei mir mit einem Sendpool "gedämpft".
sendpool cul.868.hm.busware,cul.868.hm.minipro,cul.868.hm.nanoCUL
Durch den Sendpool läuft das bei mir nun ca. 2 Wochen, bis dann irgendwann alle hängen und ich den USB Hub kurz abziehen muss um dann die Culs über Reopendann zu reanimieren.
Ich habe insgesamt 6 Culs am Server, betroffen sind aber nur die, die im HM-Betrieb sind.
Der Max und die SlowRF machen keine Probleme.
An den Culs selber liegt es wohl auch nicht, da ich die untereinander schon mehrfach getauscht hab.
Den Original Busware CUL kann ich mit der Original Fw nur mit 19200 baud ansprechen, sonst tut der nicht.
Die anderen laufen zur Zeit auf 38400 baud.
Im Log ist nur zu sehen, dass der CUL irgendwann nicht mehr auf Anfragen reagiert.
Hat jemand dazu noch eine Idee?
Gruß Hajo
Hallo,
das kann ich bestätigen. Ich habe drei nanoCULs mit a-culfw 1.26-01 laufen: am RPi (3 B) einen 433er und einen 868er (Homematic); sowie einen 868er via Netzwerk (ser2net; Homematic) an einem AP (welcher mit LEDE/OpenWRT läuft).
Der 433er verliert seit ein paar Tagen ca. alle 2 Stunden die Verbindung zum RPi, kann diesen aber mit einem get version reanimieren. Gestern half nur noch ein Neustart vom RPi und FHEM. Mit dem 868er am RPi habe ich keine Probleme, aber mit dem 868er via Netzwerk (hier blinkt die LED hochfrequent - abziehen, kurz warten und neu anstecken hilft dann).
Seit gestern Abend scheint der 433er ganz abgeschmiert zu sein.
Wenn ich in den log vom RPi (Raspbian lite) schaue, scheint es Probleme mit der Spannungsversorgung zu geben - zumindest gibt der FTDI Treiber Kommunikationsfehler aus.
Ich muss die Tage mal schauen ob ich einen anderen nanoCUL 433er flashe und dann die gleichen Probleme habe....
Allerdings wäre ich auch für Hilfe/Hinweise dankbar. :)
Grüße
y
Hi,
dann würde ich aber eher dem nachgehen ->
Zitatscheint es Probleme mit der Spannungsversorgung zu geben
Netzteilprobleme (auch wenn es längere Zeit "problemlos" lief) sind eine der häufigsten Fehlerursachen beim pi.
Rote LED beobachten...
Gruß Otto
Hi,
danke für den Hinweis, bisher ist mir nichts aufgefallen.
Kurioserweise läuft der andere nanoCUL stabil.
Im RPi log finde ich dann folgende Fehlermeldung:
ftdi_sio ttyUSB1: usb_serial_generic_read_bulk_callback - urb stopped: -32
Wie gesagt, beobachten...
VG
y
So Zeugs mit urb stopped und CUL Aussteigerei hatte ich auch, bis der Raspi hinter samt Netzteil hinter eine USV ging und die USB-Devices an einen Powered USB-HUB. Seitdem ist Ruhe.
(ausserdem hatte ich zunächst billig nanoCULs mit gefälschtem FTDI von Ebay; hier durch ein Originale ersetzt.)
Ich habe das 2,5Ah Netzteil durch ein anderes 2,5Ah Netzteil ersetzt und der CUL läuft seit drei tagen durch. Kurios.
Wirklich Spannungsversorgung. oO