CUL will nicht senden / fhem 5.0
marte
ich habe da ein ziemliches Problem, bei dem ich alleine nicht mehr
weiterkomme:
fhem 5.0 (4.6 sowie 4.9 bringen die gleichen Resultate) läuft auf
einer FritzBox 7170 mit perl 5.6.2 (download von der fhem-Webseite).
Ich verwende eine CUL V3.2 mit culfw V1.40, eingebunden über
usbserial.
Referenziert wird diese in der fhem-Config über "define CUL1 CUL /dev/
ttyUSB0@9600 1234".
Die Anzeige aller FS20- und FHT-Werte funktioniert - nur, ich kann
nichts senden. Im Log erscheint
2011.02.19 15:02:56 5: Cmd: >set FB1_but2 on<
2011.02.19 15:02:56 5: CUL1 sending F12340111
2011.02.19 15:02:56 5: Triggering FB1_but2 (1 changes)
2011.02.19 15:02:56 5: FB1_but2 trigger: Checking Logfile for notify
- sieht also an sich gut aus. Nur passiert nichts. Das gleiche
Kommando bei direkt an den PC angeschlossener CUL sowie mittels USB-
Weiterleitung von der FritzBox gesendet funktioniert. Interessant ist,
dass die LED an der CUL bei den Sendekommandos von fhtw auch nicht
blinkt (bei den beiden anderen Varianten sowie beim Empfangen dagegen
schon) - also wird wohl gar nichts gesendet.
Weitere interessante Begebenheit: Ich habe versucht, mittels eines
Perl-Skripts direkt auf der FritzBox zu senden (im Wesentlichen
Device::SerialPort, $PortObj->write('F12340111\n');) - passiert auch
nichts. ABER, wenn ich nach meinem Skript fhem starte, blinkt die LED
und die aus meinem Skript ausstehenden Kommandos werden gesendet.
Irgendwie ein falsches Newline-Kommando?!
Kann die pseudo-serielle Schnittstelle in irgendeinem bescheuerten
Modus sein? "stty < /dev/ttyUSB0" liefert
speed 9600 baud;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z;
rprnt
= ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
-brkint -imaxbel
-echo
Bin über jeden noch so kleinen Hinweis ECHT dankbar!
Gruß,
Martin
Rudolf Koenig
erst einmal solltest Du feststellen, ob das CUL gespraechsbereit ist:
Das Kommando "get CUL raw V" sollte "CUL raw => V 1.40 CUL868" zurueckliefern,
und "get CUL raw X" wiederum "CUL raw => 21 900". Hier ist die zweite Zahl
fuer dich wichtig, sollte >= 100 sein, 900 ist das maximum.
Wenn das der Fall ist, schau an, wie hoch die Empfangsstaerken sind:
Die von "list .* CUL_RSSI" gelieferte Zahlen sind alle negativ, und schwanken
so zwischen -50 (starker Empfang) und -90 (schwacher Empfang).
Falls Du nur schwach empfaengst, dann ist evtl. irgendetwas mit der Antenne:
versuch das zu schaltende Geraet naeher (0.5-1m) an das CUL zu bringen, und
dann zu schalten?
Die Sendestaerke kannst du mit "set CUL raw x09" etwa verdoppeln, siehe auch
das culfw/README.
Am besten kann man solche Probleme mit einem weiteren Empfaenger
verifizieren...
Gruss,
Rudi
marte-goo...@xmn-berlin.de
die Werte sehen gut aus:
get CUL1 raw V
CUL1 raw => V 1.40 CUL868
get CUL1 raw X
CUL1 raw => 21 614
- und EMPFANGEN kann ich ja auch. Nur halt Senden nicht - au�er, wenn
ich den USB-Anschluss an meinen PC weiterleite (also kann es ja auch
kein Problem mit der Sendest�rke sein, denn dann gehts IMMER).
Ich habe eben noch einmal fhem gestartet (Empfangen ja, Senden nein),
dann meinen Perl-Sendetest (nichts), dann wieder fhem. Und - wieder
wurde das, was ich vorher manuell auf die Schnittstelle geschrieben
hatte, gesendet. Nur wieder nichts von fhem. Es ist zum Verzweifeln! ...
Gru�
Martin
Zrrronggg!
Sendeeinheiten.
Zrrronggg!
Rudolf Koenig
> dann meinen Perl-Sendetest (nichts), dann wieder fhem. Und - wieder
> wurde das, was ich vorher manuell auf die Schnittstelle geschrieben
> hatte, gesendet. Nur wieder nichts von fhem. Es ist zum Verzweifeln! ...
Kannst Du das bitte auch mit einem aktuellen (CVS) fhem und eine CUL
Definition mit Baudrate versuchen?
define MyCUL CUL /dev/ttyUSB0@38400 0000
marte-goo...@xmn-berlin.de
Problem gel�st. Wenn ich auch nicht weiss, warum.
Ich hatte
define MyCUL CUL /dev/ttyUSB0@9600 1234
in meiner Config. Empfangen ja, senden nein.
Spa�eshalber habe ich Dein
define MyCUL CUL /dev/ttyUSB0@38400 1234
�bernommen. Empfangen ja, senden ja.
H�h?
F�r alle Besitzer einer FritzBox mit den gleichen Problemen vielleicht
DIE L�sung?!
Gru� & danke f�r die Hilfe!
Martin
P.S.: "set CUL1 raw ..." ging bei 9600 "nat�rlich" nicht (keine
Fehlermeldung, aber auch nichts gesendet) bei 38400 gehts.
wollet42
ich hab leider jetzt das gleiche Problem.
CUL ging wunderbar an der Fritz 7170 mit fhem 5.0
Dann hab ich die Box ausgesteckt und später wieder eingesteckt
Seitdem kann CUL empfangen aber nicht mehr senden.
Auch der Versuch mit @38400 bringt leider nix.
get CUL raw X
CUL raw => V 1.40 CUL868
Was kann ich denn noch versuchen?
Gruss,
Wolle
wollet42
Wenn ich die Box neu starte geht senden über CUL nicht.
Wenn ich nach dem reboot in fhem ein "Modify CUL" mache geht senden.
Ich hab mal die Einstellungen der Seriellen vor und nach dem Modify
ausgelesen:
/var/mod/root # stty < /dev/ttyUSB0
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z;
rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
-brkint -imaxbel
speed 38400 baud;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z;
rprnt = ^R;
ignbrk -brkint -icrnl -imaxbel
-opost
-isig -icanon -iexten -echo -echoe -echok -echoctl
Irgendwie wird die Baudrate nicht gesetzt obwohl ich im define @38400
eingetragen habe
/Wolle
Rudolf Koenig
> eingetragen habe
Ist ein (jedenfalls mir :) bekannter Bug unter neueren Linux Versionen:
Nach einem fork() setzt Linux die Parameter einer geoeffneten seriellen
Schnittstelle zurueck. Hab deswegen in fhem.pl die komplette Initialisierungs-
Reihenfolge umgeschrieben (erst fork, dann parsen), ist in CVS eingecheckt.
Wir haben aber deutlich laenger gebraucht, bis wir das Problem gefuden haben :)
wollet42
der Tip hatte geholfen und alles ging prima. Nun jedoch nach einiger
Zeit bin ich wieder beim Ausgangszustand.
Zuerst dachte ich ich hab nur dieses Problem:
http://groups.google.com/group/fhem-users/browse_thread/thread/89f800516a1438f2
Jetzt habe ich jedoch wieder das Problem nach einem Reboot
intialisiert die serielle nicht richtig.
Ratlos?
Gruss,
Wolle
ToM
ich habe ein ähnliches Prob:
( Ubuntu 10.04 - fhem 5.0 - mit culfw V1.40)
Der CUL empfängt tadellos, jedoch werden nicht immer alle Befehle
gesendet. Die grüne CUL LED blinkt nicht!
Ich habe folgende Varianten getestet
/dev/ttyACM0
/dev/ttyACM0@9600
/dev/ttyACM0@38400
Immer das gleich...
> > Ist ein (jedenfalls mir :) bekannter Bug unter neueren Linux Versionen:
> > Nach einem fork() setzt Linux die Parameter einer geoeffneten seriellen
> > Schnittstelle zurueck. Hab deswegen in fhem.pl die komplette Initialisierungs-
> > Reihenfolge umgeschrieben (erst fork, dann parsen), ist in CVS eingecheckt.
>
> > Wir haben aber deutlich laenger gebraucht, bis wir das Problem gefuden haben :)
Gruß, ToM
Rudolf Koenig
> gesendet. Die gr�ne CUL LED blinkt nicht!
Komisch. Kannst du das bitte nachstellen?
- erst in fhem:
"set CUL raw l00" (led aus)
"set <FS20device> on" (led muss kurz aufblitzen)
- und falls est nicht geht, dann im screen/minicom/hyperterminal
l00
F12345600
> /dev/ttyACM0@9600
Die @ Variante ist fuer kaputte Linux distros notwendig (kaputt aus Sicht der
seriellen Schnittstelle). Ubuntu und ArchLinux war fureher mal in Ordnung, und
haben diese Variante nicht gebraucht. Eigentlich ist die Baudrate selber auch
unwichtig, nur die anderen Parameter, insbesondere echo in allen Variationen.
> Nun habe ich auch die aktuelle CVS probiert
Und das ist wiederum fuer neuere kaputte Linux Distros wichtig: Neuerdings wird
nach dem fork() (d.h. im Hintergrund schicken) die serielle Schnittstelle unter
Linux auch noch zurueckgesetzt (wieder auf kaputt). Kann erst mal vermeiden wenn man
"attr global logfile -" setzt, dann wird kein fork() gemacht. Praktisch beim
testen.
ToM
ich glaube mein Prob hätte besser hier gepasst:
http://groups.google.com/group/fhem-users/browse_thread/thread/89f800516a1438f2
"CUL empfängt, aber sendet nicht mehr nach einiger Zeit"
> > DerCULempf ngt tadellos, jedoch werden nicht immer alle Befehle
> > gesendet. Die gr neCULLED blinkt nicht!
Blinkt war hier der falsche Ausdruck!
Die LED "blitzt" kurz - dann wird auch ein Befehl ausgeführt.
Es funktioniert also erstmal....
Nach 10-20 Befehlen nacheinander ist dann Schluss. Danach werden nur
noch sporadisch Befehle gesendet!
Rudolf Koenig
> noch sporadisch Befehle gesendet!
Hilft denn ein "X21" (set CUL raw X21) um das wieder in den Gang zu bringen?
Wenn ja, dann verstellt sich wohl der Funkchip.
Ein regelmaessig abgesetzter X21 waere dann die Loesung. Oder ein RFR, da die
Frequenz bei jede RFR-Uebertragung (zweimal) neu eingestellt wird.
ToM
ich glaube mein Prob hätte besser hier gepasst:
http://groups.google.com/group/fhem-users/browse_thread/thread/89f800516a1438f2
"CUL empfängt, aber sendet nicht mehr nach einiger Zeit"
> > DerCULempf ngt tadellos, jedoch werden nicht immer alle Befehle
> > gesendet. Die gr neCULLED blinkt nicht!
Blinkt war hier der falsche Ausdruck!
Die LED "blitzt" kurz - dann wird auch ein Befehl ausgeführt.
Es funktioniert also erstmal....
ToM
wieder Schluss.
Wird nur beim Senden die Frequenz neu eingestellt?
Der Empfang funktioniert immer!
Wenn ich einige Minuten warte, kann ich wieder 10-20 Befehle
absetzten....
Ich habe einen FS20 SM8 der empfängt nur mit:
freq:868.000MHz bWidth:541KHz
Deshalb habe ich an den Parametern rumgeschraubt und häufig Befehle
abgesetzt.
Kann das die Ursache sein?
Rudolf Koenig
> absetzten....
Aaah. Da haben wir es -> LOVF: (1%) Limit Overflow.
Das zweite Parameter nach "get CUL raw X" muss groesser 0 sein.
Kaputte FHT's in der naehe? Was sagt denn "get CUL raw t02" ?
ToM
> Das zweite Parameter nach "getCULraw X" muss groesser 0 sein.
raw => 21 900
> Was sagt denn "getCULraw t02" ?
00026A4E
Die einzigen Sender sind FS20LS uns FS20S16 beide neu!
Was sonst so funkt ist die Fritz!Box (die bald den CUL "verpasst"
bekommt) / Fritz!Fon - WLAN.
Ein altes FS10 System (was bald ersetzt wird) ist noch in Betrieb. Ich
habe mal zu Sicherheit alle Sender abgeschaltet. Bringt aber nichts
neues.
Rudolf Koenig
> raw => 21 900
Schade, dann passt meine Theorie nicht :/