CUL + FHEM + FS20 - Verzweifelt
Steffen L
Ich komme einfach nicht mehr weiter, vielleicht hat ja hier jemand
eine Idee:
Ich bin seit ein paar Tagen Besitzer eines CUL Version 3.2 um meine
vorhandene FS20-Landschaft, die bis dato nur aus Steckdosen FS20ST-3
und Handsenders FS20S8-2 bestand, zu automatisieren.
CUL sollte unter Linux geflasht werden, allerdings hat das Einstecken
mit gedrücktem Mikroschalter zum Einfrieren des Systems geführt, also
unter Windows mit FLIP Firmware 1.44 draufgeflasht. Eingesteckt unter
Linux (Ubuntu Server 11.10), erkannst, Device erstellt, alles gut
soweit. Es gab noch das bekannte Problem mit den Zugriffsrechten (hier
in der Gruppe bereits diskutiert), per udev-Regel behoben, FHEM 5.1
installiert, Zugriff klappt.
Danach bin ich genau nach der Anleitung vorgegangen, nämlich den CUL
definiert (define CUL CUL /dev/CUL 1234), schaltbare Steckdose
definiert (define flur FS20 1234 56) und gesichert (save). Der Empfang
von Signalen funktioniert einwandfei, also wenn ich mit dem
vorhandenen Sender Schaltvorgänge auslöse sehe ich diese im Log, es
werden automatisch Devices angelegt und Logfiles geschriebe. Problem
ist das Senden.
Ich drücke den Knopf auf der Steckdose bis die LED blinkt, dann sende
ich ein Signal über den CUL. Die LED des CUL ist so programmiert, daß
sie nur beim Senden angeht, ich sehe, daß das passiert, und die LED
auf der Steckdose geht aus, also ist das Signal dort angekommen.
Danach klappt die Steuerung der Steckdose aber maximal einmal,
anschließend kommen keine Signale mehr dort an oder werden dort
ignoriert. Ich sehe im Log von FHEM nach dem Hochsetzen des Loglevels
auch, das ein Signal versendet wird, ob das aber wirklich die Antenne
verläßt weiß ich nicht. Ich habe bereits mehrere Dinge überprüft
(Sendebuffer, vorhandene Timeslots für den CUL etc.), aber jetzt bin
ich am Ende meines Lateins. Ich sehe auch keine USB-
Verbindungsabbrüche im Log, wie sie z.B. im FAQ erwähnt werden oder
ähnliches. Die Steckdose befindet sich ca. 1,5 Meter neben dem CUL,
dazwischen ist nur Luft.
Hat irgendjemand eine Idee, woran das liegen könnte? Macht es Sinn,
mal an den Funkparametern des CUL (Frequenz, Bandbreite etc.) zu
schrauben? Wenn ja, in welche Richtung? Kann es sein, daß evtl. die
Firmware nicht korrekt geflasht ist? Mir gehen hier echt die Ideen
aus.
Danke, Steffen
Rudolf Koenig
"define CUL CUL /dev/CUL@9600 0000" waere mir in dieser Situation lieber.
> Macht es Sinn, mal an den Funkparametern des CUL (Frequenz, Bandbreite etc.)
> zu schrauben? Wenn ja, in welche Richtung?
Ja, z.Bsp. bWidth groesser, oder bei gleicher bWidth freq in 0.1 MHz Schritten
aendern. Siehe auch "get CUL ccconf"
> Kann es sein, da� evtl. die Firmware nicht korrekt geflasht ist?
Ja. Wenn ccconf komisches meldet, hilft evtl. ein reset (set CUL raw e)
Steffen L
OK, vielen Dank. Ich habe jetzt nochmal die Firmware geflasht über
CULflash (geht übrigens unter Ubuntu nicht automatisch, weil dfu-
programmer root-Rechte braucht und der Daemon unter dem User fhem
läuft, außerdem fehlt fhem Schreibrechte unter /usr/share/fhem/FHEM)
und mit 9600 Baud rate neu angelegt, jetzt klappt das Senden (fast)
zuverlässig! Super!
Fast deswegen, weil offensichlich die Reichweite der Drahtantenne am
CUL nicht ausreichend ist. Direkt neben dem Sender klappt es, aber ein
paar Meter weiter (mit Wassertank dazwischen ;-) nicht mehr. Hier muß
ich mir etwas anderes überlegen. Gibt es Möglichkeiten ohne
Hardwareveränderungen die Reichweite zu verbessern?
Komischerweise habe ich jetzt ein anderes Problem mit dem Empfangen,
weil das Senden eines Signals des Handsenders bei FHEM jetzt ein
"unknown code/help me" erzeiugt, dafür mache ich aber einen
entsprechenden Thread in fhem-users auf.
Rudolf Koenig
> verbessern?
Ja, mWn sendet CUL nicht mit der maximale Staerke, als "set CUL raw x05" (x
klein!) koennte helfen, siehe auch commandref.html. Ich meine default ist x04.
Steffen L
Das hat's gebracht (bzw. set CUL raw x09). Vielen Dank, der Support
hier ist für ein (wie ich gelesen habe) Freizeitprojekt wirklich vom
allerfeinsten!
Zrrronggg!
viel ausmachen. Drehen der Antenne um 90 Grad oder verschieben um 20
Zentimeter kann Tag und Nacht sein.
Wassertank ist funktechnisch natürlich mit das Schlimmste was es
gibt.
Ansonsten bei installierter Lambda/4 mal über eine Lambda/2
nachdenken, könnte es auch bringen.
Frank
1.) Kann es sein, dass "set CUL raw x05" den CUL auf minimale
Sendeleistung einstellt? Ich meine mal gelesen zu haben, dass "set CUL
raw x04" bzw. "set CUL raw x09" auf maximale Sendeleistung schalten,
oder?
2.) Reicht es eigentlich, wenn man genau diesen Befehl ins fhem.cfg
einträgt? Kann man die Sendeleistung irgendwie auslesen?
3.) Kann mir einer den Unterschied der beiden Zeilen aus der fhem.cfg
erklären:
define CUL CUL /dev/ttyACM0 1234
Rudolf Koenig
> Sendeleistung einstellt? Ich meine mal gelesen zu haben, dass "set CUL
> raw x04" bzw. "set CUL raw x09" auf maximale Sendeleistung schalten,
> oder?
Sorry, da habe ich vorher Mist erzaehlt, und die Sache ist auch komplexer.
- default ist x08
- es existieren 2 Verstaerkerserien:
- mit einem jeweiligen "sanften" Anstieg (ramping) x0-x4
- ohne Anstieg (nahezu rechteckig): x5-x9
- das CUL selber "hoert" Signale mit ramping nicht, die FHT/FS20 Empfaenger
schon.
- Um auf dem CUL_V2 Speicher zu sparen, wird nur das x05-x09 angeboten, und x0
bis x4 entsprechend gemapped. Auf dem CULV2 (nur da!) ist also x04 == x09
Antwort: x05 ist sehr leise, ohne Ramping. Maximale Sendestaerke ist mit x04
oder x09 zu erreichen, wobei ich x09 bevorzugen wuerde.
> 2.) Reicht es eigentlich, wenn man genau diesen Befehl ins fhem.cfg
> eintr�gt?
Es reicht x09 einmal einzugeben, es wird im EEPROM gespeichert. Danach muss
aber das Senden mit X21 initialisiert werden (oder fhem neu starten)
> Kann man die Sendeleistung irgendwie auslesen?
Ja, mit einem Rxx oder Cxx Befehl, aber ich bin jetzt zu Faul aus
culfw/clib/fncollection.h oder aus CC1101.pdf die richtigen HEX Zahlen
zusammenzurechnen.
> 3.) Kann mir einer den Unterschied der beiden Zeilen aus der fhem.cfg
> erkl�ren:
> define CUL CUL /dev/ttyACM0 1234
Angesprochen wird /dev/ttyACM0 ueber Device::SerialPort, aber es werden keine
seriellen Parameter gesetzt (kein @...), fhem verlaesst sich auf die defaults
des Betriebsystems. Funktioniert leider nur bei (aus meiner Sicht) "guten"
Distributionen (ArchLinux, OSX, Ubuntu), leider aendert sich das aber auch von
Version zu Version. /dev/ttyACM0 beutet: Linux mit dem cdc_acm USB-Treiber.
1234 ist die FHT-Adresse des CULs: 12 wird bei der Kommuniklation mit dem
FHT80b verwendet, und 1234 fuer die direkte FHT8v Steuerung. Fuer die FS20
Kommunikation ist dieser Nummer irrelevant.
> define CUL CUL /dev/CUL@9600 0000
Hier hat jemand Linux (udev?) so konfiguriert, dass CUL als /dev/CUL
ansprechbar ist. fhem setzt wegen @9600 die seriellen Parameter. Die Baudrate
selber ist fuer das CUL total egal, nicht aber die anderen Parameter wie
"echo", sie wird z.Bsp implizit geloescht.
Bei eingeschalteten echo wird alles was culfw "sagt", von der Linux seriellen
Schnittstelle gleich zurueck ans culfw geschickt. Das waere praktisch, wenn im
CUL ein kleiner Kobold sehen wollte, was er tippt, so nervt es nur.
0000 bedeutet, dass im culfw die FHT "server" Funktionalitaet abgeschaltet
wird, und das CUL antwortet nicht selbstaendig auf irgendwelche FHT Anfragen.
Die FHT Meldungen selber werden trotzdem weitergereicht.
Rudolf Koenig
> - ohne Anstieg (nahezu rechteckig): x5-x9
Tippfehler: x00-x04 bzw. x05-x09
Frank
Ich habe mal etwas rumexperimentiert, aber irgendwie scheint es nicht
zu funktionieren?!
Habe das Register 0x1B ausgelesen. Laut Datenblatt sollte dort in den
Bits 3..5 (MAX_LNA_GAIN) die Sendeleistung abgelegt sein. Dort steht
auch alles auf 0 (=Maximum). Ändert man jetzt aber die Sendeleistung
folgendermassen ab:
set CUL raw x02
set CUL raw X21
get CUL raw C1B
Dann bleibt die 0 im Register stehen (immer noch volle
Sendeleistung?!).
Fehler, oder denke ich falsch?
Rudolf Koenig
Letzteres. Siehe auch culfw/cc1101.c, ccInitChip
Die Sendestaerke steht nicht in einem Register, sondern es sind 8, die ein
Verlauf der Sendestaerke beschreiben. Diesen Verlauf habe ich mit dem RF-Studio
von TI generiert, und nicht selbst erfunden.
Frank
set CUL raw x09
set CUL raw X21
Richtig?
Gehen die Einstellungen im SleepModus eigentlich verloren (wo wie in
der Spec beschrieben)?
Rudolf Koenig
> der Spec beschrieben)?
SleepModus gibt es nur fuer das CUR, und das will busware mangels Nachfrage
bzw. Preis/Leistungsverhaeltnis wohl nicht in Serie bauen. Etwas schade um die
Antialiased Font Routinen und Monitor-Mode.
Dafuer muss ich die Fhem<->CUR Dateiuebertragung nicht debuggen, und das
Einschlafen hat auch noch seine Macken.
Wo steht denn die o.g. Beschreibung im Spec?
Frank
> Wo steht denn die o.g. Beschreibung im Spec?
"Note that the content of the PATABLE is lost
when entering the SLEEP state, except for the
first byte (index 0)."
Ansonsten wären die folgenden Kommandos richtig?
Rudolf Koenig
>
> set CUL raw x09
> set CUL raw X21
Ja. Einmalig, soll also nicht ins fhem.cfg
Frank
(Sendeproblem):
Mich würde mal interessieren, was ein l/4 Wellenstrahler oder sogar
ein 1/2 Strahler im Vergleich zum Draht an Sendeleistung bringen
würde. Gibt es hier Erfahrungswerte?
Zrrronggg!
hat: 86.2mm. 1-2 mm mehr oder weniger ist nicht etwa vernachlässigbar,
sondern spürbar.
Mit Lage und Ausrichtung experimentieren bringt mehr. Schon wenn der
Draht zu nah an einer Wand baumelt, kann das dämpfen.
JörgB
> Der Draht ist ein Lambda 1/2 Strahler, sofern er die richtige Länge
> hat: 86.2mm. 1-2 mm mehr oder weniger ist nicht etwa vernachlässigbar,
> sondern spürbar.
habe auch mal eine Frage, da ich in Antennentechnik nicht so fit
bin. :)
Zählen die 4 mm der Lötstelle beim CUL mit dazu, da das Stück der
Platine ja auch mitsendet, oder müssen die abgezogen werden?
Das währen bei 86.2 mm Draht (ab Platinenende gemessen) plus 4 mm
Lötstelle 90.2 mm Antennenlänge oder?
Wenn das so ist, dann sollte die Antennenlänge doch nur 82.2 mm
betragen?
LG Jörg
JörgB
> betragen?
Zrrronggg!
Ich weiss es nicht. Ich gehe davon aus, dass die Länge jenseits des
Massekontakts des SMA Sockets zu messen ist. Ich weiss aber nicht, wie
die CUL Version ohne SMA Socket da genau aussieht und wie es sich da
verhält, mein CUL hat einen SMA Socket.
Aber: Wenn ich recht habe, ist der Unterschied deutlich spürbar. Man
könnte sich also eine Antenne mit und eine ohne die 4mm basteln und
dann die RSSI Daten von gepairten Sendern wie FHT80bs mal mitloggen
und sehen wo die besser sind.
Wo wir gerade dabei sind: Ein gut verwendbarer Sender zum testen von
Funklagen ist der FHT_HTTK. Der ist billig und klein und lässt sich
mit CUL/FHEM bestens als "Prüfsender" verwenden. Der gibt seinen
Status netterweise auch ohne Event alle 2 Minuten ab und man kann die
RSSI von dem Ding leicht einsehen. Um ihn in FHEM zu benutzen reicht
eine Zeile zur Definition und schon gehts los. Wenn ich den Verdacht
habe, dass eine Schaltsteckdose oder so nicht geht, weil die
Funktechnisch zu weit weg vom CUL liegt, lege ich einfach einen
FHT_HTTK an die Stelle und sehe mal mit was für einem RSSI der so beim
CUL reinkommt. Mit dso einem Dinge kann man auch schnell mal durchs
Haus wandeln und muss nix weiter tun, als an jeder Stelle 3 Minuten zu
warten.
Mit der Methode könnte man vielleicht schnell rausfinden, welche
Antennenlänge die richtige ist.
Frank
dauerhaft in die Firmware zu integrieren. Mit der originalen Firmware
kann man ja mit "set CUL raw x09" die Sendeleistung erhöhen.
Kann ich dies nicht einfach in die Firmware einbauen?
Wenn ich in der Funktion "cc_factory_reset" die Zeile "cc_set_pa(8);"
in "cc_set_pa(9);" ändere, sollte das doch damit erledigt sein, oder?
Wird die Funktion "cc_factory_reset" auf jeden Fall beim Poweron
jedesmal aufgerufen?
Rudolf Koenig
> Wird die Funktion "cc_factory_reset" auf jeden Fall beim Poweron
> jedesmal aufgerufen?
Nope. Factory Reset wird nur mit e aufgerufen. Sonst waeren ja die schoenen
EEPROM Werte weg, damit koennte man das EEPROM ganz sparen.
Frank
Der Befehl "set CUL raw x09" speichert den neuen Wert in EEPROM,
richtig?!
D.h er wird dann auch erstmal dauerhaft dort gespeichert und es macht
eigentlich
keinen Sinn, diesen in die Firmware einzubauen, richtig?
Wozu dient dann der Befehl "set CUL raw X21", der oben angesprochen
wurde?
Rudolf Koenig
> richtig?!
Ja.
> D.h er wird dann auch erstmal dauerhaft dort gespeichert und es macht
> eigentlich keinen Sinn, diesen in die Firmware einzubauen, richtig?
So sehe ich das (== ja).
> Wozu dient dann der Befehl "set CUL raw X21", der oben angesprochen
> wurde?
x != X
Die X Werte werden _nicht_ im eeprom gespeichert. X21 schreibt die
Konfiguration aus dem EEPROM (samt x Einstellung) ins CC1101. Ein "X21" wird
nur dann beim booten automatisch ausgefuehrt, falls das CUL eine RFR Adresse
hat.
Frank
eigentlich
der "Normalfall" ist), nach einem PowerOn (z.B. in der fhem.cfg) die
Konfiguration aus dem EEPROM selber laden muss (mittels X21)?
Also ich verstehe das jetzt eigentlich so:
EINMALIG (!) ein "set CUL Raw x09" abschicken und man sendet immer mit
höchstmöglicher
Leistung. Also auch, wenn man den CUL "abzieht und neu steckt"?!