Hallo liebe Wissende, ich bin recht neu mit Fhem + RPi + CUL v.3_4 und habe nach einigen Erfolgserlebnissen nun ein Problem.
Auf meine CUL von Busware v.3_4 hab ich heute mit dem RPi die neuste fw geflasht und danach direkt in Betrieb genommen, ebenfalls am Pi. Das ging zunächst gut, ich hab einen FS20 S4A-2 angelernt und konnte fortan meinen Brunnen und meine Außenbeleuchtung ein und ausschalten, sowohl mit Fernbedienung, als auch über Webfrontend und App.
Nachdem ich den Pi dann an einen anderen Standort (aus dem Keller ins OG, näher an die Aktoren, obwohl keine Probleme aufgetreten sind) gestellt habe, kann ich nur noch empfangen und nicht mehr senden, sprich: die Ansteuerung der Aktoren über meinen FS20 S4A funktioniert, der Status in Fhem wird auch aktualisiert, nur aus Fhem selbst kann ich nicht mehr schalten.
Meine Recherche hat mir dann folgende Ansätze geliefert:
Einiges einstecken ausstecken reboots etc.
Baudrate auf 38400 geändert ohne Erfolg und wieder zurück
nano /etc/inittab gemäß http://www.michael-heck.net/index.php?option=com_content&view=article&id=57&Itemid=65 (//www.michael-heck.net/index.php?option=com_content&view=article&id=57&Itemid=65) verändert
nano /boot/cmdline.txt ebenso um getty loszuwerden
Empfangen klappt weiterhin, Senden weiterhin nicht. Mit der Aufstellung der Antenne sollte dies nichts zu tun haben, ich habe die 8dbi 30cm Antenne an mehreren Positionen immer mit gleichem Ergebnis aufgestellt.
Nach einem Reboot sieht der Log typischerweise so aus:
2013.08.09 18:23:35 0: Server shutdown
2013.08.09 18:26:43 1: Including fhem.cfg
2013.08.09 18:26:44 3: telnetPort: port 7072 opened
2013.08.09 18:26:46 3: WEB: port 8083 opened
2013.08.09 18:26:46 3: WEBphone: port 8084 opened
2013.08.09 18:26:46 3: WEBtablet: port 8085 opened
2013.08.09 18:26:47 3: Opening CUL device /dev/ttyACM0
2013.08.09 18:26:48 3: Setting CUL baudrate to 9600
2013.08.09 18:26:48 3: CUL device opened
2013.08.09 18:26:48 3: CUL: Possible commands: BCFiAZEGMRTVWXefmltux
2013.08.09 18:26:49 1: Including ./log/fhem.save
2013.08.09 18:26:49 1: usb create starting
2013.08.09 18:27:14 3: Opening CUL device /dev/ttyAMA0
2013.08.09 18:27:14 3: Setting CUL baudrate to 38400
2013.08.09 18:27:14 3: CUL device opened
2013.08.09 18:27:14 1: usb create end
2013.08.09 18:27:14 2: SecurityCheck: WEB,WEBtablet has no basicAuth attribute. telnetPort has no password/globalpassword attribute. Restart fhem for a new check if the problem is fixed, or set the global attribute motd to none to supress this message.
2013.08.09 18:27:14 0: Server started with 18 defined entities (version Fhem 5.4 (DEVELOPMENT), $Id: fhem.pl 3506 2013-07-26 08:57:39Z rudolfkoenig $, pid 1858)
2013.08.09 18:28:02 3: FS20 set Kugellichter on
2013.08.09 18:28:06 3: FS20 set Brunnen on
2013.08.09 18:28:39 3: FS20 set Brunnen off
2013.08.09 18:36:44 3: FS20 set Brunnen off
Ich hoffe ihr verzeiht meine Anfängerfrage und könnt mir auf die Sprünge helfen.
Beste Grüße, Laura
Hallo Laura,
ZitatEmpfangen klappt weiterhin, Senden weiterhin nicht.
Wenn das Empfangen klappt, dann sollte USB Schnittstelle keine Probleme machen. Das was Du gemäß der Anleitung von Michael Heck gemacht hast (er hat einen COC), ist für die serielle Schnittstelle, die der COC verwendet. Dein CUL verwendet die USB Schnittstelle, für die Du nichts beim Raspberry Pi freischalten musst.
Ich habe gerade ein ähnliches Problem:
- CUNO im OG schaltet FS20, der CSM im Keller empfängt dieses
- CSM im Keller schaltet sich selber, aber den CUNO im OG leider nicht
Daher muss ich auch mal schauen, an was das liegen könnte.
Sobald ich etwas weiß, lasse ich es Dich wissen.
Gruß PeMue
Hi Laura,
wie es aussieht, wird dein CUL zwei Mal definiert, mit unterschiedlichen Schnittstellen:
2013.08.09 18:26:47 3: Opening CUL device /dev/ttyACM0
...
2013.08.09 18:27:14 3: Opening CUL device /dev/ttyAMA0
Versuche doch mal nacheinander erst eine, dann die andere Def. auszukommentieren.
Die erste scheint von Hand definiert zu sein, die zweite per "usb create". Das kenne ich nicht.
Oder du lässt alles so und weist dem FS20- Gerät per iodev einen von den beiden zu.
Einer davon sollte senden können und das ist dann die funktionierende Definition.
Viel Erfolg
Frank
Zitat von: fiedel schrieb am Sa, 10 August 2013 08:30Hi Laura,
wie es aussieht, wird dein CUL zwei Mal definiert, mit unterschiedlichen Schnittstellen:
2013.08.09 18:26:47 3: Opening CUL device /dev/ttyACM0
...
2013.08.09 18:27:14 3: Opening CUL device /dev/ttyAMA0
Das ist mir gestern auch aufgefallen, ich hab dahinter allerdings eine Fehlerroutine vermutet, die eine andere Definition versucht falls die aktuelle fehlschlägt. Du hast aber Recht:
# Disable this to avoid looking for new USB devices on startup
#define initialUsbCheck notify global:INITIALIZED usb create
# If the above notify did not helped, then you probably have to enable some of
# the following lines. Verify first that /dev/xxx ist correct.
#define FHZ FHZ /dev/USB0
define CUL CUL /dev/ttyACM0@9600 1234
#attr CUL rfmode SlowRF
#attr CUL rfmode HomeMatic
Aus der zweiten Zeile die nun auskommentiert ist kam das usb create. Dementsprechend scheint das usb create mit meiner Hardware nicht korrekt zu funktionieren, denn seit ich nur noch die manuelle Definition aktiv habe funktioniert auch das Senden wieder.
Vielen vielen Dank und ein schönes Wochenende, Laura
Bin schwer begeistert... ;o)
Ebenfalls schönes WE!
Frank
So, leider muss ich mich nun nochmal melden. Nachdem das heute morgen nun prima geklappt hat funktioniert nun wieder nichts mehr vernuenftig. Über das Webfrontend bekam ich ständig 'connection lost, oben angezeigt, sodass ich mit attr WEB longpoll 0 erstmal Abhilfe geschaffen habe. Davon unabhängig lässt sich nun im Gegensatz zu heute Vormittag nur noch sporadisch und absolut unzuverlässig mein Brunnen FS20 schalten, während meine Kugellichter FS20 sich nie schalten lassen. Zudem werden im Webfrontend die statusicons nur noch manchmal angezeigt, auch bevor ich longpoll 0 gesetzt habe. Ein Update hat nichts gebracht :(
get CUL raw X liefert einen Wert > 800
Liebe Grüße, Laura
Hi Laura,
da ist Ferndiagnose wahrscheinlich nicht so einfach, aber ich geb dir mal Beispiele aus meiner Konfiguration, wo es mit FS20 keine Probleme gibt und der CUL (ein CUNO, aber das ist ja letztendlich das selbe) stabil arbeitet:
- longpoll habe ich wegen Floorplan gar nicht definiert, dafür aber:
attr WEB refresh 120
- das mit dem "get CUL raw X" stellt FHEM bei der Initialisierung automatisch ein, sollte also immer passen
- bei Sende/Empfangsproblemen kann es an der Reichweite oder am "LTE- Problem" liegen. Einige FS20- Komponenten sind nicht LTE- Störfest und werden vom LTE- Signal übersteuert. Das betrifft die Empfänger, die noch nicht die kleine Drahtantenne an der Empfangsplatine haben. Und es kann an den Einstellungen des CUL liegen. Bei mir sieht es so aus:
get CUL ccconf
bringt die Ausgabe:
CUL ccconf => freq:868.300MHz bWidth:325KHz rAmpl:42dB sens:4dB
Diese Werte kann man (fest) einstellen und sie bestimmen das Sende/Empfangsverhalten.
Hier noch mal ein Überblick:
(siehe Anhang / see attachement)
Bei Fragen, einfach fragen... ;o)
Viele Grüße
Frank