THGR122NX

[p-tech]

Hallo!

Ich versuche erfolglos meine THGR122NX-Sensoren vom Oregon über RFXtrx433E zu empfangen. Mit dem CuteComm sehe ich die richtigen 80-Bit Strings kommen, die Schnittstelle scheint also OK zu sein. In FHEM habe ich den Empfänger mit define RFX_TRX RFXCOMUSB@38400 noinit definiert. Dann attr longids THGR122NX (auch THGR228N versucht) eingegeben. Auf eine Win-Machine habe ich mit dem RFX-manager meine Sensoren aufgefangen: z.B. ID47 auf dem Kanal 3. Egal wie ich die Sensoren definiere (define Temp_3 OREGON THGR122NX_47_3 oder THGR228N_47_3) sehe ich im Log nur ankommende Daten in Blöcken verschiedener Längen im Format RFX_TRX: unknown code xxxxxxxxxxxxxxxxxx, help me!

Was mache ich falsch?

Danke und schöne Grüße

Petr

[p-tech]

Keine Idee?

Die Ausgabe im Log sieht so aus: (siehe Screenshot)

P.

[KölnSolar]

Mal nicht so ungeduldig.  Liegt vielleicht auch an der unpräzisen Fragestellung. 

Willkommen bei FHEM.

Was ist

CuteComm

? Hat mit FHEM herzlich wenig zu tun. Entweder beziehst Du Dich auf den RFXTRX-Manager oder FHEM.

Mit eingeschaltetem autocreate müsste Dir der Sender ohne Probleme automatisch angelegt werden. 

Code Auswählen Erweitern

define RFX_TRX RFXCOMUSB@38400 noinit
Die def ist aber sehr seltsam. Wie ist Deine Systemumgebung bzgl. des RFXTRX ?

Grüße Markus

[p-tech]

 , Ja, die Geduld gehört wohl nicht zu meinen Stärken...

CuteCom ist ein ser. Terminal. Mit dem habe ich geprüft, ob der Rechner selbst die Telegramme empfängt und die Inhalte stimmen.
Und zu der Fragestellung: ich bin am Anfang, ich würde zuerst mal gerne die Temperatur/Feuchtigkeit im Log des FHEMs sehen anstatt desen Hilferufe

[KölnSolar]

Auch wieder recht spärlich...

Um überhaupt mal sicherzugehen, dass der RFX den Sensor RICHTIG empfängt, musst Du es mal mit dem RFXMGR testen. Hängt ja alles auch von der von Dir gewählten firmware(uns unbekannt) und den gewählten Protokolleinstellungen(uns unbekannt) ab.

[p-tech]

Das hab ich gleich am Anfang getan, das funktioniert perfekt. Mit dem RFXMGR hab ich mir auch die IDs und Kanäle der einzelnen Sensoren ausgelesen und aufgeschrieben. Genauso die ankommenden Daten. Die sind grundsätzlich auch mit denen identisch, die jetzt im FHEM-Log angezeigt werden, nur kommen sie vom FHEM eben nicht in den zu erwartenden 80 Bit Blöcken, sondern zufällig verklebt und zerrisen. (Siehe screenshot in dem vorigen Posting).

Der RFXtrx433E wurde vom Autocreate nicht erkannt, ich habe es nach Google-Anleitung aus diversen Foren dann eben mit dem hädischen define si hingekriegt, dass überhaupt was empfangen wird.

Es wird mal auf einem Raspberry laufen, derzeit teste ich auf einem Raspberry-ISO in der VirtualBox.

Der RFX-Empfänger lief schon mal mit dem openHAB, dort funktionierte er auch.

[KölnSolar]

Das hab ich gleich am Anfang getan, das funktioniert perfekt.

Prima, dann wissen wir das jetzt auch.

Der RFXtrx433E wurde vom Autocreate nicht erkannt

Schritt 2 scheint dann das Problem zu sein ?

define RFX_TRX RFXCOMUSB@38400 noinit

Die def ist aber sehr seltsam. Wie ist Deine Systemumgebung bzgl. des RFXTRX ?

Leider noch keine Antwort.

Ein define sollte üblicherweise so aussehen

Code Auswählen Erweitern

define TRXUSB TRX /dev/serial/by-id/usb-RFXCOM_RFXtrx433_02VEJQFT-if00-port0@38400
Wie genau verrät Dir

Code Auswählen Erweitern

ls /dev/serial/by-id/

[p-tech]

Da ist mir ein Teil der RFX Definition verloren gegangen. Cirrect ist:

define RFX_TRX RFXCOMUSB /dev/ttyUSB0@38400 noinit

Ohne @38400 hat er versucht mit 4800 bps zu kommunizieren und ohne noinit hat er geschrieben, dass keine Antwort vom Empfänger kommt und diesen ignoriert. Mit Googles-Hilfe habe ich die Einstellungen gefunden.

Systemumgebung ist ein Rasperian in einer VirtualBox, wenn alles läuft wandert es auf eine "echte" Raspberry. RFX hängt über USB direkt am Rechner, USB ist verbunden und wie gesagt, der am virtuellen Raspi laufender CuteCOm Terminal kann die seriellen Telegramme vom RFX empfangen. Der FHEM irgendwie auch, denn im Log tachne sie auf, bloß in falschen Blöcken.

[KernSani]

Einen RFXCOMUSB gibt es nicht... das richtige device sollte ein TRX sein...

[KölnSolar]

ohne noinit hat er geschrieben, dass keine Antwort vom Empfänger kommt und diesen ignoriert.

Vielleicht, weil er bereits von CuteCom in Beschlag ist ? 

Systemumgebung ist ein Rasperian in einer VirtualBox

Find ich auch nicht gerade hilfreich, um einem Problem auf die Spur zu kommen. Je mehr Variable, umso größer die Fehlermöglichkeiten u. -quellen.

Daher die Schritte:
- Test mit RFXMGR
- Anbindung an nacktes Debian oder was auch immer
- wenn USB-Serial erkannt wird, Definition in FHEM(ohne noinit) u. bei Fehlern Logmeldungen posten

Edit: Hi, Oli. Jetzt erst gesehen. Hätte der TE mal mein Beispiel gelesen....

[p-tech]

OK, Danke für die Tips! define TRX anstatt des RFXCOMs ist die Lösung, schon funktioniert autocreate auch in der virtuellen Box! Die Werte kommen prima an. Der Abend ist gerettet, morgen wird weiter gearbeitet.