FHEM Forum

Hat jemand eine Firmware Version für den RFXtrx433E die mit FHEM noch funktioniert?

Der Transceiver meldet sich mit der aktuellen Firmware an FHEM nicht mehr an!

2016.03.13 13:39:09 3: Opening RFXtrx433E device /dev/serial/by-id/usb-RFXCOM_RFXtrx433_A1YUXLCQ-if00-port0
2016.03.13 13:39:09 3: Setting RFXtrx433E serial parameters to 38400,8,N,1
2016.03.13 13:39:09 3: RFXtrx433E device opened
2016.03.13 13:39:11 1: TRX: Initialization Error hexline='140100010253017f9fbe0301031c03005900000000', expected 0d0100......................
2016.03.13 13:39:11 1: Cannot init /dev/serial/by-id/usb-RFXCOM_RFXtrx433_A1YUXLCQ-if00-port0, ignoring it (RFXtrx433E)


Ich hab die neue 1001 Firmware zwar noch nicht getestet, aber
Du scheinst Dir die RFXtrx433E Ext2 Firmware runtergeladen zu haben.

Nimm einfach die ZIP "RFXtrx433E Ext Firmware"
Dort sind alle älteren Versionen enthalten, sollte die 1001 nicht funktionieren, kannst Du wieder auf eine frühere Revision wechseln

Cheers
mi.ke

@mi.ke
Das ist schon die richtige Firmware für den RFXtrx433E Ext.

Muss nur irgendwo die vorhergehende Firmware Versionen herbekommen.

Tach.
Auszug aus der History:

You only have to flash the latest firmware version.
The previous version is only present to enable you to go back in case of troubles.

RFXtrx433, RFXtrx433E, RFXrec433 change history:
============================================================
FW release 433_1001 18-02-2016
    Firmware type Ext2 released
    Firmware version restarted at 1 (combination with Type now)
    Firmware Type displayed in response message.
 

Type 2 für den (e) gibt es erst ab der Version 1001.
Willst Du eine ältere, musst Du weg von Type2.

Wie darf ich das mit TYP2 verstehen?

Habe nur die Firmware RFXtrx433_Ext_1001.hex auf den Transceiver gepackt und nicht die RFXtrx433_Ext2_1001.hex.

Eigentlich ist die Fehlermeldung komplett. Der rfx meldet sich anders als (mit der aalten fw) geplant. Eine Anpassung des moduls ist erforderlich

vg
joerg

Hallo,

bitte erst einmal die Konfiguration mit noinit, siehe commandref, also beispielsweise
define RFXTRXUSB TRX /dev/ttyUSB0@38400 noinit

ändern. Dann wird kein Initialisierungsstring gesendet und es sollte auch mit der 1001-Firmware laufen.

Ich habe die Info von RFXCOM bekommen, dass RFXCOM die Rückmeldung auf den Initiatlisierungsstring geändert hat, weil dies bzgl. der Länge nicht mehr passte.

Ich passe in Laufe der Woche die Rückmeldung im Modul an und stelle dann hier eine Testversion zur Verfügung, damit wir dies getestet haben, bevor ich es ins SVN packe.

Grüße

Willi

@Willi

Danke für den Tipp.
Funktioniert mit dem Parameter noinit wieder.

Ich habe gerade mal eine neue Version gebastelt. Vorsicht. Ist nicht getestet.
Damit sollte es auch ohne noinit laufen.

Bitte wie folgt vorgehen:
- Alte Version retten
- Neue Version testen und bitte Feedback.

Grüße

Willi

Zitat von: Willi am 14 März 2016, 19:31:42Damit sollte es auch ohne noinit laufen.

Abgesehen davon dass FHEM knapp 14 Stunden nichts mehr tut sieht es gut aus  ;)
sleep(50000); # wait 50 ms

Ich hatte vorher auch immer Probleme, mit oder ohne noinit.
Soweit scheint sich das jetzt verbessert zu haben.
Ich habe zusätzlich den Timeout auf 0.8 hochgesetzt.

Zitat von: Markus M. am 18 März 2016, 21:09:26
Abgesehen davon dass FHEM knapp 14 Stunden nichts mehr tut sieht es gut aus  ;)

Code Auswählen Erweitern

sleep(50000); # wait 50 ms

OOps! Das sollte usleep heissen. ;-)

Könntest Du es bitte mit
usleep(50000);
probieren?
Und die Ausgabe der Initialisierung posten?

Danke!

Hi,

mit usleep statt sleep gerade getestet:

Opening myrfxtrx device /dev/ttyUSB0
2016.03.19 12:08:31 3: Setting myrfxtrx serial parameters to 38400,8,N,1
2016.03.19 12:08:31 3: myrfxtrx device opened
2016.03.19 12:08:34 1: TRX: Init OK
2016.03.19 12:08:34 1: TRX: Init status: '433.92MHz transceiver, firmware=1001, protocols enabled: Lighting4 LaCrosse Hideki OREGON AC '

Funktioniert soweit.

Beste Grüße

Michael

Funktioniert mit usleep
2016.03.20 16:15:50 3: TRX device opened
2016.03.20 16:15:54 1: TRX: Init OK
2016.03.20 16:15:54 1: TRX: Init status: '433.92MHz transceiver, firmware=1001, protocols enabled: Lighting4 BlindsT1/T2/T3/T4 FS20 LaCrosse Hideki OREGON KOPPLA HOMEEASY AC X10 '

Wie ist der Status betreffend neuer Firmware.

Trotz Parameter noinit kommen keine Sensorwerte der Oregon Geräte mehr an.

Dürfte an den Signalduino Änderungen gelegen sein.

Ein Problem besteht seit Anfang an wo ich das RFXTRX Modul im Einsatz habe, das Sensoren die sehr Nahe beim Empfänger sind kaum Empfangen werden.

Ergänzend wäre die Einbindung der RSSI der Sensoren auch nicht schlecht wenn ich diese auswerten könnte.
Bei der Konfigurationssoftware des RFXTRX Sensors werden diese zumindest eingelesen.

Zitat von: Burny4600 am 23 März 2016, 18:20:52
Ergänzend wäre die Einbindung der RSSI der Sensoren auch nicht schlecht wenn ich diese auswerten könnte.
Bei der Konfigurationssoftware des RFXTRX Sensors werden diese zumindest eingelesen.

RSSI wird doch schon länger empfangen
attr Name_des_RFXTRX rssi 1

Cheers

mi.ke

Danke für die Info.

Ist die RSSI Ausgabe nur irgend ein Wert oder sollen db sein?

Zitat von: Burny4600 am 24 März 2016, 09:39:36Ist die RSSI Ausgabe nur irgend ein Wert oder sollen db sein?

RFXCOMs RFXmgr rechnet den rohen Wert in dBm um. Bei meinen THGR810 folgt das der Formel $dBm = -120 + 8*$raw.

Bei mir steht aber nur rssi 5 und keine dB.

Fein wäre es auch wenn sich diese RSSI Signale bei dennen der nanoCULs auch in die Liste einbinden lassen würden.

Zitat von: Burny4600 am 10 April 2016, 19:21:53Bei mir steht aber nur rssi 5 und keine dB.

Wie gesagt, RFXmgr rechnet den rohen Wert zusätzlich um, Fhem nicht. Bei mir hält die o.a. Formel, aber sie könnte Hardware- und/oder Firmware-abhängig sein. Die kann man ja in ein userReading basteln, wenn man mag, z.B.:
attr meinSensor userReadings rssi_dBm:rssi { -120 + 8*ReadingsVal("meinSensor","rssi",0) }

Danke für die Info.