Autor Thema: THGR122NX  (Gelesen 2299 mal)

Offline p-tech

  • New Member
  • *
  • Beiträge: 10
THGR122NX
« am: 15 April 2020, 14:57:37 »
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

Offline p-tech

  • New Member
  • *
  • Beiträge: 10
Antw:THGR122NX
« Antwort #1 am: 16 April 2020, 09:38:06 »
Keine Idee?

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

P.


Offline KölnSolar

  • Developer
  • Hero Member
  • ****
  • Beiträge: 5162
Antw:THGR122NX
« Antwort #2 am: 16 April 2020, 10:00:06 »
Mal nicht so ungeduldig.  ::) Liegt vielleicht auch an der unpräzisen Fragestellung.  ???

Willkommen bei FHEM.

Was ist
Zitat
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.  ???

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

Grüße Markus
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

Offline p-tech

  • New Member
  • *
  • Beiträge: 10
Antw:THGR122NX
« Antwort #3 am: 16 April 2020, 12:28:19 »
 :), 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 ;-)

Offline KölnSolar

  • Developer
  • Hero Member
  • ****
  • Beiträge: 5162
Antw:THGR122NX
« Antwort #4 am: 16 April 2020, 13:55:05 »
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.
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

Offline p-tech

  • New Member
  • *
  • Beiträge: 10
Antw:THGR122NX
« Antwort #5 am: 16 April 2020, 14:10:32 »
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.

Offline KölnSolar

  • Developer
  • Hero Member
  • ****
  • Beiträge: 5162
Antw:THGR122NX
« Antwort #6 am: 16 April 2020, 14:47:59 »
Zitat
Das hab ich gleich am Anfang getan, das funktioniert perfekt.
Prima, dann wissen wir das jetzt auch.

Zitat
Der RFXtrx433E wurde vom Autocreate nicht erkannt
Schritt 2 scheint dann das Problem zu sein ?
Zitat
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
define TRXUSB TRX /dev/serial/by-id/usb-RFXCOM_RFXtrx433_02VEJQFT-if00-port0@38400Wie genau verrät Dir ls /dev/serial/by-id/
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

Offline p-tech

  • New Member
  • *
  • Beiträge: 10
Antw:THGR122NX
« Antwort #7 am: 16 April 2020, 16:17:04 »
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.

Offline KernSani

  • Moderator
  • Hero Member
  • ***
  • Beiträge: 3532
Antw:THGR122NX
« Antwort #8 am: 16 April 2020, 16:27:38 »
Einen RFXCOMUSB gibt es nicht... das richtige device sollte ein TRX sein...
RasPi: RFXTRX, HM, zigbee2mqtt, mySensors, JeeLink, miLight, squeezbox, Alexa, Siri, ...

Offline KölnSolar

  • Developer
  • Hero Member
  • ****
  • Beiträge: 5162
Antw:THGR122NX
« Antwort #9 am: 16 April 2020, 16:32:05 »
Zitat
ohne noinit hat er geschrieben, dass keine Antwort vom Empfänger kommt und diesen ignoriert.
Vielleicht, weil er bereits von CuteCom in Beschlag ist ?  :-\

Zitat
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.... ::)
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

Offline p-tech

  • New Member
  • *
  • Beiträge: 10
Antw:THGR122NX
« Antwort #10 am: 16 April 2020, 21:00:03 »
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.

 

decade-submarginal