Hi, meinen RFX habe ich mit der Fw 63 geflashed. Mit dem RFXMgr funktioniert alles super, die Signale werden erkannt, aber auf dem FhEM-Rechner gibts folgendes
2013.04.04 12:56:41.737 3: Opening RFXTRX device /dev/CUL_rfxtrx
2013.04.04 12:56:41.741 3: Setting RFXTRX baudrate to 38400
2013.04.04 12:56:41.759 3: RFXTRX device opened
2013.04.04 12:56:42.373 1: TRX: Initialization Error hexline='000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000d010001025240000c2f01010000'
2013.04.04 12:56:42.376 1: Cannot init /dev/CUL_rfxtrx, ignoring it
Ideen wo ich suchen kann??
Zitat von: Tobias schrieb am Fr, 05 April 2013 14:07Hi, meinen RFX habe ich mit der Fw 63 geflashed. Mit dem RFXMgr funktioniert alles super, die Signale werden erkannt, aber auf dem FhEM-Rechner gibts folgendes
2013.04.04 12:56:41.737 3: Opening RFXTRX device /dev/CUL_rfxtrx
2013.04.04 12:56:41.741 3: Setting RFXTRX baudrate to 38400
2013.04.04 12:56:41.759 3: RFXTRX device opened
2013.04.04 12:56:42.373 1: TRX: Initialization Error hexline='000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000d010001025240000c2f01010000'
2013.04.04 12:56:42.376 1: Cannot init /dev/CUL_rfxtrx, ignoring it
Ideen wo ich suchen kann??
Die vielen führenden "00" sehen seltsam aus.
Kommen immer so viele führende Nullen zurück?
Läuft der RFXtrx, wenn Du noinit verwendest:
define <name> TRX <device> noinit
Ich werde bei Gelegenheit mal die neue Firmware testen.
Grüße
Willi
I am running firmware 64. No problem with it.
2013.04.05 20:01:08 1: TRX: Init status: '433.92MHz transceiver, firmware=64, protocols enabled: Lighting4 LaCrosse Hideki Visonic OREGON HOMEEASY AC X10 '
{HT}
Hallo Tobias,
ich habe jetzt auch auf Firmware 64 geflasht. Läuft bei mir ohne Probleme.
Hast Du die Probleme immer noch?
Grüße
Willi
ja, das merkwürdige ist, wenn fhem dann läuft und mache ich dann redefine, wird der TRX auch korrekt initialisiert.
Dazu ein Änderungswunsch: kannst du den Status des TRX auf initialized setzen wenn er initialisiert ist?
Alle anderen (CUL, ECMD) machen das so.
Jetzt steht er nur auf opened, egal ob er initialisiert werden konnte oder nicht
gruss
Zitat von: Tobias schrieb am Mo, 08 April 2013 12:43ja, das merkwürdige ist, wenn fhem dann läuft und mache ich dann redefine, wird der TRX auch korrekt initialisiert.
Dazu ein Änderungswunsch: kannst du den Status des TRX auf initialized setzen wenn er initialisiert ist?
Alle anderen (CUL, ECMD) machen das so.
Jetzt steht er nur auf opened, egal ob er initialisiert werden konnte oder nicht
gruss
Hast Du das Update auf 64 gemacht? Wenn ja, was für eine Konfiguration hast Du genau? Diesen Fehler (führende 0) habe ich bisher noch nicht gesehen.
Die Anpassung bzgl. Initialized habe ich soeben gemacht. Das war noch ein Fehler vor Urzeiten seit ich
DevIO.pm nutze, welcher dieses opened setzt.
Ist jetzt im SVN und damit morgen per update verfügbar.
so siehts im Log aus wenn ich im fehem-webif "einfach" nochmal auf "DEF" klicke:2013.04.09 08:20:11.690 3: Opening RFXTRX device /dev/CUL_rfxtrx
2013.04.09 08:20:11.695 3: Setting RFXTRX baudrate to 38400
2013.04.09 08:20:11.712 3: RFXTRX device opened
2013.04.09 08:20:12.328 1: TRX: Init OK
2013.04.09 08:20:12.330 1: TRX: Init status: '433.92MHz receiver only, firmware=64, protocols enabled: LaCrosse Hideki OREGON HOMEEASY AC ARC X10 '
Edit: ich glaube allerdings nicht das es ein grundsätzlicher Fehler des TRX-Moduls ist.... ev. ein Bug der nur in bestimmten Situationen auftritt..?? Eben bei einem fhem Restart konnte gleich im ersten Anlauf initialisiert werden.
Hi Willi,
könntest du in einer freien Minute eine Neuinitialisierung einbauen?
Wenn das Device nicht initialisiert werden konnte und "nur" auf opened steht, soll automatisch nach 30sek nocheinmal initialisiert werden. Bis jetzt mach ich es manuell, bzw müsste mir noch ein notify ausdenken
Es sollte automatisch überprüft werden aob das Device noch verfügbar ist. Zb. beim Cul wird auch automatisch erkannt das es disconnected ist, auch der reappear sowie die neuinitialisierung wird automatisch durchgeführt.
Zitat von: Tobias schrieb am Fr, 19 April 2013 08:31Hi Willi,
könntest du in einer freien Minute eine Neuinitialisierung einbauen?
Wenn das Device nicht initialisiert werden konnte und "nur" auf opened steht, soll automatisch nach 30sek nocheinmal initialisiert werden. Bis jetzt mach ich es manuell, bzw müsste mir noch ein notify ausdenken
Es sollte automatisch überprüft werden aob das Device noch verfügbar ist. Zb. beim Cul wird auch automatisch erkannt das es disconnected ist, auch der reappear sowie die neuinitialisierung wird automatisch durchgeführt.
Eigentlich sollte es bei TRX genauso wie bei CUL ablaufen.
Wenn das Device disconnected und man es erneut verbindet, dann erfolgt automatisch der reconnect. Das funktioniert eigentlich schon immer.
Funktioniert das bei Dir nicht? Was passiert, wenn Du RFXtrx433 absteckst und neu ansteckst?
Ich kann die Anfangsinitialisierung so umändern, dass die Anzahl der Versuche erhöht wird oder die führenden Nullen ignoriert werden. 30 Sekunden warten ist problematisch, da dies das komplette FHEM-System blockiert (FHEM nutzt kein Multitasking).
Das Verhalten Deines Systems ist seltsam. Welche Hardware/Software setzt Du ein?
Ist es der in der Fussnote genannte Iomega iconnect?
Wäre es möglich den Kernel zu aktualisieren?
-- Willi
wenn ich das nächste Mal vor Ort bin teste ich das VErhalten beim Stecker abziehen. Bin aber der Meinung, das der TRX immer noch auf initializted stehen bleibt wenn ich den Stecker abziehe.. aber ich teste es nocheinmal genau.
Und Ja, es ist die IConnect mit fhem 5.4.
Linux Iconnect 2.6.37 #1 PREEMPT Sun Mar 6 13:17:17 CET 2011 armv5tel GNU/Linux
Das mit 30sek warten meinte ich, einen internel Timer zu generieren der die Initialize-Funktion nochmal aufruft
Der State ist eigentlich ziemlich egal.
Ich schaue mir mal an, ob das Reconnect bei CUL anders gelöst ist. Bei mir funktioniert es.
Wenn ich es richtig sehe, erfolgt die Intialisierung bei CUL auch beim define. Sofern der Init-String nicht funktioniert, wird das Gerät auch nicht mehr verwendet.
Wenn Deine Tests hier ergeben, dass sich hier RFXtrx433 anders als CUL verhält, würde mich das interessieren.
Du könntest bei Deinem Spezialfall mal probieren in 45_TRX.pm die Zeilen 239ff
} elsif ($buf !~ m/^\x0d\x01\x00.........../) {
my $hexline = unpack('H*', $buf);
Log 1, "TRX: Initialization Error hexline='$hexline'";
return "TRX: Initialization Error %name expected char=0x2c, but char=$char received.";
} else {
Log 1, "TRX: Init OK";
$hash->{STATE} = "Initialized";
# Analyse result and display it:
if ($buf =~ m/^\x0d\x01\x00(.)(.)(.)(.)(.)(.)(.)(.)(.)(.)(.)/) {
gegen folgende zu ersetzen:
} elsif ($buf !~ m/\x0d\x01\x00.........../) {
my $hexline = unpack('H*', $buf);
Log 1, "TRX: Initialization Error hexline='$hexline'";
return "TRX: Initialization Error %name expected char=0x2c, but char=$char received.";
} else {
Log 1, "TRX: Init OK";
$hash->{STATE} = "Initialized";
# Analyse result and display it:
if ($buf =~ m/\x0d\x01\x00(.)(.)(.)(.)(.)(.)(.)(.)(.)(.)(.)/) {
Also das ^ in den Regex am Anfang weglassen.
Wenn Du einen Vorschlag mit einem internal Timer hast, dass schick mir gerne das geänderte 45_TRX.pm zum Test.
Mir ist nicht klar wie Du das realisieren willst.
-- Willi
Hast Du mal probiert in 45_TRX.pm die Zeilen 239ff abzuändern (siehe vorheriger Beitrag)?
-- Willi
Hallo Tobias,
ich habe mir das nochmal angesehen.
Wenn man im laufenden Betrieb TRXtrx433 absteckt, kommt:
2013.04.21 17:05:06 1: /dev/ttyUSB0 disconnected, waiting to reappear
und der State wechselt zu "disconnected".
Nach Anstecken kommt
2013.04.21 17:05:11 3: Setting TRX_0 baudrate to 38400
2013.04.21 17:05:11 1: /dev/ttyUSB0 reappeared (TRX_0)
und der State geht wieder auf "opened".
Der einzige Unterschied zu CUL ist, dass bei einem Neuanstecken bei CUL die Initiatlisierung wieder erfolgt.
Darauf habe ich beim RFXtrx433 verzichtet, da dies m.E. keinen Vorteil bietet.
In DevIo_OpenDev (das nutze ich) wird das Gerät ignoriert, wenn die Intialisierung nicht funktioniert
(sowohl bei CUL also auch bei TRX).
Die Änderung der Regex funktioniert auch bei korrektem Rückgabestring. Daher bitte testen, ob es jetzt auch in Deinem speziellen Fall funktioniert.
Wenn nicht könnte man die Initialisierung evtl. mehrfach probieren.
Ich bin auf Firmware 61 und habe das gleiche Problem, nach nahezu jedem Neustart.
2013.04.13 02:22:26 3: Opening TRX device /dev/ttyUSB0
2013.04.13 02:22:26 3: Setting TRX baudrate to 38400
2013.04.13 02:22:26 3: TRX device opened
2013.04.13 02:22:27 1: TRX: Initialization Error hexline='00...viele...00d01000102533d000c2f01010000'
2013.04.13 02:22:27 1: Cannot init /dev/ttyUSB0, ignoring it
Hier die Initialisierung nochmal zu versuchen wäre gut.
Hast Du die Änderung der Regex (siehe Posting vom 19 April 2013 16:26) probiert?
Was war das Ergebnis?
Das sollte eigentlich helfen.
-- Willi
Jein. Ich hatte noch nicht neu gestartet da die Musik noch lief ;)
Soweit klappt das - ich hatte den Fehler aber auch vorher schon eine Woche lang nicht mehr.
Sollte es nochmal passieren, melde ich mich wieder.
Zitat von: Markus M. schrieb am Mi, 24 April 2013 00:51Jein. Ich hatte noch nicht neu gestartet da die Musik noch lief ;)
Soweit klappt das - ich hatte den Fehler aber auch vorher schon eine Woche lang nicht mehr.
Sollte es nochmal passieren, melde ich mich wieder.
Hallo Markus,
ich würde Dich gerne bitten intensiv zu testen, ob der Regex-Fix das Problem dauerhaft bei
Deiner Konfiguration löst.
Bei dem bisher gemeldeten Verhalten, würde ich dies annehmen. Ich möchte aber ungerne diese
Änderungen ins SVN einchecken, wenn nicht wirklich erforderlich. Es ist nicht absolut auszuschließen, dass
der Fix Nebeneffekte hat (auch wenn ich dies nicht erwarte), der bei anderen Nutzern zu Problemen führt.
Danke.
-- Willi
Nach ein paar Restarts und Reboots ist soweit alles ok.
TRX wurde jedesmal korrekt initialisiert.
Danke!
Leider ist mir jetzt aufgefallen dass 'shutdown restart' bei mir gar nicht funktioniert und der RasPi nicht jedes mal wieder hochkommt.
Hat aber nichts mit deinem Fix zu tun, da zumindest das erste Problem schon immer bestand.
Ich habe die Änderung der Regexp jetzt auch bei mir eingebaut und werde beobachten.
Gruss
Zitat von: Tobias schrieb am Do, 25 April 2013 07:38Ich habe die Änderung der Regexp jetzt auch bei mir eingebaut und werde beobachten.
Gruss
Super. Danke Tobias. Ich habe die Änderung bei mir auch drin.
Ich schlage vor wir schauen mal ein paar Tage und ich packe es nächste Woche ins SVN, wenn bis dahin alles ok ist.
-- Willi
Nachdem es keine weiteren Fehlermeldungen gab, habe ich die Änderung der Initialisierung (^ in regex weglassen)
jetzt ins SVN committed.
Hi Willi,
heute hatte ich den Fehler wieder.
Kanst du, analog zum ECMD, ein "set <device> reopen" einbauen?
Dann kann ich soetwas bauen:define RFXTRX_onlinecheck at +*00:10 {
my $state = ReadingsVal("RFXTRX", "STATE", "");
if(lc($state) !~ m/initialized/) {
Log 3, "RFXTRX nicht bereit!";
}
}
Hallo Tobias,
wie sah denn diesmal die Fehlermeldung aus?
Grüße
Willi
sieht identisch aus...
2013.05.24 14:00:06 3: Opening RFXTRX device /dev/CUL_rfxtrx
2013.05.24 14:00:06 3: Setting RFXTRX baudrate to 38400
2013.05.24 14:00:06 3: RFXTRX device opened
2013.05.24 14:00:06 1: TRX: Initialization Error hexline='000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000d010001025240000c2f01010000'
2013.05.24 14:00:06 1: Cannot init /dev/CUL_rfxtrx, ignoring it
Hmm. Das ist seltsam.
Ich habe die Änderung der Zeile 247 in 45_TRX.pm
if ($buf =~ m/\x0d\x01\x00(.)(.)(.)(.)(.)(.)(.)(.)(.)(.)(.)/) {
schon seit längerem im SVN.
Das sollte fehlertolerant gegen die führenden 00 sein.
Der von Dir angegebene string hätte darauf eigentlich passen müssen.
Welche Version von 45_TRX.pm verwendest Du? Wie sieht bei Dir Zeile 247 in 45_TRX.pm aus?
-- Willi
so siehts aus:
# $Id: 45_TRX.pm 3056 2013-04-08 18:34:59Z wherzig $
[...]
} else {
Log 1, "TRX: Init OK";
$hash->{STATE} = "Initialized";
# Analyse result and display it:
if ($buf =~ m/\x0d\x01\x00(.)(.)(.)(.)(.)(.)(.)(.)(.)(.)(.)/) {
my $status = "";
Hallo Tobias,
ich teste aus, warum das nicht funktioniert hat. Dann fixe ich es oder baue Dir Dein Reset.
Komme aber vermutlich erst am Wochenende dazu.
-- Willi
Hallo Tobias,
wie oft ist das Problem in der Zwischenzeit noch aufgetreten?
Ich bin gerade dabei meine TODO-Liste für RFXtrx433 anzuschauen und hatte Deinen Thread ganz "vergessen"...
Es gab gemäß Link (http://forum.fhem.de/index.php?topic=13224.msg82836#msg82836) sowie
http://forum.fhem.de/index.php?t=msg&goto=82097&rid=136&srch=rfxtrx433#msg_82097 (//forum.fhem.de/index.php?t=msg&goto=82097&rid=136&srch=rfxtrx433#msg_82097)
Probleme mit DevIo.pm und BlockingCall.pm.
Nach der Beschreibung könnte es plausibel sein, warum es bei mir mit nur einem Device nicht
auftrat, bei Dir aber mit mehreren Devices.
Wurde erst vor kurzem gefixt. Evtl. hatte Dein Problem auch damit zu tun und ist jetzt nach neuesten
update in Ordnung.
-- Willi
Zumindest ich hatte das Problem mit der fehlgeschlagenen Initialisierung seit deiner Änderung im Mai nicht mehr.
Hi Willi,
Da ich an dem System seit dem nicx mehr verändert habe und es als produktives system nicht neu gestartet wurde, hatte ich auch den Fehler nicht mehr. Ich merke es erst wenn aus irgendeinem Grund ein Neustart ansteht (stromausfall etc). ICh melde mich aber wieder sobald ich es feststellen sollte (plus nach einem update um die neuesten Bugfixe zu haben)
Danke aber das du an mich gedacht hast :)
Nichts-desto-trotz ist es immer gut eine "set <dev> reopen" zu haben ;)
Hallo,
ich glaube bei mir tritt häufiger ein ähnlicher Fehler auf, wenn ich in der fhem.cfg editiert habe und mit "Save fhem.cfg" gespeichert habe.
Als Hinweis:
Ich hatte zwischendurch mal zwei weitere CUL angeschlossen, die im Moment nicht mehr dran sind.
Wenn ich "shutdown restart" mache, klappt es scheinbar immer.
Wenn ich mehrfach "Save fhem.cfg" mache klappt es auch irgendwann.
Scheint ein Timing Problem zu sein.
2014.12.26 17:56:27 1: Including fhem.cfg
2014.12.26 17:56:27 3: telnetPort: port 7072 opened
2014.12.26 17:56:27 3: WEB: port 8083 opened
2014.12.26 17:56:27 3: WEBphone: port 8084 opened
2014.12.26 17:56:27 3: WEBtablet: port 8085 opened
2014.12.26 17:56:28 2: eventTypes: loaded 1535 events from ./log/eventTypes.txt
2014.12.26 17:56:28 3: Opening CUL1 device /dev/ttyACM0
2014.12.26 17:56:28 3: Can't open /dev/ttyACM0: No such file or directory
2014.12.26 17:56:28 3: Opening CUL2 device /dev/ttyACM1
2014.12.26 17:56:28 3: Can't open /dev/ttyACM1: No such file or directory
2014.12.26 17:56:29 3: Opening TRX_0 device /dev/ttyUSB0
2014.12.26 17:56:29 3: Setting TRX_0 baudrate to 38400
2014.12.26 17:56:29 3: TRX_0 device opened
********* Diese Zeile ist nur zur optischen Unterstützung ***************
2014.12.26 17:56:29 1: TRX: Initialization Error: No character read
2014.12.26 17:56:29 1: Cannot init /dev/ttyUSB0, ignoring it (TRX_0)
2014.12.26 17:56:29 1: Including ./log/fhem.save
2014.12.26 17:56:38 1: Including fhem.cfg
2014.12.26 17:56:38 3: telnetPort: port 7072 opened
2014.12.26 17:56:38 3: WEB: port 8083 opened
2014.12.26 17:56:38 3: WEBphone: port 8084 opened
2014.12.26 17:56:38 3: WEBtablet: port 8085 opened
2014.12.26 17:56:39 2: eventTypes: loaded 1535 events from ./log/eventTypes.txt
2014.12.26 17:56:39 3: Opening CUL1 device /dev/ttyACM0
2014.12.26 17:56:39 3: Can't open /dev/ttyACM0: No such file or directory
2014.12.26 17:56:39 3: Opening CUL2 device /dev/ttyACM1
2014.12.26 17:56:39 3: Can't open /dev/ttyACM1: No such file or directory
2014.12.26 17:56:40 3: Opening TRX_0 device /dev/ttyUSB0
2014.12.26 17:56:40 3: Setting TRX_0 baudrate to 38400
2014.12.26 17:56:40 3: TRX_0 device opened
2014.12.26 17:56:40 1: TRX: Init OK
2014.12.26 17:56:40 1: TRX: Init status: '433.92MHz transceiver, firmware=231, protocols enabled: LaCrosse Hideki OREGON AC ARC X10 '
2014.12.26 17:56:40 1: Including ./log/fhem.save
Hallo,
ich habe mit einen RTXTRX433E besorgt, um dann damit meine Rollläden von Somfy steuern zu können.
Das funktioniert aber noch nicht ganz wie gewollt. Meine Fehlermeldung ist nämlich auch der hier angesprochene "Initialization error: No character read"
Ein paar Infos zu meinem Setup und dem (Fehl)verhalten, das bei mir auftritt.
Nach dem Verbinden des Sensors mit dem Rechner erhalte ich in meinem Linux in dmesg eine Meldung, dass der Sensor gefunden wird und per /dev/ttyUSB0 ansprechbar ist.
[5800760.652801] usb 2-1.1: new full-speed USB device number 83 using ehci-pci
[5800760.744260] usb 2-1.1: New USB device found, idVendor=0403, idProduct=6001
[5800760.744275] usb 2-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[5800760.744278] usb 2-1.1: Product: RFXtrx433
[5800760.744280] usb 2-1.1: Manufacturer: RFXCOM
[5800760.744282] usb 2-1.1: SerialNumber: A1XZPWYE
[5800760.746665] ftdi_sio 2-1.1:1.0: FTDI USB Serial Device converter detected
[5800760.746687] usb 2-1.1: Detected FT232RL
[5800760.746689] usb 2-1.1: Number of endpoints 2
[5800760.746691] usb 2-1.1: Endpoint 1 MaxPacketSize 64
[5800760.746692] usb 2-1.1: Endpoint 2 MaxPacketSize 64
[5800760.746694] usb 2-1.1: Setting MaxPacketSize 64
[5800760.747187] usb 2-1.1: FTDI USB Serial Device converter now attached to ttyUSB0
Da freut man sich doch schon mal. Ich habe das übrigens direkt am PC versucht und über einen USB-Lan-Extender... beides mal selbige Meldung (was mich beim USB-Lan-Extender fast schon überrascht hat :-))
Gut... nun sollte man das Teil ja in fhem konfigurieren können.
Sicherheitshalber habe ich noch ein update all vorgenommen.
Ich musste auch noch das perl-Modul Device::SerialPort nachinstallieren (bisher verwende ich noch keine CUL, sondern einen HM-LAN Gateway und ein Brennestuhl 433Mhz LAN-Interface).
Nach diesen Installationen habe ich folgendes in meiner Konfiguration "fhem.cfg" hinzugefügt:
# RFXTRX USB Gateway (TRX)
define TRX_0 TRX /dev/ttyUSB0@38400
define FileLog_TRX_0 FileLog ./log/TRX_0-%Y.log TRX_0
attr FileLog_TRX_0 logtype text
define Stehlampe2 TRX_LIGHT ARC FF000000 light
attr Stehlampe2 IODev TRX_0
Nach einem Neustart von fhem (per service fhem stop und anschließendem service fhem start), erscheint der InitializationError in meinem Logfile.
Der Vollständigkeit halber hier der genaue Auszug:
2015.01.12 21:40:00 3: Opening TRX_0 device /dev/ttyUSB0
2015.01.12 21:40:00 3: Setting TRX_0 baudrate to 38400
2015.01.12 21:40:00 3: TRX_0 device opened
2015.01.12 21:40:01 1: TRX: Initialization Error: No character read
2015.01.12 21:40:01 1: Cannot init /dev/ttyUSB0, ignoring it (TRX_0)
Ich bin ehrlich gesagt sehr ratlos.
Nachdem ich nun ein Firmware-Update auf die letzte Version (235) des RFXTRX433E durchgeführt habe, hat sich nichts am Verhalten geändert.
Im Rfxmngr funktioniert das Gerät (allerdings auf meinem Windows-Client und nicht am Linux-Server, auf dem Fhem läuft) alles problemlos... an der Hardware wird's also nicht liegen).
Dass das Gerät "manchmal" (oder bei Verwendung von shutdown restart) initialisiert werden kann, könnte ich nicht behaupten...
... bei mir kam der Fehler bisher immer.
Was könnte ich denn als nächstes ausprobieren?
Kann ich sonst noch irgendwelche Informationen bereitstellen oder eine bestimmte Lösung testen?
LG,
Niko
Hast du noch was mit USB abgeschlossen? JeeLink etc?
Auf welcher Hardware läuft Fhem??
Mehr Infos bitte.
Gruß Volker
Die Infos gebe ich gerne :-)
Also die Hardware auf der FHEM läuft ist ein "echter" Server.
Hardwaretechnisch ist da ein Xeon E1220L verbaut, welcher auf einem Intel-Mainboard arbeitet und 16GB RAM zur Verfügung hat.
Das werkelt alles auf einer SSD, die unter CentOS 7 läuft (Kernel Version 3.10). Angebunden sind auch zwei RAIDs (5er RAID und 1er RAID für Backups).
USB-technisch angeschlossen ist nicht wirklich viel bzw. wurde darauf geachtet, dass alle Geräte möglichst selten aktiv sind.
Prinzipiell hängt an dem Server ein USB-Hub auf welchem dann wieder Maus und Tastatur hängen.
Dieser Hub ist aber hardware-technisch (per Kippschalter) ausgeschaltet und wird nur bei Wartung aktiviert (würde mich also wundern, wenns damit Probleme gibt).
Dann gibt's noch eine USB3-Kontrollerkarte im Server (da das das Intel-Mainboard nicht anbietet), an welchem dann eine USB-Platte für ein "externes" Backup sorgt.
Diese Festplatte ist aber auch meist vom Strom getrennt. Nur einmal im Monat erhält die Festplatte Strom und erstellt dann ein Backup (wird über eine udev-Rule gesteuert).
Das "Stromerhalten" erfolgt übrigens über FHEM. Sozusagen ein "selbstsicherndes" System :-)
Ansonsten Gibt es noch einen weiteren HDD-Controller, der über USB eingebunden ist und für Testzwecke von HDDs eingesetzt wird. Aber auch der hat im Normalfall keinen Strom...
Ein "lsusb" lieftert mir folgendes:
Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 003: ID 046b:ff10 American Megatrends, Inc. Virtual Keyboard and Mouse
Ein JeeLink kommt nicht zum Einsatz.
Bisher sind alle FHEM-Sender per LAN angebunden (ein HM-LAN Gateway und ein Brennstuhl Brematic 433 GW).
LG,
Niko
Habe heute wieder etwas Zeit zum testen gefunden.
Also dass das Device in FHEM gar nicht funktioniert kann ich revidieren.
Bei mir ist das Verhalten wie folgt:
Ich bekomme immer den InitializationError, wenn ich dehm starte, wenn mein RFXTRFX433E verbunden ist.
Mache ich aber folgende in der angegebenen Reihenfolge, dann funktioniert die Initilisierung (und wirklich nur dann).
1) RFXTRX ausstecken
2) FHEM per init-skript stoppen (oder auch per service fhem stop
3) FHEM per init-skript starten (oder auch per service fhem start). Wichtig: Hier darf der RFXTRX nicht verbunden sein
Das FHEM_Log sieht dabei wie folgt aus:
2015.01.13 23:11:44 0: Server shutdown
2015.01.13 23:12:05 1: Including fhem.cfg
2015.01.13 23:12:05 3: telnetPort: port 7072 opened
2015.01.13 23:12:05 3: WEB: port 9083 opened
2015.01.13 23:12:05 3: WEBphone: port 9084 opened
2015.01.13 23:12:05 3: WEBtablet: port 9085 opened
2015.01.13 23:12:05 2: eventTypes: loaded 275 events from ./log/eventTypes.txt
2015.01.13 23:12:05 1: HMLAN_Parse: HMLAN101 new condition disconnected
2015.01.13 23:12:05 3: Opening HMLAN101 device 192.168.0.101:1000
2015.01.13 23:12:05 3: HMLAN101 device opened
2015.01.13 23:12:05 1: HMLAN_Parse: HMLAN101 new condition init
2015.01.13 23:12:05 3: Opening TRX_0 device /dev/ttyUSB0
2015.01.13 23:12:05 3: Can't open /dev/ttyUSB0: No such file or directory
2015.01.13 23:12:05 1: Including ./log/fhem.save
2015.01.13 23:12:05 0: Server started with 52 defined entities (version $Id: fhem.pl 7528 2015-01-11 18:23:31Z rudolfkoenig $, os linux, user niko, pid 22444)
2015.01.13 23:12:05 1: HMLAN_Parse: HMLAN101 new condition ok
2015.01.13 23:12:10 3: Device CUL_HM_HM_ES_PMSw1_Pl_2C1290 added to ActionDetector with 000:10 time
2015.01.13 23:12:11 3: CUL_HM set CUL_HM_HM_ES_PMSw1_Pl_2C1290_Sw statusRequest
2015.01.13 23:12:12 3: CUL_HM set CUL_HM_HM_LC_SW1_PL2_258CDC statusRequest
4) RFXTRX per USB verbinden. Im Logfile von FHEM erscheint daraufhin:
2015.01.13 23:12:25 3: Setting TRX_0 baudrate to 38400
2015.01.13 23:12:25 1: /dev/ttyUSB0 reappeared (TRX_0)
5) "shutdown restart" ausführen (bspw. per Web-Oberfläche). Nun wird RFXTRX erkannt und initialisiert. Das Logfile beinhaltet dabei:
2015.01.13 23:12:53 0: Server shutdown
2015.01.13 23:12:55 1: Including fhem.cfg
2015.01.13 23:12:55 3: telnetPort: port 7072 opened
2015.01.13 23:12:55 3: WEB: port 9083 opened
2015.01.13 23:12:55 3: WEBphone: port 9084 opened
2015.01.13 23:12:55 3: WEBtablet: port 9085 opened
2015.01.13 23:12:55 2: eventTypes: loaded 275 events from ./log/eventTypes.txt
2015.01.13 23:12:55 1: HMLAN_Parse: HMLAN101 new condition disconnected
2015.01.13 23:12:55 3: Opening HMLAN101 device 192.168.0.101:1000
2015.01.13 23:12:55 3: HMLAN101 device opened
2015.01.13 23:12:55 1: HMLAN_Parse: HMLAN101 new condition init
2015.01.13 23:12:55 3: Opening TRX_0 device /dev/ttyUSB0
2015.01.13 23:12:55 3: Setting TRX_0 baudrate to 38400
2015.01.13 23:12:55 3: TRX_0 device opened
2015.01.13 23:12:55 1: TRX: Init OK
2015.01.13 23:12:55 1: TRX: Init status: '433.92MHz transceiver, firmware=235, protocols enabled: OREGON AC ARC X10 '
2015.01.13 23:12:55 1: Including ./log/fhem.save
2015.01.13 23:12:55 0: Server started with 52 defined entities (version $Id: fhem.pl 7528 2015-01-11 18:23:31Z rudolfkoenig $, os linux, user niko, pid 22540)
2015.01.13 23:12:55 1: HMLAN_Parse: HMLAN101 new condition ok
6) Das war's. Damit sollte RFXTRX funktionieren (habs noch nicht weiter getestet, aber zumindest sieht das Log jetzt besser aus)
Warum das genau so ist, kann ich nicht sagen.
Hat dazu jemand eine Idee?
LG,
Niko
Vielleicht belegt beim Start irgendwas dein USB0
Binde ihn doch mal über seine Serial ID an
http://forum.fhem.de/index.php/topic,31823.msg243054.html#msg243054 (http://forum.fhem.de/index.php/topic,31823.msg243054.html#msg243054)
Gruß Volker
Hallo Volker,
danke für den Tipp.
Ich habs jetzt pber die ID (ist bei mir /dev/serial/by-id/usb-RFXCOM_RFXtrx433_A1XZPWYE-if00-port0) versucht.
Damit funktioniert das Device leider überhaupt nicht.
Ich bekomme zwar die Meldung "device reappeared" (so wie oben beschrieben), aber beim snschließenden "shutdown restart" scheitert dann das init immer.
Also bleibe ich wohl doch lieber bei der Angabe von /dev/ttyUSB0... damit funktionierts wenigstens mit der oben aufgelisteten Anleitung
LG,
Niko
Okay,schad
Die Baurate hattest du schon auch angehängt ? (@38400)
Hmm... stimmt... bei der Umstellnug auf die "by-id" hatte ich wirklich die Baudrate vergessen.
Wird sofort nachgeholt, wenn ich heute Abend wieder zu Hause bin :)
Hab gerade nochmal das Ansprechen des Devices über "by-id" mit angegebener Baudrate versucht.
Damit verhält sich das Device komplett identisch wie bei Angabe von /dev/ttyUSB0.
Also funktioniert die Initialisierung nur dann, wenn man genau nach dem oben geposteten Verfahren vorgeht (und damit leider alles andere als zuverlässig).
Bei mir kommt beim Neustarten des FHEM meistens auch der Initialisierungfehler:
2015.09.13 20:31:50 3: Opening RFXTRXUSB device /dev/RFXtrx433
2015.09.13 20:31:50 3: Setting RFXTRXUSB serial parameters to 38400,8,N,1
2015.09.13 20:31:50 3: RFXTRXUSB device opened
2015.09.13 20:31:51 1: TRX: Initialization Error: No character read
2015.09.13 20:31:51 1: Cannot init /dev/RFXtrx433, ignoring it (RFXTRXUSB)
Als Workaround lasse ich jetzt folgenden "Watchdog" laufen. Damit reinitialisiert sich RFXTRXUSB meist erfolgreich.
define RFXTRXUSB.watchdog at +*00:05 {\
\
if (InternalVal ("RFXTRXUSB","STATE","") eq "opened")\
{ fhem('modify RFXTRXUSB /dev/RFXtrx433@38400');;\
}\
\
}
attr RFXTRXUSB.watchdog alignTime 00:00